Gateways API de IA que tienen en cuenta los límites de velocidad: configure RPM, TPM, ráfagas y equidad para los inquilinos antes de que lleguen los 429

Un 429 de un proveedor de LLM no es solo una señal de reintento. En producción, a menudo es evidencia de que su aplicación ya ha perdido el control de admisión, equidad de inquilinos, latencia o contabilidad de cuotas específicas del proveedor.

La solución común (retroceso exponencial) es necesaria pero incompleta. Backoff reacciona después de que el proveedor rechaza el tráfico. Una puerta de enlace API AI con reconocimiento de límites de velocidad debe dar forma al tráfico antes de que las solicitudes abandonen su sistema: estimar la presión del token, reservar cuota, aislar inquilinos, poner en cola el trabajo correcto, rechazar el trabajo incorrecto y adaptarse cuando cambien los límites del proveedor.

Este artículo describe un regulador de cuota de puerta de enlace práctico para equipos que envían cargas de trabajo de producción a múltiples proveedores de LLM a través de una API unificada.

El problema del lector: los 429 son multidimensionales

Muchos equipos tratan los límites de velocidad como si fueran un número único de solicitudes por minuto. Esa suposición se rompe rápidamente con las API de LLM.

Datos de la documentación actual del proveedor:

• OpenAI documenta que los límites pueden aplicarse en períodos más cortos que el límite por minuto anunciado, por lo que las ráfagas cortas pueden fallar incluso cuando el minuto promedio parece seguro.
• La cuota de Azure OpenAI se asigna por suscripción, región, modelo y tipo de implementación en tokens por minuto. La asignación de TPM a una implementación también determina los límites de RPM de inferencia aplicados, y las proporciones de RPM a TPM varían según el modelo.
• Azure OpenAI también señala que los cálculos de tokens de límite de tasa se estiman cuando se recibe la solicitud y no son los mismos que los recuentos de tokens de facturación finales.
• Los documentos de Anthropic separan los límites de solicitudes por minuto, tokens de entrada por minuto y tokens de salida por minuto. Exceder los límites devuelve un 429 con un encabezado de reintento posterior.
• Anthropic advierte que los aumentos bruscos del tráfico pueden alcanzar los límites de aceleración y recomienda un aumento gradual.
• Para la mayoría de los modelos de Claude, los documentos de Anthropic que almacenan en caché los tokens de entrada no cuentan para los límites de tokens de entrada por minuto, lo que significa que el almacenamiento en caché rápido puede cambiar el margen efectivo.
• Los límites de tarifas de la API de Google Gemini están vinculados a los niveles de uso del proyecto; los niveles más altos dependen de la configuración de facturación, el gasto acumulativo y el tiempo transcurrido después de los hitos de pago.

La lección operativa es clara: una forma de solicitud compatible con OpenAI no implica un comportamiento de cuota compatible con OpenAI. Una puerta de enlace de múltiples proveedores necesita un modelo de cuota interna que sea más completo que "reintentar si 429".

Objetivo del diseño: hacer del control de admisión una responsabilidad de la puerta de entrada

Una puerta de enlace que tenga en cuenta el límite de velocidad debe responder cinco preguntas antes de enviar una solicitud:

1. ¿Qué proveedor, modelo, implementación, región, proyecto o espacio de trabajo recibirá la solicitud?
2. ¿Cuánta capacidad de solicitud, token de entrada, token de salida y simultaneidad podría consumir?
3. ¿Qué inquilino, equipo, clave de API, cliente o clase de carga de trabajo se debe cobrar por la capacidad compartida?
4. ¿Debería admitirse la solicitud ahora, ponerse en cola brevemente, degradarse, enrutarse a otro lugar o rechazarse?
5. ¿Cómo se debe conciliar la reserva después de que el proveedor devuelva el uso real?

La puerta de enlace se convierte en un regulador de cuotas. No reemplaza los límites del proveedor. Hace que los límites del proveedor sean visibles, predecibles y justos dentro de su propio sistema.

Construir un modelo de cuota normalizado

Empiece por definir las dimensiones del limitador interno que puedan representar a los principales proveedores sin obligarlos a agruparse en un grupo engañoso.

Dimensiones del limitador recomendadas

