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

Probado con vLLM 0.31.0 · 0.32.0 · CPU arm64 · Qwen3-0.6B · verificado 2026-10-27

Actualizado: 2026-10-27

vLLM^[1] es el servidor de referencia para servir modelos de lenguaje abiertos cuando importa el rendimiento agregado: gestiona la caché KV con PagedAttention, agrupa las peticiones de forma continua y expone una API compatible con OpenAI. El 27 de octubre de 2026 la última versión es la 0.32.0, publicada el 18 de octubre. Desde la 0.11.0, de octubre de 2025, el motor V1 es el único del proyecto, y la caché de prefijos viene activada por defecto desde la 0.8.0. Esta guía reúne lo que necesitas para desplegarlo, lo que ha cambiado en 2025 y 2026 y cuándo conviene otra herramienta. Está disponible en inglés.

Puntos clave

• PagedAttention divide la caché KV en bloques de tamaño fijo y reduce el desperdicio de memoria por debajo del 4 %, frente al 60 % a 80 % de los sistemas anteriores, según el anuncio del proyecto.
• Desde la 0.11.0 (2 de octubre de 2025) V1 es el único motor, y la caché de prefijos y el prellenado por trozos vienen activados por defecto.
• El servidor se arranca con vllm serve <modelo> y escucha en el puerto 8000 con rutas /v1 compatibles con los clientes de OpenAI.
• La cuantización depende del hardware: AWQ y GPTQ funcionan desde Turing, FP8 W8A8 necesita Ada, Hopper o una GPU AMD, y en CPU Arm solo hay INT8.
• Text Generation Inference de Hugging Face está en modo mantenimiento y su repositorio está archivado; el propio proyecto recomienda vLLM o SGLang.

¿Por qué PagedAttention cambia el rendimiento?

Los servidores de inferencia anteriores reservaban para cada petición un bloque contiguo de memoria para la caché KV, dimensionado para la longitud máxima. Con peticiones de longitudes distintas, buena parte de esa memoria quedaba reservada y sin usar. PagedAttention trocea la caché en bloques pequeños y los asigna con una tabla de páginas, igual que un sistema operativo gestiona la RAM. El equipo de UC Berkeley lo describió en el artículo de PagedAttention^[2], que midió entre 2 y 4 veces más rendimiento que FasterTransformer y Orca con la misma latencia.

Sobre esa base funciona el batching continuo: las peticiones entran y salen del lote en cada paso, sin esperar a que termine el grupo anterior. El anuncio original de vLLM^[3] cifró el resultado en hasta 24 veces más rendimiento que Hugging Face Transformers. Esas cifras son del proyecto, de 2023 y en GPU; la ventaja depende de cuántas peticiones simultáneas recibas.

¿Qué ha cambiado en vLLM en 2025 y 2026?

El cambio de fondo es el motor V1, que sustituyó al original en cuatro pasos documentados en las notas de cada versión:

La caché de prefijos automática es la mejora con más efecto en aplicaciones reales. Cuando dos o más peticiones comparten el comienzo del prompt, como el mensaje de sistema de un asistente o el contexto común de un RAG, vLLM reutiliza los bloques KV ya calculados. En una prueba del proyecto llm-d^[4], con un prompt de unos 10.000 tokens contra Qwen3-32B, el tiempo hasta el primer token bajó de 4,3 s a 0,6 s la segunda vez.

El resto de funciones avanzadas también ha madurado:

• Decodificación especulativa: un método borrador propone tokens y el modelo principal los verifica. La documentación^[5] ofrece EAGLE, MTP, n-gramas, decodificación por sufijos y modelos borrador, y valida que el muestreo voraz da el mismo resultado con y sin ella.
• Multi-LoRA: un modelo base con más de un adaptador LoRA cargados a la vez, hasta el límite de --max-loras; cada petición elige el suyo por nombre de modelo, según la guía de adaptadores LoRA^[6].
• Salida estructurada: JSON contra un esquema, expresiones regulares o gramáticas con los motores xgrammar o guidance, a través del campo structured_outputs que sustituyó a los guided_* en la 0.12.0, según la documentación de salidas estructuradas^[7].
• Hardware: además de NVIDIA, la guía de instalación^[8] lista AMD ROCm, Intel XPU, Apple Silicon a través de vLLM-Metal y CPU x86, Arm y IBM Z, con TPU, Gaudi y otros mediante plugins.

Cómo se instala y se arranca vLLM

