La diferencia entre un LLM que corre bien en tu laptop y uno que sirve miles de requests por segundo sin morir de OOM se llama vLLM, y entender por qué requiere entender un problema de memoria específico.
Cuando un LLM genera texto token por token, mantiene un "KV cache" (key-value cache) por cada request activo para no recalcular la atención sobre tokens ya procesados. Los motores de inferencia ingenuos reservan memoria contigua para el tamaño máximo posible de este cache por cada request, lo cual desperdicia enormes cantidades de VRAM cuando las secuencias reales son más cortas que el máximo — un problema análogo a fragmentación de memoria en sistemas operativos.
vLLM, desarrollado originalmente en UC Berkeley, resuelve esto con PagedAttention: en vez de memoria contigua, divide el KV cache en bloques de tamaño fijo (similar a páginas de memoria virtual) que se asignan dinámicamente según se necesitan. Esto reduce el desperdicio de memoria de hasta 60-80% en implementaciones ingenuas a menos del 4%, lo que se traduce directamente en poder servir muchas más requests concurrentes con el mismo hardware.
El batching tradicional (static batching) espera a que todas las secuencias de un batch terminen antes de procesar el siguiente batch, lo cual desperdicia cómputo cuando algunas secuencias terminan mucho antes que otras (una respuesta corta vs. una respuesta larga en el mismo batch). vLLM implementa continuous batching (también llamado batching iterativo): en cuanto una secuencia termina, su lugar se libera inmediatamente para una nueva request, sin esperar a que el resto del batch termine.
La combinación de PagedAttention más continuous batching es lo que da a vLLM ventajas de throughput de 2x a 24x sobre implementaciones ingenuas en Hugging Face Transformers puro, según el benchmark original del paper y validado repetidamente por la comunidad en cargas de producción reales.
vLLM expone un servidor OpenAI-compatible listo para producción con un solo comando, lo cual simplifica enormemente migrar código que ya usa el SDK de OpenAI apuntando a un endpoint propio.
El flag `--tensor-parallel-size` distribuye el modelo entre múltiples GPUs cuando no cabe en una sola, y `--gpu-memory-utilization` controla qué fracción de VRAM se reserva para el KV cache paginado — subirlo aumenta el número de requests concurrentes que puedes servir a costa de dejar menos margen de seguridad.
vLLM soporta múltiples esquemas de cuantización para producción — AWQ, GPTQ, y FP8 en GPUs que lo soportan nativamente (H100, L40S) — permitiendo servir modelos más grandes en menos VRAM sin la penalización de latencia que tienen algunos formatos de cuantización orientados solo a almacenamiento. Para modelos que exceden una sola GPU, además del paralelismo de tensores (dividir cada capa entre GPUs) soporta paralelismo de pipeline (dividir capas completas entre GPUs), relevante para los modelos MoE más grandes como Mixtral o DeepSeek-V3.
También soporta "prefix caching" — cachear el KV cache de prompts compartidos entre requests (por ejemplo, un system prompt común o contexto RAG repetido) para no recomputar esa parte en cada request, una optimización con impacto directo en costo cuando muchas requests comparten contexto inicial.
Text Generation Inference (TGI) de Hugging Face resuelve un problema similar con una filosofía parecida (continuous batching, cuantización), y en varios benchmarks está muy cerca de vLLM en throughput — la elección entre ambos suele depender más de qué tan bien soportan el modelo específico que quieres servir y la integración con el resto de tu stack. TensorRT-LLM de NVIDIA da el mayor rendimiento posible pero requiere compilar el modelo específicamente para la arquitectura de GPU exacta que usarás, con un ciclo de desarrollo más rígido y menos portable.
Frente a Ollama: la diferencia es de propósito. Ollama prioriza simplicidad de desarrollo y bajo tráfico; vLLM prioriza throughput bajo carga concurrente real. Para un servicio de producción con decenas o cientos de usuarios simultáneos, vLLM es virtualmente siempre la opción correcta sobre Ollama.
Para escalado horizontal, vLLM se despliega típicamente detrás de un load balancer con múltiples réplicas, cada una sirviendo el modelo en su propio conjunto de GPUs, coordinado con un sistema de colas (o directamente con el balanceo de carga estándar de Kubernetes) cuando el tráfico supera la capacidad de una sola instancia. La observabilidad se resuelve con las métricas nativas de Prometheus que vLLM expone (throughput, latencia de time-to-first-token, uso de KV cache), críticas para dimensionar correctamente cuántas réplicas necesitas antes de que la latencia se degrade bajo carga real.
En un despliegue reciente sirviendo un modelo de 32B parámetros para un cliente con tráfico de producción constante, migrar de un servidor basado en Transformers puro a vLLM con las mismas dos GPUs A100 multiplicó el throughput sostenible por aproximadamente 6x, eliminando la necesidad de aprovisionar hardware adicional que se había presupuestado inicialmente.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel