Sådan opbygger du en udbyderneutral rategrænsemægler for multimodel LLM API'er

Når flere teams deler flere LLM-udbydere, stopper takstbegrænsning med at være en udbyder-integrationsdetalje. Det bliver et problem med delt kapacitet. En udbyder kan begrænse anmodninger og inputtokens, en anden kan adskille input- og outputtokens, og en tredje kan anvende kvoter på projektniveau eller på tværs af et rullende forbrugsvindue. En genforsøgsløkke inden for hver SDK kan ikke koordinere disse begrænsninger på tværs af lejere, applikationer, partnernøgler og modelruter.

Den praktiske løsning er en centralkursgrænsemægler ved gatewayen. Mægleren estimerer efterspørgsel, reserverer kapacitet før afsendelse, sætter i kø eller afviser arbejde i henhold til politik og afstemmer reservationen med faktisk brug efter afslutning. Udbyderens svar forfiner derefter mæglerens syn på tilgængelig kapacitet i stedet for at udløse uafhængige genforsøgsstorme.

Denne arkitektur er nyttig for enhver enterprise LLM API, der har brug for forudsigelig gennemstrømning på tværs af interne teams, produktionsapplikationer, automatiseringsagenter eller eksterne partnere.

Hvorfor udbydertakstgrænser ikke kan reduceres til anmodninger pr. minut

Fakta: Udbyderkvoter bruger forskellige dimensioner og omfang. Almindelige dimensioner omfatter anmodninger pr. minut, inputtokens pr. minut, outputtokens pr. minut, samlede tokens, anmodninger pr. dag, samtidighed, forbrugsvinduer og accelerations- eller rampehastighedsgrænser. Den samme udbyder kan afsløre forskellige grænser for en organisation, projekt, arbejdsområde, model eller API produkt.

For eksempel beskriver udbyderdokumentationen kombinationer som:

• Grænser for anmodning og token med resterende kapacitet og nulstillingsoplysninger i svaroverskrifter.
• Særskilte input-token- og output-token-grænser for meddelelses-API'er.
• Kvoter på projektniveau i stedet for kvoter knyttet til individuelle API nøgler.
• Daglige anmodningsgrænser, der nulstilles på et udbyderdefineret tidspunkt.
• Rullende forbrugsbaserede vinduer, der kan afvise trafik, selv når forespørgsels- og tokensatser ser ud til at være acceptable.
• Accelerationsgrænser, der reagerer på en kraftig stigning i trafikken, selv når steady-state-forbruget er under den offentliggjorte kvote.

En gateway, der kun gemmer ét nummer kaldet provider RPM, vil i sidste ende overadministrere trafik i én dimension eller underudnytte kapacitet i en anden. Den kan heller ikke forklare, om et afslag kom fra en lejerpolitik, en udbyders projektkvote, en daglig grænse eller et overbelastningssvar.

Referencearkitektur for en mægler med satsgrænse

Placer mægleren i anmodningsstien før udbyderadapteren. Hver anmodning skal passere gennem det samme reservationsflow, uanset om den ankom via en SDK, en intern tjeneste, en automatiseringsagent eller en partner API-nøgle.

1. Normaliser identitet. Løs organisation, lejer, team, applikation, miljø, partner, API nøgle, modelrute og arbejdsbelastningsklasse.
2. Estimer efterspørgsel. Beregn forventede inputtokens, maksimale outputtokens, estimeret forbrug og eventuelle samtidige omkostninger.
3. Evaluer politik. Tjek lejerbudgetter, køfrister, ruteberettigelse, prioritet og reserveregler.
4. Reservekapacitet. Atomisk reserver kapacitet i de relevante interne og udbyder-vendte spande.
5. Afsendelse. Send kun anmodningen, når reservationen lykkes.
6. Afstem. Erstat estimater med faktisk forbrug, frigiv ubrugte reservationer og optegn udbyderens overskrifter og svarklassifikation.
7. Beslut den næste handling. Returner resultatet, sæt arbejdet i kø, prøv igen centralt, fald tilbage eller afvis det i henhold til arbejdsbyrdekontrakten.

