vLLM: Ajuste de Rendimiento y Monitoreo Prod

Parte 4 de 6. En la Parte 3 ajustamos tensor parallelism y cuantización. Aquí optimizamos el rendimiento y configuramos el monitoreo. Continúa en Parte 5: Comparación, Checklist y Solución de Problemas.

Ajuste de rendimiento para cargas de trabajo de vLLM

Optimizar vLLM se reduce a tres cosas: gestionar el KV cache, ajustar parámetros de scheduling, y calentar los kernels GPU antes de que llegue tráfico de producción.

Gestión del KV Cache

Dos parámetros controlan el KV cache, y necesitas entender ambos:

• --max-model-len: Límite estricto en la longitud total de secuencia (input tokens + tokens generados). La memoria del KV cache es aproximadamente 2 bytes por parámetro por token en FP16. Por ejemplo, Llama 3 8B usa ~128 MB por 1K tokens por secuencia; Llama 3 70B usa ~1.1 GB por 1K tokens por secuencia. Cálculo: 2 × num_layers × num_kv_heads × head_dim × 2_bytes × sequence_length.
• --gpu-memory-utilization: VRAM reservada después de cargar los pesos del modelo. El resto se asigna al KV cache.

Para contextos de 32K+, lanza más GPUs o cuantización agresiva al problema. Un modelo 70B con 32K de contexto sin cuantización exige 4× A100 80GB.

Estrategias de scheduling de requests

Procedimientos de warm-up

Las instancias en frío sufren alta latencia por la compilación JIT de kernels CUDA. Siempre dispara requests de calentamiento antes del tráfico de producción:

python -c "
import openai
client = openai.OpenAI(base_url='http://localhost:8000/v1', api_key='dummy')
for _ in range(10):
    client.chat.completions.create(
        model='meta-llama/Meta-Llama-3-8B-Instruct',
        messages=[{'role': 'user', 'content': 'Hello'}],
        max_tokens=50
    )
"

Excluye las primeras 5–10 requests de los SLIs. Yo las etiqueto con warmup: true en mis scripts de load testing.

Monitoreo y observabilidad con consultas PromQL

Monitorea cuatro SLIs core en producción: TTFT, TPOT, throughput y profundidad de cola. Prometheus los recolecta, Grafana los visualiza.

Métricas clave de Prometheus

vLLM expone métricas en /metrics. Alertas esenciales para serving:

SLIs core: TTFT, TPOT, y Throughput

TTFT (Time to First Token): Latencia desde el envío de la request hasta el primer token. Apunta a p99 < 300ms para chat. NVIDIA considera TTFT la métrica principal de latencia percibida.

TPOT (Time Per Output Token): Latencia entre tokens durante streaming. Apunta a p99 < 80ms para lectura cómoda.

Throughput: Tokens totales por segundo entre todas las requests concurrentes. Es tu métrica de eficiencia de costo.

Consultas PromQL esenciales

Importa el dashboard oficial de vLLM para Grafana (ID: 25043), luego agrega estos paneles:

TTFT p99 (ventana de 5 minutos):

histogram_quantile(0.99, rate(vllm_time_to_first_token_seconds_bucket[5m]))

TPOT p99 (ventana de 5 minutos):

histogram_quantile(0.99, rate(vllm_time_per_output_token_seconds_bucket[5m]))

Profundidad de cola (requests en espera):

vllm_num_requests_waiting

Requests activos por pod:

vllm_num_requests_running

Utilización de memoria GPU (%):

(nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes) * 100

Consumo de energía GPU (Watts):

nvidia_gpu_power_usage_milliwatts / 1000

Throughput (tokens generados por segundo):

rate(vllm_generation_tokens_total[5m])

Trigger de escalado HPA (promedio de requests en ejecución):

avg(vllm_num_requests_running) by (pod)

Mantengo una fila de cuatro paneles de un vistazo: TTFT, TPOT, profundidad de cola y utilización GPU. Si alguno se pone rojo, algo falló.

Continúa en Parte 5: Comparación, Checklist y Solución de Problemas donde comparamos vLLM vs Ollama y revisamos el checklist de producción.