Prehodi AI API, ki upoštevajo omejitve hitrosti: oblikujte RPM, TPM, burste in poštenost najemnika pred zadetkom 429

429 od ponudnika LLM ni samo signal za ponovni poskus. V produkciji je to pogosto dokaz, da je vaša aplikacija že izgubila nadzor nad sprejemom, pravičnostjo najemnikov, zakasnitvijo ali obračunavanjem kvot, specifičnim za ponudnika.

Skupni popravek – eksponentni odmik – je potreben, vendar nepopoln. Backoff se odzove, ko ponudnik zavrne promet. AI API prehod, ki pozna omejitve hitrosti, bi moral oblikovati promet, preden zahteve zapustijo vaš sistem: oceniti pritisk žetonov, rezervirati kvoto, izolirati najemnike, postaviti pravo delo v čakalno vrsto, zavrniti napačno delo in se prilagoditi, ko se omejitve ponudnika spremenijo.

Ta članek opisuje praktični regulator kvote prehoda za ekipe, ki pošiljajo produkcijske delovne obremenitve več ponudnikom LLM prek enotnega API.

Težava z bralnikom: številke 429 so večdimenzionalne

Številne skupine obravnavajo omejitve hitrosti, kot da gre za eno število zahtev na minuto. Ta predpostavka se pri API-jih LLM hitro pokvari.

Dejstva iz trenutne dokumentacije ponudnika:

• OpenAI dokumentira, da so lahko omejitve uveljavljene za krajša okna od oglaševane omejitve na minuto, tako da lahko kratki nizi ne uspejo, tudi če je povprečna minuta videti varna.
• Azure OpenAI kvota je dodeljena glede na naročnino, regijo, model in vrsto uvedbe v žetonih na minuto. Dodeljevanje TPM razmestitvi določa tudi uveljavljene omejitve vrtljajev na minuto in razmerja RPM proti TPM se razlikujejo glede na model.
• Azure OpenAI prav tako ugotavlja, da so izračuni žetonov za omejitev stopnje ocenjeni, ko je zahteva prejeta, in niso enaki končnim štetjem žetonov za obračun.
• Anthropic dokumentira ločene omejitve zahtev na minuto, vnosnih žetonov na minuto in izhodnih žetonov na minuto. Preseganje omejitev vrne 429 z glavo za ponovni poskus.
• Anthropic opozarja, da lahko močno povečanje prometa preseže omejitve pospeška, in priporoča postopno povečevanje.
• Za večino Claude modelov, Anthropic dokumenti, ki vhodne žetone za branje v predpomnilniku ne štejejo k omejitvam vnosnih žetonov na minuto, kar pomeni, da lahko hitro predpomnjenje spremeni efektivni prostor.
• Google Gemini API omejitve stopnje so vezane na ravni uporabe projekta, pri čemer so višje stopnje odvisne od nastavitve obračunavanja, skupne porabe in časa, ki je pretekel po plačilnih mejnikih.

Operativna lekcija je jasna: OpenAI-združljiva oblika zahteve ne pomeni OpenAI-združljivega vedenja kvote. Prehod z več ponudniki potrebuje model notranjih kvot, ki je bogatejši od »ponovno poskusi, če je 429«.

Cilj načrtovanja: nadzor vstopa naj postane odgovornost prehoda

Prehod, ki pozna omejitev hitrosti, bi moral odgovoriti na pet vprašanj, preden pošlje zahtevo:

1. Kateri ponudnik, model, uvedba, regija, projekt ali delovni prostor bo prejel zahtevo?
2. Koliko zmogljivosti zahteve, vhodnega žetona, izhodnega žetona in sočasnosti lahko porabi?
3. Kateremu najemniku, ekipi, API ključu, stranki ali razredu delovne obremenitve je treba zaračunati skupno zmogljivost?
4. Ali je treba zahtevo sprejeti zdaj, na kratko postaviti v čakalno vrsto, znižati, preusmeriti drugam ali zavrniti?
5. Kako je treba rezervacijo uskladiti, potem ko ponudnik vrne dejansko uporabo?

Prehod postane regulator kvote. Ne nadomešča omejitev ponudnika. Zaradi tega so omejitve ponudnika vidne, predvidljive in pravične znotraj vašega sistema.

Izdelajte normaliziran model kvote

Začnite z definiranjem notranjih dimenzij omejevalnika, ki lahko predstavljajo glavne ponudnike, ne da bi jih silili v eno zavajajočo vedro.

Priporočene mere omejevalnika

