Límite TPM de Azure OpenAI: cómo diagnosticar y resolver los errores 429

Empieza por la solicitud rechazada, no por el total de tokens

En Azure OpenAI, TPM significa tokens por minuto. El límite se aplica al despliegue que recibe las solicitudes y utiliza una estimación del trabajo máximo al admitirlas. No equivale a los tokens facturados al terminar la respuesta. Además, Azure aplica un límite de solicitudes por minuto, o RPM. Por eso, un gráfico de consumo bajo no descarta que se haya agotado alguno de los dos presupuestos. Microsoft explica esta diferencia en su guía de administración de cuotas.

Antes de pedir más cuota, identifica qué componente devuelve el 429 y qué límite se ha alcanzado. Esta guía se refiere a Azure OpenAI en Microsoft Foundry; las cuotas de una cuenta de la API de OpenAI y los límites de ChatGPT no determinan la capacidad de tu despliegue de Azure. Si utilizas directamente api.openai.com, consulta la guía de límites de la API de OpenAI.

Conserva una solicitud fallida y otra correcta del mismo despliegue, próximas en el tiempo. Registra la hora con zona horaria, nombre del despliegue, modelo y versión, tipo de despliegue, región, estado HTTP, mensaje de error e identificador de solicitud disponible. Añade el tamaño de entrada, el máximo de salida solicitado y el número real de intentos. No necesitas almacenar claves ni el texto privado de la conversación para investigar el límite.

Qué cabeceras merece la pena guardar

Recoge estas cabeceras de las respuestas que llegan a tu aplicación. Los nombres son insensibles a mayúsculas y minúsculas.

La documentación de cabeceras de Azure OpenAI describe estos campos. No conviertas un valor ausente en cero: una pasarela puede eliminar o modificar cabeceras. Tampoco supongas que todos los campos reset usan la misma unidad que retry-after-ms; registra su valor original y confirma el formato de la interfaz que utilizas.

Separa las causas antes de cambiar la cuota

Usa el mensaje, las cabeceras y la configuración conjuntamente. Una única captura orienta; varias respuestas consecutivas permiten comprobar el patrón.

Microsoft distingue entre agotamiento de cuota, estimación de tokens y restricciones temporales de capacidad. Una ampliación de cuota no soluciona necesariamente un 429 por capacidad del servicio. Un límite efectivo inferior al configurado puede indicar un ajuste temporal; no permite prometer una hora de recuperación. Tipos de errores 429 y acciones recomendadas.

Si existe Azure API Management, revisa su política llm-token-limit: mantiene contadores propios por clave. Superar la tasa de tokens puede producir un 429; agotar la cuota del periodo puede producir un 403. Esto no convierte todos los 403 en errores de cuota. La traza y la política efectiva deben confirmar quién rechaza la solicitud. Mantén los controles corporativos al investigar; el acceso directo al servicio no es un sustituto de corregir la configuración autorizada. Referencia de la política de API Management.

Por qué una respuesta breve puede consumir mucho margen TPM

El cálculo de admisión considera la entrada, el máximo de salida configurado y, cuando la API lo admite, best_of. Parte de la estimación se basa en caracteres; no es una suma exacta del tokenizador de facturación. También pueden contar solicitudes rechazadas, incluidas algunas que terminan en un HTTP 400. Por qué hay 429 con métricas de uso bajas.

Supón que un servicio resume documentos con una entrada de unos 1.500 tokens y normalmente devuelve 300. El cliente admite hasta 6.000 tokens de salida. La siguiente cuenta es una aproximación de planificación, no la fórmula exacta de Azure ni una medición de rendimiento:

La diferencia explica por qué mirar solo el uso puede llevarte a pedir una ampliación innecesaria. Ajusta el máximo a respuestas completas y útiles para tu aplicación; después comprueba que no aumentan las salidas truncadas. Utiliza el parámetro admitido por tu API y modelo: max_tokens aparece en la explicación oficial, pero no es un campo universal para todas las familias. No añadas best_of a una solicitud que no lo admite.

Para planificar, calcula tanto el presupuesto aproximado de tokens como el número de solicitudes. Divide los TPM disponibles entre tu estimación por solicitud y compáralo con los RPM del despliegue; el menor valor orienta el techo medio. Deja margen para entradas variables, estimación del servicio y otras aplicaciones. Esta cuenta no garantiza admisión, porque el control también responde a ráfagas y a las condiciones de capacidad.

Confirma dónde está asignada la cuota

La cuota aprobada de la suscripción es el fondo disponible para asignar. Los TPM del despliegue son la parte que has destinado al receptor de tu tráfico. Puedes tener cuota libre y seguir recibiendo 429 si ese despliegue tiene poca asignación. Además, la proporción entre RPM y TPM depende del modelo: no apliques de forma general la regla de seis solicitudes por cada mil tokens. Asignación y proporciones por modelo.

Comprueba el campo Scope antes de abrir otra región

Microsoft está incorporando modelos a la gestión compartida de cuota por suscripción. En los modelos incorporados, Global Standard comparte cuota entre regiones para el mismo modelo y versión, y Data Zone Standard la comparte dentro de su zona de datos. La transición comenzó después del 7 de mayo de 2026; no debes dar por migrados todos los modelos. Cuota compartida por suscripción.

En la página de cuotas, mira Scope: un valor Global o Data Zone identifica el ámbito compartido; el nombre de una región indica gestión regional para esa suscripción y modelo. Esa comprobación determina si dos despliegues compiten por el mismo fondo. Crear recursos en más regiones no garantiza multiplicar la cuota. Cómo comprobar el ámbito de gestión.

Cambia la asignación del despliegue que recibe el tráfico

