Hvordan bygge en leverandørnøytral rategrensemegler for multi-modell LLM APIer

Når flere team deler flere LLM-leverandører, slutter takstbegrensning å være en leverandørintegrasjonsdetalj. Det blir et problem med delt kapasitet. Én leverandør kan begrense forespørsler og input-tokens, en annen kan skille input- og output-tokens, og en tredje kan bruke kvoter på prosjektnivå eller over et rullende forbruksvindu. En ny forsøksløkke i hver SDK kan ikke koordinere disse begrensningene på tvers av leietakere, applikasjoner, partnernøkler og modellruter.

Den praktiske løsningen er en sentralratemegler ved inngangsporten. Megler estimerer etterspørsel, reserverer kapasitet før utsendelse, setter i kø eller avviser arbeid i henhold til policy, og avstemmer reservasjonen med faktisk bruk etter ferdigstillelse. Leverandørens svar avgrenser deretter meglerens syn på tilgjengelig kapasitet i stedet for å utløse uavhengige stormer på nytt forsøk.

Denne arkitekturen er nyttig for alle enterprise LLM API som trenger forutsigbar gjennomstrømning på tvers av interne team, produksjonsapplikasjoner, automasjonsagenter eller eksterne partnere.

Hvorfor leverandørtakstgrenser ikke kan reduseres til forespørsler per minutt

Fakta: Leverandørkvoter bruker forskjellige dimensjoner og omfang. Vanlige dimensjoner inkluderer forespørsler per minutt, input-tokens per minutt, output-tokens per minutt, totalt antall tokens, forespørsler per dag, samtidighet, forbruksvinduer og akselerasjons- eller rampehastighetsgrenser. Den samme leverandøren kan avdekke ulike grenser for en organisasjon, et prosjekt, et arbeidsområde, en modell eller et API produkt.

For eksempel beskriver leverandørdokumentasjonen kombinasjoner som:

• Forespørsels- og tokengrenser med gjenværende kapasitet og tilbakestillingsinformasjon i svarhodene.
• Separate grenser for input-token og output-token for meldings-API-er.
• Kvoter på prosjektnivå i stedet for kvoter knyttet til individuelle API-nøkler.
• Daglige forespørselsgrenser som tilbakestilles på et leverandørdefinert tidspunkt.
• Rullende forbruksbaserte vinduer som kan avvise trafikk selv når forespørsels- og tokensatser ser ut til å være akseptable.
• Akselerasjonsgrenser som reagerer på en kraftig økning i trafikken, selv når steady-state-bruken er under den publiserte kvoten.

En gateway som bare lagrer ett nummer kalt provider RPM vil til slutt overadministrere trafikk i én dimensjon eller underbruke kapasitet i en annen. Den kan heller ikke forklare om et avslag kom fra en leietakerpolicy, en leverandørprosjektkvote, en daglig grense eller et overbelastningssvar.

Referansearkitektur for en rategrensemegler

Plasser megleren i forespørselsbanen før leverandøradapteren. Hver forespørsel skal gå gjennom den samme reservasjonsflyten, uavhengig av om den kom gjennom en SDK, en intern tjeneste, en automatiseringsagent eller en partner API-nøkkel.

1. Normaliser identitet. Løs organisasjonen, leietaker, team, applikasjon, miljø, partner, API nøkkel, modellrute og arbeidsbelastningsklasse.
2. Estimer etterspørsel. Beregn forventede input-tokens, maksimale output-tokens, estimert forbruk og eventuelle samtidige kostnader.
3. Evaluer policy. Sjekk leietakerbudsjetter, køfrister, rutekvalifisering, prioritet og reserveregler.
4. Reservekapasitet. Atomisk reservekapasitet i de relevante interne og leverandørvendte bøttene.
5. Utsending. Send forespørselen først etter at reservasjonen er vellykket.
6. Reconcile. Erstatt estimater med faktisk bruk, frigi ubrukte reservasjoner og postleverandøroverskrifter og svarklassifisering.
7. Beslutt neste handling. Returner resultatet, sett arbeidet i kø, prøv på nytt sentralt, fall tilbake eller avvis det i henhold til arbeidsbelastningskontrakten.

