Com crear un intermediari de límit de tarifa neutral per al proveïdor per a API de LLM multimodel

Quan diversos equips comparteixen diversos proveïdors de LLM, la limitació de tarifes deixa de ser un detall d'integració del proveïdor. Es converteix en un problema de capacitat compartida. Un proveïdor pot limitar les sol·licituds i els testimonis d'entrada, un altre pot separar els testimonis d'entrada i de sortida i un tercer pot aplicar quotes a nivell de projecte o en una finestra de despesa continuada. Un bucle de reintent dins de cada SDK no pot coordinar aquestes restriccions entre inquilins, aplicacions, claus de soci i rutes de models.

La solució pràctica és un intermediari de límit de tarifa central a la passarel·la. El corredor estima la demanda, reserva la capacitat abans de l'enviament, fa cua o rebutja el treball segons la política i concilia la reserva amb l'ús real després de la finalització. Les respostes del proveïdor milloren la visió de l'agent sobre la capacitat disponible en lloc de provocar tempestes de reintents independents.

Aquesta arquitectura és útil per a qualsevol LLM empresarial API que necessiti un rendiment previsible entre equips interns, aplicacions de producció, agents d'automatització o socis externs.

Per què els límits de tarifa del proveïdor no es poden reduir a sol·licituds per minut

Fet: Les quotes dels proveïdors utilitzen diferents dimensions i àmbits. Les dimensions habituals inclouen sol·licituds per minut, fitxes d'entrada per minut, fitxes de sortida per minut, fitxes totals, sol·licituds per dia, concurrència, finestres de despesa i límits d'acceleració o velocitat de rampa. El mateix proveïdor pot exposar diferents límits per a una organització, projecte, espai de treball, model o API producte.

Per exemple, la documentació del proveïdor descriu combinacions com ara:

• Límits de sol·licitud i testimoni amb la capacitat restant i la informació de restabliment a les capçaleres de resposta.
• Separeu els límits de testimoni d'entrada i de sortida per a les API de missatges.
• Quotes a nivell de projecte en lloc de quotes adjuntes a les claus API individuals.
• Límits de sol·licituds diàries que es restableixen a una hora definida pel proveïdor.
• Finestres en continu basades en despesa que poden rebutjar el trànsit fins i tot quan les tarifes de sol·licituds i testimonis semblen acceptables.
• Límits d'acceleració que reaccionen a un fort augment del trànsit, fins i tot quan l'ús en estat estacionari està per sota de la quota publicada.

Una passarel·la que emmagatzema només un número anomenat RPM del proveïdor acabarà superant el trànsit en una dimensió o la capacitat de subutilització en una altra. Tampoc no pot explicar si un rebuig prové d'una política d'inquilí, una quota de projecte del proveïdor, un límit diari o una resposta de sobrecàrrega.

Arquitectura de referència per a un intermediari de límit de tarifes

Coloqueu l'agent al camí de la sol·licitud abans de l'adaptador del proveïdor. Cada sol·licitud ha de passar pel mateix flux de reserva, independentment de si ha arribat a través d'una clau SDK, un servei intern, un agent d'automatització o una clau de soci API.

1. Normalitzar la identitat. Resoldre l'organització, l'arrendatari, l'equip, l'aplicació, l'entorn, el soci, la clau API, la ruta del model i la classe de càrrega de treball.
2. Estima la demanda. Calcula els testimonis d'entrada esperats, els testimonis de sortida màxims, la despesa estimada i qualsevol cost de concurrència.
3. Avalueu la política. Comproveu els pressupostos dels inquilins, els terminis de la cua, l'elegibilitat de les rutes, la prioritat i les regles alternatives.
4. Reserva de capacitat. Reserva de capacitat atòmica als cubs interns i orientats al proveïdor pertinents.
5. Enviament. Envieu la sol·licitud només un cop s'hagi realitzat la reserva.
6. Reconciliar. Substituïu les estimacions per l'ús real, allibereu les reserves no utilitzades i registreu les capçaleres del proveïdor i la classificació de respostes.
7. Decideix la següent acció. Retorna el resultat, posa el treball a la cua, torna-ho a provar de manera centralitzada, retrocedeix o rebutja-lo segons el contracte de càrrega de treball.

