AI API pristupnici koji su svjesni ograničenja brzine: oblik RPM-a, TPM-a, burstova i pravednosti stanara prije 429s hita

429 od pružatelja LLM-a nije samo signal za ponovni pokušaj. U proizvodnji je to često dokaz da je vaša aplikacija već izgubila kontrolu nad pristupom, pravednošću zakupca, kašnjenjem ili obračunom kvota specifičnih za pružatelja usluga.

Uobičajeni popravak—eksponencijalni backoff—neophodan je, ali nepotpun. Backoff reagira nakon što pružatelj odbije promet. AI API pristupnik svjestan ograničenja brzine trebao bi oblikovati promet prije nego što zahtjevi napuste vaš sustav: procijeniti pritisak tokena, rezervirati kvotu, izolirati zakupce, staviti pravi rad u red čekanja, odbiti pogrešan rad i prilagoditi se kada se promijene ograničenja pružatelja usluga.

Ovaj članak opisuje praktični regulator kvote pristupnika za timove koji šalju radna opterećenja proizvodnje višestrukim pružateljima LLM-a putem objedinjenog API.

Problem s čitačem: 429 su višedimenzionalni

Mnogi timovi tretiraju ograničenja stope kao da se radi o jednom broju zahtjeva po minuti. Ta se pretpostavka brzo razbija s LLM API-jima.

Činjenice iz trenutne dokumentacije pružatelja usluge:

• OpenAI dokumentira da se ograničenja mogu primijeniti na kraće prozore od oglašenog ograničenja po minuti, tako da kratki nizovi mogu zakazati čak i kada prosječna minuta izgleda sigurno.
• Azure OpenAI kvota se dodjeljuje prema pretplati, regiji, modelu i vrsti implementacije u tokenima po minuti. Dodjeljivanje TPM-a implementaciji također određuje ograničenja RPM-a prinudnog zaključivanja, a omjeri RPM-a-TPM-a ovise o modelu.
• Azure OpenAI također primjećuje da se izračuni tokena ograničenja brzine procjenjuju kada se primi zahtjev i nisu isti kao konačni brojevi tokena za naplatu.
• Anthropic dokumentira zasebna ograničenja zahtjeva po minuti, ulaznih tokena po minuti i izlaznih tokena po minuti. Prekoračenje ograničenja vraća 429 sa zaglavljem retry-after.
• Anthropic upozorava da oštro povećanje prometa može dosegnuti ograničenja ubrzanja i preporučuje postupno povećanje.
• Za većinu Claude modela, Anthropic dokumenti koji ulazne tokene za čitanje u predmemoriju ne ubrajaju se u ograničenja unosa tokena po minuti, što znači da brzo predmemoriranje može promijeniti efektivni prostor.
• Google Gemini API ograničenja stope povezana su s razinama korištenja projekta, s višim razinama ovisno o postavkama naplate, kumulativnoj potrošnji i proteklom vremenu nakon prekretnica plaćanja.

Operativna lekcija je jasna: OpenAI-kompatibilan oblik zahtjeva ne podrazumijeva OpenAI-kompatibilno ponašanje kvote. Gateway s više pružatelja usluga treba interni model kvota koji je bogatiji od "ponovo pokušaj ako 429."

Cilj dizajna: učiniti kontrolu pristupa odgovornošću pristupnika

Gateway koji je svjestan ograničenja brzine trebao bi odgovoriti na pet pitanja prije slanja zahtjeva:

1. Koji će pružatelj, model, implementacija, regija, projekt ili radni prostor primiti zahtjev?
2. Koliko zahtjeva, ulaznog tokena, izlaznog tokena i kapaciteta paralelnosti može potrošiti?
3. Koji stanar, tim, API ključ, kupac ili klasa radnog opterećenja trebaju biti naplaćeni prema zajedničkom kapacitetu?
4. Treba li zahtjev sada prihvatiti, nakratko staviti u red čekanja, vratiti na nižu razinu, preusmjeriti drugamo ili odbiti?
5. Kako treba uskladiti rezervaciju nakon što pružatelj vrati stvarnu upotrebu?

Gateway postaje regulator kvote. Ne zamjenjuje ograničenja pružatelja usluga. Čini ograničenja pružatelja usluga vidljivima, predvidljivima i pravednima unutar vašeg vlastitog sustava.

Izradite normalizirani model kvota

Započnite definiranjem unutarnjih dimenzija ograničenja koje mogu predstavljati glavne pružatelje bez da ih tjeraju u jednu zavaravajuću kantu.

