Límites de velocidad de LLM 2026: RPM, TPM y límites de concurrencia en todos los proveedores

Solicitudes por minuto (RPM) limita cuántas llamadas API puedes hacer en una ventana de 60 segundos. El límite se reinicia sobre una base móvil — el comportamiento de ráfaga está permitido dentro de la ventana, pero las RPM sostenidas altas desencadenan 429s. La mayoría de cargas de trabajo de producción alcanzan primero los límites RPM.

Tokens por minuto (TPM) limita el total de tokens (entrada + salida, en la mayoría de proveedores; algunos cuentan solo entrada) que fluyen a través de tu cuenta por minuto. Las llamadas de contexto largo consumen el presupuesto TPM rápidamente: una única llamada de 200k-entrada en un límite de 200k TPM deja cero presupuesto para otras solicitudes en ese minuto.

Los límites de solicitudes concurrentes limitan cuántas solicitudes pueden estar en vuelo simultáneamente. OpenAI no publica un límite de concurrencia duro en los niveles estándar (limitado indirectamente por TPM/RPM). Together AI publica 200-500 concurrentes en el nivel estándar. Alcanzar límites de concurrencia se muestra como una ruta de error diferente a RPM/TPM — típicamente un 503 en lugar de un 429.

Los tres límites se reinician por modelo. gpt-5.5 y gpt-5.4-mini tienen cuotas independientes; ejecutar gpt-5.5 en el límite no afecta tu margen de maniobra de gpt-5.4-mini. Esto es útil para patrones de respaldo — consulta la sección de resiliencia a continuación.

Carga de trabajo de referencia: un chatbot de soporte al cliente que promedian 1.500 tokens de entrada + 500 de salida por llamada.

En OpenAI Nivel 2 (gpt-5.5: 5.000 RPM / 450.000 TPM): RPM de 5.000 es la restricción vinculante a esta forma de token, ya que 5.000 llamadas × 2.000 tokens = 10M tokens/min — muy por encima de TPM. Así el límite es 5.000 llamadas/min = 83 llamadas/segundo. Un estallido de 100 usuarios concurrentes enviando un mensaje cada uno, con el modelo tomando ~5 segundos para responder, se sitúa cómodamente bajo el límite.

Misma carga de trabajo en Anthropic Nivel 2 (Claude Sonnet 4.6: 1.000 RPM / 80.000 TPM entrada / 16.000 TPM salida): 1.000 RPM ÷ 60 = 17 RPS. Pero TPM de entrada es la restricción real aquí — 1.000 llamadas × 1.500 tokens de entrada = 1.5M tokens de entrada, muy por encima de 80k TPM. El límite real es 80.000 / 1.500 = 53 llamadas/min en entrada — mucho más restrictivo que los 1.000 RPM del titular. Necesitas actualizar al Nivel 3 o mover el chatbot a un modelo de nivel superior con límites más relajados.

En Google Gemini Nivel de pago 1 (Gemini 2.5 Pro: 1.000 RPM / 2.000.000 TPM): 2M TPM / 2k tokens por llamada = 1.000 llamadas/min — exactamente coincidiendo RPM. El Nivel 1 sustenta aproximadamente 17 llamadas/segundo; suficiente para una aplicación pequeña a mediana.

Planifica la restricción vinculante, no el número del titular. TPM frecuentemente limita antes que RPM en cargas de trabajo de contexto largo.

Carga de trabajo de referencia: un enriquecimiento de una sola pasada de 1M de registros, cada uno requiere una llamada de clasificación de 500-token-entrada / 100-token-salida.

Síncrono en OpenAI Nivel 4 (10.000 RPM / 2.000.000 TPM): 10k RPM ÷ 60 = 167 RPS. 1M llamadas / 167 RPS = ~100 minutos de ráfaga sostenida — u 1 hora 40 minutos si puedes correr sin restricciones. TPM a 600 tokens × 10k llamadas = 6M, muy por encima del límite de 2M TPM, así TPM es la restricción. Rendimiento real: 2M TPM / 600 tokens = 3.333 llamadas/min, así 1M llamadas / 3.333 = 300 minutos = 5 horas.