El servei de reserves ha de ser escalable horitzontalment, però la seva decisió ha de ser atòmica per a cada sol·licitud. Un comptador distribuït que permeti a dos treballadors observar la mateixa capacitat restant pot recrear el problema del proveïdor 429 dins de la passarel·la.

Utilitzeu un model de quota canònic sense amagar les diferències dels proveïdors

Definiu un model canònic que pugui representar restriccions específiques del proveïdor en lloc de forçar tots els proveïdors a una abstracció.

Representeu cada límit com un cub amb un abast, capacitat, regla de recàrrega o restabliment, unitat i font. Un grup de projectes del proveïdor pot contenir sol·licituds i testimonis d'entrada. Un cub d'espai de treball pot contenir fitxes de sortida. Una política de soci interna pot afegir límits de concurrència i despesa. La decisió d'admissió només té èxit si totes les reserves necessàries tenen èxit.

No tracteu les capçaleres del proveïdor com una font completa de veritat. Utilitzeu-los per corregir les estimacions del corredor, però manteniu un model configurat per als límits que no s'exposen a cada resposta. Els noms de capçalera, la disponibilitat i la semàntica de restabliment varien segons el proveïdor i la ruta.

Reserveu les fitxes abans de l'enviament i, a continuació, reconcilieu-les

La reserva de testimonis és la diferència més important entre un corredor i un embolcall de reintents. El corredor necessita una estimació de la demanda abans d'enviar la sol·licitud.

Per als testimonis d'entrada, estimació a partir dels missatges serialitzats, definicions d'eines, esquema de sortida estructurada i qualsevol context recuperat. Per als testimonis de sortida, utilitzeu el màxim de sol·licitud quan estigui disponible, o una estimació específica del model i la càrrega de treball quan el client no en proporcioni cap. Manteniu l'estimació adjunta a la reserva perquè es pugui comparar amb l'ús real més endavant.

Un registre de reserva senzill pot contenir:

• Un identificador únic de sol·licitud i reserva.
• Inquilí, aplicació, API clau, ruta i classe de càrrega de treball.
• Fitxas d'entrada estimades, fitxes de sortida, fitxes totals i despesa.
• Cada cub cobrat per la reserva.
• Temps de creació, temps de caducitat, data límit de la cua i clau d'idempotència.
• Ús real final i l'import alliberat o cobrat durant la conciliació.

Les estimacions conservadores redueixen les respostes del proveïdor 429, però poden limitar la capacitat. Mesureu l'error d'estimació per model, ruta, família d'indicadors, longitud del context i mode de sortida estructurada. A continuació, ajusteu les estimacions mitjançant correccions limitades en lloc de permetre que una sola sol·licitud inusual distorsioni tot el model.

La reproducció en temps real requereix una política específica. Podeu reservar la quantitat màxima de sortida i alliberar la part no utilitzada quan acabi el flux, o reservar la capacitat de sortida en increments més petits a mesura que arribin les fitxes. El primer enfocament és més fàcil de raonar; el segon pot millorar l'ús, però requereix cancel·lació, temps d'espera i gestió de desconnexió fiables.

Aplicar les quotes jeràrquicament

La capacitat s'ha de comprovar des de la política més limitada fins al recurs compartit més ampli. Una jerarquia típica és:

1. API clau o identitat del servei.
2. Aplicació i entorn.
3. Inquilí d'equip o client.
4. Compte de soci o distribuïdor.
5. Espai de treball o subcompte del proveïdor.
6. Projecte o organització del proveïdor.
7. Model i ruta.

Per tant, una sol·licitud d'una aplicació de partner pot necessitar quatre reserves: la política de concurrència del partner, el pressupost de testimoni de l'arrendatari del client, l'assignació de rutes de la passarel·la i la quota disponible del projecte del proveïdor. Si alguna reserva falla, allibereu les reserves ja adquirides i apliqueu la decisió del grup fallat.

