Rate-Limit-Aware AI API-gateways: vorm RPM, TPM, Bursts en eerlijkheid van huurders voordat 429's toeslaan

Een 429 van een LLM-provider is niet alleen een signaal voor een nieuwe poging. In productie is dit vaak een bewijs dat uw applicatie de controle over toegang, eerlijkheid van tenants, latentie of providerspecifieke quota-accounting al heeft verloren.

De algemene oplossing – exponentiële uitstel – is noodzakelijk maar onvolledig. Backoff reageert nadat de provider verkeer heeft afgewezen. Een AI API-gateway is zich bewust van de snelheidslimieten en moet het verkeer vormgeven voordat verzoeken uw systeem verlaten: schat de tokendruk, reserveert quota, isoleert tenants, zet het juiste werk in de wachtrij, wijst het verkeerde werk af en past zich aan wanneer de providerlimieten veranderen.

Dit artikel beschrijft een praktische gateway-quotumbeheer voor teams die productiewerklasten naar meerdere LLM-providers sturen via een uniforme API.

Het lezersprobleem: 429's zijn multidimensionaal

Veel teams behandelen tarieflimieten alsof het een enkel aantal verzoeken per minuut is. Deze veronderstelling wordt snel verbroken met LLM API's.

Feiten uit de huidige leveranciersdocumentatie:

• OpenAI documenten kunnen deze limieten worden afgedwongen over kortere perioden dan de geadverteerde limiet per minuut, dus korte bursts kunnen mislukken, zelfs als de gemiddelde minuut veilig lijkt.
• Azure OpenAI-quotum wordt toegewezen per abonnement, regio, model en implementatietype in tokens per minuut. Het toewijzen van TPM aan een implementatie bepaalt ook de afgedwongen RPM-limieten voor gevolgtrekkingen, en de RPM-tot-TPM-verhoudingen variëren per model.
• Azure OpenAI merkt ook op dat tokenberekeningen met snelheidslimieten worden geschat wanneer het verzoek wordt ontvangen en niet hetzelfde zijn als de uiteindelijke aantallen factureringstokens.
• Anthropic documenteert afzonderlijke limieten voor verzoeken per minuut, invoertokens per minuut en uitvoertokens per minuut. Als u de limieten overschrijdt, wordt er een 429 geretourneerd met een 'retry-after'-header.
• Anthropic waarschuwt dat scherpe verkeerstoenames de acceleratielimieten kunnen bereiken en beveelt een geleidelijke toename aan.
• Voor de meeste Claude modellen tellen Anthropic documenten die invoertokens in de cache lezen niet mee voor de limieten voor invoertokens per minuut, wat betekent dat promptcaching de effectieve speelruimte kan veranderen.
• Google Gemini API tarieflimieten zijn gekoppeld aan projectgebruiksniveaus, waarbij hogere niveaus afhankelijk zijn van de factureringsconfiguratie, cumulatieve uitgaven en verstreken tijd na betalingsmijlpalen.

De operationele les is duidelijk: een OpenAI-compatibele verzoekvorm impliceert geen OpenAI-compatibel quotumgedrag. Een gateway met meerdere providers heeft een intern quotamodel nodig dat uitgebreider is dan 'opnieuw proberen als 429'.

Ontwerpdoel: van toegangscontrole een gateway-verantwoordelijkheid maken

Een gateway die zich bewust is van de snelheidslimiet moet vijf vragen beantwoorden voordat hij een verzoek verzendt:

1. Welke provider, model, implementatie, regio, project of werkruimte ontvangt het verzoek?
2. Hoeveel verzoek-, invoertoken-, uitvoertoken- en gelijktijdigheidscapaciteit kan dit verbruiken?
3. Welke tenant, team, API sleutel, klant of werklastklasse moet in rekening worden gebracht op de gedeelde capaciteit?
4. Moet het verzoek nu worden toegelaten, kort in de wachtrij worden geplaatst, worden gedegradeerd, ergens anders naartoe worden gerouteerd of worden afgewezen?
5. Hoe moet de reservering worden afgestemd nadat de aanbieder het daadwerkelijke gebruik heeft geretourneerd?

De gateway wordt een quotumbeheerder. Het vervangt de providerlimieten niet. Het maakt providerlimieten zichtbaar, voorspelbaar en eerlijk binnen uw eigen systeem.

Ontwikkel een genormaliseerd quotamodel

Begin met het definiëren van interne limiter-dimensies die de grote aanbieders kunnen vertegenwoordigen zonder ze in één misleidende categorie te dwingen.