Mismo trabajo en la API de Lote: envía 1M llamadas en un archivo JSONL, obtén resultados en hasta 24 horas, al 50% de descuento tanto entrada como salida. Sin preocupación RPM o TPM — la cola de lote maneja la limitación internamente. El costo baja de $0.005 × 1M = $5.000 (gpt-5.4-mini estándar) a $2.500.

Para pasadas de enriquecimiento de una sola vez, lote es casi siempre la respuesta correcta — mismo ahorro de costo que una actualización de nivel síncrono, ops más simples, sin ingeniería de límite de velocidad. Para ingesta continua, síncrono en un nivel superior es generalmente lo correcto.

OpenAI promociona automáticamente entre niveles según el gasto acumulado y la antigüedad de la cuenta. Nivel 1 → 2 a $50 en 7+ días, Nivel 2 → 3 a $100 en 7+ días, Nivel 3 → 4 a $250 en 14+ días, Nivel 4 → 5 a $1.000 en 30+ días. La progresión es automática; no se necesita ticket de soporte.

Anthropic utiliza depósitos en lugar de gasto. Nivel 1 → 2 a depósito de $40 en 7+ días, Nivel 2 → 3 a $200 en 14+ días, Nivel 3 → 4 a $400 en 30+ días. Para límites más altos, contacta con ventas para un plan personalizado.

Google Gemini utiliza gasto acumulado en el nivel de pago. El nivel gratuito está severamente limitado (10 RPM en Flash, 5 en Pro). El Nivel de pago 1 se habilita al configurar la facturación. Nivel de pago 2 a $250 acumulado en 30+ días. El Nivel 3 requiere contactar con ventas o cambiar a Vertex AI.

La implicación práctica: una implementación de producción debe estar en Nivel 3+ dentro del primer mes. Si lanzas en Nivel 1 o 2 y el tráfico se dispara, alcanzarás límites y 429s antes de que la promoción automática de nivel se active. La forma más rápida de saltarse la espera es depositar el monto completo por adelantado — la mayoría de proveedores honran el nivel superior dentro de horas de la detección.

Todos los proveedores principales devuelven HTTP 429 (Demasiadas solicitudes) cuando se excede un límite RPM, TPM o de concurrencia. La respuesta incluye Retry-After en segundos, que es el retardo sugerido antes de reintentar. Honrar Retry-After es la diferencia entre una degradación elegante y un abarrotamiento de cola en cascada.

Patrón de reintento malo: reintento inmediato sin retardo. Causa que la misma llamada falle repetidamente y amplifica la carga en el sistema de límite de velocidad del proveedor. A menudo desencadena una prohibición temporal de IP en tormentas de reintento agresivas.

Patrón de reintento bueno: retroceso exponencial con jitter. Comienza con el valor Retry-After (u 1 segundo si falta), duplica en cada reintento hasta un máximo (típicamente 60 segundos), añade 0-25% de jitter aleatorio para evitar una manada en estampida. La mayoría de clientes HTTP de producción (el SDK de OpenAI, SDK de Anthropic, SDK de google-generativeai) implementan esto de forma predeterminada; verifica que esté habilitado.

Mejor patrón: conciencia de límite de velocidad en el nivel de cola. Si tienes 10.000 llamadas para hacer y un límite de 5.000 RPM, distribúyelas en 2+ minutos de forma proactiva en lugar de disparar los 10k y dejar que la mitad 429. Usa un limitador de velocidad de cubo con fugas o cubo de tokens en tu capa de cliente API.

Mejor patrón a escala: una cadena de respaldo de multi-nivel. Modelo primario en su propia cuota, modelo secundario (más barato) en su propia cuota para desbordamiento, cola de lote para tráfico no urgente. Cuando principal 429, retrocede a secundario; cuando secundario 429, cae a lote.

Patrón 1: respaldo de modelo. Cada modelo tiene cuotas independientes. Cuando RPM de gpt-5.5 limita, reintenta en gpt-5.4. Cuando Claude Sonnet 4.6 limita, reintenta en Claude Haiku 4.5. La calidad baja ligeramente pero la disponibilidad se mantiene al 100%. Implementa con un enrutador simple de reintento-en-429 en tu cliente.

Patrón 2: respaldo de proveedor. Redundancia entre proveedores con AI Gateway o Portkey o enrutamiento personalizado. Primario en OpenAI, secundario en Anthropic, terciario en Gemini. Cuando un proveedor tiene una interrupción o límites de velocidad, enruta al siguiente. Añade complejidad de evaluación (las respuestas de cada proveedor difieren ligeramente) pero elimina riesgo de proveedor único.

