Gateway-uri API AI cu limitele ratei: forma RPM, TPM, rafale și corectitudinea chiriașilor înainte de atingerea 429s

A 429 de la un furnizor LLM nu este doar un semnal de reîncercare. În producție, este adesea o dovadă că aplicația dvs. a pierdut deja controlul asupra admiterii, echității chiriașilor, latenței sau contabilității cotelor specifice furnizorului.

Remedierea obișnuită – retragerea exponențială – este necesară, dar incompletă. Backoff-ul reacţionează după ce furnizorul respinge traficul. Un gateway API AI care știe limitele de rată ar trebui să modeleze traficul înainte ca solicitările să părăsească sistemul dvs.: estimați presiunea jetonului, rezervați cota, izolați chiriașii, puneți în coadă lucrările potrivite, respingeți lucrarea greșită și adaptați atunci când limitele furnizorului se modifică.

Acest articol descrie un guvernator practic de cotă de gateway pentru echipele care trimit sarcini de lucru de producție către mai mulți furnizori LLM printr-un API unificat.

Problema cititorului: 429-urile sunt multidimensionale

Multe echipe tratează limitele ratelor ca și cum ar fi un singur număr de solicitări pe minut. Această presupunere se rupe rapid cu API-urile LLM.

Fapte din documentația curentă a furnizorului:

• OpenAI documentează că limitele pot fi aplicate în ferestre mai scurte decât limita pe minut anunțată, astfel încât rafale scurte pot eșua chiar și atunci când minutul mediu pare sigur.
• Cota Azure OpenAI este alocată în funcție de abonament, regiune, model și tip de implementare în token-uri pe minut. Atribuirea TPM unei implementări determină, de asemenea, limitele RPM de inferență impuse, iar rapoartele RPM-TPM variază în funcție de model.
• Azure OpenAI observă, de asemenea, că calculele pentru token-ul limită de rată sunt estimate atunci când se primește cererea și nu sunt identice cu numărul de simboluri de facturare finale.
• Anthropic documentează limitele de solicitări-pe-minut, de jetoane de intrare-pe-minut și de jetoane de ieșire-pe-minut. Depășirea limitelor returnează un 429 cu un antet de reîncercare după.
• Anthropic avertizează că creșterile bruște ale traficului pot atinge limitele de accelerație și recomandă o accelerare treptată.
• Pentru majoritatea modelelor Claude, documentele Anthropic în care jetoanele de intrare citite în cache nu sunt luate în considerare pentru limitele jetoanelor de intrare pe minut, ceea ce înseamnă că stocarea în cache promptă poate modifica spațiul efectiv.
• Limitele ratei Google Gemini API sunt legate de nivelurile de utilizare ale proiectului, cu niveluri mai mari în funcție de configurarea facturării, cheltuielile cumulate și timpul scurs după etapele de plată.

Lecția operațională este clară: o formă de solicitare compatibilă cu OpenAI nu implică un comportament de cotă compatibil cu OpenAI. Un gateway cu mai mulți furnizori are nevoie de un model de cotă intern care este mai bogat decât „reîncercați dacă 429”.

Obiectiv de proiectare: faceți din controlul admiterii o responsabilitate de poartă

Un gateway care știe limita de rate ar trebui să răspundă la cinci întrebări înainte de a trimite o solicitare:

1. Ce furnizor, model, implementare, regiune, proiect sau spațiu de lucru va primi solicitarea?
2. Câtă capacitate de solicitare, indicativ de intrare, simbol de ieșire și concurență poate consuma?
3. Ce chiriaș, echipă, cheie API, client sau clasă de sarcină de lucru ar trebui să fie taxat pentru capacitatea partajată?
4. Ar trebui să fie admisă cererea acum, să fie pusă în coadă pentru scurt timp, să fie retrogradată, direcționată în altă parte sau respinsă?
5. Cum ar trebui să fie reconciliată rezervarea după ce furnizorul returnează utilizarea efectivă?

Poarta de acces devine un guvernator de cote. Nu înlocuiește limitele furnizorului. Face limitele furnizorilor vizibile, previzibile și corecte în propriul dvs. sistem.

Creați un model de cotă normalizat

Începeți prin a defini dimensiunile interne ale limitatorului care pot reprezenta furnizorii majori, fără a-i forța într-un singur grup înșelător.

Dimensiuni recomandate ale limitatorului

