¿Cómo deberían las APIs de LLM limitar las solicitudes, los tokens y la concurrencia?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Una API de LLM necesita límites separados para el número de solicitudes, el volumen de tokens y el trabajo concurrente. Las solicitudes por minuto no bastan para proteger un servicio cuando varían la longitud de los prompts y las salidas generadas. Añade límites de entrada y salida por solicitud y después prueba los límites de admisión frente al objetivo de latencia.
Por qué no basta con contar las solicitudes
Un prompt de 10 tokens y otro de 100,000 tokens difieren en longitud de entrada por un factor de 10,000. Sus costes totales también dependen de la longitud de salida, el modelo y el uso de caché. Un límite que los trate por igual puede admitir más trabajo del que el servicio puede procesar.
Combina varios controles:
| Límite | Qué controla |
|---|---|
| Solicitudes por minuto | Volumen de llamadas, incluidas muchas solicitudes pequeñas |
| Tokens de entrada y salida | Volumen de procesamiento y gasto variables |
| Solicitudes concurrentes | Trabajo activo que consume capacidad de decodificación y memoria KV |
| Tokens por solicitud | Prompts o salidas individuales que superan los límites probados |
Aplica los límites de cada cliente antes de un límite compartido para todo el servicio, de modo que un cliente no pueda consumir toda la capacidad disponible.
Cómo funciona la reserva de tokens
Una posible política de la aplicación reserva los tokens de entrada estimados más la salida máxima permitida al admitir la solicitud. Una solicitud con 2,000 tokens de entrada y un límite de salida de 1,000 reserva 3,000 tokens. Si produce 200 tokens de salida, el uso real es de 2,200; la aplicación devuelve 800.
Distingue este ejemplo de la contabilidad del proveedor. OpenAI documenta sus propias estimaciones de cuotas de solicitudes y tokens. Anthropic documenta límites separados de tokens de entrada y salida. Una reserva local no permite predecir qué cuota del proveedor consume una solicitud. Reconcilia las solicitudes interrumpidas cuando se conozca el uso y limita las reservas que no puedan reconciliarse.
Qué comprobar bajo carga
Combina prompts cortos y largos, salidas cortas y largas y clientes simultáneos. Registra el tiempo en cola, las solicitudes rechazadas, TTFT, TPOT y el uso de KV cache. Mantén las solicitudes en cola solo durante un tiempo limitado; si se supera, recházalas con una política clara de reintentos. Un presupuesto de tokens por minuto puede seguir admitiendo una ráfaga que supere la capacidad de memoria para solicitudes concurrentes.
Para conocer el diseño más amplio, lee la limitación de la tasa de solicitudes en la guía de ingeniería de LLM.