• RPM: zahtev na minuto.
• Vhodni TPM: poziv, sporočilo, orodje in žetoni konteksta na minuto.
• Izhodni TPM: žetoni dokončanja na minuto, rezervirani ločeno za pretakanje in dolge generacije.
• Skupni TPM: uporaben za ponudnike ali uvedbe, ki so izpostavljene kombiniranemu pritisku žetonov.
• Sočasnost: aktivne zahteve, aktivni tokovi ali opravila med letom.
• Trajanje pretakanja: dolgotrajni tokovi lahko zasedejo prostor za povezavo in izhodni žeton, tudi če je RPM nizek.
• Obseg, specifičen za ponudnika: naročnina/regija/uvedba Azure, Anthropic razred delovnega prostora/modela, Google projekt/stopnja ali OpenAI skupina organizacija/projekt/model.

Ne skrivaj dimenzij, specifičnih za ponudnika. Normalizirajte jih v skupno shemo, vendar ohranite dovolj podrobnosti za kasnejšo razlago zavrnitve.

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

Ta notranji objekt je treba konfigurirati eksplicitno, ne pa izpeljati zgolj iz imen modelov. Nadzorne plošče ponudnika, ravni računa, regionalne uvedbe in nastavitve delovnega prostora lahko spremenijo učinkovito zmogljivost iste družine modelov.

Ocena pritiska žetona pred pošiljanjem

Omejevanje cene na strani ponudnika se pogosto zgodi, preden je znana končna poraba zaračunavanja. Vaš prehod bi moral opraviti enako konzervativno oceno, preden pošlje promet.

Vnosi rezervacij pred letom

• Serializirani poziv in dolžina sporočila.
• Tokenizacija, specifična za model, in režijski stroški za vloge, orodja, slike ali strukturirana izhodna navodila.
• max_completion_tokens ali enakovredna izhodna omejitev.
• Preteklo razmerje dokončanja za to končno točko, najemnika, profil modela in razred zahteve.
• Pričakovani žetoni za branje predpomnilnika, če je hitro predpomnjenje na voljo in ga je mogoče izmeriti.
• Oznaka pretakanja in pričakovano trajanje pretakanja.

Za začetek je pogosto dovolj preprosto pravilo rezervacije:

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 neznane poti uporabite konzervativno privzeto. Za stabilne proizvodne poti nenehno posodabljajte ocene glede na dejansko uporabo.

Rezerviraj, nato uskladi

Rezervacije kvote ne bi smele postati stalne bremenitve. Obravnavajte jih kot zadržke:

1. Citat: oceni vhodni in izhodni tlak.
2. Rezerva: odštejte od ustreznih žetonov pred odpremo.
3. Poravnava: zamenjajte oceno s porabo, ki jo poroča ponudnik, ko je na voljo.
4. Vračilo ali bremenitev: po potrebi vrnite neuporabljeno rezervirano kapaciteto ali zaračunajte presežke v naslednjem oknu.

To je najpomembnejše za klice z dolgim kontekstom in pretočne klice. Če pred pošiljanjem preverite samo vhodni TPM, se lahko tok uspešno zažene in pozneje naleti na pritisk izhodnega žetona. Z ločeno rezervacijo izhodne višine se zmanjša napaka na sredini toka in tveganje zastoja.

Uporaba hierarhičnih žetonov za pravičnost najemnikov

En sam globalni omejevalnik ščiti račun ponudnika, ne ščiti pa najemnikov drug pred drugim. Eno paketno opravilo z dolgim kontekstom lahko porabi TPM v skupni rabi in povzroči neuspešne interaktivne zahteve drugih skupin.

Uporaba hierarhičnih veder žetonov:

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

Zahteva mora prestati vsako ustrezno vedro. To vam omogoča uveljavljanje več pravilnikov hkrati:

• Organizacija ne sme preseči zmogljivosti ponudnika.
• Najemnik ne more porabiti več, kot znaša njegov pogodbeni delež.
• Ključ API ne sme preseči predvidene omejitve okolja ali aplikacije.
• Profil paketnega modela ne more izčrpati profila interaktivnega modela.
• Uvedbe ponudnika ni mogoče preobremeniti, tudi če ima druga uvedba rezervno kvoto.

Poštena delitev v primerjavi z uporabo

Priporočilo: uporabite ponderirano pošteno delitev z nadzorovano burno izposojo.

Stroge omejitve glede na najemnika je enostavno razložiti, vendar lahko povzročijo neuporabljeno zmogljivost. Burst sposojanje izboljša izkoriščenost tako, da najemniku omogoči začasno uporabo nedejavne kvote iz skupnega bazena. Kompromis je zapletenost: nadzorne plošče morajo pokazati, kaj je bilo zajamčeno, kaj je bilo izposojeno in kdaj je bilo izposojanje preklicano.

