Hoe u een provider-neutrale tarieflimietmakelaar kunt bouwen voor LLM-API's met meerdere modellen

Als verschillende teams meerdere LLM-providers delen, is de snelheidslimiet niet langer een detail van de providerintegratie. Het wordt een probleem van gedeelde capaciteit. De ene aanbieder kan verzoeken en invoertokens beperken, een andere kan invoer- en uitvoertokens scheiden, en een derde kan quota's toepassen op projectniveau of over een voortschrijdend uitgavenvenster. Een herhalingslus binnen elke SDK kan deze beperkingen niet coördineren tussen tenants, applicaties, partnersleutels en modelroutes.

De praktische oplossing is een centrale tarieflimietmakelaar bij de gateway. De makelaar schat de vraag in, reserveert capaciteit vóór verzending, zet werk in de wachtrij of wijst werk af volgens het beleid, en stemt de reservering na voltooiing af op het daadwerkelijke gebruik. De reacties van de provider verfijnen vervolgens het beeld van de makelaar van de beschikbare capaciteit in plaats van dat er onafhankelijke stormen van nieuwe pogingen worden geactiveerd.

Deze architectuur is nuttig voor elke bedrijfs-LLM API die voorspelbare doorvoer nodig heeft tussen interne teams, productieapplicaties, automatiseringsagenten of externe partners.

Waarom de tarieflimieten van providers niet kunnen worden verlaagd tot verzoeken per minuut

Feit: Providerquota gebruiken verschillende dimensies en bereiken. Veel voorkomende dimensies zijn onder meer verzoeken per minuut, invoertokens per minuut, uitvoertokens per minuut, totaaltokens, verzoeken per dag, gelijktijdigheid, uitgavenvensters en limieten voor versnelling of oplopende snelheid. Dezelfde provider kan verschillende limieten instellen voor een organisatie, project, werkruimte, model of API product.

In de documentatie van de provider worden bijvoorbeeld combinaties beschreven als:

• Verzoek- en tokenlimieten met resterende capaciteit en reset-informatie in antwoordheaders.
• Afzonderlijke invoertoken- en uitvoertokenlimieten voor bericht-API's.
• Quota's op projectniveau in plaats van quota's die zijn gekoppeld aan individuele API sleutels.
• Dagelijkse verzoeklimieten die worden gereset op een door de provider gedefinieerd tijdstip.
• Rollende, op uitgaven gebaseerde vensters die verkeer kunnen weigeren, zelfs als de aanvraag- en tokentarieven acceptabel lijken.
• Versnellingslimieten die reageren op een sterke toename van het verkeer, zelfs als het stabiele gebruik onder het gepubliceerde quotum ligt.

Een gateway die slechts één nummer opslaat, genaamd provider RPM, zal uiteindelijk verkeer in de ene dimensie te veel toelaten of de capaciteit in een andere dimensie te weinig gebruiken. Het kan ook niet verklaren of een afwijzing voortkomt uit een tenantbeleid, een projectquotum van de provider, een dagelijkse limiet of een overbelastingsreactie.

Referentiearchitectuur voor een tarieflimietmakelaar

Plaats de makelaar in het verzoekpad vóór de provideradapter. Elk verzoek moet door hetzelfde reserveringsproces gaan, ongeacht of het binnenkomt via een SDK, een interne service, een automatiseringsagent of een partner API-sleutel.

1. Normaliseer de identiteit. Los de organisatie, tenant, team, applicatie, omgeving, partner, API sleutel, modelroute en werkbelastingklasse op.
2. Schat de vraag. Bereken de verwachte invoertokens, maximale uitvoertokens, geschatte uitgaven en eventuele gelijktijdigheidskosten.
3. Evalueer het beleid. Controleer huurderbudgetten, deadlines voor wachtrijen, geschiktheid van routes, prioriteit en reserveregels.
4. Reserveer capaciteit. Reserveer capaciteit op atomaire wijze in de relevante interne en providergerichte buckets.
5. Verzending. Verzend het verzoek pas nadat de reservering is gelukt.
6. Reconcile. Vervang schattingen door feitelijk gebruik, geef ongebruikte reserveringen vrij, en recordproviderheaders en antwoordclassificatie.
7. Beslis de volgende actie. Retourneer het resultaat, zet het werk in de wachtrij, probeer het centraal opnieuw, val terug of wijs het af volgens het werklastcontract.

