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

En 429 från en LLM-leverantör är inte bara en signal om att försöka igen. I produktionen är det ofta bevis på att din ansökan redan har tappat kontrollen över tillträde, hyresgästs rättvisa, latens eller leverantörsspecifik kvotredovisning.

Den gemensamma fixen – exponentiell backoff – är nödvändig men ofullständig. Backoff reagerar efter att leverantören avvisar trafik. En hastighetsgräns-medveten AI API-gateway bör forma trafiken innan förfrågningar lämnar ditt system: uppskatta tokentryck, reservera kvot, isolera hyresgäster, köa rätt arbete, avvisa fel arbete och anpassa när leverantörsgränserna ändras.

Den här artikeln beskriver en praktisk gateway-kvotregulator för team som skickar produktionsbelastningar till flera LLM-leverantörer via ett enhetligt API.

Läsarproblemet: 429:or är flerdimensionella

Många team behandlar hastighetsgränser som om de vore ett enda nummer för begäranden per minut. Det antagandet bryter snabbt med LLM API:er.

Fakta från aktuell leverantörsdokumentation:

• OpenAI dokumenterar att gränser kan tillämpas över kortare fönster än den annonserade per minutgränsen, så korta skurar kan misslyckas även när den genomsnittliga minuten ser säker ut.
• Azure OpenAI-kvoten tilldelas efter prenumeration, region, modell och distributionstyp i tokens per minut. Att tilldela TPM till en distribution avgör också RPM-gränser för påtvingade slutledningar, och RPM-till-TPM-förhållanden varierar beroende på modell.
• Azure OpenAI noterar också att beräkningar av hastighetsgränstoken uppskattas när begäran tas emot och inte är detsamma som slutliga faktureringstoken.
• Antropiska dokument separerar gränser för begäranden per minut, input-tokens per minut och output-tokens per minut. Överskridande av gränser returnerar en 429 med ett försök efter-huvudet igen.
• Anthropic varnar för att kraftiga trafikökningar kan nå accelerationsgränserna och rekommenderar en gradvis ökning.
• För de flesta Claude-modeller räknas inte antropiska dokument som cachelästa indatatokens mot gränserna för input-token per minut, vilket innebär att snabb cachning kan ändra det effektiva utrymmet.
• Google Gemini API-hastighetsgränser är knutna till projektanvändningsnivåer, med högre nivåer beroende på faktureringsinställningar, kumulativa utgifter och förfluten tid efter betalningsmilstolpar.

Den operativa lärdomen är tydlig: en OpenAI-kompatibel begärandeform innebär inte OpenAI-kompatibelt kvotbeteende. En gateway för flera leverantörer behöver en intern kvotmodell som är rikare än "försök igen om 429."

Designmål: göra antagningskontroll till ett gatewayansvar

En gateway med gränsvärde bör svara på fem frågor innan en förfrågan skickas:

1. Vilken leverantör, modell, distribution, region, projekt eller arbetsyta kommer att ta emot begäran?
2. Hur mycket kapacitet för begäran, input-token, output-token och samtidighet kan den förbruka?
3. Vilken hyresgäst, team, API-nyckel, kund eller arbetsbelastningsklass ska debiteras mot delad kapacitet?
4. Bör begäran godkännas nu, köas kort, nedgraderas, dirigeras någon annanstans eller avvisas?
5. Hur ska reservationen stämmas av efter att leverantören returnerar faktisk användning?

Gatewayen blir en kvotguvernör. Det ersätter inte leverantörsgränser. Det gör leverantörsgränser synliga, förutsägbara och rättvisa i ditt eget system.

Bygg en normaliserad kvotmodell

Börja med att definiera interna begränsningsmått som kan representera de stora leverantörerna utan att tvinga dem i en vilseledande hink.

Rekommenderade begränsarmått

• RPM: förfrågningar per minut.
• Inmatning av TPM: prompt, meddelande, verktyg och sammanhangstoken per minut.
• Utdata TPM: slutförandetokens per minut, reserverade separat för streaming och långa generationer.
• Total TPM: användbart för leverantörer eller distributioner som exponerar kombinerat tokentryck.
• Samtidighet: aktiva förfrågningar, aktiva strömmar eller jobb under flygning.
• Strömningslängd: långlivade strömmar kan uppta utrymme för anslutning och utdatatoken även när RPM är lågt.
• Leverantörsspecifikt omfång: Azure-prenumeration/region/distribution, Antropisk arbetsyta/modellklass, Google-projekt/nivå eller OpenAI-organisation/projekt/modellgrupp.

