Mimari ve çalışma modeli
Üretim AI paketi yalnız model dosyası değildir. Model digest'i, tokenizer, istem şablonu, retrieval/embedding sürümü, veri snapshot'ı, araç şemaları, runtime imajı, değerlendirme kanıtı ve politika kararı tek manifestte bağlanır. Registry bu bağıntıyı ve aşama geçişini kaydeder.
Mutable 'latest' etiketi yerine değişmez artifact kimlikleri dağıtılır; alias yalnız kontrollü işaretçidir. Eğitim veya istem deneyi pipeline run kimliğiyle tekrarlanabilir olmalı, kaynak veri erişimi ve lisansı kaydedilmelidir. Onay, artifact üretmekten ayrı bir görev ve kimlikle yapılır.
Rollback eski container'ı başlatmakla bitmez. Eski modelin beklediği embedding boyutu, prompt değişkenleri, veri şeması ve araç sözleşmesi korunmalıdır. Geriye uyumsuz indeks veya özellik dönüşümü blue/green veri düzlemi gerektirebilir. Canary, shadow ve aşamalı trafik yolları manifest seviyesinde izlenir.
- 1Artifact üretimi ve digest
- 2Registry, lineage ve onay
- 3Canary dağıtım ve gözlem
- 4Alias değişimi veya rollback
Tasarım parametreleri
- Sürüm manifesti
- Model, prompt, data, index, image, policy ve eval digest'lerini değişmez kimliklerle bağlayın.
- Aşama kapısı
- Staging→production geçişinde yetkili onay, eval sonucu ve güvenlik taramasını zorunlu kılın.
- Uyumluluk sözleşmesi
- Girdi/çıktı şeması, embedding boyutu, tokenizer ve araç parametrelerini sürümleyin.
- Geri dönüş hedefi
- RTO, önceki artifact erişimi, veri uyumu ve trafik anahtarlama süresini birlikte test edin.
Hesap ve uygulama örneği
Release manifesti model sha256:m1, prompt p17, embedding e3, index snapshot i88 ve runtime image c42 içerir. p18 ile yalnız istem değişse bile eval tekrar koşar. e4 embedding boyutunu değiştiriyorsa i88 kullanılamaz; çift indeks hazırlanıp doğrulandıktan sonra trafik taşınır.
Canary %5 trafikte 20 dakika boyunca en az 5.000 istek görmeli deniyorsa düşük trafikte yalnız süre şartı yeterli değildir. Hem örnek sayısı hem zaman penceresi sağlanır; hata oranı %1'i veya p95 TTFT 900 ms'yi aşarsa alias eski manifesti gösterir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
mlflow models register -m runs:/RUN_ID/model -n support-llm
release-manifest verify release-42.yaml
deploy canary --manifest release-42.yaml --traffic 5 --rollback-on error_rate>0.01Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Rollback sonrası cevaplar bozuluyor | Eski model yeni prompt/index/şemayla çalışıyor. | Canlı manifestte model dışındaki artifact digest'lerini önceki release ile karşılaştırın. |
| Hangi veriyle eğitildiği bilinmiyor | Pipeline lineage veya dataset snapshot kimliği eksiktir. | Registry run bağlantısını, object version ve veri erişim kaydını doğrulayın. |
| Alias yanlış sürüme gidiyor | Manuel değişiklik veya yarışan pipeline vardır. | Alias değişiklik günlüğünü ve optimistic concurrency/revision koşulunu kontrol edin. |
Kabul ve doğrulama kontrolleri
- Bütün artifact'ler için içerik digest'i ve sahibi kaydedin.
- Pipeline run, kaynak kod commit'i ve veri snapshot'ını bağlayın.
- Eval ve güvenlik kapılarını production alias değişiminden önce zorunlu kılın.
- Şema ve embedding uyumluluğunu otomatik test edin.
- Canary için hem süre hem örnek sayısı eşiği belirleyin.
- Önceki iki release'e gerçek trafik benzeri rollback tatbikatı yapın.
İlgili kavramlar
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Bağımlılık ve yeniden başlatma sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.