AI API Ağ Geçidinde Hizmet Katmanı Yönlendirmesi: Sabit Kodlama Sağlayıcıları Olmadan Hızlı, Standart, Tedarik Edilmiş ve Toplu
Ağ geçidinde sağlayıcıdan bağımsız yapay zeka iş yükü katmanlarını ortaya çıkarmak, ardından her isteği kiracı kontrolleri, analizler ve faturalama kayıtlarıyla hızlı, standart, tedarik edilmiş veya toplu kapasiteyle eşlemek için pratik bir mimari.
Hizmet katmanı yönlendirme, bir yapay zeka isteğinin üstün düşük gecikme süreli kapasiteyi, normal isteğe bağlı kapasiteyi, ayrılmış aktarım hızını veya indirimli eşzamansız işlemeyi hak edip etmediğine karar veren politika katmanıdır. Bu katman olmadan uygulama ekipleri genellikle sağlayıcıya özel işaretleri, dağıtım adlarını ve toplu uç noktaları doğrudan ürün kodunda kodlar. Bu da gecikmenin, maliyetin, kotanın ve kiracının faturalandırma davranışının yönetilmesini zorlaştırıyor.
Ağ geçidi, sağlayıcı mekanizmalarını değil, iş yükünün amacını açığa çıkarmalıdır. Bir ürün ekibi "bu etkileşimli bir destek yanıtıdır" veya "bu gecelik bir zenginleştirme işidir" diyebilmeli ve ağ geçidi amacı doğru yukarı akış kapasite seçeneğiyle eşleştirip gerçekte ne olduğunu kaydedebilmelidir.
Okuyucu sorunu: kapasite sınıfları uygulama mantığı haline geliyor
Birden fazla model sağlayıcı kullanan ekipler genellikle basit model yönlendirmeyle başlar: Bu model kimliğini bu sağlayıcıya gönderin. Sağlayıcılar farklı kapasite sınıflarını kullanıma sunduğunda yönlendirme zorlaşır:
- Kullanıcıya yönelik yollar için birinci sınıf, düşük gecikmeli istek işleme.
- Sıradan eşzamanlı trafik için standart paylaşılan kapasite.
- Tahmin edilebilir aktarım hızı için ayrılmış veya temel hazırlığı yapılmış kapasite.
- Gecikmeye toleranslı iş yükleri için toplu veya eşzamansız API'ler.
- Ayrılmış kapasite tükendiğinde yayılma davranışı.
Her uygulama bu seçimleri kendisi yaparsa kuruluş dört şey üzerindeki kontrolünü kaybeder: Premium kapasiteyi kim kullanabilir, maliyeti ne kadardır, kapasite kullanılamadığında ne olur ve seçilen katmanın ürünü harcamayı haklı çıkaracak kadar geliştirip geliştirmediği.
Pratik model, AI API ağ geçidinin içine sağlayıcıdan bağımsız bir hizmet kalitesi katmanı yerleştirmektir.
Geliştirilecek gerçekler
Ayrıntılar sağlayıcıya göre değişir ancak gözlemlenebilir bazı gerçekler, ağ geçidi düzeyinde bir tasarımı destekler.
- Gerçek: Bazı sağlayıcılar, premium işleme için istek başına hizmet katmanı sunar. OpenAI, Hızlı modu
service_tierparametresini kullanan istek başına bir seçenek olarak tanımlıyor ve bunun Standart işlemeye göre daha yüksek bir ücretle faturalandırıldığını söylüyor. OpenAI ayrıca 30 Temmuz 2026'da Öncelikli işlemenin Hızlı mod olarak yeniden adlandırıldığını ve hemservice_tier=priorityhem deservice_tier=fast'ın API istekleri için kabul edildiğini belirtiyor. - Gerçek: Premium isteklerinin işlenmesi ayrı bir kota evreni olmayabilir. OpenAI, Hızlı mod hız sınırlarının diğer hizmet katmanlarıyla paylaşıldığını ve hızlı trafik artışlarının, trafiğin bir kısmının Standart işlemeye gönderilebileceği artış hızı davranışını tetikleyebileceğini belirtiyor.
- Gerçek: Hizmet katmanı bir raporlama ve faturalandırma boyutu olabilir. OpenAI, API müşterilerinin Kullanım kontrol paneli verilerini hizmet katmanına ve satır öğesine göre gruplandırabileceğini söylüyor. API kullanım raporlamasında hizmet katmanı değerleri olarak antropik belgeler
standart,öncelikvetoplu. - Gerçek: Toplu API'ler, eşzamansız çalışmanın maliyetini önemli ölçüde azaltabilir. Antropik fiyatlandırma belgeleri, Batch API'sinin, giriş ve çıkış jetonlarında %50 indirimle eşzamansız büyük hacimli işlemeyi desteklediğini söylüyor. Google'ın Gemini Batch API belgeleri, bazı yüksek hacimli işler için 24 saate kadar teslim süresi gibi ödünleşimlerle birlikte, standart maliyetin %50'si tutarındaki büyük eşzamansız iş yüklerini açıklamaktadır.
- Gerçek: Tedarik edilen aktarım hızı ayrı bir kapasite modelidir. Microsoft, kapasitenin paylaşıldığı ve verimin talebe göre değişebileceği standart dağıtımların aksine, Azure OpenAI tarafından sağlanan verimi ayrılmış kapasite olarak belgeliyor. Microsoft ayrıca aynı Azure OpenAI kaynağında sağlanan dağıtımlardan standart dağıtımlara yayılmayı da belgeliyor.
Öneri, her sağlayıcı teriminin uygulama koduna yansıtılmamasıdır. Öneri, bu mekanizmaları iş odaklı ağ geçidi katmanlarına göre normalleştirmektir.
Sağlayıcıdan bağımsız ağ geçidi katmanlarını tanımlama
Katmanları satıcı terminolojisine göre değil, iş yükü davranışına göre adlandırarak başlayın. Yararlı bir ilk sınıflandırma şöyledir:
interactive_fastetkileşimli_standartayrılmış_kapasitebackground_discountemergency_fallbackBu seviye listesi kasıtlı olarak küçüktür. Yirmi katman oluşturursanız geliştiriciler sistemi atlayacaktır. Ağ geçidi yine de bir nötr katmanı dahili olarak sağlayıcıya özgü çeşitli mekanizmalarla eşleyebilir.
İstenen katmanı seçilen katmandan ayırın
Arayanın istenen katmanı göndermesi gerekir, ancak ağ geçidinin hem istenen katmanı hem de seçilen gerçek katmanı kaydetmesi gerekir. Bunlar her zaman aynı değildir.
Örnek istek meta verileri:
<ön>Örnek sevk kaydı:
<ön>Artış sınırları veya kiracı bütçe kuralları nedeniyle standart işleme bir prim isteği gönderilirse bunun görünür olması gerekir:
<ön>Bu ayrım, yanıltıcı analizlerin önlenmesini sağlar. Kontrol panelleri yalnızca arayanın istediğini gösteriyorsa finans, prim amacını görecek ancak prim uygulamasını göremeyecektir. Kontrol panelleri yalnızca yukarı akış sonucunu gösteriyorsa ürün ekipleri, gecikmeye duyarlı iş akışlarının premium kapasitesinin ne zaman reddedildiğini bilemez.
Yönlendirmeden önce bir yetenek matrisi oluşturun
Hizmet katmanı yönlendiricisinin bir yetenek matrisine ihtiyacı vardır. Matris şu soruyu yanıtlamalıdır: Belirli bir model, bölge, kiracı ve iş akışı için hangi kapasite mekanizmaları mevcuttur?
Minimum alanlar:
sağlayıcımodel_or_deploymentbölgelersupports_syncsupports_batchsupports_premium_tiersupports_provisioned_capacitysupports_spilloverprovider_tier_valuesbilling_line_itemsbilinen_downgrade_behaviortenant_allowlist
Basitleştirilmiş bir örnek:
gateway_tier_map:
interaktif_fast:
tercih edilen:
- sağlayıcı: openai
request_params:
service_tier: hızlı
- sağlayıcı: antropik
request_params:
service_tier: öncelik
geri dönüş:
- ağ geçidi_katmanı: etkileşimli_standart
izin verilen_zaman: politika.allows_standard_downgrade
arka plan_indirim:
tercih edilen:
- sağlayıcı: antropik
mod: toplu
- sağlayıcı: gemini
mod: toplu
geri dönüş:
- kuyruk: gecikmeli_yeniden deneme
izin verilen_zaman: doğru
ayrılmış_kapasite:
tercih edilen:
- sağlayıcı: azure_openai
dağıtım_sınıfı: temel hazırlığı yapıldı
geri dönüş:
- sağlayıcı: azure_openai
dağıtım_sınıfı: standart
izin verilen_zaman: politika.allows_spilloverBu matris dağınık kod değil, konfigürasyon olmalıdır. Sağlayıcı adlandırma değişiklikleri, bölgesel kullanılabilirlik ve faturalandırma yöntemi zamanla değişecektir. Ağ geçidi politikasını güncellemek, API'yi çağıran her uygulamayı yeniden dağıtmaktan daha güvenlidir.
Kapasiteyi seçmeden önce iş yüklerini sınıflandırın
En zor kısım sağlayıcı eşlemesi değil. Hangi isteklerin hangi seviyeyi hak ettiğine karar veriyor.
interactive_fast
için iyi adaylar
- Gecikmenin konuşmayı böldüğü durumlarda sesli asistanlar.
- Yüksek değerli dönüşüm veya elde tutma yolları hakkında müşteriyle yüz yüze sohbet.
- Bir aracının aktif olarak beklediği döngüdeki insan operasyonları.
- Gecikmenin doğrudan azaltmayı etkilediği üretim olayları.
interactive_standard
için iyi adaylar
- Dahili yardımcı pilotlar.
- İnsanın normal yanıt süresini tolere edebileceği bir yerde taslak hazırlamayı destekleyin.
- Yanıt süresinin önemli olduğu ancak kritik olmadığı ürün özellikleri.
background_discount
için iyi adaylar
- Gecelik özeti.
- Büyük belge zenginleştirme.
- Çevrimdışı değerlendirmeler.
- Toplu yerleştirme yenileniyor.
- Analitik etiketleme ve rapor oluşturma.
reserved_capacity
için iyi adaylar
- Sürekli yüksek hacimli üretim iş yükleri.
- Öngörülebilir üretim taahhütleriyle sözleşmeli müşteri iş yükleri.
- Gürültülü komşu değişkenliğini tolere edemeyen ve ayrılmış kapasiteyi haklı çıkaracak kadar yeterli kullanıma sahip olan trafik.
Basit bir politika kuralı şudur: Arayanların yalnızca hızı tercih ettikleri için premium kapasiteyi seçmelerine izin vermeyin. Beyan edilmiş bir iş akışı, kiracı izni ve bütçe kapsamı zorunlu kılın.
Kiracı ve API anahtarı izinlerini zorunlu kılın
Her kiracı ve API anahtarının izin verilen bir katman kümesi olmalıdır. Yeni anahtarlar varsayılan olarak premium katmanlara değil standart ve arka plan katmanlarına ayarlanmalıdır.
Örnek kiracı politikası:
<ön>Anahtar düzeyinde geçersiz kılma örneği:
<ön>Anahtar düzeyi politikası yanlışlıkla genişletmeyi önler. Bir geliştirici, iş akışına da izin verilmediği sürece, ses trafiğine yönelik bir anahtarı alıp toplu özetleme komut dosyası için kullanamaz.
Sürüm düşürme ve yayılma davranışını açıkça tasarlayın
Sürüm düşürme davranışı yalnızca bir altyapı kararı değil, bir ürün kararıdır. Premium veya sağlanan kapasite kullanılamadığında ağ geçidinin dört yoldan birini seçmesi gerekir:
- Standartlarla ilerleyin: Kullanılabilirliğin gecikme tutarlılığından daha önemli olduğu durumlarda kullanışlıdır.
- Sıra: Arka plan işleri ve toplu iş yükleri için kullanışlıdır.
- Hızlı başarısız olun: Sıkı gerçek zamanlı döngüler gibi, yavaş bir yanıtın yanıt vermemekten daha kötü olacağı durumlarda kullanışlıdır.
- Arayandan yeniden denemesini iste: İstemcinin bir geri alma ve korunan bir geçicilik anahtarıyla güvenli bir şekilde yeniden deneyebildiği durumlarda kullanışlıdır.
Örnek politika:
downgrade_policy:
Voice_control_loop:
istenen_tier: interaktif_hızlı
if_fast_unavailable: başarısız_fast
error_code: tier_capacity_unavailable
customer_support_reply:
istenen_tier: interaktif_hızlı
if_fast_unavailable: devam_on_standard
Record_outcome: notu düşürüldü
nightly_document_enrichment:
request_tier: arka plan_indirim
if_batch_unavailable: kuyruk
max_queue_delay_hours: 24
sözleşmeli_api_müşteri:
request_tier: ayrılmış_kapasite
if_reserved_exhausted: yayılma_to_standard
require_spillover_budget: doğruDökülmeyi gizlemeyin. Yayılma kullanılabilirliği artırabilir ancak maliyeti ve SLO yorumunu değiştirir. Faturalar ve analizler, ayrılmış kapasite talebini, yayılma olayını, gerçekte kullanılan standart kapasiteyi ve nedenini göstermelidir.
Hizmet katmanı yönlendirmesini faturalandırmaya bağlama
Kademe seçimi defterin bir parçası değilse ağ geçidi premium harcamayı kontrol edemez. Bu alanları her istek veya iş için saklayın:
- İstenen ağ geçidi katmanı.
- Seçili sağlayıcı katmanı veya kapasite sınıfı.
- Kademe sonucu: seçildi, düşürüldü, yükseltildi, sıraya alındı, yayılma, reddedildi.
- Sonucun nedeni.
- Kiracı, API anahtarı, kullanıcı ve iş akışı tanımlayıcıları.
- Model takma adı ve yukarı akış modeli veya dağıtımı.
- Gönderim öncesi tahmini maliyet.
- Sağlayıcı kullanımı bilindikten sonra ödenen maliyet.
- Eşzamanlı istekler için gecikme ve yeniden deneme sayısı.
- Eşzamansız işler için toplu gönderim süresi, tamamlanma süresi ve sonuç alım durumu.
Bu alanlarla ağ geçidi, finans ve mühendisliğin soracağı soruları yanıtlayabilir:
- Bu hafta hangi kiracılar premium kapasiteyi kullandı?
- En fazla prim harcamasına hangi iş akışları neden oldu?
- Premium isteklerinin düzeyi ne sıklıkla standarda geriledi?
interactive_fast, p95 gecikmesini premium'u haklı çıkaracak kadar iyileştirdi mi?- Senkronize standart işlemeyle karşılaştırıldığında arka planda toplu işleme ne kadar tasarruf sağladı?
- Tedarik edilen kapasite ne kadar standart yayılım oluşturdu?
Önemli öneri: Operasyonel bağlam için istenen katmanı görüntülerken, kullanılan gerçek katmanı faturalayın. Aksi takdirde kiracılar ya maliyet konusunda şaşıracak ya da hizmet kalitesi konusunda yanıltılacaktır.
Premium'un varsayılan hale gelmemesi için korkuluklar ekleyin
Ekipler daha hızlı bir seviye keşfettiklerinde onu aşırı kullanabilirler. Geniş kullanıma sunmadan önce ağ geçidine sınırlar koyun.
- Kiracı prim bütçesi: Sabit aylık ve günlük tavanlar.
- İş akışı onayı: Premium'a yalnızca adlandırılmış iş akışları için izin verilir.
- Trafik paylaşımı sınırı: Örneğin, bir kiracının eşzamanlı isteklerinin %10'undan fazlası onay olmadan
interactive_fast'ı kullanamaz. - Standarttan premium'a uyarı: Normalde standart kullanan bir iş akışı yükseltildiğinde uyarı verir.
- Premium yakma hızı uyarısı: Tahmini harcama, onaylanan sınırı aştığında uyarı verir.
- Otomatik süre sonu: Geçici acil durum geçersiz kılma işlemlerinin süresi, manuel temizleme olmadan sona ermelidir.
- Toplu uygunluk kontrolleri: Toplu iş ölçütlerini karşıladıkları takdirde eşzamanlı premium katmanlardaki toplu işleri engelleyin.
Korkuluklar ters çevrilebilir olmalıdır. Bir olay sırasında, yetkili bir operatörün geçici bir prim geçersiz kılma izni vermesi gerekebilir. Bu geçersiz kılmanın bir nedeni, onaylayanı, bütçesi, son kullanma tarihi ve denetim kaydı bulunmalıdır.
Uygulama sırası
Güvenli bir kullanıma sunma, premium yönlendirmenin her yerde etkinleştirilmesiyle başlamaz. Ölçümle başlayın.
1. Gölge katmanı sınıflandırmasını ekleyin
Her isteği önerilen bir ağ geçidi katmanına göre sınıflandırın ancak yönlendirmeyi henüz değiştirmeyin. Önerilen katmanı mevcut gecikme, maliyet ve iş akışı meta verilerinin yanına kaydedin. Bu, politikanın uygulanması durumunda ne kadar trafiğin premium, toplu veya ayrılmış kapasiteye taşınacağını gösterir.
2. Yetenek matrisini oluşturun
Sağlayıcı mekanizmalarını, desteklenen modelleri, bölgeleri, sınırları, raporlama alanlarını ve bilinen sürüm düşürme davranışlarını listeleyin. Bilinmeyen sürüm düşürme davranışlarını, test edilene kadar risk olarak değerlendirin.
3. Prova modunda kiracı izinlerini zorunlu kılın
Her isteğe izin verilip verilmeyeceğini, eski sürüme geçirilip geçirilmeyeceğini, kuyruğa alınacağını veya reddedileceğini günlüğe kaydedin. Yaptırım uygulanmadan önce sonuçları ürün sahipleriyle paylaşın.
4. Bir grup için bir katmanı etkinleştirin
Canlı destek yanıt yolu veya gecelik özetleme işi gibi dar bir iş akışı seçin. Küçük bir kiracı grubu için ilgili ağ geçidi katmanını etkinleştirin. Mümkün olduğunda p50 gecikmesini, p95 gecikmesini, maliyetini, sürüm düşürme oranını, hata oranını ve kullanıcıya yönelik iş metriklerini ölçün.
5. Yalnızca veriler desteklediğinde genişletin
Premium katman gecikmeyi artırıyor ancak ürün sonuçlarını iyileştirmiyorsa bunu sınırlı tutun. Toplu işleme, ürün davranışına zarar vermeden maliyeti düşürüyorsa genişletin. Tedarik edilen kapasite boşta kalırsa taahhüdü tekrar gözden geçirin veya buna daha fazla öngörülebilir trafik yönlendirin.
Açık bir şekilde ifade etmek için ödünler
- Düşük gecikme süreli premium katmanlar yanıt verme hızını artırabilir ancak hız sınırlarını paylaşabilir veya rampa kısıtlamalarını tetikleyebilirler. Bunlar, oran sınırı şekillendirmenin yerine geçmez.
- Tedarik edilen kapasite öngörülebilirliği artırır ancak kullanım düşük olduğunda para israfına neden olabilir. Ani veya gecikmeye toleranslı trafik için standart veya toplu kapasite daha iyi olabilir.
- Toplu işleme belirteç maliyetini azaltabilir ancak yanıtlar eşzamansız olduğundan ve çok daha sonra gelebileceğinden ürün davranışını değiştirir.
- Sağlayıcıdan bağımsız katman adları uygulama kodunu basitleştirir ancak sağlayıcılar farklı adlar, sınırlar, faturalandırma satırları ve sürüm düşürme davranışı kullandığından ağ geçidinin güncel bir yetenek matrisi sağlaması gerekir.
- Otomatik sürüm düşürme, kullanılabilirliği artırır ancak ağ geçidi, kullanılan gerçek katmanı kaydetmediği sürece SLO ve faturalandırma beklentilerini bulanıklaştırabilir.
- Katı kiracı kontrolleri sürpriz harcamaları önler ancak aşırı katı politikalar, kontrollü bir geçersiz kılma yolu olmadığı sürece acil üretim iş akışlarını engelleyebilir.
Tahmin: Hizmet katmanı birinci sınıf bir yönlendirme boyutu haline gelecek
Tahmin: Model API'leri olgunlaştıkça hizmet katmanı, AI yönlendirme açısından model seçimi, bölge ve bağlam penceresi kadar önemli hale gelecektir. Takımlar sadece “buna hangi model cevap vermeli?” diye sormayacaklar. "Hangi model, hangi kapasite sınıfı altında, hangi kiracı bütçesi için, hangi not düşürme politikasıyla?" diye soracaklar.
Öneri: Ağ geçidi defterini ve politika modelini şimdi, uygulama kodunu değiştirmeden yeni sağlayıcı kapasite sınıflarının eklenebileceği şekilde tasarlayın. Yalnızca standart ve toplu iş ile başlasanız bile, başlangıçtan itibaren requested_gateway_tier, selected_provider_tier ve tier_outcome gibi alanları kullanın.
Uygulanabilir kontrol listesi
- Sağlayıcıdan bağımsız en fazla beş ağ geçidi katmanı tanımlayın.
- Her API anahtarının hangi katmanları ve iş akışlarını kullanabileceğini beyan etmesini zorunlu kılın.
- Premium, standart, temel hazırlık, toplu ve yayılma davranışı için bir sağlayıcı yetenek matrisi oluşturun.
- İstenen katmanı, seçilen katmanı, sürüm düşürme veya yayılma sonucunu, gecikmeyi, kullanımı ve kararlaştırılan maliyeti kaydedin.
- Standart veya arka plan katmanlarına ilişkin varsayılan yeni anahtarlar.
- Premium bütçeler, trafik paylaşımı sınırları ve uyarılar ekleyin.
- İş akışına göre sürüm düşürme davranışını açıkça belirtin.
- Uygulamadan önce gölge metrikleriyle başlayın.
- Premium veya tedarik edilen kapasiteyi önce küçük bir gruba sunun.
- Yalnızca gecikme, güvenilirlik veya iş ölçümleri maliyeti haklı çıkardığında genişletin.
Sonuç
Hizmet katmanı yönlendirmesi, kesişen bir politika kararı olduğundan AI API ağ geçidine aittir. Gecikmeyi, maliyeti, kotaları, kiracı izinlerini, faturaları ve operasyonel beklentileri etkiler. Uygulama ekipleri, yalnızca iş yükünün aciliyetini ifade etmek için sağlayıcıya özel katman adlarını veya dağıtım sınıflarını sabit kodlamamalıdır.
Pratik bir ağ geçidi, interactive_fast, interactive_standard, reserved_capacity ve background_discount gibi tarafsız katmanları ortaya çıkarır. Bu katmanları sağlayıcıya özgü mekanizmalarla eşleştirir, kiracı izinlerini zorunlu kılar, gerçek sonucu kaydeder ve premium kapasitesini varsayılan yol yerine kasıtlı bir istisna haline getirir.