Hace dos años, servir modelos de lenguaje en producción era un ejercicio de fragmentación. Cada equipo que llegaba al problema acababa eligiendo entre una docena de opciones (Hugging Face Text Generation Inference, DeepSpeed-MII, FasterTransformer, llama.cpp servers, implementaciones caseras sobre PyTorch). La decisión rara vez era definitiva.

Hoy, aunque alternativas serias persisten, vLLM se ha convertido en el motor por defecto para servir modelos en GPU. Y el crecimiento no ha sido casual: es el resultado de un ritmo de mejora consistente durante dos años.

Este post repasa los cambios importantes en vLLM durante los últimos meses y los enmarca en lo que significan para quien opera el servicio.

Puntos clave

  • El prefix caching automático es la mejora con más impacto. En peticiones que repiten un prefijo largo, el tiempo hasta el primer token puede caer de varios segundos a menos de un segundo, sin cambiar nada en la aplicación.

  • El speculative decoding reduce latencia especialmente en modelos 70B+, pero añade complejidad operativa.

  • El soporte multi-LoRA transforma la economía de servicios multi-tenant: un modelo base compartido + adaptadores por cliente.

  • El soporte multi-GPU sigue siendo más frágil que single-GPU para algunos modelos grandes.

  • El hardware no-NVIDIA (AMD ROCm, Intel Habana) va por detrás en experiencia y madurez.

El momento de madurez

vLLM empezó como un proyecto académico centrado en una idea concreta: PagedAttention, la gestión eficiente de memoria KV durante la inferencia. Ha crecido hasta convertirse en una plataforma con ciclo de releases predecible, API estable y ecosistema de usuarios empresariales. La consolidación se nota en detalles. La documentación es mejor que hace un año, los benchmarks que publica el proyecto son más sinceros y la integración con frameworks de orquestación (Ray, Kubernetes) es de primera clase.

Lo más relevante es técnico: el paper original de PagedAttention[1] ya documentaba una mejora de throughput de 2 a 4 veces frente a sistemas comparables de la época (FasterTransformer, Orca) para la misma latencia. La clave es reducir el desperdicio de memoria de la KV cache de un 60-80% habitual a menos de un 4%. Esa ventaja de arquitectura se ha mantenido con las mejoras posteriores, y se traduce directamente en coste de infraestructura.

Prefix caching: lo que más ha cambiado

La mejora que más impacto ha tenido es el prefix caching automático. Cuando dos o más peticiones comparten un prefijo (típico: el system prompt de una aplicación, o el contexto común de un RAG), vLLM detecta la coincidencia y reutiliza la cache de atención ya calculada. El efecto práctico es que cargas que antes ejecutaban la misma cabeza de prompt miles de veces al día ahora lo hacen una sola vez por nodo.

Para aplicaciones con mucho repetido (asistentes con instrucciones largas fijas, RAG con contexto recurrente, chat con historial compartido entre turnos), el ahorro es real. En una prueba publicada por el proyecto llm-d[2], una petición con un prompt de unos 10.000 tokens contra una instancia de Qwen3-32B tardó 4,3 segundos hasta el primer token. La segunda vez tardó 0,6 segundos, gracias únicamente al prefix caching. Y el throughput agregado sube proporcionalmente.

La integración es además sin fricción: funciona automáticamente, sin configurar nada. Para un equipo que ya está usando vLLM, pasar a la versión con prefix caching es cuestión de actualizar.

Speculative decoding: la segunda gran mejora

La técnica consiste en usar un modelo pequeño rápido para predecir un bloque de tokens por adelantado y luego verificar esas predicciones con el modelo principal. Si las predicciones son correctas, el modelo grande valida en una sola pasada lo que habría requerido una pasada por token, y la latencia efectiva baja.

vLLM ha incorporado speculative decoding con cuatro opciones de modelo borrador (EAGLE, MTP, n-gram, modelos borrador dedicados), según la documentación oficial del proyecto[3]. La mejora en latencia es especialmente notable en modelos grandes (70B+) donde cada token individual cuesta mucho. Para cargas interactivas donde la experiencia de usuario depende del tiempo al primer token y la velocidad de generación, es un cambio cualitativo.

El único aspecto a tener en cuenta es que speculative decoding añade complejidad operativa: necesitas desplegar el modelo borrador junto al principal, y afinar el ratio de aceptación para tu carga específica.

Multi-LoRA: un caso específico

Para equipos que sirven múltiples fine-tunes del mismo modelo base (típico en SaaS multi-tenant donde cada cliente tiene su adaptador), el soporte multi-LoRA de vLLM ha madurado. Según la documentación de LoRA Adapters[4], puedes cargar un modelo base y tantos adaptadores LoRA simultáneos como permita el parámetro max_loras. Cada petición especifica el adaptador que quiere usar como si fuera un modelo distinto, sin recargar el modelo base.

Esto transforma la economía de servicios multi-tenant con LLM. En vez de desplegar un modelo por cliente (que no escala), desplegas un modelo base compartido y un adaptador por cliente. Los adaptadores son pequeños (unos pocos MB cada uno), así que en la misma GPU caben a la vez muchos más adaptadores activos de los que permitiría desplegar un modelo completo por cliente.

La aplicación típica es SaaS B2B con IA personalizada: cada cliente entrena su propio adaptador sobre sus datos, y el servicio sirve a todos con un solo modelo base. Nuestro análisis de modelos de pesos abiertos en empresa explica cómo encaja esta arquitectura en proyectos reales.

Comparación con alternativas

Las alternativas serias siguen siendo Text Generation Inference de Hugging Face y TensorRT-LLM de NVIDIA.

