Benchmark de vLLM: reproduce la latencia, el rendimiento y el coste de GPU antes de desplegar

Un benchmark de vLLM solo es útil cuando se parece al tráfico que su aplicación enviará realmente. Una cifra destacada de tokens por segundo puede ocultar un primer token lento, una cola sobrecargada o una distribución de prompts que nunca aparece en producción. Esta guía le ofrece un benchmark de serving repetible: elija una carga de trabajo, varíe la carga ofrecida, registre juntos la distribución de latencia y el rendimiento, y compare configuraciones de GPU con el mismo objetivo de calidad.

Respuesta rápida: Use vllm bench serve con una versión y un modelo de vLLM fijados en un servidor de GPU dedicado. Mantenga fijos el modelo, la precisión, las longitudes de prompt y salida, la configuración de muestreo, el estado de la caché y la ubicación del cliente. Ejecute varias tasas de solicitudes, capture TTFT, TPOT, latencia de extremo a extremo, tasa de solicitudes correctas y tokens de salida por segundo; después, elija la configuración menos costosa que cumpla su objetivo de servicio con carga máxima. Una sola ejecución de rendimiento máximo no es un plan de capacidad.

Qué medir en un benchmark de vLLM

La documentación de benchmarks de vLLM define TTFT, latencia entre tokens y TPOT según sus puntos de medición. Use esas definiciones al comparar herramientas. En particular, el TTFT del cliente incluye el transporte y el trabajo del frontend; las métricas opcionales del lado del servidor pueden separar la espera del planificador de la ejecución del modelo, pero habilitarlas añade sobrecarga. Mantenga las ejecuciones de diagnóstico separadas de los resultados principales.

Fije una comparación justa antes de ejecutar

Anote la revisión del modelo y el tokenizador, la versión de vLLM, el tipo y número de GPU, el tamaño de paralelismo de tensores, las opciones de serving, el formato de cuantización, la longitud de contexto y el entorno de software. Use los mismos prompts y objetivos de salida para cada candidato. Si cambia el modelo, la precisión y la GPU a la vez, el resultado no puede indicarle qué cambio ayudó.

Elija al menos dos cargas de trabajo. Una carga de trabajo sintética de longitud fija es útil para variaciones controladas; un rastro anonimizado de longitudes de solicitudes reales es mejor para tomar una decisión de producción. Conserve la distribución de prompts largos, respuestas cortas y ráfagas. Para un producto de chat, mida el endpoint de chat con el backend de benchmark correspondiente. Para una carga de trabajo de completions, use el backend de completions. No compare sus cifras como si el formato de las solicitudes fuera idéntico.

Decida los criterios de aprobación antes de la ejecución. Por ejemplo, establezca una tasa requerida de solicitudes correctas y un TTFT p95 y una latencia de extremo a extremo p95 máximos para su propia carga de trabajo. No publicamos un umbral universal: depende de la experiencia de usuario y del tamaño de salida. Una tabla de aceptación con los umbrales, los resultados medidos y el motivo de aprobación/rechazo es más útil que una única puntuación de rendimiento.

Ejecute una prueba de serving controlada

La guía actual de la CLI de vLLM indica vllm bench serve para mediciones de serving en línea y recomienda el extra bench para sus dependencias. El siguiente esquema utiliza el ejemplo documentado de completions de vLLM. Sustituya el modelo y el conjunto de datos por recursos que tenga licencia para ejecutar y que se ajusten a su hardware. Estos comandos son una plantilla reproducible, no resultados medidos de Flatkey.

python -m pip install 'vllm[bench]'
vllm serve YOUR_MODEL_ID

En una segunda shell, después de que el servidor esté listo:

vllm bench serve \
  --backend vllm \
  --model YOUR_MODEL_ID \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --num-prompts 1000 \
  --request-rate 1 \
  --save-result \
  --save-detailed

A continuación, repite con una serie corta de valores más altos de --request-rate manteniendo fijas las demás entradas. Usa suficientes prompts para evitar interpretar unas pocas solicitudes como una distribución de latencia de cola. Guarda los resultados sin procesar y el comando exacto de cada ejecución. El ejemplo oficial de benchmark en línea muestra los campos de salida y explica cómo --save-result y --save-detailed conservan la evidencia. Para solicitudes de chat, usa el backend documentado openai-chat y el endpoint /v1/chat/completions con un conjunto de datos y un modelo compatibles con el formato de chat.

No ejecutes este benchmark contra un endpoint de producción compartido sin un plan de tráfico. Genera carga intencionadamente. Usa un despliegue de prueba aislado o una ventana de mantenimiento controlada, y registra cualquier trabajo en segundo plano que pueda afectar al resultado.

Haz un barrido hasta encontrar el punto de inflexión de la latencia

