1. Simpan pesan dan konteksnya sebelum menjalankan ulang
Berhenti menambahkan tugas ke antrean. Catat teks persis pesan kesalahan, berkas atau pertanyaan yang terkait, jumlah item yang diproses bersamaan, dan tahap yang sudah tercapai. Apakah model sedang dimuat, komputasi sedang berjalan, atau keluaran sedang ditulis? Simpan pengaturan dalam catatan dan hasil yang sudah selesai di foldernya masing-masing.
Layar yang membeku atau aplikasi yang tertutup tanpa penjelasan tidak cukup untuk mengidentifikasi penyebabnya. Temukan log-nya jika tersedia. Gangguan koneksi, input yang tidak valid, dan memori yang penuh dapat menghasilkan gejala yang mirip di antarmuka. Jika perangkat lunak tidak menjelaskan apa pun, tulis "penyebab tidak diketahui" dan siapkan uji minimal daripada mengarang diagnosis.
2. Pisahkan memori GPU, memori sistem, dan ruang disk
Memori GPU digunakan untuk elemen komputasi di kartu. RAM server dan penyimpanan memenuhi kebutuhan lain. Kapasitas yang ditampilkan pada halaman GPU BriefGPU tidak menggambarkan RAM atau disk yang benar-benar tersedia. Periksa sumber daya yang disebutkan dalam pesan dan informasi lingkungan Anda.
Dalam Python, MemoryError menunjukkan kegagalan alokasi memori; nama itu saja tidak berarti kekurangan VRAM. Kode ENOSPC berarti kurangnya ruang pada perangkat yang dituju. Petunjuk ini mengarahkan penelusuran, tetapi log aplikasi tetap diperlukan untuk menemukan operasinya.
| Pengamatan | Pemeriksaan pertama | Apa yang tidak bisa diselesaikan hanya dengan GPU yang lebih besar |
|---|---|---|
| Pesan CUDA out of memory selama komputasi | Memori kartu yang terpakai, tugas lain, dan ukuran batch | Ketidakcocokan perangkat lunak atau berkas yang rusak |
| MemoryError saat membaca berkas | Memori proses, jumlah data yang dimuat ke RAM | Memuat seluruh folder ke memori sistem |
| No space left on device saat ekspor | Ruang dan kemungkinan kuota folder keluaran atau folder sementara | Disk penuh atau batas penyimpanan |
| Aplikasi tertutup tanpa pesan yang bisa ditelusuri | Log, tahap yang tercapai, dan uji pada satu entri | Penyebab yang belum diketahui |
3. Kembali ke satu entri dan satu pekerjaan aktif saja
Periksa dulu proses yang Anda jalankan sendiri. Pratinjau, sesi lama, atau alat kedua bisa saja masih bekerja. Tutup dengan benar tugas yang sudah tidak diperlukan setelah menyimpan statusnya. Jangan menghentikan proses yang tidak Anda kenali dan jangan memulai ulang seluruh lingkungan hanya untuk menghemat beberapa menit diagnosis.
Jalankan ulang entri yang gagal, sendirian, tanpa menurunkan kualitasnya. Jika entri itu berhasil sendirian tetapi gagal dalam kelompok, jumlah item bersamaan menjadi petunjuk. Misalnya, kurangi kelompok dari empat menjadi dua, lalu menjadi satu jika perlu. Jumlah berkas di folder tetap sama; hanya jumlah yang diproses bersamaan yang berubah.
Beberapa alat menawarkan pemrosesan berurutan untuk membatasi lonjakan memori. Diffusers antara lain mendokumentasikan pemecahan dekode untuk sekelompok gambar. Kemungkinan ini bergantung pada pipeline yang digunakan: periksa opsinya sebelum mengaktifkan pengaturan yang ditemukan untuk model lain.
4. Kurangi beban tanpa kehilangan hasil yang diminta
Jika satu entri saja gagal, periksa dimensi atau panjangnya. Untuk gambar, mengubah ukuran dari 2.048 × 2.048 menjadi 1.024 × 1.024 membagi jumlah piksel menjadi empat. Ini tidak menjamin total memori terbagi empat: model dan elemen lain tetap punya kebutuhan sendiri. Pengurangan hanya dapat diterima jika keluarannya tetap mempertahankan detail yang diperlukan.
Untuk asisten, bedakan antara dokumen yang diberikan, pertanyaan, dan jawaban yang dihasilkan. Cache generasi dapat mengonsumsi lebih banyak memori dengan konteks yang panjang; mekanisme persisnya bergantung pada model. Cobalah permintaan yang lebih pendek atau satu permintaan saja pada satu waktu. Jangan menghapus bagian yang berisi jawaban lalu menyimpulkan bahwa masalahnya sudah teratasi.
Selalu simpan input asli. Beri nama pada varian uji coba dan tuliskan apa yang diubahnya. Jika alat tersebut menawarkan pemecahan menjadi ubin atau pemindahan sebagian elemen ke RAM, periksa dokumentasinya dan kontrol sambungan, kualitas, serta waktu yang teramati. Opsi yang hemat VRAM dapat memindahkan kendala ke tempat lain.
5. Jangan samakan memori yang dicadangkan dengan memori yang terpakai
Dengan PyTorch, memori yang dicadangkan oleh allocator dan memori yang ditempati tensor adalah dua ukuran yang berbeda. Mengosongkan cache yang tidak terpakai tidak melepaskan tensor yang masih aktif. Jadi, perintah pembersihan tidak mengubah beban yang terlalu besar menjadi beban yang kompatibel.
Jika memulai ulang aplikasi Anda dengan bersih membantu, jalankan kembali kasus kecil yang sama dan catat hasilnya. Keberhasilan setelah restart saja tidak membuktikan adanya kebocoran memori yang telah diperbaiki. Jika penggunaan meningkat pada setiap proses yang identik, simpan pengamatan ini dan konsultasikan dokumentasi atau dukungan perangkat lunak sebelum menumpuk restart.
Contoh: mengisolasi masalah dalam folder berisi dua belas gambar
Berikut adalah skenario ilustratif, tanpa pengukuran perangkat keras. Seorang freelancer menyiapkan dua belas gambar, dua di antaranya berukuran besar dan berisi teks halus. Pemrosesan per kelompok berisi empat gagal. Ia menyimpan pesan errornya, lalu mencoba salah satu gambar besar itu sendirian, pada kualitas awal. Tabel menunjukkan cara menafsirkan kemungkinan pengamatan.
Dalam skenario ini, ia baru memilih kelompok berisi dua setelah memeriksa kedua gambar besar itu bersamaan dan beberapa gambar biasa. Ia memeriksa teks dan kontur pada file yang diekspor. Ia tidak menggeneralisasi hasil ini untuk semua ukuran gambar, semua model, maupun perangkat lunak lain.
| Uji skenario | Pengamatan hipotetis | Keputusan lokal |
|---|---|---|
| Empat gambar secara bersamaan | Gagal karena memori | Simpan kesalahannya dan kurangi ukuran kelompok |
| Satu gambar besar, pengaturan sama | Hasil lengkap dan dapat diterima | Kualitas target dapat berhasil pada kasus terisolasi ini |
| Dua gambar besar bersamaan | Hasil lengkap dan dapat diterima | Uji kelompok ini pada rentang yang singkat |
| Gambar diperkecil secara signifikan | Perhitungan selesai, teks tidak terbaca | Singkirkan pengurangan ini meskipun secara teknis berhasil |
Kapan kapasitas lain menjadi langkah yang beralasan
Bandingkan dengan kartu lain ketika kekurangan memori GPU telah teridentifikasi, kasus yang sangat penting gagal sendirian, dan pengurangan yang sesuai dengan kualitas Anda tidak cukup. Simpan perangkat lunak, versi, parameter, dan input terkait: berkas ini membuat uji coba berikutnya dapat dibandingkan. Ini tidak memungkinkan untuk menyimpulkan secara persis berapa GB tambahan yang akan cukup.
Kesalahan saat memuat model juga dapat mengurangi manfaat memperkecil kelompok: sebagian besar beban sudah ada sebelum input pertama. Opsi presisi atau kuantisasi mengubah kondisi eksekusi dan terkadang hasilnya; keduanya memerlukan uji coba terpisah. Menambahkan batch tidak secara otomatis menyatukan memori dari beberapa kartu.
Akhiri dengan diagnosis yang dapat digunakan
Catatan akhir Anda terdiri dari lima elemen: pesan dan tahap, sumber daya yang dicurigai, input yang disimpan, pengaturan yang berhasil atau gagal, kontrol kualitas yang dilakukan. Tambahkan apa yang masih belum diketahui. Jika tidak ada kasus kecil yang berhasil, hentikan pengulangan batch penuh dan mintalah bantuan dengan informasi ini.
Jangan hapus satu-satunya salinan asli Anda untuk mengosongkan disk, jangan turunkan beberapa parameter sekaligus, dan jangan anggap hasil parsial sebagai keberhasilan. Sisihkan waktu untuk mencadangkan hasil yang valid. Diagnosis harus mengurangi ketidakpastian; ia tidak perlu berubah menjadi sesi pengaturan yang tak berkesudahan.