Rate-Limit-Aware AI API-gatewayer: Shape RPM, TPM, Bursts og Tenant Fairness Before 429s Hit

En 429 fra en LLM-leverandør er ikke bare et signal på nytt. I produksjon er det ofte bevis på at søknaden din allerede har mistet kontrollen over opptak, leietakers rettferdighet, ventetid eller leverandørspesifikk kvoteregnskap.

Den vanlige løsningen – eksponentiell backoff – er nødvendig, men ufullstendig. Backoff reagerer etter at leverandøren avviser trafikk. En satsgrensebevisst AI API-gateway bør forme trafikk før forespørsler forlater systemet ditt: estimer tokentrykk, reserver kvote, isoler leietakere, sett riktig arbeid i kø, avvis feil arbeid og tilpass når leverandørgrensene endres.

Denne artikkelen beskriver en praktisk gateway-kvoteregulator for team som sender produksjonsarbeidsmengder til flere LLM-leverandører gjennom en enhetlig API.

Leserproblemet: 429-er er flerdimensjonale

Mange team behandler takstgrenser som om de var et enkelt antall forespørsler per minutt. Denne antagelsen bryter raskt med LLM APIer.

Fakta fra gjeldende leverandørdokumentasjon:

• OpenAI dokumenterer at grenser kan håndheves over kortere vinduer enn den annonserte per minuttgrensen, så korte serier kan mislykkes selv når gjennomsnittsminuttet ser trygt ut.
• Azure OpenAI-kvoten tildeles etter abonnement, region, modell og distribusjonstype i tokens per minutt. Å tilordne TPM til en distribusjon bestemmer også tvungne RPM-grenser, og RPM-til-TPM-forhold varierer etter modell.
• Azure OpenAI merker seg også at beregninger av rate-limit tokens estimeres når forespørselen mottas og er ikke det samme som endelige faktureringstokentellinger.
• Antropiske dokumenter skiller grenser for forespørsler per minutt, input-tokens-per-minutt og output-tokens per minutt. Overskridelse av grenser returnerer en 429 med en ny prøv etter-overskrift.
• Anthropic advarer om at kraftige trafikkøkninger kan treffe akselerasjonsgrensene og anbefaler gradvis opptrapping.
• For de fleste Claude-modeller teller ikke Anthropic-dokumenter som cache-lest input-tokens mot grensene for input-token-per-minutt, noe som betyr at hurtigbufring kan endre den effektive takhøyden.
• Satsgrenser for Google Gemini API er knyttet til prosjektbruksnivåer, med høyere nivåer avhengig av faktureringsoppsett, akkumulert forbruk og medgått tid etter betalingsmilepæler.

Den operasjonelle leksjonen er klar: en OpenAI-kompatibel forespørselsform innebærer ikke OpenAI-kompatibel kvoteadferd. En gateway med flere leverandører trenger en intern kvotemodell som er rikere enn «prøv på nytt hvis 429».

Designmål: Gjør adgangskontroll til et gatewayansvar

En gateway som er klar over takstgrenser bør svare på fem spørsmål før du sender en forespørsel:

1. Hvilken leverandør, modell, distribusjon, region, prosjekt eller arbeidsområde vil motta forespørselen?
2. Hvor mye kapasitet for forespørsel, input-token, output-token og samtidighetskapasitet kan den forbruke?
3. Hvilken leietaker, team, API-nøkkel, kunde eller arbeidsbelastningsklasse skal belastes mot delt kapasitet?
4. Skal forespørselen godtas nå, settes i kø kort, nedgraderes, rutes andre steder eller avvises?
5. Hvordan bør reservasjonen avstemmes etter at leverandøren returnerer faktisk bruk?

Porten blir en kvoteguvernør. Det erstatter ikke leverandørgrenser. Det gjør leverandørgrenser synlige, forutsigbare og rettferdige i ditt eget system.

Bygg en normalisert kvotemodell

Begynn med å definere interne begrensningsdimensjoner som kan representere de store leverandørene uten å tvinge dem inn i en misvisende bøtte.

Anbefalte begrenserdimensjoner

• RPM: forespørsler per minutt.
• Ta inn TPM: ledetekst, melding, verktøy og konteksttokens per minutt.
• Utdata-TPM: fullføringstokener per minutt, reservert separat for strømming og lange generasjoner.
• Total TPM: nyttig for leverandører eller distribusjoner som eksponerer kombinert tokentrykk.
• Samtidighet: aktive forespørsler, aktive strømmer eller jobber om bord.
• Strømmevarighet: strømmer med lang levetid kan oppta tilkoblings- og utdata-token-høyderom selv når RPM er lavt.
• Leverandørspesifikt omfang: Azure-abonnement/region/distribusjon, Antropisk arbeidsområde/modellklasse, Google-prosjekt/nivå eller OpenAI-organisasjon/prosjekt/modellgruppe.

