PyTorch tidak mendeteksi GPU: pemeriksaan apa yang harus dilakukan lebih dulu?

Alur diagnosis dalam empat keputusan

Tujuannya adalah menemukan lapisan pertama yang gagal, bukan mencoba beberapa pemasangan berturut-turut. Simpan perintah yang dijalankan, pesan error pertama, dan hasil setiap pemeriksaan. Jika Anda mengubah Python, paket PyTorch, dan ukuran batch sekaligus, Anda tidak akan tahu perubahan mana yang menyelesaikan masalah.

Skrip yang dapat diunduh menerapkan alur ini dan menghasilkan laporan teknis yang terbatas. Skrip ini tidak menjalankan model Anda dan tidak mengubah pemasangan Anda. Gunakan di lingkungan yang sama dengan proyek Anda, jika tidak Anda akan memeriksa interpreter yang berbeda dari program yang bermasalah.

• Unduh skrip diagnostik Kernodeck v1 ↓
• Baca opsi dan kode keluar ↓
• Unduh skrip dan contoh JSON-nya ↓
• Membangun ulang lingkungan proyek ↗

1. Identifikasi Python yang benar-benar dijalankan

Terminal, notebook, dan layanan dapat menggunakan interpreter yang berbeda. Tampilkan sys.executable di konteks yang menjalankan proyek, lalu periksa versinya. Jalur tersebut memungkinkan Anda menemukan lingkungan virtual yang terlupakan atau notebook yang masih menggunakan kernel lain. Periksa di mesin Anda; tidak perlu mempublikasikan struktur direktori pribadi Anda dalam laporan.

Selanjutnya gunakan interpreter yang sama untuk menanyakan paket. Perintah python -m pip show torch memberikan informasi PyTorch yang terkait dengan Python tersebut. Jika import torch gagal, langkah berikutnya adalah memperbaiki pemasangan ini: mengurangi batch atau mengubah bobot model tidak akan menyelesaikan modul yang tidak ada.

python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip show torch

• Python: identifikasi executable yang digunakan ↗
• PyTorch: pilih perintah pemasangan yang sesuai ↗

2. Bedakan CUDA, ROCm, dan paket tanpa akselerasi GPU

Catat secara terpisah torch.__version__, torch.version.cuda, dan torch.version.hip. Jangan simpulkan "paket CPU" hanya dari nilai None pada torch.version.cuda: PyTorch untuk ROCm menggunakan HIP, memakai kembali torch.cuda, dan juga mengharapkan perangkat bernama cuda. Mengganti nama tersebut dengan rocm atau hip bukanlah perbaikan yang harus dilakukan.

Selanjutnya, periksa torch.cuda.is_available() dan torch.cuda.device_count(). Hasil ini menjelaskan apa yang dapat digunakan oleh lingkungan Python ini pada saat itu. Hasil ini tidak menggantikan perhitungan minimal. Sebuah alat sistem mungkin dapat melihat sebuah kartu, sedangkan paket, driver yang dapat diakses oleh proses, atau lingkungannya mencegah PyTorch menggunakannya.

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.version.hip); print(torch.cuda.is_available()); print(torch.cuda.device_count())"

• PyTorch: ROCm menggunakan kembali antarmuka torch.cuda ↗
• Instalasi dan pemeriksaan awal PyTorch ↗

3. Membuat laporan dengan skrip Kernodeck

Setelah mengunduh file, letakkan di folder kerja dan jalankan dengan Python milik proyek. Secara default, skrip ini memerlukan GPU. Mode CPU harus diminta secara eksplisit: keberhasilannya memverifikasi cabang CPU dari diagnostik dan tidak pernah mengubah GPU yang tidak tersedia menjadi GPU yang tervalidasi. Laporan ditulis ke terminal dan, dengan --output, ke file JSON baru. File yang sudah ada tidak pernah ditimpa: pilih nama lain untuk percobaan berikutnya.

