vLLM

vLLM es una biblioteca de código abierto para la inferencia y el servicio rápido y eficiente en memoria de grandes modelos de lenguaje. Fue creada en el Sky Computing Lab de UC Berkeley en 2023 por Woosuk Kwon, Zhuohan Li, Siyuan Zhuang y colaboradores, y desde entonces ha sido donada a la PyTorch Foundation para garantizar una gobernanza neutral respecto a los proveedores. El problema central que resuelve es la fragmentación de la memoria de la GPU durante el servicio de LLM: antes de vLLM, los servidores de inferencia desperdiciaban entre el 60 y el 80 % de la memoria caché KV reservada al asignar bloques contiguos por secuencia. El algoritmo PagedAttention de vLLM toma prestada la paginación de memoria virtual de los sistemas operativos para almacenar la caché KV en páginas no contiguas, reduciendo el desperdicio a casi cero y permitiendo muchas más secuencias simultáneas en el mismo hardware.

La biblioteca incluye un servidor de API REST compatible con OpenAI, procesamiento por lotes continuo (continuous batching) a nivel de iteración (no a nivel de solicitud), paralelismo de tensores y canalizaciones (pipeline) para implementaciones multi-GPU y multinodo, decodificación especulativa y soporte nativo para formatos de cuantización que incluyen GPTQ, AWQ, INT8 y FP8. Es compatible con cientos de modelos a través de la integración con HuggingFace Transformers: Llama 3.x, Mistral, Mixtral, Qwen, DeepSeek, Gemma, Phi y modelos de visión y lenguaje como LLaVA y Pixtral. La reescritura de la arquitectura v1 de enero de 2025 separó el programador (scheduler) del bucle de trabajo (worker loop), lo que produjo una estructura interna más limpia y mejores herramientas para perfilar implementaciones en producción. vLLM se ejecuta en hardware NVIDIA, AMD ROCm, Intel Gaudi y AWS Trainium.

Lo que realmente hace vLLM en abril de 2026

El trabajo de vLLM es servir LLM de código abierto a niveles de rendimiento que hagan económicamente viable su implementación en producción. El mecanismo es PagedAttention más el procesamiento por lotes continuo. PagedAttention divide el almacenamiento de la caché KV en "páginas" de tamaño fijo y las administra con una tabla de bloques, eliminando la fragmentación que proviene de preasignar una región de memoria contigua para la longitud máxima posible de cada secuencia. El procesamiento por lotes continuo significa que el motor inserta nuevas solicitudes en un lote activo tan pronto como termina una secuencia, manteniendo alta la utilización de la GPU en lugar de esperar a que se vacíe un lote completo antes de comenzar el siguiente.

El resultado, documentado en el artículo de SOSP 2023, fue un rendimiento hasta 24 veces mayor en comparación con un bucle de servicio básico de HuggingFace Transformers en el mismo hardware. En términos prácticos: una sola A100 de 80 GB que sirve Llama 3.1 8B puede manejar aproximadamente 200 usuarios simultáneos en streaming con una latencia aceptable, mientras que un bucle básico podría saturarse con 10-20.

Iniciar el servidor requiere un solo comando: vllm serve meta-llama/Llama-3.1-8B-Instruct --tensor-parallel-size 1. Luego, el servidor expone los endpoints /v1/chat/completions y /v1/completions que coinciden con la especificación de la API de OpenAI. Cualquier aplicación existente que utilice el cliente de Python de OpenAI puede redirigirse al servidor vLLM cambiando la URL base y la clave de API, sin ningún otro cambio en el código. Los ingenieros de plataformas citan esta compatibilidad como el mayor impulsor de adopción, ya que elimina la barrera de migración desde un prototipo hasta la producción autoalojada.

Más allá del servidor, vLLM expone una API de inferencia fuera de línea para trabajos por lotes. Un equipo de ciencia de datos que procesa 100.000 finalizaciones de clasificación puede cargar un modelo una vez y ejecutar una llamada LLM.generate() en una lista de prompts, logrando un rendimiento de 5 a 10 veces mayor que las llamadas secuenciales a la API. Los equipos de Together AI utilizan esta vía para trabajos de inferencia por lotes a gran escala donde la latencia importa menos que el costo por token.

"Pasamos de servir a unos 20 usuarios simultáneos a más de 200 en el mismo hardware después de cambiar a vLLM. El procesamiento por lotes continuo realmente cambia las reglas del juego para nuestro costo de inferencia". - u/ml_infra_eng, Reddit r/LocalLLaMA, noviembre de 2023

