vLLM: cómo desplegar LLMs open source en producción con máxima throughput (2026)

¿Qué es vLLM?

vLLM es un motor de inferencia de LLMs de alto rendimiento, desarrollado originalmente como colaboración entre UC Berkeley y University of Chicago. Es el estándar de facto para servir modelos open source en producción, con soporte para PagedAttention, continuous batching, cuantización y API compatible con OpenAI.

A diferencia de Ollama (optimizado para uso local single-user), vLLM está diseñado para servir múltiples usuarios concurrentes con la máxima throughput posible. Mantiene la GPU al 85-92% de utilización bajo carga concurrente, frente al 15-30% típico de Ollama en el mismo escenario.

¿Qué problema resuelve vLLM?

Desplegar un LLM en producción tiene tres retos principales:

• Memoria: El KV cache de un LLM consume VRAM masiva. Un modelo de 70B en FP16 necesita ~140GB solo de pesos, más varios GB de KV cache por request concurrente
• Throughput: Servir múltiples requests simultáneos sin que la GPU se quede idle esperando
• Latencia: Minimizar el time-to-first-token (TTFT) para experiencias de chat fluidas

vLLM resuelve esto con tres innovaciones clave:

1. PagedAttention: Gestiona el KV cache como páginas de memoria virtual, eliminando fragmentación y permitiendo sharing de prefijos
2. Continuous batching: En cada iteración, saca requests completadas y mete nuevas, manteniendo la GPU siempre activa
3. Prefix caching: Cachea el KV cache de system prompts comunes para que requests repetidos no recomputen

Características principales

1. PagedAttention

La innovación central de vLLM. En lugar de reservar memoria contigua para el KV cache de cada secuencia (que causa fragmentación y desperdicio), PagedAttention divide el KV cache en bloques fijos (pages) que se asignan dinámicamente. Esto reduce el desperdicio de memoria de un 60-80% típico a menos del 4%.

Además, el mecanismo Copy-on-Write permite que múltiples secuencias que comparten un prefijo (como beam search o sampling paralelo) reutilicen los mismos bloques físicos de KV cache, reduciendo el uso de memoria hasta un 55%.

2. Continuous Batching

En el batching tradicional (static batching), todos los requests del batch deben completarse antes de admitir nuevos. vLLM elimina esta restricción: en cada step de decodificación, puede:

• Sacar requests que terminaron
• Meter nuevos requests en cola
• Continuar generando tokens para los requests activos

Resultado: la GPU se mantiene al 85-92% de utilización bajo carga concurrente.

3. Automatic Prefix Caching (APC)

Si múltiples requests comparten el mismo system prompt, APC cachea el KV cache del prefijo común. El primer request lo computa, los siguientes lo reutilizan instantáneamente. Para un system prompt de 2000 tokens con 100 requests/segundo, esto ahorra recomputar 200K tokens/segundo.

vllm serve modelo --enable-prefix-caching

4. Cuantización

vLLM soporta múltiples formatos de cuantización para reducir VRAM y aumentar throughput:

Método	Bits	VRAM 70B	Calidad	Soporte vLLM
FP16 (baseline)	16	~140GB	100%	Default
FP8 (W8A8)	8	~70GB	99.5%	Sí
AWQ (W4)	4	~35GB	98.5%	Sí
GPTQ (W4)	4	~35GB	98.0%	Sí
GGUF (Q4_K_M)	4	~35GB	97.5%	Limitado

Para servir un modelo AWQ cuantizado:

vllm serve TheBloke/Llama-3.1-70B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

5. Quantized KV Cache

Además de cuantizar los pesos del modelo, vLLM puede cuantizar el KV cache a FP8, reduciendo aún más el consumo de VRAM y permitiendo contextos más largos:

vllm serve modelo --kv-cache-dtype fp8_e4m3

6. Speculative Decoding

vLLM soporta speculative decoding, donde un modelo pequeño genera borradores que un modelo grande valida en paralelo. Esto puede reducir la latencia de generación en un 2-3x.

7. Multi-GPU Tensor Parallelism

Para modelos que no caben en una sola GPU:

vllm serve modelo --tensor-parallel-size 4

Distribuye los pesos del modelo across 4 GPUs. vLLM también soporta pipeline parallelism y expert parallelism para modelos MoE como DeepSeek V4.

8. API OpenAI-compatible