vLLM se instala como paquete de Python o se ejecuta desde su imagen Docker, y el servidor se arranca con un único comando. La guía de inicio rápido^[9] recomienda uv para instalarlo con el backend de PyTorch adecuado a tu GPU:

uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen3-8B \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 32768

El servidor queda en http://localhost:8000/v1 y cualquier cliente de la API de OpenAI funciona cambiando la URL base. Para Docker, la imagen vllm/vllm-openai tiene como punto de entrada el mismo vllm serve, así que solo le pasas el modelo y las opciones. Estos son los parámetros que más pesan:

• --tensor-parallel-size: cuántas GPU del nodo reparten el modelo; por defecto, 1.
• --gpu-memory-utilization: la fracción de memoria de la GPU que vLLM reserva para pesos y caché KV; por defecto, 0,92.
• --max-model-len: la longitud máxima de contexto; si no la indicas, vLLM toma la del modelo y reserva caché para ella.
• --enable-prefix-caching: ya viene activada; --no-enable-prefix-caching la desactiva si necesitas medir sin ella.

No tenemos GPU en el equipo de pruebas, así que el comando anterior no lo hemos ejecutado. Sí ejecutamos el 27 de octubre de 2026 la imagen CPU vllm/vllm-openai-cpu en una CPU arm64 de 18 núcleos, con Qwen3-0.6B y --enforce-eager. La 0.32.0 arrancó, informó de enable_prefix_caching=True y enable_chunked_prefill=True, y su primera petición tumbó el motor con RuntimeError: Boolean value of Tensor with more than one value is ambiguous. La 0.31.0, con la misma orden, respondió sin errores en /v1/chat/completions.

Con la 0.31.0 medimos la caché de prefijos con tres preguntas distintas detrás del mismo mensaje de sistema de 3.918 tokens y max_tokens a 1. La primera petición tardó 13,63 s, y las dos siguientes 1,16 s y 1,02 s:

Al terminar, la métrica vllm:prefix_cache_hits_total marcaba 7.680 tokens reutilizados de los 11.770 consultados. Las dos peticiones repetidas solo tuvieron que calcular los tokens de la pregunta.

Cuantización y paralelismo según el hardware

La cuantización reduce la memoria de los pesos y, con ella, deja más sitio a la caché KV, pero cada formato funciona solo en cierto hardware. La tabla de compatibilidad de la documentación^[10] resume los formatos más usados así:

En Ampere, FP8 solo funciona a través de los kernels Marlin, que cuantizan los pesos pero no las activaciones. La memoria de los pesos es el número de parámetros por los bytes de cada uno. Un modelo de 70.000 millones de parámetros ocupa unos 140 GB en BF16 y unos 35 GB en 4 bits, antes de contar la caché KV.

El paralelismo de tensores reparte cada capa entre las GPU de un nodo y es la primera opción cuando el modelo no cabe en una. El paralelismo de pipeline reparte las capas entre nodos y añade la latencia de la red a cada paso, así que se reserva para cuando un nodo no basta.

¿Y en una CPU sin GPU?

vLLM funciona en CPU, pero en una CPU arm64 un servidor como llama.cpp con pesos cuantizados le saca mucha ventaja. Lo medimos en vLLM en una CPU ARM frente a llama.cpp, con Qwen3-1.7B en Docker el 28 de septiembre de 2026 y vLLM 0.30.0. llama.cpp en Q8_0 generó 72,7 tokens/s con una petición, 7,2 veces lo que dio vLLM en BF16, y con 8 peticiones a la vez seguía 3,5 veces por delante:

vLLM escaló casi en línea recta de 1 a 8 peticiones, que es lo que promete su planificador, pero partía de 9,9 tokens/s. En CPU, vLLM tiene sentido para probar el mismo servidor que usarás con GPU; para servir de verdad sin GPU, la guía de cómo instalar llama.cpp es mejor punto de partida.

Observabilidad: qué métricas vigilar

vLLM publica métricas de Prometheus en /metrics, en el mismo puerto que la API. Estas son las que conviene tener en un panel desde el primer día, con los nombres que expuso la 0.31.0 en nuestra prueba:

• vllm:num_requests_running y vllm:num_requests_waiting: peticiones en curso y en cola.
• vllm:kv_cache_usage_perc: ocupación de la caché KV.
• vllm:time_to_first_token_seconds: histograma del tiempo hasta el primer token.
• vllm:e2e_request_latency_seconds: histograma de la latencia completa de cada petición.
• vllm:prefix_cache_hits_total y vllm:prefix_cache_queries_total: su cociente es la tasa de acierto de la caché de prefijos.

