Actualizado: 2026-07-07

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), y la decisión rara vez era definitiva. Hoy, aunque alternativas serias persisten, vLLM se ha convertido en el motor por defecto para la mayoría de equipos que sirven modelos en GPU. Y el crecimiento no ha sido casual: es el resultado de un ritmo de mejora muy 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) y 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, 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, gracias a 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 muchas 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 muy 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 pasó de 4,3 segundos hasta el primer token a solo 0,6 segundos la segunda vez, 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 varios 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 varias, y la latencia efectiva baja.

vLLM ha incorporado speculative decoding con varias 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), vLLM ha madurado el soporte multi-LoRA significativamente. Según la documentación de LoRA Adapters[4], puedes cargar un modelo base y varios adaptadores LoRA simultáneos (el límite lo fija el parámetro max_loras), y 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 caben muchos activos en memoria de GPU al mismo tiempo, muy por encima de lo 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: según una comparativa técnica publicada en MarkTechPost[5], en prompts muy largos (más de 200.000 tokens) TGI v3 puede servir una respuesta en unos 2 segundos frente a los 27,5 segundos que le cuesta a vLLM, gracias a su chunking del prefill. 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 cambian modelos con frecuencia, 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. 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