Límites de solicitudes de la API de LLM: maneja errores 429, reintentos y concurrencia de forma segura

Una aplicación LLM en producción necesita más que un bucle de reintentos. Necesita saber por qué se rechazó una solicitud, cuánto trabajo puede admitir y cuándo dejar de intentarlo.

El punto de partida práctico es simple: clasificar el error, controlar la admisión de solicitudes y reintentar solo las fallas que puedan recuperarse de forma plausible dentro del plazo de la operación. Aumentar los reintentos sin estos controles puede convertir un pequeño pico de tráfico en una interrupción más larga.

Esta guía cubre el diseño de aplicaciones neutral respecto al proveedor. Las cuotas exactas, los códigos de error, los encabezados y las reglas de contabilidad dependen de tu proveedor, modelo, cuenta y gateway.

Entiende qué límite alcanzaste

Estos controles responden a preguntas distintas:

Control	Qué mide	Respuesta de la aplicación
Tasa de solicitudes	Solicitudes admitidas dentro de una ventana de tiempo	Regula los inicios y suaviza los picos
Tasa de tokens	Uso de tokens o demanda estimada de tokens	Reserva capacidad de tokens y limita el tamaño de la solicitud
Concurrencia	Solicitudes actualmente en curso	Limita los workers o usa un semáforo
Gasto o saldo	Disponibilidad financiera	Revisa los controles de cobros o presupuesto

OpenAI, por ejemplo, documenta límites separados de solicitudes y de tokens, con alcances que pueden incluir proyectos y familias de modelos compartidas. Por lo tanto, una nueva clave de API no necesariamente implica nueva capacidad. Su documentación también distingue los errores transitorios de límite de solicitudes de los límites estrictos de gasto, incluso cuando ambos usan 429. Lee el cuerpo del error en lugar de tomar decisiones solo con el código de estado. Documentación de límites de solicitudes de OpenAI

El estándar HTTP define 429 pero no prescribe cómo un servicio identifica a quienes llaman ni cómo cuenta las solicitudes. También hace que Retry-After sea opcional. No asumas que todos los endpoints compatibles con OpenAI tienen un comportamiento de limitación idéntico. Especificación de HTTP 429

Dimensiona el tráfico según la restricción más ajustada

Considera un límite simplificado e hipotético de 60 solicitudes por minuto y 120,000 tokens por minuto. Si cada solicitud consume 4,000 tokens contados, la capacidad de tokens solo admite 30 solicitudes de ese tipo por minuto:

120,000 tokens/minute ÷ 4,000 tokens/request = 30 requests/minute

Este es un ejemplo de planeación, no una cuota de proveedor ni un programador exacto. Un servicio puede reservar la salida estimada, usar ventanas de aplicación más cortas o contabilizar de forma distinta las diferentes categorías de tokens.

Mide tu propia distribución de tamaños de solicitud. Los promedios por sí solos ocultan cargas de documentos grandes y generaciones largas. Mantén un margen para estos casos atípicos en lugar de apuntar al máximo matemático.

Usa controles separados para los inicios y el trabajo en curso. Un límite de concurrencia por sí solo no aplica solicitudes por minuto: las respuestas rápidas pueden liberar espacios lo bastante rápido como para crear inicios excesivos. A la inversa, un limitador de tasa de solicitudes no evita que los streams lentos se acumulen y agoten las conexiones.

Coloca el control de admisión antes de los reintentos

Una ruta de solicitud útil es:

Authenticated request → bounded queue → rate/token admission → worker → provider

Diseña la cola de forma deliberada:

• Establece una longitud máxima de cola y un tiempo máximo de espera.
• Da a las solicitudes interactivas un plazo más corto que a los trabajos en segundo plano.
• Rechaza o difiere el trabajo excedente con una respuesta clara a nivel de aplicación.
• Elimina los trabajos cancelados y vencidos antes del despacho.
• Comparte el estado de admisión entre las réplicas que consumen la misma cuota del proveedor.

