Infraestructura y técnica

Tokens por minuto (TPM) y rate limits

Tokens por minuto (TPM) y peticiones por minuto (RPM) son los principales límites que los proveedores de IA imponen sobre el uso de sus APIs. Definen cuántos tokens se pueden procesar y cuántas peticiones se pueden enviar en un minuto, con límites distintos según el tier de la cuenta. Gestionarlos es esencial para no perder peticiones en pico de carga.

Por Ana María González Actualizado: 9 de mayo de 2026

Definición rápida

Respuesta directa

Explicación ampliada

Cada proveedor de IA gestiona la capacidad finita de sus servidores estableciendo límites por cuenta. Las dimensiones típicas: TPM (tokens por minuto, sumando input y output o por separado), RPM (peticiones por minuto), TPD (tokens por día). Los límites varían radicalmente por tier: una cuenta nueva puede tener 10.000 TPM y 60 RPM en un modelo grande; una cuenta enterprise con histórico de uso, millones de TPM y miles de RPM. Cuando se rebasa el límite, la API devuelve un error 429 ("rate limit exceeded") y la petición se pierde si el cliente no la reintenta. Las técnicas de gestión: rate limiting del lado cliente con librerías (tenacity, backoff, aiolimiter); request queueing con Redis o RabbitMQ para acumular en pico; backoff exponencial al recibir 429; distribuir entre varias cuentas o regiones; usar batch APIs (50% más baratas con SLA distinto, donde el proveedor procesa cuando puede). Para casos críticos, los proveedores ofrecen "dedicated capacity" o "provisioned throughput": pagas un fijo mensual por capacidad reservada, evitando el riesgo de límites en pico.

Por qué importa para tu empresa

Aplicación práctica

Para una empresa con uso intensivo de IA, TPM y RPM importan tanto como el precio por token. Un proyecto puede ser técnicamente viable pero operativamente inviable si choca contra límites. Tres prácticas maduras: (1) en evaluación de proveedores, preguntar siempre por límites del tier que vas a contratar y por proceso de subida (algunos elevan automáticamente con uso, otros requieren solicitud); (2) implementar rate limiting cliente-lado desde el día uno, no como reacción a problemas; (3) si tu carga es crítica y predecible, evaluar provisioned throughput o batch APIs según el caso. Los problemas de rate limit son una de las causas más frecuentes de incidentes en sistemas IA empresariales en producción.

Ejemplo concreto

Caso real

Una empresa de servicios automatizó la generación de informes para clientes con un asistente IA. Funcionaba bien la mayoría del tiempo, pero el primer día de cada mes se acumulaban peticiones (informes de cierre) y el sistema fallaba con errores 429 esporádicos. Investigaron: estaban usando tier 2 con 60.000 TPM y picos de 90.000 TPM en cierre. Tres soluciones implementadas: rate limiter cliente-lado con cola que respeta el TPM, distribución de carga a lo largo del día (informes empiezan a procesarse desde el día 28), y subida a tier 3 con 200.000 TPM tras documentar uso. Cero errores 429 desde entonces. Coste extra: marginal (el tier 3 era automático tras volumen). Lección: planificar para pico, no para promedio.