De reserveringsservice moet horizontaal schaalbaar zijn, maar de beslissing moet voor elk verzoek atomair zijn. Een gedistribueerde teller waarmee twee werknemers dezelfde resterende capaciteit kunnen observeren, kan het provider 429-probleem binnen de gateway reproduceren.

Gebruik een canoniek quotamodel zonder de verschillen tussen providers te verbergen

Definieer een canoniek model dat providerspecifieke beperkingen kan weergeven in plaats van elke provider in één abstractie te dwingen.

Geef elke limiet weer als een bucket met een bereik, capaciteit, regel voor bijvullen of resetten, eenheid en bron. Een providerprojectbucket kan verzoeken en invoertokens bevatten. Een werkruimtebucket kan uitvoertokens bevatten. Een intern partnerbeleid kan gelijktijdigheid en bestedingslimieten toevoegen. De toelatingsbeslissing is alleen succesvol als alle vereiste reserveringen slagen.

Behandel headers van providers niet als een volledige bron van waarheid. Gebruik ze om de schattingen van de makelaar te corrigeren, maar behoud een geconfigureerd model voor limieten die niet bij elk antwoord zichtbaar zijn. Headernamen, beschikbaarheid en reset-semantiek variëren per provider en route.

Reserveer tokens vóór verzending en stem ze vervolgens af

Tokenreservering is het belangrijkste verschil tussen een makelaar en een retry-wrapper. De makelaar heeft een schatting van de vraag nodig voordat hij het verzoek verzendt.

Voor invoertokens maakt u een schatting op basis van de geserialiseerde berichten, tooldefinities, het gestructureerde uitvoerschema en alle opgehaalde context. Voor uitvoertokens gebruikt u het maximale verzoek, indien beschikbaar, of een model- en werklastspecifieke schatting als de client er geen verstrekt. Bewaar de schatting bij de reservering, zodat deze later kan worden vergeleken met het daadwerkelijke gebruik.

Een eenvoudig reserveringsrecord kan het volgende bevatten:

• Een uniek verzoek en reserverings-ID.
• Tenant, applicatie, API sleutel, route en werkbelastingklasse.
• Geschatte invoertokens, uitvoertokens, totaaltokens en uitgaven.
• Elke bucket die in rekening wordt gebracht door de reservering.
• Aanmaaktijd, vervaltijd, wachtrijdeadline en idempotentiesleutel.
• Het uiteindelijke daadwerkelijke gebruik en het bedrag dat tijdens de afstemming wordt vrijgegeven of in rekening wordt gebracht.

Conservatieve schattingen verminderen de 429-reacties van providers, maar kunnen de capaciteit belemmeren. Meet de schattingsfout per model, route, promptfamilie, contextlengte en gestructureerde uitvoermodus. Pas vervolgens de schattingen aan met behulp van begrensde correcties, in plaats van toe te staan dat één ongebruikelijk verzoek het hele model vertekent.

Streaming vereist een specifiek beleid. Je kunt de maximale uitvoercapaciteit reserveren en het ongebruikte deel vrijgeven wanneer de stroom eindigt, of de uitvoercapaciteit in kleinere stappen reserveren als de tokens arriveren. De eerste benadering is gemakkelijker om over te redeneren; de tweede kan het gebruik verbeteren, maar vereist betrouwbare annulering, time-out en afhandeling van de verbinding.

Quota's hiërarchisch afdwingen

De capaciteit moet worden gecontroleerd, van het smalste beleid tot de breedste gedeelde bron. Een typische hiërarchie is:

1. API sleutel of service-identiteit.
2. Toepassing en omgeving.
3. Team- of klanttenant.
4. Partner- of reselleraccount.
5. Werkruimte of subaccount van de aanbieder.
6. Providerproject of organisatie.
7. Model en route.

Voor een verzoek van een partnertoepassing zijn mogelijk vier succesvolle reserveringen nodig: het gelijktijdigheidsbeleid van de partner, het tokenbudget van de klanttenant, de routetoewijzing van de gateway en het beschikbare quotum van het providerproject. Als een reservering mislukt, geeft u de reeds verworven reserveringen vrij en past u de beslissing van de mislukte bucket toe.