Aanbevolen limiterafmetingen

• RPM: verzoeken per minuut.
• Invoer-TPM: prompt-, bericht-, tool- en contexttokens per minuut.
• Uitvoer-TPM: voltooiingstokens per minuut, afzonderlijk gereserveerd voor streaming en lange generaties.
• Totale TPM: nuttig voor providers of implementaties die een gecombineerde tokendruk blootstellen.
• Gelijktijdigheid: actieve verzoeken, actieve streams of taken tijdens de vlucht.
• Streamingduur: langlevende streams kunnen verbindings- en uitvoertokenruimte in beslag nemen, zelfs als de RPM laag is.
• Providerspecifiek bereik: Azure-abonnement/regio/implementatie, Anthropic werkruimte/modelklasse, Google project/laag of OpenAI organisatie/project/modelgroep.

Verberg providerspecifieke dimensies niet. Normaliseer ze in een gemeenschappelijk schema, maar behoud voldoende details om een afwijzing later uit te leggen.

{
  "provider": "provider_a",
  "model_profile": "fast-chat",
  "provider_scope": {
    "project": "prod",
    "region": "us-east",
    "deployment": "chat-large-01"
  },
  "limits": {
    "rpm": 1200,
    "input_tpm": 800000,
    "output_tpm": 250000,
    "concurrency": 200
  }
}

Dit interne object moet expliciet worden geconfigureerd, en mag niet alleen uit modelnamen worden afgeleid. Providerdashboards, accountniveaus, regionale implementaties en werkruimte-instellingen kunnen allemaal de effectieve capaciteit van dezelfde modelfamilie veranderen.

Schat de tokendruk vóór verzending

Tarieflimieten aan de providerzijde vinden vaak plaats voordat het definitieve factureringsgebruik bekend is. Uw gateway moet dezelfde conservatieve schatting maken voordat verkeer wordt verzonden.

Preflight-reserveringsinvoer

• Geserialiseerde prompt en berichtlengte.
• Modelspecifieke tokenisatie en overhead voor rollen, tools, afbeeldingen of gestructureerde uitvoerinstructies.
• max_completion_tokens of gelijkwaardige uitvoerlimiet.
• Historische voltooiingsratio voor dit eindpunt, tenant, modelprofiel en verzoekklasse.
• Verwachte cache-leestokens als promptcaching beschikbaar en meetbaar is.
• Streamingvlag en verwachte streamduur.

Een eenvoudige reserveringsregel is vaak genoeg om te beginnen:

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

Gebruik voor onbekende routes een conservatieve standaard. Voor stabiele productieroutes moet u de schattingen voortdurend bijwerken op basis van het daadwerkelijke gebruik.

Reserveren en vervolgens afstemmen

Quotareserveringen mogen geen permanente kosten worden. Behandel ze als houvast:

1. Citaat: schat de invoer- en uitvoerdruk.
2. Reserveren: wordt vóór verzending afgetrokken van de relevante tokenbuckets.
3. Vereffenen: vervang de schatting door het door de provider gerapporteerde gebruik, indien beschikbaar.
4. Terugbetalen of afschrijven: geef ongebruikte gereserveerde capaciteit terug of breng indien nodig de overschotten door naar het volgende venster.

Dit is het belangrijkst voor gesprekken met lange context en streaming. Als u vóór verzending alleen de invoer-TPM controleert, kan een stream met succes starten en later in de uitvoertokendruk terechtkomen. Door de uitgangsruimte afzonderlijk te reserveren, wordt het risico op midstream-uitval en blokkering verminderd.

Gebruik hiërarchische tokenbuckets voor eerlijkheid van huurders

Eén enkele globale limiter beschermt het provideraccount, maar beschermt tenants niet tegen elkaar. Eén batchtaak met een lange context kan gedeelde TPM verbruiken en ervoor zorgen dat interactieve verzoeken van andere teams mislukken.

Gebruik hiërarchische tokenbuckets:

organization
  └── tenant
      └── team
          └── api_key
              └── model_profile
                  └── provider_deployment

Een verzoek moet elke relevante bucket passeren. Hiermee kunt u meerdere beleidsregels tegelijk afdwingen:

• De organisatie mag de capaciteit van de provider niet overschrijden.
• Een huurder kan niet meer verbruiken dan zijn gecontracteerde aandeel.
• Een API sleutel mag de beoogde omgevings- of applicatielimiet niet overschrijden.
• Een batchmodelprofiel kan een interactief modelprofiel niet uitsluiten.
• Een providerimplementatie kan niet overbelast worden, zelfs niet als een andere implementatie een reservequotum heeft.

