Hız Sınırına Duyarlı Yapay Zeka API Ağ Geçitleri: RPM'yi, TPM'yi, Patlamaları ve Kiracı Adilliğini 429'lar Vurmadan Önce Şekillendirin
LLM API 429'ların basamaklandırılmasını önlemek için pratik bir ağ geçidi mimarisi: sağlayıcı sınırlarını normalleştirin, dağıtımdan önce jeton basıncını tahmin edin, kiracıya göre kota ayırın, trafik rampalarını düzeltin ve kısıtlamayı denetlenebilir hale getirin.
LLM sağlayıcısından gelen 429 yalnızca bir yeniden deneme sinyali değildir. Üretim aşamasında bu genellikle uygulamanızın kabul, kiracı adaleti, gecikme veya sağlayıcıya özel kota hesaplaması kontrolünü kaybettiğinin kanıtıdır.
Genel çözüm olan üstel geri çekilme gerekli ancak eksik. Geri çekilme, sağlayıcı trafiği reddettikten sonra tepki verir. Hız sınırına duyarlı bir AI API ağ geçidi, istekler sisteminizden ayrılmadan önce trafiği şekillendirmelidir: jeton basıncını tahmin edin, kotayı ayırın, kiracıları izole edin, doğru işi kuyruğa alın, yanlış işi reddedin ve sağlayıcı sınırları değiştiğinde uyum sağlayın.
Bu makalede, üretim iş yüklerini birden fazla LLM sağlayıcısına birleştirilmiş bir API aracılığıyla gönderen ekipler için pratik bir ağ geçidi kota düzenleyicisi açıklanmaktadır.
Okuyucu sorunu: 429'lar çok boyutludur
Birçok ekip, hız sınırlarını dakika başına tek bir istek sayısıymış gibi ele alır. Bu varsayım, LLM API'leriyle hızla bozuluyor.
Mevcut sağlayıcı belgelerinden gerçekler:
- Sınırlama yapan OpenAI belgeleri, reklamı yapılan dakika başına sınırdan daha kısa pencerelerde uygulanabilir; dolayısıyla, ortalama dakika güvenli görünse bile kısa patlamalar başarısız olabilir.
- Azure OpenAI kotası abonelik, bölge, model ve dağıtım türüne göre dakika başına belirteç olarak atanır. Bir dağıtıma TPM atamak, zorunlu çıkarım RPM sınırlarını da belirler ve RPM-TPM oranları modele göre değişir.
- Azure OpenAI ayrıca hız sınırı belirteci hesaplamalarının istek alındığında tahmin edildiğini ve nihai faturalandırma belirteci sayımlarıyla aynı olmadığını belirtiyor.
- Antropik belgeler dakika başına istek, dakika başına giriş jetonu ve dakika başına çıkış jetonu sınırlarını ayırır. Sınırların aşılması, yeniden deneme sonrası başlığıyla birlikte 429 sonucunu döndürür.
- Anthropic, keskin trafik artışlarının hızlanma sınırlarını aşabileceği konusunda uyarıyor ve kademeli olarak artışı öneriyor.
- Çoğu Claude modelinde, giriş jetonlarını önbelleğe alan Antropik belgeler, dakika başına giriş jetonu sınırlarına dahil edilmez; bu, hızlı önbelleğe almanın etkin boşluğu değiştirebileceği anlamına gelir.
- Google Gemini API ücret sınırları proje kullanım katmanlarına bağlıdır; daha yüksek katmanlar faturalandırma kurulumuna, kümülatif harcamaya ve ödeme aşamalarından sonra geçen süreye bağlıdır.
Operasyonel ders açıktır: OpenAI uyumlu bir istek şekli, OpenAI uyumlu kota davranışı anlamına gelmez. Çok sağlayıcılı bir ağ geçidinin "429 ise yeniden dene"den daha zengin bir dahili kota modeline ihtiyacı vardır.
Tasarım hedefi: giriş kontrolünü bir ağ geçidi sorumluluğu haline getirmek
Hız sınırına duyarlı bir ağ geçidinin, bir isteği göndermeden önce beş soruyu yanıtlaması gerekir:
- İsteği hangi sağlayıcı, model, dağıtım, bölge, proje veya çalışma alanı alacak?
- Ne kadar istek, giriş jetonu, çıkış jetonu ve eşzamanlılık kapasitesi tüketebilir?
- Paylaşılan kapasite karşılığında hangi kiracı, ekip, API anahtarı, müşteri veya iş yükü sınıfı ücretlendirilmelidir?
- İstek şimdi kabul edilmeli mi, kısa süreliğine kuyruğa alınmalı mı, eski sürüme geçirilmeli mi, başka bir yere yönlendirilmeli mi yoksa reddedilmeli mi?
- Sağlayıcı gerçek kullanımı iade ettikten sonra rezervasyonun mutabakatı nasıl yapılmalıdır?
Ağ geçidi kota yöneticisi haline gelir. Sağlayıcı limitlerinin yerine geçmez. Sağlayıcı sınırlarını kendi sisteminizde görünür, öngörülebilir ve adil hale getirir.
Normalleştirilmiş bir kota modeli oluşturma
Büyük sağlayıcıları tek bir yanıltıcı gruba zorlamadan temsil edebilecek dahili sınırlayıcı boyutları tanımlayarak başlayın.
Önerilen sınırlayıcı boyutları
- BGBG: dakika başına istek.
- TPM'yi girin: dakika başına bilgi istemi, mesaj, araç ve bağlam belirteçleri.
- Çıktı TPM'si: dakika başına tamamlama jetonları, akış ve uzun nesiller için ayrı olarak ayrılmıştır.
- Toplam TPM: birleşik belirteç baskısını ortaya çıkaran sağlayıcılar veya dağıtımlar için kullanışlıdır.
- Eşzamanlılık: etkin istekler, etkin akışlar veya devam eden işler.
- Akış süresi: Uzun ömürlü akışlar, RPM düşük olduğunda bile bağlantıyı ve çıkış jetonu boşluğunu işgal edebilir.
- Sağlayıcıya özel kapsam: Azure aboneliği/bölgesi/dağıtım, Antropik çalışma alanı/model sınıfı, Google projesi/katmanı veya OpenAI kuruluşu/projesi/model grubu.
Sağlayıcıya özel boyutları gizlemeyin. Bunları ortak bir şema halinde normalleştirin ancak daha sonra reddedilmeyi açıklamak için yeterli ayrıntıyı koruyun.
<ön>Bu dahili nesne, yalnızca model adlarından çıkarılmamalı, açıkça yapılandırılmalıdır. Sağlayıcı kontrol panelleri, hesap katmanları, bölgesel dağıtımlar ve çalışma alanı ayarlarının tümü aynı model ailesinin etkin kapasitesini değiştirebilir.
Göndermeden önce jeton basıncını tahmin edin
Sağlayıcı tarafı ücret sınırlaması genellikle nihai faturalandırma kullanımı bilinmeden önce gerçekleşir. Ağ geçidiniz, trafiği göndermeden önce aynı tür ihtiyatlı tahminde bulunmalıdır.
Ön kontrol rezervasyon girişleri
- Serileştirilmiş istem ve mesaj uzunluğu.
- Roller, araçlar, görüntüler veya yapılandırılmış çıktı talimatları için modele özgü simgeleştirme ve ek yük.
max_completion_tokensveya eşdeğer çıktı sınırı.- Bu uç nokta, kiracı, model profili ve istek sınıfı için geçmiş tamamlanma oranı.
- Hızlı önbelleğe almanın mevcut ve ölçülebilir olması durumunda beklenen önbellek okuma belirteçleri.
- Akış bayrağı ve beklenen yayın süresi.
Başlamak için genellikle basit bir rezervasyon kuralı yeterlidir:
estimated_input_tokens = tokenize(request_messages) + model_overhead
tahmin edilen_output_tokens = dk(
max_completion_tokens,
p95_historical_output_tokens_for_route
)
Reserved_total_tokens = tahmin edilen_input_tokens + tahmin edilen_output_tokensBilinmeyen rotalar için ihtiyatlı bir varsayılan kullanın. Sabit üretim rotaları için tahminleri sürekli olarak fiili kullanımdan güncelleyin.
Rezervasyon yapın ve ardından mutabakat sağlayın
Kota rezervasyonları kalıcı ücretlere dönüşmemelidir. Bunlara muhafaza gibi davranın:
- Alıntı: giriş ve çıkış basıncını tahmin edin.
- Rezervasyon: gönderilmeden önce ilgili jeton paketlerinden düşülür.
- Anlaşın: mümkün olduğunda tahmini, sağlayıcı tarafından bildirilen kullanımla değiştirin.
- Geri ödeme veya borçlandırma: Kullanılmayan ayrılmış kapasiteyi iade edin veya gerekirse aşım ücretlerini bir sonraki pencereye bırakın.
Bu, en çok uzun bağlamlı ve akışlı aramalar için önemlidir. Göndermeden önce yalnızca giriş TPM'sini kontrol ederseniz, bir akış başarılı bir şekilde başlatılabilir ve daha sonra çıkış jetonu basıncına maruz kalabilir. Çıkış boşluğunu ayrı ayrı ayırmak, orta akış arızasını ve durma riskini azaltır.
Kiracı adaleti için hiyerarşik jeton gruplarını kullanın
Tek bir genel sınırlayıcı, sağlayıcı hesabını korur ancak kiracıları birbirinden korumaz. Uzun bağlamlı bir toplu iş, paylaşılan TPM'yi tüketebilir ve diğer ekiplerden gelen etkileşimli isteklerin başarısız olmasına neden olabilir.
Hiyerarşik jeton gruplarını kullanın:
organizasyon
└── kiracı
└── takım
└── api_key
└── model_profile
└── sağlayıcı_deploymentBir isteğin ilgili her gruptan geçmesi gerekir. Bu, aynı anda birden fazla politikayı uygulamanıza olanak tanır:
- Kuruluş, sağlayıcı kapasitesini aşamaz.
- Kiracı, sözleşmeye konu olan payından fazlasını tüketemez.
- Bir API anahtarı, amaçlanan ortamı veya uygulama sınırını aşamaz.
- Bir toplu model profili, etkileşimli bir model profilini aç bırakamaz.
- Başka bir dağıtımın yedek kotası olsa bile sağlayıcı dağıtımı aşırı yüklenemez.
Adil paylaşım ve kullanım karşılaştırması
Öneri: kontrollü hızlı borçlanma ile ağırlıklı adil paylaşımı kullanın.
Kiracı başına katı üst sınır değerlerinin açıklanması kolaydır ancak kullanılmayan kapasitenin kısıtlanmasına neden olabilir. Ani ödünç alma, kiracının paylaşılan bir havuzdaki boş kotayı geçici olarak kullanmasına izin vererek kullanımı artırır. Aradaki tercih karmaşıktır: Kontrol panelleri neyin garanti edildiğini, neyin ödünç alındığını ve ödünç almanın ne zaman iptal edildiğini göstermelidir.
Pratik bir kural:
- Her kiracıya garantili bir temel verin.
- Kullanılmayan paylaşılan kapasiteden seri ödünç almaya izin verin.
- Daha yüksek öncelikli veya garantili trafik göründüğünde ödünç alınan kapasiteyi geri alın.
- Ödünç alınan trafiğin garantili trafik için sağlayıcı düzeyinde 429'lar oluşturmasına asla izin vermeyin.
Trafik sınıflarını çekişmeden önce ayırın
Tüm istekler aynı kuyruk davranışını hak etmez. Trafiği, ayrı kuyruklara ve kota havuzlarına sahip model profillerine yerleştirin.
Kuyruğa alma başarı oranını artırır ancak kuyruk gecikmesini artırır. Bir ağ geçidi bu ödünleşimi açıkça ortaya koymalıdır. Örneğin, etkileşimli bir istek kota için 300 milisaniyeye kadar bekleyebilir, ardından geri çekilebilir veya başarısız olabilir. Gecelik bir toplu iş 20 dakika bekleyebilir ve yine de başarılı sayılabilir.
429'ları tek bir hata şeması halinde normalleştirin
İyi bir giriş kontrolü olsa bile sağlayıcı 429'lar yine de ortaya çıkacaktır. Sınırlar değişebilir, sağlayıcı tahminleri sizinkinden farklı olabilir ve trafik beklenenden daha keskin artışlarla gelebilir.
Her sağlayıcıyı 429 bir ağ geçidi hata nesnesine normalleştirin:
<ön>Anahtar alan gateway_decision'dur. Ağ geçidinin isteği kabul etmesinden sonraki bir 429, ağ geçidinin gönderilmeden önce yerel olarak reddettiği istekten farklıdır. Birincisi sınırlayıcı kalibrasyon problemini gösterir. İkincisi kasıtlı korumayı belirtir.
Sağlayıcı başlıklarından uyarlayın ancak bunlara bağlı kalmayın
Bazı sağlayıcılar, yeniden deneme veya kalan kapasite göstergeleri gibi yararlı başlıklar döndürür. Mümkün olduğunda bunları kullanın.
Öneri: Sağlayıcı başlıkları yerel yöneticinizi değiştirmeli, onun yerine geçmemelidir.
Nedenler:
- Başlığın kullanılabilirliği sağlayıcıya ve uç noktaya göre farklılık gösterir.
- Başlıklar her sınırlayıcı boyutu göstermeyebilir.
- Sonra yeniden deneme size bir sonraki adımda hangi kiracının kapasiteye sahip olması gerektiğini değil, ne zaman tekrar denemeniz gerektiğini söyler.
- Sağlayıcı tarafı jeton tahminleri faturalandırmanızdan veya dahili muhasebenizden farklı olabilir.
Güçlü bir uygulama, yerel paket doldurma oranlarını ve bekleme sürelerini başlıklara göre güncellerken aynı zamanda ağ geçidi içinde kiracı, API anahtarı, trafik sınıfı ve sağlayıcı dağıtım sınırlarını uygulamaya devam eder.
Taşıma işlemleri ve planlanmış işler için rampa düzenleyicileri ekleyin
Planlanan değişiklikler sırasında birçok hız sınırı olayı meydana gelir: bir modelden diğerine geçiş, sağlayıcıların değiştirilmesi, yeni bir aracı iş akışının etkinleştirilmesi veya planlanmış bir değerlendirme çalışmasının başlatılması.
Öneri: Trafik artışını kontrollü bir kullanıma sunma olarak değerlendirin.
- Kiracıya, rotaya veya trafik yüzdesine göre özellik işaretleme modeli geçişleri.
- Yeni sağlayıcı dağıtımları için dakika başına büyüme tavanları belirleyin.
- Tüm trafiği anında değiştirmek yerine trafiği saatler içinde kademeli olarak ısıtın.
- 429 hızı, sürüm düşürme oranı, kuyruk derinliği veya p95 gecikmesi bir eşiği aştığında kullanıma sunmayı duraklatın.
- Yalnızca yedek bir model değil, bir uyumluluk politikasıyla acil durum geri alma rotasını koruyun.
Tahmin: Sağlayıcı yönlendirme modları, öncelik katmanları ve çalışma alanı düzeyindeki kontroller daha yaygın hale geldikçe, rampa yönetimi bir olay-yanıt komut dosyası yerine standart bir ağ geçidi özelliği haline gelecektir.
Geri çekilme yalnızca bir kapasite kararı değil, bir politika kararıdır
Bir sağlayıcı 429 döndürdüğünde, başka bir sağlayıcıya yönlendirmek doğru yanıt olabilir. Ayrıca güvenli olmayabilir.
Geri dönüş değişebilir:
- Çıktı kalitesi ve talimat takibi.
- Bağlam uzunluğu.
- Araç çağırma davranışı.
- Yapılandırılmış çıktı güvenilirliği.
- Veri saklama ve ikamet durumu.
- Maliyet ve gecikme.
Kota yöneticisi, bir uyumluluk katmanına bu istek sınıfı için geri dönüşe izin verilip verilmediğini sormalıdır. Aksi halde anlambilimi sessizce değiştirmek yerine net bir yerel hız sınırı yanıtıyla sıraya girmeli veya başarısız olmalıdır.
Kararları açıklayan kota kontrol panellerini kullanıma sunun
Kimsenin anlayamadığı bir kota sistemi aşılacak. Operasyonel sorular etrafında kontrol panelleri oluşturun:
- Hangi kiracılar en fazla RPM'yi, giriş TPM'sini ve çıkış TPM'sini tüketiyor?
- Hangi model profilleri sıraya giriyor, reddediliyor veya geri çekiliyor?
- Hangi sağlayıcı kapsamı darboğazdır: proje, bölge, dağıtım, çalışma alanı, model sınıfı veya hesap katmanı?
- Ağ geçidi tahminleri sağlayıcı kullanımından ne sıklıkla farklılık gösterir?
- Sağlayıcıya ve sınırlayıcı türüne göre yeniden deneme dağıtımı nedir?
- İstemli önbellek okumaları ne kadar etkili boşluk payı yaratıyor?
- Hangi trafik sınıfları patlama kapasitesini ödünç alıyor?
Müşteriye veya iş ortağına yönelik ürünler için güvenli kontrolleri ortaya çıkarın:
- Anahtar başına hız sınırları.
- Takım başına ani artış sınırları.
- Müşteri başına günlük sınırlar.
- Kiracı veya anahtar için acil durum duraklaması.
- 429 ani artış, sıra büyümesi ve anormal token baskısı için uyarılar.
- Bayi kotası yönetimi için iş ortağı API uç noktaları.
Bu, hız sınırlamasını gizemli bir sağlayıcı hatası olmaktan çıkarıp ekip API yönetiminin denetlenebilir bir parçası haline getiriyor.
Uygulama kontrol listesi
Aşama 1: gözlemleyin ve sınıflandırın
- Her çağrı için günlük sağlayıcı, model, dağıtım, bölge, çalışma alanı, proje, kiracı, API anahtarı ve istek sınıfı.
- Sağlayıcı 429'ları yeniden deneme ve ham hata meta verileriyle yakalayın.
- Tahmini ve gerçek giriş/çıkış jetonlarını ayrı ayrı kaydedin.
- Telemetride etkileşimli, toplu, değerlendirme ve arka plan trafiğini ayırın.
2. Aşama: yerel giriş kontrolü
- RPM, giriş TPM'si, çıkış TPM'si, toplam TPM ve eşzamanlılık için dahili sınırlayıcı nesneler oluşturun.
- Ön kontrol jetonu tahminini ekleyin.
- Kotayı göndermeden önce ayırın ve sağlayıcı kullanımı geldikten sonra mutabakat sağlayın.
- Bir istek, kiracı veya sağlayıcı paketine sığamadığında yerel olarak reddedin.
Aşama 3: adalet ve kuyruklar
- Kuruluştan sağlayıcı dağıtımına hiyerarşik paketler ekleyin.
- Garantili kiracı hisselerini ve kontrollü seri borçlanmayı atayın.
- Trafik sınıfına göre ayrı kuyruklar oluşturun.
- Sınıfa özgü maksimum bekleme sürelerini ve geri dönüş kurallarını ayarlayın.
4. Aşama: adaptasyon ve operasyonlar
- Bekleme sürelerini ayarlamak ve varsayımları yeniden doldurmak için sağlayıcı başlıklarını kullanın.
- Taşıma işlemleri ve planlanmış işler için rampa düzenleyicileri ekleyin.
- Kota kontrol panellerini ve uyarıları kullanıma çıkarın.
- Tahmin hatasını ve atılan kotayı haftalık olarak inceleyin.
Harekete geçirilebilir sonuç
Ağ geçidiniz yalnızca 429'ları yeniden denerse, hatadan sonra çalışıyor demektir. Üretim düzeyinde bir AI API ağ geçidi, kimin neyi, ne zaman ve hangi sağlayıcı kotasına göre göndermesine izin verildiğine karar vererek çoğu hız sınırı hatasını önlemelidir.
Normalleştirilmiş bir sınırlayıcı model, ön kontrol belirteci rezervasyonu ve trafik sınıfı kuyruklarıyla başlayın. Daha sonra hiyerarşik kiracı adaletini, sağlayıcı-başlık uyumunu ve rampa yöneticilerini ekleyin. Sonuç sadece 429 sayısının azalması değil. Mühendislik, finans ve müşteri destek ekiplerinizin gerçekte açıklayabileceği daha net kapasite tahsisi, daha öngörülebilir gecikme, daha güvenli geçişler ve oran sınırı davranışıdır.