Reservasjonstjenesten bør være horisontalt skalerbar, men avgjørelsen må være atomær for hver forespørsel. En distribuert teller som lar to arbeidere observere den samme gjenværende kapasiteten, kan gjenskape 429-leverandørproblemet inne i gatewayen.

Bruk en kanonisk kvotemodell uten å skjule leverandørforskjeller

Definer en kanonisk modell som kan representere leverandørspesifikke begrensninger i stedet for å tvinge hver leverandør inn i én abstraksjon.

Representer hver grense som en bøtte med et omfang, kapasitet, påfyllings- eller tilbakestillingsregel, enhet og kilde. En leverandørprosjektbøtte kan inneholde forespørsler og inndatatokens. En arbeidsområdebøtte kan inneholde utdatatokens. En intern partnerpolicy kan legge til samtidighet og forbruksgrenser. Opptaksbeslutningen er vellykket bare hvis alle nødvendige reservasjoner lykkes.

Ikke behandle leverandøroverskrifter som en fullstendig kilde til sannhet. Bruk dem til å korrigere meglerens estimater, men behold en konfigurert modell for grenser som ikke er eksponert for hvert svar. Overskriftsnavn, tilgjengelighet og semantikk for tilbakestilling varierer etter leverandør og rute.

Reserver tokens før utsendelse, og avstem dem deretter

Tokenreservasjon er den viktigste forskjellen mellom en megler og en gjenforsøk. Megleren trenger et behovsanslag før forespørselen sendes.

For input-tokens, estimat fra de serialiserte meldingene, verktøydefinisjoner, strukturert utdataskjema og eventuell hentet kontekst. For utdata-tokens, bruk forespørselsmaksimum når det er tilgjengelig, eller et modell- og arbeidsbelastningsspesifikt estimat når klienten ikke gir et. Behold anslaget vedlagt reservasjonen slik at det kan sammenlignes med faktisk bruk senere.

En enkel reservasjonspost kan inneholde:

• En unik forespørsel og reservasjons-ID.
• Leietaker, applikasjon, API-nøkkel, rute og arbeidsbelastningsklasse.
• Anslåtte inndatatokener, utdatatokens, totale tokens og forbruk.
• Hver bøtte belastet av reservasjonen.
• Opprettelsestid, utløpstid, køfrist og idempotensnøkkel.
• Endelig faktisk bruk og beløpet som er frigitt eller belastet under avstemming.

Konservative anslag reduserer leverandørens 429-svar, men kan strande kapasiteten. Mål estimeringsfeil etter modell, rute, ledetekstfamilie, kontekstlengde og strukturert utdatamodus. Juster deretter estimatene ved å bruke avgrensede korrigeringer i stedet for å la en enkelt uvanlig forespørsel forvrenge hele modellen.

Strøming krever en spesifikk policy. Du kan reservere den maksimale utgangskvoten og frigjøre den ubrukte delen når strømmen avsluttes, eller reservere utgangskapasitet i mindre intervaller etter hvert som tokens kommer. Den første tilnærmingen er lettere å resonnere rundt; den andre kan forbedre utnyttelsen, men krever pålitelig kansellering, tidsavbrudd og håndtering av frakobling.

Håndheve kvoter hierarkisk

Kapasiteten bør kontrolleres fra den smaleste policyen til den bredeste delte ressursen. Et typisk hierarki er:

1. API nøkkel eller tjenesteidentitet.
2. Applikasjon og miljø.
3. Team- eller kundeleietaker.
4. Partner- eller forhandlerkonto.
5. Leverandørarbeidsområde eller underkonto.
6. Leverandørprosjekt eller organisasjon.
7. Modell og rute.

En forespørsel fra en partnerapplikasjon kan derfor trenge fire vellykkede reservasjoner: partnerens retningslinjer for samtidighet, kundens leietakers tokenbudsjett, gatewayens rutetildeling og leverandørprosjektets tilgjengelige kvote. Hvis en reservasjon mislykkes, frigi reservasjonene som allerede er anskaffet og bruk avgjørelsen til den mislykkede bøtten.