vLLM sirve un endpoint compatible con la API de OpenAI. Cualquier cliente que funcione con OpenAI funciona con vLLM:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="dummy"
)

response = client.chat.completions.create(
    model="qwen/Qwen2.5-72B-Instruct",
    messages=[{"role": "user", "content": "Hola, ¿qué eres?"}]
)

9. Modelos soportados

vLLM soporta prácticamente cualquier modelo de Hugging Face:

• Qwen: Qwen3, Qwen3-Coder, Qwen2.5
• Llama: Llama 4, Llama 3.3, Llama 3.1
• DeepSeek: DeepSeek V4, DeepSeek R1
• GLM: GLM-5.2, GLM-5
• Mistral: Mistral Large, Mixtral
• MiniMax: MiniMax M3
• Kimi: Kimi K2.7
• Gemma: Gemma 3
• Y muchos más (ver lista completa en la documentación)

10. Production Stack con Kubernetes

vLLM ofrece un production stack oficial para Kubernetes con:

• Helm charts para deployment
• Router con model-aware y prefix-aware routing
• Autoscaling basado en métricas de vLLM (QPS, TTFT, requests pendientes)
• Observabilidad con Grafana dashboards
• Soporte para múltiples modelos en el mismo cluster
• KV cache offloading con LMCache
• Fault tolerance automática

Instalación de vLLM

Método 1: pip (recomendado para empezar)

pip install vllm

Para la versión más reciente con fixes no publicados:

uv pip install -U vllm \
  --torch-backend=auto \
  --extra-index-url https://wheels.vllm.ai/nightly

Método 2: Docker (recomendado para producción)

docker run --runtime nvidia --gpus all \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-72B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Método 3: Desde el código

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

Método 4: Production Stack con Kubernetes

# Instalar Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Añadir repo de vLLM
helm repo add vllm https://vllm-project.github.io/production-stack

# Deploy minimal
helm install vllm vllm/vllm-stack \
  -f tutorials/assets/values-01-minimal-example.yaml

El archivo values.yaml para configurar tu modelo:

servingEngineSpec:
  runtimeClassName: ""
  modelSpec:
  - name: "qwen-72b"
    repository: "vllm/vllm-openai"
    tag: "latest"
    modelURL: "Qwen/Qwen2.5-72B-Instruct"
    replicaCount: 2
    requestCPU: 6
    requestMemory: "16Gi"
    requestGPU: 1
    pvcStorage: "100Gi"

Servir un modelo — paso a paso

Paso 1: Verificar GPU

nvidia-smi
# Verifica que tienes GPU(s) con suficiente VRAM

Paso 2: Iniciar el servidor

vllm serve Qwen/Qwen2.5-14B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --disable-log-requests

Paso 3: Verificar que funciona

curl http://localhost:8000/v1/models

Paso 4: Hacer un chat completion

curl -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-14B-Instruct",
    "messages": [{"role": "user", "content": "Escribe una función de quicksort en Python"}],
    "max_tokens": 500,
    "temperature": 0.7
  }'

Paso 5: Probar con el cliente de OpenAI

pip install openai

python -c "
from openai import OpenAI
client = OpenAI(base_url='http://localhost:8000/v1', api_key='dummy')
r = client.chat.completions.create(
    model='Qwen/Qwen2.5-14B-Instruct',
    messages=[{'role':'user','content':'Hola'}]
)
print(r.choices[0].message.content)
"

Configuración para producción

Parámetros clave del servidor

Parámetro	Para qué	Recomendado
--tensor-parallel-size	Número de GPUs para tensor parallel	1-4 según VRAM
--max-model-len	Longitud máxima de contexto	32768 o 131072
--gpu-memory-utilization	Fracción de VRAM a usar	0.90
--max-num-seqs	Requests concurrentes máximos	256 (según load test)
--enable-prefix-caching	Cachear prefijos comunes	Sí (esencial con system prompts)
--quantization	Método de cuantización	awq, gptq o fp8
--kv-cache-dtype	Cuantizar KV cache	fp8_e4m3
--disable-log-requests	No loguear cada request	Sí en producción

Comando completo para producción

vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ \
  --host 0.0.0.0 \
  --port 8000 \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 256 \
  --enable-prefix-caching \
  --kv-cache-dtype fp8_e4m3 \
  --disable-log-requests \
  --dtype auto

