Hur man bygger en leverantörsneutral räntegränsmäklare för LLM-API:er med flera modeller

När flera team delar flera LLM-leverantörer, slutar prisbegränsningen att vara en leverantörsintegreringsdetalj. Det blir ett problem med delad kapacitet. En leverantör kan begränsa förfrågningar och inmatningstoken, en annan kan separera in- och utmatningstoken, och en tredje kan tillämpa kvoter på projektnivå eller över ett rullande utgiftsfönster. En återförsöksslinga inuti varje SDK kan inte koordinera dessa begränsningar mellan hyresgäster, applikationer, partnernycklar och modellrutter.

Den praktiska lösningen är en mäklare av centralkursgränser vid gatewayen. Mäklaren uppskattar efterfrågan, reserverar kapacitet före avsändning, köar eller avvisar arbete enligt policy och stämmer av reservationen med faktisk användning efter slutförandet. Leverantörssvar förfinar sedan mäklarens syn på tillgänglig kapacitet istället för att utlösa oberoende stormar igen.

Denna arkitektur är användbar för alla enterprise LLM API som behöver förutsägbar genomströmning mellan interna team, produktionsapplikationer, automationsagenter eller externa partners.

Varför kan leverantörsprisgränser inte reduceras till förfrågningar per minut

Fakta: Leverantörskvoter använder olika dimensioner och omfattningar. Vanliga dimensioner inkluderar förfrågningar per minut, inmatningstoken per minut, utdatatoken per minut, totalt antal tokens, förfrågningar per dag, samtidighet, utgiftsfönster och accelerations- eller ramphastighetsgränser. Samma leverantör kan exponera olika gränser för en organisation, projekt, arbetsyta, modell eller API produkt.

Till exempel beskriver leverantörsdokumentationen kombinationer som:

• Begäran och tokengränser med återstående kapacitet och återställningsinformation i svarsrubriker.
• Separata gränser för input-token och output-token för meddelande-API:er.
• Kvoter på projektnivå snarare än kvoter kopplade till individuella API nycklar.
• Dagliga förfrågningsgränser som återställs vid en leverantörsdefinierad tidpunkt.
• Rullande utgiftsbaserade fönster som kan avvisa trafik även när förfrågnings- och tokenpriser verkar acceptabla.
• Accelerationsgränser som reagerar på en kraftig ökning av trafiken, även när steady-state-användningen är under den publicerade kvoten.

En gateway som bara lagrar ett nummer som heter provider RPM kommer så småningom att tillåta för mycket trafik i en dimension eller underutnyttja kapacitet i en annan. Det kan inte heller förklara om ett avslag kom från en hyresgästpolicy, en leverantörsprojektkvot, en daglig gräns eller ett överbelastningssvar.

Referensarkitektur för en räntegränsmäklare

Placera mäklaren i sökvägen före leverantörsadaptern. Varje begäran ska passera genom samma reservationsflöde, oavsett om den kom via en SDK, en intern tjänst, en automationsagent eller en partner API-nyckel.

1. Normalisera identitet. Lös organisationen, hyresgästen, teamet, applikationen, miljön, partnern, API-nyckeln, modellvägen och arbetsbelastningsklassen.
2. Uppskatta efterfrågan. Beräkna förväntade indatatokens, maximala outputtokens, uppskattade utgifter och eventuella samtidiga kostnader.
3. Utvärdera policy. Kontrollera hyresgästbudgetar, ködeadlines, ruttkvalificering, prioritet och reservregler.
4. Reservera kapacitet. Atomiskt reservera kapacitet i relevanta interna och leverantörsvända hinkar.
5. Utsändning. Skicka förfrågan först efter att bokningen har lyckats.
6. Reconcile. Ersätt uppskattningar med faktisk användning, släpp oanvända reservationer och postleverantörsrubriker och svarsklassificering.
7. Besluta nästa åtgärd. Returnera resultatet, köa arbetet, försök igen centralt, fall tillbaka eller avvisa det enligt arbetsbelastningskontraktet.

