Passarel·les d'API d'IA conscients del límit de tarifes: forma RPM, TPM, ràfegues i equitat dels inquilins abans de l'impacte de 429s

Un 429 d'un proveïdor de LLM no és només un senyal de reintent. En producció, sovint es mostra que la vostra aplicació ja ha perdut el control de l'admissió, l'equitat dels inquilins, la latència o la comptabilitat de quotes específica del proveïdor.

La solució comuna, la reducció exponencial, és necessària però incompleta. Backoff reacciona després que el proveïdor rebutgi el trànsit. Una passarela d'API AI que tingui en compte el límit de tarifes hauria de donar forma al trànsit abans que les sol·licituds surtin del vostre sistema: calculeu la pressió del testimoni, reserveu la quota, aïlleu els inquilins, poseu a la cua el treball adequat, rebutgeu el treball equivocat i adapteu-vos quan canviïn els límits del proveïdor.

Aquest article descriu un governador de quota de passarel·la pràctic per als equips que envien càrregues de treball de producció a diversos proveïdors de LLM mitjançant una API unificada.

El problema del lector: els 429 són multidimensionals

Molts equips tracten els límits de tarifes com si fossin un sol nombre de sol·licituds per minut. Aquesta hipòtesi trenca ràpidament amb les API de LLM.

Fets de la documentació actual del proveïdor:

• OpenAI documenta que els límits es poden aplicar en finestres més curtes que el límit per minut anunciat, de manera que les ràfegues curtes poden fallar fins i tot quan el minut mitjà sembla segur.
• La quota d'Azure OpenAI s'assigna per subscripció, regió, model i tipus de desplegament en testimonis per minut. L'assignació de TPM a un desplegament també determina els límits de RPM d'inferència forçada i les relacions entre RPM i TPM varien segons el model.
• Azure OpenAI també assenyala que els càlculs de testimonis de límit de tarifa s'estimen quan es rep la sol·licitud i no són els mateixos que els recomptes de testimonis de facturació finals.
• Els documents antròpics separen els límits de sol·licituds per minut, fitxes d'entrada per minut i fitxes de sortida per minut. Superar els límits retorna un 429 amb una capçalera de reintentar després.
• Anthropic adverteix que els forts augments del trànsit poden arribar als límits d'acceleració i recomana una acceleració gradual.
• Per a la majoria de models de Claude, els documents Anthropic en què els testimonis d'entrada de lectura de memòria cau no compten per als límits de testimonis d'entrada per minut, la qual cosa significa que la memòria cau ràpida pot canviar l'espai d'accés efectiu.
• Els límits de tarifa de l'API de Google Gemini estan lligats als nivells d'ús del projecte, amb nivells més alts en funció de la configuració de la facturació, la despesa acumulada i el temps transcorregut després de les fites de pagament.

La lliçó operativa és clara: una forma de sol·licitud compatible amb OpenAI no implica un comportament de quota compatible amb OpenAI. Una passarel·la multiproveïdor necessita un model de quota intern que sigui més ric que "tornar-ho si 429".

Objectiu del disseny: fer del control d'admissions una responsabilitat de passarel·la

Una passarel·la conscient del límit de tarifes hauria de respondre cinc preguntes abans d'enviar una sol·licitud:

1. Quin proveïdor, model, implementació, regió, projecte o àrea de treball rebrà la sol·licitud?
2. Quanta capacitat de sol·licitud, testimoni d'entrada, testimoni de sortida i concurrència pot consumir?
3. A quin inquilí, equip, clau d'API, client o classe de càrrega de treball s'ha de cobrar per la capacitat compartida?
4. La sol·licitud s'ha d'admetre ara, posar-la a la cua breument, rebaixar-la, dirigir-la a un altre lloc o rebutjar-la?
5. Com s'ha de conciliar la reserva després que el proveïdor torni l'ús real?

La passarel·la es converteix en un governador de quota. No substitueix els límits del proveïdor. Fa que els límits del proveïdor siguin visibles, previsibles i justos dins del vostre propi sistema.

Crea un model de quota normalitzat

Comenceu definint les dimensions internes del limitador que puguin representar els principals proveïdors sense forçar-los a un cub enganyós.

Mides recomanades del limitador

