Explicación de los límites de tasa de LLM: RPM, TPM y reintentos

Los límites de tasa de LLM determinan cuánto tráfico puede enviar tu aplicación a un modelo dentro de una ventana de tiempo. Los dos límites que los ingenieros encuentran con más frecuencia son RPM (solicitudes por minuto) y TPM (tokens por minuto). Una carga de trabajo puede mantenerse por debajo de uno y aun así superar el otro.

Esa distinción importa. Si tratas cada 429 como un problema genérico de conteo de solicitudes, puedes añadir reintentos que aumenten la presión de tokens, incrementen la latencia y empeoren una caída del servicio. Un diseño seguro para producción identifica primero el recurso restringido y luego elige entre ritmo, colas, reintentos, reducción de tokens o redirección a otro lugar.

Esta guía explica la mecánica, proporciona fórmulas de planificación de capacidad e incluye un patrón de reintento acotado en TypeScript para APIs compatibles con OpenAI.

RPM vs. TPM: la respuesta rápida

RPM controla la frecuencia. TPM controla el rendimiento. La concurrencia controla el trabajo simultáneo. Interactúan, pero no son intercambiables.

Por qué una solicitud puede fallar por debajo del límite principal

Un límite publicado como 600 RPM no significa necesariamente que un cliente pueda enviar 600 solicitudes en el primer segundo de cada minuto. Los proveedores suelen aplicar límites con ventanas deslizantes o controles de estilo token bucket. Una ráfaga breve puede agotar la capacidad disponible de inmediato, incluso cuando la aritmética para todo el minuto parece segura.

Otras razones por las que un 429 puede aparecer antes incluyen:

• El límite se aplica a un proyecto, organización, cuenta, familia de modelos o nivel de servicio, en lugar de a una sola clave de API.
• Los tokens de entrada y salida usan buckets separados.
• Múltiples trabajadores, servicios o usuarios comparten el mismo grupo de cuota.
• Los reintentos de fallos anteriores están consumiendo el mismo límite.
• El proveedor está aplicando un límite de aceleración o de ráfaga mientras el tráfico aumenta bruscamente.
• Un grupo específico del modelo está lleno aunque otro modelo aún tenga capacidad.

Por eso la aplicación no debe inferir la causa solo a partir de su propio contador de solicitudes. Lee el cuerpo de la respuesta y las cabeceras, conserva los IDs de solicitud del proveedor y registra el modelo, la cuenta, las estimaciones de tokens, el número de intento y el retraso en cola.

Una fórmula práctica de capacidad

Empiece con dos topes independientes.

request_ceiling = RPM × safety_factor

token_ceiling = (TPM × safety_factor) ÷ average_tokens_per_request

safe_requests_per_minute = min(request_ceiling, token_ceiling)

Use un factor de seguridad por debajo de 1.0—por ejemplo 0.7 a 0.9—para absorber la variación de tokens, los reintentos, los consumidores compartidos y los patrones de llegada desiguales.

Ejemplo

Suponga que un grupo de modelos permite:

• 1,000 RPM
• 2,000,000 TPM
• 4,000 tokens totales promedio por solicitud
• factor de seguridad operativa del 80%

request_ceiling = 1,000 × 0.8 = 800 solicitudes/minuto

token_ceiling = (2,000,000 × 0.8) ÷ 4,000
              = 400 solicitudes/minuto

safe_requests_per_minute = min(800, 400) = 400

TPM es la restricción vinculante. Agregar más trabajadores no aumentará el rendimiento sostenible; solo creará una cola más grande o más respuestas 429.

Para los sistemas en línea, traduzca el rendimiento en un punto de partida de concurrencia con la ley de Little:

target_concurrency ≈ requests_per_second × average_request_seconds

Si la tasa segura es de 400 solicitudes por minuto (6.67 por segundo) y la latencia promedio del modelo es de 3 segundos, una concurrencia inicial es de aproximadamente 20. Añada margen con cuidado y luego ajuste según la latencia p95 real y las distribuciones de tokens.

Los límites de tokens suelen ser el cuello de botella oculto

Los equipos a menudo supervisan los conteos de solicitudes, pero pasan por alto el volumen de tokens. La presión de TPM aumenta cuando usted:

• Agrega más documentos recuperados a cada prompt.
• Mantiene historiales de conversación largos.
• Ejecuta varias completaciones candidatas por tarea.
• Aumenta los límites de salida.
• Envía repetidamente el mismo prompt grande de sistema.
• Lanza suites de evaluación paralelas contra una cuota de proyecto.

