CapordiaTetapkan batas antara yang bermigrasi dan yang harus menunggu
Panduan ini ditujukan bagi orang yang mengoordinasikan komputasi, data, dan operasi. Batch di sini berarti paket pekerjaan yang teridentifikasi, berbeda dari batch kartu GPU dalam katalog. Metode ini terutama cocok untuk keluaran yang dapat diperiksa sebelum diterima. Untuk layanan yang menerima permintaan tanpa henti, tentukan di mana entri baru akan menunggu, berapa lama penantian itu dapat diterima, dan bagaimana entri tersebut akan bergabung ke target. Berkas yang disalin tidak dengan sendirinya menetapkan kebijakan penerimaan ini.
Latihan yang disarankan bekerja pada himpunan tertutup berisi delapan batch sintetis. Latihan ini tidak mengirim permintaan jaringan apa pun dan tidak mengakses GPU maupun akun Capordia. Latihan ini mengajarkan logika pemulihan pada satu workstation dan satu proses kerja. Latihan ini tidak memvalidasi antrean terdistribusi, kelangsungan layanan yang terpapar, atau pemindahan komputasi secara langsung. Sebelum migrasi nyata, tim Anda harus memenuhi unsur-unsur tersebut dengan aplikasi dan perangkat keras yang dipilih.
Susun inventaris yang memungkinkan rekonstruksi
Kumpulkan kode beserta versinya, dependensi, parameter, model, masukan, tugas terjadwal, dan tujuan keluaran. Untuk masing-masing, cantumkan pemilik, metode rekonstruksi, dan pemeriksaan yang diharapkan pada target. Catat nama rahasia dan cara penyediaannya, tanpa menempatkan nilainya dalam register bersama. Pemasangan manual atau tugas yang dipicu saat startup dapat terlewat dalam sekadar salinan direktori proyek.
Pisahkan berkas masukan, hasil yang diterima, dan status yang diperlukan untuk memulai ulang. Untuk pelatihan, status ini dapat melebihi bobot model: tutorial PyTorch tentang menyimpan checkpoint secara umum mencakup antara lain status optimizer dan kemajuan. Isi yang diperlukan bergantung pada kode Anda. Pulihkan dalam proses baru, lalu bandingkan keluaran sesuai toleransi yang ditetapkan sebelum uji; jangan simpulkan identitas numerik universal dari satu keberhasilan restart.
Menetapkan keputusan, transfer, dan penerimaan
Tetapkan peran sebelum menetapkan jendela waktu. Satu orang yang sama dapat memegang beberapa peran dalam tim kecil, tetapi keputusannya tetap terpisah. Penanggung jawab peralihan mengonfirmasi penghentian produsen lama dan mengizinkan dimulainya target. Penanggung jawab data mengendalikan inventaris, sidik jari, dan keluaran. Pemilik pemrosesan menilai kualitas fungsional. Operasional menyimpan catatan perubahan dan menyiapkan serah terima.
Lembar peralihan harus menjawab empat pertanyaan konkret: siapa yang dapat menghentikan masukan, siapa yang memastikan pemrosesan lama tidak lagi menerbitkan hasil, siapa yang menerima hasil pertama, dan siapa yang memutuskan pemulihan. Cantumkan juga batas waktu pengambilan keputusan dan cara menghubungi orang-orang tersebut. “Kembali jika perlu” tidak cukup ketika target sudah menghasilkan keluaran yang tidak dikenal oleh register lama.
Menjaga register yang membedakan dimulai dan diterima
Berikan pengenal yang stabil untuk setiap lot dan kaitkan dengan versi data yang tepat. Simpan statusnya, jumlah percobaan, lokasi hasil, dan kontrol yang mengizinkan penerimaannya. Lot yang sedang berjalan tidak dianggap selesai hanya karena file keluaran sudah ada: file tersebut bisa parsial atau berasal dari percobaan sebelumnya. Prosedur harus menjelaskan apa yang akan disimpan, apa yang akan dihitung ulang, dan apa yang akan dikarantina untuk ditinjau.
Dalam latihan ini, register SQLite lokal menyimpan status dan penerimaan hasil dalam satu transaksi. Statusnya adalah termine, en_cours, dan a_reprendre; yang terakhir juga mencakup lot yang belum dimulai. Target melanjutkan lot yang belum divalidasi alih-alih menjalankan ulang delapan masukan secara sembarangan. Ekspor JSON dan CSV membuat pelacakan mudah dibaca. CSV kosong mendampingi persiapan dan tinjauan manusia Anda; itu tidak menggantikan mekanisme koordinasi aplikasi nyata.
| Lot | Status di batas | Keputusan sebelum dimulai kembali |
|---|---|---|
| LOT-001 hingga LOT-003 | termine | Simpan hasil dan verifikasi integritasnya |
| LOT-004 | en_cours, hasil belum diterima | Siapkan percobaan baru secara eksplisit |
| LOT-005 hingga LOT-008 | a_reprendre, tidak ada percobaan | Jalankan pada target setelah otorisasi |
Unduh dan jalankan latihan pemutusan dan pemulihan
Siapkan Python 3.10 atau lebih baru dengan modul sqlite3, dan direktori lokal yang dapat ditulis. Unduh arsip lengkap dan ekstrak dengan menyimpan skrip, folder data, dan manifes tetap bersama. File README merinci perintah yang tersedia. Tidak ada driver, paket komputasi, atau model yang perlu dipasang. Baca skrip sebelum menjalankannya, lalu gunakan folder keluaran baru agar bukti dari beberapa percobaan tidak tercampur.
Dari direktori yang berisi exercice.py, perintah di bawah ini menghasilkan referensi berkelanjutan, pemrosesan yang terputus, salinan peralihan, dan pemulihan yang dibandingkan dengan referensi. Delapan file CSV berisi 48 pengukuran dimensi fiktif dari kupon, dinyatakan dalam mikrometer bulat dan dibuat untuk berkas ini. Tidak ada kontrol industri nyata yang diwakili. Perhitungan pada CPU digunakan untuk memeriksa pengelolaan lot, bukan untuk memperkirakan throughput GPU atau durasi migrasi data Anda.
python exercice.py demonstration --dossier essai-capordiaBaca bukti pemulihan, lot demi lot
Contoh Capordia: sebuah tim menyiapkan delapan paket file untuk diproses. Referensi memprosesnya tanpa pemutusan. Pada alur lainnya, penghentian menyisakan tiga lot selesai, LOT-004 sedang berjalan, dan empat lot untuk dilanjutkan tanpa percobaan. Penanggung jawab peralihan tidak meminta “lanjutkan dari tengah”: ia menunjuk LOT-004. Persiapan pemulihan mengembalikannya ke status a_reprendre: tiga lot lalu selesai dan lima harus dijalankan. Lot yang sudah diterima tidak boleh dihitung ulang.
Lihat etat.json untuk pengenal, status, dan percobaan, registre-lots.csv untuk tinjauan, resultats.json untuk keluaran, lalu rapport-verification.json untuk pemeriksaan. Saat eksekusi lokal pada 24 September 2026 di Windows AMD64, Python 3.14.6 dan SQLite 3.50.4, 16 pemeriksaan dari 37 peluncuran skrip berhasil: delapan hasil yang diambil sesuai dengan referensi, lot yang selesai tidak dihitung ulang, dan penerimaan baru untuk lot yang sama ditolak. Entri yang diubah, pengenal duplikat, dan keluaran yang rusak juga terdeteksi.
Menyalin status yang konsisten, lalu memeriksa integritasnya
Dalam peralihan yang sesungguhnya, hentikan penerimaan atau tempatkan entri baru dalam antrean yang memang disediakan. Tunggu pekerjaan yang sedang berjalan selesai, atau catat lot yang terhenti sesuai aturan pemulihan Anda. Setelah itu pastikan instans lama tidak dapat lagi memublikasikan. Penyegelan sumber dalam latihan ini mencegah skrip menggunakannya kembali sebagai produsen. Ini tetap merupakan perlindungan lokal untuk skenario tersebut, bukan pengecualian mutual antara beberapa mesin yang masing-masing memiliki salinan status.
Untuk menyalin basis data SQLite yang digunakan oleh aplikasi, dokumentasinya menawarkan API pencadangan yang menghasilkan snapshot yang konsisten. Jadi, penyalinan biasa atas berkas basis data yang sedang ditulis bukanlah prosedur yang bisa dilakukan secara improvisasi. Periksa juga manifes berkas yang ditransfer. Sidik jari SHA-256, yang tersedia di hashlib, membantu mendeteksi perbedaan konten; sidik jari itu tidak menyatakan apakah hasilnya benar untuk proses bisnis Anda, maupun apakah manifes referensi dapat dipercaya.
Memutuskan kapan melanjutkan dan kapan kembali
Izinkan target hanya ketika entri, register, dan hasil yang disimpan sudah sesuai, produsen lama telah dihentikan, dan prasyarat perangkat lunak terpenuhi. Mulailah dengan cakupan yang keluarannya dapat ditinjau ulang. Pemilik pemrosesan menerima kualitasnya; penanggung jawab data memeriksa pengenal, data yang hilang, dan duplikat. Mulai tanpa kesalahan saja tidak cukup jika hasil yang berguna tidak lengkap.
Jika cacat muncul sebelum ada publikasi baru, biarkan target tetap berhenti dan mulai lagi dari status sumber yang terkendali sesuai prosedur yang ditetapkan. Setelah publikasi, lindungi dulu hasil dan register target. Bandingkan lot yang telah diselesaikannya dengan lot sumber, lalu pilih satu pemulihan yang diizinkan. Mengaktifkan kedua sisi sekaligus untuk menghemat waktu justru dapat menciptakan duplikat yang seharusnya dicegah oleh migrasi.
| Observasi | Keputusan segera | Syarat untuk melanjutkan |
|---|---|---|
| Entri tidak ada atau sidik jari berbeda | Tangguhkan transfer dan isolasi salinan | Ambil entri yang sesuai dengan manifes referensi |
| Pengenal duplikat atau keluaran tak terduga | Jangan publikasikan lot terkait | Pahami konfliknya dan pilih satu versi yang diterima |
| Status pemulihan tidak dapat digunakan | Hentikan target dan simpan buktinya | Pulihkan status yang diketahui atau terapkan pemulihan yang telah disiapkan |
| Hasil di luar kriteria bisnis | Hentikan perluasan pemulihan | Perbaiki lalu ulangi validasi fungsional |
| Batas waktu pengambilan keputusan tercapai | Picu keputusan pemulihan atau penundaan | Persetujuan eksplisit dari penanggung jawab dan kemampuan menyelesaikan ekspor |
Ukur seluruh jendela waktu dan siapkan serah terima
Ulangi instalasi, penyalinan, verifikasi, pemulihan, dan ekspor dalam urutan yang sebenarnya. Catat waktu setiap fase dan intervensi manusia, dengan sampel yang transfernya diizinkan. Untuk memperkirakan jendela waktu Anda, pertimbangkan entri baru yang akan menunggu dan kemampuan menyerap keterlambatan tersebut. Waktu terbaik yang teramati pada folder kecil bukanlah komitmen untuk volume yang lebih besar.
Periode yang dipilih harus mencakup persiapan, pengulangan, peralihan, pemantauan, dan pengambilan hasil. Paket Capordia 3, 7, atau 30 hari tetap merupakan periode yang perlu diatur; panduan ini tidak menyimpulkan waktu komputasi apa pun darinya. Sebelum penutupan, orang kedua harus dapat menemukan register, membuka keluaran dari tujuannya, dan mengetahui cara menjalankan ulang pemrosesan. Arsipkan keputusan akhir pemulihan, selisih yang diterima, dan tindakan yang tersisa sebelum mencabut akses yang tidak lagi diperlukan.
Apa yang diverifikasi oleh latihan ini dan apa yang masih perlu didefinisikan
Kontribusi berkas ini adalah prosedur yang mudah dibaca dan pengalaman pemulihan yang dapat direproduksi pada berkas sintetis. Batch yang sama harus dapat diidentifikasi sebelum penghentian, selama peralihan, dan setelah pemulihan. Register, perbandingan dengan referensi, dan penolakan yang disengaja membuat aturan ini dapat diamati. Interupsi dipicu oleh pengecualian terkendali dalam skrip: tidak ada uji pemadaman listrik yang dilakukan. Dokumentasi teknis yang dikutip menjelaskan mekanisme yang digunakan; dokumentasi tersebut tidak menjamin lingkungan produksi Anda di masa mendatang.
Hanya satu proses yang bekerja pada satu waktu dalam skenario ini. Penyegelan lokal bukan kunci terdistribusi; sidik jari bukan uji kualitas; hasil CPU bukan kualifikasi CUDA, ROCm, atau multi-GPU. Aplikasi yang juga menulis ke basis data eksternal, penyimpanan bersama, atau antrean memerlukan aturan yang konsisten di semua tujuan tersebut. Mintalah aturan ini dan rencana pemulihan Anda divalidasi sebelum memigrasikan pemrosesan yang sebenarnya.
Untuk mempersiapkan kelanjutannya
Cadangan harus memungkinkan pekerjaan dilanjutkan.
Memulihkan ke target terisolasi dan memverifikasi bahwa salinan benar-benar memungkinkan pengambilan kembali.
Serah terima dengan status, tindakan dan penanggung jawab.
Meneruskan tindakan, batasan, dan tanggung jawab kepada orang lain.