Reservationstjenesten skal være horisontalt skalerbar, men dens beslutning skal være atomisk for hver anmodning. En distribueret tæller, der tillader to arbejdere at observere den samme resterende kapacitet, kan genskabe udbyderens 429-problem inde i gatewayen.

Brug en kanonisk kvotemodel uden at skjule udbyderforskelle

Definer en kanonisk model, der kan repræsentere udbyderspecifikke begrænsninger i stedet for at tvinge hver udbyder til én abstraktion.

Repræsenter hver grænse som en kurv med et omfang, kapacitet, genopfyldnings- eller nulstillingsregel, enhed og kilde. En udbyderprojektsamling kan indeholde anmodninger og inputtokens. En arbejdsområdebøtte kan indeholde outputtokens. En intern partnerpolitik kan tilføje samtidighed og forbrugsgrænser. Optagelsesbeslutningen er kun vellykket, hvis alle nødvendige reservationer lykkes.

Behandl ikke udbyderens overskrifter som en komplet kilde til sandhed. Brug dem til at rette mæglerens estimater, men behold en konfigureret model for grænser, der ikke er eksponeret ved hvert svar. Headernavne, tilgængelighed og semantik til nulstilling varierer afhængigt af udbyder og rute.

Reserver tokens før afsendelse, og afstem dem derefter

Tokenreservation er den vigtigste forskel mellem en mægler og en genforsøgsindpakning. Mægleren har brug for et efterspørgselsestimat, før anmodningen sendes.

For inputtokens, estimat fra de serialiserede meddelelser, værktøjsdefinitioner, struktureret output-skema og enhver hentet kontekst. For outputtokens skal du bruge anmodningsmaksimum, når det er tilgængeligt, eller et model- og arbejdsbelastningsspecifikt estimat, når klienten ikke leverer et. Behold estimatet knyttet til reservationen, så det kan sammenlignes med det faktiske forbrug senere.

En simpel reservationspost kan indeholde:

• En unik anmodning og reservations-id.
• Lejer, applikation, API-nøgle, rute og arbejdsbelastningsklasse.
• Estimerede input-tokens, output-tokens, samlede tokens og forbrug.
• Hver spand opkrævet af reservationen.
• Oprettelsestid, udløbstid, kø-deadline og idempotensnøgle.
• Endelig faktisk brug og det beløb, der frigives eller debiteres under afstemning.

Konservative skøn reducerer udbyderes 429-svar, men kan strande kapacitet. Mål estimeringsfejl efter model, rute, promptfamilie, kontekstlængde og struktureret output-tilstand. Juster derefter estimater ved hjælp af afgrænsede korrektioner i stedet for at tillade en enkelt usædvanlig anmodning at forvrænge hele modellen.

Streaming kræver en specifik politik. Du kan reservere den maksimale output-kvote og frigive den ubrugte del, når streamen slutter, eller reservere outputkapacitet i mindre trin, efterhånden som tokens ankommer. Den første tilgang er lettere at ræsonnere om; den anden kan forbedre udnyttelsen, men kræver pålidelig annullering, timeout og håndtering af afbrydelser.

Håndhæv kvoter hierarkisk

Kapaciteten bør kontrolleres fra den smalleste politik til den bredeste delte ressource. Et typisk hierarki er:

1. API nøgle eller tjenesteidentitet.
2. Applikation og miljø.
3. Team- eller kundelejer.
4. Partner- eller forhandlerkonto.
5. Udbyderarbejdsområde eller underkonto.
6. Udbyderprojekt eller organisation.
7. Model og rute.