"vLLM es lo que impulsa la mayor parte de la pila de inferencia de Together AI. Solo PagedAttention redujo nuestro uso de memoria caché KV en aproximadamente un 55 % en solicitudes de contexto largo, que es donde nuestros márgenes se veían más reducidos". - Tim Dettmers, equipo de inferencia, blog de ingeniería de Together AI, febrero de 2024

Dónde se sitúa vLLM frente a TGI y SGLang

Los tres motores de inferencia de código abierto más implementados en 2026 son vLLM, HuggingFace TGI y SGLang. Comparten objetivos pero difieren mecánicamente en aspectos que son importantes para cargas de trabajo específicas.

vLLM frente a TGI (Text Generation Inference): HuggingFace TGI tiene un punto de entrada más simple centrado en Docker. La implementación estándar es un solo comando docker run con un ID de modelo. TGI agregó soporte para PagedAttention en su versión v2 en 2024, reduciendo la brecha de rendimiento. Sin embargo, el procesamiento por lotes continuo de vLLM opera con una granularidad más fina: inserta nuevos tokens en el lote activo en cada paso de decodificación, mientras que TGI procesa por lotes a un nivel más grueso en algunas configuraciones. En los benchmarks de la comunidad sobre Llama 3 70B con cuantización de 4 bits (Reddit r/LocalLLaMA, noviembre de 2024), vLLM generalmente logra un rendimiento de tokens de salida entre un 15 y un 25 % mayor que TGI en cargas de trabajo de alta concurrencia. La ventaja de TGI es la integración con HuggingFace Hub, un servidor respaldado por Rust con menor sobrecarga de Python y un proceso de implementación que requiere menos configuración. Para los equipos que ya están inmersos en el ecosistema de HuggingFace, TGI es la primera opción natural. Para los equipos que optimizan el rendimiento bruto a escala, vLLM generalmente gana.

vLLM frente a SGLang: SGLang, del grupo LMSYS, introduce RadixAttention: uso compartido de la caché KV entre solicitudes que comparten un prefijo común. En la práctica, esto significa que un prompt del sistema de 2.000 tokens utilizado por 1.000 usuarios simultáneos se calcula y se almacena en caché una vez, no 1.000 veces. En cargas de trabajo de agentes, conversaciones de múltiples turnos e inferencia por lotes con prefijos compartidos, RadixAttention de SGLang puede reducir el tiempo hasta el primer token (time-to-first-token) entre un 50 y un 80 % en comparación con vLLM. vLLM agregó su propio almacenamiento en caché de prefijos para cerrar esta brecha, pero la implementación de SGLang sigue siendo más madura. Donde vLLM tiene una clara ventaja es en: la amplitud de soporte de modelos (cientos frente a una lista más reducida), las herramientas de paralelismo de canalizaciones multinodo, la cobertura de formatos de cuantización y el tamaño de la comunidad de operaciones de producción a su alrededor. Para cargas de trabajo de IA de agentes específicamente, considere SGLang; para el servicio de propósito general con la máxima compatibilidad de modelos, vLLM sigue siendo la opción predeterminada.

Un tercer competidor, TensorRT-LLM de NVIDIA, compila modelos en gráficos CUDA optimizados y logra un mayor rendimiento máximo en hardware NVIDIA. La contrapartida es operativa: la compilación del modelo TensorRT-LLM tarda entre 30 y 60 minutos por modelo y por tipo de GPU. vLLM carga un modelo desde el disco en menos de un minuto. Para los equipos que ejecutan muchos modelos o iteran con frecuencia, la simplicidad operativa de vLLM gana de manera decisiva. TensorRT-LLM vale el costo de compilación solo cuando se busca exprimir al máximo los tokens por segundo en un modelo fijo a escala. vLLM también se ejecuta en AMD ROCm, Intel Gaudi y AWS Trainium; TensorRT-LLM es exclusivo de NVIDIA.

Cómo es la realidad de la implementación

Una implementación típica en producción implica elegir una instancia de GPU (A10G para modelos más pequeños, A100/H100 para 70B+), instalar vLLM a través de pip y ejecutar el comando de servicio. Para un modelo de 70B en 4x A100, el comando agrega --tensor-parallel-size 4. Los pesos del modelo se descargan desde HuggingFace Hub en la primera ejecución y luego se almacenan en caché localmente. El inicio en frío (cold start) en un modelo de 70B tarda entre 3 y 8 minutos, dependiendo de la velocidad de almacenamiento. Para los servicios que necesitan escalar a cero, esta latencia es una limitación real.

