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 produkciji 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—potreban je, ali nepotpun. Backoff reagira nakon što pružatelj odbije promet. AI API pristupnik koji je 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.

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

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 provoditi 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 dodjeljuje se 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 razlikuju se ovisno o modelu.
• Azure OpenAI također napominje da se izračuni tokena za ograničenje brzine procjenjuju kada se primi zahtjev i nisu isti kao konačni brojevi tokena za naplatu.
• Antropski dokumenti odvajaju ograničenja zahtjeva po minuti, ulaznih tokena po minuti i izlaznih tokena po minuti. Prekoračenje ograničenja vraća 429 sa zaglavljem ponovnog pokušaja.
• 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, dokumenti Anthropic koji ulazne tokene za čitanje predmemoriraju ne ubrajaju se u ograničenja unosa tokena po minuti, što znači da brzo spremanje u predmemoriju može promijeniti efektivni prostor.
• Ograničenja stopa Google Gemini API-ja 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: oblik zahtjeva kompatibilan s OpenAI-jem ne podrazumijeva ponašanje kvote kompatibilno s OpenAI-jem. Pristupnik s više pružatelja usluga treba interni model kvote koji je bogatiji od "pokušaj ponovo ako 429."

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

Gateway 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 zakupac, tim, API ključ, korisnik 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 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 završetka po minuti, odvojeno rezervirani za strujanje i duge generacije.
• Ukupni TPM: korisno 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 pružatelja usluga: Azure pretplata/regija/uvođenje, Anthropic radni prostor/klasa modela, Google projekt/razina ili OpenAI organizacija/projekt/grupa modela.

Ne skrivajte 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": "brzi chat",
  "provider_scope": {
    "projekt": "proizvod",
    "regija": "us-istok",
    "deployment": "chat-large-01"
  },
  "ograničenja": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "istodobnost": 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 rezervacija prije leta

• Serializirani upit i duljina poruke.
• Tokenizacija specifična za model i režijski 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
procijenjeni_izlazni_tokeni = min(
  max_completion_tokens,
  p95_historical_output_tokens_for_route
)
rezervirani_totalni_tokeni = procijenjeni_input_tokeni + procijenjeni_izlazni_tokeni

Za nepoznate rute upotrijebite konzervativnu zadanu vrijednost. Za stabilne proizvodne rute kontinuirano ažurirajte procjene prema stvarnoj upotrebi.

Rezerviraj, pa uskladi

Rezervacije kvota ne bi trebale postati stalne naknade. Tretirajte ih kao zadržavanja:

1. Citat: procijenite ulazni i izlazni tlak.
2. Rezerviraj: odbij od relevantnih žetona prije otpreme.
3. Nagodba: zamijenite procjenu s upotrebom koju je prijavio davatelj usluga kada je dostupna.
4. Povrat novca ili zaduženje: vratite neiskorišteni rezervirani kapacitet ili naplatite višak u sljedećem prozoru ako je potrebno.

Ovo je najvažnije za pozive dugog konteksta i strujanje. Ako provjerite samo ulazni TPM prije slanja, tok se može uspješno pokrenuti, a kasnije naići na pritisak izlaznog tokena. Zasebno rezerviranje prostora za visinu izlaza 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 skupni posao dugog konteksta može potrošiti dijeljeni TPM i uzrokovati neuspjeh interaktivnih zahtjeva drugih timova.

Koristite hijerarhijske spremnike tokena:

organizacija
  └── podstanar
      └── tim
          └── api_ključ
              └── profil_modela
                  └── provider_deployment

Zahtjev mora proći svaki relevantni spremnik. To vam omogućuje da nametnete nekoliko pravila odjednom:

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

Pošteno dijeljenje nasuprot korištenju

Preporuka: koristite ponderirano pravedno dijeljenje s kontroliranim burst posuđivanjem.

Stroga ograničenja po stanarima lako je objasniti, ali mogu dovesti do gubitka neiskorištenog kapaciteta. 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 usluga 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.

{
  "greška": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "brzi chat",
    "provider_model": "model-x",
    "ponovi_nakon_ms": 2400,
    "stanar_id": "stanar_123",
    "api_key_id": "ključ_456",
    "request_class": "interaktivan",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "prihvaćen_zatim_provider_odbijen",
    "fallback_allowed": netočno,
    "trace_id": "trace_abc"
  }
}