Proses migrasi model

Artikel ini menjelaskan proses enam tahap untuk memigrasikan beban kerja berbasis LLM dari satu model dasar ke model dasar lain: apa yang perlu dipertimbangkan pada setiap tahap, fitur Microsoft Foundry mana yang berlaku, dan bagaimana pekerjaan tersebut berubah untuk berbagai jenis tim.

Apa yang dimaksud dengan migrasi model

Setiap model yang Anda jalankan di lingkungan produksi memiliki tanggal pensiun. Ketika model yang Anda andalkan diganti, atau ketika model yang lebih baru akan melayani beban kerja Anda dengan lebih baik, Anda bermigrasi. Menukar model bukanlah perubahan satu baris: model yang berbeda dapat mengalihkan nada, pemformatan, bentuk JSON, latensi, biaya, atau perilaku panggilan alat secara diam-diam, dan memecah kode hilir yang bergantung pada perilaku lama.

Migrasi yang berhasil mempertahankan perilaku aplikasi atau meningkatkannya dengan cara yang terukur. Keberhasilan membutuhkan proses berulang untuk mendeteksi penyimpangan, beradaptasi dengan aman, dan membuktikan kualitas sebelum peluncuran luas.

Kapan harus bermigrasi

Migrasi biasanya dimulai karena salah satu dari empat alasan:

  • Sebuah model akan dipensiunkan. Di Foundry, setiap model yang tersedia secara umum hadir dengan tanggal penghentian, dan keluarga model lama digantikan seiring waktu. Untuk kebijakan dan tanggal penghentian, lihat siklus hidup dan kebijakan dukungan Foundry Models dan jadwal penghentian model.
  • Model yang lebih baik tersedia. Model yang lebih baru menawarkan kualitas yang lebih tinggi, biaya yang lebih rendah, latensi yang lebih baik, atau kemampuan (seperti output terstruktur atau panggilan alat yang ditingkatkan) yang dibutuhkan beban kerja Anda.
  • Masalah biaya atau latensi memaksa perubahan. Latensi model atau biaya unit saat ini tidak lagi memenuhi kebutuhan Anda.
  • Suatu kesenjangan kapabilitas menghambat produk. Model saat ini tidak dapat melakukan sesuatu yang dibutuhkan produk Anda sekarang.

Apa yang terjadi pada tanggal pensiun

Apa yang Azure lakukan ketika model berhenti tergantung pada bagaimana Anda membeli kapasitas, dan Foundry menggunakan terminologi yang berbeda untuk setiap jalur:

  • Penyebaran Standar, Standar Global, dan Standar Zona Data (bayar sesuai penggunaan)ditingkatkan secara otomatis pada jadwal bergulir berdasarkan wilayah. Anda mengatur waktu dengan versionUpgradeOption disetel ke salah satu dari: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired, atau NoAutoUpgrade (yang berarti penerapan berhenti berfungsi saat masa pensiun). Pemrosesan Prioritas mengikuti jalur yang sama.
  • Penyebaran yang disediakan (PTU)tidak ditingkatkan secara otomatis. Anda memigrasikannya sendiri, baik secara in-place (trafik dialihkan dalam jangka waktu 20–30 menit tanpa henti layanan) maupun berdampingan (siapkan deployment baru, uji, alihkan trafik, hapus deployment lama).
  • Penyebaran batch mengikuti pendekatan berdampingan: terapkan model baru, kirim ulang job, lalu nonaktifkan deployment lama.

Tidak peduli jalur mana yang berlaku, tantangan pengembang sama: pada tanggal yang ditetapkan, lalu lintas Anda mulai mencapai model yang berbeda. Titik akhir yang masih merespons tidak berarti aplikasi Anda masih berperilaku dengan benar, sehingga beban kerja yang ditingkatkan secara otomatis dan dimigrasikan secara manual mendapat manfaat dari penilaian dan validasi yang dijelaskan artikel ini.

Migrasi sebelum tanggal penghentian

