Çoklu Sağlayıcı LLM API'leri için Model Yaşam Döngüsü Kontrol Düzlemi Nasıl Oluşturulur

Model kimlikleri üretim bağımlılıklarıdır. Bir uygulama OpenAI, Anthropic, Gemini, Azure'da barındırılan modelleri veya bunlardan birkaçını paylaşılan bir API katmanı aracılığıyla çağırırsa, model yaşam döngüsü değişiklikleri istekleri bozabilir, çıktı davranışını değiştirebilir veya aceleye getirilmiş geçişleri zorlayabilir. Operasyonel risk, kullanımdan kaldırılan bir modelle sınırlı değildir. Aynı zamanda önizleme modellerinin ortadan kaybolmasını, takma adların daha yeni anlık görüntülere çözümlenmesini, sağlayıcıya özel yaşam döngüsü terimlerinin yanlış okunmasını ve ekiplerin artık kimsenin sahip olmadığı hizmetlerde model adlarını sabit olarak kodlamasını da içerir.

Model yaşam döngüsü kontrol düzlemi, mühendislik ekiplerine model durumunu izlemek, üretim politikasını uygulamak ve sağlayıcının son tarihlerinden önce taşıma işlemlerini yürütmek için yönetilen tek bir yer sağlar. Her sağlayıcıyı belirsiz bir durum etiketine sığdırmamalı. Sağlayıcı anlamlarını korumalı, daha basit bir dahili politika ortaya koymalı ve model değişikliklerini müşteriye yönelik iş yüklerine ulaşmadan önce gözlemlenebilir hale getirmelidir.

Soyutlamayla değil, gerçeklerle başlayın

Gerçekler: Büyük sağlayıcılar yaşam döngüsü bilgilerini yayınlar, ancak bunu farklı şekilde yaparlar. OpenAI, genel kullanımdan kaldırma belgelerini barındırıyor ve aktif kullanıcıların, değiştirmeleri değerlendirebilmeleri, davranışları test edebilmeleri ve kaldırmadan önce geçiş yapabilmeleri için bilgilendirildiğini söylüyor. Anthropic etkin, eski, kullanımdan kaldırılmış, kullanımdan kaldırılmış ve kullanımdan kaldırılmış model isteklerinin başarısız olması gibi yaşam döngüsü durumlarını tanımlar. Anthropic ayrıca sabitlenmiş anlık görüntü kimliklerini kullanışlı takma adlardan ayırır. Google Gemini kararlı, önizleme, en son ve deneysel model kategorilerini belgeler. Microsoft Foundry, Azure tarafından barındırılan modeller için API'ler aracılığıyla yaşam döngüsü ve kullanımdan kaldırılma meta verilerini açığa çıkarır, ancak API durum adlarının dikkatli yorumlanması gerekir: Kullanımdan Kaldırılmış portal durumu API'da Kullanımdan Kaldırılıyor olarak görünebilir; Kullanımdan Kaldırılmış API değeri ise modelin kullanımdan kaldırıldığı ve artık çıkarım sunmadığı anlamına gelir.

Öneri: Sağlayıcı yaşam döngüsü verilerini kaynak olarak değerlendirin girdi, iç politikanız olarak değil. Dahili sisteminiz operasyonel sorulara cevap vermelidir: Bu model üretimde kullanılabilir mi? Kimin sahibi? Ne zaman göç etmesi gerekiyor? Ortadan kaybolursa ne kırılır? Değişim, sözleşme ve görev değerlendirmelerini geçti mi?

Tahmin: Çoklu sağlayıcı model portföyleri daha az değil, daha dinamik hale gelecektir. Yönetişim olmadan en son tarz takma adlara veya önizleme modellerine bağımlı olan ekipler, taşıma işlemlerini rutin bağımlılık işleri yerine acil durumlar olarak görmeye devam edecektir.

Kontrol düzlemi sınırını tanımlayın

Yaşam döngüsü kontrol düzlemi, ağ geçidinde veya model yönlendiricisinde uygulama kancaları olacak şekilde istek yolunun yanında yer almalıdır. Her bilgi istemine, değerlendirmeye veya faturalandırma iş akışına sahip olması gerekmez. Hangi model kimliklerinin, hangi ortamlarda hangi iş yükleri tarafından kullanılabileceği konusunda yetkiye ihtiyacı vardır.