• RPM: solicitări pe minut.
• Introduceți TPM: indicative de solicitare, mesaj, instrument și context pe minut.
• TPM de ieșire: jetoane de finalizare pe minut, rezervate separat pentru streaming și generații lungi.
• Total TPM: util pentru furnizorii sau implementările care expun presiunea combinată a simbolurilor.
• Concurență: solicitări active, fluxuri active sau joburi în timpul zborului.
• Durata fluxului: fluxurile cu durată lungă de viață pot ocupa spațiu de conectare și token de ieșire chiar și atunci când RPM este scăzut.
• Aria specific furnizorului: abonament/regiune/implementare Azure, spațiu de lucru antropic/clasă de model, proiect/nivel Google sau organizație/proiect/grup de modele OpenAI.

Nu ascunde parametrii specifici furnizorului. Normalizați-le într-o schemă comună, dar păstrați suficiente detalii pentru a explica o respingere mai târziu.

{
  "provider": "provider_a",
  "model_profile": "fast-chat",
  „provider_scope”: {
    "proiect": "produs",
    "regiune": "noi-est",
    „deployment”: „chat-large-01”
  },
  „limite”: {
    „rpm”: 1200,
    „input_tpm”: 800000,
    „output_tpm”: 250000,
    „concurență”: 200
  }
}

Acest obiect intern ar trebui configurat în mod explicit, nu dedus doar din numele modelelor. Tablourile de bord ale furnizorilor, nivelurile de cont, implementările regionale și setările spațiului de lucru pot schimba capacitatea efectivă a aceleiași familii de modele.

Estimați presiunea simbolului înainte de expediere

Limitarea ratei de către furnizor are loc adesea înainte ca utilizarea finală a facturării să fie cunoscută. Gateway-ul dvs. ar trebui să facă același tip de estimare conservatoare înainte de a trimite trafic.

Intrari privind rezervarea preflight

• Prompt serializat și lungimea mesajului.
• Tokenizare specifică modelului și supraîncărcare pentru roluri, instrumente, imagini sau instrucțiuni structurate de ieșire.
• max_completion_tokens sau limita de ieșire echivalentă.
• Rata de finalizare istorică pentru acest punct final, locatar, profil de model și clasă de solicitare.
• Token-uri de citire a memoriei cache așteptate, dacă stocarea în cache promptă este disponibilă și măsurabilă.
• Signal de streaming și durata estimată a fluxului.

O regulă simplă de rezervare este adesea suficientă pentru a începe:

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

Pentru rute necunoscute, utilizați o valoare implicită conservatoare. Pentru rute de producție stabile, actualizați estimările continuu din utilizarea reală.

Rezervați, apoi reconciliați

Rezervarile de cote nu ar trebui să devină taxe permanente. Tratează-le ca pe niște prize:

1. Citat: estimați presiunea de intrare și de ieșire.
2. Rezervare: deduceți din grupele de jetoane relevante înainte de expediere.
3. Rezolvați: înlocuiți estimarea cu utilizarea raportată de furnizor, atunci când este disponibilă.
4. Rambursare sau debitare: returnați capacitatea rezervată nefolosită sau taxați excedente în fereastra următoare, dacă este necesar.

Acest lucru contează cel mai mult pentru apelurile în context lung și în flux. Dacă verificați TPM-ul de intrare doar înainte de expediere, un flux poate începe cu succes și apoi va intra în presiunea jetonului de ieșire mai târziu. Rezervarea separată a spațiului de ieșire reduce eșecul la mijlocul fluxului și riscul de blocare.

Utilizați grupuri de jetoane ierarhice pentru corectitudinea chiriașilor

Un singur limitator global protejează contul de furnizor, dar nu îi protejează pe chiriași unul de celălalt. O sarcină în lot de lungă durată poate consuma TPM partajat și poate duce la eșecul solicitărilor interactive de la alte echipe.

Utilizați grupe de jetoane ierarhice:

organizare
  └── chiriaș
      └── echipa
          └── api_key
              └── model_profil
                  └── provider_deployment

O solicitare trebuie să treacă fiecare grup relevant. Acest lucru vă permite să aplicați mai multe politici simultan:

• Organizația nu poate depăși capacitatea furnizorului.
• Un chiriaș nu poate consuma mai mult decât cota contractată.
• O cheie API nu poate depăși limita prevăzută pentru mediul sau aplicația.
• Un profil de model în lot nu poate înfometa un profil de model interactiv.
• O implementare de furnizor nu poate fi supraîncărcată chiar dacă o altă implementare are cotă de rezervă.

Partajare echitabilă versus utilizare

Recomandare: utilizați partajarea echitabilă ponderată cu împrumuturi controlate în rafală.

