GPU untuk proyek Anda · pembayaran kripto tanpa KYC Cara menyewa
Bahasa Indonesia
Buka konsol
Panduan praktis / KERNODECK

Error CUDA muncul: operasi mana yang harus diperiksa?

Simpan kegagalan pertama, identifikasi batch yang bersangkutan, dan perkecil aplikasi hingga ke operasi yang memicunya. Pada CUDA, eksekusi asinkron dapat memunculkan error lebih lambat daripada penyebabnya. Selanjutnya periksa indeks, bentuk, tipe, dan perangkat sebelum mengubah lingkungan. Metode ini berlaku untuk aplikasi yang sudah diluncurkan; ia tidak menggantikan pemeriksaan awal ketersediaan GPU.

6 menit baca · Panduan untuk developer

Simpan kegagalan pertama dan konteksnya

Panduan ini dimulai setelah peluncuran yang berhasil: PyTorch melihat perangkat, lalu aplikasi Anda gagal pada sebuah batch atau operator. Jika tidak ada komputasi kecil yang berhasil, mulailah lagi dari diagnosis awal. Jika tidak, simpan error pertama, nomor iterasi, dan langkah terakhir yang selesai. Rangkaian pesan setelah kegagalan pertama bisa jadi menggambarkan konsekuensinya, bukan beberapa penyebab yang independen.

Catat revisi kode, versi Python dan PyTorch, backend, tipe numerik, dan bentuk input. Untuk data, utamakan pengenal internal dan dimensi daripada salinan utuh seluruh konten. Cari apa yang membedakan batch yang bermasalah: panjang, target yang tidak ada, lot terakhir yang tidak lengkap, augmentasi, atau cabang yang jarang digunakan. Berkas ini memungkinkan Anda mengulang kasus tanpa menjalankan ulang seluruh kampanye.

Melacak peluncuran yang bermasalah meskipun asinkron

Pada CUDA, operasi diantrekan dan dapat selesai setelah fungsi Python kembali. Error yang muncul saat penyalinan ke CPU atau pembacaan skalar bisa jadi berasal dari komputasi sebelumnya. Dokumentasi PyTorch menjelaskan eksekusi asinkron ini. Baris yang ditunjukkan oleh trace adalah titik pengamatan yang perlu diperiksa, bukan selalu penyebabnya.

Untuk reproduksi singkat pada NVIDIA/CUDA, jalankan peluncuran terpisah dengan CUDA_LAUNCH_BLOCKING=1. Opsi ini membuat panggilan menjadi sinkron dan dapat mendekatkan error ke sumbernya. Ini untuk diagnostik, bukan untuk pengukuran waktu. Anda juga dapat menempatkan sinkronisasi sementara di antara tahap-tahap besar untuk mempersempit interval yang dicurigai. Setelah itu hapus instrumentasi ini: ia mengubah penjadwalan biasanya.

Perintah berikut bersifat edukatif dan belum dijalankan. Ia mengasumsikan terminal POSIX dan skrip train.py yang sudah ada. Penetapan ini hanya berlaku untuk peluncuran tersebut; sesuaikan sintaksis dengan shell Anda. Jangan menggeneralisasi variabel NVIDIA ini ke tumpukan ROCm.

Peluncuran diagnostik yang diusulkan, belum dijalankan
CUDA_LAUNCH_BLOCKING=1 python train.py

Membaca sekelompok error tanpa menyimpulkan terlalu cepat

Pesan error mempersempit ruang pencarian; ia tidak menggantikan kasus yang dapat direproduksi. Indeks di luar rentang, tensor pada perangkat yang salah, dan alokasi yang tidak mungkin memerlukan pemeriksaan yang berbeda. Pertahankan perbedaan antara data tidak valid, kontrak operator, dan lingkungan biner. Mengubah batch, presisi, dan pustaka secara bersamaan menghapus perbedaan tersebut.

Setelah assertion dijalankan pada perangkat, jangan mencoba melanjutkan pelatihan yang sama di proses yang sama. NVIDIA menyatakan bahwa cudaErrorAssert membatalkan alokasi yang ada dan mengharuskan Anda mengakhiri lalu memulai ulang proses. Di notebook, ini berarti Anda harus memulai ulang kernel sebelum reproduksi yang diperbaiki. Namun memulai ulang tidak memperbaiki target yang salah maupun indeks yang tidak valid.

Geser tabel untuk membaca semua kolom.
Petunjuk diagnostik, tanpa keterkaitan otomatis antara pesan dan penyebab
Petunjuk yang diamatiPemeriksaan pertamaKesimpulan yang harus dihindari
device-side assertIndeks, target, dan kondisi operatorGPU pasti rusak
Out of memoryBentuk, masa hidup tensor, memori prosesSetiap error CUDA adalah kekurangan VRAM
Operator atau kernel tidak tersediaVersi, ekstensi, backend, dan dtypeMemasang ulang semuanya secara asal
Perangkat yang berbedaPenempatan model dan setiap inputMenambahkan salinan tanpa memahami asalnya

Contoh yang dikerjakan: kelas 4 pada masalah empat kelas

Ambil contoh sebuah pengklasifikasi edukatif yang keluarannya memiliki empat kolom. Kelasnya diindeks dari 0 hingga 3. Berkas anotasi yang berisi nilai 4 dapat mengungkapkan pengodean dari 1 hingga 4 atau kelas kelima yang tidak terduga. Sekadar memperbesar ukuran keluaran akan menghilangkan sebuah kendala tanpa menyelesaikan makna anotasinya.