Tipik bir kurumsal LLM API kurulumunda, kontrol düzleminin beş sorumluluğu vardır:

• Sağlayıcı modelleri ve dahili rotaların standart bir kaydını tutmak.
• API'lerden, belgelerden, sürümden sağlayıcı yaşam döngüsü sinyallerini alma notlar ve manuel inceleme.
• Model kimliklerini, takma ad ve önizleme riski de dahil olmak üzere üretim riskine göre sınıflandırın.
• Dağıtım zamanında ve istek zamanında politikayı uygulayın.
• Canary geçişlerini kullanımdan kaldırmadan veya politika son tarihlerinden önce koordine edin.

Bu, geri dönüş yönlendirmesinden farklıdır. Geri dönüş, kesinti sırasında yardımcı olabilir ancak bu bir yaşam döngüsü stratejisi değildir.Bir değiştirme modeli, varsayılan rota haline gelmeden önce davranış, çıktı sözleşmeleri, gecikme, maliyet, reddetme kalıpları ve araç çağrısı şekli açısından değerlendirilmelidir.

Kanonik bir model kaydı oluşturun

Kayıt gerçeğin kaynağıdır. Sağlayıcının yerel meta verilerini ve dahili yönetişim meta verilerini içermelidir. Yalnızca model adını ve sağlayıcıyı saklayan şemalardan kaçının. Bir istek başarısız oluncaya kadar yaşam döngüsü riski bu şekilde görünmez kalır.

Minimum kayıt defteri alanları

• provider: openai, anthropic, google, azure_openai veya başka bir sağlayıcı ad alanı.
• provider_model_id: sağlayıcıya veya dağıtım uç noktasına gönderilen tam kimlik.
• internal_model_key: sabit dahili adınız, örneğin support_summarizer_primary.
• model_family: raporlama ve taşıma gruplaması için normalleştirilmiş bir aile etiketi.
• id_type: sabitlenmiş anlık görüntü, tarihli sürüm, değişen takma ad, tarihsiz sabit takma ad, en son, önizleme, deneysel, dağıtım takma adı veya bilinmiyor.
• provider_lifecycle_state: sağlayıcının ham durumu değer.
• internal_lifecycle_state: izin verildi, izle, blocked_for_new_production, migrate_required, kullanımdan kaldırıldı veya exception_only.
• retirement_date: bilindiğinde sağlayıcının kullanımdan kaldırılma tarihi.
• replacement_candidate: sağlayıcı tarafından önerilen değiştirme veya dahili olarak seçilen hedef.
• supported_surfaces: sohbet, yanıtlar, mesajlar, yerleştirmeler, transkripsiyon, görüntü, toplu iş, ince ayar veya diğer ilgili API yüzeyler.
• capabilities: bağlam penceresi, yapılandırılmış çıktı desteği, araç kullanımı, görüş, akıl yürütme kontrolleri, akış, JSON modu, istem önbelleğe alma, toplu destek ve uygun olduğu yerde logprob'lar.
• pricing_class: maddi olarak farklı olanı tanımlamak için yeterli maliyet meta verileri replacements.
• owner_team ve code_owner: üretim kullanımından sorumlu ekip ve incelemeci.
• last_verified_at ve source: yaşam döngüsü verilerinin nereden geldiği ve ne zaman kontrol edildiği.

Sağlayıcı koşullarını provider_lifecycle_state'de olduğu gibi koruyun. Daha sonra bunları kendi internal_lifecycle_state numaranızla eşleştirin. Bu, özellikle bir sağlayıcının kullanımdan kaldırılmış olması, başka bir API değerinin kullanımdan kaldırıldığı anlamına gelirken, başka bir sağlayıcının kullanımdan kaldırılmış olması durumunda, tehlikeli çeviri hatalarını önler.

Örnek kayıt defteri kaydı

{
  "provider": "anthropic",
  "provider_model_id": "claude-example-20261001",
  "internal_model_key": "customer_email_classifier_primary",
  "model_family": "claude-example",
  "id_type": "pinned_snapshot",
  "provider_lifecycle_state": "active",
  "internal_lifecycle_state": "allowed",
  "retirement_date": null,
  "replacement_candidate": null,
  "supported_surfaces": ["messages"],
  "capabilities": {
    "tool_use": true,
    "structured_output": "tool_schema",
    "streaming": true,
    "context_window_tokens": 200000
  },
  "owner_team": "support-platform",
  "code_owner": "team-support-platform",
  "last_verified_at": "2026-10-07",
  "source": "provider_docs"
}