Las implementaciones multinodo (paralelismo de canalizaciones en varios servidores) requieren Ray o un backend distribuido personalizado. La configuración del clúster de Ray es donde la mayoría de los equipos informan haber perdido horas. La documentación de vLLM cubre esto adecuadamente, pero los modos de fallo (configuración de red, errores de NCCL, confusión en el panel de control de Ray) no están bien documentados. Los ingenieros que lo han hecho con éxito recomiendan ejecutar primero una configuración de un solo nodo, validar el comportamiento del modelo y solo agregar nodos una vez que la línea base sea estable.

Para los equipos que desean evitar por completo la gestión de la infraestructura, los endpoints administrados basados en vLLM están disponibles en Modal, Replicate y Together AI, cada uno ofreciendo la misma API compatible con OpenAI con precios por token y sin gestión de servidores. La contrapartida es el costo y la residencia de los datos: el autoalojamiento en su propia GPU es más económico a escala y mantiene los datos en las instalaciones (on-premises).

La arquitectura v1 de enero de 2025 trajo una estructura interna más limpia, pero también introdujo algunos cambios importantes (breaking changes) en el registro de modelos personalizados. Los equipos que ejecutaban capas de atención modificadas o arquitecturas no estándar encontraron fricciones al actualizar desde la versión v0.x. Los mantenedores publicaron una guía de migración, pero los equipos con implementaciones muy personalizadas pasaron días depurando. Dicho esto, para el servicio de modelos estándar, la actualización a v1 fue universalmente positiva en los comentarios de la comunidad.

Para quién está diseñado vLLM

vLLM es un software de infraestructura, no un producto orientado al usuario final. Está diseñado para ingenieros de ML y equipos de plataformas que tienen acceso a hardware de GPU, se sienten cómodos con entornos Python y Linux, y necesitan servir modelos de lenguaje de código abierto a un rendimiento que justifique el costo de la infraestructura.

Los casos de uso más adecuados: una empresa que construye una API de LLM privada para uso interno (los datos permanecen en las instalaciones, sin dependencia de proveedores); un equipo que encontró prohibitivos los costos de inferencia en las API comerciales y desea ejecutar un modelo ajustado (fine-tuned) más pequeño en su lugar; un laboratorio de investigación que necesita ejecutar inferencias sobre grandes lotes de texto para experimentos; una startup que construye un producto sobre modelos de código abierto donde el margen requiere autoalojamiento.

Para los equipos que ya utilizan modelos de código abierto localmente a través de una GUI, combinar vLLM con una interfaz de chat es sencillo. AnythingLLM y frontends similares pueden apuntar a un servidor vLLM local. Para los usuarios que desean una experiencia de modelo local lista para usar sin configuración de servidor, Ollama es el mejor punto de partida. vLLM es la herramienta adecuada una vez que el rendimiento y la concurrencia se convierten en la principal preocupación, no la facilidad de la primera ejecución. Los equipos que implementan a escala comercial con pesos de modelos de código abierto, como aquellos que ya podrían estar ejecutando modelos en arquitecturas de la familia Llama, encontrarán en vLLM la opción de producción más madura.

Lo que no es vLLM

vLLM no se ejecuta de forma nativa en Windows. Los usuarios deben usar WSL2 o Docker, lo que agrega fricción para el desarrollo local. No es una aplicación GUI, una interfaz de chat ni una herramienta de gestión de modelos al estilo de LM Studio. No ajusta (fine-tune) modelos. No proporciona limitación de velocidad, autenticación ni facturación integradas: estos requieren una capa de proxy como LiteLLM. No es un servicio administrado; no existe un "vLLM Cloud" del propio proyecto. Los equipos que necesitan una API de inferencia totalmente administrada sin responsabilidad de infraestructura deberían considerar Replicate o Together AI (que ejecuta vLLM internamente). Para los ingenieros que evalúan si autoalojar o usar una API administrada, vLLM inclina la balanza hacia el autoalojamiento una vez que el tráfico alcanza una escala en la que los costos de las instancias de GPU son más bajos que las tarifas de API por token, generalmente entre 1 y 10 millones de tokens por día, dependiendo del tamaño del modelo y del proveedor de la nube.