Última actualización: 2026-06-22

Qué es la planificación de límites de tasa de un LLM

La planificación de límites de tasa de un modelo de lenguaje grande (LLM) es el proceso de determinar la tasa sostenible de solicitudes, y la concurrencia en curso que implica, que permiten los límites de la interfaz de programación (API) de un proveedor para una carga de trabajo dada. Las API de inferencia alojada limitan el rendimiento en dos ejes independientes: tokens por minuto (TPM), el número de tokens (entrada más salida) que la cuenta puede procesar cada minuto, y solicitudes por minuto (RPM), el número de llamadas a la API permitidas cada minuto con independencia de su tamaño. El tope que se alcanza primero fija el techo.

Qué límite restringe

Una carga de trabajo con un coste medio de tokens por llamada traduce el tope de TPM en un tope equivalente de solicitudes. Dividir el presupuesto de tokens por minuto entre los tokens consumidos por solicitud da las solicitudes por minuto que permite el límite de tokens por sí solo:

donde $L_t$ es el límite de TPM y $n$ son los tokens por solicitud. La tasa sostenible es el menor entre este tope derivado de los tokens y el tope explícito de RPM $L_r$:

Si $R_t < L_r$ restringe el límite de tokens; si $R_t \ge L_r$ restringe el límite de solicitudes. El trabajo con muchos tokens (contexto largo, respuestas grandes) tiende a estar limitado por los tokens; las llamadas pequeñas de alta frecuencia tienden a estar limitadas por las solicitudes.

Concurrencia a partir de la ley de Little

La tasa sostenible por segundo es $R_s = R / 60$. La ley de Little, un resultado de teoría de colas que establece que el número medio de elementos en un sistema es igual a la tasa de llegada por el tiempo medio que cada uno pasa en él, convierte esa tasa y la latencia media de la solicitud $t_L$ en la concurrencia $C$ que debe ejecutarse en paralelo para mantener el canal lleno:

Ejemplo resuelto

Considérese un límite de TPM de $L_t = 2\,000\,000$, un límite de RPM de $L_r = 10\,000$ y un promedio de n = 2,000 tokens por solicitud. El tope derivado de los tokens es

Como 1,000 < 10,000, restringe el límite de tokens: el rendimiento queda limitado a 1000 solicitudes por minuto, no a las 10 000 principales. A una latencia media de $t_L = 20$ segundos, la tasa por segundo es $R_s = 1\,000 / 60 \approx 16.7$, de modo que la concurrencia requerida es

Sostener la tasa significa, por tanto, mantener unas 333 solicitudes en curso a la vez. Como la carga de trabajo está limitada por los tokens, elevar el tope de RPM no ayudaría; reducir los tokens por solicitud (mediante mensajes más cortos, respuestas más pequeñas o Calculadora de ahorro por caché de mensajes) o solicitar una asignación de TPM más alta sí lo haría.

Variaciones y aplicación

Cuando las solicitudes están limitadas por las solicitudes en su lugar, agrupar varios elementos por llamada eleva el rendimiento efectivo mientras que recortar tokens no. La latencia entra solo a través de la ley de Little: duplicar $t_L$ duplica la concurrencia que exige una tasa fija, de modo que los modelos más rápidos relajan el dimensionamiento del grupo de conexiones y de las colas. La cifra de concurrencia alimenta la configuración del cliente (número de trabajadores, límites de semáforo, grupos de conexiones) y la tasa sostenible alimenta las proyecciones de coste mediante Calculadora de coste mensual de LLM. Como el número de tokens varía por solicitud y los proveedores pueden encolar o permitir ráfagas, las cifras en estado estacionario son una referencia de planificación que conviene validar frente al tráfico real.