Tam alanlar değişiklik gösterir, ancak prensip sabittir: her üretim rotasının bir sahibi, bir yaşam döngüsü durumu, bir politika kararı ve değiştirmeyi planlamak için yeterli yetenek meta verileri olmalıdır.

Model kimliğini sınıflandırın risk

Model yaşam döngüsü kontrolü tanımlayıcıyla başlar.Sabitlenmiş bir model sürümü ve en yeni stildeki takma ad, şu anda aynı temel modele çözümlenseler bile eşdeğer operasyonel seçenekler değildir.

Şunun gibi bir risk sınıflandırması kullanın:

• Varsayılan olarak üretim açısından güvenli: kararlı tarihli sürümler, sağlayıcı tarafından desteklenen sabitlenmiş anlık görüntüler ve onaylanmış sabitlenmiş hedeflere çözümlenen dahili takma adlar.
• İzin verilir izleme: sağlayıcı belgelerinde, sağlayıcı semantiğini kaydedip bunları düzenli aralıklarla doğrularsanız, sabit bir anlık görüntüyle eşleştiği söylenen sabit, tarihsiz kimlikler.
• İstisna gerekli: önizleme, deneysel, en yeni, sürekli takma adlar ve otomatik olarak daha yeni tarihli anlık görüntülere taşınan sağlayıcı takma adları.
• Yeni üretim için engellendi: kullanımdan kaldırılmış modeller, kullanımdan kaldırılmadan önce donma penceresi içindeki modeller ve sahibi olmayan modeller.
• Tamamen engellendi: kullanımdan kaldırılmış modeller veya artık çıkarım sağlamayan modeller.

Ödünleşme: Sürüm sabitleme, tekrarlanabilirliği artırır ve değişiklikleri incelenebilir hale getirir, ancak kullanımdan kaldırma çalışmalarını artırır. En son tarzdaki takma adlar, kısa vadede bakımı azaltır, ancak davranışı sessizce değiştirebilirler. Kontrol düzlemi, tek tek hizmetlerin tesadüfen karar vermesine izin vermek yerine bu dengelemeyi açık bir şekilde yapmalıdır.

Yaşam döngüsü verilerini bir programa göre senkronize edin

Kayıt defteri, aktif olarak bakımı yapılmadığı sürece bayat hale gelir. Sağlayıcı meta verilerini güncelleyen ve bir şeyler değiştiğinde uyarıları açan, planlanmış bir yaşam döngüsü senkronizasyon işi ekleyin.

Mümkün olduğu yerlerde makine tarafından okunabilen sağlayıcı API'lerini kullanın. Azure'da barındırılan modeller için, model API'lerindeki yaşam döngüsü ve kullanımdan kaldırma alanlarını içerebilir. Temel olarak yaşam döngüsü bilgilerini belgelerde yayınlayan sağlayıcılar için, üretim politikasını değiştirmeden önce insan incelemesi ile kontrollü bir belge izleme iş akışı kullanın. Bir HTML kazıyıcının üretim dağıtımlarını incelemeden doğrudan engellemesine izin vermeyin; dokümantasyon sayfaları düzeni, ifadeleri ve biçimlendirmeyi değiştirir.

Yaşam döngüsü senkronizasyon iş akışı

1. API'lerden, dokümanların anlık görüntülerinden veya onaylanmış manuel girişlerden sağlayıcı modeli meta verilerini alın.
2. Sağlayıcının yerel durum değerlerini korurken ham kayıtları bir aşamalandırma tablosunda normalleştirin.
3. Aşama kayıtlarını geçerli olana göre farklılaştırın kayıt defteri.
4. Değişiklikleri sınıflandırın: yeni model, yaşam döngüsü durumu değişikliği, kullanımdan kaldırılma tarihi eklendi, kullanımdan kaldırılma tarihi değiştirildi, değiştirme eklendi, yetenek değiştirildi, fiyatlandırma değiştirildi veya model kaynaktan kaldırıldı.
5. Politikayı etkileyen değişiklikler için inceleme öğelerini açın.
6. İncelemeden sonra, kaydı güncelleyin ve sahip ekipleri bilgilendirin.
7. Bir üretim rotası girdiğinde taşıma biletlerini otomatik olarak oluşturun migrate_required.