Voor de eerlijkheid: gebruik gewogen eerlijke wachtrijen of round-robin met tekorten in plaats van toe te staan dat de werknemer die het eerst arriveert de gedeelde pool gebruikt. Wijs hogere gewichten toe aan productieverkeer en lagere gewichten aan achtergrondtaken, terwijl u de burst-credits voor elke huurder behoudt. Harde partitionering is gemakkelijker uit te leggen, maar kan de capaciteit inactief laten als één tenant stil is. Gewogen delen maakt over het algemeen efficiënter gebruik van de capaciteit, op voorwaarde dat luidruchtige tenants begrensde burst-limieten hebben.

Ontwerp wachtrijen rond werklastcontracten

Een wachtrij is niet automatisch een betrouwbaarheidsfunctie. Het kan een zichtbare 429 veranderen in een onzichtbare vertraging van tien minuten. Elke wachtrijklasse heeft een deadline, annuleringsgedrag, maximale diepte en overbelastingsactie nodig.

• Interactief: korte deadline, kleine wachtrij, voorspelbare afwijzing of verslechtering van het model wanneer er geen capaciteit beschikbaar is.
• Productieachtergrond: langere deadline, duurzame wachtrij, idempotentiesleutel en gecontroleerd budget voor nieuwe pogingen.
• Partner: Tenantspecifieke quota, gepubliceerde metagegevens van antwoorden en geen toegang tot de wachtrijstatus van een andere tenant.
• Batchbaar: Vertraagde uitvoering, grotere wachtrij en optionele routering naar een providerbatch API wanneer de werklast dit toelaat.

Toelating in de wachtrij zou een duidelijke beslissing moeten opleveren. Afhankelijk van het API-contract geeft u een 429- of een gateway-specifiek overbelastingsantwoord weer met een waarde voor opnieuw proberen, wachtrij-ID en redencode. Beloof geen voltooiingstijd, tenzij het systeem die belofte kan afdwingen.

Batchverwerking kan niet-interactief werk uit de synchrone capaciteit verwijderen, maar het verandert de resultaattiming, het gedrag van nieuwe pogingen, annulering en afstemming. Behandel het als een afzonderlijk uitvoeringspad in plaats van eenvoudigweg synchrone verzoeken in een zeer lange wachtrij te plaatsen. Vergelijk voor achtergrondproductietaken de operationele afwegingen met AI API kostenbeheersingsbeleid en bestaande batchbewerkingen.

Centraliseer de afhandeling van nieuwe pogingen en overbelasting

Feit: Reacties op tijdelijke snelheidslimieten gebruiken vaak HTTP 429, terwijl bij overbelasting van de provider mogelijk 503 of een providerspecifieke foutcode wordt gebruikt. Sommige providers retourneren een Retry-After-header, en in de documentatie van de provider wordt aanbevolen deze te respecteren wanneer deze aanwezig is. Een snelle verkeershelling kan ook versnellings- of vertragingsgedrag veroorzaken zonder dat de bak uitput.

Aanbeveling: behandel Retry-After als een ondergrens, niet als een optionele suggestie. Pauzeer tot die tijd het getroffen providerbereik, voeg begrensde jitter toe om gesynchroniseerde wake-ups te voorkomen en laat de makelaar beslissen welke verzoeken in de wachtrij de herstelde capaciteit kunnen gebruiken.

Als Retry-After afwezig of ongeldig is, gebruik dan een afgetopte exponentiële uitstel met jitter. Bewaar het budget voor nieuwe pogingen in de broker, niet afzonderlijk in elke SDK- en provideradapter. Anders kan één logisch verzoek een nieuwe poging tot een gateway, een SDK nieuwe poging, een HTTP client-nieuwe poging en een herhaling aan de providerkant opleveren.

Classificeer fouten voordat u het opnieuw probeert:

• Herhaalbare capaciteit: Tijdelijke 429 of gedocumenteerde tijdelijke quotumreactie.
• Opnieuw te proberen overbelasting: Tijdelijk 503- of gelijkwaardig overbelastingssignaal van de provider.
• Niet-opnieuw te proberen beleidsfout: Dagelijks quotum, bestedingslimiet, uitgeschakeld project of tenantlimiet.
• Niet-opnieuw te proberen verzoekfout: Ongeldig schema, niet-ondersteunde parameter, authenticatiefout of onjuist opgemaakte invoer.
• Deadline mislukt: een verzoek waarvan de resterende gebruikers- of workflowdeadline korter is dan de volgende veilige poging.