Eerlijk delen versus gebruik

Aanbeveling: gebruik gewogen eerlijk delen met gecontroleerde burst-leningen.

Strikte limieten per tenant zijn eenvoudig uit te leggen, maar kunnen ongebruikte capaciteit doen mislukken. Burstleningen verbeteren het gebruik doordat een huurder tijdelijk inactieve quota uit een gedeelde pool kan gebruiken. De afweging is complexiteit: dashboards moeten laten zien wat er gegarandeerd is, wat er geleend is en wanneer het lenen is ingetrokken.

Een praktische regel:

• Geef elke tenant een gegarandeerde basislijn.
• Sta burst-lenen toe van ongebruikte gedeelde capaciteit.
• Vorder geleende capaciteit terug wanneer verkeer met een hogere prioriteit of gegarandeerd verkeer verschijnt.
• Laat geleend verkeer nooit 429's op providerniveau creëren voor gegarandeerd verkeer.

Afzonderlijke verkeersklassen voordat ze strijden

Niet alle verzoeken verdienen hetzelfde wachtrijgedrag. Plaats verkeer in modelprofielen met aparte wachtrijen en quotapools.

Wachtrijen verbeteren het succespercentage, maar verhogen de staartlatentie. Een gateway moet die afweging expliciet maken. Een interactief verzoek kan bijvoorbeeld maximaal 300 milliseconden wachten op het quotum, en vervolgens terugvallen of mislukken. Een nachtelijke batchtaak kan twintig minuten wachten en toch als succesvol worden beschouwd.

Normaliseer 429's in een schema met enkele fouten

Zelfs met een goede toegangscontrole zullen provider 429's nog steeds voorkomen. Limieten kunnen veranderen, schattingen van providers kunnen verschillen van die van u en het verkeer kan in scherpere uitbarstingen arriveren dan verwacht.

Normaliseer elke provider 429 in een gateway-foutobject:

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

Het sleutelveld is gateway_decision. Een 429 nadat de gateway het verzoek heeft toegelaten, verschilt van een verzoek dat de gateway lokaal vóór verzending heeft afgewezen. De eerste duidt op een probleem met de kalibratie van de begrenzer. De tweede duidt op opzettelijke bescherming.

Pas de headers van de provider aan, maar wees er niet afhankelijk van

Sommige providers retourneren nuttige headers, zoals indicatoren voor opnieuw proberen of resterende capaciteit. Gebruik ze indien beschikbaar.

Aanbeveling: headers van providers moeten uw lokale gouverneur afstemmen en niet vervangen.

Redenen:

• De beschikbaarheid van headers verschilt per provider en eindpunt.
• Headers geven mogelijk niet elke limiter-dimensie weer.
• Opnieuw proberen na vertelt u wanneer u het opnieuw moet proberen, niet welke tenant als volgende capaciteit moet krijgen.
• De tokenschattingen aan de providerzijde kunnen afwijken van uw facturering of interne boekhouding.

Een robuuste implementatie werkt de lokale aanvulsnelheden en cooldowns van buckets bij op basis van headers, terwijl de implementatielimieten voor tenants, API sleutels, verkeersklassen en providers binnen de gateway nog steeds worden gehandhaafd.

Voeg platformregelaars toe voor migraties en geplande taken

Veel tarieflimietincidenten vinden plaats tijdens geplande wijzigingen: het overstappen van het ene model naar het andere, het wisselen van provider, het inschakelen van een nieuwe agentworkflow of het starten van een geplande evaluatierun.

Aanbeveling: behandel de verkeersgroei als een gecontroleerde implementatie.

• Modelmigraties van functievlaggen per tenant, route of percentage verkeer.
• Stel groeiplafonds per minuut in voor de implementatie van nieuwe providers.
• Verwarm het verkeer geleidelijk gedurende uren, in plaats van al het verkeer onmiddellijk om te schakelen.
• Pauzeer de uitrol wanneer de 429-snelheid, de downgradesnelheid, de wachtrijdiepte of de p95-latentie een drempel overschrijdt.
• Behoud een terugdraairoute voor noodgevallen met een compatibiliteitsbeleid, niet alleen met een reservemodel.

Voorspelling: naarmate routeringsmodi, prioriteitsniveaus en controles op werkruimteniveau steeds gebruikelijker worden, zal ramp-governance een standaard gatewayfunctie worden in plaats van een incident-responsscript.

Fallback is een beleidsbeslissing, niet alleen een capaciteitsbeslissing