Uyarılar sahipliğe bağlı olmalıdır. Bir mühendislik kanalındaki genel bir mesaj yeterli değildir. Sahip ekibin bir son tarihe, etkilenen hizmetlere, mevcut trafiğe, yedek adaylara ve bir sonraki gerekli eyleme ihtiyacı vardır.

Çalışma zamanı hatalarından önce politikayı zorunlu kılın

Kontrol düzlemi, kötü model seçimlerini üretime ulaşmadan önce engellemelidir. Model kimlikleri sistemlere kod, yapılandırma, denemeler, not defterleri ve iş ortaklarına yönelik API'ler yoluyla girdiğinden, yaptırım birden fazla yere aittir.

Dağıtım zamanı kontrolleri

Model kimlikleri ve dahili model anahtarları için hizmet yapılandırmasını tarayan CI veya dağıtım kontrolleri ekleyin.Bir hizmet, kayıt defterinde bulunmayan, sahibi olmayan, kullanımdan kaldırılmış olarak işaretlenmiş veya yeni üretim için engellenmiş bir model sunduğunda dağıtımları engelleyin. Önizleme, deneysel, en yeni veya dönüşümlü takma ad kimlikleri için açık onay gerektir.

Bu kontrol, net bir hata mesajı oluşturmalıdır:

Model policy violation:
- service: document-ingestion-api
- requested model: gemini-example-preview
- state: exception_required
- reason: preview models are not allowed for new production routes without owner approval
- action: request exception or select an approved internal model key

İstek zamanı kontrolleri

Ağ geçidi veya yönlendirici, çalışma zamanında aynı politikayı uygulamalıdır. Bu önemlidir çünkü bazı iş yükleri modelleri dinamik olarak seçer veya model adlarını müşteri yapılandırmasından alır. Çalışma zamanı politikası, kullanımdan kaldırılan modelleri engelleyebilir, onaylanmamış önizleme modellerini reddedebilir ve dahili takma adları onaylanmış sabitlenmiş hedeflere yönlendirebilir.

Yalnızca uygulama koduna güvenmeyin. Paylaşılan istek katmanı, ekipler arasında model yönetimini uygulamak için tutarlı olan son yerdir.

Takma ad kaymasını gözlemlenebilir hale getirin

Bir sağlayıcı çözümlenen modeli ortaya çıkarırsa, hem istenen modeli hem de çözümlenen veya döndürülen modeli günlüğe kaydedin. Aksi takdirde istek zamanında kullanılan dahili kayıt defteri eşlemesini günlüğe kaydedin. Metrikler dahili model anahtarını, sağlayıcıyı, talep edilen modeli, mümkün olduğunda çözümlenen modeli, model ailesini, yaşam döngüsü durumunu ve sahip ekibini içermelidir.

Bu, operasyonel soruların hızlı bir şekilde yanıtlanmasını mümkün kılar:

• Hangi üretim rotaları hâlâ kullanımdan kaldırılması planlanan bir modeli kullanıyor?
• Hangi istekler önizlemeyi veya en son kimlikleri kullanıyor?
• Bir takma ad farklı şekilde çözümlenmeye başladı mı sağlayıcı güncellemesinden sonra?
• Yaşam döngüsü politikası değişikliğinden hangi ekipler etkilenecek?
• Taşıma işlemi sırasında gecikme, maliyet veya çıktı doğrulama hataları değişiyor mu?

Takma ad kayması her zaman bir sağlayıcı hatası değildir. Bazen bu, uygun bir takma adın belgelenmiş davranışıdır. Risk, görünürlük olmadan bu davranışa bağlı olmaktan kaynaklanır.

Emeklilik tarihlerinden önce kanarya geçişlerini kullanın

Emeklilik bildirimi, yeniden yazmanın başlangıcı değildir. Değerlendirmenin tamamlanması ve kullanıma sunulması için son tarihtir. Her üretim modeli rotası için, değiştirme gerektiğinde yürütülebilecek bir geçiş runbook'u bulundurun.