De lo contrario, agregar servidores de aplicación puede multiplicar el tráfico mientras la capacidad del proveedor permanece sin cambios. Para cargas de trabajo mixtas, reserva algo de capacidad para las solicitudes dirigidas al usuario, de modo que un trabajo de importación de documentos no pueda ocupar todos los espacios.

Estas son recomendaciones de arquitectura, no promesas de que un gateway en particular exponga una cola o controles de concurrencia ajustables.

Usa una sola política de reintentos acotada

Los reintentos deben tener un responsable. Inspecciona el comportamiento del SDK antes de agregar otro bucle. En una configuración hipotética, tres intentos de la aplicación envueltos alrededor de tres intentos del SDK pueden producir nueve intentos en el proveedor para una sola operación lógica.

Una política práctica es:

1. Clasifica la falla usando la información de error documentada por el proveedor.
2. Detente de inmediato ante errores que requieran cambiar credenciales, permisos, cobros o el contenido de la solicitud.
3. Reintenta solo las fallas transitorias elegibles mientras sigan disponibles tanto el presupuesto de intentos como el de tiempo.
4. Respeta la guía válida de reintento del servidor; de lo contrario, usa retroceso exponencial con límite máximo y jitter.
5. Devuelve la falla final con suficiente contexto para investigarla de forma segura.

Retry-After puede especificar un retraso o una fecha. Trata un retraso aplicable del servidor como un mínimo, no como una sugerencia para acortarlo. Si supera el plazo restante de la operación, difiere el trabajo o falla de forma clara en lugar de reintentar antes de tiempo. Semántica de Retry-After de HTTP

Las esperas aleatorizadas reducen las oleadas de reintentos sincronizados. Los tiempos de espera y los intentos acotados evitan que los reintentos retengan recursos indefinidamente. La guía de ingeniería de AWS explica por qué los reintentos pueden amplificar la sobrecarga y por qué un tiempo de espera no prueba que una operación no haya tenido efecto. Guía de AWS sobre tiempos de espera y reintentos

No repitas a ciegas streams ni acciones de agentes

Un stream que se detiene después de mostrar texto no es lo mismo que una solicitud rechazada antes de que comenzara el trabajo. Tu interfaz necesita un estado incompleto explícito. Volver a empezar automáticamente puede duplicar texto, consumir tokens adicionales o producir una respuesta diferente.

Los flujos de trabajo de agentes necesitan un límite adicional: reintentar la generación del modelo no debe repetir automáticamente acciones de herramientas ya completadas. Registra los resultados de las acciones y usa mecanismos de idempotencia donde el servicio de acciones los admita. Una respuesta fallida no justifica enviar el mismo correo ni crear el mismo pedido dos veces.

Monitorea el trabajo lógico, no solo el éxito HTTP

Da seguimiento a esto por separado:

• Operaciones lógicas e intentos en el proveedor.
• Espera en cola y solicitudes en curso.
• Rechazos por motivo de error documentado.
• Uso de entrada/salida y costo por operación completada.
• Tiempos de espera, trabajo cancelado y streams incompletos.

Usa identificadores de solicitud y metadatos sanitizados. Evita registrar encabezados de autorización o prompts completos de forma predeterminada. Una tasa de errores a la baja no es una victoria si los reintentos duplicaron el costo de cada tarea completada.

Revisa los controles de la pasarela por separado de la capacidad

La información de precios y de la cuenta publicada por cheapaimodel describe presupuestos por clave, vencimiento, listas de permitidos de modelos/IP y una respuesta 403 cuando se agota el saldo de la cuenta. Esa condición de saldo no es algo que un breve backoff resuelva. Esos controles tampoco establecen un rendimiento ilimitado de solicitudes o tokens.

Antes de escalar una integración, consulta la documentación actual de cheapaimodel y confirma los límites aplicables para la ruta que piensas usar. Mantén el control de admisión y la política de reintentos configurables para que los cambios no requieran reescribir la lógica de la aplicación.

La meta es trabajo completado predecible: espera acotada, fallas explicables, gasto controlado y reintentos que ayuden a la recuperación en lugar de pelearse con ella.