Peningkatan otomatis hanya merupakan jaring pengaman untuk penyebaran prabayar, bukan rencana migrasi. Penyebaran yang disediakan tidak memiliki jaring pengaman. Bagaimanapun, ini bukan pengganti rencana migrasi. Dua komitmen kebijakan memberi Anda ruang untuk bermigrasi pada jadwal Anda sendiri alih-alih menunggu tenggat waktu:

  • Model pengganti tersedia sekitar 90 hari sebelum pensiun di Standar Global, dan sekitar 30 hari sebelum pensiun di wilayah yang disediakan di mana pendahulunya pensiun. Gunakan jendela ini untuk mengevaluasi model baru dan bermigrasi secara manual.
  • Tanggal penghentian tidak dapat diperpanjang. Tidak ada proses pengecualian, jadi tanggal yang tidak Anda rencanakan masih berlaku untuk Anda.

Anda tidak perlu pemberitahuan deprekasi untuk memulai. Jika model yang lebih baru itu lebih murah, lebih cepat, atau lebih canggih, segera jalankan melalui proses tersebut. Migrasi sengaja mengubah tanggal pensiun menjadi formalitas. Karena migrasi terjadi berulang kali, sebaiknya buat prosesnya dapat diulang.

Siapa yang harus menggunakan proses migrasi

Proses migrasi paling cocok ketika tim Anda membangun fitur yang didukung LLM di dalam produk atau platform yang lebih besar, bermigrasi pada irama triwulanan yang kira-kira, dan memiliki pemilik yang jelas (seperti tim platform pusat atau tim aplikasi) yang menjalankan setiap migrasi dengan sengaja.

Proses ini juga cocok dengan tim asli AI, di mana modelnya adalah produk. Fasenya sama, tetapi berjalan lebih cepat dan sering secara paralel daripada dalam urutan yang ketat.

Proses ini mengasumsikan bahwa Anda berpindah antar model dasar, yakni model yang Anda deploy sebagaimana dipublikasikan dalam katalog model, tanpa kustomisasi pada level bobot. Beban kerja yang di-fine-tune tidak termasuk dalam cakupan. Mereka tidak dapat ditingkatkan secara otomatis, karena masing-masing memiliki masa penghentian pelatihan dan penerapannya sendiri. Menyesuaikan workload yang telah di-fine-tune berarti melakukan distilasi atau pelatihan ulang, bukan mengubah prompt dan skema. Jika Anda menjalankan deployment yang telah di-fine-tuning, rencanakan untuk melakukan fine-tuning ulang menggunakan model dasar pengganti sedini mungkin.

Fase migrasi

Migrasi bergerak melalui enam fase. Setiap fase menghasilkan output yang digunakan fase berikutnya. Fase migrasi adalah:

Temukan → Menilai → Adaptasi → Validasi → Meluncurkan → Pensiun

Diagram melingkar proses migrasi model enam fase yang menampilkan Penemuan, Penilaian, Adaptasi, Validasi, Penerapan, dan Penghentian, disusun searah jarum jam.

Tabel berikut ini menjelaskan setiap fase dan fitur dan alat Foundry yang mendukungnya. Fitur tersedia baik di Microsoft Foundry maupun Azure OpenAI kecuali jika ditandai Foundry only, yang berarti Azure OpenAI tidak memiliki padanannya.

Bagian per fase nanti dalam artikel ini menjelaskan mengapa setiap fase ada, seperti apa hasil yang berhasil, apa yang harus dipertimbangkan, kapan menggunakan setiap fitur, dan di mana fase umumnya berhenti.

Phase Description Fitur dan alat
Menemukan Pelajari bahwa perubahan model akan datang atau diperlukan, dan putuskan apakah akan bertindak.
Menilai Pilih model target dan konfirmasikan tersedia secara operasional.
Beradaptasi Jalankan kembali beban kerja saat ini pada model baru, diagnosis perubahan perilaku, dan rancang ulang prompt, parameter, definisi alat, skema output, serta kode pemanggil yang terkait.
Validasi Nilai beban kerja yang disesuaikan terhadap rubrik berkualitas untuk memutuskan apakah aman untuk dikirim.
Luncurkan Promosikan ke produksi melalui paparan bertahap, pantau perilaku langsung, dan terapkan atau gulung balik.
Retire Hentikan deployment lama, bebaskan kapasitas, arsipkan evaluasi, dan perbarui dokumentasi downstream.

Sebelum Anda bermigrasi: Siapkan himpunan data pengujian

Langkah persiapan ini menyusun serangkaian input perwakilan, output yang diharapkan, dan kriteria keberhasilan yang disepakati sebelum pekerjaan migrasi dimulai. Set ini merupakan prasyarat utama untuk bagian tengah proses: Anda tidak dapat menjalankan ulang dalam fase Adaptasi tanpa input, dan Anda tidak dapat melakukan penilaian dalam fase Validasi tanpa data acuan dan kriteria.