Praktično pravilo:

• Dajte vsakemu najemniku zajamčeno izhodišče.
• Dovoli začasno izposojo iz neuporabljene skupne zmogljivosti.
• Povrnitev izposojene zmogljivosti, ko se pojavi promet z višjo prioriteto ali zajamčen promet.
• Nikoli ne dovolite, da izposojeni promet ustvari 429 na ravni ponudnika za zajamčen promet.

Ločite prometne razrede, preden se spopadejo

Vse zahteve si ne zaslužijo enakega obnašanja v čakalni vrsti. Postavite promet v profile modelov z ločenimi čakalnimi vrstami in nabori kvot.

Čakalna vrsta izboljša stopnjo uspešnosti, vendar poveča zakasnitev repa. Prehod bi moral ta kompromis jasno navesti. Na primer, interaktivna zahteva lahko čaka do 300 milisekund na kvoto, nato pa se vrne ali ne uspe. Nočno paketno opravilo lahko počaka 20 minut in se vseeno šteje za uspešno.

Normaliziraj 429 v eno samo shemo napak

Tudi pri dobrem nadzoru sprejema se bodo številke 429 ponudnika še vedno pojavile. Omejitve se lahko spremenijo, ocene ponudnika se lahko razlikujejo od vaših in promet lahko prihaja v močnejših izbruhih od pričakovanega.

Normaliziraj vsakega ponudnika 429 v objekt napake prehoda:

{
  "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 po tem, ko je prehod sprejel zahtevo, se razlikuje od zahteve, ki jo je prehod zavrnil lokalno pred pošiljanjem. Prvi kaže na težavo s kalibracijo omejevalnika. Drugi pomeni namerno zaščito.

Prilagodi se glavam ponudnika, vendar ne bodi odvisen od njih

Nekateri ponudniki vrnejo uporabne glave, kot so indikatorji ponovnega poskusa ali preostale zmogljivosti. Uporabite jih, ko so na voljo.

Priporočilo: glave ponudnika naj prilagodijo vaš lokalni guverner, ne pa ga nadomestijo.

Razlogi:

• Razpoložljivost glave se razlikuje glede na ponudnika in končno točko.
• Glave morda ne bodo izpostavile vseh dimenzij omejevalnika.
• Retry-after vam pove, kdaj poskusite znova, ne kateri najemnik naj prejme zmogljivost naslednji.
• Ocene žetonov na strani ponudnika se lahko razlikujejo od vašega obračunavanja ali internega računovodstva.

Močna izvedba posodablja lokalne stopnje ponovnega polnjenja vedra in ohlajanja na podlagi glav, hkrati pa še vedno uveljavlja omejitve najemnika, API ključa, razreda prometa in uvedbe ponudnika znotraj prehoda.

Dodaj regulatorje rampe za selitve in načrtovana opravila

Med načrtovanimi spremembami se zgodi veliko incidentov z omejitvijo hitrosti: prehod z enega modela na drugega, menjava ponudnikov, omogočanje novega delovnega toka posrednika ali zagon načrtovanega ocenjevanja.

Priporočilo: rast prometa obravnavajte kot nadzorovano uvajanje.

• Migracije modela zastavic funkcij po najemniku, poti ali odstotku prometa.
• Nastavite zgornje meje rasti na minuto za uvedbe novih ponudnikov.
• Ogrevajte promet postopoma več ur, namesto da takoj preklopite ves promet.
• Zaustavi uvajanje, ko stopnja 429, stopnja znižanja, globina čakalne vrste ali zakasnitev p95 preseže prag.
• Ohranite pot za nujno vrnitev s pravilnikom o združljivosti, ne samo z rezervnim modelom.

Predvidevanje: ko bodo načini usmerjanja ponudnika, prednostne ravni in kontrole na ravni delovnega prostora vse pogostejši, bo upravljanje rampe postalo standardna funkcija prehoda in ne skript za odziv na incident.

Nadomestna rešitev je odločitev politike, ne le odločitev glede zmogljivosti

Ko en ponudnik vrne 429, je lahko usmerjanje k drugemu ponudniku pravi odgovor. Morda tudi ni varno.

Nadomestna možnost se lahko spremeni:

• Kakovost izhoda in naslednja navodila.
• Dolžina konteksta.
• Vedenje klica orodja.
• Zanesljivost strukturiranih izhodov.
• Hranjenje podatkov in drža prebivališča.
• Cena in zakasnitev.

Guverner kvote mora združljivostno plast vprašati, ali je za ta razred zahteve dovoljen nadomestni način. Če ne, bi se moral postaviti v čakalno vrsto ali odpovedati z jasnim odzivom lokalne omejitve hitrosti, namesto da tiho spreminja semantiko.

Izpostavite nadzorne plošče kvot, ki pojasnjujejo odločitve

Sistem kvot, ki ga nihče ne razume, bo zaobšel. Zgradite nadzorne plošče okoli operativnih vprašanj:

• Kateri najemniki porabijo največ RPM, vhodnega TPM in izhodnega TPM?
• Kateri profili modelov so v čakalni vrsti, zavračajo ali se vračajo?
• Kateri obseg ponudnika je ozko grlo: projekt, regija, uvedba, delovni prostor, razred modela ali raven računa?
• Kako pogosto se ocene prehoda razlikujejo od uporabe ponudnika?
• Kakšna je porazdelitev po ponovnem poskusu glede na ponudnika in vrsto omejevalnika?
• Koliko učinkovitega prostora ustvarijo takojšnja branja predpomnilnika?
• Kateri prometni razredi si izposojajo razpočno zmogljivost?

Za izdelke, namenjene strankam ali partnerjem, izpostavite varne kontrole:

• Omejitve hitrosti na ključ.
• Omejitve izbruhov na ekipo.
• Dnevne omejitve na stranko.
• Premor v sili za najemnika ali ključ.
• Opozorila za 429 konic, rast čakalne vrste in nenormalen pritisk žetonov.
• Partner API končne točke za upravljanje kvot preprodajalcev.

To spremeni omejevanje hitrosti iz skrivnostne napake ponudnika v revizijski del upravljanja skupine API.

Kontrolni seznam za implementacijo

1. faza: opazovanje in razvrščanje

• Ponudnik dnevnika, model, uvedba, regija, delovni prostor, projekt, najemnik, API ključ in razred zahteve za vsak klic.
• Zajemi ponudnikove 429 s ponovnim poskusom in neobdelanimi metapodatki o napakah.
• Ločeno zabeležite ocenjene in dejanske vhodne/izhodne žetone.
• Ločite interaktivni, paketni, eval in promet v ozadju v telemetriji.

2. faza: lokalni sprejemni nadzor

• Ustvarite notranje omejevalne objekte za RPM, vhodni TPM, izhodni TPM, skupni TPM in sočasnost.
• Dodajte oceno žetona pred tiskom.
• Rezervirajte kvoto pred pošiljanjem in uskladite, ko ponudnik prispe.
• Zavrni lokalno, ko zahteva ne ustreza svojemu vedru najemnika ali ponudnika.

3. faza: pravičnost in čakalne vrste

• Dodajte hierarhične segmente iz organizacije v uvedbo ponudnika.
• Dodelite zajamčene deleže najemnikov in nadzorovano izbruh zadolževanja.
• Ustvarite ločene čakalne vrste glede na prometni razred.
• Nastavite najdaljše čakalne dobe in nadomestna pravila, specifične za razred.

4. faza: prilagajanje in delovanje

• Uporabite glave ponudnika za prilagoditev ohlajanja in predpostavk o polnjenju.
• Dodaj regulatorje rampe za selitve in načrtovana opravila.
• Izpostavite nadzorne plošče kvot in opozorila.
• Tedensko preglejte napako ocene in nasedlo kvoto.

Dejanski sklep

Če vaš prehod samo znova poskusi 429s, po napaki deluje. Produkcijski razred AI API prehod bi moral preprečiti večino napak pri omejitvi hitrosti z odločanjem o tem, komu je dovoljeno pošiljati kaj, kdaj in glede na kvoto katerega ponudnika.

Začnite z normaliziranim modelom omejevalnika, rezervacijo žetona pred tiskom in čakalnimi vrstami prometnega razreda. Nato dodajte hierarhično pravičnost najemnikov, prilagoditev glave ponudnika in regulatorje rampe. Rezultat ni le manj 429-k. To je jasnejša dodelitev zmogljivosti, bolj predvidljiva zakasnitev, varnejše selitve in vedenje pri omejitvah hitrosti, ki jih lahko dejansko razložijo vaše ekipe za inženiring, finance in podporo strankam.

Sorodno branje

• rezervacija pred tiskom in usklajevanje uporabe
• prompt cache računovodstvo in analitika zadetkov predpomnilnika
• združljivi pravilniki o nadomestnem usmerjanju