Rate-Limit-Aware AI API Gateways: Shape RPM, TPM, Bursts og Tenant Fairness Before 429s Hit
En praktisk gateway-arkitektur til at forhindre cascading LLM API 429'er: normaliser udbydergrænser, estimer tokentryk før afsendelse, reserver kvote for lejer, udjævn trafikramper, og gør reguleringen auditbar.
En 429 fra en LLM-udbyder er ikke bare et genforsøgssignal. I produktionen er det ofte et bevis på, at din ansøgning allerede har mistet kontrollen over optagelse, lejers retfærdighed, latens eller udbyderspecifik kvoteregnskab.
Den fælles rettelse – eksponentiel backoff – er nødvendig, men ufuldstændig. Backoff reagerer, efter at udbyderen afviser trafik. En hastighedsgrænsebevidst AI API-gateway bør forme trafikken, før anmodninger forlader dit system: estimer tokentryk, reserver kvote, isoler lejere, sæt det rigtige arbejde i kø, afvis det forkerte arbejde og tilpas, når udbydergrænserne ændres.
Denne artikel beskriver en praktisk gateway-kvoteregulator for teams, der sender produktionsarbejdsbelastninger til flere LLM-udbydere gennem en samlet API.
Læserproblemet: 429'ere er multidimensionelle
Mange teams behandler takstgrænser, som om de var et enkelt antal anmodninger pr. minut. Den antagelse bryder hurtigt med LLM API'er.
Fakta fra aktuel udbyderdokumentation:
- OpenAI dokumenterer, at grænser kan håndhæves over kortere vinduer end den annoncerede pr. minut-grænse, så korte bursts kan mislykkes, selv når det gennemsnitlige minut ser sikkert ud.
- Azure OpenAI-kvoten tildeles efter abonnement, region, model og implementeringstype i tokens pr. minut. Tildeling af TPM til en implementering bestemmer også påtvungne RPM-grænser, og RPM-til-TPM-forhold varierer efter model.
- Azure OpenAI bemærker også, at beregninger af rate-limit tokens estimeres, når anmodningen modtages og ikke er det samme som endelige faktureringstokentællinger.
- Antropiske dokumenter adskiller grænser for anmodninger pr. minut, input-tokens pr. minut og output-tokens pr. minut. Overskridelse af grænser returnerer en 429 med en gentagelsesoverskrift.
- Anthropic advarer om, at kraftige trafikstigninger kan ramme accelerationsgrænserne og anbefaler en gradvis stigning.
- For de fleste Claude-modeller tæller Anthropic-dokumenter om, at cache-læste inputtokens ikke tæller med i input-token-per-minute grænser, hvilket betyder, at hurtig caching kan ændre den effektive frihøjde.
- Satsgrænser for Google Gemini API er bundet til projektbrugsniveauer, med højere niveauer afhængigt af faktureringsopsætning, kumulativt forbrug og forløbet tid efter betalingsmilepæle.
Den operationelle lektie er klar: En OpenAI-kompatibel anmodningsform indebærer ikke OpenAI-kompatibel kvoteadfærd. En gateway med flere udbydere har brug for en intern kvotemodel, der er mere rig end "prøv igen hvis 429."
Designmål: Gør adgangskontrol til et gatewayansvar
En gateway, der er bevidst om hastighedsgrænsen, skal besvare fem spørgsmål, før du sender en anmodning:
- Hvilken udbyder, model, implementering, region, projekt eller arbejdsområde vil modtage anmodningen?
- Hvor meget anmodnings-, input-token, output-token og samtidighedskapacitet kan det forbruge?
- Hvilken lejer, team, API-nøgle, kunde eller arbejdsbelastningsklasse skal debiteres delt kapacitet?
- Skal anmodningen indrømmes nu, stilles kort i kø, nedgraderes, dirigeres andre steder hen eller afvises?
- Hvordan skal reservationen afstemmes, efter at udbyderen returnerer det faktiske forbrug?
Gatewayen bliver en kvoteguvernør. Det erstatter ikke udbydergrænser. Det gør udbydergrænser synlige, forudsigelige og retfærdige i dit eget system.
Byg en normaliseret kvotemodel
Start med at definere interne begrænserdimensioner, der kan repræsentere de store udbydere uden at tvinge dem ind i en vildledende bøtte.
Anbefalede begrænserdimensioner
- RPM: anmodninger pr. minut.
- Input TPM: prompt, besked, værktøj og konteksttokens pr. minut.
- Output TPM: færdiggørelsestokens pr. minut, reserveret separat til streaming og lange generationer.
- Samlet TPM: nyttigt for udbydere eller implementeringer, der afslører kombineret tokentryk.
- Samtidig: aktive anmodninger, aktive streams eller job under flyvningen.
- Streamingsvarighed: langlivede streams kan optage forbindelse og output-token frihøjde, selv når RPM er lavt.
- Udbyderspecifikt omfang: Azure-abonnement/region/implementering, Antropisk arbejdsområde/modelklasse, Google-projekt/niveau eller OpenAI-organisation/projekt/modelgruppe.
Skjul ikke udbyderspecifikke dimensioner. Normaliser dem til et fælles skema, men bevar nok detaljer til at forklare en afvisning senere.
Dette interne objekt skal konfigureres eksplicit, ikke udledes af modelnavne alene. Udbyderdashboards, kontoniveauer, regionale implementeringer og arbejdsområdeindstillinger kan alle ændre den effektive kapacitet i den samme modelfamilie.
Estimer tokentryk før afsendelse
Taxebegrænsning på udbydersiden sker ofte, før det endelige faktureringsforbrug er kendt. Din gateway bør lave den samme slags konservative estimat, før du sender trafik.
Indgange til forudgående reservation
- Serialiseret prompt og beskedlængde.
- Modelspecifik tokenisering og overhead for roller, værktøjer, billeder eller strukturerede outputinstruktioner.
max_completion_tokenseller tilsvarende output cap.- Historisk fuldførelsesforhold for dette slutpunkt, lejer, modelprofil og anmodningsklasse.
- Forventede cache-læste tokens, hvis prompt caching er tilgængelig og målbar.
- Streamingflag og forventet streamvarighed.
En simpel reservationsregel er ofte nok til at starte:
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_tokensFor ukendte ruter skal du bruge en konservativ standard. For stabile produktionsruter skal du opdatere estimater løbende fra det faktiske forbrug.
Reserver, og afstem derefter
Kvotereservationer bør ikke blive permanente gebyrer. Behandl dem som hold:
- Citat: estimer input- og outputtryk.
- Reserve: træk fra de relevante token-bøtter før afsendelse.
- Afgør: Erstat estimatet med udbyderrapporteret brug, når det er tilgængeligt.
- Refusion eller debitering: returner ubrugt reserveret kapacitet eller opkræve overskud til næste vindue, hvis det er nødvendigt.
Dette betyder mest for lange kontekst- og streamingopkald. Hvis du kun tjekker input-TPM før afsendelse, kan en stream starte med succes og derefter løbe ind i output-token-tryk senere. Ved at reservere outputhøjde separat reduceres midstream-fejl og risiko for stall.
Brug hierarkiske token-buckets for lejers retfærdighed
En enkelt global limiter beskytter udbyderkontoen, men beskytter ikke lejere mod hinanden. Ét batchjob med lang sammenhæng kan forbruge delt TPM og få interaktive anmodninger fra andre teams til at mislykkes.
Brug hierarkiske token-bøtter:
organisation
└── lejer
└── hold
└── api_key
└── model_profil
└── provider_deploymentEn anmodning skal bestå hver relevant bunke. Dette lader dig håndhæve flere politikker på én gang:
- Organisationen kan ikke overskride udbyderens kapacitet.
- En lejer kan ikke forbruge mere end sin aftalte andel.
- En API-nøgle må ikke overskride dens tilsigtede miljø- eller applikationsgrænse.
- En batchmodelprofil kan ikke udsulte en interaktiv modelprofil.
- En udbyderimplementering kan ikke overbelastes, selvom en anden implementering har en ekstra kvote.
Retfærdig deling versus udnyttelse
Anbefaling: brug vægtet rimelig deling med kontrolleret burst-låning.
Strenge per-lejer-lofter er nemme at forklare, men kan strande ubrugt kapacitet. Burst-lån forbedrer udnyttelsen ved at tillade en lejer midlertidigt at bruge ledig kvote fra en delt pulje. Afvejningen er kompleksitet: dashboards skal vise, hvad der var garanteret, hvad der blev lånt, og hvornår lånet blev tilbagekaldt.
En praktisk regel:
- Giv hver lejer en garanteret baseline.
- Tillad burst-lån fra uudnyttet delt kapacitet.
- Genvinde lånt kapacitet, når højere prioritet eller garanteret trafik vises.
- Lad aldrig lånt trafik skabe 429'er på udbyderniveau for garanteret trafik.
Adskil trafikklasser, før de kæmper
Ikke alle anmodninger fortjener den samme køadfærd. Sæt trafik i modelprofiler med separate køer og kvotepuljer.
Kø forbedrer succesraten, men øger haleforsinkelsen. En gateway bør gøre denne afvejning eksplicit. For eksempel kan en interaktiv anmodning vente op til 300 millisekunder på kvoten og derefter falde tilbage eller mislykkes. Et batchjob hver nat kan vente 20 minutter og stadig blive betragtet som vellykket.
Normaliser 429s til et enkelt fejlskema
Selv med god adgangskontrol vil udbyder 429s stadig forekomme. Grænserne kan ændre sig, udbyderes estimater kan afvige fra dine, og trafikken kan ankomme i skarpere udbrud end forventet.
Normaliser hver 429 udbyder til et gateway-fejlobjekt:
Nøglefeltet er gateway_decision. Et 429, efter at gatewayen har indrømmet anmodningen, er forskellig fra en anmodning, som gatewayen afviste lokalt før afsendelse. Den første angiver et problem med begrænserkalibrering. Det andet angiver forsætlig beskyttelse.
Tilpas fra udbyderens overskrifter, men afhængig ikke af dem
Nogle udbydere returnerer nyttige overskrifter såsom indikatorer for genforsøg efter eller resterende kapacitet. Brug dem, når de er tilgængelige.
Anbefaling: udbyderoverskrifter bør justere din lokale guvernør, ikke erstatte den.
Årsager:
- Tilgængeligheden af overskrifter varierer efter udbyder og slutpunkt.
- Overskrifter viser muligvis ikke alle begrænserdimensioner.
- Prøv igen efter fortæller dig, hvornår du skal prøve igen, ikke hvilken lejer der skal få kapacitet næste gang.
- Toksestimater på udbydersiden kan afvige fra din fakturering eller dit interne regnskab.
En robust implementering opdaterer lokale bucket-genopfyldningshastigheder og nedkøling baseret på overskrifter, mens den stadig håndhæver grænser for lejer, API-nøgle, trafikklasse og udbyderimplementering inde i gatewayen.
Tilføj ramperegulatorer til migreringer og planlagte job
Mange hændelser med hastighedsgrænser sker under planlagte ændringer: flytning fra en model til en anden, skift af udbydere, aktivering af en ny agentarbejdsgang eller lancering af en planlagt evalueringskørsel.
Anbefaling: Behandl trafikvækst som en kontrolleret udrulning.
- Migrationer af funktionsflag efter lejer, rute eller procentdel af trafikken.
- Indstil vækstlofter pr. minut for nye udbyderimplementeringer.
- Varm trafikken op gradvist over timer i stedet for at skifte al trafik med det samme.
- Sæt udgivelsen på pause, når 429-hastighed, nedgraderingshastighed, kødybde eller p95-latens passerer en tærskel.
- Bevar en nødstilbageføringsrute med en kompatibilitetspolitik, ikke kun en reservemodel.
Forudsigelse: Efterhånden som udbyderroutingtilstande, prioritetsniveauer og kontrolelementer på arbejdsområdeniveau bliver mere almindelige, bliver rampestyring en standard gateway-funktion snarere end et hændelses-respons-script.
Tilbagefald er en politisk beslutning, ikke kun en kapacitetsbeslutning
Når en udbyder returnerer en 429, kan routing til en anden udbyder være det rigtige svar. Det kan også være usikkert.
Tilbagefald kan ændres:
- Outputkvalitet og følgende instruktioner.
- Kontekstlængde.
- Værktøjsopkaldsadfærd.
- Struktureret output-pålidelighed.
- Dataopbevaring og opholdsstilling.
- Pris og forsinkelse.
Kvoteguvernøren bør spørge et kompatibilitetslag, om det er tilladt at anvende reservekrav for denne anmodningsklasse. Hvis ikke, bør den stå i kø eller fejle med et tydeligt svar på lokal hastighedsgrænse i stedet for lydløst at ændre semantikken.
Afslør kvote-dashboards, der forklarer beslutninger
Et kvotesystem, som ingen kan forstå, vil blive omgået. Byg dashboards omkring operationelle spørgsmål:
- Hvilke lejere bruger mest RPM, input TPM og output TPM?
- Hvilke modelprofiler står i kø, afviser eller falder tilbage?
- Hvilket udbyderomfang er flaskehalsen: projekt, region, implementering, arbejdsområde, modelklasse eller kontoniveau?
- Hvor ofte adskiller gateway-estimater sig fra udbyderbrug?
- Hvad er fordelingen efter forsøg efter udbyder og begrænsertype?
- Hvor meget effektiv frihøjde skabes af prompt-cache-læsninger?
- Hvilke trafikklasser låner sprængkapacitet?
For produkter rettet mod kunder eller partnere skal du udsætte sikre kontroller:
- Pr. nøglehastighedsgrænser.
- Burstgrænser pr. hold.
- Daglige grænser pr. kunde.
- Nødpause for en lejer eller nøgle.
- Advarsler for 429 spidser, køvækst og unormalt tokentryk.
- Partner API-slutpunkter til administration af forhandlerkvoter.
Dette forvandler hastighedsbegrænsning fra en mystisk udbyderfejl til en reviderbar del af team API-styring.
Implementeringstjekliste
Fase 1: observer og klassificer
- Logudbyder, model, implementering, region, arbejdsområde, projekt, lejer, API-nøgle og anmodningsklasse for hvert opkald.
- Fang udbyder 429'er med genforsøg og rå fejlmetadata.
- Optag anslåede og faktiske input/output-tokens separat.
- Adskil interaktiv, batch-, eval- og baggrundstrafik i telemetri.
Fase 2: lokal adgangskontrol
- Opret interne begrænserobjekter for RPM, input TPM, output TPM, total TPM og concurrency.
- Tilføj estimering af preflight-token.
- Reserver kvote før afsendelse og afstem efter udbyderbrug ankommer.
- Afvis lokalt, når en anmodning ikke kan passe dens lejer eller udbyder.
Fase 3: retfærdighed og køer
- Tilføj hierarkiske buckets fra organisation til udbyderimplementering.
- Tildel garanterede lejerandele og kontrolleret burst-låning.
- Opret separate køer efter trafikklasse.
- Indstil klassespecifikke maksimale ventetider og reserveregler.
Fase 4: tilpasning og drift
- Brug udbyderoverskrifter til at justere nedkølings- og genopfyldningsantagelser.
- Tilføj ramperegulatorer til migreringer og planlagte job.
- Afslør kvotekontrolpaneler og underretninger.
- Gennemgå estimeringsfejl og strandet kvote ugentligt.
Aktiv konklusion
Hvis din gateway kun forsøger 429s igen, fungerer den efter fejlen. En AI API-gateway i produktionsgrad bør forhindre de fleste hastighedsgrænsefejl ved at bestemme, hvem der må sende hvad, hvornår og mod hvilken udbyderkvote.
Start med en normaliseret limiter-model, reservation af forudgående tokener og køer i trafikklasse. Tilføj derefter hierarkisk lejerretfærdighed, udbyder-header-tilpasning og ramperegulatorer. Resultatet er ikke kun færre 429s. Det er klarere kapacitetsallokering, mere forudsigelig ventetid, sikrere migreringer og rategrænseadfærd, som dine ingeniør-, økonomi- og kundesupportteam faktisk kan forklare.