Preporučene dimenzije graničnika

• RPM: zahtjeva po minuti.
• Ulazni TPM: upit, poruka, alat i tokeni konteksta po minuti.
• Izlazni TPM: tokeni dovršetka po minuti, rezervirani zasebno za strujanje i duge generacije.
• Ukupni TPM: koristan za pružatelje usluga ili implementacije koje izlažu kombinirani pritisak tokena.
• Podudarnost: aktivni zahtjevi, aktivni tokovi ili poslovi u letu.
• Trajanje strujanja: dugotrajni streamovi mogu zauzeti prostor za vezu i izlazni token čak i kada je RPM nizak.
• Opseg specifičan za davatelja usluga: Azure pretplata/regija/uvođenje, Anthropic radni prostor/klasa modela, Google projekt/razina ili OpenAI organizacija/projekt/grupa modela.

Nemojte skrivati dimenzije specifične za pružatelja usluga. Normalizirajte ih u zajedničku shemu, ali sačuvajte dovoljno detalja da kasnije objasnite odbijanje.

{
  "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
  }
}

Ovaj interni objekt treba konfigurirati eksplicitno, a ne zaključivati samo iz naziva modela. Nadzorne ploče pružatelja usluga, razine računa, regionalne implementacije i postavke radnog prostora mogu promijeniti efektivni kapacitet iste obitelji modela.

Procijenite pritisak tokena prije otpreme

Ograničenje stope na strani pružatelja često se događa prije nego što se sazna konačna naplata. Vaš pristupnik trebao bi napraviti istu vrstu konzervativne procjene prije slanja prometa.

Unosi rezervacije prije leta

• Serializirani upit i duljina poruke.
• Tokenizacija specifična za model i dodatni troškovi za uloge, alate, slike ili upute za strukturirani izlaz.
• max_completion_tokens ili ekvivalentno izlazno ograničenje.
• Povijesni omjer završetka za ovu krajnju točku, stanara, profil modela i klasu zahtjeva.
• Očekivani tokeni za čitanje predmemorije ako je brzo predmemoriranje dostupno i mjerljivo.
• Oznaka strujanja i očekivano trajanje strujanja.

Jednostavno pravilo rezervacije često je dovoljno za početak:

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

Za nepoznate rute koristite konzervativnu zadanu vrijednost. Za stabilne proizvodne rute, kontinuirano ažurirajte procjene iz stvarne upotrebe.

Rezerviraj, pa uskladi

Rezervacije kvota ne bi trebale postati stalne naknade. Tretirajte ih kao zahtjeve:

1. Citat: procijenite ulazni i izlazni tlak.
2. Rezerva: oduzeti od relevantnih spremnika tokena prije otpreme.
3. Nagodba: zamijenite procjenu korištenjem koje je prijavio pružatelj usluga kada je dostupno.
4. Povrat novca ili zaduženje: vratite neiskorišteni rezervirani kapacitet ili naplatite višak do sljedećeg prozora ako je potrebno.

Ovo je najvažnije za dugi kontekst i strujanje poziva. Ako provjerite samo ulazni TPM prije slanja, tok se može uspješno pokrenuti, a kasnije naići na pritisak izlaznog tokena. Odvojeno rezerviranje izlaznog prostora smanjuje kvar srednjeg toka i rizik od zastoja.

Koristite hijerarhijske spremnike tokena za pravednost stanara

Jedan globalni limiter štiti račun pružatelja usluga, ali ne štiti stanare jedne od drugih. Jedan paketni posao dugog konteksta može potrošiti dijeljeni TPM i uzrokovati neuspjeh interaktivnih zahtjeva drugih timova.

Upotreba hijerarhijskih spremnika tokena:

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

Zahtjev mora proći svaki relevantni spremnik. To vam omogućuje provođenje nekoliko pravila odjednom:

• Organizacija ne može premašiti kapacitet pružatelja usluga.
• Zakupac ne može trošiti više od svog ugovorenog udjela.
• Ključ API ne može premašiti predviđeno ograničenje okruženja ili aplikacije.
• Profil skupnog modela ne može izgladnjeti profil interaktivnog modela.
• Implementacija davatelja usluga ne može se preopteretiti čak i ako druga implementacija ima rezervnu kvotu.

Pošteno dijeljenje nasuprot korištenju

Preporuka: koristite ponderirano pošteno dijeljenje s kontroliranim burst posuđivanjem.