En anmodning fra en partnerapplikation kan derfor kræve fire vellykkede reservationer: partnerens samtidighedspolitik, kundens lejers tokenbudget, gatewayens rutetildeling og udbyderprojektets tilgængelige kvote. Hvis en reservation mislykkes, skal du frigive de allerede erhvervede reservationer og anvende den mislykkede buckets beslutning.

For retfærdighedens skyld skal du bruge vægtet retfærdig kø eller underskud round-robin i stedet for at tillade den medarbejder, der ankommer først, at forbruge den delte pulje. Tildel højere vægt til produktionstrafik og lavere vægt til baggrundsjob, mens du bevarer burst-kreditter for hver lejer. Hård opdeling er lettere at forklare, men kan lade kapaciteten være inaktiv, når en lejer er stille. Vægtet deling bruger generelt kapaciteten mere effektivt, forudsat at støjende lejere har begrænsede burst-grænser.

Design køer omkring arbejdsbyrdekontrakter

En kø er ikke automatisk en pålidelighedsfunktion. Det kan forvandle en synlig 429 til en usynlig ti minutters forsinkelse. Hver køklasse har brug for en deadline, annulleringsadfærd, maksimal dybde og overbelastningshandling.

• Interaktiv: Kort deadline, lille kø, forudsigelig afvisning eller modelforringelse, når kapaciteten ikke er tilgængelig.
• Produktionsbaggrund: Længere deadline, holdbar kø, idempotensnøgle og kontrolleret budget for genforsøg.
• Partner: Lejerspecifikke kvoter, offentliggjorte svarmetadata og ingen adgang til en anden lejers køtilstand.
• Batchbar: Forsinket udførelse, større kø og valgfri routing til en udbyder-batch API, når arbejdsbyrden tillader det.

Optagelse i kø bør give en klar beslutning. Depending on the API contract, expose a 429 or a gateway-specific overload response with a retry-after value, queue identifier, and reason code. Lov ikke en færdiggørelsestid, medmindre systemet kan håndhæve dette løfte.

Batch processing can remove noninteractive work from synchronous capacity, but it changes result timing, retry behavior, cancellation, and reconciliation. Behandl det som en separat udførelsessti i stedet for blot at placere synkrone anmodninger i en meget lang kø. For baggrundsarbejdsbelastninger skal du sammenligne de operationelle afvejninger med AI API omkostningskontrolpolitikker og eksisterende batch-operationer.

Centraliser forsøg igen og overbelastningshåndtering

Fact: Temporary rate-limit responses commonly use HTTP 429, while provider overload conditions may use 503 or a provider-specific error code. Nogle udbydere returnerer en Retry-After-header, og udbyderdokumentationen anbefaler, at man respekterer den, når den er til stede. En hurtig trafikrampe kan også fremkalde acceleration eller opbremsning uden almindelig skovludmattelse.

Anbefaling: Behandl Prøv igen-efter som en nedre grænse, ikke som et valgfrit forslag. Pause the affected provider scope until that time, add bounded jitter to prevent synchronized wake-ups, and let the broker decide which queued requests can use the recovered capacity.

Når Retry-After er fraværende eller ugyldig, skal du bruge begrænset eksponentiel backoff med jitter. Behold genforsøgsbudgettet i mægleren, ikke separat i hver SDK og udbyderadapter. Ellers kan én logisk anmodning producere et gateway-genforsøg, et SDK-gentag, et HTTP-klientforsøg og et genafspilning på udbydersiden.

Klassificer fejl, før du prøver igen:

• Gentagelig kapacitet: Midlertidig 429 eller dokumenteret forbigående kvotesvar.
• Gentagelig overbelastning: Midlertidig 503 eller tilsvarende udbyder overbelastningssignal.
• Politikfejl, der ikke kan prøves igen: Daglig kvote, forbrugsloft, deaktiveret projekt eller lejergrænse.
• Anmodningsfejl, der ikke kan prøves igen: Ugyldigt skema, ikke-understøttet parameter, godkendelsesfejl eller forkert udformet input.
• Deadlinefejl: En anmodning, hvis resterende bruger- eller arbejdsgangsfrist er kortere end det næste sikre forsøg.