Dölj inte leverantörsspecifika dimensioner. Normalisera dem till ett gemensamt schema, men bevara tillräckligt med detaljer för att förklara ett avslag senare.

{
  "provider": "provider_a",
  "model_profile": "snabbchatt",
  "provider_scope": {
    "project": "prod",
    "region": "us-öst",
    "deployment": "chat-large-01"
  },
  "gränser": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "samtidighet": 200
  }
}

Detta interna objekt bör konfigureras explicit, inte härledas enbart från modellnamn. Leverantörsinstrumentpaneler, kontonivåer, regionala implementeringar och arbetsytainställningar kan alla ändra den effektiva kapaciteten för samma modellfamilj.

Uppskatta tokentrycket före avsändning

Taxebegränsning på leverantörssidan sker ofta innan den slutliga faktureringsanvändningen är känd. Din gateway bör göra samma sorts konservativa uppskattning innan trafik skickas.

Ingångar för preflightreservation

• Serialiserad uppmaning och meddelandelängd.
• Modellspecifik tokenisering och overhead för roller, verktyg, bilder eller strukturerade utdatainstruktioner.
• max_completion_tokens eller motsvarande utdatatak.
• Historiskt slutförande förhållande för denna slutpunkt, klient, modellprofil och begäranklass.
• Förväntade cache-lästa tokens om snabb cachelagring är tillgänglig och mätbar.
• Strömningsflagga och förväntad strömlängd.

En enkel bokningsregel räcker ofta för att starta:

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

För okända rutter, använd en konservativ standard. För stabila produktionsvägar, uppdatera uppskattningar kontinuerligt från faktisk användning.

Reservera och stämma sedan av

Kvotreservationer bör inte bli permanenta avgifter. Behandla dem som spärrar:

1. Citat: uppskatta ingångs- och utgående tryck.
2. Reservera: dra av från relevanta token-hinkar före avsändning.
3. Skäll: ersätt uppskattningen med leverantörsrapporterad användning när den är tillgänglig.
4. Återbetalning eller debitering: returnera oanvänd reserverad kapacitet eller debitera överskott till nästa fönster om det behövs.

Detta är viktigast för samtal med långa sammanhang och strömmande samtal. Om du bara kontrollerar ingångs-TPM före avsändning, kan en ström starta framgångsrikt och sedan hamna i utgångs-tokentryck senare. Att reservera utgångsutrymme separat minskar risken för misslyckanden i mitten av strömmen och stopp.

Använd hierarkiska token-buckets för hyresgästers rättvisa

En enda global limiter skyddar leverantörskontot men skyddar inte hyresgäster från varandra. Ett batchjobb med långa sammanhang kan konsumera delad TPM och orsaka att interaktiva förfrågningar från andra team misslyckas.

Använd hierarkiska token-buckets:

organisation
  └── hyresgäst
      └── laget
          └── api_key
              └── modell_profil
                  └── provider_deployment

En begäran måste passera varje relevant hink. Detta låter dig tillämpa flera policyer samtidigt:

• Organisationen kan inte överskrida leverantörens kapacitet.
• En hyresgäst kan inte konsumera mer än sin avtalade andel.
• En API-nyckel får inte överskrida den avsedda miljö- eller programgränsen.
• En batchmodellprofil kan inte svälta en interaktiv modellprofil.
• En leverantörsimplementering kan inte överbelastas även om en annan distribution har extra kvot.

Rättvis delning kontra utnyttjande

Rekommendation: använd viktad rättvis delning med kontrollerad burst-låning.

Strikta per-hyresgästtak är lätta att förklara men kan stranda outnyttjad kapacitet. Burst-lån förbättrar utnyttjandet genom att tillåta en hyresgäst att tillfälligt använda ledig kvot från en delad pool. Avvägningen är komplexitet: instrumentpaneler måste visa vad som garanterades, vad som lånades och när upplåningen återkallades.

En praktisk regel:

• Ge varje hyresgäst en garanterad baslinje.
• Tillåt skurlån från oanvänd delad kapacitet.
• Ta tillbaka lånad kapacitet när högre prioritet eller garanterad trafik dyker upp.
• Låt aldrig lånad trafik skapa 429:or på leverantörsnivå för garanterad trafik.

Separera trafikklasser innan de tävlar

Alla förfrågningar förtjänar inte samma köbeteende. Lägg in trafik i modellprofiler med separata köer och kvotpooler.

{
  "error": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "snabbchatt",
    "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": false,
    "trace_id": "trace_abc"
  }
}