Per ser justos, utilitzeu la cua justa ponderada o el round-robin deficitari en lloc de permetre que el treballador que arribi primer consumeixi el grup compartit. Assigna pes més alts al trànsit de producció i pes més baixos als treballs de fons, tot conservant els crèdits de ràfega per a cada inquilí. La partició dura és més fàcil d'explicar, però pot deixar la capacitat inactiva quan un inquilí està en silenci. L'ús compartit ponderat generalment utilitza la capacitat de manera més eficient, sempre que els inquilins sorollosos tinguin límits de ràfega limitats.

Dissenyeu cues al voltant dels contractes de càrrega de treball

Una cua no és automàticament una funció de fiabilitat. Pot convertir un 429 visible en un retard invisible de deu minuts. Cada classe de cua necessita una data límit, un comportament de cancel·lació, una profunditat màxima i una acció de sobrecàrrega.

• Interactiu: Termini curt, cua petita, rebuig previsible o degradació del model quan la capacitat no està disponible.
• Antecedents de producció: Termini més llarg, cua duradora, clau d'idempotència i pressupost de reintents controlat.
• Partner: Quotes específiques de l'inquilí, metadades de resposta publicades i sense accés a l'estat de la cua d'un altre inquilí.
• Batchable: Execució retardada, cua més gran i encaminament opcional a un lot de proveïdor API quan la càrrega de treball ho permet.

L'admissió a la cua hauria de retornar una decisió clara. En funció del contracte API, exposa una resposta de sobrecàrrega 429 o específica de la passarel·la amb un valor de reintent després, un identificador de cua i un codi de motiu. No prometeu un temps de finalització tret que el sistema pugui fer complir aquesta promesa.

El processament per lots pot eliminar el treball no interactiu de la capacitat síncrona, però canvia el temps dels resultats, el comportament dels reintents, la cancel·lació i la conciliació. Tracteu-lo com una ruta d'execució independent en lloc de col·locar sol·licituds sincròniques en una cua molt llarga. Per a les càrregues de treball en segon pla, compareu les compensacions operatives amb les polítiques de control de costos d'AI API i les operacions per lots existents.

Centralitzar el reintent i la gestió de la sobrecàrrega

Fet: Les respostes de límit de velocitat temporals solen utilitzar el HTTP 429, mentre que les condicions de sobrecàrrega del proveïdor poden utilitzar el 503 o un codi d'error específic del proveïdor. Alguns proveïdors tornen una capçalera Retry-After i la documentació del proveïdor recomana que l'honori quan estigui present. Una rampa de trànsit ràpida també pot produir un comportament d'acceleració o desacceleració sense esgotar la galleda normal.

Recomanació: Tracteu Reintentar-Després com un límit inferior, no com un suggeriment opcional. Posa en pausa l'abast del proveïdor afectat fins a aquest moment, afegiu fluctuacions limitades per evitar activacions sincronitzades i deixeu que l'agent decideixi quines sol·licituds en cua poden utilitzar la capacitat recuperada.

Quan Retry-After no és vàlid o no és vàlid, utilitzeu un backoff exponencial limitat amb fluctuació. Conserveu el pressupost de reintents al corredor, no per separat a cada SDK i adaptador del proveïdor. En cas contrari, una sol·licitud lògica pot produir un nou intent de passarel·la, un SDK reintent, un HTTP reintent del client i una reproducció del proveïdor.

Classifica els errors abans de tornar-ho a provar:

• Capacitat que es pot tornar a provar: Resposta de quota transitòria temporal 429 o documentada.
• Sobrecàrrega que es pot tornar a provar: Senyal de sobrecàrrega del proveïdor temporal 503 o equivalent.
• Error de la política que no es pot tornar a intentar: Quota diària, límit de despesa, projecte desactivat o límit d'inquilí.
• Error de sol·licitud que no es pot tornar a intentar: Esquema no vàlid, paràmetre no admès, error d'autenticació o entrada amb format incorrecte.
• Error de la data límit: Una sol·licitud el termini de l'usuari o del flux de treball restant és més curt que el següent intent segur.

