12 Haziran 2026'da, ABD ihracat kontrolleri Anthropic'i Claude Fable 5'i neredeyse hiç uyarı vermeden çevrimdışına almaya zorladı ve model 1 Temmuz'da geri dönene kadar kapalı kaldı. Tek bir model dizesini sabit kodlamış ekipler on dokuz gün boyunca telaşlandı; yedekleme zinciri olan ekipler bir yapılandırma değerini değiştirdi ve işlerine geri döndü.
Ders, tek bir kesintiden daha büyük. Çoğu LLM destekli uygulama, model kullanılabilirliğini DNS veya yerçekimi gibi sabit bir değişken olarak ele alıyor. Bu mimari bir varsayım ve yanlış. Bir model, yasal sorumluluğu, kapasite tavanları, bir kullanımdan kaldırma takvimi ve onu geri çekebilecek bir güvenlik ekibi olan bir üründür. Bu rehber, yapay zeka API'leri için yedeklemeyi nasıl tasarlayacağınızı ele alıyor, böylece bir sonraki kaybolma, hangi sağlayıcıyı vurursa vursun, size bir olay köprüsü yerine bir yapılandırma değişikliğine mal olur.
düğme
Modeller neden kaybolur?
Modeller, çoğu ekibin planladığından daha fazla nedenden dolayı ortadan kaybolur:
- Düzenleme. Fable 5'in askıya alınması teknik bir hatadan değil, ihracat kontrollerinden kaynaklandı. Yasal ve uyumluluk olayları, kullanımdan kaldırma takvimlerini takip etmez ve 90 günlük bir bildirim göndermezler. Kesinti sırasında dışarıdan nasıl göründüğü burada.
- Sağlayıcı olayları. Her büyük sağlayıcının çok saatlik kesintileri oldu. Kendi müşterilerinizle olan SLA'nız, onlarınki iyileşirken duraklamaz.
- Kullanımdan kaldırma. Sağlayıcılar, yayımlanmış takvimlere göre modelleri kullanımdan kaldırır. OpenAI, sürekli güncellenen bir kullanımdan kaldırma sayfası tutar ve Anthropic de eski Claude sürümlerini aynı şekilde sonlandırmıştır. Kullanımdan kaldırma, takvim tarihi olan yavaş çekim bir kesintidir.
- Kapasite. Lansman haftaları ve trafik yoğunlukları sırasında, sağlayıcılar yükü azaltır. Model "var olmasına" rağmen istekleriniz 429 ve 529 hataları döndürmeye başlar.
- Güvenlik geri alımları. Bir sağlayıcı, lansman sonrası bir sorun bulduktan sonra bir modeli engelleyebilir veya geri çekebilir. Bu sessizce ve bazen hesap başına gerçekleşir.
Farklı nedenler, aynı belirti: kodunuzun bağlı olduğu model kimliği yanıt vermeyi durdurur. Nedeni ne olursa olsun çözüm aynıdır, bu yüzden yedekleme tasarımı olay müdahalesi yerine sürekli yapılan bir iştir.
Yedekleme hiyerarşisi
Yedekleme tek bir karar değildir. Üç seviyesi vardır ve olgun sistemler genellikle birden fazlasını uygular.
Seviye 1: Aynı sağlayıcı yedeği. Aynı satıcıdan kardeş bir modele yönlendirin, örneğin Fable 5 → Opus 4.8 → Sonnet 4.6. Aynı SDK, aynı kimlik doğrulama, aynı yanıt şekli, bu yüzden geçiş ucuz ve hızlıdır. Anthropic, aynı API çağrısı içinde reddedilen bir isteği yedek bir modelde yeniden deneyen bir yedekleme parametresi aracılığıyla bunu sunucu tarafında bile destekler. İhtiyacınız olmadan önce yedek çiftinizi bilin: Fable 5 ve Opus 4.8 karşılaştırması, sabah 3'te karşılığını veren türden bir ödevdir.
Seviye 2: Çapraz sağlayıcı yedeği. Tamamen farklı bir satıcıya yönlendirin. Bu, sağlayıcı genelindeki kesintilere, hesap askıya almalarına ve aynı sağlayıcı zincirinin hayatta kalamayacağı bölgesel kısıtlamalara karşı koruma sağlar. Maliyeti, ikinci bir SDK, ikinci bir faturalandırma ilişkisi, ikinci bir kimlik doğrulama yolu ve farklı davranan istemlerdir.
Seviye 3: Düşük mod. Hiçbir sınır modeli olmadan yararlı bir şey sunun: tekrarlanan sorgular için önbelleğe alınmış yanıtlar, sınıflandırma seviyesindeki görevler için küçük bir yerel model veya net bir mesajla devre dışı bırakılmış özellik. Özelliğin kötüleşmesi kabul edilebilir. Uygulamanın bozulması kabul edilemez.
| Seviye | Geçiş gecikmesi | Kalite düşüşü | Mühendislik maliyeti |
|---|---|---|---|
| Aynı sağlayıcı yedeği | Saniyeler ila dakikalar; bir yapılandırma değişimi veya otomatik yeniden deneme | Küçük ila orta; aynı model ailesi, tanıdık davranış | Düşük; aynı SDK, kimlik doğrulama ve yanıt formatı |
| Çapraz sağlayıcı yedeği | Dakikalar ila saatler; yönlendirme mantığı ve test edilmiş istemler gerektirir | Orta; farklı tokenizörler, formatlar ve ret davranışı | Orta ila yüksek; ikinci entegrasyon, faturalandırma ve izleme |
| Düşük mod | Yapıldıktan sonra anında etkili | Büyük ama öngörülebilir ve dürüst | Orta; önbellek katmanı, yerel model veya özellik işaretleri |
Çoğu ekip bu çeyrekte Seviye 1'i uygulamalı, Seviye 3'ü taban olarak tutmalı ve Seviye 2'yi ancak risk altındaki gelir ikinci bir entegrasyonu haklı çıkardığında eklemelidir.
Bir tasarım noktası daha: sadece hedefleri değil, tetikleme koşullarını da tanımlayın. Bir zincir, trafiği neyin aşağıya çekeceğine karar vermediğiniz sürece eksiktir. Mantıklı varsayılanlar: model kimliğinde bir 404 hemen yedeklemeye geçer, bir ret sonraki modelde bir kez yeniden dener, bir 429 yedeklemeye geçmeden önce geri çekilir ve art arda üç zaman aşımı o model için bir devre kesici açar. Bu kuralları yönlendirme katmanına kodlayın, böylece sabah 3 kararı önceden alınmış olur.
Yedeklemeyi ucuz hale getiren tasarım hamleleri
Yedekleme, herhangi bir kesintiden çok önce verdiğiniz kararlara bağlı olarak ucuz veya pahalıdır.
Model kimliklerini kodda değil, yapılandırmada tutun. Model dizeniniz için hızlı bir grep çalıştırın. Eğer tek bir yapılandırma dosyası yerine uygulama kodunda görünüyorsa, bir dağıtım yapmadan yedeklemeye geçemezsiniz. Yol başına öncelik listesi işe yarayan şekildir:
# config/model-routes.yaml
routes:
chat-assist:
primary: claude-fable-5
fallbacks:
- claude-opus-4-8
- claude-sonnet-4-6
degraded_mode: cached_answers
max_output_tokens: 8192
timeout_seconds: 120
ticket-classifier:
primary: claude-sonnet-4-6
fallbacks:
- claude-haiku-4-5
degraded_mode: rules_engine
Yönlendirmeyi tek bir yerde yönetin. Bir ağ geçidi hizmeti veya yüz satırlık bir sarmalayıcı olsun, tam olarak bir modül bir isteğe hangi modelin hizmet vereceğine karar vermeli ve diğer her şey onu çağırmalıdır. Minimal bir versiyon şöyle görünür:
MODEL_CHAIN = ["claude-fable-5", "claude-opus-4-8", "claude-sonnet-4-6"]
def complete(prompt: str) -> str:
last_error = None
for model in MODEL_CHAIN:
try:
response = client.messages.create(
model=model,
max_tokens=8192,
messages=[{"role": "user", "content": prompt}],
)
if response.stop_reason == "refusal":
last_error = RefusalError(model)
continue # try the next model in the chain
return response.content[0].text
except (anthropic.NotFoundError, anthropic.RateLimitError,
anthropic.APIStatusError) as err:
last_error = err
continue
raise AllModelsUnavailable(MODEL_CHAIN) from last_error
Üretim versiyonları devre kesiciler ve model başına zaman aşımları ekler, ancak prensip her boyutta geçerlidir: çağrı yapanlar bir tamamlanma ister, bir model değil.
Yetenek düzeyli istemler yazın. Bir modelin tuhaflıklarına bağlı bir istem, yedekleme hikayenizi kurguya dönüştürür. Tüm yedekleme kümenizde kabul edilebilir çıktı üreten temel istemler yazın, ardından modele özgü hileleri (belirli bir düşünme yapılandırması, ayarladığınız bir biçimlendirme alışkanlığı) görevi bozmadan bırakılabilecek model başına katmanlara ayırın. Temel istemi en güçlü birincil modelinizde değil, en zayıf yedeğinizde test edin. Bu kulağa geldiğinden daha önemlidir: daha yeni sınır modelleri genellikle seyrek, hedef odaklı istemleri ödüllendirirken, daha küçük yedeklerin daha açık bir yapıya ihtiyacı vardır. Her şeyi birincil model için ayarlarsanız, yedekleme takip edemeyeceği talimatları miras alır; eğer her şeyi tüm küme için ayarlarsanız, birincil modelde biraz parlaklık kaybedersiniz ve uçtan uca çalışan bir zincir kazanırsınız.
İstek parametrelerini de taşınabilir tutun. İstemler, modele özgü tek yüzey değildir. Düşünme yapılandırması, örnekleme parametreleri ve çıktı sınırları model nesillerine göre farklılık gösterir ve birincil modelin kabul ettiği bir parametre, yedekte 400 hatası döndürebilir. Yapılandırmada model kimliklerinin yanına model başına parametre kümeleri depolayın ve yönlendirme katmanının bunları gönderme sırasında uygulamasını sağlayın. Geçersiz bir parametre hatası nedeniyle ölen bir yedekleme, sahip olmadığınız bir yedeklemedir.
Yanıtları sağlayıcıdan bağımsız olarak işleyin. Yönlendirme sınırında yanıtları kendi dahili şeklinize normalleştirin: metin dışarı, yapılandırılmış alanlar doğrulanmış, durma nedenleri kendi numaralandırmanıza eşlenmiş. On iki yerden sağlayıcıya özgü bir yanıt nesnesine ulaşan kod, sağlayıcıları değiştirdiğiniz gün bozulacaktır.
Maliyet ve limit farklılıkları için bütçe ayırın. Yedekleme modelleri, jeton başına fiyat, bağlam penceresi ve maksimum çıktı açısından farklılık gösterir. Fable 5'ten Opus 4.8'e düşmek jeton başına maliyeti yaklaşık yarı yarıya düşürürken, Sonnet 4.6 daha da ucuzdur ancak çıktıyı daha düşük bir seviyede sınırlar; hafızanızdaki sayılara güvenmek yerine mevcut model genel bakışına bakın. Yönlendirme katmanınız, model başına max_output_tokens ve kesme davranışını taşımalıdır, böylece bir yedekleme sessizce kesik yanıtlar veya sürpriz bir fatura üretmez.
Yedekleme kümenizde sözleşme testi
Asla kullanmadığınız yedekleme yolu, ihtiyacınız olduğunda başarısız olan yoldur. Yedekleme zincirinizi bir API sözleşmesi olarak ele alın ve onu öyle test edin.
İşe yarayan desen: kritik istemlerinizi yedekleme zincirindeki her modele karşı, düzenli olarak ve CI'da çalıştıran bir test senaryosunu Apidog'da tutun. Her model için üç şeyi doğrulayın:
- Şema. Yanıt ayrıştırılır, gerekli alanlar mevcuttur ve yapılandırılmış çıktı JSON Şemanıza göre doğrulanır. Bu, yedek bir modelin JSON'u farklı şekilde kaçırması veya ayrıştırıcınızın varsaydığı bir alanı düşürmesi gibi ince kopmaları yakalar.
- Gecikme. p95, o model için belirlediğiniz bütçenin altında kalır. Teknik olarak çalışan ancak 40 saniye süren bir yedekleme farklı türde bir kesintidir.
- Kalite sinyalleri. Ucuz, mekanik kontroller: çıktı boş değil, doğru dilde, gerekli öğeleri içeriyor ve istem kümesindeki ret oranı başlangıç seviyesine yakın kalıyor. CI'da ifadeyi değerlendirmiyorsunuz; işi yapmayı bırakan bir modeli tespit ediyorsunuz.
Her model veya sağlayıcı için bir Apidog ortamıyla yapılandırın, uç nokta URL'sini, API anahtarını ve model kimliğini ortam değişkenleri olarak tutun. Aynı senaryo, ortamları değiştirerek `claude-fable-5`, `claude-opus-4-8` ve `claude-sonnet-4-6` üzerinde değişmeden çalışır ve zincire dördüncü bir model eklemek, yeni testler yazmak yerine bir ortam eklemek anlamına gelir.
İstem kümesini bilinçli olarak seçin. Yüzlerce vakaya ihtiyacınız yok; üretim trafiğinizi temsil eden on ila yirmi isteme ihtiyacınız var: gönderdiğiniz en uzun bağlam, ayrıştırdığınız en sıkı yapılandırılmış çıktı, bir zamanlar ayrıştırıcınızı bozan uç durum ve alanınızın hassas sınırına yakın en az bir istem, böylece ret kayması bir destek biletinde değil, bir test çalıştırmasında görünür. Bu küme sürümünü istemlerinizle birlikte tutun ve üretim sizi şaşırttığında, şaşırtıcı durumu pakete ekleyin.
Bir kesinti sırasında bir bonus var: bir ortamı kaydedilmiş yanıtları döndüren bir sahte sunucuya yönlendirin ve sağlayıcı kapalıyken CI'niz modelin aşağısındaki her şeyi doğrulamaya devam eder. Apidog, testlerinizin zaten kullandığı aynı API belirtiminden bu sahte sunucuyu oluşturabilir, böylece kesinti sürüm döngünüzü de engellemez.
12 Haziran'da, sakin ekipler ile panik içindeki ekipler arasındaki fark buydu. Bazıları, Opus 4.8 yollarının en iyi istemleri için geçerli çıktı ürettiğine dair geceleyin kanıtlara sahipti. Diğerleri ise umut besliyordu.
Operasyonel hazırlık
Mimari, size yedekleme yeteneği sağlar. Operasyonlar, kararın hızlı ve temiz bir şekilde alınmasını sağlar.
- Sadece birincil modeli değil, her modeli sorgulayın. Zincirdeki her modele, kullanıcı trafiğinden ayrı olarak, zamanlanmış sentetik bir istem çalıştırın. status.anthropic.com gibi sağlayıcı durum sayfaları yararlıdır, ancak geride kalırlar ve sağlayıcının dünyasını anlatırlar, sizin hesabınızı, bölgenizi veya hız limiti katmanınızı değil. Kendi sorgunuz önce başarısız olur.
- Sadece 5xx hatalarını değil, ret ve hata oranlarını da uyarın. Model düzeyindeki sorunlar genellikle artan bir ret oranı, bir 404 `model_not_found` hatası patlaması veya 429'lar olarak ortaya çıkar, oysa HTTP düzeyindeki panolar yeşil kalır.
- İhtiyacınız olmadan önce geçiş planını yazın. Kimin yedeklemeye geçeceğine, hangi yapılandırma değerinin değişeceğine, desteğe ve müşterilere yapılacak duyurunun ne olacağına ve ilk saatte hangi panoların izleneceğine karar verin. Fable 5 kesintisi sırasında, bir planı olmayan ekipler, karar verme sürecine yapmaktan daha fazla zaman harcadı.
- Geri dönüşü aşamalandırın. Birincil model geri döndüğünde, trafiğin %100'ünü tek bir hareketle çevirmeyin. Küçük bir dilimi kanarya testi yapın, kalite ve ret metriklerini yedekleme temel seviyenizle karşılaştırın, sonra artırın. Bu sürecin mekaniklerini Fable 5 API'ye nasıl geri döneceğimiz bölümünde ele alıyoruz ve bu model, geri dönen herhangi bir birincil model için geçerlidir.
- Provasını yapın. Üç ayda bir, hazırlık ortamında veya risk toleransınız izin veriyorsa üretimde küçük bir trafik dilimi için bilerek yedeklemeye geçin. Bir tatbikat, yedekleme hesabındaki süresi dolmuş API anahtarını, kimsenin bulamadığı panoyu ve altı ay önce yeniden adlandırılan yapılandırma değerini ortaya çıkarır. Bunların her birini sakin bir Salı günü bulmak daha ucuzdur.
Fable 5 olayının özel olarak öğrettikleri
1 Temmuz'daki geri dönüş, etrafında politika oluşturmaya değer bir ayrıntı içeriyordu: Anthropic, yeniden eğitilmiş bir güvenlik sınıflandırıcısı ile Fable 5'i yeniden dağıttı. Aynı model kimliği, aynı API yüzeyi, ancak çevrimdışı olan model byte-byte aynı değildi. Ret sınırları değişti. Haziran başında sorunsuz çalışan istemler Temmuz'da farklı sonuçlar verebilir ve eskiden tetiklenen bazı retler artık tetiklenmedi.
Bundan çıkan kural: geri dönüşte yeniden test edin, yeniden etkinleştirmeyin. Bir modelin herhangi bir yokluktan dönmesi, ister askıya alma, ister geri alma, ister uzun bir kullanımdan kaldırma ertelemesi olsun, yeni bir model sürümü olarak ele alınmalıdır. Tam sözleşme paketini ona karşı çalıştırın. Ret ve kalite metriklerini yedek modelinizin sayılarıyla değil, kesinti öncesi temel seviyelerinizle karşılaştırın. Yükseltmeden önce kanarya testi yapın.
İkinci, daha sessiz bir ders var. On dokuz gün, yedeğinizin fiili temel seviyeniz haline gelmesi için yeterince uzun bir süredir. Kullanıcılar Opus 4.8'in davranışına adapte oldu; iç ekipler istemleri buna göre ayarladı. Bir geri dönüş sadece teknik bir olay değil, aynı zamanda bir ürün değişikliğidir ve bir ürün piyasaya sürmekle aynı özeni hak eder.
Sıkça Sorulan Sorular
Aynı sağlayıcı yedekleme zinciri yeterli mi, yoksa ikinci bir sağlayıcıya mı ihtiyacım var?
Aynı sağlayıcı ile başlayın. Kullanımdan kaldırmaları, kapasite olaylarını, güvenlik geri alımlarını ve modele özgü askıya almaları, mühendislik maliyetinin çok küçük bir kısmıyla kapsar ve Anthropic'in sunucu tarafı yedeklemeleri gibi özellikler, onu neredeyse ücretsiz hale getirir. Tam bir sağlayıcı kesintisi veya hesap düzeyindeki bir olay, ikinci bir entegrasyon sürdürmekten size daha pahalıya mal olacaksa, çapraz sağlayıcı bir yol ekleyin. Her iki durumda da düşük mod inşa etmeye değerdir.
Trafik daha küçük bir modele yönlendirildiğinde kullanıcılar bunu fark edecek mi?
Bu göreve bağlıdır, bu yüzden tahmin etmek yerine ölçün. Çıkarma ve sınıflandırma için, iyi yönlendirilmiş daha küçük bir model genellikle ayırt edilemez. Uzun biçimli akıl yürütme için boşluklar ortaya çıkar; Fable 5 ve Opus 4.8 karşılaştırmamız gibi kıyaslamalar size bir başlangıç haritası verir. Yetenek düzeyli istemler ve dürüst UI metni ("yanıtlar şu an daha kısa olabilir") algılanan boşluğu daha da daraltır.
Yedekleme yolu ne sıklıkla test edilmelidir?
Her gece düzenli olarak, istemlerde veya yönlendirme yapılandırmasında herhangi bir değişiklik olduğunda CI'da ve zincirinizi etkileyen herhangi bir sağlayıcı duyurusundan hemen sonra. İlk yirmi isteminizi üç modele karşı çalıştırmanın jeton maliyeti, bir kesinti sırasında bozuk bir yedekleme keşfetmeye kıyasla çok küçük bir miktardır.
Model kullanılabilirliği daha tahmin edilebilir olmayacak, aksine daha az tahmin edilebilir olacak: daha sıkı düzenlemeler, daha hızlı sürüm ve kullanımdan kaldırma döngüleri ve her lansmanla değişen kapasite. Bir sonraki Fable 5 anını atlatacak ekipler, modeli kalıcı bir parça olarak değil, test edilmiş bir yedekle değiştirilebilir bir bileşen olarak görenler olacaktır. İş, bir yapılandırma dosyasına, bir yönlendirme sarmalayıcısına ve her gece çalışan bir sözleşme paketine sığar. Apidog'u indirin ve yedekleme zincirinizi bugün zamanlanmış bir teste bağlayın; bir sonraki kesinti ne zaman olacak, sadece bir zaman meselesi.