En la nueva interfaz de Microsoft Foundry, con New Foundry activado:

1. Abre Manage > Quota > Token per minute.
2. Selecciona el despliegue y comprueba su asignación y los despliegues asociados.
3. En Affiliated deployments using shared quota, utiliza el icono del lápiz para ajustar la asignación, si tienes permisos.
4. Si falta cuota disponible, revisa si puedes redistribuirla sin perjudicar otros servicios o solicita una ampliación con Request quota.
5. Vuelve a consultar la asignación y contrástala con nuevas respuestas del servicio.

Microsoft indica que la propagación de cambios puede tardar hasta 15 minutos; esto no es un plazo de aprobación de nuevas cuotas. El rol Cognitive Services Usages Reader, aplicado a la suscripción, permite consultar el uso con permisos mínimos, pero no autoriza a editarlo. Pasos y permisos en la documentación de Foundry.

Si automatizas la comprobación, la API de administración Usages devuelve currentValue y limit: describen la cuota ocupada por despliegues y su límite, no los tokens facturados durante este minuto. Conserva el identificador de modelo y tipo de despliegue, junto con la unidad original; algunas entradas expresan miles de TPM. La API Model Capacities responde a otra pregunta: qué capacidad hay para desplegar. Tener cuota no demuestra disponibilidad de capacidad. Consulta programática de cuota y capacidad.

Controla las llegadas y los reintentos como una sola carga

Los RPM pueden evaluarse en ventanas cortas, normalmente de uno o diez segundos. En el ejemplo oficial, un despliegue de 600 RPM evaluado cada segundo admite un ritmo de diez solicitudes por segundo; concentrar más en ese segundo puede provocar rechazo aunque el total del minuto sea bajo. No presupongas que tu modelo utiliza exactamente esa ventana. Evaluación de RPM.

Una cola debe regular cuándo sale cada solicitud y cuánto presupuesto aproximado necesita. Limitar solo las solicitudes simultáneas no fija el ritmo: con cinco solicitudes concurrentes y respuestas que tardan medio segundo, puedes iniciar muchas más por minuto que con respuestas de cinco segundos. Si hay varios procesos, el control debe abarcar su tráfico conjunto hacia el despliegue, incluidas las tareas programadas.

Aplica una política de reintentos con estas decisiones explícitas:

• Un único mecanismo gestiona los reintentos: el SDK o tu aplicación. Si los implementas fuera del SDK, desactiva los internos cuando proceda; en el cliente Python del ejemplo oficial se configura con max_retries=0.
• Tras un 429, el cliente respeta retry-after-ms cuando esté disponible, o Retry-After si la interfaz lo proporciona con un formato válido. Sin indicación del servidor, usa espera exponencial con variación aleatoria.
• Fija tanto un número máximo de intentos como un plazo total que tenga sentido para el usuario. Si la espera indicada supera el tiempo restante, devuelve un resultado controlado o deja el trabajo en una cola adecuada; no reintentes antes de lo solicitado.
• Los reintentos vuelven a pasar por el control de admisión. Reenviarlos por un camino separado anula la protección de la cola.

Las solicitudes fallidas pueden consumir presupuesto. Por ejemplo, tres intentos externos combinados con un SDK que realiza hasta tres intentos por llamada permiten llegar a nueve solicitudes por una sola operación del usuario. Cuenta intentos reales, no solo operaciones de negocio. La guía oficial de reintentos explica la espera y cómo evitar la duplicación. Para decidir qué hacer cuando se agota el plazo, consulta cuándo reintentar y cuándo recurrir a otro modelo.

Verifica la recuperación sin confundirla con una bajada de tráfico

Un 200 aislado confirma que una solicitud pasó; no demuestra que la aplicación soporte otra vez su carga habitual. Prepara una comparación antes y después con el mismo despliegue, una mezcla comparable de entradas y un volumen conocido. Cambia una sola variable cuando sea viable para poder interpretar el resultado.

Registra, por intervalo, solicitudes originales, intentos totales, respuestas 429, operaciones completadas dentro de plazo, tiempo de espera en cola y latencia. Si has reducido la salida máxima, añade respuestas truncadas. Guarda también los límites efectivos de las cabeceras. El porcentaje de 429 por intento detecta presión sobre el servicio; el porcentaje de operaciones completadas dentro de plazo mide lo que recibe el usuario.

Empieza con tráfico reducido, mantén varios intervalos completos y aumenta gradualmente hasta la carga objetivo, siempre dentro de los límites autorizados. Si el servicio termina menos trabajo del que entra, la cola crece: todavía falta capacidad o hay que reducir la demanda, aunque ya no veas tantos 429. Usa los objetivos de plazo y completitud de tu aplicación como criterio de aceptación; no existe un porcentaje universal que convierta el resultado en satisfactorio.

Si el problema persiste, reúne la identidad exacta del despliegue, las horas con zona horaria, identificadores de solicitudes, límites configurados y efectivos, ritmo de intentos y cambios ya realizados para soporte de Azure. Un patrón sostenido con poca carga y límite efectivo inferior al asignado requiere una investigación distinta de una ráfaga provocada por el cliente.

Para cargas estables exigentes, valora un despliegue aprovisionado con PTU a partir del modelo y la mezcla real de trabajo. PTU también puede saturarse y devolver 429; no tiene una conversión universal a TPM ni la aprobación de cuota garantiza capacidad disponible. Cómo funciona el rendimiento aprovisionado. Y si el fallo es por tamaño de contexto de una solicitud, aumentar TPM no lo corrige: debes reducir la entrada o elegir un modelo cuyo contexto admita ese trabajo.