Skrip ini mengalokasikan dua matriks 2 × 2 dalam float32, memverifikasi hasil perkaliannya lalu sebuah gradien dan menyinkronkan perangkat GPU. Loss yang diharapkan bernilai 196 untuk perhitungan tetap ini. Pemeriksaan yang sangat singkat ini tidak memuat bobot model apa pun dan tidak mengukur throughput apa pun. Pemeriksaan ini meminta perhitungan nyata yang kecil dari backend, di luar sekadar deteksi perangkat.

Pemeriksaan sistem opsional menggunakan nvidia-smi bila tersedia. Pemeriksaan ini hanya melaporkan versi driver NVIDIA dan total memori yang terlihat oleh alat tersebut; pemeriksaan ini bukan pemeriksaan sistem yang setara untuk ROCm. Batas waktu perhitungan adalah 30 detik secara default dan dapat berkisar dari 5 hingga 120 detik. Pemeriksaan sistem memiliki batas waktu maksimalnya sendiri sebesar 3 detik.

python kernodeck-diagnostic-v1.py --device-index 0 --timeout 30 --output diagnostic-gpu.json

python kernodeck-diagnostic-v1.py --device cpu --output diagnostic-cpu.json

python kernodeck-diagnostic-v1.py --host-check --output diagnostic-gpu-systeme.json

• Unduh skrip Python ↓
• NVIDIA: cakupan dan opsi nvidia-smi ↗

4. Membaca laporan dan memilih tindakan selanjutnya

Mulailah dengan status, code, exit_code, dan stage. Blok runtime mengidentifikasi versi Python dan keluarga sistem. Blok pytorch membedakan paket yang diimpor, versi kompilasi CUDA/HIP-nya, backend yang dideklarasikan, dan perangkat yang terlihat. Blok execution menunjukkan di mana perhitungan sebenarnya berlangsung dan apakah hasil perkalian serta gradien telah diverifikasi.

Dalam mode CPU, gpu_available dan visible_device_count tetap bernilai null: skrip tidak menanyakan status driver GPU. Ini bukan nol maupun kerusakan. Bacalah juga execution.device: paket yang dikompilasi untuk CUDA bisa saja menjalankan pemeriksaan ini di CPU ketika diminta secara eksplisit.

Laporan berisi pilihan data teknis. Laporan ini tidak menyertakan variabel lingkungan, path mesin, ID sesi, daftar lengkap paket, atau jejak mentah suatu pengecualian. Skrip tidak mengirimkan laporan apa pun ke Kernodeck. Untuk kesalahan terperinci dari aplikasi Anda, simpan jejaknya di ruang kerja Anda dan hapus rahasia sebelum membagikannya.

• Laporan nyata pemeriksaan CUDA ↓
• Laporan nyata pemeriksaan CPU ↓
• Laporan nyata saat PyTorch tidak ada ↓

5. Beralih dari perhitungan kecil ke aplikasi Anda

Sebelum peluncuran, siapkan perintah yang dapat direproduksi, model yang teridentifikasi, kumpulan data kecil, dan direktori keluaran yang dapat diakses. Pilih masukan yang mempertahankan karakteristik penting dari pekerjaan akhir: panjang teks, dimensi gambar, format audio, atau bidang wajib. Masukan yang sengaja dibuat pendek dapat menyembunyikan masalah yang ingin Anda amati.

Tuliskan kriteria keberhasilan yang konkret. Untuk perhitungan embeddings, setiap pengenal masukan harus menghasilkan vektor dengan dimensi yang diharapkan, dengan nilai yang finit. Untuk pelatihan, satu langkah harus menghasilkan loss yang dapat digunakan, memperbarui parameter yang diharapkan, dan memungkinkan penyimpanan. Kode keluar proses melengkapi pemeriksaan ini; kode itu tidak menggantikannya.

Tambahkan penanda sebelum dan sesudah pembacaan parameter, impor pustaka, pemuatan bobot, persiapan data, transfernya, perhitungan, dan penulisan. Beri setiap percobaan sebuah pengenal dan simpan parameter terkait. Pesan "model dimuat" harus sesuai dengan peristiwa yang telah selesai, bukan sekadar niat untuk memuat.