Reservationstjänsten bör vara horisontellt skalbar, men dess beslut måste vara atomärt för varje begäran. En distribuerad räknare som tillåter två arbetare att observera samma återstående kapacitet kan återskapa leverantörsproblemet 429 inuti gatewayen.

Använd en kanonisk kvotmodell utan att dölja leverantörsskillnader

Definiera en kanonisk modell som kan representera leverantörsspecifika begränsningar istället för att tvinga alla leverantörer till en abstraktion.

Representera varje gräns som en hink med en omfattning, kapacitet, påfyllnings- eller återställningsregel, enhet och källa. En leverantörsprojektbucket kan innehålla förfrågningar och inmatningstoken. En arbetsyta hink kan innehålla utdatatoken. En intern partnerpolicy kan lägga till samtidighet och utgiftsgränser. Antagningsbeslutet är framgångsrikt endast om alla nödvändiga reservationer lyckas.

Behandla inte leverantörsrubriker som en fullständig källa till sanning. Använd dem för att korrigera mäklarens uppskattningar, men behåll en konfigurerad modell för gränser som inte exponeras vid varje svar. Rubriknamn, tillgänglighet och semantik för återställning varierar beroende på leverantör och rutt.

Reservera tokens före avsändning och stäm sedan av dem

Tokenreservation är den viktigaste skillnaden mellan en mäklare och en återförsök. Mäklaren behöver en uppskattning av efterfrågan innan begäran skickas.

För indatatokens, uppskattning från de serialiserade meddelandena, verktygsdefinitioner, schemat för strukturerad utdata och eventuella hämtade sammanhang. För utdatatokens, använd maximal begäran när det är tillgängligt, eller en modell- och arbetsbelastningsspecifik uppskattning när klienten inte tillhandahåller en. Behåll uppskattningen bifogad bokningen så att den kan jämföras med faktisk användning senare.

En enkel bokningspost kan innehålla:

• En unik begäran och boknings-ID.
• Hyresgäst, applikation, API-nyckel, rutt och klass för arbetsbelastning.
• Uppskattade indatatoken, utdatatoken, totala tokens och utgifter.
• Varje hink debiteras av bokningen.
• Skapningstid, utgångstid, ködeadline och idempotensnyckel.
• Slutlig faktisk användning och det belopp som frisläppts eller debiterats under avstämning.

Konservativa uppskattningar minskar leverantörernas 429-svar men kan stranda kapaciteten. Mät uppskattningsfel efter modell, rutt, promptfamilj, kontextlängd och strukturerat utdataläge. Justera sedan uppskattningar med hjälp av avgränsade korrigeringar istället för att tillåta en enda ovanlig begäran att förvränga hela modellen.

Streaming kräver en specifik policy. Du kan reservera den maximala utmatningskapaciteten och frigöra den oanvända delen när strömmen slutar, eller reservera utmatningskapacitet i mindre steg när tokens anländer. Det första tillvägagångssättet är lättare att resonera kring; den andra kan förbättra användningen men kräver tillförlitlig avbokning, timeout och hantering av frånkoppling.

Tillämpa kvoter hierarkiskt

Kapaciteten bör kontrolleras från den smalaste policyn till den bredaste delade resursen. En typisk hierarki är:

1. API nyckel eller tjänstidentitet.
2. Applikation och miljö.
3. Team eller kundhyresgäst.
4. Partner- eller återförsäljarkonto.
5. Provider arbetsyta eller underkonto.
6. Providerprojekt eller organisation.
7. Modell och rutt.

En begäran från en partnerapplikation kan därför behöva fyra framgångsrika reservationer: partnerns policy för samtidighet, kundens hyresgästs tokenbudget, gatewayens rutttilldelning och leverantörsprojektets tillgängliga kvot. Om någon reservation misslyckas släpper du de redan förvärvade reservationerna och tillämpar den misslyckade buckets beslut.