Mida al menos cuatro valores de tokens por cada solicitud exitosa:

1. Tokens de entrada.
2. Tokens de salida.
3. Tokens totales.
4. Un p50, p95 y máximo en curso por carga de trabajo y modelo.

La planificación de capacidad solo con el promedio es optimista. Un programador más seguro reserva con base en un percentil alto o en una estimación específica de la carga de trabajo, y luego reconcilia la reserva con el uso real después de la finalización.

Qué significa un 429 y qué no significa

HTTP 429 Too Many Requests le indica que el servidor rechazó la solicitud bajo un límite activo o una política de capacidad. No significa automáticamente “espere un segundo e inténtelo de nuevo”.

Clasifique un 429 en un grupo operativo:

El cuerpo y los encabezados difieren según el proveedor. Prefiera una señal explícita Retry-After o de restablecimiento del límite de tasa cuando se proporcione. De lo contrario, use backoff exponencial con jitter aleatorio.

Backoff exponencial con jitter

El backoff exponencial aumenta el retraso después de cada intento fallido. El jitter aleatoriza ese retraso para que cientos de trabajadores no reintenten al mismo instante.

Una fórmula común de jitter completo es:

delay_ms = random(0, min(cap_ms, base_ms × 2^attempt))

Una política de reintentos de producción también necesita límites:

• Número máximo de intentos: normalmente una cantidad pequeña, no un bucle infinito.
• Tiempo máximo transcurrido: deténgase cuando se agote el presupuesto de latencia del llamador.
• Lista de estados reintentables: comúnmente 429, respuestas 5xx seleccionadas y fallos de red seguros.
• Pistas del servidor: respete Retry-After cuando sea válido.
• Cancelación: deténgase inmediatamente cuando la solicitud aguas arriba se cancele.
• Observabilidad: registre el conteo de intentos, el tiempo de espera, el estado final y el ID de solicitud del proveedor.

Las solicitudes fallidas aún pueden consumir capacidad del límite de tasa. Los reintentos agresivos pueden, por tanto, prolongar el período de limitación.

TypeScript: un helper de reintento con límites

El siguiente ejemplo usa la URL base Flatkey compatible con OpenAI. Solo reintenta antes de que se consuma un cuerpo de respuesta exitoso y se detiene cuando se agota el límite de intentos o el presupuesto de tiempo total.

type ChatRequest = {
  model: string;
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;
  max_tokens?: number;
};

const sleep = (milliseconds: number) =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

function retryAfterMilliseconds(response: Response): number | null {
  const value = response.headers.get("retry-after");
  if (!value) return null;

  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);

  const date = Date.parse(value);
  return Number.isNaN(date) ? null : Math.max(0, date - Date.now());
}

export async function createChatCompletion(
  apiKey: string,
  request: ChatRequest,
  options: { maxAttempts?: number; maxElapsedMs?: number } = {},
) {
  const maxAttempts = options.maxAttempts ?? 4;
  const maxElapsedMs = options.maxElapsedMs ?? 30_000;
  const startedAt = Date.now();

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(
      "https://router.flatkey.ai/v1/chat/completions",
      {
        method: "POST",
        headers: {
          Authorization: `Bearer ${apiKey}`,
          "Content-Type": "application/json",
        },
        body: JSON.stringify(request),
      },
    );

    if (response.ok) return response.json();

    const retryable = response.status === 429 || response.status >= 500;
    const finalAttempt = attempt === maxAttempts - 1;
    if (!retryable || finalAttempt) {
      throw new Error(`La solicitud al LLM falló con ${response.status}: ${await response.text()}`);
    }

    const hintedDelay = retryAfterMilliseconds(response);
    const exponentialCap = Math.min(8_000, 500 * 2 ** attempt);
    const jitteredDelay = Math.random() * exponentialCap;
    const delayMs = hintedDelay ?? jitteredDelay;

    if (Date.now() + delayMs - startedAt >= maxElapsedMs) {
      throw new Error("Se agotó el presupuesto de reintentos del LLM");
    }

    await sleep(delayMs);
  }

  throw new Error("Estado de reintento inalcanzable");
}

Para uso en producción, añada tiempos de espera de solicitud, tipos de error estructurados, métricas y la señal de cancelación de su aplicación. Si la operación puede crear efectos secundarios externos, como enviar un correo electrónico o ejecutar una herramienta, haga que la operación de negocio sea idempotente antes de reintentarlo.

¿Reintentar, poner en cola, reducir o enrutar?

Use la causa, no solo el código de estado, para elegir el control.

Reintentar