TGI ha mejorado mucho y ahora tiene features comparables a vLLM en la mayoría de áreas. Es una buena opción si ya estás integrado en el ecosistema de Hugging Face.

Tiene además un punto fuerte concreto: en prompts largos (más de 200.000 tokens) TGI v3 puede servir una respuesta en unos 2 segundos, frente a los 27,5 segundos de vLLM. El mérito es de su chunking del prefill, según una comparativa técnica publicada en MarkTechPost[5]. Para cargas dominadas por contexto largo y reutilización (RAG sobre documentos extensos), merece la pena evaluarlo.

TensorRT-LLM ofrece el throughput más alto en hardware NVIDIA cuando puedes dedicar tiempo a la optimización específica. La misma comparativa cita cifras de más de 10.000 tokens de salida por segundo en H100 para cargas bien compiladas. El precio es un pipeline de compilación más complejo y menos flexibilidad para cargas dinámicas. Para servicios de alto volumen con cargas predecibles, merece considerarlo; para servicios con cargas variables o que rotan de modelo, vLLM sigue siendo más cómodo.

llama.cpp y derivados (Ollama, LM Studio) no compiten con vLLM en throughput sino en simplicidad y flexibilidad. Para prototipos, aplicaciones locales y despliegues pequeños, siguen siendo excelentes. Para servicios que atienden decenas o cientos de peticiones concurrentes, vLLM es superior por diseño. Ver nuestra guía de cómo instalar Ollama para casos de desarrollo local.

Lo que sigue siendo punto débil

vLLM no es perfecto:

  • El soporte multi-GPU ha mejorado pero sigue siendo más frágil que el single-GPU. Las configuraciones con tensor parallelism pueden surgir problemas con ciertos modelos grandes.

  • El soporte de hardware no-NVIDIA va por detrás. vLLM funciona en AMD con ROCm y se ha portado a Intel Habana, pero la experiencia es claramente inferior a NVIDIA.

  • El consumo de memoria durante el arranque es alto. vLLM carga el modelo y los buffers de KV cache agresivamente. Para modelos grandes en GPUs con VRAM limitada, puede ser difícil hacer que quepa.

Lo que significa para quien opera

Para prácticamente cualquier equipo que esté sirviendo LLMs en GPU NVIDIA con cargas no triviales, vLLM es la opción con mejor retorno en inversión de tiempo. Las mejoras recientes (prefix caching, speculative decoding, multi-LoRA) han ampliado la ventaja sobre alternativas en los últimos seis meses.

Mi recomendación a un equipo empezando hoy:

  • Arranca con la última versión estable.

  • Mide con tu carga real antes de micro-optimizar.

  • Activa prefix caching desde el principio si tus prompts tienen partes repetidas.

  • Considera speculative decoding solo si las mediciones te muestran que la latencia es un problema real.

  • No intentes optimizar todos los knobs a la vez.

A medio plazo, espero que vLLM mantenga su ritmo de mejora y se convierta en una infraestructura dada por sentada, como hoy son Redis o PostgreSQL en su respectivo nicho. Para quien está construyendo productos sobre LLMs, esa estabilidad es una buena noticia: menos tiempo en infraestructura, más en el producto.

Esta entrada también está disponible en inglés: vLLM in 2025: the improvements that matter to LLM-serving teams.

Fuentes:

  1. Kwon et al.: Efficient Memory Management for Large Language Model Serving with PagedAttention (arXiv)[1]
  2. vLLM: Speculative Decoding (documentación oficial)[3]
  3. vLLM: LoRA Adapters (documentación oficial)[4]
  4. llm-d: KV-Cache Wins You Can See, From Prefix Caching in vLLM to Distributed Scheduling[2]
  5. MarkTechPost: vLLM vs TensorRT-LLM vs HF TGI vs LMDeploy, A Deep Technical Comparison for Production LLM Inference[5]

Preguntas frecuentes

¿Tengo que configurar algo para aprovechar el prefix caching de vLLM?

No: funciona automáticamente, sin configurar nada, así que para un equipo que ya usa vLLM la actualización lo activa. Cuando dos o más peticiones comparten un prefijo (el system prompt de la aplicación o el contexto común de un RAG), vLLM reutiliza la cache de atención ya calculada. En una prueba publicada por llm-d, un prompt de unos 10.000 tokens contra Qwen3-32B pasó de 4,3 segundos hasta el primer token a 0,6 segundos la segunda vez.

¿Merece la pena activar speculative decoding en mi servicio?

Solo si tus mediciones muestran que la latencia es un problema real. La mejora es especialmente notable en modelos de 70B+ donde cada token cuesta mucho, y vLLM ofrece cuatro modelos borrador (EAGLE, MTP, n-gram o modelos dedicados). A cambio añade complejidad operativa: hay que desplegar el modelo borrador junto al principal y afinar el ratio de aceptación para tu carga. Mide con tu carga real antes de micro-optimizar.

¿Cómo sirvo un fine-tune distinto por cliente sin desplegar un modelo por cada uno?

Con el soporte multi-LoRA: cargas un modelo base compartido y tantos adaptadores LoRA simultáneos como permita el parámetro max_loras. Cada petición indica el adaptador que quiere como si fuera un modelo distinto, sin recargar el modelo base. Los adaptadores ocupan unos pocos MB cada uno, así que en una GPU caben a la vez muchos más adaptadores que modelos completos, lo que cambia la economía de un SaaS multi-tenant.

Fuentes

  1. paper original de PagedAttention
  2. llm-d
  3. documentación oficial del proyecto
  4. documentación de LoRA Adapters
  5. comparativa técnica publicada en MarkTechPost