• RPM: sol·licituds per minut.
• Introdueix TPM: indicació, missatge, eina i testimonis de context per minut.
• TPM de sortida: fitxes de finalització per minut, reservades per separat per a reproduccions en temps real i generacions llargues.
• TPM total: útil per a proveïdors o implementacions que exposen la pressió de testimoni combinada.
• Simultània: sol·licituds actives, emissions actives o feines en vol.
• Durada de la reproducció en temps real: els fluxos de llarga durada poden ocupar espai de connexió i testimoni de sortida fins i tot quan el RPM sigui baix.
• Àmbit específic del proveïdor: subscripció/regió/desplegament d'Azure, espai de treball antròpic/classe de model, projecte/nivell de Google o organització/projecte/grup de models d'OpenAI.

No amagueu les dimensions específiques del proveïdor. Normalitzeu-los en un esquema comú, però preserveu prou detall per explicar un rebuig més endavant.

{
  "proveïdor": "proveïdor_a",
  "model_profile": "Xat ràpid",
  "abast_proveïdor": {
    "projecte": "prod",
    "region": "us-est",
    "desplegament": "xat-large-01"
  },
  "límits": {
    "rpm": 1200,
    "entrada_tpm": 800000,
    "output_tpm": 250000,
    "concurrència": 200
  }
}

Aquest objecte intern s'ha de configurar explícitament, no s'ha de deduir només dels noms dels models. Els taulers de control del proveïdor, els nivells de compte, les implementacions regionals i la configuració de l'espai de treball poden canviar la capacitat efectiva de la mateixa família de models.

Estimeu la pressió del testimoni abans de l'enviament

La limitació de tarifes per part del proveïdor sovint es produeix abans que es conegui l'ús final de la facturació. La vostra passarel·la hauria de fer el mateix tipus d'estimació conservadora abans d'enviar trànsit.

Entrades de reserva prèvia al vol

• Avís serialitzat i longitud del missatge.
• Tokenització específica del model i sobrecàrrega per a funcions, eines, imatges o instruccions de sortida estructurades.
• max_completion_tokens o límit de sortida equivalent.
• Ratio de finalització històrica d'aquest punt final, inquilí, perfil de model i classe de sol·licitud.
• Tokens de lectura de la memòria cau esperats si la memòria cau d'invites està disponible i es pot mesurar.
• Marca de reproducció i durada prevista de la reproducció.

Sovint n'hi ha prou amb una simple regla de reserva per començar:

estimated_input_tokens = tokenize(request_messages) + model_overhead
fitxes_de_sortida_estimada = min(
  max_completion_tokens,
  p95_indicadors_de_sortida_històrica_per_la_ruta
)
reserved_total_tokens = estimated_input_tokens + estimated_output_tokens

Per a rutes desconegudes, utilitzeu un valor predeterminat conservador. Per a rutes de producció estables, actualitzeu les estimacions contínuament a partir de l'ús real.

Reserva i després concilia

Les reserves de quota no s'han de convertir en càrrecs permanents. Tracta'ls com a presa:

1. Cita: estima la pressió d'entrada i sortida.
2. Reserva: es dedueix dels dipòsits de fitxes rellevants abans de l'enviament.
3. Resolució: substituïu l'estimació per l'ús informat pel proveïdor quan estigui disponible.
4. Reembossament o dèbit: retorneu la capacitat reservada no utilitzada o cobreu els excedents a la finestra següent si cal.

Això és més important per a les trucades de context llarg i en temps real. Si només comproveu el TPM d'entrada abans de l'enviament, un flux pot iniciar-se amb èxit i després es trobarà amb la pressió del testimoni de sortida. Reservar l'espai de sortida de sortida per separat redueix el risc d'interrupció del flux mitjà i el risc d'aturada.

Utilitzeu grups de testimonis jeràrquics per a l'equitat dels inquilins

Un únic limitador global protegeix el compte del proveïdor però no protegeix els llogaters els uns dels altres. Un treball per lots de context llarg pot consumir TPM compartit i provocar que les sol·licituds interactives d'altres equips fallin.

Utilitza els contenidors de testimoni jeràrquics:

organització
  └── llogater
      └── equip
          └── api_key
              └── model_profile
                  └── provider_deployment

Una sol·licitud ha de passar cada grup rellevant. Això us permet aplicar diverses polítiques alhora:

• L'organització no pot superar la capacitat del proveïdor.
• Un inquilí no pot consumir més de la quota contractada.
• Una clau d'API no pot superar el límit d'aplicació o d'entorn previst.
• Un perfil de model per lots no pot eliminar un perfil de model interactiu.
• Un desplegament de proveïdor no es pot sobrecarregar encara que un altre desplegament tingui quota de recanvi.

Compartició justa versus utilització

Recomanació: utilitzeu la compartició justa ponderada amb préstecs en ràfega controlada.