Apa yang harus dipertimbangkan

  • Buat himpunan data sebelum Anda memilih target. Himpunan data menjelaskan beban kerja Anda, bukan model kandidat, sehingga Anda dapat merakitnya secara paralel dengan Discover.
  • Kumpulkan input dari sumber nyata atau sintetis. Gunakan data traffic produksi yang direkam atau contoh domain yang dikurasi dalam format CSV atau JSONL. Ketika Anda belum memiliki data representatif, hasilkan input sintetis dan adversarial dengan Simulator.
  • Rekam instrumen sebelum Anda memerlukannya. Perekaman konten produksi bersifat opt-in dan tidak berlaku surut, sehingga Anda tidak dapat mengevaluasi lalu lintas yang tidak Anda rekam. Mulailah mencatat prompt, respons, latensi, dan jumlah token sekarang.
  • Bekukan himpunan data. Pertahankan input, nilai acuan, dan kriteria keberhasilan tetap sama selama seluruh proses migrasi. Jika salah satu dari mereka berubah, Anda tidak dapat lagi membandingkan hasil sumber dan target.

Anda juga memerlukan inventarisasi penyebaran model yang digunakan beban kerja Anda, termasuk jenis penyebarannya (Standar, Disediakan, atau Batch). Untuk setiap model sumber, perhatikan tanggal penghentiannya dan penggantian yang disarankan dari jadwal penghentian Model.

Fase 1: Temukan

Tujuan dari fase Temukan adalah untuk mengenali bahwa perubahan model akan datang atau bermanfaat dan untuk memutuskan apakah akan bertindak. Outputnya adalah keputusan go/no-go, dan tetap menggunakan model saat ini adalah pilihan yang valid. Hasil yang baik adalah indikasi awal yang terstruktur yang memberi Anda informasi tentang tanggal penghentian, model pengganti, dan jangka waktu migrasi, atau keputusan yang dipertimbangkan dengan matang untuk tetap menggunakan model saat ini.

Apa yang harus dipertimbangkan

  • Berapa tanggal pensiun, dan berapa banyak runway yang benar-benar Anda miliki? Anggap tanggal deprekasi yang dikurangi waktu validasi dan peluncuran Anda sebagai tenggat waktu yang sebenarnya.
  • Apakah ada penggantian bernama yang disarankan, atau apakah Anda perlu men-shortlist kandidat sendiri?
  • Apakah perubahan membawa kepatuhan atau batasan regional (untuk beban kerja, ketersediaan, dan sertifikasi yang diatur sering kali penting sebelum kualitas)?

Bagian yang biasanya mengalami kerusakan

Tim mengetahui adanya penghentian secara tidak konsisten, melalui email, banner di portal, atau pesan internal, dan mereka terlambat menyadari sinyal tersebut. Penundaan itu semakin mempersempit rentang waktu yang memang sudah sempit. Pengembang solo dan tim kecil sering kali baru mengetahui adanya penghentian saat terjadi error di lingkungan produksi, bukan melalui pengumuman resmi.

Apa yang Anda bawa

Jadwal pensiun dan API Models menyediakan data melalui kontrak yang stabil. Organisasi yang matang menambahkan lapisan notifikasi internal tambahan di atasnya untuk meneruskannya kepada penanggung jawab yang tepat.

Fase 2: Menilai

Tujuan fase Penilaian adalah memilih model kandidat yang akan menjadi target dan memastikan bahwa model tersebut dapat dijalankan: di wilayah yang tepat, dengan jenis penyebaran yang tepat, kuota yang memadai, serta ketersediaan berdampingan dengan model saat ini agar pengembalian ke versi sebelumnya tetap dimungkinkan. Hasil yang baik adalah pilihan yang jelas dari antara model kandidat, dengan wilayah, SKU, kuota, dan biaya telah dipastikan sebelum penyetelan dimulai.