Stroga ograničenja po stanarima lako je objasniti, ali mogu blokirati neiskorišteni kapacitet. Burst borrowing poboljšava iskorištenost dopuštajući zakupcu da privremeno koristi neaktivnu kvotu iz zajedničkog skupa. Kompromis je složenost: nadzorne ploče moraju prikazivati što je zajamčeno, što je posuđeno i kada je posudba opozvana.

Praktično pravilo:

• Dajte svakom zakupcu zajamčenu osnovnu vrijednost.
• Dopusti brzo posuđivanje iz neiskorištenog zajedničkog kapaciteta.
• Povratite posuđeni kapacitet kada se pojavi promet višeg prioriteta ili zajamčeni promet.
• Nikada ne dopustite da posuđeni promet stvara 429 na razini pružatelja za zajamčeni promet.

Razdvojite prometne klase prije nego što se bore

Ne zaslužuju svi zahtjevi isto ponašanje u redu čekanja. Stavite promet u profile modela s odvojenim redovima čekanja i skupovima kvota.

Stavljanje u red čekanja poboljšava stopu uspjeha, ali povećava latenciju repa. Gateway bi trebao učiniti taj kompromis eksplicitnim. Na primjer, interaktivni zahtjev može čekati do 300 milisekundi za kvotu, a zatim se vratiti ili ne uspjeti. Noćni grupni posao može čekati 20 minuta i još uvijek se smatra uspješnim.

Normalizirajte 429 u jednu shemu pogreške

Čak i uz dobru kontrolu pristupa, davatelj 429 će se i dalje javljati. Ograničenja se mogu promijeniti, procjene pružatelja mogu se razlikovati od vaših, a promet može stizati u oštrijim naletima od očekivanog.

Normalizirajte svakog pružatelja 429 u objekt pogreške pristupnika:

{
  "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"
  }
}

Ključno polje je gateway_decision. 429 nakon što je pristupnik prihvatio zahtjev razlikuje se od zahtjeva koji je pristupnik lokalno odbio prije slanja. Prvi ukazuje na problem s kalibracijom limitera. Drugi označava namjernu zaštitu.

Prilagodi se zaglavljima pružatelja usluga, ali ne ovisi o njima

Neki pružatelji usluga vraćaju korisna zaglavlja kao što su indikatori ponovnog pokušaja ili preostalog kapaciteta. Koristite ih kada su dostupni.

Preporuka: zaglavlja pružatelja usluga trebaju prilagoditi vašeg lokalnog upravitelja, a ne zamijeniti ga.

Razlozi:

• Dostupnost zaglavlja razlikuje se ovisno o pružatelju i krajnjoj točki.
• Zaglavlja možda neće otkriti svaku dimenziju ograničenja.
• Retry-after govori vam kada da pokušate ponovno, a ne koji bi zakupac sljedeći trebao dobiti kapacitet.
• Procjene tokena na strani davatelja mogu se razlikovati od vaše naplate ili internog računovodstva.

Robusna implementacija ažurira lokalne stope punjenja spremnika i hlađenja na temelju zaglavlja, dok još uvijek provodi zakupca, API ključ, prometnu klasu i ograničenja implementacije pružatelja unutar pristupnika.

Dodaj regulatore rampe za migracije i zakazane poslove

Mnogi incidenti ograničenja brzine događaju se tijekom planiranih promjena: prelazak s jednog modela na drugi, promjena pružatelja usluga, omogućavanje novog tijeka rada agenta ili pokretanje zakazanog izvođenja procjene.

Preporuka: rast prometa tretirajte kao kontrolirano uvođenje.

• Migracije modela zastavica značajki prema zakupcu, ruti ili postotku prometa.
• Postavite gornje granice rasta po minuti za nove implementacije pružatelja usluga.
• Zagrijavajte promet postupno tijekom sati umjesto da odmah prebacite sav promet.
• Pauziraj uvođenje kada stopa 429, stopa prelaska na stariju verziju, dubina čekanja ili kašnjenje p95 prijeđe prag.
• Zadržite rutu za hitno vraćanje s politikom kompatibilnosti, a ne samo rezervnim modelom.

Predviđanje: kako načini usmjeravanja pružatelja, razine prioriteta i kontrole na razini radnog prostora postaju sve češći, upravljanje rampom postat će standardna značajka pristupnika, a ne skripta za odgovor na incident.

Zamjena je odluka o politici, a ne samo o kapacitetu

Kada jedan pružatelj vrati 429, usmjeravanje na drugog pružatelja može biti pravi odgovor. Također može biti nesigurno.

Zamjena se može promijeniti:

