- vLLM es un motor de inferencia de código abierto para servir modelos de lenguaje grande (LLM) en GPUs con un alto rendimiento (throughput), exponiéndolos mediante una API HTTP compatible con OpenAI.
- Sus dos técnicas fundamentales — PagedAttention y procesamiento por lotes continuo (continuous batching) — permiten que una sola GPU gestione muchas solicitudes simultáneas sin desperdiciar VRAM.
- Instale con
pip install vllmen un entorno Python limpio en Linux (GPU NVIDIA, capacidad de cómputo 7.0 o superior), luego inicie un servidor convllm serve <modelo>. - Está diseñado para servir a muchos usuarios o aplicaciones. Para un chatbot personal en una computadora portátil, Ollama o LM Studio es la herramienta más adecuada.
vLLM es un motor de inferencia y servicio de código abierto para modelos de lenguaje grande. Carga un modelo en una o varias GPUs y lo expone mediante una API HTTP compatible con OpenAI, utilizando dos técnicas — PagedAttention y procesamiento por lotes continuo (continuous batching) — para atender muchas solicitudes simultáneas con un rendimiento (throughput) mucho mayor que el servicio básico. Fue creado en el Sky Computing Lab de la Universidad de California en Berkeley y lanzado en 2023.
Qué es vLLM y para quién está destinado
Piense en vLLM como la contraparte orientada a producción de herramientas de escritorio como Ollama. Ambas toman un modelo y responden a solicitudes, pero están optimizadas para objetivos opuestos. Ollama está optimizado para que una persona obtenga una respuesta en hardware modesto. vLLM está optimizado para rendimiento (throughput): el número total de tokens generados por segundo entre decenas o cientos de solicitudes simultáneas dirigidas a la misma GPU.
Esto convierte a vLLM en la herramienta adecuada cuando usted:
- Servir un modelo de lenguaje de gran tamaño (LLM) detrás de una API interna o pública utilizada por múltiples personas o servicios
- Ejecutar trabajos por lotes —clasificación, extracción, generación de datos sintéticos— sobre grandes conjuntos de datos
- Sustituir una API de pago por un modelo de código abierto autoalojado para reducir los costos por token (el calculador de punto de equilibrio entre autoalojamiento y API le ayuda a determinar si la factura de la GPU realmente resulta más económica que la factura de la API, según su volumen de uso)
Y la herramienta equivocada si lo que desea es un asistente conversacional en su propio portátil, inferencia ocasional para un solo usuario o cualquier otra tarea en una máquina sin una GPU potente. vLLM asume un entorno servidor: Linux, una GPU NVIDIA como ruta predeterminada (existen backends para AMD ROCm, Intel, TPU y CPU, pero son menos comunes), y una carga de trabajo con concurrencia.
En su lanzamiento en 2023, las pruebas de rendimiento de vLLM mostraron un rendimiento hasta 24 veces superior al de servir modelos mediante Hugging Face Transformers estándar y aproximadamente de 2 a 3,5 veces mayor que los sistemas de servicio disponibles en aquel momento. Los valores exactos varían según el modelo, el hardware y la carga de trabajo; no obstante, comprender la causa de esta diferencia es fundamental, ya que revela cuándo vLLM ofrece una ventaja real.
PagedAttention, explicado de forma sencilla
Cuando un LLM genera texto, mantiene una caché KV caché KV (claves y valores de atención) en la memoria de la GPU: las claves y valores de atención para cada token de todas las conversaciones activas. Esta caché crece con cada token generado y, en contextos largos, puede consumir más VRAM que los propios pesos del modelo.
Antes de vLLM, los motores de servicio asignaban a cada solicitud un bloque contiguo de memoria dimensionado para la longitud máxima posible de secuencia, porque no podían saber de antemano cuánto duraría la salida. La mayoría de las solicitudes finalizan mucho antes del límite máximo, por lo que gran parte de esa memoria reservada permanecía inactiva. El artículo original de vLLM midió un desperdicio del 60–80 % de la memoria de la caché KV en sistemas anteriores debido a esta fragmentación.
PagedAttention adopta la solución empleada por los sistemas operativos: la paginación de memoria virtual. La caché KV se divide en bloques pequeños de tamaño fijo (16 tokens por defecto), que se asignan bajo demanda y no necesitan ser contiguos. Una tabla de bloques asigna las posiciones lógicas de cada secuencia a los bloques físicos libres disponibles, exactamente como un sistema operativo asigna páginas virtuales a la RAM física. El desperdicio de memoria cae por debajo del 4 %, y los bloques incluso pueden compartirse entre distintas secuencias (útil al generar varias respuestas a partir de un mismo prompt).
La consecuencia práctica: caben muchas más secuencias simultáneas en la misma VRAM. Más secuencias en memoria significan lotes efectivos mayores, y lotes mayores son lo que mantiene ocupada la GPU. Esa es toda la historia del rendimiento: PagedAttention no acelera ninguna solicitud individual; simplemente permite ejecutar muchas más solicitudes simultáneamente.
Procesamiento por lotes continuo (continuous batching)
La segunda técnica aborda la planificación (scheduling), no la memoria. La agrupación por lotes ingenua agrupa las solicitudes, ejecuta todo el lote hasta su finalización y luego inicia el siguiente lote; así, una solicitud que termina en 20 tokens debe esperar a otra que genera 2.000 tokens, mientras que las nuevas solicitudes se quedan encoladas fuera. Procesamiento por lotes continuo (continuous batching) La planificación continua (también llamada planificación a nivel de iteración) reforma el lote en cada paso de generación: las secuencias finalizadas salen inmediatamente y las solicitudes pendientes se incorporan al instante.
La GPU permanece saturada, las solicitudes cortas no quedan retenidas por las largas y tanto la latencia bajo carga como el rendimiento mejoran. PagedAttention y la agrupación continua se refuerzan mutuamente: la primera permite alojar más secuencias en memoria, y la segunda garantiza que dicha capacidad se utilice eficazmente.
Instalación de vLLM: las restricciones que suelen causar problemas
La instalación requiere un solo comando, pero tres restricciones causan la mayoría de los fallos de instalación:
- Versión de Python. Las versiones recientes apuntan aproximadamente al rango Python 3.9–3.12, y la ventana de versiones compatibles varía entre lanzamientos. Si
pipinforma que no encuentra ninguna distribución coincidente, su versión de Python es el primer sospechoso. - Versión de CUDA. Los paquetes precompilados están construidos contra una versión principal específica de CUDA (CUDA 12.x para las versiones actuales). Necesita un controlador NVIDIA reciente; para algunas versiones existen paquetes compatibles con otras versiones de CUDA mediante URLs especiales de índice documentadas en la documentación oficial de vLLM.
- Conflictos con PyTorch. vLLM fija su propia versión de PyTorch. Instalarlo en un entorno donde ya existe una versión distinta de Torch es la causa clásica de errores crípticos al importar. Use siempre un entorno virtual limpio.
Desde el punto de vista del hardware, la ruta principal requiere una GPU NVIDIA con capacidad computacional 7.0 o superior —por ejemplo, V100, T4, series RTX 20 y posteriores. Si está eligiendo hardware, consulte la guía sobre las mejores GPUs para ejecutar LLMs localmente.
Linux (plataforma compatible)
python3 -m venv vllm-env
source vllm-env/bin/activate
pip install vllmLa documentación de vLLM también recomienda uv (uv venv y luego uv pip install vllm), que resuelve las dependencias fijadas más rápidamente. En cualquier caso, lo esencial es usar un entorno limpio.
Windows: use WSL2 o Docker
No existe una compilación nativa para Windows. Las configuraciones funcionales son WSL2 con una distribución Ubuntu (el controlador de NVIDIA para Windows permite el acceso a CUDA desde WSL2, por lo que las instrucciones para Linux anteriores funcionan perfectamente dentro de él) o Docker Desktop con soporte para GPU habilitado, usando la imagen oficial:
docker run --gpus all -p 8000:8000 vllm/vllm-openai --model Qwen/Qwen2.5-7B-InstructmacOS: no es la herramienta adecuada
vLLM carece de un backend para GPU Metal/Apple. Existe una compilación experimental para CPU que puede realizarse desde el código fuente, pero esto va en contra del propósito de un motor optimizado para alto rendimiento. En un Mac, use LM Studio o Ollama en su lugar —ambos aprovechan correctamente la GPU de Apple Silicon.
Ejecución de un servidor: vllm serve
Un solo comando inicia un servidor de inferencia (el modelo se descarga automáticamente desde Hugging Face en la primera ejecución):
vllm serve Qwen/Qwen2.5-7B-InstructEsto sirve el modelo en el puerto 8000. Las opciones que usará con mayor frecuencia son:
| Opción | Qué hace | Cuándo necesita usarla |
|---|---|---|
--max-model-len | Limita la longitud del contexto, reduciendo la reserva de memoria para la caché KV | La solución más común cuando el inicio falla con un error de memoria insuficiente |
--gpu-memory-utilization | Fracción de VRAM que vLLM preasigna (valor predeterminado: 0,9) | Redúzcala si la GPU se comparte con otros procesos |
--tensor-parallel-size | Divide el modelo entre N GPUs | Modelos demasiado grandes para una sola tarjeta |
--quantization | Selecciona un método de cuantización (AWQ, GPTQ, FP8…) | Normalmente se detecta automáticamente a partir del punto de control; especifíquelo explícitamente si no es así |
--dtype | Precisión de los pesos (auto, float16, bfloat16) | GPU antiguas sin soporte para bfloat16 |
--api-key | Requiere un token de tipo «bearer» en cada solicitud | Cualquier servidor accesible más allá de localhost |
--port | Puerto de escucha (predeterminado: 8000) | Conflictos de puerto, varios modelos en un mismo host |
Tenga en cuenta que vLLM preasigna la mayor parte de la GPU por diseño: una lectura de VRAM casi llena es normal, no una fuga de memoria. Antes de elegir un modelo, compruebe que los pesos más la caché KV caben en su tarjeta mediante la Calculadora de VRAM; como regla aproximada, los pesos en FP16 necesitan unos 2 GB por cada mil millones de parámetros, y los de 8 bits, aproximadamente la mitad, además de margen adicional para la caché.
La API compatible con OpenAI
El servidor implementa la interfaz de API de OpenAI: /v1/chat/completions, /v1/completions, /v1/models, y /v1/embeddings (para modelos de incrustaciones). Cualquier aplicación desarrollada con el SDK de OpenAI funciona sin modificaciones al cambiar únicamente la URL base:
curl http://localhost:8000/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{"role": "user", "content": "Explica PagedAttention en una sola oración."}]
}'En Python, OpenAI(base_url="http://localhost:8000/v1", api_key="none") es toda la migración necesaria. Esta compatibilidad constituye una parte fundamental de la adopción de vLLM: las herramientas, agentes y marcos existentes funcionan sin cambios.
Cuándo Ollama o llama.cpp son mejores opciones
| vLLM | Ollama | llama.cpp | |
|---|---|---|---|
| Diseñado para | Servicio multiusuario en GPU | Uso personal o de escritorio | Portabilidad, CPU+GPU, integración en aplicaciones |
| Hardware | GPU de servidor (orientadas principalmente a NVIDIA) | Cualquier plataforma, incluido Apple Silicon | Cualquier plataforma, incluidos los teléfonos móviles |
| Formato del modelo | Safetensors de Hugging Face (AWQ/GPTQ/FP8) | GGUF | GGUF |
| Concurrencia | Excelente: es precisamente su propósito principal | Limitado | Limitado |
| Configuración | Entorno Python/CUDA | Un solo instalador | Binario o biblioteca independiente |
Seleccionar Ollama cuando el número de usuarios es uno y el hardware es una laptop o un equipo de escritorio: su configuración consiste en un único instalador y ejecuta cómodamente modelos cuantizados GGUF en CPUs y Apple Silicon (véase la Guía completa de Ollama). Elija llama.cpp directamente cuando necesite máxima portabilidad o desee integrar la inferencia dentro de otra aplicación. Elija vLLM cuando las solicitudes lleguen de forma concurrente y la métrica clave sea tokens por segundo por dólar. Una carga de trabajo con un solo usuario obtiene pocos beneficios de PagedAttention; una carga con 50 usuarios obtiene enormes ventajas.
Preguntas frecuentes
¿Es vLLM gratuito?
Sí. vLLM es de código abierto bajo la licencia Apache 2.0, originalmente desarrollado en la Universidad de California en Berkeley y actualmente mantenido como un proyecto comunitario bajo la Fundación PyTorch. No existe ninguna versión de pago; sus únicos costos son el hardware y la electricidad.
¿Puede vLLM ejecutar modelos GGUF como lo hace Ollama?
El soporte para GGUF existe, pero es experimental y no representa el flujo de trabajo previsto. vLLM está construido en torno a puntos de control estándar de Hugging Face (safetensors), con cuantización mediante checkpoints AWQ, GPTQ o FP8. Si sus modelos solo existen en formato GGUF, Ollama o llama.cpp son soluciones más adecuadas.
¿Funciona vLLM sin una GPU de NVIDIA?
Existen backends para AMD ROCm, hardware Intel, TPUs de Google, AWS Neuron y CPUs, pero la ruta CUDA de NVIDIA es, con mucho, la más madura y mejor documentada. vLLM en CPU únicamente sirve para pruebas, no para ofrecer el rendimiento de procesamiento que justifica su existencia.
¿Cuánta VRAM necesita vLLM?
Tanta como requieran los pesos del modelo más la caché KV: aproximadamente 2 GB por cada mil millones de parámetros en FP16, cerca de la mitad en 8 bits, además de margen para la caché, que aumenta con la longitud del contexto y la concurrencia. Un modelo de 7B en FP16 cabe cómodamente en una tarjeta de 24 GB; un modelo de 70B requiere múltiples GPUs o una cuantización agresiva. La referencia de requisitos de VRAM por modelo incluye valores específicos para cada modelo.
¿Cómo se compara vLLM con TensorRT-LLM, SGLang o TGI?
Todos pertenecen a la misma categoría: motores de inferencia para producción. En general, vLLM ofrece el soporte más amplio para modelos, la configuración más sencilla y la comunidad más grande; TensorRT-LLM puede extraer un rendimiento máximo superior en hardware NVIDIA, aunque a costa de un proceso de compilación y ajuste más complejo; SGLang es un competidor sólido, especialmente para salidas estructuradas. Realice pruebas comparativas con su propio modelo y carga de trabajo antes de decidirse: los resultados varían entre versiones.
¿Puedo afinar modelos con vLLM?
No: vLLM está diseñado exclusivamente para inferencia. A menudo se utiliza como backend rápido de generación dentro de marcos de entrenamiento RLHF, pero el entrenamiento propiamente dicho se lleva a cabo en otro lugar. Para el ajuste fino, use herramientas como Hugging Face TRL, Axolotl o Unsloth, y luego sirva el punto de control resultante con vLLM.