• RPM: solicitudes por minuto.
• Ingrese TPM: tokens de aviso, mensaje, herramienta y contexto por minuto.
• TPM de salida: tokens de finalización por minuto, reservados por separado para streaming y generaciones largas.
• TPM total: útil para proveedores o implementaciones que exponen presión de token combinada.
• Simultaneidad: solicitudes activas, transmisiones activas o trabajos en curso.
• Duración de la transmisión: las transmisiones de larga duración pueden ocupar espacio de conexión y de token de salida incluso cuando las RPM son bajas.
• Ámbito específico del proveedor: suscripción/región/implementación de Azure, espacio de trabajo/clase de modelo antrópico, proyecto/nivel de Google u organización/proyecto/grupo de modelo de OpenAI.

No oculte dimensiones específicas del proveedor. Normalícelos en un esquema común, pero conserve suficientes detalles para explicar un rechazo más adelante.

{
  "proveedor": "proveedor_a",
  "model_profile": "chat rápido",
  "alcance_proveedor": {
    "proyecto": "prod",
    "región": "ee.uu.-este",
    "implementación": "chat-large-01"
  },
  "límites": {
    "rpm": 1200,
    "entrada_tpm": 800000,
    "salida_tpm": 250000,
    "concurrencia": 200
  }
}

Este objeto interno debe configurarse explícitamente, no inferirse únicamente de los nombres de los modelos. Los paneles de control de proveedores, los niveles de cuenta, las implementaciones regionales y la configuración del espacio de trabajo pueden cambiar la capacidad efectiva de la misma familia de modelos.

Estimar la presión del token antes del envío

La limitación de tarifas por parte del proveedor suele ocurrir antes de que se conozca el uso de facturación final. Su portal debe hacer el mismo tipo de estimación conservadora antes de enviar tráfico.

Entradas de reserva de verificación previa

• Mensaje serializado y longitud del mensaje.
• Tokenización y gastos generales específicos del modelo para roles, herramientas, imágenes o instrucciones de salida estructuradas.
• max_completion_tokens o límite de salida equivalente.
• Proporción de finalización histórica para este punto final, inquilino, perfil de modelo y clase de solicitud.
• Tokens de lectura de caché esperados si el almacenamiento en caché está disponible y es mensurable.
• Indicador de transmisión y duración esperada de la transmisión.

Una simple regla de reserva suele ser suficiente para comenzar:

tokens_de_entrada_estimados = tokenize(solicitud_messages) + model_overhead
tokens_de_salida_estimados = min(
  max_completion_tokens,
  p95_tokens_de_salida_historica_para_ruta
)
tokens_totales_reservados = tokens_de_entrada_estimados + tokens_de_salida_estimados

Para rutas desconocidas, utilice un valor predeterminado conservador. Para rutas de producción estables, actualice las estimaciones continuamente a partir del uso real.

Reservar, luego conciliar

Las reservas de cuotas no deben convertirse en cargos permanentes. Trátelos como presas:

1. Cita: estimar la presión de entrada y salida.
2. Reserva: deducir de los depósitos de tokens pertinentes antes del envío.
3. Liquidar: reemplace la estimación con el uso informado por el proveedor cuando esté disponible.
4. Reembolso o débito: devolver la capacidad reservada no utilizada o cargar los excedentes en la siguiente ventana si es necesario.

Esto es más importante para llamadas de larga duración y de streaming. Si solo verifica el TPM de entrada antes del envío, una secuencia puede iniciarse correctamente y luego ejecutar presión de token de salida más adelante. Reservar el espacio libre de salida por separado reduce el riesgo de fallas a mitad de camino y bloqueo.

Utilice depósitos de tokens jerárquicos para lograr equidad para los inquilinos

Un limitador global único protege la cuenta del proveedor pero no protege a los inquilinos entre sí. Un trabajo por lotes de contexto prolongado puede consumir TPM compartido y provocar que fallen las solicitudes interactivas de otros equipos.

Usar depósitos de tokens jerárquicos:

organización
  └── inquilino
      └── equipo
          └── api_key
              └── perfil_modelo
                  └── proveedor_implementación

Una solicitud debe pasar por cada segmento relevante. Esto le permite aplicar varias políticas a la vez:

• La organización no puede exceder la capacidad del proveedor.
• Un inquilino no puede consumir más de su parte contratada.
• Una clave API no puede exceder su entorno previsto o límite de aplicación.
• Un perfil de modelo por lotes no puede privar a un perfil de modelo interactivo.
• La implementación de un proveedor no se puede sobrecargar incluso si otra implementación tiene una cuota adicional.

Reparto justo frente a utilización

Recomendación: utilice un reparto justo ponderado con endeudamiento en ráfagas controladas.