Representa la tasa de solicitudes ofrecida en el eje horizontal. Representa las solicitudes completadas por segundo, TTFT p95, latencia de extremo a extremo p95 y tokens de salida por segundo como series independientes. Al principio, el rendimiento puede aumentar aproximadamente con la carga ofrecida. Más allá de la región sostenible, la cola crece, la latencia de cola aumenta y el rendimiento exitoso puede estabilizarse. Ese punto de inflexión importa más que el mayor número impreso en una sola ejecución.

Mantén una ejecución de calentamiento separada. vLLM advierte que repetir un benchmark contra el mismo servidor puede reutilizar prefijos en caché e inflar el rendimiento. Si la reutilización de caché no forma parte de la carga de trabajo del producto, varía la semilla o restablece el servidor o la caché según las directrices oficiales del benchmark. Si la reutilización de caché sí es realista, informa de la tasa de aciertos de caché e incluye una comparación con caché fría. Un benchmark sin una política de caché declarada es difícil de reproducir.

Cuando una ejecución no alcanza su objetivo, inspecciona la secuencia. Un aumento de TTFT con una cola creciente puede indicar saturación o control de admisión. Un TPOT deficiente con un tiempo de cola estable puede indicar decodificación, ancho de banda de memoria, paralelismo o una elección de precisión ineficiente. Si aumentan los fallos, revisa los tiempos de espera, los OOM y los registros del servidor antes de ajustar la configuración del modelo. Cambiar varias variables a la vez oculta la causa.

Compara las opciones de GPU por trabajo aceptado, no por velocidad bruta

Una GPU más grande puede producir más tokens de salida por segundo y, aun así, costar más por solicitud aceptada. Calcula un coste aproximado para cada configuración:

Coste de GPU por 1.000 solicitudes exitosas = coste horario de GPU ÷ solicitudes exitosas por hora × 1.000

Usa una cotización actual para la región y el compromiso exactos, e incluye infraestructura que no sea GPU o incrementos mínimos de facturación si son relevantes. Compara únicamente ejecuciones que cumplan tus objetivos de latencia y errores. Una configuración más barata que no cumple el TTFT p95 no es una forma más barata de prestar el mismo servicio.

Para una comparación inicial en la nube, mantén el modelo y la configuración de servicio fijos mientras cambias únicamente el tipo de GPU. Después prueba un pequeño número de cambios de ajuste, como la configuración de lote y memoria, de uno en uno. Captura la utilización, el margen de VRAM, la profundidad de cola, la tasa de éxito de solicitudes y el artefacto del benchmark. Flatkey Compute puede ser una opción de capacidad que evaluar; verifica la GPU ofrecida, la región y la cotización actual antes de usarla en una comparación de costes. Esta guía no afirma que una GPU concreta sea siempre más rápida o más barata.

Un resultado de benchmark de vLLM que puedes entregar a un revisor

Para cada ejecución, registra: modelo y revisión; versiones de vLLM y del controlador; GPU y topología; comando y suma de comprobación del conjunto de datos; distribución de longitudes de entrada/salida; ubicación del cliente; política de caché; tasa de solicitudes; solicitudes completadas y fallidas; TTFT p50/p95/p99; latencia de extremo a extremo p50/p95/p99; rendimiento de tokens de salida; utilización de GPU y VRAM; cotización por hora; coste por solicitud aceptada; y aprobado/reprobado frente al objetivo predeterminado.

Este es también el momento de mantener visibles la seguridad y la calidad. Los prompts del benchmark deben eliminar los datos de clientes, y la calidad de salida debe comprobarse al comparar modelos cuantizados o diferentes revisiones de modelos. Una aparente ganancia de velocidad que cambia la calidad de la tarea no es una ventaja comparable.

Preguntas frecuentes

¿Es vllm bench throughput lo mismo que vllm bench serve?

No. El primero se centra en el rendimiento de inferencia sin conexión; el segundo envía solicitudes en línea a un servidor en ejecución y mide el comportamiento del servicio de cara al cliente. Use bench serve para planificar la latencia y la capacidad de un despliegue de API. La referencia de la CLI de vLLM incluye ambos comandos.

¿Qué métrica debo optimizar primero?

Comience por el objetivo de servicio: tasa de éxito y latencia de cola con el tráfico máximo previsto. Después, minimice el coste entre las configuraciones que cumplan los criterios. El rendimiento agregado de tokens es útil para diagnosticar la capacidad, pero no puede sustituir un objetivo de latencia de cara al usuario.

¿Puedo comparar cifras de benchmark publicadas por distintos proveedores?

Solo si coinciden el modelo, la precisión, la carga de trabajo, la longitud de salida, el endpoint, la política de caché, el régimen de tasa de solicitudes y las definiciones de medición. En la mayoría de los casos, volver a ejecutar la misma carga de trabajo en ambos entornos proporciona una comparación más defendible.

Siguiente paso: tome una traza representativa, fije los criterios de aprobación, ejecute un breve barrido de tasas en dos configuraciones de GPU y conserve los resultados completos junto con la decisión. Si también está cambiando la precisión, utilice la guía de cuantización de vLLM independiente para evaluar la memoria y la calidad antes de atribuir cualquier diferencia de velocidad a la GPU.