Apa yang harus dipertimbangkan

  • Kualitas dan posisi antara kandidat. Ketika beberapa model sedang digunakan, tentukan model mana yang paling sesuai dengan beban kerja Anda berdasarkan kualitasnya, bukan sekadar model yang memperoleh nilai tertinggi pada tolok ukur publik.
  • Biaya pada lalu lintas Anda sendiri. Struktur harga bergeser antar generasi model. Token penalaran, input yang di-cache, dan overhead output terstruktur dapat membuat ekonomi unit berubah hingga 2x lipat atau lebih, jadi proyeksikan biaya bulanan berdasarkan trafik historis, bukan hanya harga katalog.
  • Ketersediaan operasional. Pastikan wilayah, SKU, dan kuota sudah sesuai, serta target dapat berjalan berdampingan dengan sumber sehingga Anda tetap memiliki jalur rollback.
  • Gerbang kepatuhan Untuk beban kerja yang diatur, sertifikasi dan ketersediaan regional dapat memfilter daftar kandidat sebelum kualitas memasuki percakapan.

Bagian yang biasanya mengalami kerusakan

Kebingungan dalam memilih muncul ketika beberapa opsi memiliki pemosisian yang tidak jelas. Tim baru menyadari di tengah perencanaan bahwa model yang dipilih tidak tersedia di wilayah atau SKU mereka. Atau proyeksi biaya mengungkapkan bahwa model baru secara signifikan lebih mahal dalam trafik nyata.

Apa yang Anda bawa

Benchmark dihitung menggunakan himpunan data publik, jadi anggap papan peringkat sebagai filter, bukan garis akhir, dan konfirmasikan kandidat terpilih dengan beban kerja Anda sendiri. Proyeksi biaya kurang lebih sama: tampilan per bulan didasarkan pada log token Anda sendiri, yang cukup mudah setelah Anda memiliki data trafik.

Fase 3: Adaptasi

Tujuan dari fase Adapt adalah untuk membuat beban kerja berfungsi dengan baik pada model baru. Jalankan kembali terlebih dahulu beban kerja yang ada tanpa perubahan (untuk mengisolasi perubahan perilaku yang didorong oleh model), identifikasi apa yang berubah, lalu lakukan rekayasa ulang secara iteratif. Hasil yang berhasil adalah perbandingan perilaku berdampingan dengan lalu lintas nyata atau representatif, dengan setiap perubahan dilacak.

Adapt lebih dari sekadar pengeditan prompt

Prompt adalah bagian yang paling terlihat, tetapi migrasi biasanya juga mencakup empat aspek lainnya:

  • Parameter.temperature, top_p, max_tokens, dan kontrol upaya penalaran tidak memiliki padanan satu banding satu antargenerasi, dan keluarga model yang lebih baru mungkin tidak mendukung beberapa parameter.
  • Definisi alat. Anda mungkin perlu menulis ulang atau mengencangkan nama argumen, deskripsi, dan bidang yang diperlukan yang memandu model lama dengan andal.
  • Skema keluaran. Model berbeda dalam hal mematuhi format output terstruktur. Anda mungkin perlu menambahkan batasan eksplisit ke skema yang dipenuhi model lama secara longgar, atau Anda mungkin akhirnya dapat memberlakukan skema.
  • Kode panggilan. Perbedaan permukaan API dan SDK (Penyelesaian Obrolan versus Respons, bentuk streaming, dan bidang permintaan baru atau yang diganti namanya). Anda mungkin juga perlu memperbarui penguraian hilir yang mengasumsikan bentuk respons lama.

Untuk beban kerja agentik dan alur kerja, pekerjaan skema dan pemanggilan alat sering kali lebih dominan daripada pekerjaan terkait prompt.

Apa yang harus dipertimbangkan

  • Putar ulang tanpa perubahan sebelum Anda menyesuaikannya. Jalankan konfigurasi Anda saat ini pada model target tanpa perubahan apa pun. Pendekatan ini membantu Anda memisahkan perilaku yang diubah model dari perubahan yang Anda perkenalkan, dan memberi Anda garis besar.
  • Perhatikan apa yang sebenarnya bergeser. Verbositas, kedalaman penalaran, kepatuhan terhadap keluaran terstruktur, bentuk pemanggilan alat, perilaku penolakan, dan variansi latensi umumnya berubah.
  • Putar ulang rekam jejak nyata untuk mendeteksi regresi pada pemanggilan alat. Bidang tambahan, argumen yang diganti namanya, dan mengubah permukaan urutan hanya dalam jejak nyata, bukan dalam tolok ukur giliran tunggal.
  • Lacak perubahan Anda. Rekayasa ulang prompt mudah dilakukan dan mudah hilang. Pertahankan asli dan catat apa yang berubah dan mengapa.