Reintenta cuando la falla sea transitoria y el solicitante aún tenga tiempo. Mantén un presupuesto de reintentos por solicitud y un presupuesto de reintentos a nivel de servicio para que un incidente del proveedor no pueda multiplicar el tráfico total.

Poner en cola

Pon en cola cuando la tasa de llegada supere temporalmente la tasa de servicio sostenible. Una cola útil expone:

• La antigüedad del elemento más antiguo.
• La hora estimada de inicio.
• La equidad por inquilino.
• La cancelación de trabajos obsoletos.
• Una profundidad máxima con comportamiento explícito de descarte.

Reducir tokens

Cuando TPM limita, elimina contexto irrelevante, resume el historial, reduce el número de candidatos, disminuye los límites de salida, almacena en caché los prefijos reutilizables del prompt cuando sea compatible, y separa el tráfico interactivo corto de los trabajos batch largos.

Derivar a otro lugar

El enrutamiento es apropiado cuando otro modelo o proveedor satisface el mismo contrato y tiene capacidad saludable. El respaldo debe preservar capacidades requeridas como salida estructurada, llamada a herramientas, longitud de contexto, política de seguridad y objetivo de latencia. Para un marco de implementación más profundo, usa el LLM API fallback routing playbook.

Límites de tasa en las evaluaciones de modelos

Un control de tasa deficiente puede invalidar una evaluación.

Supón que el modelo A se prueba con 10 trabajadores mientras que el modelo B se prueba con 100. Si el modelo B pasa más tiempo limitado por throttling, su latencia medida incluye tiempo de cola y retraso por reintentos que el modelo A nunca afrontó. El resultado puede describir la configuración de tu entorno de pruebas en lugar del rendimiento del modelo.

Para comparaciones defendibles:

1. Separa la latencia del modelo, el retraso de cola y el retraso por reintentos.
2. Aplica el mismo proceso de llegada o un nivel de utilización normalizado a cada proveedor.
3. Calienta el tráfico gradualmente cuando los proveedores usen controles de aceleración.
4. Registra tokens e intentos por tarea completada.
5. Reporta tanto la tasa de éxito en el primer intento como la tasa de éxito eventual.
6. Compara el costo por tarea aceptada, no solo el costo por token.
7. Ejecuta las pruebas de sobrecarga por separado de los benchmarks de calidad y latencia.

Si está evaluando proveedores tanto por fiabilidad como por coste, combine este proceso con la comparación de precios de API de IA.

Una arquitectura de límites de tasa para producción

Un recorrido de solicitudes robusto suele tener cinco capas de control:

1. Control de admisión rechaza o aplaza el trabajo que no puede cumplir su plazo.
2. Reserva de tokens estima el coste de cuota probable de la solicitud.
3. Limitador de tasa regula cada proveedor, grupo de modelos, inquilino y clase de prioridad.
4. Controlador de reintentos gasta un presupuesto de reintentos limitado con jitter.
5. Enrutador selecciona una alternativa compatible con el contrato después de que el presupuesto de reintentos o la política de capacidad indiquen que hay que cambiar.

cliente
  → control de admisión
  → cola de prioridad
  → limitador de RPM + reserva de tokens
  → ruta de proveedor/modelo
  → reintento limitado
  → fallback seguro para el contrato
  → registros de uso y latencia

No coloque un bucle de reintentos ilimitado en cada worker de la aplicación. Centralice la política para que todos los llamadores compartan la misma comprensión de la capacidad disponible.

Métricas sobre las que vale la pena alertar

Haga seguimiento de estas por proveedor, modelo, proyecto, ruta, inquilino y carga de trabajo:

• Solicitudes por minuto y tokens por minuto.
• Tokens estimados reservados frente a tokens reales utilizados.
• Tasa de éxito en el primer intento.
• Intentos de reintento por solicitud exitosa.
• Tasa de 429 por causa clasificada.
• Profundidad de la cola y antigüedad del elemento más antiguo.
• Tiempo invertido esperando capacidad de tasa.
• Latencia de extremo a extremo p50, p95 y p99.
• Tasa de fallback y resultado del fallback.
• Coste por tarea exitosa o aceptada.

Una alerta solo sobre el recuento total de 429 es ruidosa. Una mejor señal combina la tasa de limitación con la antigüedad de la cola, la amplificación de reintentos y la tasa final de fallos.

Errores comunes

Tratar RPM como un límite de concurrencia

RPM mide admisiones a lo largo del tiempo; la concurrencia mide el trabajo en curso. Las solicitudes lentas pueden crear una alta concurrencia con un RPM modesto.

