CapordiaJelaskan masalah dengan hasil dan jendela waktu
Gantilah « GPU tidak bekerja » dengan pengamatan yang dapat diverifikasi: hasil pertama datang terlambat, tahapan menunjukkan jeda, atau jumlah keluaran yang diterima menurun. Berikan kumpulan masukan, versi aplikasi, pengaturan, dan periode yang diamati. Peluncuran pertama dapat mencakup fase yang berbeda dari eksekusi yang sudah disiapkan; jangan mencampurnya tanpa menjelaskannya.
Pecah alurnya menjadi pembukaan berkas, persiapan CPU, transfer, komputasi GPU, penulisan, lalu validasi. Fase-fase ini dapat tumpang tindih: gambaran tersebut merupakan hipotesis yang harus diuji terhadap jejak. Catat batasnya dengan zona waktu yang sama dan presisi yang memadai. Grafik perangkat keras yang diambil setelah jeda tidak dapat menjelaskan jeda tersebut, meskipun nilainya tampak tidak biasa.
Membaca persentase dan memori dengan benar
Dalam NVIDIA SMI, pemanfaatan GPU menunjukkan bagian dari interval pengambilan sampel selama setidaknya satu kernel berjalan. Ini bukan nilai kinerja semua komponen. Pemanfaatan memori menggambarkan aktivitas baca atau tulisnya; ini tidak boleh disamakan dengan jumlah memori yang terpakai. Dokumentasi juga menjelaskan bahwa beberapa bidang mungkin tidak tersedia tergantung lingkungan.
Karena itu, simpan nama metrik yang tepat beserta satuannya. Jumlah memori yang tinggi dapat berarti data yang disimpan menunggu; aktivitas rendah dapat muncul selama fase persiapan yang normal. Sebaliknya, aktivitas tinggi tidak membuktikan bahwa program melakukan pekerjaan yang berguna. Kita harus melihat keluaran dan kemajuan aplikasi bersamaan dengan perangkat keras.
Kumpulkan rekaman yang terkorelasi dan cukup singkat
Pilih urutan yang representatif dan batasi pengumpulan pada urutan tersebut. Catat jam, pengenal GPU, aktivitas, memori yang terpakai, dan fase aplikasi. Secara paralel, gunakan alat yang tersedia di sistem Anda untuk mengamati proses CPU, penantiannya, pembacaan dan penulisannya. Rata-rata di seluruh inti dapat menyembunyikan satu utas yang jenuh; perhatikan juga proses terkait.
Perintah pembacaan di bawah ini disarankan untuk target NVIDIA yang diizinkan yang sudah memiliki NVIDIA SMI. Perintah ini tidak dijalankan untuk panduan ini. Perintah ini mempertahankan satuan dalam CSV dan menampilkan satu pengamatan per detik hingga dihentikan. Periksa bidang yang didukung oleh versi Anda dan hentikan pengumpulan di akhir skenario. Bidang N/A tetap tidak diketahui: jangan mengubahnya menjadi nol.
Log minimum menghubungkan pengenal pekerjaan, jam dengan zona waktu, fase saat ini, entri atau batch yang dapat diidentifikasi, kemajuan, dan kesalahan yang mungkin terjadi. Log tidak boleh berisi rahasia maupun konten bisnis yang tidak perlu untuk diagnosis. Jika telemetri tidak ada, periksa terlebih dahulu perangkat pengumpulannya dan kemajuan aplikasi: kurva kosong tidak membuktikan proses berhenti. Tandai periode tanpa pengamatan alih-alih merekonstruksinya dari ingatan.
nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1Membedakan antara petunjuk dan kesimpulan
Jika aktivitas GPU menurun saat aplikasi menunggu inputnya, periksa jalur berkas. Jika menurun selama persiapan CPU yang lama, periksa fase tersebut dan paralelisme sebenarnya. Jika perangkat menunggu peserta lain dari pekerjaan terdistribusi, periksa keseimbangan beban dan komunikasi. Beberapa gejala dapat terjadi bersamaan; korelasinya belum merupakan bukti kausalitas.
Tuliskan hipotesis singkat dan satu perubahan yang dapat membedakannya. Misalnya, membandingkan input yang sama yang sudah disiapkan dengan persiapan biasanya dapat mengisolasi satu tahap, asalkan hasilnya tetap identik. Jangan mengubah secara bersamaan ukuran batch, presisi, jumlah proses, dan lokasi berkas: peningkatan akan sulit dikaitkan.
| Pengamatan terkorelasi | Hipotesis yang mungkin | Pemeriksaan berikutnya |
|---|---|---|
| GPU menunggu dan pembacaan input lama | Pasokan data terbatas | Bandingkan subset yang sudah disiapkan dengan input biasanya |
| Satu utas CPU sibuk selama jeda | Persiapan atau peluncuran dibatasi oleh utas ini | Profil fase ini, tanpa mengubah GPU terlebih dahulu |
| Satu peserta menunggu peserta lain | Ketidakseimbangan atau komunikasi | Bandingkan fase per proses |
| Aktivitas tinggi, sedikit keluaran yang diterima | Pekerjaan mahal, pengulangan, atau hasil ditolak | Hubungkan setiap periode dengan kemajuan dan kesalahan |
Contoh fiktif: menganalisis perulangan seratus detik
Tim fiktif « Revue des maquettes » menggambarkan perulangan tanpa tumpang tindih: enam puluh detik persiapan CPU, dua puluh detik komputasi GPU, lalu dua puluh detik ekspor. Totalnya 100 detik dan fraksi waktu yang dialokasikan untuk komputasi GPU bernilai 20/100, yaitu 20%. Perhitungan pedagogis ini tidak memprediksi persentase alat pengambilan sampel dan tidak sesuai dengan pengukuran GPU mana pun di katalog.
Misalkan persiapan dapat dipangkas menjadi tiga puluh detik, tanpa mengubah komputasi maupun keluaran. Perulangan kemudian menjadi 30 + 20 + 20 = 70 detik: tiga puluh detik lebih singkat, dengan fraksi GPU 20/70, yaitu sekitar 28,6%. Sebaliknya, secara hipotetis membagi dua hanya komputasi GPU akan menghasilkan 60 + 10 + 20 = 90 detik. Skenario ini menjelaskan mengapa menangani penantian terpanjang dapat lebih berpengaruh daripada mengganti kartu.
| Skenario | Persiapan CPU | Komputasi GPU | Ekspor | Total |
|---|---|---|---|---|
| Hipotesis awal | 60 dtk | 20 dtk | 20 dtk | 100 dtk |
| Persiapan yang secara hipotetis dipangkas | 30 dtk | 20 dtk | 20 dtk | 70 dtk |
| Hanya komputasi GPU yang secara hipotetis dibagi dua | 60 dtk | 10 dtk | 20 dtk | 90 dtk |
Memperdalam suatu fase dengan profiler
Jika observasi umum menemukan zona lambat tanpa menjelaskannya, gunakan profiler yang sesuai dengan aplikasi pada jendela singkat. PyTorch Profiler dapat mengumpulkan peristiwa CPU dan CUDA serta mengatur jendela pengumpulan. Dokumentasi menunjukkan adanya biaya tambahan saat perekaman bentuk atau tumpukan diaktifkan. Trace terperinci karenanya merupakan instrumen diagnostik; total waktunya tidak boleh disajikan tanpa catatan sebagai waktu normal program.
Jaga nama fase cukup jelas untuk menghubungkan operasi teknis dengan pekerjaan Anda: persiapan sekelompok file, transfer, tahap aplikatif, atau publikasi keluaran. Mulailah dengan tingkat detail yang diperlukan untuk hipotesis. Setelah perubahan, lakukan lagi observasi yang sebanding lalu eksekusi tanpa instrumentasi berat. Kontrol kedua ini memungkinkan verifikasi bahwa manfaatnya juga ada dalam kondisi biasa.
Menghindari koreksi yang menyembunyikan masalah
Meningkatkan konkurensi dapat memenuhi GPU sekaligus membebani disk, memori host, atau keluaran. Memperbesar ukuran batch dapat mengubah latensi dan memori yang dibutuhkan. Mengurangi presisi dapat mengubah hasil. Keputusan ini tidak dilarang, tetapi harus dievaluasi pada tujuan bisnis yang sama, beserta efek sampingnya, alih-alih dipertahankan hanya karena persentase yang ditampilkan meningkat.
Jangan mengatur ulang perangkat atau mengubah parameter perangkat kerasnya untuk mendiagnosis penurunan aktivitas sederhana. Mulailah dengan pembacaan, lalu mintalah penanggung jawab berwenang memeriksa kesalahan eksplisit. Hindari juga memublikasikan trace mentah yang berisi jalur privat, parameter rahasia, atau data masukan. Siapkan kutipan yang berguna untuk diagnostik dan simpan bukti lengkapnya dalam lingkup tim yang diizinkan.
Menutup diagnostik dengan bukti yang berguna untuk keputusan
Berkas akhir harus mencantumkan gejala, hipotesis yang dipilih, perubahan yang dicoba, kondisinya, dan hasil yang diamati. Simpan setidaknya satu perbandingan sebelum/sesudah pada kumpulan masukan yang sama, kualitas yang sama, dan definisi selesai yang sama. Jika hasilnya tidak konklusif, tuliskan apa yang telah dieliminasi dan observasi berikutnya yang diperlukan. Jalur yang ditolak dan didokumentasikan mencegah orang lain mengulanginya secara acak.
Aktivitas rendah yang normal tidak selalu memerlukan koreksi. Jika tugas memenuhi tenggat, kualitas, dan anggarannya, mengurangi suatu kompleksitas bisa lebih baik daripada optimasi yang rapuh. Jika konfigurasi baru dipertimbangkan, sampaikan kendala yang terbukti ke berkas penerimaan. Tidak ada catatan tunggal yang mengklasifikasikan katalog dan tidak ada nilai dari contoh ini yang merupakan performa yang dijanjikan.
Pertanyaan untuk memutuskan
Apakah penggunaan 100% membuktikan bahwa semuanya sudah optimal?
Tidak. Persentase menggambarkan aktivitas menurut definisi alat; ia tidak mengukur kualitas hasil maupun efisiensi menyeluruh program. Pantau juga waktu hingga keluaran yang diterima, kesalahan, waktu tunggu, dan sumber daya bersama.
Haruskah saya memilih GPU yang lebih kuat ketika aktivitasnya rendah?
Tidak sebelum Anda mengidentifikasi fase yang membatasi. Penantian data atau persiapan CPU yang lama bisa tetap sama dengan kartu lain. Bangun hipotesis, bandingkan perubahan yang tertarget, dan periksa keseluruhan alur.
Apa yang harus dilakukan jika suatu metrik bernilai N/A?
Simpan sebagai tidak tersedia dan periksa apa yang didukung alat di lingkungan Anda. Tidak adanya nilai bukan berarti tidak ada aktivitas. Lengkapi dengan peristiwa aplikatif atau alat lain yang diizinkan, dengan menyebutkan cakupannya.