Los límites estrictos por inquilino son fáciles de explicar, pero pueden dejar sin uso la capacidad no utilizada. El préstamo en ráfagas mejora la utilización al permitir que un inquilino utilice temporalmente una cuota inactiva de un grupo compartido. La contrapartida es la complejidad: los paneles deben mostrar qué se garantizó, qué se tomó prestado y cuándo se revocó el préstamo.

Una regla práctica:

• Brinde a cada inquilino una base garantizada.
• Permitir el préstamo en ráfagas de capacidad compartida no utilizada.
• Recupere capacidad prestada cuando aparezca tráfico garantizado o de mayor prioridad.
• Nunca permita que el tráfico prestado cree 429 a nivel de proveedor para tráfico garantizado.

Separe las clases de tráfico antes de competir

No todas las solicitudes merecen el mismo comportamiento en la cola. Distribuya el tráfico en perfiles de modelo con colas y grupos de cuotas separados.

La cola mejora la tasa de éxito pero aumenta la latencia de cola. Una puerta de enlace debería hacer explícita esa compensación. Por ejemplo, una solicitud interactiva puede esperar hasta 300 milisegundos para alcanzar la cuota y luego retroceder o fallar. Un trabajo por lotes nocturno puede esperar 20 minutos y aun así considerarse exitoso.

Normalizar los 429 en un único esquema de error

Incluso con un buen control de admisión, los proveedores 429 seguirán ocurriendo. Los límites pueden cambiar, las estimaciones de los proveedores pueden diferir de las suyas y el tráfico puede llegar en ráfagas más intensas de lo esperado.

Normalice cada proveedor 429 en un objeto de error de puerta de enlace:

{
  "error": {
    "tipo": "tasa_limitada",
    "limitador": "output_tpm",
    "proveedor": "proveedor_a",
    "model_profile": "chat rápido",
    "provider_model": "modelo-x",
    "retry_after_ms": 2400,
    "tenant_id": "tenant_123",
    "api_key_id": "key_456",
    "request_class": "interactivo",
    "tokens_de_entrada_estimados": 4200,
    "tokens_de_salida_estimada": 800,
    "gateway_decision": "admitido_luego_proveedor_rechazado",
    "fallback_allowed": falso,
    "trace_id": "trace_abc"
  }
}

El campo clave es gateway_decision. Un 429 después de que la puerta de enlace admitió la solicitud es diferente de una solicitud que la puerta de enlace rechazó localmente antes del envío. El primero indica un problema de calibración del limitador. El segundo indica protección intencional.

Adaptar los encabezados de los proveedores, pero no depender de ellos

Algunos proveedores devuelven encabezados útiles, como reintentos posteriores o indicadores de capacidad restante. Úsalos cuando estén disponibles.

Recomendación: los encabezados de los proveedores deben ajustar el gobernador local, no reemplazarlo.

Razones:

• La disponibilidad del encabezado difiere según el proveedor y el punto final.
• Es posible que los encabezados no expongan todas las dimensiones del limitador.
• Reintentar después le indica cuándo volver a intentarlo, no qué inquilino debe obtener capacidad a continuación.
• Las estimaciones de tokens del proveedor pueden diferir de su facturación o contabilidad interna.

Una implementación sólida actualiza las tasas de recarga de depósitos locales y los tiempos de reutilización en función de los encabezados, al mismo tiempo que aplica los límites de implementación de inquilinos, claves de API, clases de tráfico y proveedores dentro de la puerta de enlace.

Añadir reguladores de rampa para migraciones y trabajos programados

Muchos incidentes de límite de tarifas ocurren durante cambios planificados: pasar de un modelo a otro, cambiar de proveedor, habilitar un nuevo flujo de trabajo de agente o iniciar una ejecución de evaluación programada.

Recomendación: trate el crecimiento del tráfico como una implementación controlada.

• Migraciones de modelos de indicadores de funciones por inquilino, ruta o porcentaje de tráfico.
• Establezca límites de crecimiento por minuto para implementaciones de nuevos proveedores.
• Caliente el tráfico gradualmente durante horas en lugar de cambiar todo el tráfico instantáneamente.
• Pausar el lanzamiento cuando la tasa 429, la tasa de degradación, la profundidad de la cola o la latencia p95 cruzan un umbral.
• Mantenga una ruta de reversión de emergencia con una política de compatibilidad, no solo un modelo de repuesto.

Predicción: a medida que los modos de enrutamiento de proveedores, los niveles de prioridad y los controles a nivel de espacio de trabajo se vuelvan más comunes, la gobernanza en rampa se convertirá en una característica de puerta de enlace estándar en lugar de un script de respuesta a incidentes.