Patrón 3: limitación en el lado del cliente. Usa un limitador de velocidad de cubo con fugas (ej: aiolimiter en Python, bottleneck en Node) dimensionado al 80% del límite de tu nivel. Previene ráfagas en 429s desde el principio.

Patrón 4: aceleración de nivel de gasto. Si estás a 6 días de una promoción de nivel que resolvería tu problema de velocidad, pre-deposita o haz que una ejecución de llamada API única dispare el umbral de promoción más rápido.

Patrón 5: lote donde sea posible. Cualquier cosa no cara a cara con el usuario debe estar en la API de Lote. Tanto los puntos finales de Lote de OpenAI como de Anthropic tienen grupos de cuota separados que no afectan tus límites sincrónicos.

Para el lado de costos de estos patrones, consulta GPT vs Claude vs Gemini calculadora de costos, que compara cadenas de respaldo de extremo a extremo.

Método 1: gasta a través del umbral. El camino más barato: ejecuta tráfico real para alcanzar el criterio de gasto acumulado. Quema el monto de dólar requerido a través de carga de trabajo legítima durante los días requeridos. La mayoría de equipos se sientan en el siguiente nivel dentro de 30-60 días de lanzamiento.

Método 2: pre-deposita. Algunos proveedores (Anthropic) aceptan pre-depósitos que cuentan hacia criterios de nivel inmediatamente, acelerando la promoción sin esperar a que el uso se acumule.

Método 3: contacta con ventas. El camino más rápido para volumen empresarial. OpenAI, Anthropic, Google, Mistral y Together todos tienen equipos de ventas que pueden autorizar límites de nivel más alto personalizados con una discusión del volumen esperado, caso de uso y compromiso de plazo. Tiempo de entrega: típicamente días a semanas.

Método 4: puntos finales dedicados. Together AI, Anthropic (vía Bedrock) y Google (vía Vertex AI) todos ofrecen puntos finales de capacidad reservada donde los límites de velocidad efectivamente desaparecen a cambio de pagos de capacidad mensual comprometida. Útil en volumen alto sostenido con formas de carga predecibles.

Método 5: distribución entre cuentas. Algunos equipos fragmentan tráfico de producción entre múltiples cuentas (típicamente por entorno o característica). Cada cuenta obtiene su propia cuota. Sé cauteloso — los términos de servicio de los proveedores usualmente prohíben usar múltiples cuentas para evadir límites; los casos de uso legítimos (aplicaciones genuinamente separadas o entornos) están bien.

El margen de límite de velocidad no es un número único — es un número por región por proveedor. Todos los principales proveedores de LLM exponen sus modelos insignia a través de más de un punto final, y cada punto final aplica su propia cuota RPM y TPM independiente. Un equipo que corre contra solo el punto final predeterminado deja 2x a 3x de capacidad usable en la mesa, a menudo sin darse cuenta. El patrón multi-región trata cada punto final regional como un cubo de cuota paralelo y enruta tráfico entre ellos con una política de respaldo.

Anthropic es el más flexible aquí. Claude está disponible en la API de Anthropic directa, en AWS Bedrock en us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1, ap-northeast-1 y varias regiones más nuevas, y en Google Cloud Vertex AI en us-east5, europe-west1 y asia-southeast1. Cada uno de esos puntos finales tiene una cuota separada. Una carga de trabajo que alcanza el límite de Tier 3 de 2.000 RPM de la API directa puede enrutar desbordamiento a Bedrock us-east-1 (cuota separada por cuenta negociada contra AWS) y Vertex AI us-east5 (negociada contra GCP). El mismo modelo Claude Sonnet 4.6 subyacente sirve los tres con el mismo esquema de solicitud, así el riesgo de diferencia de evaluación que existe en respaldo entre proveedores es efectivamente cero.