Pemeriksaan yang diusulkan di bawah ini diterapkan sebelum transfer target ke CPU. Ia belum dijalankan. Ia menggambarkan kontrak CrossEntropyLoss untuk indeks kelas bertipe long, dengan ignore_index=-100 yang dipilih secara eksplisit. Ia tidak mencakup target yang berupa distribusi probabilitas. Dalam skenario ini, [0, 2, 4] harus ditolak; hasil yang diharapkan ini disimpulkan dari aturannya, bukan disajikan sebagai pengukuran.

Selanjutnya perbaiki pemetaan dalam persiapan data dan periksa bijeksinya dengan nama kelas. Jangan kurangi 1 di mana-mana selama Anda belum tahu apakah semua sumber menggunakan konvensi yang sama. Tambahkan kasus yang bermasalah ke himpunan verifikasi kecil yang disimpan bersama proyek.

Garda CPU edukatif untuk indeks kelas
import torch

classes = 4
ignore_index = -100
target = torch.tensor([0, 2, 4], dtype=torch.long)
if target.ndim != 1 or target.dtype != torch.long:
    raise ValueError("Target: vektor indeks diharapkan")
valid = target[target != ignore_index]
if valid.numel() == 0:
    raise ValueError("Tidak ada target yang dapat digunakan dalam batch ini")
if bool(((valid < 0) | (valid >= classes)).any()):
    raise ValueError("Indeks kelas di luar rentang")

Menyederhanakan program tanpa menghapus pemicu

Jalankan ulang terlebih dahulu satu entri atau satu batch dengan transformasi yang sama. Hapus pelacakan jarak jauh, penulisan hasil, dan cabang yang tidak berkaitan dengan kegagalan. Pertahankan dtype, bentuk, dan operator yang dicurigai. Jika kesalahan bergantung pada panjang atau tata letak memori tertentu, tensor acak berukuran kecil berisiko tidak lagi mereproduksinya.

Bandingkan satu perubahan pada satu waktu: ekstensi opsional dinonaktifkan, operator referensi, presisi biasa, atau operasi yang sama di CPU jika tersedia di sana. Keberhasilan di CPU hanyalah petunjuk, bukan validasi CUDA. Untuk fungsi kustom, catat juga asumsi tentang strides, kontiguitas, dan ukuran. Cari contoh yang gagal sebelum perbaikan dan berhasil setelahnya, dengan verifikasi keluaran alih-alih sekadar tidak adanya pengecualian.

Memverifikasi perbaikan pada cakupan awal

Perbaikan yang dapat diterima harus lulus kasus minimal, kasus-kasus di sekitarnya, dan sebagian representatif dari alur asli. Uji kembali khususnya batch terakhir, entri pendek, entri panjang, dan nilai batas pemetaan. Pastikan elemen yang ditolak dapat diidentifikasi dan jumlah entri yang diproses tetap sesuai harapan. Mengabaikan pengecualian secara diam-diam dapat mengubah crash yang terlihat menjadi hasil yang tidak lengkap.

Hapus mode diagnostik, mulai dari proses baru, dan konfirmasi perilaku dengan konfigurasi normal. Simpan penyebab, perubahan yang diterapkan, dan pengujian non-regresi. Jika Anda sempat menghentikan pelatihan, mulai dari checkpoint koheren yang telah divalidasi sebelum kesalahan; keberadaan file yang tertulis selama gangguan tidak cukup untuk menjamin pemulihannya.

Mengetahui kapan meminta analisis yang lebih terarah

Jika kasus minimal yang sama gagal dengan entri yang valid, siapkan permintaan yang tepat: operasi, bentuk, tipe, backend, versi, dan pesan pertama yang relevan. Hapus pengenal pribadi dan jalur yang tidak perlu. Ekstensi biner mungkin memerlukan matriks kompatibilitasnya sendiri; dukungan umum PyTorch tidak otomatis memvalidasi ekstensi tersebut.

Pada ROCm, PyTorch mempertahankan antarmuka torch.cuda dan nama perangkat cuda. Periksa torch.version.hip untuk mengidentifikasi tumpukan ini sebelum menerapkan prosedur NVIDIA. Pesan, alat, dan opsi diagnostik dapat berbeda. Tidak ada pengujian yang dijelaskan di sini yang membuktikan kompatibilitas lingkungan yang disiapkan dengan penawaran Kernodeck; gunakan kriteria ini untuk memperjelas kebutuhan Anda sebelum memilih GPU.

Pertanyaan Anda

Apakah CUDA_LAUNCH_BLOCKING=1 memperbaiki kesalahan CUDA?

Tidak. Opsi ini membuat panggilan CUDA sinkron untuk membantu melokalisasi operasi yang bermasalah. Gunakan pada reproduksi singkat, lalu perbaiki penyebabnya dan hapus sebelum mengukur performa normal.

Bisakah saya melanjutkan notebook setelah device-side assert?

Mulai ulang kernel sebelum menjalankan ulang kasus yang telah diperbaiki. Assert di sisi perangkat dapat membuat konteks tidak dapat digunakan dan alokasi menjadi tidak valid. Menjalankan ulang memulihkan konteks, tetapi tidak memperbaiki indeks atau data yang salah.

Jika perhitungan yang sama berhasil di CPU, apakah GPU-nya rusak?

Tidak. Hasil ini membedakan dua jalur eksekusi. Dtype, ekstensi, kernel, atau batasan data dapat menjelaskan perbedaannya. Reproduksi operasi minimal pada tumpukan GPU yang bersangkutan sebelum menyimpulkan.

Apakah prosedur NVIDIA sama pada ROCm?

Tidak sepenuhnya. PyTorch untuk ROCm juga menggunakan torch.cuda, tetapi alat dan beberapa variabel diagnostiknya berbeda. Identifikasi HIP dengan torch.version.hip dan konsultasikan dokumentasi yang sesuai dengan backend sebenarnya.