CapordiaMenyusun berkas awal yang ringkas namun dapat direkonstruksi
Simpan versi sistem, aplikasi, dan dependensinya, prosedur peluncuran, serta kumpulan data kecil yang representatif. Tambahkan jalur yang diharapkan, izin, dan cara memeriksa keluaran. Manifes ini menjelaskan acuan yang diketahui. Untuk suatu perubahan, buat versi kandidat di samping acuan tersebut; rahasia tetap berada di perangkat pengelolaan akses Anda. Sebutkan elemen yang hilang beserta penanggung jawabnya alih-alih menutupinya dengan keterangan "lingkungan siap".
Tunjuk satu orang untuk penerimaan dan satu orang lain untuk keputusan peralihan bila organisasi Anda memerlukannya. Mereka harus mengetahui kriterianya sebelum pemrosesan baru menjadi dependensi bagi seluruh tim. Preferensi Ubuntu, PyTorch, Blender, atau kustom yang dipilih saat pemesanan akan mengarahkan penyiapan; hal itu tidak menggantikan inventarisasi aplikasi Anda yang terperinci.
Memeriksa sumber daya yang benar-benar terlihat
Saat sumber daya diserahkan, bandingkan model yang terdeteksi, jumlah kartu, dan memori mereka dengan cakupan yang diharapkan. Catat juga elemen yang diperlukan untuk proyek yang tidak dijelaskan oleh GPU saja: sistem, ruang kerja, izin, dan akses ke tujuan. Setiap selisih menjadi pertanyaan tepat yang harus ditangani, tanpa mengasumsikan adanya kapasitas CPU, jaringan, atau disk yang tidak tercantum dalam lembar spesifikasi.
Pada lingkungan NVIDIA yang memiliki nvidia-smi, perintah yang diusulkan membaca nama, memori total yang dilaporkan oleh alat tersebut, dan driver. Perintah ini tidak menilai performa maupun semua dependensi CUDA. Untuk AMD, gunakan dokumentasi yang sesuai dengan perangkat keras dan kombinasi ROCm yang dipilih; hindari menerapkan pemeriksaan NVIDIA sebagai bukti bahwa MI300X berfungsi.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csvLakukan uji coba menyeluruh dengan kriteria terpisah
Periksa secara berurutan akses, konfigurasi, pemuatan data, eksekusi, dan ekspor. Untuk setiap tahap, catat satu observasi dan satu keputusan. Program yang selesai tanpa kesalahan belum tentu menghasilkan semua berkas yang diharapkan. Sebaliknya, tampilan kartu yang benar tidak membuktikan bahwa perangkat lunak menggunakan GPU yang dipilih.
Tetapkan hasil yang dapat diterima sebelum pengujian. Hasil tersebut bisa berupa jumlah folder yang tepat, gambar yang diperiksa secara visual, atau kriteria numerik. PyTorch mengingatkan bahwa reproduktibilitas penuh tidak dijamin antar versi dan platform. Karena itu, pilih toleransi yang sesuai dengan pekerjaan bersama penanggung jawabnya; jangan memperlebarnya setelahnya hanya agar pengujian lolos.
| Tahap | Observasi yang diharapkan | Keputusan jika gagal |
|---|---|---|
| Akses | Orang yang berwenang mencapai lingkungan yang benar | Perbaiki akses sebelum impor |
| Pemuatan | Semua masukan dari set uji dapat dibaca | Perbaiki paket atau izinnya |
| Eksekusi | Pemrosesan menggunakan sumber daya yang direncanakan dan selesai | Identifikasi dependensi atau pengaturannya |
| Hasil | Konten memenuhi kriteria yang tertulis | Hentikan perluasan kampanye |
| Ekspor | Hasil dapat digunakan dari tujuannya | Perbaiki keluaran sebelum beralih |
Contoh nyata: seratus folder diterima, sembilan puluh sembilan hasil
Dalam kasus fiktif ini, sebuah tim mengganti versi A dari prapemrosesan dengan versi B. Manifesnya mencantumkan kode, dependensi, dan format keluaran sebelum dan sesudah; set penerimaan tetap terdiri dari 100 folder yang sama, ditandai 001 hingga 100. Versi A menghasilkan 100 hasil. Versi B selesai tetapi mengekspor 99 pengenal yang berbeda: folder 057 hilang. Kriteria tertulis menuntut 100 hasil tanpa duplikat. Karena itu, perubahan ditolak pada tahap ini.
Sebuah dependensi yang diperlukan untuk folder 057 tidak ada dalam paket kandidat. Tim mengembalikannya dalam versi baru manifes, memeriksa folder tersebut, lalu menjalankan ulang 100 masukan pada kandidat yang diperbaiki. Mereka kembali mendapatkan 100 pengenal yang berbeda dan membuka paket dari tujuan akhir. Uji coba lengkap memverifikasi bahwa perbaikan tidak hanya memperbaiki kasus terisolasi. Hasil ini menyelesaikan selisih yang dijelaskan; namun belum membuktikan berfungsinya pada volume yang lebih besar maupun beban berkelanjutan.
Bandingkan manifes sebelum dan sesudah, lalu putuskan adopsinya
Catatan perubahan cukup beberapa baris: alasan, elemen yang diubah, elemen yang dipertahankan, kriteria, dan penanggung jawab. Simpan salinan konfigurasi acuan yang dapat digunakan. Jika Anda mengubah driver, framework, dan format data sekaligus, Anda memperbanyak kemungkinan penyebab selisih. Pisahkan bila memungkinkan; jika tidak, perlakukan kumpulan ini secara eksplisit sebagai perubahan yang lebih luas.
Setelah perbaikan, mintalah pemilik hasil memvalidasi acuan baru. Tabel di bawah ini mengatur keputusan tersebut; tabel ini bukan daftar perangkat lunak yang disediakan. Versi yang dipilih baru menjadi acuan setelah kontrol yang disepakati. Beri tanggal adopsi dan sebutkan tugas yang menjadi cakupannya, agar dua orang tidak diam-diam menjalankan dua varian dari kampanye yang sama.
| Elemen | Sebelum | Kandidat yang dipilih setelah perbaikan |
|---|---|---|
| Aplikasi | Versi A | Versi B, termasuk perbaikan dependensi |
| Entri penerimaan | 100 berkas tetap | 100 berkas yang sama |
| Hasil yang disyaratkan | 100 pengenal berbeda | 100 pengenal berbeda, format diterima |
| Publikasi | Referensi yang digunakan tim | Adopsi bertanggal setelah persetujuan penanggung jawab |
Pertahankan kemungkinan rollback tanpa mencampur hasil
Sebelum adopsi, pastikan referensi sebelumnya masih dapat membaca entri-entrinya dan melanjutkan statusnya. Pisahkan keluaran kandidat, hindari publikasi ganda, dan tentukan siapa yang berwenang memutuskan rollback. Jika perangkat lunak baru mengubah berkas kerja secara ireversibel, menyimpan program lama saja tidak cukup: diperlukan juga status data yang kompatibel. Panduan migrasi membahas peralihan antar lingkungan; di sini, keputusan menyangkut perubahan perangkat lunak yang terkualifikasi.
Konfirmasi pembayaran dan penyediaan akses tetap terpisah dari pemeriksaan teknis ini. Tombol “Saya sudah membayar” menandai sebuah pembayaran; tombol itu tidak memvalidasi akses maupun perubahan perangkat lunak. Lakukan pengujian ketika lingkungan benar-benar dapat diakses, lalu kaitkan hasilnya dengan referensi pesanan Anda dalam berkas internal.
Selesaikan dengan tim yang mampu mengoperasikan dan keluar
Keluaran yang diharapkan adalah berkas singkat: lingkungan yang tercatat, set penerimaan, pemeriksaan yang diterima, selisih yang tersisa, dan orang yang memutuskan langkah selanjutnya. Mintalah seseorang yang tidak menyiapkan instalasi untuk meninjau ulang prosedur peluncuran. Jika orang tersebut harus menanyakan jalur atau pengaturan penting, lengkapi berkas sebelum menyerahkan operasional kepadanya.
Rencanakan juga pengambilan akhir dan pengendaliannya. Kesalahan yang sering terjadi adalah memperbesar beban sebelum penerimaan, mengganti beberapa versi selama diagnosis, dan baru menyadari soal ekspor saat tenggat tiba. Dalam 3, 7, atau 30 hari, sediakan waktu untuk langkah-langkah ini dalam periode yang dipilih, tanpa menganggapnya sebagai operasi yang selalu instan.
Pertanyaan untuk memutuskan
Apakah satu kartu yang terdeteksi cukup untuk menerima penerapan?
Tidak. Deteksi hanya memverifikasi sebagian cakupan perangkat keras. Masih ada langkah memuat entri, menjalankan perangkat lunak, memeriksa hasilnya, dan mengambilnya dari tujuan. Setiap pemeriksaan harus memiliki kriteria yang berbeda.
Apakah keluaran harus benar-benar identik setelah pergantian GPU?
Itu bergantung pada pemrosesan Anda. Tentukan apa yang harus tetap benar-benar identik dan apa yang termasuk toleransi yang beralasan. Dokumentasikan versi dan parameternya; kesamaan sempurna tidak boleh diasumsikan untuk semua perangkat lunak dan semua lingkungan.
Siapa yang memutuskan bahwa suatu selisih dapat diterima?
Penanggung jawab yang ditunjuk untuk kriteria terkait, bersama pengambil keputusan peralihan jika selisih tersebut memengaruhi layanan. Orang yang menjalankan uji coba mendeskripsikan pengamatan; ia tidak otomatis menggantikan penanggung jawab bisnis atau penanggung jawab data.