Fitur Pengecoran

Tiga fitur Foundry mendukung fase ini:

  • Prompt Optimizer adalah tombol Optimalkan yang berada tepat di bawah kolom instruksi sistem di playground Agen. Ini merestrukturisasi instruksi Anda menggunakan praktik terbaik rekayasa perintah, menunjukkan penalaran per paragraf untuk setiap perubahan, dan mendukung perulangan iterasi: tambahkan saran seperti "pertahankan skema JSON dengan tepat" dan optimalkan kembali. Hanya tersedia di Foundry, tidak Azure OpenAI.
  • Optimasi agen menyempurnakan instruksi, alat, dan pemilihan model secara bersamaan untuk beban kerja agen. Hanya tersedia di Foundry, tidak Azure OpenAI.
  • Simulator menghasilkan input sintetis dan input adversarial ketika Anda tidak memiliki data produksi untuk diputar ulang.

Bagian yang biasanya mengalami kerusakan

Untuk beban kerja tertanam yang berhadapan langsung dengan produk, fase ini biasanya memakan waktu paling lama karena siklus diagnosisnya dilakukan secara manual: tim menjalankan ulang prompt, membandingkan perbedaannya, dan jarang mencatat apa yang mereka ubah atau alasannya.

Apa yang Anda bawa

  • Mulailah dengan pengoptimal, lalu verifikasi. Mereka menerapkan praktik terbaik umum dalam satu kali proses, alih-alih menyesuaikannya dengan dataset Anda, dan mereka menyesuaikan teks instruksi, bukan definisi alat atau skema keluaran. Perlakukan output sebagai draf yang kuat: salin permintaan asli Anda terlebih dahulu (tidak ada riwayat versi), lalu evaluasi ulang terhadap himpunan data beku Anda sebelum Anda mempercayai perubahan.
  • Rencanakan pekerjaan manual tambahan untuk pemindahan lintas keluarga. Tidak ada proses "optimalkan untuk model target X", jadi perpindahan antarkeluarga model melibatkan penerjemahan prompt dan skema secara sengaja.
  • Rekam lalu lintas sebelum Anda membutuhkannya. Tayangan ulang hanya sebaik hasil rekaman yang Anda tangkap, dan perekaman konten bersifat opsional serta tidak pernah berlaku surut.

Fase 4: Validasi

Tujuan dari fase Validasi adalah untuk memutuskan apakah beban kerja yang disesuaikan aman untuk dikirim dengan menilainya terhadap rubrik berkualitas pada himpunan data yang dikumpulkan. Rubrik dapat berbasis aturan, berbasis referensi, LLM sebagai hakim, tinjauan manusia, atau kerangka kerja khusus domain. Hasil yang baik adalah menghasilkan rangkaian evaluasi yang tepercaya, yang dijalankan pada dataset yang sudah dibekukan, dan dipercayai oleh tim aplikasi maupun para peninjau.

Validate adalah satu fase, tetapi memiliki dua titik interaksi, jadi jangan menganggapnya sebagai satu kejadian di akhir alur:

  • Bersiaplah lebih awal. Bekukan himpunan data dan kriteria keberhasilan di Sebelum Anda bermigrasi, sebelum Anda Beradaptasi. Begitu hal-hal itu berubah, sumber dan sasaran Anda tidak lagi dapat dibandingkan.
  • Gate tertunda, dalam dua tahap. Pertama, jalankan model saat ini pada set yang dibekukan untuk menetapkan baseline sumber, angka yang harus Anda lampaui. Kemudian nilai target pada set yang sama dan putuskan.

Apa yang harus dipertimbangkan

  • Biarkan himpunan data dan kriteria tetap beku. Ini adalah satu-satunya disiplin terpenting dalam proses untuk menjaga hasil sebanding.
  • Ukur tiga dimensi yang menjadi dasar persetujuan akhir: kualitas (skor evaluator atau peninjau), latensi (waktu hingga token pertama dan throughput, yang diisolasi pada panggilan yang sedang Anda migrasikan), dan biaya (biaya token masukan dan keluaran per permintaan).
  • Cocokkan rubrik dengan beban kerja. Rubrik ringkasan klinis, pernyataan pengurutan panggilan alat untuk agen, atau sinyal umpan balik pengguna yang sudah ada sebelumnya mungkin lebih bermakna daripada skor generik.
  • Perlakukan gerbang sebagai sinyal untuk tim asli AI. Alih-alih sekadar lulus/gagal satu kali, evaluasi berjalan secara berkelanjutan, pada setiap commit, dan menyatu dengan Roll out.