Wanneer een provider een 429 retourneert, kan routeren naar een andere provider het juiste antwoord zijn. Het kan ook onveilig zijn.

Fallback kan veranderen:

• Uitvoerkwaliteit en instructies volgen.
• Contextlengte.
• Tool-call-gedrag.
• Gestructureerde uitvoerbetrouwbaarheid.
• Gegevensretentie en verblijfsstatus.
• Kosten en latentie.

De quotabeheerder moet een compatibiliteitslaag vragen of terugval is toegestaan voor deze verzoekklasse. Als dat niet het geval is, moet het in de wachtrij staan of mislukken met een duidelijk lokaal snelheidslimietantwoord in plaats van stilletjes de semantiek te veranderen.

Onthul quotadashboards die beslissingen verklaren

Een quotasysteem dat niemand kan begrijpen, zal worden omzeild. Bouw dashboards rond operationele vragen:

• Welke tenants verbruiken de meeste RPM, input-TPM en output-TPM?
• Welke modelprofielen staan in de wachtrij, weigeren of vallen terug?
• Welk providerbereik is het knelpunt: project, regio, implementatie, werkruimte, modelklasse of accountlaag?
• Hoe vaak verschillen gatewayschattingen van providergebruik?
• Wat is de distributie na opnieuw proberen per provider en limitertype?
• Hoeveel effectieve speelruimte wordt gecreëerd door promptcache-lezingen?
• Welke verkeersklassen lenen burst-capaciteit?

Voor klantgerichte of partnergerichte producten, zorg voor veilige controles:

• Prijslimieten per sleutel.
• Per team burst-limieten.
• Dagelijkse limieten per klant.
• Noodpauze voor een tenant of sleutel.
• Waarschuwingen voor 429 pieken, wachtrijgroei en abnormale tokendruk.
• Partner API eindpunten voor resellerquotabeheer.

Hiermee wordt de snelheidsbeperking van een mysterieuze providerfout veranderd in een controleerbaar onderdeel van team API-beheer.

Implementatiechecklist

Fase 1: observeren en classificeren

• Logboekprovider, model, implementatie, regio, werkruimte, project, tenant, API sleutel en verzoekklasse voor elke aanroep.
• Leg provider 429's vast met 'retry-after' en onbewerkte metagegevens over fouten.
• Registreer geschatte en daadwerkelijke invoer-/uitvoertokens afzonderlijk.
• Gescheiden interactief, batch-, evaluatie- en achtergrondverkeer in telemetrie.

Fase 2: lokale toegangscontrole

• Maak interne limiter-objecten voor RPM, invoer-TPM, uitvoer-TPM, totale TPM en gelijktijdigheid.
• Preflight-tokenschatting toevoegen.
• Reserveer quota vóór verzending en stem af nadat het providergebruik arriveert.
• Lokaal afwijzen als een verzoek niet in de tenant- of providerbucket past.

Fase 3: eerlijkheid en wachtrijen

• Voeg hiërarchische buckets toe van organisatie- naar providerimplementatie.
• Gegarandeerde huurdersaandelen en gecontroleerde burst-leningen toewijzen.
• Maak afzonderlijke wachtrijen per verkeersklasse.
• Stel klassespecifieke maximale wachttijden en reserveregels in.

Fase 4: aanpassing en exploitatie

• Gebruik providerheaders om cooldowns aan te passen en aannames aan te vullen.
• Voeg platformregelaars toe voor migraties en geplande taken.
• Maak quotadashboards en waarschuwingen zichtbaar.
• Bekijk de schattingsfout en het gestrande quotum wekelijks.

Conclusie waar actie op ondernomen kan worden

Als uw gateway alleen 429s opnieuw probeert, werkt deze na de fout. Een AI API gateway van productiekwaliteit zou de meeste fouten in de snelheidslimieten moeten voorkomen door te beslissen wie wat mag verzenden, wanneer en tegen welk providerquotum.

Begin met een genormaliseerd limitermodel, preflight-tokenreservering en wachtrijen op verkeersklasse. Voeg vervolgens hiërarchische eerlijkheid van huurders, aanpassing van provider-headers en hellingsregelaars toe. Het resultaat is niet alleen minder 429's. Het is een duidelijkere capaciteitstoewijzing, voorspelbaardere latentie, veiligere migraties en snelheidslimietgedrag dat uw technische, financiële en klantenondersteuningsteams daadwerkelijk kunnen verklaren.

Gerelateerd lezen

• preflight-reservering en afstemming van gebruik
• prompt cache-accounting en cache-hit analytics
• compatibel fallback-routeringsbeleid