Throughput frente a goodput en LLM: ¿qué métrica debes usar?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
El throughput de un LLM mide cuánto trabajo completa un servidor por segundo. El goodput mide la tasa de trabajo que además cumple unos requisitos de servicio definidos. Para tomar decisiones de serving, usa el throughput de tokens de salida junto con las solicitudes completadas correctamente por segundo que cumplen tus objetivos de latencia del primer token y de generación.
Un servidor que produce más tokens mientras las solicitudes agotan su tiempo de espera puede tener un throughput mayor y una capacidad útil menor.
Define qué solicitudes cumplen los requisitos
Antes de hacer pruebas, define las condiciones que debe cumplir una solicitud. Por ejemplo: completarse correctamente, una TTFT inferior a 500 ms y una TPOT media inferior a 50 ms. Después, cuenta las solicitudes completadas que cumplen esos requisitos durante el intervalo de medición:
request goodput = qualifying completed requests / measured seconds
output throughput = generated output tokens / measured seconds
Estos son un SLO ilustrativo y dos definiciones explícitas de métricas. Si se completan 100 solicitudes en diez segundos, pero solo 60 cumplen los requisitos, el throughput de finalización es de diez solicitudes por segundo y el goodput es de seis. Indica también el throughput de tokens de salida, ya que las respuestas pueden tener distintas longitudes.
DistServe usa el goodput para evaluar el serving con requisitos de TTFT y generación de tokens. Indica siempre si tu unidad son solicitudes o tokens que cumplen los requisitos: la palabra por sí sola no define el denominador ni las reglas para decidir qué se cuenta.
Mantén una carga de trabajo comparable
| Registra | Por qué afecta al resultado |
|---|---|
| Longitudes de entrada y salida | Varían el trabajo de prefill, el tamaño de la caché y la duración de la decodificación |
| Modelo, precisión, GPU y revisión del runtime | Cambian el coste de ejecución |
| Solicitudes ofrecidas por segundo | Determina la presión sobre la cola |
| Solicitudes simultáneas | Cambia la agrupación en lotes y el uso de memoria |
| Política de caché | Los prefijos repetidos pueden reducir el trabajo de prefill |
| Errores y cancelaciones | La finalización correcta forma parte de la capacidad útil |
Con lotes pequeños de decodificación, añadir solicitudes puede mejorar la reutilización de los pesos. Los lotes mayores o el aumento de la carga ofrecida pueden acabar elevando la latencia o superando los límites de memoria, cómputo o comunicación. La curva depende de la carga de trabajo; no está garantizado que escale de forma lineal.
Aumenta la carga ofrecida por etapas y representa el throughput, el goodput, la latencia P99, los errores y la longitud de la cola. Elige una carga que cumpla los requisitos y deje margen para las variaciones de tráfico. El experimento de Anyscale sobre agrupación continua en lotes muestra por qué una comparación necesita especificar la distribución de solicitudes.
La guía de ingeniería: throughput y compromiso con la latencia explica este compromiso del serving en contexto.