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 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 muhasebesi 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 sıraya koyun, 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 çok LLM sağlayıcısına birleşik bir API.

Okuyucu sorunu: 429'lar çok boyutludur

Birçok ekip, hız sınırlarını sanki dakika başına tek bir istek sayısıymış gibi ele alır. LLM API'lerinde bu varsayım hızla bozuluyor.

Mevcut sağlayıcı belgelerinden gerçekler:

• OpenAI Sınırlandırma yapan belgeler, 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 jeton cinsinden atanır. Bir dağıtıma TPM atamak aynı zamanda zorunlu çıkarım RPM sınırlarını da belirler ve RPM-TPM oranları modele göre değişir.
• Azure OpenAI ayrıca, ücret 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ı da belirtir.
• Anthropic; dakika başına istek, dakika başına giriş jetonu ve dakika başına çıkış jetonu sınırlarını ayrı ayrı belgeler. Limitlerin aşılması, retry-after başlığına sahip bir 429 sonucunu döndürür.
• Anthropic, keskin trafik artışlarının hızlanma sınırlarına ulaşabileceği konusunda uyarıyor ve kademeli olarak artışı öneriyor.
• Çoğu Claude modeli için Anthropic, önbellek okumalı giriş jetonlarını içeren belgeler, dakika başına giriş jetonu sınırlarına dahil edilmez; bu, istemi ö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 ayarlarına, kümülatif harcamaya ve ödeme aşamalarından sonra geçen süreye bağlıdır.

İşlemsel 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 getirin

Hız sınırına duyarlı bir ağ geçidinin, istek göndermeden önce beş soruyu yanıtlaması gerekir:

1. İsteği hangi sağlayıcı, model, dağıtım, bölge, proje veya çalışma alanı alacak?
2. Ne kadar istek, giriş jetonu, çıkış jetonu ve eşzamanlılık kapasitesi tüketebilir?
3. Paylaşılan kapasite karşılığında hangi kiracı, ekip, API anahtar, müşteri veya iş yükü sınıfı ücretlendirilmelidir?
4. İ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?
5. 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şturun

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ı

• RPM: istek/dakika.
• TPM'yi girin: dakika başına istem, mesaj, araç ve bağlam belirteçleri.
• Çıktı TPM'si: dakika başına tamamlama jetonu, akış ve uzun nesiller için ayrı olarak ayrılmıştır.
• Toplam TPM: birleşik jeton baskısını açığa çı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.
• Yayın süresi: Uzun ömürlü akışlar, RPM düşük olduğunda bile bağlantıyı ve çıkış belirteci boşluğunu işgal edebilir.
• Sağlayıcıya özel kapsam: Azure aboneliği/bölge/dağıtım, Anthropic çalışma alanı/model sınıfı, Google proje/katman veya OpenAI kuruluş/proje/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.

{
  "provider": "provider_a",
  "model_profile": "fast-chat",
  "provider_scope": {
    "project": "prod",
    "region": "us-east",
    "deployment": "chat-large-01"
  },
  "limits": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "concurrency": 200
  }
}

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 son 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, resimler veya yapılandırılmış çıktı talimatları için modele özel jetonlaştırma ve ek yük.
• max_completion_tokens veya eşdeğer çıktı sınırı.
• Bu uç nokta, kiracı, model profili ve istek sınıfı için geçmiş tamamlanma oranı.
• İstemli önbelleğe alma mevcut ve ölçülebilirse, beklenen önbellek okuma belirteçleri.
• Yayın 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
estimated_output_tokens = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
reserved_total_tokens = estimated_input_tokens + estimated_output_tokens

Bilinmeyen rotalar için ihtiyatlı bir varsayılan kullanın. Sabit üretim rotaları için tahminleri sürekli olarak gerçek 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:

1. Alıntı: giriş ve çıkış basıncını tahmin edin.
2. Rezerv: Gönderimden önce ilgili jeton paketlerinden düşülür.
3. Yerleştir: mümkün olduğunda tahmini, sağlayıcı tarafından bildirilen kullanımla değiştirin.
4. Geri ödeme veya borçlandırma: gerekirse kullanılmayan ayrılmış kapasiteyi iade edin veya aşım ücretlerini bir sonraki pencereye bırakın.

Bu, en çok uzun içerikli 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 paketlerini kullanın

Tek bir genel sınırlayıcı, sağlayıcı hesabını korur ancak kiracıları birbirlerinden 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 paketlerini kullanın:

organization
  └── tenant
      └── team
          └── api_key
              └── model_profile
                  └── provider_deployment

Bir 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şmeli payından fazlasını tüketemez.
• Bir API anahtarı, amaçlanan ortamı veya uygulama sınırını aşamaz.
• Toplu model profili, etkileşimli 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ıma karşı

Öneri: kontrollü seri borçlanma ile ağırlıklı adil paylaşımı kullanın.

Kiracı başına katı sınırların açıklanması kolaydır ancak kullanılmayan kapasiteyi zora sokabilir. 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 ver.
• 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.

Sıraya 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:

{
  "error": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "fast-chat",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interactive",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": false,
    "trace_id": "trace_abc"
  }
}

Anahtar alan gateway_decision'dır. 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, değiştirmemelidir.

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 seferde hangi kiracının kapasiteye ulaşması 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çindeki 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 taşıma işlemleri.
• Yeni sağlayıcı dağıtımları için dakika başına büyüme tavanlarını belirleyin.
• Tüm trafiği anında değiştirmek yerine, trafiği saatler içinde kademeli olarak ısıtın.
• 429 oranı, sürüm düşürme oranı, sıra derinliği veya p95 gecikmesi bir eşiği aştığında sunumu duraklatın.
• Yalnızca yedek bir model değil, uyumluluk politikasıyla acil bir geri alma rotası tutun.

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 cevap olabilir. Ayrıca güvenli olmayabilir.

Yedek değişiklik yapılabilir:

• Çı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 duruşu.
• Maliyet ve gecikme.

Kota yöneticisi, uyumluluk katmanına bu istek sınıfı için geri dönüşe izin verilip verilmediğini sormalıdır. Değilse, 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 BGBG, giriş TPM'si 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ı 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 jeton baskısı için uyarılar.
• İş Ortağı API bayi kotası yönetimi için uç noktalar.

Bu, hız sınırlamayı gizemli bir sağlayıcı hatası olmaktan çıkarıp API ekibinin yönetişiminin denetlenebilir bir parçası haline getirir.

Uygulama kontrol listesi

1. Aşama: gözlemleme ve sınıflandırma

• Günlük sağlayıcı, model, dağıtım, bölge, çalışma alanı, proje, kiracı, API anahtarı ve her çağrı için 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 uymadığında yerel olarak reddet.

3. Aşama: adalet ve kuyruklar

• Kuruluştan sağlayıcı dağıtımına hiyerarşik paketler ekleyin.
• Garantili kiracı paylaşımlarını 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 işlemler

• 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ı gösterin.
• 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üzeyindeki 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çıklayabildiği daha net kapasite tahsisi, daha öngörülebilir gecikme, daha güvenli geçişler ve hız sınırı davranışıdır.

İlgili okuma

• ön kontrol rezervasyonu ve kullanım mutabakatı
• istem önbellek hesaplaması ve önbellek isabeti Analytics
• uyumlu yedek yönlendirme politikaları