For rettferdighets skyld, bruk vektet rettferdig kø eller underskudd round-robin i stedet for å la den arbeidstakeren som kommer først, konsumere den delte poolen. Tildel høyere vekter til produksjonstrafikk og lavere vekter til bakgrunnsjobber, mens du beholder burst-kreditter for hver leietaker. Hard partisjonering er lettere å forklare, men kan la kapasiteten være inaktiv når en leietaker er stille. Vektet deling bruker vanligvis kapasiteten mer effektivt, forutsatt at støyende leietakere har begrensede burst-grenser.

Design køer rundt arbeidsbelastningskontrakter

En kø er ikke automatisk en pålitelighetsfunksjon. Det kan gjøre en synlig 429 til en usynlig ti-minutters forsinkelse. Hver køklasse trenger en tidsfrist, kanselleringsadferd, maksimal dybde og overbelastningshandling.

• Interaktiv: Kort tidsfrist, liten kø, forutsigbar avvisning eller modellforringelse når kapasiteten er utilgjengelig.
• Produksjonsbakgrunn: Lengre tidsfrist, varig kø, idempotensnøkkel og kontrollert budsjett på nytt forsøk.
• Partner: Leietakerspesifikke kvoter, publiserte svarmetadata og ingen tilgang til en annen leietakers køtilstand.
• Batchbar: Forsinket kjøring, større kø og valgfri ruting til en leverandørbatch API når arbeidsmengden tillater det.

Køopptak bør gi en klar avgjørelse. Avhengig av API-kontrakten, eksponer en 429- eller en gateway-spesifikk overbelastningsrespons med en gjentatt forsøk-etter-verdi, køidentifikator og årsakskode. Ikke lov en gjennomføringstid med mindre systemet kan håndheve dette løftet.

Batchbehandling kan fjerne ikke-interaktivt arbeid fra synkron kapasitet, men det endrer resultattiming, atferd for gjentatt forsøk, kansellering og avstemming. Behandle det som en egen utførelsesbane i stedet for bare å plassere synkrone forespørsler i en veldig lang kø. For bakgrunnsarbeidsbelastninger, sammenligne de operasjonelle avveiningene med AI API kostnadskontrollpolicyer og eksisterende batchoperasjoner.

Sentraliser forsøk på nytt og overbelastningshåndtering

Fakta: Midlertidige svargrenser bruker vanligvis HTTP 429, mens leverandøroverbelastningsforhold kan bruke 503 eller en leverandørspesifikk feilkode. Noen leverandører returnerer en Retry-After-overskrift, og leverandørdokumentasjonen anbefaler å respektere den når den er tilstede. En rask trafikkrampe kan også gi akselerasjon eller nedbremsing uten vanlig skuffeutmattelse.

Anbefaling: Behandle Prøv på nytt-etter som en nedre grense, ikke som et valgfritt forslag. Sett det berørte leverandøromfanget på pause til det tidspunktet, legg til avgrenset jitter for å forhindre synkroniserte vekkelser, og la megleren bestemme hvilke forespørsler i kø som kan bruke den gjenopprettede kapasiteten.

Når Retry-After er fraværende eller ugyldig, bruk begrenset eksponentiell backoff med jitter. Behold prøvebudsjettet i megleren, ikke separat i hver SDK og leverandøradapter. Ellers kan én logisk forespørsel produsere et nytt forsøk på gatewayen, et SDK nytt forsøk, et nytt forsøk på HTTP klient, og en replay på leverandørsiden.

Klassifiser feil før du prøver på nytt:

• Prøvbar kapasitet: Midlertidig 429 eller dokumentert forbigående kvoterespons.
• Prøvbar overbelastning: Midlertidig 503 eller tilsvarende leverandør overbelastningssignal.
• Retningsfeil som ikke kan prøves på nytt: Daglig kvote, forbrukstak, deaktivert prosjekt eller leietakergrense.
• Forespørselsfeil som ikke kan prøves på nytt: Ugyldig skjema, parameter som ikke støttes, autentiseringsfeil eller feilaktig inndata.
• Deadline failure: En forespørsel hvis gjenværende bruker- eller arbeidsflytfrist er kortere enn neste sikre forsøk.