Geçiş runbook'u

1. Etkilenen rotaları, sahip ekipleri, istek hacmini, müşterileri ve API yüzeyleri tanımlayın.
2. Sağlayıcı kılavuzundan ve dahili yetenek gereksinimlerinden bir veya daha fazla yedek aday seçin.
3. Şunlar için çevrimdışı sözleşme testleri çalıştırın: şema geçerliliği, araç çağrıları, reddetme yönetimi, güvenliğe duyarlı yanıtlar ve bilgi istemi biçimi varsayımları.
4. Temsili istemleri ve beklenen inceleme kriterlerini kullanarak görev düzeyinde değerlendirmeler çalıştırın.
5. Gecikme, maliyet, belirteç kullanımı, hata oranları ve çıktı doğrulama hatalarını karşılaştırın.
6. Canary, replacement.
7. Sahip ekiple farklılıkları inceleyin.
8. Trafiği kademeli olarak artırın veya mevcut sabitlenmiş modele geri dönün.
9. Dahili takma adı yalnızca kabul kriterleri karşılandıktan sonra güncelleyin.
10. Kullanımdan kaldırılan modeli izin verilenler listelerinden kaldırın ve taşıma işlemini kapatın ticket.

Öneri: Kanarya başlamadan önce kabul kriterlerini tanımlayın. Aksi halde takımlar bireysel örneklerden yola çıkarak tartışmaya eğilimlidirler.Yararlı kriterler arasında JSON şema geçerliliği, araç çağrısı bağımsız değişkeni uyumluluğu, görev başarı derecesi, ret oranı, p95 gecikmesi, başarılı görev başına ortalama maliyet ve sağlayıcı hata oranı yer alır.

Ödül: Canary değerlendirmesi, geçişleri yavaşlatır ancak yanlış bir uyumluluk algısını önler. İki model hem araçları hem de yapılandırılmış çıktıyı destekleyebilir ve yine de bağımsız değişken şekli, ayrıntı düzeyi, reddetme davranışı veya bilgi istemi sırasına duyarlılık açısından farklılık gösterebilir.

Dondurma pencerelerini ve istisna kurallarını ayarlayın

Yeni kullanımı engellemek için sağlayıcının kullanımdan kaldırılma tarihine kadar beklemeyin. Modele yönelik yeni üretim dağıtımlarının engellendiği ve mevcut rotaların geçiş biletlerine sahip olması gereken, kullanımdan kaldırılmadan önceki 60 veya 90 gün gibi bir dondurma aralığı oluşturun.

Politika katı olmalı ancak kör olmamalıdır. Ekibin bir önizleme modeline veya kullanımdan kaldırılmış bir modele geçici olarak erişmeye ihtiyaç duyduğu durumlar olacaktır. Son kullanma tarihleri, sahip onayı, etkilenen hizmetler, beklenen trafik ve geri alma planlarını içeren istisna kayıtlarını kullanın. Süresi dolmayan istisnalar, sessiz politika atlamalarına dönüşür.

Uygulamaya uygun sonuç

Bir model yaşam döngüsü kontrol düzlemi oluşturmak için, halihazırda müşteri trafiğini taşıyan üretim rotalarıyla başlayın. Her rotayı sağlayıcı kimliği, dahili sahip, yaşam döngüsü durumu, takma ad sınıflandırması, kullanımdan kaldırılma tarihi, yedek aday ve yetenek meta verileriyle birlikte bir kayıt defterine yerleştirin. Sağlayıcı yaşam döngüsü değişiklikleri için planlanmış bir senkronizasyon işlemi ekleyin. Politikayı CI'da ve ağ geçidinde uygulayın. Talep edilen ve çözümlenen modelleri günlüğe kaydedin. Ardından canary geçişini, sağlayıcının son teslim tarihlerine tek seferlik bir yanıt olarak değil, standart bir runbook haline getirin.

Pratik hedef basit: hiçbir üretim iş yükü, yönetilmeyen bir model kimliğine bağlı olmamalıdır. Her modelin bir sahibi, bir yaşam döngüsü durumu, bir politika kararı ve test edilmiş bir değiştirme yolu olmalıdır.

İlgili okumalar

• OpenAI uyumlu çoklu model için geçiş sözleşmeleri API