Fallback is een afzonderlijke beslissing. Een andere provider kan andere uitvoergedrag-, prijs-, latentie-, verblijfs- of contextlimieten hebben. Gebruik alleen fallback als het routebeleid bevestigt dat het werklastcontract deze verschillen kan tolereren.

Leg beslissingen bloot en meet verzadiging

Teams kunnen geen problemen met de beperking oplossen als de gateway alleen een generieke 429 retourneert. Veilige metagegevens retourneren, zoals de toepasselijke limiet, resterende capaciteit, resettijd, wachtrijbeslissing, werklastklasse en afwijzingsreden. Voorkom dat het gebruik van een andere tenant of de onbewerkte providerreferenties openbaar wordt gemaakt.

Controleer minimaal:

• Reserveringssucces en afwijzingspercentage per huurder, route en bucket.
• Wachtrijdiepte, wachttijd in wachtrij, verlopen deadlines en annuleringen.
• Provider 429- en 503-tarieven, Retry-After-frequentie en afwijzingen van de oplopende snelheid.
• Geschat versus feitelijk tokengebruik en capaciteitsverspilling door overreservering.
• Gelijktijdigheidsverzadiging en het aandeel van de capaciteit dat door elke tenant wordt verbruikt.
• Opnieuw proberen per logisch verzoek en terugvalfrequentie.
• Dagelijkse quota en speelruimte.

Belastingstests moeten burst-verkeer, lange-contextverzoeken, maximale uitvoerverzoeken, streaming-verbroken verbindingen, dagelijkse quota-uitputting, provider 429- en 503-reacties en één luidruchtige tenant die concurreert met productieverkeer omvatten. Valideer niet alleen of verzoeken uiteindelijk worden voltooid, maar ook of wachtrijdeadlines, eerlijkheid en budgetten voor nieuwe pogingen intact blijven.

Implementatiechecklist

• Definieer canonieke dimensies zonder providerspecifieke limieten terzijde te schuiven.
• Wijs aan elk verzoek een genormaliseerde tenant, route, werklastklasse en idempotency-sleutel toe.
• Schat en reserveer invoer, uitvoer, totale tokens, uitgaven, verzoeken en gelijktijdigheid vóór verzending.
• Maak reserveringen voor meerdere buckets atomair en laat verlaten reserveringen veilig verlopen.
• Registreer het daadwerkelijke providergebruik en de antwoordheaders na elke poging.
• Gebruik gewogen eerlijkheid, burst-credits en expliciete prioriteitsklassen.
• Geef elke wachtrij een deadline, maximale diepte en overbelastingsactie.
• Centraliseer nieuwe pogingen en respecteer de waarden van de provider Retry-After.
• Scheid tijdelijke capaciteitsfouten van permanente beleids- en verzoekfouten.
• Publiceer metadata voor beperking en controleer de verzadiging per tenant en route.
• Test de quota-uitputting van de provider, opvoerlimieten, streaming, terugval en luidruchtige burengedrag.

Conclusie

Een gateway met meerdere modellen moet de providerquota beheren als gedeelde infrastructuurcapaciteit, en niet als een verzameling onafhankelijke SDK instellingen. Een provider-neutrale tarieflimietmakelaar geeft platformteams één toegangspad, één eerlijkheidsbeleid, één budget voor nieuwe pogingen en één plek waar ze schattingen kunnen afstemmen op de werkelijkheid.

Het ontwerp vereist meer dan een generieke tokenbucket. Het moet verzoeken, invoer- en uitvoertokens, dagelijkse quota, uitgavenvensters, gelijktijdigheid, providerbereik en oploopsnelheid vertegenwoordigen. Zodra deze dimensies expliciet zijn, kan de gateway voorspelbare keuzes maken: nu verzenden, in de wachtrij staan ​​met een deadline, werk afschaffen, centraal opnieuw proberen of een contractveilige fallback gebruiken. Op die manier wordt doorvoercontrole een operationele mogelijkheid in plaats van een terugkerende bron van productie-429- en 503-incidenten.

Gerelateerd lezen

• batchverwerking voor niet-interactieve LLM-workloads