Tilbakekomst er en egen beslutning. En annen leverandør kan ha forskjellig utdataatferd, prissetting, ventetid, bosted eller kontekstgrenser. Bruk kun reserver når rutepolicyen bekrefter at arbeidsbelastningskontrakten kan tolerere disse forskjellene.

Avslør beslutninger og mål metning

Team kan ikke feilsøke struping hvis gatewayen bare returnerer en generisk 429. Returner sikre metadata som gjeldende grense, gjenværende kapasitet, tilbakestillingstid, køavgjørelse, arbeidsbelastningsklasse og årsak til avvisning. Unngå å avsløre en annen leietakers bruk eller rå leverandørlegitimasjon.

Minst overvåk:

• Reservasjonssuksess og avvisningsfrekvens etter leietaker, rute og bøtte.
• Kødybde, ventetid i kø, utløp av frister og kanselleringer.
• Provider 429- og 503-takster, Retry-After-frekvens og rampe-rate avvisninger.
• Estimert kontra faktisk tokenbruk og kapasitet bortkastet ved overreservasjon.
• Samtidig metning og andelen kapasitet som forbrukes av hver leietaker.
• Forsøk på nytt per logisk forespørsel og reservefrekvens.
• Daglig kvote og takhøyde i forbruksvinduet.

Belastningstester bør inkludere burst-trafikk, forespørsler med lang kontekst, forespørsler om maksimal utgang, frakoblinger av strømming, daglig kvotebruk, leverandør 429- og 503-svar og én støyende leietaker som konkurrerer med produksjonstrafikk. Valider ikke bare om forespørsler til slutt fullføres, men også om køfrister, rettferdighet og budsjetter for gjenforsøk forblir intakte.

Implementeringssjekkliste

• Definer kanoniske dimensjoner uten å forkaste leverandørspesifikke grenser.
• Tildel hver forespørsel en normalisert leietaker, rute, arbeidsbelastningsklasse og idempotensnøkkel.
• Estimer og reserver input, output, totalt tokens, forbruk, forespørsler og samtidighet før utsendelse.
• Gjør multi-bucket-reservasjoner atomære og utløp forlatte reservasjoner trygt.
• Avstem faktisk leverandørbruk og svaroverskrifter etter hvert forsøk.
• Bruk vektet rettferdighet, burst-kreditter og eksplisitte prioritetsklasser.
• Gi hver kø en frist, maksimal dybde og overbelastningshandling.
• Sentraliser gjenforsøk og respekter leverandørens Retry-After-verdier.
• Skill midlertidige kapasitetsfeil fra permanente retningslinjer og forespørselsfeil.
• Publiser reguleringsmetadata og overvåk metning etter leietaker og rute.
• Test leverandørkvotebruk, rampegrenser, strømming, fallback og bråkete naboatferd.

Konklusjon

En gateway med flere modeller bør administrere leverandørkvoten som delt infrastrukturkapasitet, ikke som en samling uavhengige SDK-innstillinger. En leverandørnøytral takstgrensemegler gir plattformteam én adgangsbane, én rettferdighetspolicy, ett budsjett på nytt forsøk og ett sted for å avstemme estimater med virkeligheten.

Designet krever mer enn en generisk token-bøtte. Den må representere forespørsler, input- og output-tokens, daglige kvoter, forbruksvinduer, samtidighet, leverandøromfang og rampehastighet. Når disse dimensjonene er eksplisitte, kan gatewayen ta forutsigbare valg: sende nå, stå i kø med en frist, avbryte arbeidet, prøve på nytt sentralt eller bruke en kontraktsikker reserve. Det er slik gjennomstrømningskontroll blir en operasjonell evne i stedet for en tilbakevendende kilde til produksjon 429 og 503 hendelser.

Relatert lesing

• batchbehandling for ikke-interaktive LLM-arbeidsbelastninger