Els límits estrictes per inquilí són fàcils d'explicar, però poden limitar la capacitat no utilitzada. El préstec en ràfega millora l'ús ja que permet a un inquilí utilitzar temporalment la quota inactiva d'un grup compartit. La compensació és la complexitat: els taulers han de mostrar què es va garantir, què es va prestar i quan es va revocar el préstec.

Una regla pràctica:

• Oferiu a cada inquilí una línia de base garantida.
• Permet préstecs en ràfega de la capacitat compartida no utilitzada.
• Recupereu la capacitat prestada quan aparegui trànsit de prioritat més alta o garantit.
• Mai deixeu que el trànsit prestat creï 429 a nivell de proveïdor per al trànsit garantit.

Separeu les classes de trànsit abans de competir

No totes les sol·licituds mereixen el mateix comportament de la cua. Col·loqueu trànsit als perfils de models amb cues i grups de quotes separats.

La cua millora la taxa d'èxit però augmenta la latència de la cua. Una passarel·la hauria de fer explícit aquest compromís. Per exemple, una sol·licitud interactiva pot esperar fins a 300 mil·lisegons per obtenir la quota i després retrocedir o fallar. Una tasca per lots nocturna pot esperar 20 minuts i encara es considera correcta.

Normalitzeu els 429 en un únic esquema d'error

Fins i tot amb un bon control d'admissió, els proveïdors 429 encara es produiran. Els límits poden canviar, les estimacions del proveïdor poden diferir de les vostres i el trànsit pot arribar en ràfegues més pronunciades del que s'esperava.

Normalitzeu cada proveïdor 429 en un objecte d'error de passarel·la:

{
  "error": {
    "tipus": "taxa_limitada",
    "limitador": "output_tpm",
    "proveïdor": "proveïdor_a",
    "model_profile": "Xat ràpid",
    "provider_model": "model-x",
    "retry_after_ms": 2400,
    "tenant_id": "arrendatari_123",
    "api_key_id": "key_456",
    "request_class": "interactiu",
    "estimated_input_tokens": 4200,
    "estimated_output_tokens": 800,
    "gateway_decision": "admitted_then_provider_rejected",
    "fallback_allowed": fals,
    "trace_id": "trace_abc"
  }
}

El camp clau és gateway_decision. Un 429 després que la passarel·la va admetre la sol·licitud és diferent d'una sol·licitud que la passarel·la va rebutjar localment abans de l'enviament. El primer indica un problema de calibratge del limitador. El segon indica una protecció intencionada.

Adapteu-vos de les capçaleres del proveïdor, però no en depengueu

Alguns proveïdors retornen capçaleres útils, com ara indicadors de reintent després o de capacitat restant. Utilitzeu-los quan estiguin disponibles.

Recomanació: les capçaleres del proveïdor haurien d'ajustar el vostre governador local, no substituir-lo.

Motius:

• La disponibilitat de la capçalera difereix segons el proveïdor i el punt final.
• És possible que les capçaleres no exposin totes les dimensions del limitador.
• Tornar a provar després t'indica quan ho has de tornar a provar, no quin llogater hauria d'aconseguir la capacitat següent.
• Les estimacions dels testimonis del proveïdor poden diferir de la vostra facturació o comptabilitat interna.

Una implementació sòlida actualitza els índexs d'ompliment de la cubeta local i els temps de reutilització en funció de les capçaleres, alhora que imposa els límits de desplegament d'inquilí, clau d'API, classe de trànsit i proveïdor dins de la passarel·la.

Afegiu governadors de rampa per a migracions i feines programades

Molts incidents de límit de velocitat es produeixen durant els canvis planificats: passar d'un model a un altre, canviar de proveïdor, habilitar un nou flux de treball d'agent o llançar una avaluació programada.

Recomanació: tracteu el creixement del trànsit com un llançament controlat.

• Migracions de models de marca de funcions per inquilí, ruta o percentatge de trànsit.
• Definiu límits de creixement per minut per a les implementacions de nous proveïdors.
• Escalfeu el trànsit gradualment durant hores en lloc de canviar tot el trànsit a l'instant.
• Atureu el llançament quan el ritme 429, el ritme de degradació, la profunditat de la cua o la latència p95 superin un llindar.
• Mantingueu una ruta de retrocés d'emergència amb una política de compatibilitat, no només un model de recanvi.

Predicció: a mesura que els modes d'encaminament del proveïdor, els nivells de prioritat i els controls a nivell d'espai de treball siguin més habituals, el govern de rampa es convertirà en una funció de passarel·la estàndard en lloc d'un script de resposta a incidents.