Reintentar inmediatamente cada 429

Los reintentos inmediatos sincronizan los workers y consumen más capacidad. Respete el tiempo del servidor cuando esté disponible y añada jitter.

Usar un único limitador para cada modelo

Los proveedores pueden usar grupos separados o compartidos. La política específica del modelo debe seguir el alcance de cuota documentado por el proveedor y los encabezados observados.

Ignorar a los consumidores compartidos

Un panel, un trabajo por lotes y una API de producción pueden compartir una sola cuota de proyecto. Reserve capacidad por carga de trabajo e aisle el tráfico crítico cuando sea posible.

Reintentar un flujo parcial

Una vez que los tokens han llegado al usuario, reproducir la solicitud puede duplicar contenido o acciones de herramientas. Defina una semántica explícita de continuación o reinicio en lugar de reintentar silenciosamente.

Cómo Flatkey cambia el modelo operativo

Flatkey proporciona una clave de API y una URL base compatible con OpenAI para acceder a través de los proveedores de modelos compatibles. Eso ofrece a una aplicación una única superficie de integración, al tiempo que permite que la política de enrutamiento considere la adecuación del modelo, la capacidad, la fiabilidad y el coste.

La puerta de enlace no elimina los límites del proveedor. Facilita implementar controles consistentes alrededor de ellos: una sola integración de cliente, registros de solicitudes centralizados y la opción de mover el tráfico elegible cuando una ruta está restringida. Revisa la guía de arquitectura de una puerta de enlace de API de IA para conocer el diseño de enrutamiento más amplio, o consulta los precios actuales de Flatkey antes de seleccionar rutas de producción.

Preguntas frecuentes

¿Cuál es la diferencia entre RPM y TPM?

RPM limita cuántas solicitudes se admiten con el tiempo. TPM limita cuántos tokens de entrada y/o salida se admiten. Los prompts pequeños suelen presionar primero RPM; las cargas de trabajo con mucho contexto o alta salida suelen presionar primero TPM.

¿Por qué obtengo errores 429 por debajo de mi límite de RPM?

El proveedor puede aplicar ventanas móviles más cortas, buckets de tokens, cuotas de proyecto compartidas, límites de tokens separados, límites de aceleración o grupos específicos por modelo. Tu contador local de solicitudes puede no representar el alcance total de la cuota.

¿Debería reintentar cada 429?

No. Reintenta el estrangulamiento de corta duración con un presupuesto pequeño y jitter. No reintentes repetidamente la agotación de la cuota diaria, las restricciones de facturación ni una sobrecarga sostenida que no tenga tiempo para recuperarse.

¿El backoff exponencial garantiza el éxito?

No. El backoff reduce las colisiones y da tiempo para que se recupere la capacidad transitoria. No puede crear cuota. El agotamiento persistente requiere menor demanda, más capacidad, trabajo diferido u otra ruta elegible.

¿Cuántos reintentos debe usar una solicitud LLM?

No existe un número universal. Define los intentos según el presupuesto de latencia visible para el usuario y el modo de fallo. Muchas aplicaciones interactivas deberían permitir solo unos pocos intentos cortos antes de fallar o redirigir a otra parte; los trabajos sin conexión pueden tolerar colas más largas.

¿Los reintentos cuentan contra los límites de tasa?

Pueden hacerlo. Los proveedores pueden contar los intentos fallidos dentro de los límites activos, por lo que la amplificación de reintentos debe supervisarse y acotarse.

Lista de verificación final

• Modela por separado RPM, TPM, los límites diarios y la concurrencia.
• Calcula la capacidad a partir del mínimo entre los topes de solicitudes y de tokens.
• Opera por debajo del máximo publicado con un factor de seguridad.
• Usa colas y ritmo controlado para cargas sostenidas.
• Respeta Retry-After y usa backoff exponencial con jitter.
• Limita los intentos y el tiempo total de reintento.
• No repitas automáticamente streams parciales ni efectos secundarios.
• Redirige solo a modelos que preserven el contrato requerido.
• Separa el retraso de cola y reintento de la latencia del modelo en las evaluaciones.
• Genera alertas por amplificación de reintentos y antigüedad de la cola, no solo por los recuentos brutos de 429.

Los límites de tasa son, antes que nada, un problema de planificación de capacidad y luego un problema de reintentos. Una vez que mides por separado la frecuencia de solicitudes, el rendimiento de tokens, la concurrencia y la amplificación de reintentos, los errores 429 se convierten en señales accionables en lugar de ruido impredecible en producción.