Si la cola crece de forma sostenida con la caché KV cerca del 100 %, el límite es la capacidad: añade réplicas o una GPU con más memoria. Para seguir costes y calidad de las respuestas, conecta estas métricas con la observabilidad de LLM con trazas.

vLLM frente a SGLang, TensorRT-LLM y TGI

La oferta de servidores ha cambiado en 2026, y la principal novedad es la salida de Text Generation Inference. Hugging Face lo puso en modo mantenimiento, archivó su repositorio^[11] y recomienda en su README usar vLLM o SGLang. Su última versión es la 3.3.7, de diciembre de 2025.

SGLang es la alternativa abierta más cercana y destaca en cargas con mucho prefijo compartido. Su versión 0.5.22 es del 16 de octubre de 2026. TensorRT-LLM apura el hardware NVIDIA a cambio de una compilación por modelo más compleja, y su rama 1.4 está en versión candidata. llama.cpp y Ollama no compiten en rendimiento agregado sino en sencillez de despliegue. Son la opción para un portátil, una CPU o un prototipo, como explica la guía de cómo instalar Ollama.

¿Cuándo compensa servir tu propio modelo con vLLM?

Servir con vLLM compensa cuando tienes tráfico concurrente sostenido, un modelo abierto que cubre tu caso y alguien que pueda operarlo. El coste se calcula con tres cifras: horas de GPU al mes, tokens servidos en esas horas medidos con tu carga y horas de ingeniería de operación. Compáralo con la tarifa por token de la API que sustituirías; no hay un umbral universal, porque depende del modelo, de la GPU y de cuánto aprovechas la caché de prefijos.

El error habitual es tratar vLLM como un binario que se enciende y se olvida. Requiere dimensionar el contexto máximo, elegir la cuantización según la GPU, decidir réplicas y vigilar la cola. Si además necesitas adaptar el modelo, LoRA y QLoRA producen adaptadores que vLLM sirve con multi-LoRA sobre un único modelo base, la arquitectura que describimos en modelos de pesos abiertos en empresa.

Preguntas frecuentes

¿Tengo que cambiar el código de mi aplicación para pasar de la API de OpenAI a vLLM?

No. vllm serve expone en el puerto 8000 rutas /v1 compatibles con la API de OpenAI, como /v1/chat/completions y /v1/models. Cualquier SDK de OpenAI funciona cambiando la URL base y el nombre del modelo, y pasando una clave ficticia si el servidor no exige autenticación.

¿Hay que activar la caché de prefijos?

No desde la 0.8.0, de marzo de 2025: viene activada por defecto y la 0.31.0 la mostró como enable_prefix_caching=True al arrancar. En nuestra prueba en CPU, la segunda petición con el mismo mensaje de sistema de 3.918 tokens tardó 1,16 s, frente a los 13,63 s de la primera. Para desactivarla, usa --no-enable-prefix-caching.

¿Qué fue del artículo «vLLM en 2025»?

Su contenido, la caché de prefijos, la decodificación especulativa, multi-LoRA y la comparación con otros servidores, está actualizado en esta guía. El artículo de vLLM en 2025 se mantiene como fotografía de aquel momento, cuando el motor V1 acababa de llegar.

Conclusión

vLLM sigue siendo la opción más práctica para servir modelos abiertos en GPU con tráfico concurrente. PagedAttention y el batching continuo exprimen la memoria de la tarjeta, el motor V1 trae la caché de prefijos activada y la API compatible con OpenAI evita cambiar la aplicación. Con TGI archivado, su alternativa abierta directa es SGLang. En CPU funciona, pero llama.cpp con pesos cuantizados rinde bastante más, como mostró nuestra medida en arm64.

Fuentes: [1] Kwon y otros, Efficient Memory Management for Large Language Model Serving with PagedAttention^[2], [2] vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention^[3], [3] Notas de vLLM 0.11.0^[12], [4] Documentación de cuantización de vLLM^[10], [5] llm-d, KV-Cache Wins You Can See^[4], [6] Repositorio de Text Generation Inference^[11].

Fuentes

1. vLLM
2. artículo de PagedAttention
3. anuncio original de vLLM
4. prueba del proyecto llm-d
5. documentación
6. guía de adaptadores LoRA
7. documentación de salidas estructuradas
8. guía de instalación
9. guía de inicio rápido
10. tabla de compatibilidad de la documentación
11. repositorio
12. Notas de vLLM 0.11.0