La alternativa és una decisió política, no només una decisió de capacitat

Quan un proveïdor retorna un 429, l'encaminament a un altre proveïdor pot ser la resposta correcta. També pot ser insegur.

La alternativa pot canviar:

• Qualitat de la sortida i instruccions següents.
• Llargada del context.
• Comportament de trucada d'eines.
• Fiabilitat de la sortida estructurada.
• Retenció de dades i postura de residència.
• Cost i latència.

El governador de la quota hauria de preguntar a una capa de compatibilitat si es permet una alternativa per a aquesta classe de sol·licitud. Si no, hauria de posar-se en cua o fallar amb una resposta de límit de velocitat local clara en lloc de canviar la semàntica en silenci.

Exposa taulers de control de quota que expliquen les decisions

S'evitarà un sistema de quotes que ningú pot entendre. Creeu taulers de control sobre preguntes operatives:

• Quins inquilins consumeixen més RPM, TPM d'entrada i TPM de sortida?
• Quins perfils de model estan a la cua, rebutjant o retrocedint?
• Quin abast del proveïdor és el coll d'ampolla: projecte, regió, desplegament, espai de treball, classe de model o nivell de compte?
• A quina freqüència difereixen les estimacions de la passarel·la de l'ús del proveïdor?
• Quina és la distribució de reintents després per proveïdor i tipus de limitador?
• Quant espai efectiu es creen les lectures de la memòria cau d'avís?
• Quines classes de trànsit prenen prestada capacitat de ràfega?

Per als productes orientats al client o als socis, exposa els controls segurs:

• Límits de tarifa per clau.
• Límits de ràfega per equip.
• Límits diaris per client.
• Pausa d'emergència per a un inquilí o clau.
• Alertes de pics de 429, creixement de la cua i pressió de testimoni anormal.
• Punts finals de l'API de partner per a la gestió de quotes de distribuïdors.

Això converteix la limitació de velocitat d'un error misteriós del proveïdor en una part auditable del govern de l'API d'equip.

Llista de verificació d'implementació

Fase 1: observar i classificar

• Registreu el proveïdor, el model, el desplegament, la regió, l'espai de treball, el projecte, l'arrendatari, la clau API i la classe de sol·licitud per a cada trucada.
• Captureu el proveïdor 429 amb metadades d'error en brut i reintent després.
• Enregistreu els testimonis d'entrada/sortida estimats i reals per separat.
• Separa el trànsit interactiu, per lots, d'avaluació i de fons a la telemetria.

Fase 2: control d'admissió local

• Creeu objectes limitadors interns per a RPM, TPM d'entrada, TPM de sortida, TPM total i concurrència.
• Afegiu una estimació de testimonis previs al vol.
• Reserveu la quota abans de l'enviament i reconcilieu-la després que arribi l'ús del proveïdor.
• Rebutja localment quan una sol·licitud no s'adapta al seu grup d'inquilí o de proveïdor.

Fase 3: equitat i cues

• Afegiu grups jeràrquics des de l'organització fins al desplegament del proveïdor.
• Assigneu accions garantides per a llogaters i préstecs de ràfega controlats.
• Creeu cues separades per classe de trànsit.
• Estableix temps d'espera màxims específics de classe i regles alternatives.

Fase 4: adaptació i operacions

• Utilitzeu les capçaleres del proveïdor per ajustar els temps de reutilització i omplir les hipòtesis.
• Afegiu governadors de rampa per a migracions i feines programades.
• Exposa taulers de control de quota i alertes.
• Reviseu l'error d'estimació i la quota encallada setmanalment.

Conclusió accionable

Si la vostra passarel·la només torna a provar 429s, està funcionant després de l'error. Una passarela d'API AI de nivell de producció hauria d'evitar la majoria dels errors de límit de velocitat decidint qui pot enviar què, quan i amb quina quota de proveïdor.

Comenceu amb un model de limitador normalitzat, una reserva prèvia de testimonis de vol i cues de classe de trànsit. A continuació, afegiu l'equitat jeràrquica dels inquilins, l'adaptació de la capçalera del proveïdor i els governadors de rampa. El resultat no és només menys 429. És una assignació de capacitat més clara, una latència més predictible, migracions més segures i un comportament de límit de tarifes que els vostres equips d'enginyeria, finances i assistència al client poden explicar.

Lectura relacionada

• prompt comptabilitat de la memòria cau i anàlisi de dades de memòria cau
• polítiques d'encaminament de reserva compatibles