¿Qué es realmente un límite de tasa?
A límite de tasa es un límite a la rapidez con la que puedes usar una API. Los proveedores los imponen para mantener el servicio justo y estable: sin ellos, un solo bucle con errores o un pico de tráfico de un cliente podría matar de hambre a todos los demás, por lo que los límites protegen la capacidad, imponen niveles de planes y mitigan el abuso y los ataques de denegación de servicio. Cuando cruzas un límite, la API deja de servirte por un momento y te devuelve un HTTP 429 "Demasiadas solicitudes" respuesta en lugar de hacer el trabajo.
Los límites vienen en algunas unidades comunes y puedes alcanzar cualquiera de ellos primero:
| Unidad | Significado | lo que lo agota |
|---|---|---|
| RPM | Solicitudes por minuto | Muchas llamadas pequeñas y frecuentes. |
| TPM | Tokens por minuto (LLM API) | Algunas llamadas de gran contexto o de salida larga |
| RPD | Solicitudes por día | Alto volumen total durante 24 horas (común en los niveles gratuitos) |
| concurrencia | Solicitudes simultáneas durante el vuelo | Llamadas lentas que se superponen (generaciones largas, cargas grandes) |
En las API de LLM, las dos que muerden con mayor frecuencia son RPM y TPM, y son independientes. Cincuenta pequeñas llamadas de clasificación pueden superar las RPM sin apenas tocar el TPM; un resumen de documentos de 100.000 tokens puede superar el TPM en una sola solicitud. Diseñe para cualquier techo que alcance primero su carga de trabajo.
Convertir un límite de TPM en "¿cuántos usuarios puedo atender?"
La planificación de la capacidad es sólo aritmética. Empezar desde las fichas uno el usuario consume por minuto, luego divida su límite por él.
- Fichas por solicitud = tokens de entrada (mensaje + mensaje del sistema + contexto) más tokens de salida que genera el modelo. Ambos cuentan contra TPM.
- Solicitudes por usuario por minuto = qué tan hablador es un usuario activo.
- Tokens por usuario por minuto = tokens por solicitud × solicitudes por usuario por minuto.
Ejemplo: cada turno de chat utiliza ~1500 entradas + ~500 salidas = 2000 fichas, y un usuario activo envía ~1,5 vueltas por minuto → 3000 tokens/usuario/minuto. con un 300.000 TPM límite que puedes servir aproximadamente 300.000 ÷ 3.000 = 100 usuarios activos simultáneos. Haga la misma división contra su límite de RPM y tome el menor de las dos respuestas, ese es su verdadero techo. Nota "activo" significa envío activo; un producto con 100 usuarios simultáneos suele tener miles de cuentas iniciadas.
Calculadora de capacidad límite de tarifa →Calculadora de límite de tarifa →Niveles: gastar más aumenta tus límites
La mayoría de los proveedores ejecutan niveles de uso. Las cuentas nuevas comienzan con RPM/TPM/RPD bajos; A medida que gasta más y su cuenta envejece, se le asciende automáticamente a niveles más altos con límites mucho mayores, a veces 10 o 100 veces los números iniciales. Si estás alcanzando límites, las primeras preguntas son: ¿en qué nivel estoy y califico para el siguiente? Los acuerdos empresariales y de gasto comprometido pueden elevar aún más los límites o agregar capacidad dedicada.
Técnicas que amplían su rendimiento efectivo
- procesamiento por lotes — combine muchos elementos en menos solicitudes y de mayor tamaño para aliviar la presión de las RPM. Las API por lotes dedicadas de los proveedores también funcionan con descuento para trabajos no urgentes.
- Transmisión — La transmisión de tokens no aumenta el presupuesto de tokens, pero acorta la latencia percibida y libera recursos del cliente antes, por lo que las solicitudes superpuestas se eliminan más rápido.
- Retroceso y ritmo — distribuir las llamadas de manera uniforme a lo largo del minuto en lugar de dispararlas todas a la vez te mantiene bajo techos llenos de ráfagas con los que de otro modo tropezarías.
- Fichas de recorte — Los mensajes más cortos, el almacenamiento en caché de mensajes y los límites de salida estrictos aumentan directamente la cantidad de solicitudes que caben dentro de un presupuesto fijo de TPM.
Manejo de 429: retrocesos, reintentos y colas
Alcanzar un límite es normal; la pregunta es si su aplicación se recupera correctamente. El patrón estándar es retroceso exponencial con jitter: en un 429, espere un poco y luego vuelva a intentarlo; si falla nuevamente, aproximadamente duplique el retraso cada vez (por ejemplo, 1, 2, 4, 8) y agregue un pequeño desplazamiento aleatorio para que muchos clientes no vuelvan a intentarlo al mismo tiempo. Respeta siempre un Reintentar después encabezado si el proveedor envía uno: le indica exactamente cuánto tiempo esperar.
Límite estricto versus límite suave/ráfaga
A límite estricto es un límite absoluto: si lo excede, se rechazarán todas las solicitudes hasta que se restablezca la ventana. A límite suave o estallido permite picos cortos por encima de su ritmo constante (a menudo a través de un depósito de fichas que se recarga con el tiempo), por lo que pasan breves ráfagas pero la sobrecarga sostenida aún se regula. Saber a qué te enfrentas cambia tu estrategia: los límites de ráfaga recompensan suavizar el tráfico a través de la ventana; Los límites estrictos requieren una verdadera cola que mide las solicitudes a una tarifa segura.
- Cola de trabajo no urgente por lo que drena a un ritmo controlado en lugar de dañar la API.
- Carga extendida uniformemente en lugar de estallar al final de cada minuto.
- Limitar el total de reintentos por lo que una solicitud condenada falla limpiamente en lugar de repetirse para siempre.
El ángulo del coste: los límites dan forma a la arquitectura, no la factura
Los límites de tarifas no cuestan dinero directamente; nunca se le cobra por un 429. Pero influyen en gran medida en la forma en que construye y en esas opciones. hacer tener un costo. Cuando una sola clave no puede proporcionar el rendimiento que necesita, los equipos suelen recurrir a una cadena de reserva (conmutación por error a un segundo modelo o proveedor cuando el principal acelera), múltiples claves o proveedores a la capacidad del pool, y un API por lotes para impulsar los trabajos no urgentes hacia carriles más baratos y con límites más altos. Cada uno agrega resiliencia y margen de maniobra, pero también complejidad de integración y, a veces, precios más altos por token en el caso de respaldo. El enfoque más saludable es aumentar su nivel y recortar los tokens primero, luego agregar redundancia solo cuando un límite estricto realmente lo bloquee.
Cómo funcionan los precios de LLM API →Más guías de aprendizaje →Preguntas frecuentes
¿Cuál es la diferencia entre RPM y TPM?
RPM (solicitudes por minuto) limita la cantidad de llamadas API que puede realizar cada minuto, mientras que TPM (tokens por minuto) limita la cantidad de texto que pueden mover esas llamadas. Puede alcanzar cualquiera de los límites primero: muchas llamadas pequeñas agotan el RPM, mientras que algunas llamadas de contexto grande agotan el TPM.
¿Cómo convierto un límite de TPM en la cantidad de usuarios a los que puedo atender?
Calcule los tokens que consume un usuario por minuto (tokens por solicitud multiplicados por solicitudes por usuario por minuto, contando tanto la entrada como la salida), luego divida su límite de TPM por esa cifra. Si un usuario necesita 3000 tokens por minuto y su límite es 300 000 TPM, puede atender a unos 100 usuarios activos simultáneos.
¿Cómo debo manejar un error 429 Demasiadas solicitudes?
Vuelva a intentarlo con retroceso y fluctuación exponencial: espere progresivamente más tiempo entre intentos y respete cualquier encabezado Retry-After que devuelva el proveedor. Ponga en cola el trabajo no urgente, distribuya la carga de manera uniforme en lugar de sobrecargarla y limite el total de reintentos para que una solicitud finalmente falle limpiamente en lugar de repetirse para siempre.
Solo referencia educativa: los límites exactos, las unidades y los umbrales de niveles varían según el proveedor; confirme los valores actuales en la documentación de límite de tarifas de cada proveedor.