• Kvaliteta izlaza i sljedeće upute.
• Duljina konteksta.
• Ponašanje poziva alata.
• Pouzdanost strukturiranog izlaza.
• Položaj zadržavanja podataka i boravka.
• Cijena i latencija.

Guverner kvote trebao bi pitati sloj kompatibilnosti je li zamjena dopuštena za ovu klasu zahtjeva. Ako nije, trebao bi stati u red ili biti neuspješan s jasnim odgovorom o lokalnom ograničenju brzine umjesto tihe promjene semantike.

Izložite nadzorne ploče kvota koje objašnjavaju odluke

Sustav kvota koji nitko ne može razumjeti bit će zaobiđen. Izgradite nadzorne ploče oko operativnih pitanja:

• Koji stanari troše najviše RPM-a, ulaznog TPM-a i izlaznog TPM-a?
• Koji profili modela čekaju, odbijaju ili se vraćaju?
• Koji je opseg pružatelja usko grlo: projekt, regija, implementacija, radni prostor, klasa modela ili razina računa?
• Koliko se često procjene pristupnika razlikuju od upotrebe davatelja?
• Što je distribucija ponovnog pokušaja prema pružatelju i vrsti limitera?
• Koliko se učinkovitog prostora stvara brzim čitanjem predmemorije?
• Koje prometne klase posuđuju burst kapacitet?

Za proizvode usmjerene na kupce ili partnere, izložite sigurne kontrole:

• Ograničenja stope po ključu.
• Ograničenja praska po timu.
• Dnevna ograničenja po kupcu.
• Hitna pauza za stanara ili ključ.
• Upozorenja za 429 skokova, rast reda čekanja i abnormalni pritisak tokena.
• Partner API krajnje točke za upravljanje kvotama preprodavača.

Ovo pretvara ograničavanje stope iz misteriozne pogreške pružatelja u revizijski dio upravljanja timom API.

Popis za provjeru implementacije

1. faza: promatranje i klasificiranje

• Dobavljač dnevnika, model, implementacija, regija, radni prostor, projekt, stanar, API ključ i klasa zahtjeva za svaki poziv.
• Snimite 429 davatelja usluga s ponovnim pokušajem i neobrađenim metapodacima pogreške.
• Odvojeno zabilježite procijenjene i stvarne ulazno/izlazne tokene.
• Odvojite interaktivni, batch, eval i pozadinski promet u telemetriji.

Faza 2: lokalna kontrola pristupa

• Stvorite interne objekte ograničenja za RPM, ulazni TPM, izlazni TPM, ukupni TPM i konkurentnost.
• Dodajte procjenu tokena prije provjere.
• Rezervirajte kvotu prije otpreme i uskladite nakon što davatelj usluga stigne.
• Odbij lokalno kada zahtjev ne može stati u segment zakupca ili davatelja.

Faza 3: pravednost i redovi čekanja

• Dodajte hijerarhijske segmente od organizacije do implementacije pružatelja usluga.
• Dodijelite zajamčene udjele stanarima i kontrolirano brzo zaduživanje.
• Stvorite zasebne redove prema klasi prometa.
• Postavite maksimalno vrijeme čekanja i zamjenska pravila specifična za klasu.

Faza 4: prilagodba i operacije

• Upotrijebite zaglavlja dobavljača za podešavanje pretpostavki o hlađenju i ponovnom punjenju.
• Dodaj regulatore rampe za migracije i zakazane poslove.
• Izložite nadzorne ploče i upozorenja o kvotama.
• Tjedno pregledajte pogrešku procjene i nasukanu kvotu.

Poduzimajući zaključak

Ako vaš pristupnik pokušava samo 429s, on radi nakon greške. Pristupnik AI API proizvodne razine trebao bi spriječiti većinu neuspjeha ograničenja brzine odlučivanjem tko smije poslati što, kada i prema kvoti kojeg davatelja usluga.

Počnite s normaliziranim modelom limitera, rezervacijom tokena prije leta i redovima čekanja klase prometa. Zatim dodajte hijerarhijsku pravednost stanara, prilagodbu zaglavlja pružatelja usluga i regulatore rampe. Rezultat nije samo manje 429-ica. To je jasnija dodjela kapaciteta, predvidljivija latencija, sigurnije migracije i ponašanje ograničenja stope koje vaši inženjerski, financijski i timovi za korisničku podršku zapravo mogu objasniti.

Povezana literatura

• rezervacija prije leta i usklađivanje upotrebe
• prompt cache računovodstvo i analitika pogodaka predmemorije
• kompatibilna rezervna pravila usmjeravanja