vLLM: servir LLM en producción con altísimo throughput

Actualizado: 2026-05-03

vLLM^[1] se ha asentado como la referencia para servir modelos de lenguaje en GPU cuando lo que importa es el rendimiento agregado. Su algoritmo PagedAttention gestiona la caché KV como si fuera memoria paginada del sistema operativo, y esa decisión arquitectónica explica la mayor parte de la diferencia frente a implementaciones ingenuas. Este artículo recoge lo esencial para desplegarlo en producción y, sobre todo, cuándo tiene sentido y cuándo no.

Puntos clave

• PagedAttention elimina la fragmentación de memoria KV y multiplica el número de peticiones simultáneas por tarjeta.
• El batching continuo elimina la espera entre grupos y es la razón principal del salto en throughput bajo carga real.
• La API compatible con OpenAI permite migrar aplicaciones existentes cambiando solo la URL base.
• AWQ ofrece la mejor relación calidad-memoria para Llama y Mistral; FP8 solo compensa en H100.
• El break-even frente a API comercial se sitúa en torno a diez millones de tokens diarios para un modelo mediano.

Por qué PagedAttention cambia las reglas

Los servidores de inferencia tradicionales reservan memoria contigua por petición para guardar la caché de atención. Cuando conviven en la misma GPU peticiones de longitudes muy distintas, esa estrategia provoca una fragmentación enorme: bloques de memoria inutilizados que no pueden cederse a otras peticiones. PagedAttention rompe la caché en bloques pequeños de tamaño fijo y los gestiona con una tabla de páginas, exactamente como hace un kernel con la RAM.

El resultado es que puedes meter muchas más peticiones simultáneas en la misma tarjeta sin aumentar los pesos. Sobre esa base se apila el batching continuo: las peticiones entran y salen del lote en curso sin esperar a que termine el grupo anterior, eliminando los huecos de GPU ociosa que aparecen cuando unas respuestas son cortas y otras largas. En la práctica, la mejora de throughput frente a un servidor ingenuo varía entre 3x y 24x según la mezcla de tráfico —y esa cifra no es marketing, es matemática de ocupación de memoria.

vLLM expone además una API compatible con la de OpenAI, soporta paralelismo de tensores para repartir un modelo entre varias GPU, ofrece cuantización en formatos AWQ, GPTQ, FP8 e INT8, y cubre la familia abierta relevante: Llama, Mistral, Qwen, DeepSeek, Phi y Gemma.

Instalación y primer arranque

El punto de entrada mínimo es un único comando que levanta un servidor HTTP con la API de OpenAI lista para consumir desde cualquier cliente existente:

pip install vllm
python -m vllm.entrypoints.openai.api_server 
  --model meta-llama/Meta-Llama-3-8B-Instruct 
  --tensor-parallel-size 4 
  --gpu-memory-utilization 0.95 
  --max-model-len 32768 
  --quantization awq

El endpoint queda en http://localhost:8000/v1 y cualquier SDK que hable con la API de OpenAI funciona cambiando únicamente la URL base y pasando una clave ficticia. Esto es lo que más acelera la adopción: el código de aplicación no cambia.

Los cuatro parámetros que más mueven la aguja:

• tensor-parallel-size: cuántas GPU reparten el modelo; debe coincidir con las tarjetas físicas del nodo.
• gpu-memory-utilization: entre el 90 % y el 95 %; subirlo más deja sin margen para picos.
• max-model-len: condiciona cuánta caché KV reservas; ampliarlo cuando el tráfico real usa longitudes cortas es regalar memoria.
• quantization: con AWQ o GPTQ, casi siempre una victoria neta en memoria y velocidad.

Cuantización y paralelismo en la práctica

AWQ ofrece la mejor relación calidad-memoria en la mayoría de modelos Llama y Mistral, y los pesos vienen ya pre-cuantizados en Hugging Face, lo que hace el arranque inmediato. GPTQ es equivalente en espíritu pero con otro formato. FP8 solo interesa en H100; en A100 cae a caminos lentos. INT4 comprime mucho pero empieza a degradar el razonamiento en cadenas largas, y eso no siempre se nota en benchmarks cortos.