Lipsele stricte pentru fiecare locatar sunt ușor de explicat, dar pot limita capacitatea nefolosită. Împrumutul în rafală îmbunătățește utilizarea, permițând unui chiriaș să utilizeze temporar cota inactivă dintr-un pool partajat. Compensația este complexitatea: tablourile de bord trebuie să arate ce a fost garantat, ce a fost împrumutat și când împrumutul a fost revocat.

O regulă practică:

• Oferiți fiecărui chiriaș o valoare de referință garantată.
• Permite împrumutul în rafală de la capacitatea partajată nefolosită.
• Recuperați capacitatea împrumutată atunci când apare trafic cu prioritate mai mare sau garantat.
• Nu lăsați niciodată traficul împrumutat să creeze 429 la nivel de furnizor pentru trafic garantat.

Separați clasele de trafic înainte de a se lupta

Nu toate solicitările merită același comportament în coadă. Puneți trafic în profiluri de model cu cozi separate și grupuri de cote.

Astarea în coadă îmbunătățește rata de succes, dar crește latența finală. Un gateway ar trebui să explice acest compromis. De exemplu, o solicitare interactivă poate aștepta până la 300 de milisecunde pentru cotă, apoi poate să retragă sau să eșueze. O sarcină în lot de noapte poate aștepta 20 de minute și poate fi considerată totuși reușită.

Normalizați 429s într-o singură schemă de eroare

Chiar și cu un control bun al admiterii, furnizorii 429 vor apărea în continuare. Limitele se pot schimba, estimările furnizorilor pot diferi de ale dvs., iar traficul poate ajunge în rafale mai bruște decât se aștepta.

Normalizează fiecare furnizor 429 într-un obiect de eroare gateway:

{
  „eroare”: {
    "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": "interactiv",
    „estimated_input_tokens”: 4200,
    „estimated_output_tokens”: 800,
    "gateway_decision": "admitted_then_provider_rejected",
    „fallback_allowed”: fals,
    "trace_id": "trace_abc"
  }
}

Câmpul cheie este gateway_decision. Un 429 după ce gateway-ul a admis cererea este diferit de o cerere pe care gateway-ul a respins-o local înainte de expediere. Primul indică o problemă de calibrare a limitatorului. Al doilea indică protecția intenționată.

Adaptați-vă de la anteturile furnizorului, dar nu depindeți de ele

Unii furnizori returnează anteturi utile, cum ar fi indicatorii de reîncercare după sau de capacitate rămasă. Folosiți-le când sunt disponibile.

Recomandare: anteturile furnizorului ar trebui să ajusteze guvernatorul local, nu să îl înlocuiască.

Motive:

• Disponibilitatea antetului diferă în funcție de furnizor și punct final.
• E posibil ca anteturile să nu expună fiecare dimensiune a limitatorului.
• Reîncercați după vă spune când să încercați din nou, nu care chiriaș ar trebui să obțină mai departe capacitatea.
• Estimările de indicative ale furnizorului pot diferi de facturarea sau contabilitatea dvs. internă.

O implementare robustă actualizează ratele de reîncărcare a grupului local și perioadele de răcire pe baza antetelor, impunând în același timp limitele de implementare a locatarului, cheii API, clasei de trafic și furnizorilor în interiorul gateway-ului.

Adăugați guvernatori de rampă pentru migrații și lucrări programate

Multe incidente cu limita de rată au loc în timpul modificărilor planificate: trecerea de la un model la altul, schimbarea furnizorilor, activarea unui nou flux de lucru pentru agent sau lansarea unei evaluări programate.

Recomandare: tratați creșterea traficului ca pe o lansare controlată.

• Migrarea modelului de semnalizare caracteristică în funcție de chiriaș, rută sau procent de trafic.
• Stabiliți plafoane de creștere pe minut pentru implementările de noi furnizori.
• Încălziți traficul treptat de-a lungul orelor, în loc să comutați tot traficul instantaneu.
• Întrerupeți lansarea când rata 429, rata downgrade, adâncimea cozii sau latența p95 depășesc un prag.
• Păstrați o rută de derulare de urgență cu o politică de compatibilitate, nu doar un model de rezervă.

Predicție: pe măsură ce modurile de rutare a furnizorului, nivelurile de prioritate și controalele la nivel de spațiu de lucru devin mai frecvente, guvernarea rampei va deveni o funcție standard de gateway, mai degrabă decât un script de răspuns la incident.

Fallback-ul este o decizie de politică, nu doar o decizie de capacitate

Când un furnizor returnează un 429, rutarea către alt furnizor poate fi răspunsul corect. De asemenea, poate fi nesigur.

