Límites de LLM API: 13 proveedores y 2 SDK sin reintentos 429
Contenido
De las trece LLM API analizadas aquí (diez proveedores más Bedrock, Vertex AI y Azure OpenAI), cuatro informan del presupuesto restante en cada respuesta, Mistral envía un único contador restante y ocho no dicen nada hasta que la solicitud falla. Un “429” puede describir cuatro situaciones distintas: un throttle que conviene reintentar, un límite de aceleración que obliga a reducir el ritmo, una cuota o límite de gasto que no debe reintentarse, y una sobrecarga que cada proveedor comunica como 429, 503 o 529. Además, el cliente influye más que el proveedor: los SDK de OpenAI, Anthropic y Groq reintentan dos veces un 429 y desisten si Retry-After supera 60 o 120 segundos, mientras que los SDK de Google GenAI y Mistral llevan los reintentos desactivados. Esta referencia compara proveedores a partir del código fuente de sus SDK oficiales: dimensiones, tokens contabilizados, headers, semántica de los 429 y comportamiento de cada SDK.
TL;DR
- Las LLM API aplican límites por solicitudes y tokens por minuto; Anthropic separa entrada y salida, mientras que DeepSeek solo limita la concurrencia.
- OpenAI, Azure y Bedrock descuentan
max_tokenspor adelantado; Anthropic excluye las lecturas de caché; xAI cuenta el razonamiento; Bedrock consume 10 tokens de cuota por cada token de salida de Claude 5. - OpenAI, Anthropic, Groq y Azure devuelven headers con el saldo restante y el tiempo de reset en cada 200; ocho API no documentan ninguno.
- Los SDK de google-genai y Mistral no reintentan un 429 por defecto; los de OpenAI, Anthropic y Groq lo reintentan dos veces y limitan Retry-After a 60 o 120 segundos.
¿Qué significan RPM, TPM y los demás límites?
Todos fijan cuánto se puede enviar dentro de una ventana. Cada proveedor elige qué métricas aplica:
| Grupo | Términos | Qué significan y quién los utiliza |
|---|---|---|
| Métricas de solicitudes | RPM, RPD, RPS, concurrencia | Solicitudes por minuto o por día, una por llamada sin importar su tamaño. RPS suele ser RPM dividido entre 60 y se aplica como protección contra ráfagas (xAI, Alibaba, Mistral, Azure). La concurrencia mide las solicitudes en curso, no las enviadas por ventana, y es el único límite de DeepSeek |
| Métricas de tokens | TPM, TPD, ITPM, OTPM, burndown rate | Tokens por minuto o por día. Algunos proveedores separan entrada (ITPM) y salida (OTPM). Un burndown rate multiplica los tokens de salida antes de cargarlos a la cuota (Bedrock). Cada proveedor decide qué tokens cuentan, como se explica a continuación |
| Métricas para otras unidades | IPM, segundos de audio, páginas de OCR | Imágenes por minuto en modelos de imagen (OpenAI, Gemini), segundos de audio por hora o día (Groq, Mistral), y páginas por minuto para OCR de documentos (Mistral) |
| Cómo se aplica la ventana | Token bucket, límite de aceleración | Un token bucket se rellena de forma continua en lugar de reiniciarse cada minuto. Por eso, una ráfaga puede agotarlo aunque el total por minuto no supere el límite (Anthropic; Alibaba y Azure describen el mismo efecto). Un límite de aceleración comprueba por separado a qué velocidad crece el uso. Puede activarse ante un aumento repentino aunque el consumo siga por debajo del límite (Anthropic, slow_down de OpenAI) |
| Qué determina los valores | Tier, límite de gasto o cuota, capacidad aprovisionada | Un tier es el nivel que fija las métricas anteriores. Sube con el uso de pago o el historial, no al recargar saldo. Un límite de gasto o una cuota diaria restringe el dinero o el volumen, no la velocidad, así que esperar un minuto no sirve. La capacidad aprovisionada es throughput reservado que se factura por unidad y hora (Bedrock y Vertex AI Provisioned Throughput, Azure PTU). En este caso, un 429 indica que la reserva está llena, no que se haya agotado una cuota |
El valor publicado marca el máximo de la ventana, no una cantidad garantizada. Anthropic indica que 60 RPM “podrían aplicarse como 1 solicitud por segundo”. Azure advierte que “una ráfaga dentro de una ventana de 1 o 10 segundos puede provocar un 429 aunque el total por minuto esté dentro de los límites”.
¿Qué limitan las LLM API?
Casi todas limitan solicitudes y tokens por minuto. Los tres clouds no se limitan a replicar las reglas de sus proveedores. Las definiciones siguientes son las de cada proveedor según las páginas enlazadas, consultadas el 2026-09-03 y el 2026-09-04.
| Proveedor | Dimensiones | Cómo aumentan los límites | Fuente |
|---|---|---|---|
| OpenAI | RPM, RPD, TPM, TPD, IPM, minutos de audio por minuto; cola de Batch API medida por tokens de entrada en espera | Tiers 1 a 5 según pagos acumulados | límites de uso |
| Anthropic | RPM, ITPM y OTPM por clase de modelo; token bucket; límites de aceleración | Tiers Start, Build y Scale según historial de uso | límites de uso |
| Google Gemini | RPM, TPM (entrada), RPD; IPM en modelos de imagen | Gratuito, seguido de Tiers 1 a 3 con límites de gasto por 10 minutos | límites de uso |
| xAI | RPS (RPM / 60) y TPM por modelo | Tiers 0 a 4 más Enterprise | límites de uso |
| Alibaba Model Studio | RPM y TPM por modelo, con RPS = RPM / 60 y TPS = TPM / 60 como protección contra ráfagas | Por modelo; el procesamiento batch está exento en algunos modelos | límites de uso |
| DeepSeek | Solo concurrencia: 500 conexiones en V4 Pro y 2,500 en V4 Flash | Fijo por modelo | límite de uso |
| Mistral | RPS, tokens por minuto y tokens por mes, por modelo y workspace | Tiers 1 a 4 según facturación acumulada; “Añadir créditos no aumenta los límites de uso” | uso y límites, centro de ayuda |
| MiniMax | RPM y TPM por modelo; MiniMax M3 tiene 200 RPM y 10M TPM | Contactar con ventas | límites de uso |
| Moonshot Kimi | Concurrencia, RPM, TPM, TPD; el Tier 0 admite 1 solicitud concurrente y 3 RPM, y el Tier 5, 100 y 300 | Seis tiers según recargas acumuladas, de $1 a $3,000 | límites |
| Groq | RPM, RPD, TPM, TPD, ITPM, OTPM, segundos de audio por hora y día | Por modelo | límites de uso |
| Amazon Bedrock | RPM, TPM y TPD por modelo y región; TPD tiene por defecto el valor TPM x 1,440 | Service Quotas, ampliables bajo solicitud; las cuentas nuevas empiezan con límites reducidos | cuotas |
| Google Vertex AI | Sin valor por proyecto en pago por uso: un pool compartido donde “el gasto histórico de la organización determina el Usage Tier y el throughput base (TPM)”, con ráfagas best effort | Usage tier según gasto; Provisioned Throughput “aísla del pool compartido de PayGo” | blog de Google Cloud |
| Azure OpenAI | TPM asignados por deployment, con RPM derivados (6 RPM por 1,000 TPM en modelos antiguos y 1 RPM por 1,000 TPM en los actuales); los deployments PTU están limitados por utilización | Tiers de cuota 0 a 6, con actualización automática | cuotas y límites, gestión de cuotas |
Dos filas no usan ventanas por minuto. DeepSeek limita las conexiones abiertas y, cuando hay carga, mantiene abierta la solicitud con líneas vacías (o comentarios : keep-alive en streaming) durante un máximo de 10 minutos en vez de rechazarla. Vertex AI no publica una cuota para el pago por uso: un 429 significa que el pool compartido no tenía capacidad en ese momento.
¿Qué tokens cuentan para el límite?
No siempre son los mismos tokens que se facturan. La diferencia puede hacer que la capacidad real sea una fracción o un múltiplo del valor publicado:
| Proveedor | Qué cuenta para el límite de tokens | Consecuencia |
|---|---|---|
| OpenAI | El mayor valor entre max_tokens y una estimación basada en el prompt, descontado al recibir la solicitud: “Si configuras un valor de max_tokens demasiado alto, el uso puede sobreestimarse aunque la respuesta real sea mucho más corta” (cookbook) | Un max_tokens de 4,000 para una respuesta de 50 tokens consume 4,000 TPM |
| Azure OpenAI | Una estimación basada en “el texto y la cantidad del prompt, la configuración del parámetro max_tokens y la configuración del parámetro best_of”, calculada en parte por número de caracteres; en deployments PTU, “los tokens en caché reciben un descuento del 100%” (guía de cuotas) | “El límite de uso puede alcanzarse antes de lo esperado”; si no se define max_tokens, Azure lo estima |
| Amazon Bedrock | Al inicio descuenta “Total de tokens de entrada + max_tokens” y al final lo corrige a InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate). Las lecturas de caché están exentas. El burndown es 5x en Claude 4.7 y anteriores, 10x en Sonnet 5, Opus 5, Fable 5.1 y los modelos GPT-5.6, y 15x en Claude 4.8 (cómputo de tokens) | En el ejemplo documentado, 1,000 tokens de entrada y 100 de salida en un modelo 5x consumen 1,500 tokens de cuota y facturan 1,100 |
| Anthropic | ITPM cuenta input_tokens y cache_creation_input_tokens; cache_read_input_tokens “NO cuenta para ITPM”. OTPM cuenta la salida real; “max_tokens no interviene en OTPM” (documentación) | En el ejemplo documentado, 2M ITPM con un 80% de aciertos de caché admiten 10M tokens de entrada por minuto |
| xAI | ”Todos los tokens consumidos por una solicitud cuentan para el límite TPM: tokens del prompt (texto, imagen y audio), tokens de completion, tokens de razonamiento (en modelos de razonamiento) y tokens del prompt en caché” | El razonamiento consume TPM con tokens que nunca se ven; la caché no aumenta el throughput |
| Google Gemini | Tokens de entrada | La longitud de la salida no consume el límite |
| Alibaba, Mistral, MiniMax | Entrada más salida | |
| Kimi, Groq, DeepSeek, Vertex AI | No se especifica | Groq mide ITPM y OTPM por separado; DeepSeek no tiene límite de tokens; Vertex AI solo publica un baseline por usage tier |
Una misma solicitud tiene un tamaño distinto para cada límite, entre 800 y 6,000 tokens en el ejemplo anterior. Por eso, un router que distribuye una carga entre varios proveedores necesita un medidor por proveedor.
¿Qué headers devuelve cada proveedor?
Cuatro API incluyen el estado de los límites en cada respuesta, Mistral envía un campo y las otras ocho obligan a llevar la cuenta.
| Proveedor | Headers en una respuesta normal | Notas sobre el formato |
|---|---|---|
| OpenAI | x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens, más el trío -project-tokens | Reset indica “el tiempo restante hasta que se restablece el límite”; Retry-After aparece en los 429 |
| Azure OpenAI | Los mismos seis nombres x-ratelimit-* en cada llamada; retry-after-ms y retry-after en los 429 | Si x-ratelimit-limit-tokens está por debajo de los TPM configurados, hay un “ajuste temporal del límite de uso” activo |
| Anthropic | anthropic-ratelimit-requests-{limit,remaining,reset}, el mismo trío para tokens, input-tokens y output-tokens, más anthropic-priority-* y anthropic-fast-* cuando corresponden esos tiers | Reset en RFC 3339; el saldo restante se redondea al millar más cercano; el trío tokens-* muestra “el límite más restrictivo activo en ese momento” |
| Groq | x-ratelimit-limit-requests (diario), x-ratelimit-limit-tokens (por minuto), x-ratelimit-remaining-*, x-ratelimit-reset-*; “siempre incluidos” | Reset como duración, "2m59.56s", "7.66s"; retry-after en segundos y solo en los 429 |
| Mistral | X-RateLimit-Remaining | |
| Gemini, xAI, Alibaba, DeepSeek, MiniMax, Kimi, Bedrock, Vertex AI | Ninguno documentado | Gemini, Alibaba y Bedrock indican la causa en el cuerpo del error; Kimi documenta Retry-After para sobrecarga; los SDK de AWS leen x-amz-retry-after en milisegundos cuando un servicio lo envía |
El problema práctico es que un mismo campo usa tres formatos: la duración de OpenAI, el timestamp de Anthropic y el valor 2m59.56s de Groq requieren tres parsers. Esta es una de las razones por las que los SDK solo leen retry-after. El 2026-09-03 se midieron dos intermediarios con una solicitud cada uno. Un gran agregador multiproveedor no devolvió ningún header de límites en un 200 y los reservó para respuestas 429; el gateway de Synthorai devolvió x-ratelimit-remaining-requests y x-ratelimit-reset-requests junto con el coste de la solicitud.
¿Qué significa un 429 y cuándo debe reintentarse?
Depende de cuál de estas cuatro situaciones lo haya provocado. Solo dos justifican un reintento:
| Significado | ¿Reintentar? | Cómo lo expresa cada proveedor |
|---|---|---|
| Throttle: se ha superado un límite | Sí, después de Retry-After o con backoff | OpenAI y Anthropic usan 429 rate_limit_error, Anthropic con retry-after; Gemini y Vertex AI usan 429 RESOURCE_EXHAUSTED, que en Vertex AI indica falta de capacidad en el pool compartido; Kimi usa rate_limit_reached_error; Bedrock, ThrottlingException, más ModelNotReadyException, que el SDK reintenta hasta 5 veces; Azure, “Rate limit is exceeded”; xAI, RateLimitError; Alibaba, “Requests rate limit exceeded”; DeepSeek y Mistral, 429 |
| Aceleración: el ritmo ha aumentado demasiado rápido | Reducir el ritmo y reintentar | OpenAI usa slow_down; Anthropic, “acceleration limits”; Alibaba, “Request rate increased too quickly”; Azure, una ráfaga dentro de una ventana de 1 o 10 segundos |
| Cuota o límite de gasto: esperar no libera capacidad | No; hay que corregir la facturación o esperar a la fecha de reset | OpenAI usa insufficient_quota, credit_balance_exhausted, organization_spend_limit_exceeded; Anthropic, enforced_spend_limit_reached sin retry-after, mientras que un límite de gasto propio genera un 400; Gemini, quota_exceeded (diario); Kimi, exceeded_current_quota_error; Bedrock, 400 ServiceQuotaExceededException; el agregador y DeepSeek, 402. En Azure, la cuota se asigna al crear el deployment, por lo que agotarla no genera un 429 |
| Sobrecarga: falta capacidad del proveedor, no del cliente | Sí, con backoff | OpenAI usa 503 server_is_overloaded; Anthropic, 529 overloaded_error; Gemini, 503 UNAVAILABLE; Kimi, 429 engine_overloaded_error con Retry-After; Bedrock, 503 ServiceUnavailableException y 529 overloaded_error; Azure, “System is experiencing high demand”, un “ajuste temporal del límite de uso” del pool compartido o un PTU al 100% de utilización con retry-after-ms; DeepSeek, 503 |
La trampa está en la tercera fila. El 429 por límite de gasto de Anthropic tiene el mismo tipo rate_limit_error que un throttle, y la documentación indica que “Los reintentos, incluidos los automáticos de los SDK, fallan hasta que se restablece el acceso”. insufficient_quota de OpenAI también es un 429. Un cliente que solo evalúe el código HTTP reintentará ambos, igual que hacen todos los SDK oficiales, como muestra la siguiente sección. La decisión debe basarse en el código de error. Un 429 sin Retry-After puede indicar que esperar no servirá.
La cuarta fila muestra la diferencia entre los clouds. La guía de troubleshooting de Azure lo dice de forma directa: “Muchos clientes confunden los 429 relacionados con la capacidad con problemas de cuota y aplican soluciones incorrectas”. En Azure, un 429 con x-ratelimit-limit-tokens por debajo del límite configurado indica que el pool compartido se está protegiendo. En Vertex AI, todos los 429 de pago por uso significan eso. Bedrock comunica la misma situación con un 503 o 529, nunca con ThrottlingException. A través de un agregador aparece en el cuerpo: durante la medición de headers, un 429 llegó envuelto como provider_error_code: insufficient_quota, limit_source: upstream_provider_shared_pool. El estado indicaba throttle; el cuerpo indicaba la cuota de otro cliente.
¿Qué hace el SDK con un 429?
Depende del SDK, y dos de los más utilizados no hacen nada. Los datos proceden del código fuente de cada cliente oficial consultado el 2026-09-04, no de su documentación:
| SDK | Reintentos por defecto | Estados que reintenta | Backoff | Gestión de Retry-After |
|---|---|---|---|---|
| openai-python (también Azure OpenAI) | 2 | 408, 409, 429, 5xx o lo que indique x-should-retry | min(0.5 × 2^n, 8) s con jitter | Lee retry-after-ms y después retry-after como segundos o fecha; si supera 120 s, no reintenta |
| anthropic-sdk-python, groq-python | 2 | Los mismos | El mismo | Mismo parsing; si supera 60 s, ignora el header y aplica la fórmula de backoff |
| openai-node, anthropic-sdk-typescript | 2 | Los mismos | El mismo | Igual; si supera 60 s, usa el backoff por defecto |
| google-genai (Python, Gemini API y Vertex AI) | 0: retry_options tiene None por defecto, lo que se traduce en un único intento | Al activarlo: 408, 429, 500, 502, 503, 504 | Al activarlo: 5 intentos, empezando en 1 s y duplicando hasta 60 s, con jitter | No lee Retry-After |
| mistralai (Python) | 0: retry_config no viene definido por defecto | Al configurarlo: 429, 500, 502, 503, 504 | Al configurarlo: 500 ms × 1.5^n hasta 60 s, con 1 h total | Respeta cualquier Retry-After, tanto en segundos como en formato de fecha |
| boto3 (Bedrock) | Modo legacy: 5 intentos incluido el primero; modo standard: 3 | ThrottlingException y similares, 429, 5xx | Factor base 2, con un máximo de 20 s en modo standard. El comportamiento de 2026 (opt-in mediante AWS_NEW_RETRIES_2026=true) usa full jitter, una base de 1,000 ms para throttling y un retry token bucket | Sin Retry-After; el comportamiento de 2026 lee x-amz-retry-after en milisegundos, limitado al backoff más 5 s |
| xai-sdk (Python, gRPC) | 5 intentos, solo para UNAVAILABLE | RESOURCE_EXHAUSTED, el equivalente gRPC del 429, no se reintenta | 0.1 s duplicándose hasta 1 s | n/a |
| dashscope (Alibaba) | 0 ante estados HTTP; reenvía una vez si una conexión del pool se corta antes de recibir cualquier byte | |||
| DeepSeek, Kimi, MiniMax | No tienen SDK propio para chat; la documentación de DeepSeek indica que se use “el SDK de OpenAI/Anthropic” con otra URL base |
De aquí se desprenden tres conclusiones. Primero, un 429 de Gemini, Vertex AI o Mistral llega al código de la aplicación en el primer intento salvo que se hayan configurado los reintentos. El comentario del código fuente de google-genai que afirma que el cliente “reintentará 4 veces” describe la configuración activada, no el valor por defecto. Segundo, los topes de Retry-After chocan con las esperas largas que los proveedores solicitan en la práctica: si Anthropic pide esperar 90 segundos, su SDK ignora el header y vuelve en menos de 8; si OpenAI pide 150, su SDK deja de reintentar. Tercero, los SDK generados por Stainless (el generador de código usado por los clientes de OpenAI, Anthropic y Groq) obedecen un header x-should-retry no documentado antes de comprobar el código de estado, y leen retry-after-ms antes de retry-after. Por tanto, un proveedor o gateway puede dirigir los reintentos sin cambiar el código de estado.
Ninguno diferencia un 429 por límite de gasto de un throttle. Dos reintentos de una respuesta insufficient_quota solo desperdician unos segundos cada uno, pero una flota que lo haga a escala genera su propia ráfaga.
¿Cómo cambia el panorama un gateway?
Un gateway permite resolver todo esto en un único punto. Hacia upstream, lee los headers que envíe cada proveedor, de modo que los tres formatos de reset y los cuatro significados de un 429 dejan de ser responsabilidad de cada cliente. Hacia downstream, ofrece un único conjunto de headers y una única estructura de error, como muestran los headers de Synthorai medidos antes. Lo que un gateway no puede cambiar es la contabilidad del proveedor: detrás de OpenAI, el max_tokens del cliente sigue descontando TPM por adelantado; detrás de Bedrock, un token de salida de Claude sigue consumiendo diez. Además, si el gateway agrupa muchos clientes bajo una sola key del proveedor, alcanza el límite de aceleración antes que cualquier cliente individual. Para eso hacen falta buckets por key, no un contador compartido.
Preguntas frecuentes
¿Cuenta max_tokens para el límite de uso?
Sí en OpenAI, Azure OpenAI y Bedrock: max_tokens se descuenta al llegar la solicitud, así que un valor sobredimensionado desperdicia TPM aunque la respuesta sea corta. Bedrock corrige el descuento cuando termina la respuesta. En Anthropic no: OTPM cuenta los tokens generados realmente y max_tokens “no interviene”.
¿Cuentan los tokens en caché para el límite de uso?
No en Anthropic, Bedrock ni en deployments PTU de Azure, donde las lecturas de caché están excluidas. En xAI cuentan por completo. OpenAI y Gemini no lo especifican.
¿Siempre se envía Retry-After con un 429?
No. OpenAI, Azure (como retry-after-ms) y Groq lo envían en throttles; Anthropic lo envía en throttles, pero no al alcanzar el límite de gasto; Kimi y Bedrock solo lo envían en sobrecargas. Gemini, Vertex AI, xAI, Alibaba, DeepSeek y MiniMax no documentan ninguno, así que el cliente necesita su propia estrategia de backoff.
¿Por qué mi SDK no reintentó un 429?
En los SDK de Google GenAI o Mistral para Python, los reintentos están desactivados por defecto: hay que pasar retry_options o un RetryConfig. En el SDK de OpenAI para Python, si el servidor pidió esperar más de 120 segundos, el SDK no reintenta deliberadamente. Si el 429 corresponde a una cuota o un límite de gasto, no reintentar era la decisión correcta.
Relacionado: guía de unidades de facturación, tiers de precios para contextos largos, anatomía del uso de tokens, auditoría de caché del gateway.