Fitur Pengecoran

Dua fitur Foundry mendukung fase ini:

  • Azure AI Evaluation SDK mencakup lebih dari 30 evaluator bawaan, yang meliputi keterdasaran, relevansi, temu kembali, koherensi, kelancaran, metrik berbasis referensi (F1, BLEU, dan ROUGE), keamanan, evaluator agen, dan penilai Azure OpenAI. Ini juga mencakup LLM kustom sebagai hakim untuk rubrik khusus tugas.
  • Evaluasi portal menjalankan evaluator yang sama pada target model, agen, dataset, dan trace.

Jalankan kumpulan evaluator yang identik pada dataset yang dibekukan terhadap baik sumber maupun target agar angkanya dapat dibandingkan.

Dimensi Apa yang harus diukur Where
Quality Skor evaluator pada sumber vs. target SDK Evaluasi Azure AI, evaluasi portal
Keterlambatan Waktu hingga token pertama dan throughput Papan peringkat tolok ukur, metrik operasional
Cost Biaya token input dan output per permintaan Hasil evaluasi, harga model

Bagian yang biasanya mengalami kerusakan

Sebagian besar tim tidak memiliki suite evaluasi, dan tim yang memilikinya pun sering kali membangunnya sendiri. Untuk beban kerja teregulasi, peninjauan wajib oleh manusia atau manajemen mutu diterapkan di atasnya dan menjadi hambatan utama. Migrasi ini terhenti pada Validate, bukan Adapt.

Apa yang Anda bawa

Evaluator siap dijalankan, tetapi menyusun set pengujian yang relevan dengan domain dari lalu lintas produksi Anda sendiri merupakan pekerjaan langsung untuk beban kerja model (non-agen). Kebutuhan inilah alasan langkah persiapan sepadan dengan biayanya.

Fase 5: Peluncuran

Tujuan fase ini adalah untuk menerapkan konfigurasi yang telah divalidasi ke lingkungan produksi secara bertahap: mulai dari lingkungan nonproduksi, kemudian canary atau persentase berbobot, lalu cakupan yang lebih luas. Selama proses berlangsung, pantau latensi, kesalahan, dan, idealnya, kualitas secara langsung dibandingkan dengan tolok ukur pra-migrasi. Kemudian komit atau batalkan. Hasil yang baik adalah eksposur bertahap melalui trafik canary, berbobot, atau shadow, indikator kualitas secara langsung selain latensi dan error, serta jalur rollback yang tetap tersedia.

Apa yang harus dipertimbangkan

  • Kenali tipe deployment Anda. Jenis penyebaran Anda menentukan mekanisme: Penyebaran keluarga standar dapat ditingkatkan secara otomatis pada jadwal yang Anda kontrol. Penyebaran yang diprovisikan, batch, dan yang disetel halus dimigrasikan secara manual. Tabel berikut menunjukkan mekanika berdasarkan jenis.
  • Pertahankan koridor putar kembali. Pastikan deployment lama tetap dapat diakses sampai Anda benar-benar yakin. Keputusan untuk melakukan rollback yang dipaksakan oleh tenggat penghentian penggunaan alih-alih berdasarkan bukti merupakan tanda peringatan bahwa Anda memulainya terlalu terlambat.
  • Saat Anda tidak dapat menggunakan canary, gunakan mode shadow atau mirror. Alur yang diatur (PHI, transaksi keuangan) sering kali tidak dapat mengekspos model baru ke lalu lintas pelanggan nyata. Yang setara menjalankan model baru pada input produksi secara offline dan membandingkan output dengan model lama tanpa memengaruhi pengguna.
  • Waspadai regresi yang tidak terdeteksi dalam evaluasi offline. Latensi pengguna sebenarnya dan perilaku pada kasus tepi baru terlihat saat sistem menangani beban produksi.

Mekanika migrasi berdasarkan jenis penyebaran