Integración con otras herramientas

Conectar con Open WebUI

Open WebUI puede conectarse a vLLM como si fuera un endpoint OpenAI-compatible:

1. Ve a Settings → Connections
2. Añade una conexión OpenAI API
3. Base URL: http://tu-servidor-vllm:8000/v1
4. API Key: cualquier string (vLLM no autentica por defecto)
5. Guarda y refresca

Los modelos de vLLM aparecerán en el selector de Open WebUI.

Conectar con OpenCode / MiMo Code

OpenCode y MiMo Code pueden usar vLLM como proveedor OpenAI-compatible:

# En OpenCode: /connect → Custom Provider
# Base URL: http://tu-servidor-vllm:8000/v1
# Model: Qwen/Qwen2.5-72B-Instruct
# API Key: dummy

Conectar con OpenRouter

Si quieres exponer tu vLLM a través de OpenRouter, puedes configurar vLLM como un endpoint custom. Esto es útil para que otros servicios accedan a tus modelos self-hosted a través de una API unificada.

Conectar con Claude Code

Claude Code soporta endpoints OpenAI-compatible vía su configuración de proveedores custom. Puedes usar vLLM para servir modelos más baratos y Claude Code para tareas que requieran Claude.

Conectar con LM Studio / Jan

Para desarrollo local sin GPU potente, usa LM Studio o Jan en tu laptop. Para producción con GPUs dedicadas, usa vLLM.

vLLM vs Ollama vs SGLang vs TGI

Característica	vLLM	Ollama	SGLang	TGI
Uso principal	Producción multi-user	Local single-user	Producción + structured gen	Producción (legacy)
Throughput	Muy alta	Baja (sin batching)	Muy alta	Alta
GPU utilization	85-92%	15-30%	85-92%	70-80%
PagedAttention	Sí (inventó el concepto)	No	Sí	No
Continuous batching	Sí	No	Sí	Sí
Prefix caching	Sí	No	Sí	Sí
API OpenAI-compatible	Sí	Sí	Sí	Sí
Kubernetes	Production stack oficial	No	Comunidad	Docker
Facilidad de setup	Media	Muy fácil	Media	Media
Estado en 2026	Estándar de facto	Activo (local)	Alternativa fuerte	En desuso

Requisitos de hardware

Modelo	FP16 VRAM	AWQ/GPTQ VRAM	FP8 VRAM
Qwen 14B	~28GB (1×A10G)	~8GB (1×T4)	~14GB (1×T4)
Qwen 72B	~140GB (2×A100)	~35GB (1×A100)	~70GB (1×A100)
Llama 70B	~140GB (2×A100)	~35GB (1×A100)	~70GB (1×A100)
DeepSeek V4 (MoE)	Multi-GPU (4-8×H100)	~4×A100	~2-4×H100
GLM-5.2	~140GB (2×A100)	~35GB (1×A100)	~70GB (1×A100)

Deployment en la nube

AWS EKS

# Crear cluster EKS con nodos GPU
eksctl create cluster --name vllm-cluster \
  --node-type g5.12xlarge \
  --nodes 2

# Instalar vLLM production stack
helm install vllm vllm/vllm-stack -f values.yaml

Google GCP GKE

# Crear cluster GKE con nodos L4
gcloud container clusters create vllm-cluster \
  --machine-type g2-standard-12 \
  --num-nodes 2

Self-hosted con Docker Compose

version: "3.8"
services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    volumes:
      - vllm-cache:/root/.cache/huggingface
    ports:
      - "8000:8000"
    ipc: host
    command:
      - --model=Qwen/Qwen2.5-14B-Instruct
      - --max-model-len=32768
      - --gpu-memory-utilization=0.90
      - --enable-prefix-caching
      - --disable-log-requests
    restart: unless-stopped

volumes:
  vllm-cache:

Mejores prácticas para producción

1. Usa cuantización

Para producción, AWQ o FP8 ofrecen la mejor relación calidad/VRAM. Un 70B en AWQ cabe en una sola A100 80GB vs 2×A100 en FP16.

2. Activa prefix caching

Si tienes system prompts compartidos (chatbots, asistentes), prefix caching es esencial. Reduce el TTFT drásticamente.

3. Configura max-num-seqs según load test

El valor por defecto puede no ser óptimo para tu hardware. Haz load testing con tu tráfico real y ajusta.