Catat bentuk, tipe, dan perangkat tensor yang berguna tanpa menyalin seluruh kumpulan data. Ringkasan seperti "masukan: 8 sekuens, panjang maksimum 512, perangkat cuda:0" membantu membandingkan dua percobaan. Angka-angka ini di sini menggambarkan contoh log, bukan konfigurasi universal. Hindari menempatkan token akses atau konten masukan yang sensitif dalam pesan-pesan ini.

6. Perbaiki kesalahan pada lapisan yang tepat

Jika perhitungan kecil berhasil tetapi bobot tidak ditemukan, periksa jalurnya, formatnya, dan hak aksesnya. Jika sebuah ekstensi gagal diimpor, verifikasi kompatibilitasnya dengan paket PyTorch dan backend proyek. Diagnosis yang berhasil tidak menjamin semua ekstensi aplikasi. Mulailah kembali dari langkah pertama yang gagal, bukan mengubah beberapa dependensi sekaligus.

Kesalahan perangkat dapat berasal dari masukan yang tetap berada di CPU padahal model ada di GPU. Kesalahan tipe dapat berasal dari konversi sebagian atau operator yang tidak kompatibel dengan presisi yang dipilih. Simpan pesan lengkap pertama dan trace-nya. Ubah satu hipotesis pada satu waktu, lalu jalankan ulang masukan minimal sebelum memasukkan kembali volume akhir.

7. Jika model mulai berjalan lalu melampaui memori

Kenali apakah pelampauan terjadi saat pemuatan bobot, pada perhitungan pertama, atau setelah beberapa iterasi. Momen-momen ini mengarah pada penyebab yang berbeda: model terlalu besar, aktivasi atau cache generasi yang besar, penumpukan tensor yang disimpan. Catat torch.cuda.memory_allocated() dan torch.cuda.memory_reserved() pada langkah yang sama. Yang pertama melacak alokasi tensor; yang kedua mencakup memori yang dikelola oleh allocator.

torch.cuda.empty_cache() dapat mengembalikan cache yang tidak terpakai, tetapi tidak menghapus tensor yang masih direferensikan. Karena itu periksa daftar keluaran, riwayat loss, dan objek yang menyimpan graf komputasi. Kemudian kurangi batch atau panjang masukan untuk mengisolasi faktor penentunya. Mengganti kartu menjadi keputusan yang terinformasi ketika Anda mengetahui fase yang melampaui dan margin yang benar-benar dibutuhkan.

• PyTorch: memori yang dialokasikan untuk tensor ↗
• PyTorch: memori yang dikelola oleh allocator ↗
• PyTorch: apa yang dibebaskan oleh empty_cache ↗
• Menghubungkan memori, konteks, dan batch inferensi ↗

8. Ukur perhitungan tanpa melupakan asinkronisme

Operasi GPU dapat bersifat asinkron terhadap program Python. Pengukur waktu yang ditempatkan di sekitar sebuah panggilan karena itu bisa jadi terutama mengukur pengiriman pekerjaan. Untuk pengukuran diagnostik, sinkronkan GPU pada batas segmen yang diamati, atau gunakan event yang sesuai. Sinkronisasi ini mengubah jalannya proses: jaga instrumentasi ini terpisah dari operasi normal aplikasi Anda.

Bangun contoh sederhana dengan tiga segmen: persiapan input, komputasi, penulisan output. Untuk segmen GPU, panggil torch.cuda.synchronize(), catat time.perf_counter(), jalankan komputasi, sinkronkan lagi, lalu hitung selisihnya. Simpan terpisah proses pertama dan proses berikutnya. Pemuatan atau inisialisasi tidak boleh hilang dalam rata-rata yang disajikan sebagai waktu respons penuh.

• PyTorch: sinkronisasi dan pengukuran komputasi GPU ↗