El respaldo es una decisión política, no solo una decisión de capacidad

Cuando un proveedor devuelve un 429, enrutarlo a otro proveedor puede ser la respuesta correcta. También puede ser peligroso.

El respaldo puede cambiar:

• Calidad de salida y seguimiento de instrucciones.
• Longitud del contexto.
• Comportamiento de llamada de herramienta.
• Fiabilidad de salida estructurada.
• Posición de residencia y retención de datos.
• Coste y latencia.

El gobernador de cuota debe preguntar a una capa de compatibilidad si se permite el respaldo para esta clase de solicitud. De lo contrario, debería ponerse en cola o fallar con una respuesta clara de límite de velocidad local en lugar de cambiar silenciosamente la semántica.

Exponer paneles de cuotas que explican las decisiones

Se evitará un sistema de cuotas que nadie puede entender. Cree paneles en torno a preguntas operativas:

• ¿Qué inquilinos consumen más RPM, TPM de entrada y TPM de salida?
• ¿Qué perfiles de modelo están en cola, rechazados o retrocedidos?
• ¿Qué ámbito de proveedor es el cuello de botella: proyecto, región, implementación, espacio de trabajo, clase de modelo o nivel de cuenta?
• ¿Con qué frecuencia las estimaciones de la puerta de enlace difieren del uso del proveedor?
• ¿Cuál es la distribución de reintentos posteriores por proveedor y tipo de limitador?
• ¿Cuánto margen efectivo se crea mediante lecturas de caché rápidas?
• ¿Qué clases de tráfico están tomando prestada capacidad de ráfaga?

Para productos orientados al cliente o a socios, exponga controles seguros:

• Límites de tasa por clave.
• Límites de ráfagas por equipo.
• Límites diarios por cliente.
• Pausa de emergencia para un inquilino o llave.
• Alertas de 429 picos, crecimiento de colas y presión anormal de tokens.
• Puntos finales de API de socios para la gestión de cuotas de revendedores.

Esto convierte la limitación de velocidad de un misterioso error del proveedor en una parte auditable del gobierno de la API del equipo.

Lista de verificación de implementación

Fase 1: observar y clasificar

• Proveedor de registro, modelo, implementación, región, espacio de trabajo, proyecto, inquilino, clave API y clase de solicitud para cada llamada.
• Capture proveedores 429 con reintentos posteriores y metadatos de error sin procesar.
• Registre los tokens de entrada/salida estimados y reales por separado.
• Separe el tráfico interactivo, por lotes, de evaluación y en segundo plano en la telemetría.

Fase 2: control de admisión local

• Cree objetos limitadores internos para RPM, TPM de entrada, TPM de salida, TPM total y simultaneidad.
• Agregar estimación de token de verificación previa.
• Reserve la cuota antes del envío y concilie después de que llegue el uso del proveedor.
• Rechazar localmente cuando una solicitud no se ajuste a su grupo de inquilino o proveedor.

Fase 3: equidad y colas

• Agregue depósitos jerárquicos desde la organización hasta la implementación del proveedor.
• Asignar acciones de inquilinos garantizadas y endeudamiento explosivo controlado.
• Cree colas separadas por clase de tráfico.
• Establezca tiempos de espera máximos y reglas de reserva específicos de cada clase.

Fase 4: adaptación y operaciones

• Utilice encabezados de proveedores para ajustar los tiempos de reutilización y rellenar los supuestos.
• Añadir reguladores de rampa para migraciones y trabajos programados.
• Exponer alertas y paneles de cuotas.
• Revisar el error de estimación y la cuota bloqueada semanalmente.

Conclusión procesable

Si su puerta de enlace solo reintenta 429, está funcionando después del error. Una puerta de enlace API AI de nivel de producción debería evitar la mayoría de las fallas en el límite de velocidad al decidir quién puede enviar qué, cuándo y contra qué cuota de proveedor.

Comience con un modelo limitador normalizado, reserva de tokens de verificación previa y colas de clase de tráfico. Luego agregue equidad jerárquica para inquilinos, adaptación del encabezado del proveedor y gobernadores de rampa. El resultado no es sólo menos 429. Se trata de una asignación de capacidad más clara, una latencia más predecible, migraciones más seguras y un comportamiento de límite de velocidad que sus equipos de ingeniería, finanzas y atención al cliente realmente pueden explicar.

Lectura relacionada

• reserva y uso previo al vuelo reconciliación
• contabilidad de caché rápida y análisis de visitas de caché
• políticas de enrutamiento alternativo compatibles