Fallback se poate modifica:

• Calitatea ieșirii și instrucțiunile care urmează.
• Lungimea contextului.
• Comportamentul apelului instrumentului.
• Fiabilitatea ieșirii structurate.
• Poziția de păstrare a datelor și de rezidență.
• Cost și latență.

Guvernatorul cotei ar trebui să întrebe un strat de compatibilitate dacă este permisă alternativă pentru această clasă de solicitare. Dacă nu, ar trebui să fie în coadă sau să eșueze cu un răspuns local clar de limită de rată, mai degrabă decât să schimbe în tăcere semantica.

Expunerea tablouri de bord pentru cote care explică deciziile

Un sistem de cote pe care nimeni nu îl poate înțelege va fi ocolit. Creați tablouri de bord în jurul întrebărilor operaționale:

• Care chiriași consumă cele mai multe RPM, TPM de intrare și TPM de ieșire?
• Ce profiluri de model sunt în coadă, resping sau retrag?
• Ce domeniu de aplicare al furnizorului este blocajul: proiect, regiune, implementare, spațiu de lucru, clasă de model sau nivel de cont?
• Cât de des diferă estimările gateway-ului de utilizarea furnizorului?
• Care este distribuția după reîncercare în funcție de furnizor și tip de limitator?
• Cât de mult spațiu eficient este creat de citirile prompte din memoria cache?
• Ce clase de trafic împrumută capacitatea de explozie?

Pentru produse destinate clienților sau partenerilor, expuneți comenzile sigure:

• Limite de rată pentru fiecare cheie.
• Limite de explozie per echipă.
• Limite zilnice pentru fiecare client.
• Pauză de urgență pentru un chiriaș sau cheie.
• Alerte pentru 429 de vârfuri, creșterea cozii de așteptare și presiune anormală a simbolurilor.
• Punctele finale ale API-ului partener pentru gestionarea cotelor de distribuitori.

Acest lucru transformă limitarea ratei dintr-o eroare misterioasă a furnizorului într-o parte auditabilă a guvernării API-ului echipei.

Lista de verificare a implementării

Faza 1: observați și clasificați

• Furnizor de jurnal, model, implementare, regiune, spațiu de lucru, proiect, chiriaș, cheie API și clasa de solicitare pentru fiecare apel.
• Capturați furnizorii 429 cu metadate pentru reîncercare și erori brute.
• Înregistrați separat simbolurile de intrare/ieșire estimate și reale.
• Separați traficul interactiv, lot, eval și de fundal în telemetrie.

Faza 2: controlul admiterii locale

• Creați obiecte de limitare interne pentru RPM, TPM de intrare, TPM de ieșire, TPM total și concurență.
• Adăugați o estimare a simbolului preflight.
• Rezervați cota înainte de expediere și reconciliați după sosirea utilizării furnizorului.
• Respingeți la nivel local atunci când o solicitare nu se potrivește cu chiriașul sau furnizorul său.

Faza 3: corectitudine și cozi

• Adăugați compartimente ierarhice de la organizație la implementarea furnizorului.
• Atribuiți acțiuni garantate pentru chiriași și împrumuturi controlate.
• Creați cozi separate în funcție de clasa de trafic.
• Setați timpii maximi de așteptare și regulile de rezervă specifice clasei.

Faza 4: adaptare și operațiuni

• Utilizați anteturile furnizorilor pentru a ajusta perioadele de răcire și pentru a completa ipotezele.
• Adăugați regulatori de rampă pentru migrații și lucrări programate.
• Expunerea tablouri de bord și alerte privind cotele.
• Examinați săptămânal eroarea de estimare și cota blocată.

Concluzie acționabilă

Dacă gateway-ul dvs. reîncearcă doar 429s, acesta funcționează după defecțiune. Un gateway API AI de nivel de producție ar trebui să prevină majoritatea eșecurilor privind limitarea ratei, hotărând cui îi este permis să trimită ce, când și față de ce cotă de furnizor.

Începeți cu un model de limitator normalizat, rezervare preflight token și cozi de nivel de trafic. Apoi adăugați corectitudinea ierarhică a chiriașilor, adaptarea antetului furnizorului și guvernatorii de rampă. Rezultatul nu este doar mai puține 429s. Este o alocare mai clară a capacității, o latență mai previzibilă, migrări mai sigure și un comportament de limitare a ratei pe care echipele dvs. de inginerie, finanțe și asistență pentru clienți îl pot explica de fapt.

Lectură similară

• prompt cache accounting și cache-hit analytics
• politici de rutare alternativă compatibile