Tilbagefald er en separat beslutning. En anden udbyder kan have forskellig outputadfærd, prissætning, latenstid, opholdstilladelse eller kontekstgrænser. Brug kun fallback, når rutepolitikken bekræfter, at arbejdsbyrdekontrakten kan tolerere disse forskelle.

Afslør beslutninger og mål mætning

Teams kan ikke fejlfinde throttling, hvis gatewayen kun returnerer en generisk 429. Returner sikre metadata såsom den gældende grænse, resterende kapacitet, nulstillingstid, købeslutning, arbejdsbelastningsklasse og afvisningsårsag. Undgå at afsløre en anden lejers brug eller rå udbyderoplysninger.

Sæt som minimum:

• Reservationssucces og afvisningsrate efter lejer, rute og bucket.
• Kødybde, ventetid i kø, udløb af frister og aflysninger.
• Udbyder 429- og 503-takster, Retry-After-frekvens og rampe-rate afvisninger.
• Estimeret versus faktisk tokenbrug og kapacitet spildt ved overreservation.
• Samtidighedsmætning og andelen af kapacitet, der forbruges af hver lejer.
• Prøv igen pr. logisk anmodning og fallback-frekvens.
• Daglig kvote og frihøjde i forbrugsvinduet.

Belastningstest bør omfatte burst-trafik, langkontekstanmodninger, maksimale outputanmodninger, streamingafbrydelser, daglig kvoteopbrug, udbyder 429- og 503-svar og én støjende lejer, der konkurrerer med produktionstrafik. Valider ikke kun, om anmodninger til sidst fuldføres, men også om køfrister, retfærdighed og budgetter for genforsøg forbliver intakte.

Implementeringstjekliste

• Definer kanoniske dimensioner uden at kassere udbyderspecifikke grænser.
• Tildel hver anmodning en normaliseret lejer, rute, arbejdsbelastningsklasse og idempotensnøgle.
• Estimer og reserver input, output, samlede tokens, forbrug, anmodninger og samtidighed før afsendelse.
• Gør multi-bucket reservationer atomiske og udløb forladte reservationer sikkert.
• Afstem faktisk udbyderbrug og svaroverskrifter efter hvert forsøg.
• Brug vægtet retfærdighed, burst-kreditter og eksplicitte prioritetsklasser.
• Giv hver kø en deadline, maksimal dybde og overbelastningshandling.
• Centraliser genforsøg, og respekter udbyderens Gentry-After-værdier.
• Adskil midlertidige kapacitetsfejl fra permanent politik og anmodningsfejl.
• Offentliggør reguleringsmetadata og overvåg mætning efter lejer og rute.
• Test udbyderkvoteopbrug, rampegrænser, streaming, fallback og støjende naboadfærd.

Konklusion

En multimodel-gateway bør administrere udbyderkvoter som delt infrastrukturkapacitet, ikke som en samling af uafhængige SDK-indstillinger. En udbyderneutral prisgrænsemægler giver platformsteams én adgangsvej, én retfærdighedspolitik, én genforsøgsbudget og ét sted at afstemme estimater med virkeligheden.

Designet kræver mere end en generisk token-bøtte. Det skal repræsentere anmodninger, input- og outputtokens, daglige kvoter, forbrugsvinduer, samtidighed, udbyderomfang og rampehastighed. Når disse dimensioner er eksplicitte, kan gatewayen træffe forudsigelige valg: afsendes nu, stå i kø med en deadline, afskedige arbejde, prøve igen centralt eller bruge en kontraktsikker reserve. Det er sådan gennemløbskontrol bliver en operationel kapacitet snarere end en tilbagevendende kilde til produktions 429 og 503 hændelser.

Relateret læsning

• batchbehandling for ikke-interaktive LLM-arbejdsbelastninger