Ikke skjul leverandørspesifikke dimensjoner. Normaliser dem til et felles skjema, men bevar nok detaljer til å forklare en avvisning senere.

{
  "provider": "provider_a",
  "model_profile": "rask chat",
  "provider_scope": {
    "project": "prod",
    "region": "oss-øst",
    "deployment": "chat-large-01"
  },
  "grenser": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250 000,
    "samtidighet": 200
  }
}

Dette interne objektet bør konfigureres eksplisitt, ikke utledes fra modellnavn alene. Leverandørdashbord, kontonivåer, regionale distribusjoner og arbeidsområdeinnstillinger kan alle endre den effektive kapasiteten til samme modellfamilie.

Estimer tokentrykk før utsendelse

Taxbegrensning på leverandørsiden skjer ofte før den endelige faktureringsbruken er kjent. Gatewayen din bør gjøre den samme typen konservative estimat før du sender trafikk.

Inndata for forhåndsreisereservasjon

• Serialisert melding og meldingslengde.
• Modellspesifikk tokenisering og overhead for roller, verktøy, bilder eller strukturerte utdatainstruksjoner.
• max_completion_tokens eller tilsvarende utdatatak.
• Historisk fullføringsgrad for dette endepunktet, leietakeren, modellprofilen og forespørselsklassen.
• Forventede cache-lese-tokens hvis hurtigbufring er tilgjengelig og målbart.
• Strømmeflagg og forventet strømmevarighet.

En enkel reservasjonsregel er ofte nok til å 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_tokens

For ukjente ruter, bruk en konservativ standard. For stabile produksjonsruter, oppdater estimater kontinuerlig fra faktisk bruk.

Reserver, og avstem deretter

Kvotereservasjoner skal ikke bli permanente kostnader. Behandle dem som hold:

1. Sitat: estimer inngangs- og utgangstrykk.
2. Reserver: trekk fra de relevante token-bøttene før utsendelse.
3. Avgjøre: erstatt anslaget med leverandørrapportert bruk når det er tilgjengelig.
4. Refusjon eller debet: returner ubrukt reservert kapasitet eller belaster overskudd til neste vindu om nødvendig.

Dette er viktigst for lang-kontekst- og strømmingsamtaler. Hvis du kun sjekker inngangs-TPM før utsendelse, kan en strøm starte med suksess og deretter støte på utgangs-token-trykk senere. Ved å reservere utgangshøyde separat reduseres midtstrømsfeil og risiko for stopp.

Bruk hierarkiske token-bøtter for leietakers rettferdighet

En enkelt global begrenser beskytter leverandørkontoen, men beskytter ikke leietakere mot hverandre. Én batchjobb med lang kontekst kan konsumere delt TPM og føre til at interaktive forespørsler fra andre team mislykkes.

Bruk hierarkiske token-bøtter:

organisasjon
  └── leietaker
      └── lag
          └── api_key
              └── modell_profil
                  └── provider_deployment

En forespørsel må sendes til hver relevante bøtte. Dette lar deg håndheve flere retningslinjer samtidig:

• Organisasjonen kan ikke overskride leverandørkapasiteten.
• En leietaker kan ikke konsumere mer enn den avtalte andelen.
• En API-nøkkel kan ikke overskride den tiltenkte miljø- eller programgrensen.
• En batchmodellprofil kan ikke sulte ut en interaktiv modellprofil.
• En leverandørdistribusjon kan ikke overbelastes selv om en annen distribusjon har ledig kvote.

Riktig deling versus utnyttelse

Anbefaling: bruk vektet rettferdig deling med kontrollert burst-lån.

Strenge per-tenant caps er enkle å forklare, men kan strande ubrukt kapasitet. Burst-lån forbedrer utnyttelsen ved å la en leietaker midlertidig bruke ledig kvote fra en delt pool. Avveiningen er kompleksitet: dashbord må vise hva som ble garantert, hva som ble lånt og når lånet ble tilbakekalt.

En praktisk regel:

• Gi hver leietaker en garantert grunnlinje.
• Tillat serielån fra ubrukt delt kapasitet.
• Ta tilbake lånt kapasitet når høyere prioritet eller garantert trafikk vises.
• La aldri lånt trafikk lage 429-er på leverandørnivå for garantert trafikk.

Skill trafikkklasser før de kjemper

Ikke alle forespørsler fortjener samme køadferd. Sett trafikk inn i modellprofiler med separate køer og kvotepooler.

{
  "feil": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "rask chat",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interaktiv",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": usant,
    "trace_id": "trace_abc"
  }
}