Jenis penyebaran Pendekatan migrasi Quota
Standar, Standar Global, Standar Zona Data Pemutakhiran otomatis secara bertahap sesuai jadwal. Mengontrol waktu dengan versionUpgradeOption (OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired, atau NoAutoUpgrade). Pemrosesan Prioritas mengikuti jalur yang sama. Diteruskan secara otomatis
Disiapkan Manual: di lokasi yang sama (trafik dialihkan dalam rentang waktu 20–30 menit) atau secara berdampingan (deployment baru, alihkan trafik, hapus deployment lama). Pastikan terlebih dahulu kuota model tujuan
Batch Berdampingan: sebarkan model baru, kirim ulang pekerjaan, lalu hentikan penyebaran lama. Memastikan kuota model target
Disetel secara khusus (di luar cakupan artikel ini) Tidak ditingkatkan secara otomatis; jam penghentian pelatihan dan penyebaran terpisah. Setel ulang atau lakukan distilasi pada model dasar pengganti. Memastikan kuota model target

Setelah trafik dialihkan, siapkan evaluasi berkelanjutan untuk menilai persentase sampel dari trafik produksi di dasbor Foundry Observability, yang terhubung ke trace untuk analisis akar masalah, serta alert Azure Monitor saat kualitas menurun.

Bagian yang biasanya mengalami kerusakan

Penurunan kualitas yang luput dari evaluasi offline muncul saat beban produksi. Keputusan untuk melakukan rollback sering kali terpaksa diambil karena tenggat penghentian dukungan, bukan berdasarkan bukti, yang menandakan bahwa migrasi dimulai terlalu terlambat.

Apa yang Anda bawa

Perutean berbobot antara dua deployment diterapkan pada gateway atau lapisan aplikasi Anda sendiri, dan masa rollback sengaja dipilih untuk menjaga deployment lama tetap aktif selama periode tertentu (tim embedded biasanya menginginkan sekitar 30 hari). Keduanya layak dirancang sekali dan digunakan kembali dalam setiap migrasi.

Fase 6: Pensiun

Tujuan fase Retire adalah untuk menghentikan deployment lama, membebaskan kapasitas, mengarsipkan artefak evaluasi, dan mengomunikasikan perubahan tersebut ke dokumentasi untuk pelanggan, halaman pemasaran, runbook dukungan, dan log audit yang memerlukan retensi. Pada akhirnya, deployment lama sudah tidak ada, jumlah deployment cenderung menurun, dan pembelajaran yang didapat dibawa ke siklus berikutnya.

Apa yang harus dipertimbangkan

  • Perlakukan penghentian sebagai tata kelola, bukan hanya pembersihan. Untuk beban kerja yang diatur, kewajiban retensi dapat memerlukan penyimpanan artefak selama bertahun-tahun.
  • Pastikan sumber benar-benar sudah hilang. Verifikasi versi lama dihentikan, lalu hapus penyebaran sehingga berhenti mengkonsumsi kapasitas.
  • Terapkan pembelajaran ke tahap berikutnya. Masukkan kembali jejak produksi terbaru ke dalam dataset acuan Anda agar migrasi berikutnya dimulai dengan biaya lebih rendah.

Bagian yang biasanya mengalami kerusakan

Teams melewati penghentian, yang menyebabkan akumulasi penyebaran zombie. Tim yang tidak secara aktif pensiun membawa jauh lebih banyak penyebaran langsung daripada rekan-rekan mereka, dan sebagian besar dari jumlah itu adalah serpihan struktural dari migrasi sebelumnya. Sub-langkah yang terlewatkan umum adalah komunikasi: pemasaran dan dokumentasi produk masih merujuk ke model lama setelah pertukaran.

Apa yang Anda bawa

Dasbor observabilitas menunjukkan jumlah deployment yang cenderung menurun, tetapi menentukan deployment mana yang masih menanggung beban kerja merupakan keputusan berdasarkan penilaian tim Anda. Jadikan penonaktifan sebagai tugas yang dilacak secara eksplisit, bukan sekadar harapan.

Migrasi jarang biner

Migrasi nyata sering kali terbagi: sebagian beban kerja berjalan pada model baru, sementara jalur yang sensitif terhadap latensi atau berisiko lebih tinggi tetap berjalan pada model lama, terkadang selama berminggu-minggu. Rencanakan peluncuran parsial dan rollback parsial alih-alih melakukan alih sekaligus dari model lama ke model baru. Penghentian sering kali tertinggal beberapa minggu atau bulan dari peluncuran, dan deployment lama yang masih tertinggal itulah yang tampak sebagai sprawl.

Konten terkait

  • Terakhir diperbarui pada