För rättvisans skull, använd viktad rättvis kö eller underskott round-robin istället för att tillåta den arbetare som kommer först att konsumera den delade poolen. Tilldela högre vikter till produktionstrafik och lägre vikter till bakgrundsjobb, samtidigt som du behåller burst-krediter för varje hyresgäst. Hård partitionering är lättare att förklara men kan lämna kapaciteten inaktiv när en hyresgäst är tyst. Viktad delning använder i allmänhet kapaciteten mer effektivt, förutsatt att bullriga hyresgäster har begränsade burst-gränser.

Designa köer kring arbetsbelastningskontrakt

En kö är inte automatiskt en tillförlitlighetsfunktion. Det kan förvandla en synlig 429 till en osynlig tio minuters fördröjning. Varje köklass behöver en deadline, avbokningsbeteende, maximalt djup och överbelastningsåtgärd.

• Interaktiv: Kort deadline, liten kö, förutsägbart avslag eller modellförsämring när kapacitet inte är tillgänglig.
• Produktionsbakgrund: Längre deadline, varaktig kö, idempotensnyckel och kontrollerad budget för återförsök.
• Partner: Hyresgästspecifika kvoter, publicerade svarsmetadata och ingen åtkomst till en annan hyresgästs kötillstånd.
• Batchbar: Försenad exekvering, större kö och valfri routning till en leverantörsbatch API när arbetsbelastningen tillåter det.

Kötillträde bör ge ett tydligt beslut. Beroende på API-kontraktet, exponera ett 429 eller ett gateway-specifikt överbelastningssvar med ett återförsök efter-värde, köidentifierare och orsakskod. Lova inte en slutförandetid om inte systemet kan genomdriva det löftet.

Batchbearbetning kan ta bort icke-interaktivt arbete från synkron kapacitet, men det ändrar resultattiming, återförsöksbeteende, annullering och avstämning. Behandla det som en separat exekveringsväg snarare än att bara placera synkrona förfrågningar i en mycket lång kö. För bakgrundsarbetsbelastningar, jämför de operativa avvägningarna med AI API kostnadskontrollpolicyer och befintliga batchoperationer.

Centralisera försök igen och överbelastningshantering

Fakta: Tillfälliga svar med hastighetsgränser använder vanligtvis HTTP 429, medan leverantörsöverbelastningsförhållanden kan använda 503 eller en leverantörsspecifik felkod. Vissa leverantörer returnerar en Retry-After-rubrik, och leverantörsdokumentationen rekommenderar att man respekterar den när den finns. En snabb trafikramp kan också ge upphov till acceleration eller avmattning utan vanlig skoputmattning.

Rekommendation: Behandla Retry-After som en nedre gräns, inte som ett valfritt förslag. Pausa det berörda leverantörsomfånget tills dess, lägg till begränsat jitter för att förhindra synkroniserade väckningar och låt mäklaren bestämma vilka förfrågningar i kö som kan använda den återställda kapaciteten.

När Retry-After är frånvarande eller ogiltigt, använd exponentiell backoff med tak med jitter. Behåll budgeten för ett nytt försök i mäklaren, inte separat i varje SDK och leverantörsadapter. Annars kan en logisk begäran producera ett gateway-försök, ett SDK-försök, ett HTTP-klientförsök och en omspelning på leverantörssidan.

Klassificera fel innan du försöker igen:

• Försökbar kapacitet: Tillfälligt 429 eller dokumenterat övergående kvotsvar.
• Omförsökbar överbelastning: Tillfällig 503 eller motsvarande leverantörsöverbelastningssignal.
• Policyfel som inte går att försöka igen: Daglig kvot, utgiftstak, inaktiverat projekt eller hyresgästgräns.
• Begäran misslyckades med icke-försök: Ogiltigt schema, parameter som inte stöds, autentiseringsfel eller felaktig inmatning.
• Deadline fel: En begäran vars återstående användar- eller arbetsflödesdeadline är kortare än nästa säkra försök.