9. Memeriksa output dan menyimpan diagnostik yang dapat digunakan kembali

Untuk inferensi klasik, model.eval() mengatur perilaku modul terkait, sedangkan torch.inference_mode() menonaktifkan pelacakan yang diperlukan untuk gradien. Kedua pengaturan ini memiliki fungsi yang berbeda. Gunakan yang kedua ketika tensor yang dihasilkan tidak boleh ikut serta dalam komputasi dengan gradien. Evaluasi model selama pelatihan mengharuskan Anda secara eksplisit mengembalikan mode yang benar sebelum melanjutkan.

Sekarang bandingkan output dengan kontrak yang telah disiapkan: jumlah hasil, kesesuaian identitas, dimensi, nilai finite, dan metrik bisnis yang sesuai. Jika Anda menambah batch, periksa kembali kesesuaian ini. Jika Anda menambah GPU, periksa distribusi input dan pengumpulan output. Lot sewa mengacu pada kartu yang dipesan; batch mengacu pada contoh yang diproses bersama oleh program Anda.

Hasil dari metode ini adalah folder kecil: perintah, versi, parameter, input minimal, langkah terakhir yang berhasil, kesalahan pertama, observasi memori, dan output yang diperoleh. Jika peluncuran berhasil, simpan folder ini sebagai titik pembanding sebelum menambah beban. Jika peluncuran gagal, folder ini memungkinkan Anda mereproduksi masalah tanpa mengulang seluruh penyelidikan.

Sebelum pemrosesan panjang, lakukan juga penghentian yang bersih dan pemulihan pada kumpulan input kecil ini. Pastikan output yang sudah ditulis tidak hilang atau dihitung dua kali. Setelah semua pemeriksaan ini lolos, tingkatkan secara bertahap satu sumbu saja — batch, panjang, konkurensi, atau jumlah proses — dan catat batas yang teramati. Anda mendapatkan rentang operasi yang terukur untuk aplikasi Anda, bukan asumsi yang terkait dengan nama GPU.

• PyTorch: perbedaan antara inference_mode dan eval ↗
• Memeriksa pemulihan dalam proses baru ↗

Bukti yang disediakan dan batasannya

Contoh yang dapat diunduh berasal dari pemeriksaan nyata yang dilakukan pada 24 September 2026. Kedua eksekusi dengan PyTorch menggunakan Windows, Python 3.14.6, dan PyTorch 2.11.0+cu128. Pemeriksaan GPU menggunakan CUDA, pada NVIDIA GeForce RTX 5070; pemeriksaan CPU secara eksplisit meminta CPU. Perangkat keras pemeriksaan ini tidak disajikan sebagai penawaran Kernodeck. Tidak ada komputasi ROCm yang dijalankan untuk bukti ini.

Komputasi kecil yang berhasil menunjukkan bahwa jalur alokasi dan komputasi berfungsi pada perangkat yang dipilih. Ini tidak mengukur kecepatan model Anda, memori yang diperlukan untuk input terbesarnya, maupun kompatibilitasnya dengan ekstensi tertentu. Laporan ini juga tidak mensertifikasi topologi multi-kartu. Lanjutkan ke uji yang representatif sebelum memutuskan untuk menambah beban atau sewa.

Untuk aplikasi CUDA, bandingkan spesifikasi NVIDIA dengan kebutuhan memori dan pustaka Anda; untuk rantai ROCm, periksa ketentuan MI300X. Spesifikasi yang ditautkan adalah opsi yang harus dikualifikasi untuk proyek Anda, bukan daftar perangkat keras yang digunakan dalam bukti. Pertahankan waktu pemeriksaan awal dan ekspor dalam periode 3, 7, atau 30 hari Anda.

• Membaca protokol dan batasan diagnostik ↓
• Memeriksa RTX 4090 untuk proyek CUDA ↗
• Memeriksa MI300X untuk rantai ROCm ↗
• Mengonfigurasi sewa setelah kualifikasi proyek ↗