OpenAI es más limitado en la API directa — presenta un único punto final global con una cuota única — pero Azure OpenAI Service replica GPT-5.x en implementaciones regionales (East US, East US 2, West US, West US 3, North Central US, South Central US, North Europe, West Europe, Sweden Central, France Central, UK South, Japan East, Australia East y otros). Cada región de Azure tiene su propia cuota RPM y TPM asignada en la creación de la implementación. Un equipo bloqueado en el límite de 10.000 RPM del Nivel 4 de OpenAI puede implementar GPT-5.5 en tres regiones de Azure a 3.000 RPM cada una y enrutar entre ellas, añadiendo instantáneamente 9.000 RPM de capacidad de canal lateral sin esperar a la promoción automática de nivel.

Google Gemini sigue el mismo patrón a través de Vertex AI. La API de AI Studio tiene una cuota compartida única; Vertex AI publica puntos finales regionales (us-central1, us-east1, us-east4, us-west1, europe-west1, europe-west4, asia-southeast1, asia-northeast1 y más), cada uno con cuotas independientes configurables por proyecto. Las cuotas de Vertex AI también tienden a ser más altas que el nivel de pago de AI Studio en el mismo nivel de gasto, así la migración es doblemente valiosa para cargas de trabajo de alto volumen.

Las matemáticas en una configuración de tres regiones raramente producen un 3x perfecto. Equilibrio de carga imperfecto — formas de tráfico desiguales, tormentas de reintento concentrándose en el primario, clientes fijados a región en cargas de trabajo reguladas — típicamente entrega un multiplicador efectivo de 2.6x a 2.8x en la mayoría de cargas de trabajo realistas de chatbot e ingesta. Usa 2.7x como regla de pulgar de planificación. Un ejemplo práctico: un chatbot en un límite de 30.000 TPM por región, implementado primario en us-east-1, secundario en eu-west-1, terciario en ap-southeast-1, sustenta aproximadamente 80.000 TPM agregado antes de que cualquier región 429. Eso es equivalente a una actualización de nivel completa, conseguible en horas en lugar de los 14 a 30 días que requeriría una promoción basada en gasto, y sin compromiso de depósito mínimo.

El monitoreo es la parte en la que los equipos subevalúan. Cada región necesita su propio panel de margen de maniobra, su propia alerta de velocidad de 429, y su propio presupuesto de reintento rastreado por separado — agregar entre regiones oculta la región que está realmente saturada. Etiqueta cada solicitud con su región objetivo en la capa del cliente, registra los encabezados de límite de velocidad regional (Azure devuelve x-ratelimit-remaining-requests por implementación; Bedrock devuelve encabezados x-amzn-bedrock-quota-*; Vertex devuelve encabezados de cuota estándar de Google) en tu pila de observabilidad, y grafica cada región como una serie separada. El enrutador de respaldo debe seleccionar la región con el margen de maniobra más alto restante en lugar de un primario fijo, lo que suaviza la utilización y empuja el multiplicador efectivo más cerca del 3x teórico. Para implementaciones en AI Gateway de Vercel, la lógica de enrutamiento regional puede sentarse en una capa de middleware delgada enfrente de la puerta de enlace y pasar a través del punto final elegido.

La mayoría de proveedores devuelven encabezados de límite de velocidad en cada respuesta exitosa. OpenAI: x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens. Anthropic: anthropic-ratelimit-requests-remaining, anthropic-ratelimit-tokens-remaining. Google: x-goog-api-client (menos detallado; consulta la API para estado de cuota).

Registra estos encabezados por solicitud y construye un panel de control mostrando margen de maniobra rodante de 1 minuto y 5 minutos en RPM y TPM. Cuando el margen de maniobra regularmente cae por debajo del 20% en base sostenida, el nivel es tu tope de producción real; planifica una promoción antes de que el tráfico lo sobrepase.

Alerta sobre tres señales: velocidad de 429 por encima de 0.1% del tráfico total, margen de maniobra sostenido sub-20% durante >5 minutos y cualesquiera errores de 503 (concurrencia). Cada señal indica una remediación diferente: 429 = aumenta de nivel o suaviza ráfagas; margen de maniobra sostenido bajo = actualización de nivel requerida; 503 = baja concurrencia en tu cliente o actualiza a dedicado.

El monitoreo de costos debe alinearse: si tu panel de control de límite de velocidad muestra que regularmente golpeas el límite de TPM, estás en un nivel donde el costo marginal de actualizar es mucho menor que el costo de solicitudes caídas o retrasadas. Para comparación de costos de proveedor a escala, consulta Precios de API de OpenAI y Precios de Anthropic Claude.