Tillbakagång är ett separat beslut. En annan leverantör kan ha olika utdatabeteende, prissättning, latens, uppehållstillstånd eller sammanhangsgränser. Använd endast reserv när ruttpolicyn bekräftar att arbetsbelastningskontraktet kan tolerera dessa skillnader.

Exponera beslut och mät mättnad

Team kan inte felsöka strypning om gatewayen endast returnerar en generisk 429. Returnera säker metadata som tillämplig gräns, återstående kapacitet, återställningstid, köbeslut, arbetsbelastningsklass och orsak till avslag. Undvik att exponera en annan hyresgästs användning eller råa leverantörsuppgifter.

Övervaka åtminstone:

• Bokningsframgång och avvisningsfrekvens efter hyresgäst, rutt och yta.
• Ködjup, köväntetid, deadline som löper ut och avbokningar.
• Taxor för leverantör 429 och 503, Försök igen-efter-frekvens och avslag på ramphastighet.
• Uppskattad kontra faktisk tokenanvändning och slösad kapacitet genom överreservation.
• Samtidighetsmättnad och andelen kapacitet som förbrukas av varje hyresgäst.
• Försök igen per logisk begäran och reservfrekvens.
• Daglig kvot och utgiftsutrymme.

Belastningstester bör inkludera burst-trafik, långa sammanhangsbegäranden, maximala utdatabegäranden, strömningsavbrott, daglig kvotförbrukning, leverantörssvar 429 och 503 och en bullrig hyresgäst som konkurrerar med produktionstrafik. Validera inte bara om förfrågningar slutförs, utan också om ködeadlines, rättvisa och budgetar för återförsök förblir intakta.

Checklista för implementering

• Definiera kanoniska dimensioner utan att ta bort leverantörsspecifika gränser.
• Tilldela varje begäran en normaliserad hyresgäst, rutt, arbetsbelastningsklass och idempotensnyckel.
• Uppskatta och reservera indata, utdata, totala tokens, utgifter, förfrågningar och samtidighet före avsändning.
• Gör atomreservationer med flera hinkar och förfall övergivna reservationer säkert.
• Sammanställ faktisk leverantörsanvändning och svarsrubriker efter varje försök.
• Använd viktad rättvisa, burst credits och explicita prioritetsklasser.
• Ge varje kö en deadline, maximalt djup och överbelastningsåtgärd.
• Centralisera omförsök och uppmärksamma leverantörens Retry-After-värden.
• Separera tillfälliga kapacitetsfel från permanent policy och begärandefel.
• Publicera strypmetadata och övervaka mättnad efter klient och rutt.
• Testa utmattning av leverantörskvoter, rampgränser, streaming, reserv och bullriga grannar.

Slutsats

En gateway med flera modeller bör hantera leverantörskvoter som delad infrastrukturkapacitet, inte som en samling oberoende SDK-inställningar. En leverantörsneutral mäklare med räntegränser ger plattformsteam en tillträdesväg, en rättvisa policy, en budget för omförsök och en plats att stämma av uppskattningar med verkligheten.

Designen kräver mer än en allmän token-hink. Den måste representera förfrågningar, in- och utmatningstoken, dagliga kvoter, utgiftsfönster, samtidighet, leverantörsomfång och ramphastighet. När dessa dimensioner är tydliga kan gatewayen göra förutsägbara val: skicka nu, köa med en deadline, avbryta arbetet, försök igen centralt eller använda en kontraktssäker reserv. Det är så genomströmningskontroll blir en operativ förmåga snarare än en återkommande källa för produktionsincidenter 429 och 503.

Relaterad läsning

• batchbearbetning för icke-interaktiva LLM-arbetsbelastningar