La alternativa és una decisió independent. Un proveïdor diferent pot tenir un comportament de sortida, un preu, una latència, una residència o uns límits de context diferents. Utilitzeu la alternativa només quan la política de ruta confirmi que el contracte de càrrega de treball pot tolerar aquestes diferències.

Exposa decisions i mesura la saturació

Els equips no poden solucionar problemes d'acceleració si la passarel·la només retorna un 429 genèric. Retorna metadades segures, com ara el límit aplicable, la capacitat restant, el temps de restabliment, la decisió de la cua, la classe de càrrega de treball i el motiu del rebuig. Eviteu exposar l'ús d'un altre inquilí o les credencials del proveïdor en brut.

Com a mínim, supervisa:

• Percentatge d'èxit de la reserva i de rebuig per llogater, ruta i cub.
• Profunditat de la cua, temps d'espera de la cua, venciments de terminis i cancel·lacions.
• Tarifes del proveïdor 429 i 503, freqüència de reintentar després i rebuigs de velocitat ràpida.
• Ús estimat en comparació amb el real i la capacitat malgastada per una reserva excessiva.
• La saturació de concurrència i la quota de capacitat consumida per cada inquilí.
• Torna a intentar-ho per sol·licitud lògica i freqüència de reserva.
• Quota diària i marge de la finestra de despesa.

Les proves de càrrega haurien d'incloure trànsit de ràfega, sol·licituds de context llarg, sol·licituds de sortida màxima, desconnexions de transmissió en temps real, esgotament de la quota diària, respostes del proveïdor 429 i 503 i un inquilí sorollós que competeix amb el trànsit de producció. Valideu no només si les sol·licituds s'acaben de completar, sinó també si els terminis de la cua, l'equitat i els pressupostos de reintents romanen intactes.

Llista de comprovació d'implementació

• Definiu dimensions canòniques sense descartar els límits específics del proveïdor.
• Assigneu a cada sol·licitud un inquilí normalitzat, una ruta, una classe de càrrega de treball i una clau d'idempotència.
• Calculeu i reserveu l'entrada, la sortida, el total de fitxes, la despesa, les sol·licituds i la concurrència abans de l'enviament.
• Feu atòmics les reserves de diversos compartiments i caduqueu les reserves abandonades de manera segura.
• Reconciliar l'ús real del proveïdor i les capçaleres de resposta després de cada intent.
• Utilitzeu l'equitat ponderada, els crèdits d'explosió i les classes de prioritat explícita.
• Doneu a cada cua una data límit, una profunditat màxima i una acció de sobrecàrrega.
• Centralitzeu els reintents i honoreu els valors Retry-After del proveïdor.
• Separeu els errors de capacitat temporals de les polítiques permanents i sol·liciteu els errors.
• Publiqueu metadades d'acceleració i superviseu la saturació per inquilí i ruta.
• Prova l'exhauriment de la quota del proveïdor, els límits de rampa, la transmissió en temps real, la alternativa i el comportament dels veïns sorollosos.

Conclusió

Una passarel·la multimodel hauria de gestionar la quota del proveïdor com a capacitat d'infraestructura compartida, no com una col·lecció de configuracions independents SDK. Un intermediari de límit de tarifes neutral per al proveïdor ofereix als equips de la plataforma una ruta d'admissió, una política d'equitat, un pressupost de reintent i un lloc per conciliar les estimacions amb la realitat.

El disseny requereix més que un cub de testimonis genèric. Ha de representar sol·licituds, testimonis d'entrada i sortida, quotes diàries, períodes de despesa, concurrència, abast del proveïdor i taxa de rampa. Un cop aquestes dimensions siguin explícites, la passarel·la pot prendre decisions previsibles: enviar ara, fer cua amb una data límit, deixar el treball, tornar a provar de manera centralitzada o utilitzar una alternativa segura per al contracte. Així és com el control del rendiment es converteix en una capacitat operativa en lloc d'una font recurrent d'incidències de producció 429 i 503.

Lectura relacionada

• processament per lots per a càrregues de treball de LLM no interactives