El paralelismo de tensores se vuelve imprescindible cuando el modelo no cabe en una sola GPU: un Llama 3.1 de 70 B en FP16 necesita cuatro A100 de 80 GB, mientras que con AWQ cabe en dos. El paralelismo de pipeline solo compensa si ya has agotado el tensor parallelism dentro del nodo y necesitas cruzar a otro servidor; la latencia internodo penaliza mucho el tiempo al primer token.

En rendimiento concreto, un Llama 3 de 8 B sobre un A100 de 80 GB da unos 60-80 tokens por segundo en peticiones aisladas, pero con cincuenta conexiones concurrentes el agregado se dispara a 2 000-3 000 tokens por segundo. Ese salto es el regalo de PagedAttention y el batching continuo.

Observabilidad y funciones avanzadas

vLLM expone métricas de Prometheus activando un puerto dedicado. Las cinco que conviene vigilar siempre son:

• Peticiones en curso y en cola.
• Ocupación de la caché KV de GPU.
• Tiempo hasta el primer token.
• Latencia extremo a extremo.

El dashboard oficial de Grafana las cubre. Si la cola crece de forma sostenida, el problema no es el modelo sino la capacidad: toca escalar con réplicas o cambiar a una tarjeta más potente.

De las funciones avanzadas, tres merecen mención especial. Multi-LoRA sirve varios adaptadores sobre el mismo modelo base y conmuta por petición, lo que es muy útil cuando tienes varios fine-tunes pequeños. El decodificado especulativo usa un modelo borrador que propone tokens y el principal los verifica, con aceleraciones realistas de 2x-3x. Y la salida estructurada —vía integración con Outlines— garantiza JSON válido contra un esquema, eliminando una categoría entera de parsers frágiles en la aplicación. Para la observabilidad de tu stack LLM conviene conectar las métricas de vLLM con herramientas especializadas como Langfuse.

vLLM frente a TGI y SGLang

Text Generation Inference de Hugging Face mantiene ingeniería sólida e integración con el ecosistema HF, pero cambió a una licencia restrictiva que complica ciertos despliegues comerciales y en throughput puro se queda algo por detrás. SGLang es fuerte en workloads con mucho prefijo compartido pero su comunidad es aún pequeña. LMDeploy brilla con la familia Intern y cuantización agresiva, pero pierde fuelle fuera de ese nicho.

vLLM ocupa el centro de gravedad: gana en throughput general, mantiene licencia Apache 2.0 y recibe mejoras casi cada semana. Para rendimiento máximo en hardware NVIDIA, TensorRT-LLM puede ofrecer 2x-3x adicional a costa de una complejidad de build muy superior.

Cuándo compensa el self-hosting

Si tu carga llega a varios millones de tokens diarios y controlas el hardware, el self-hosting con vLLM compite con la API comercial antes de lo que la gente suele calcular. El punto de equilibrio en tarifas típicas se sitúa en torno a diez millones de tokens al día para un modelo mediano, una vez contabilizas horas de ingeniería y electricidad. Por encima de ese umbral, el ahorro se vuelve agresivo y la soberanía sobre el modelo empieza a tener valor estratégico.

El principal error es tratar vLLM como un binario que se enciende y se olvida. No lo es: requiere criterio para dimensionar contexto máximo, elegir cuantización, decidir réplicas horizontales y calibrar la utilización de memoria. También exige aceptar sus límites: solo soporta bien NVIDIA (ROCm sigue experimental), el arranque puede tardar minutos cargando los pesos, y algunos modelos menos populares tienen kernels menos optimizados.

Pon métricas desde el primer día, vigila cola y caché KV, y escala por réplicas cuando la cola crezca. Con eso cubres el noventa por ciento de los casos reales. Si necesitas fine-tuning eficiente sobre esos modelos antes de servirlos, LoRA y QLoRA son el complemento natural para reducir el coste de adaptación.

Conclusión

vLLM es la opción más pragmática para servir LLM open en GPU: combina el mayor throughput disponible en Apache 2.0, la API compatible con OpenAI que elimina fricciones de migración, y una comunidad que entrega mejoras semanalmente. El salto de rendimiento que aportan PagedAttention y el batching continuo convierte el mismo hardware en una infraestructura órdenes de magnitud más eficiente bajo carga real.

1. vLLM