4. Usa Docker en producción

Docker aísla dependencias y facilita actualizaciones. La imagen oficial vllm/vllm-openai está optimizada.

5. Monitoriza métricas

vLLM expone métricas Prometheus en /metrics:

• QPS (queries por segundo)
• TTFT (time-to-first-token)
• Requests pendientes/running/finished
• Uptime
• GPU utilization

6. Configura health checks

# Health check
curl http://localhost:8000/health

# Kubernetes probe
livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 300
  periodSeconds: 10

7. Usa --ipc=host en Docker

vLLM usa shared memory para comunicación inter-GPU. Sin --ipc=host, puede haber errores de OOM en shared memory.

Casos de uso

1. Chatbot privado para tu empresa

Despliega Qwen 72B en AWQ con vLLM, conecta Open WebUI como frontend, y toda tu empresa tiene un ChatGPT privado sin enviar datos a terceros.

2. API de inferencia para tu app

vLLM como backend OpenAI-compatible para tu aplicación. Tus developers usan el mismo SDK de OpenAI pero apuntando a tu servidor.

3. Coding agent self-hosted

Sirve Qwen3-Coder o DeepSeek Coder con vLLM y conéctalo a OpenCode/MiMo o Claude Code para tener un agente de programación self-hosted.

4. Multi-modelo en Kubernetes

Con vLLM Production Stack, despliega varios modelos en el mismo cluster con routing inteligente. El router dirige cada request al modelo adecuado.

5. Inferencia económica con GLM-5.2

Sirve GLM-5.2 con vLLM en AWQ para obtener capacidad similar a Claude Opus a una fracción del coste, con control total de datos.

Solución de problemas

OOM (Out of Memory)

• Usa cuantización (AWQ, GPTQ o FP8)
• Reduce --max-model-len
• Reduce --gpu-memory-utilization a 0.85
• Reduce --max-num-seqs
• Usa --kv-cache-dtype fp8_e4m3

El modelo no carga

• Verifica que el nombre del modelo sea correcto en Hugging Face
• Comprueba que tienes suficiente VRAM
• Para modelos gated (como Llama), configura HF_TOKEN
• Revisa que --tensor-parallel-size sea compatible con el modelo

Latencia alta

• Activa --enable-prefix-caching
• Usa speculative decoding si aplica
• Reduce --max-num-seqs para menos contención
• Verifica que estás usando Flash Attention (--enforce-eager desactivado)

Error de shared memory en Docker

docker run --shm-size 10g ... # o
docker run --ipc=host ...

Problemas con tensor parallelism

• El TP size debe dividir uniformemente el número de attention heads
• Algunos modelos cuantizados solo funcionan con TP sizes específicos
• Verifica que todas las GPUs sean del mismo tipo

vLLM vs TensorRT-LLM

TensorRT-LLM es la alternativa de NVIDIA para inferencia de LLMs. Comparación rápida:

Aspecto	vLLM	TensorRT-LLM
Licencia	Apache 2.0	Apache 2.0 (NVIDIA)
Hardware	NVIDIA, AMD, Intel, CPU	Solo NVIDIA
Facilidad	Fácil (pip install)	Complejo (build engines)
Performance	Muy alta	Ligeramente superior en H100
Modelos	Cualquier HF model	Requiere build por modelo
Comunidad	Muy activa	Moderada
Mejor para	La mayoría de casos	Máximo performance en H100

Para la mayoría de deployments, vLLM es la mejor elección por su facilidad de uso, soporte multi-hardware y comunidad activa. TensorRT-LLM solo vale la pena si necesitas el último 5-10% de performance en H100 y tienes tiempo para optimizar engines.

Conclusión

vLLM es el estándar de facto para servir LLMs open source en producción en 2026. Si estás construyendo un producto con IA y necesitas servir modelos self-hosted a múltiples usuarios, vLLM es la opción más probada, flexible y performante.

Para un stack completo de IA self-hosted: vLLM como motor de inferencia, Open WebUI como frontend web, OpenCode/MiMo o Claude Code para coding, OpenRouter para modelos cloud como fallback, y Ollama para desarrollo local en tu laptop.

Si necesitas máxima economía, sirve GLM-5.2 en AWQ con vLLM: capacidad similar a Claude Opus a 1/5 del coste, con control total de tus datos.