Séptimo módulo del Curso de GPU para IA. Hasta aquí todo sirve a un usuario: tú. Pero el bloque de nube que se acerca tiene una pregunta incómoda: ¿qué pasa cuando tu servicio tiene 50 conversaciones a la vez? La respuesta cambia de herramienta, de métrica y de mentalidad. Bienvenido al serving.

La tesis del módulo

Servir a un usuario y servir a cien son problemas distintos. Para uno, optimizas latencia; para cien, throughput. vLLM existe porque una GPU atendiendo de a una petición desperdicia casi toda su capacidad — y llenarla bien es un problema de ingeniería precioso.

El problema: la GPU ociosa

La inferencia de una sola conversación es memory-bound (Módulo 2): los núcleos esperan a la memoria la mayor parte del tiempo. Con un solo usuario, tu GPU carísima trabaja a una fracción de su potencial.

La solución es conocida del glosario: batch — procesar varias peticiones juntas. Leer los pesos una vez y aplicarlos a 20 conversaciones cuesta casi lo mismo que a una. Pero el batching ingenuo (esperar a juntar 20, procesarlas, responder) tiene un defecto fatal con texto generativo: las respuestas terminan en momentos distintos, y todos esperan a la más larga.

Las dos ideas de vLLM

vLLM es el runtime de serving open source más usado, construido sobre dos ideas:

1. Batching continuo — el lote no es fijo: en cada token, las peticiones que terminaron salen y las nuevas entran. La GPU nunca espera y nadie espera de más.

 cliente A ──┐                    peticiones entran y salen
 cliente B ──┤                    del lote en cada token
 cliente C ──┼─────────────────────────► ┌─────────────┐
 cliente D ──┤    batching continuo      │ GPU al 100% │
 cliente E ──┘                           └─────────────┘

2. PagedAttention — el KV cache de cada conversación se guarda en páginas chicas, como la memoria virtual de un sistema operativo, en vez de en bloques contiguos reservados al peor caso. Resultado: cabe mucho más gente en la misma VRAM, sin fragmentación.

Estas dos piezas son el motivo de que un mismo modelo en la misma GPU pase de atender unos pocos usuarios a decenas.

Usarlo

vLLM es Python y su casa es Linux con CUDA (en Windows se usa vía WSL2, y en Mac existe el soporte vLLM-Metal para Apple Silicon, más nuevo). Si nada de eso calza con tu máquina, tranquilo: este módulo es la antesala del bloque de nube, donde el Linux con GPU lo pone el proveedor:

pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct --max-model-len 8192

Dos cosas nuevas respecto al mundo llama.cpp:

El modelo se nombra por su id de Hugging Face y se descarga en formato original (safetensors), no GGUF. vLLM tiene su propio ecosistema de cuantización: AWQ, GPTQ, FP8 — mismos principios del Módulo 4, otra familia de formatos.
La API (puerto 8000) es compatible con OpenAI, igual que Ollama y llama-server: tu mismo cliente de siempre, tercera URL.

Cuidado: al arrancar, vLLM preasigna casi toda la VRAM (por defecto ~90%, ajustable con --gpu-memory-utilization). Verás nvidia-smi lleno con el servidor recién levantado y cero usuarios: no es una fuga, es PagedAttention reservando su cancha. Y --max-model-len acota el contexto máximo por petición — sin él, modelos con contextos enormes pueden no caber ni arrancar.

Latencia vs throughput: elegir qué optimizar

La tabla mental de este módulo:

Métrica	Qué mide	Quién la sufre	Quién la optimiza
Latencia	Cuánto tarda UNA respuesta	El usuario individual	Chat personal, asistentes
Throughput	Tokens totales por segundo del sistema	Tu presupuesto	APIs, procesamiento masivo

El batching mejora el throughput a costa de algo de latencia por usuario: compartes la GPU con el lote. Para un chat personal es mal negocio; para servir una API con decenas de clientes, es EL negocio — throughput es dinero: más usuarios atendidos por la misma GPU arrendada.

El mapa completo de runtimes

Con esto cierras el panorama de las tres herramientas del curso:

	Ollama	llama.cpp	vLLM
Para	Uso personal, desarrollo	Control fino, hardware justo	Servir a muchos
Formato	GGUF (catálogo propio)	GGUF (Hugging Face)	safetensors + AWQ/GPTQ/FP8
Plataforma	Win / Mac / Linux	Win / Mac / Linux	Linux + CUDA
Concurrencia	Baja	Baja–media	Alta (batching continuo)
Filosofía	Simplicidad	Perillas	Throughput

Regla de decisión: desarrolla con Ollama, exprime con llama.cpp, sirve con vLLM. Las tres hablan OpenAI: tu código de agentes no cambia, cambia la URL.

Errores comunes

Usar vLLM para uso personal. Es como arrendar un bus para ir al almacén: la VRAM preasignada y la complejidad no te devuelven nada con un usuario.
Buscar archivos GGUF para vLLM. Ecosistemas distintos: en vLLM el modelo llega por id de Hugging Face en su formato nativo o cuantizado AWQ/GPTQ.
Medir throughput con un cliente. El batching brilla con concurrencia; un solo hilo de prueba te miente sobre la capacidad real.
Asustarse por nvidia-smi al 90%. Es diseño, no fuga. La pregunta correcta no es cuánta VRAM usa, sino cuántos usuarios atiende con ella.

La frase para llevarse

“Con un usuario, la métrica es cuánto espera él; con cien, cuánto desperdicia la GPU. El serving es el arte de que nadie espere mientras nada se desperdicia.”

Qué viene

Módulo 8, cierre del bloque intermedio: más allá del LLM — embeddings, voz e imágenes corriendo en la misma GPU local, y cómo repartir la VRAM cuando todo quiere vivir en ella.

GPU para IA — Módulo 7: vLLM y el serving de producción