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 huurders, 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 die zich bewust is van de snelheidslimieten moet het verkeer vormgeven voordat verzoeken uw systeem verlaten: schat de tokendruk in, reserveert quota, isoleert tenants, zet het juiste werk in de wachtrij, wijst het verkeerde werk af en past zich aan wanneer de limieten van de provider veranderen.

Dit artikel beschrijft een praktische gateway-quotumregelaar voor teams die productieworkloads 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 betreft. Deze aanname breekt snel met LLM API's.

Feiten uit de huidige leveranciersdocumentatie:

• OpenAI documenteert dat limieten kunnen worden afgedwongen over kortere periodes dan de geadverteerde limiet per minuut, zodat korte bursts kunnen mislukken, zelfs als de gemiddelde minuut veilig lijkt.
• Het 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 berekeningen van snelheidslimiettokens worden geschat wanneer het verzoek wordt ontvangen en niet hetzelfde zijn als de definitieve aantallen factureringstokens.
• Antropische documenten scheiden limieten voor aanvragen 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.
• De API-limieten van Google Gemini zijn gekoppeld aan de gebruiksniveaus van projecten, waarbij hogere niveaus afhankelijk zijn van de factureringsinstellingen, de cumulatieve uitgaven en de verstreken tijd na de betalingsmijlpalen.

De operationele les is duidelijk: een OpenAI-compatibele verzoekvorm impliceert geen OpenAI-compatibel quotagedrag. Een gateway met meerdere providers heeft een intern quotamodel nodig dat rijker 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-, invoer-token-, uitvoer-token- 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 quotabeheerder. 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 waarbij sprake is van gecombineerde tokendruk.
• Gelijktijdig: 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": "snel chatten",
  "provider_scope": {
    "project": "product",
    "regio": "us-oost",
    "implementatie": "chat-large-01"
  },
  "limieten": {
    "tpm": 1200,
    "invoer_tpm": 800000,
    "output_tpm": 250000,
    "gelijktijdigheid": 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 een soortgelijke 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, deze tenant, dit modelprofiel en deze verzoekklasse.
• Verwachte tokens voor het lezen in de cache als promptcaching beschikbaar en meetbaar is.
• Streamingvlag en verwachte streamduur.

Een eenvoudige reserveringsregel is vaak genoeg om te beginnen:

geschatte_input_tokens = tokenize(request_messages) + model_overhead
geschatte_output_tokens = min(
  max_completion_tokens,
  p95_historische_output_tokens_voor_route
)
gereserveerde_total_tokens = geschatte_input_tokens + geschatte_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 bewaarplichten:

1. Citaat: schat de input- en outputdruk.
2. Reserve: trek vóór verzending af van de relevante tokenbuckets.
3. Afrekenen: vervang de schatting door het door de provider gerapporteerde gebruik, indien beschikbaar.
4. Terugbetaling of afschrijving: geef ongebruikte gereserveerde capaciteit terug of breng indien nodig overtollige capaciteit 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 uitvoerruimte apart te reserveren, wordt het risico op midstream-uitval en blokkering verminderd.

Gebruik hiërarchische tokenbuckets voor eerlijkheid van huurders

Een 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:

organisatie
  └── huurder
      └──-team
          └── api_sleutel
              └── model_profiel
                  └── provider_deployment

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

• De organisatie kan de capaciteit van de provider niet overschrijden.
• Een huurder kan niet meer verbruiken dan zijn gecontracteerde deel.
• Een API-sleutel kan 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 gemakkelijk 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 is geleend en wanneer het lenen is ingetrokken.

Een praktische regel:

• Geef elke huurder 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.

Scheid verkeersklassen voordat ze strijden

Niet alle verzoeken verdienen hetzelfde wachtrijgedrag. Plaats verkeer in modelprofielen met afzonderlijke 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 20 minuten wachten en toch als succesvol worden beschouwd.

Normaliseer 429s 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:

{
  "fout": {
    "type": "rate_limited",
    "limiter": "output_tpm",
    "provider": "provider_a",
    "model_profile": "snel chatten",
    "provider_model": "model-x",
    "opnieuw proberen na_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interactief",
    "geschatte_input_tokens": 4200,
    "geschatte_output_tokens": 800,
    "gateway_decision": "toegegeven_dan_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 de 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 beperkende 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 updatet de lokale bucket-aanvulpercentages en cooldowns op basis van headers, terwijl de implementatielimieten voor tenants, API-sleutels, verkeersklassen en providers binnen de gateway nog steeds worden afgedwongen.

Voeg platformgouverneurs 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 uitrol.

• Modelmigraties met functievlaggen per tenant, route of percentage verkeer.
• Stel groeiplafonds per minuut in voor de implementatie van nieuwe providers.
• Verwarm het verkeer geleidelijk gedurende een paar uur, 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 overschrijden.
• Behoud een terugdraairoute voor noodgevallen met een compatibiliteitsbeleid, en niet alleen een reservemodel.

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

Fallback is een beleidsbeslissing, niet alleen een capaciteitsbeslissing

Wanneer een provider een 429 retourneert, kan routering 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 ingezetenschap.
• Kosten en latentie.

De quota-gouverneur zou aan een compatibiliteitslaag moeten 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 de gatewayschattingen van het providergebruik?
• Wat is de distributie na opnieuw proberen per provider en limitertype?
• Hoeveel effectieve speelruimte wordt gecreëerd door prompt-cache-lezingen?
• Welke verkeersklassen lenen burst-capaciteit?

Voor klantgerichte of partnergerichte producten, zorg voor veilige controles:

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

Hierdoor wordt de snelheidslimiet van een mysterieuze providerfout veranderd in een controleerbaar onderdeel van team-API-beheer.

Implementatiechecklist

Fase 1: observeren en classificeren

• Log provider, 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.
• Geschatte en daadwerkelijke invoer-/uitvoertokens afzonderlijk registreren.
• Scheid 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.
• Voeg preflight-tokenschatting toe.
• Reserveer quota vóór verzending en stem af nadat 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 de implementatie van de organisatie tot de provider.
• 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.

Bruikbare conclusie

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, meer voorspelbare latentie, veiligere migraties en tarieflimietgedrag 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