Skip to main content
PromptQuorum
Inicio/LLM locales avanzados/vLLM explicado: servidor de inferencia LLM de alto rendimiento con PagedAttention (2026)
Overview & Reference

vLLM explicado: servidor de inferencia LLM de alto rendimiento con PagedAttention (2026)

·13 min de lectura·Por Hans Kuepper · Fundador de PromptQuorum, herramienta de despacho multi-modelo · PromptQuorum

**vLLM es una biblioteca gratuita y de código abierto (Apache 2.0) para inferencia y servicio de LLM de alto rendimiento, originada en el Sky Computing Lab de la UC Berkeley y hoy mantenida por una gran comunidad de código abierto.** Su diferenciador técnico clave es PagedAttention, que gestiona la caché KV de atención en bloques no contiguos de tamaño fijo — de forma similar a como un sistema operativo gestiona la memoria virtual —, permitiendo que una GPU mantenga el estado de muchas más solicitudes simultáneas sin sobrerreservar memoria para cada una. Combinado con el batching continuo, esto permite a vLLM atender a muchos usuarios simultáneos desde una GPU (o una configuración multi-GPU con paralelismo de tensores) con menos memoria desperdiciada que un bucle de servicio ingenuo. vLLM incluye un servidor de API compatible con OpenAI (vllm serve), soporta formatos de cuantización como AWQ, GPTQ y FP8, y está construido para servicio de producción y multiinquilino — no para el caso de uso de un solo usuario haciendo clic que buscan herramientas como Ollama y LM Studio.

vLLM es una biblioteca gratuita, con licencia Apache 2.0, para inferencia y servicio de LLM, originada en el Sky Computing Lab de la UC Berkeley y mantenida hoy por una gran comunidad de código abierto. Su aporte técnico principal es PagedAttention, una técnica de gestión de memoria para la caché de clave-valor (KV) de atención que permite a una GPU atender muchas más solicitudes simultáneas desde la misma memoria que con implementaciones de atención ingenuas, combinada con batching continuo que mantiene la GPU ocupada con muchas solicitudes simultáneas en lugar de procesarlas en lotes fijos. vLLM incluye un servidor de API compatible con OpenAI y apunta al servicio de producción multiusuario — una herramienta distinta de las apps de escritorio para un solo usuario como Ollama o LM Studio.

vLLM explicado: servidor de inferencia LLM de alto rendimiento con PagedAttention (2026)

Conclusiones clave

  • Gratuito y de código abierto con licencia Apache 2.0, originado en el Sky Computing Lab de la UC Berkeley
  • PagedAttention gestiona la caché KV en bloques no contiguos de tamaño fijo para reducir el desperdicio de memoria de GPU
  • El batching continuo procesa muchas solicitudes simultáneas en lugar de un lote fijo a la vez
  • Incluye un servidor de API compatible con OpenAI, iniciado con el comando vllm serve
  • Soporta formatos de cuantización como AWQ, GPTQ y FP8
  • Soporta servicio con paralelismo de tensores y de pipeline en múltiples GPU
  • El hardware principal y mejor soportado son las GPU NVIDIA; existen backends de AMD, Intel y otros pero con cobertura más limitada
  • No es una app de escritorio de un solo usuario — sin instalador gráfico, y no está pensado para CPU sola o Apple Silicon como llama.cpp y Ollama

📍 En una frase

vLLM es una biblioteca gratuita, con licencia Apache 2.0, originada en el Sky Computing Lab de la UC Berkeley, que usa PagedAttention y batching continuo para atender eficientemente muchas solicitudes LLM simultáneas desde una GPU, e incluye un servidor de API compatible con OpenAI.

💬 En términos simples

En lugar de una app de chat de escritorio, vLLM es software de servidor: se apunta a un modelo y expone una API que muchas personas o aplicaciones pueden llamar a la vez, aprovechando la memoria de la GPU con más eficiencia que un esquema simple de una solicitud a la vez.

📌Nota: Este artículo se basa en el repositorio de GitHub oficial de vLLM y su documentación pública, no en benchmarks propios. No se incluyen cifras específicas de rendimiento o latencia porque no se midieron de forma independiente para este artículo y varían mucho según la GPU, el modelo, el tamaño de lote y la versión de vLLM.

¿Qué es vLLM?

vLLM es una biblioteca y servidor gratuitos, con licencia Apache 2.0, para ejecutar inferencia de grandes modelos de lenguaje a escala. Se originó como proyecto de investigación en el Sky Computing Lab de la UC Berkeley y desde entonces ha crecido hasta ser uno de los motores de servicio de LLM de código abierto más usados, con contribuciones de miles de desarrolladores de organizaciones académicas e industriales. A diferencia de herramientas pensadas principalmente para un solo usuario conversando con un modelo en su propia máquina, vLLM está diseñado para atender muchas solicitudes simultáneas — de varios usuarios o aplicaciones — de la forma más eficiente posible desde capacidad de GPU compartida.

  • Originado en el Sky Computing Lab de la UC Berkeley, hoy un proyecto de código abierto gobernado por la comunidad
  • Con licencia Apache 2.0: el código fuente está disponible públicamente para uso, modificación y redistribución según los términos de la licencia
  • Carga modelos en el formato compatible con Hugging Face Transformers, lo que le da amplia cobertura de arquitecturas — Llama, Mistral, Qwen, DeepSeek y muchas otras familias de modelos — sin un paso de conversión separado para la mayoría de los modelos
  • Construido para atender de forma eficiente muchas solicitudes simultáneas, no solo para ejecutar rápido una única conversación
  • Uno de los proyectos de servicio de LLM de código abierto más referenciados en GitHub

¿Qué es PagedAttention y por qué importa?

PagedAttention es la técnica de gestión de memoria por la que vLLM es más conocido. Durante la generación, un modelo transformer almacena una caché de clave-valor (KV) de atención para cada token de cada solicitud activa — normalmente esta caché se asigna como un único bloque contiguo grande por solicitud, dimensionado para la longitud máxima posible de la solicitud, lo que desperdicia memoria de GPU cada vez que una solicitud termina antes o es más corta que el máximo reservado. PagedAttention, en cambio, divide la caché KV en bloques pequeños de tamaño fijo (páginas) que pueden asignarse de forma no contigua y compartirse entre solicitudes, tomando prestada una idea de cómo los sistemas operativos gestionan la memoria virtual.

  • Reduce el desperdicio de memoria por reservar en exceso espacio de caché KV para solicitudes que resultan más cortas que su máximo
  • Permite compartir bloques de memoria entre solicitudes que comparten un prefijo común, como el mismo prompt de sistema
  • Permite que la GPU mantenga la caché KV de más solicitudes simultáneas en la misma cantidad de memoria frente a una asignación contigua ingenua
  • Funciona junto con el batching continuo, que permite a vLLM añadir y quitar solicitudes de un lote en curso a medida que llegan y terminan, en lugar de esperar a que un lote fijo termine por completo antes de empezar el siguiente

¿Qué hardware necesita vLLM?

El objetivo principal y mejor soportado de vLLM son las GPU NVIDIA con CUDA, y la mayoría de los despliegues de producción corren sobre hardware NVIDIA. El proyecto también documenta backends adicionales, pero la cobertura y el rendimiento no son iguales en todos ellos.

GPU NVIDIA (CUDA)

Detalles:
El objetivo principal y más maduro. El servicio con paralelismo de tensores y de pipeline en múltiples GPU NVIDIA está bien documentado y ampliamente usado en producción.

GPU AMD (ROCm)

Detalles:
Documentado como backend soportado para hardware AMD vía ROCm, con adopción real y cobertura comunitaria más limitadas que la ruta CUDA.

GPU Intel y aceleradores Gaudi

Detalles:
Backends adicionales documentados por el proyecto para hardware Intel; conviene tratarlos como una ruta de despliegue más pequeña y menos probada que las GPU NVIDIA.

TPU de Google

Detalles:
Un backend documentado para hardware TPU de Google Cloud, pensado para equipos que ya operan sobre esa infraestructura.

CPU (x86 / ARM / PowerPC)

Detalles:
Existe un backend solo de CPU, pero no es el caso de uso objetivo de vLLM — el proyecto está construido para servicio en GPU, y la ejecución en CPU se documenta como sustancialmente más lenta que los backends de GPU.

Apple Silicon (Mac)

Detalles:
No es una ruta oficial de primera clase. Proyectos mantenidos por la comunidad (como un plugin de backend Metal) añaden soporte parcial de Apple Silicon, pero la cobertura y madurez quedan muy por detrás del soporte de GPU NVIDIA de vLLM.

Si el objetivo es ejecutar un modelo en un solo Mac o una máquina solo con CPU, vLLM no es la herramienta pensada para eso — llama.cpp y herramientas construidas sobre él, como Ollama y LM Studio, apuntan directamente a hardware CPU y Apple Silicon y encajan mejor en ese escenario.

¿Qué formatos de cuantización soporta vLLM?

vLLM soporta servir modelos con precisión numérica reducida para bajar el uso de memoria y, en muchos casos, aumentar el rendimiento, usando varios formatos de cuantización establecidos en lugar de uno solo propietario.

AWQ

Detalles:
Activation-aware Weight Quantization, un método de cuantización de pesos a 4 bits ampliamente usado, con modelos precuantizados publicados por la comunidad en Hugging Face.

GPTQ

Detalles:
Un método de cuantización posterior al entrenamiento, distribuido habitualmente como checkpoints de modelos precuantizados, también típicamente a 4 bits.

FP8

Detalles:
Precisión de punto flotante de 8 bits, soportada en generaciones más nuevas de GPU NVIDIA con soporte de hardware FP8, cambiando algo de precisión por menor uso de memoria y ejecución más rápida que FP16/BF16.

INT8 / INT4

Detalles:
Rutas de cuantización entera de menor precisión documentadas por el proyecto junto a AWQ y GPTQ para mayor reducción de memoria.

Este artículo no incluye cifras de pérdida de calidad medidas de forma independiente para cada formato — estas varían según la arquitectura del modelo y la tarea. Comparar salidas de un par de formatos con sus propios prompts es la forma más fiable de juzgar el compromiso para su caso de uso.

¿Qué ofrece el servidor compatible con OpenAI de vLLM?

Ejecutar vllm serve inicia un servidor HTTP que implementa el protocolo de la API de OpenAI, de modo que aplicaciones y SDKs ya construidos sobre la API de OpenAI a menudo pueden apuntar a una instancia de vLLM autoalojada cambiando solo la URL base y el nombre del modelo.

  • Endpoints compatibles con OpenAI para chat completions y completions, utilizables como reemplazo directo de código cliente basado en la API de OpenAI
  • Host y puerto configurables (el servidor escucha por defecto en http://localhost:8000)
  • Flags del motor para el tamaño del paralelismo de tensores, el objetivo de utilización de memoria de GPU y el formato de cuantización, definidos al iniciar el servidor
  • Soporte para servir varios adaptadores LoRA sobre un mismo modelo base cargado
  • Soporte de salidas estructuradas y llamadas a funciones/herramientas para formatos de solicitud compatibles

¿Cómo se instala y ejecuta vLLM?

vLLM se distribuye como paquete de Python y normalmente se instala con pip en un entorno Python con una GPU NVIDIA disponible y drivers CUDA compatibles.

  1. 1
    Confirme que tiene una GPU NVIDIA soportada con drivers CUDA actuales instalados (o revise la documentación del proyecto para instrucciones de instalación específicas de AMD/Intel/TPU si va a usar uno de esos backends).
  2. 2
    Cree un entorno virtual de Python e instale vLLM: pip install vllm.
  3. 3
    Inicie el servidor compatible con OpenAI con un modelo de Hugging Face, por ejemplo: vllm serve meta-llama/Llama-3.1-8B-Instruct.
  4. 4
    Para un modelo precuantizado, pase el flag correspondiente, por ejemplo: vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq.
  5. 5
    Para servicio multi-GPU, añada un flag de paralelismo de tensores, por ejemplo: vllm serve <model> --tensor-parallel-size 2 para repartir el modelo entre dos GPU.
  6. 6
    Por defecto el servidor escucha en http://localhost:8000; envíe una solicitud a su endpoint /v1/chat/completions con cualquier biblioteca cliente compatible con la API de OpenAI, o con curl.
  7. 7
    Apunte código cliente de OpenAI existente a su servidor autoalojado cambiando solo la URL base y el nombre del modelo.

¿Necesito una GPU para ejecutar vLLM?

Para cualquier uso más allá de pruebas, sí — el objetivo principal y mejor soportado de vLLM son las GPU NVIDIA. Existe un backend solo de CPU, pero se documenta como sustancialmente más lento y no es el foco del proyecto.

¿Puedo ejecutar vLLM con un modelo cuantizado?

Sí — vLLM soporta formatos como AWQ, GPTQ y FP8, y muchos modelos precuantizados en estos formatos están publicados en Hugging Face y pueden servirse con el flag --quantization correspondiente.

¿Cómo se compara vLLM con Ollama y LM Studio?

Ollama y LM Studio apuntan a un problema distinto al de vLLM: darle a una persona, de forma rápida y sencilla, un modelo con el que chatear en su propia máquina. vLLM apunta a atender a muchos usuarios o aplicaciones simultáneos de la forma más eficiente posible desde capacidad de GPU compartida. Ambas categorías de herramientas no son sustitutos cercanos para la mayoría de los casos de uso.

  • Ollama y LM Studio suelen construirse sobre llama.cpp o motores similares y el formato de modelo GGUF, optimizados para uso de un solo usuario en hardware de consumo, incluidas máquinas solo con CPU y Apple Silicon
  • vLLM se construye sobre PagedAttention y el batching continuo, optimizado para servicio de GPU de alta concurrencia en lugar de capacidad de respuesta de un solo usuario en hardware modesto
  • Ollama se instala con un comando sin necesitar GPU; vLLM espera un entorno Python, una GPU NVIDIA en la mayoría de los despliegues, y configuración por línea de comandos
  • LM Studio añade una interfaz gráfica de chat de escritorio; vLLM no tiene interfaz gráfica — se accede a través de su API compatible con OpenAI o flags de línea de comandos
  • Tanto vLLM como las herramientas basadas en llama.cpp pueden exponer una API compatible con OpenAI, así que las herramientas de front-end construidas para esa API a menudo funcionan con cualquiera de las dos

¿Cómo se compara vLLM con TGI y TensorRT-LLM?

vLLM, Text Generation Inference (TGI) de Hugging Face, y TensorRT-LLM de NVIDIA apuntan todos al mismo trabajo amplio — servicio de LLM en producción a escala — pero con diseños y compromisos distintos.

vLLM

Detalles:
Con licencia Apache 2.0, basado en Python, construido sobre PagedAttention y batching continuo. Carga directamente modelos compatibles con Hugging Face Transformers, con amplia cobertura de arquitecturas y soporte de backends de GPU multi-proveedor (NVIDIA principal; AMD, Intel, TPU documentados).

TGI

Detalles:
El motor de servicio propio de Hugging Face, con licencia Apache 2.0, que también soporta batching continuo y varios formatos de cuantización. Estrechamente integrado con el Hugging Face Hub y su ecosistema.

TensorRT-LLM

Detalles:
El motor de NVIDIA, construido específicamente para GPU NVIDIA. Los modelos se compilan de antemano en un motor TensorRT optimizado para la GPU objetivo, lo que puede dar un rendimiento sólido en ese hardware específico, a costa de un paso de compilación y menos flexibilidad entre hardware que vLLM o TGI.

Este artículo no ha comparado de forma independiente estos tres motores entre sí y no afirma que uno sea universalmente más rápido — el rendimiento depende mucho del modelo, el hardware, las características de los lotes y la versión de cada motor. Vea la guía de servidores de inferencia empresarial para una comparación más detallada de despliegue y licencias de los tres.

¿Para quién es vLLM?

vLLM encaja con equipos que sirven un modelo a muchos usuarios o aplicaciones simultáneos sobre infraestructura de GPU, no con personas que buscan la forma más rápida de chatear con un modelo en su propio equipo.

vLLM frente a alternativas, de un vistazo

Estas herramientas se ubican en distintos puntos del espectro entre uso de un solo usuario y servicio en producción.

vLLM

Interfaz e instalación:
Paquete de Python instalado vía pip; servidor de API compatible con OpenAI iniciado con vllm serve. Requiere una GPU NVIDIA y CUDA en la mayoría de los despliegues.
Ideal para:
Servicio de GPU de alto rendimiento y multiusuario en producción.

Ollama

Interfaz e instalación:
CLI y API REST, comúnmente reportado como corriendo sobre llama.cpp como backend en la mayoría de las plataformas. Un comando lo instala; un comando descarga y ejecuta un modelo.
Ideal para:
El camino más rápido a un modelo local funcionando para un solo usuario, sin paso de compilación ni GPU requerida.

LM Studio

Interfaz e instalación:
App gráfica de escritorio para Mac, Windows y Linux. Descargar, instalar, y luego explorar y descargar un modelo desde la app.
Ideal para:
Usuarios no técnicos que quieren una app de chat local para hacer clic.

llama.cpp

Interfaz e instalación:
CLI, interfaz web integrada y API compatible con OpenAI vía llama-server. Compilar desde el código fuente o usar un binario precompilado; corre en CPU o GPU.
Ideal para:
Control directo a nivel de motor, despliegue embebido/edge, y hardware CPU o Apple Silicon.

Este artículo no ha comparado de forma independiente la velocidad ni la calidad de salida de estas herramientas y no afirma que una sea técnicamente superior — la comparación anterior cubre solo hechos documentados de arquitectura, instalación y modelo de acceso. Para cifras de rendimiento por hardware, vea la comparación llama.cpp vs. Ollama vs. vLLM y la guía de servidores de inferencia empresarial.

¿Qué no cubre este artículo?

Este es un artículo explicativo construido a partir de la documentación pública y el repositorio de vLLM, no un informe de benchmarks propio.

  • Sin cifras de rendimiento, latencia o solicitudes por segundo medidas de forma independiente — estas dependen mucho de la GPU, el modelo, la composición de los lotes y la versión de vLLM
  • Sin porcentajes de pérdida de calidad verificados de forma independiente para formatos de cuantización específicos — estos varían según la arquitectura del modelo y la tarea
  • Sin auditoría de seguridad línea por línea del código de vLLM — es de código abierto y con licencia Apache 2.0, por lo que el código está disponible para revisión
  • Sin cobertura completa de cada backend de hardware soportado, flag del motor u opción de orquestación de despliegue (Kubernetes, configuraciones específicas de nube) — este artículo se centra en los conceptos y flags que la mayoría de los equipos evalúan primero
  • Sin cobertura de acuerdos de soporte comercial ni ofertas de alojamiento gestionado de vLLM, ya que vLLM en sí es un proyecto de código abierto comunitario, no un producto de proveedor con contrato de soporte

Errores comunes al probar vLLM

La mayor parte de la fricción con vLLM viene de tratarlo como una herramienta de escritorio de un solo usuario en lugar de software de servidor de producción.

Preguntas frecuentes

¿Qué es vLLM?

vLLM es una biblioteca y servidor gratuitos, con licencia Apache 2.0, para inferencia de LLM de alto rendimiento, originados en el Sky Computing Lab de la UC Berkeley. Usa PagedAttention y batching continuo para atender eficientemente muchas solicitudes simultáneas desde una GPU.

¿Es gratis vLLM?

Sí. vLLM es software gratuito y de código abierto publicado bajo la licencia Apache 2.0, sin necesidad de suscripción ni cuenta para ejecutarlo usted mismo.

¿Qué es PagedAttention?

PagedAttention es la técnica de vLLM para gestionar la caché KV de atención en bloques pequeños, no contiguos y de tamaño fijo en lugar de una única asignación contigua grande por solicitud, lo que reduce el desperdicio de memoria de GPU y permite compartir memoria entre solicitudes con un prefijo común.

¿Necesita vLLM una GPU?

Para cualquier carga de trabajo real, sí — el objetivo principal y mejor soportado de vLLM son las GPU NVIDIA. Existe un backend solo de CPU, pero se documenta como sustancialmente más lento y no es el foco del proyecto, y el soporte de Apple Silicon se limita a extensiones mantenidas por la comunidad en lugar de una ruta de primera clase.

¿Qué formatos de cuantización soporta vLLM?

vLLM soporta varios formatos, incluidos AWQ, GPTQ, FP8 e INT8/INT4, con muchos modelos precuantizados en estos formatos publicados en Hugging Face.

¿Es vLLM mejor que Ollama?

"Mejor" depende del trabajo: vLLM está construido para servicio de GPU de producción de alta concurrencia, mientras que Ollama está construido para el camino más rápido a un modelo local de un solo usuario sin necesitar GPU. Para la mayoría de los casos de uso no son sustitutos cercanos — vea la tabla comparativa arriba.

¿Puede vLLM servir modelos en varias GPU?

Sí. vLLM soporta servicio con paralelismo de tensores y de pipeline en varias GPU, configurable con flags como --tensor-parallel-size al iniciar el servidor.

¿Tiene vLLM una API compatible con OpenAI?

Sí. Ejecutar vllm serve inicia un servidor que implementa el protocolo de la API de OpenAI, de modo que muchas aplicaciones construidas para la API de OpenAI pueden apuntar a una instancia de vLLM autoalojada cambiando solo la URL base y el nombre del modelo.

¿En qué se diferencia vLLM de TensorRT-LLM?

TensorRT-LLM es el motor de NVIDIA, que compila los modelos de antemano en un motor optimizado para una GPU NVIDIA específica. vLLM carga directamente modelos compatibles con Hugging Face Transformers sin un paso de compilación previo, y documenta soporte de backends más allá de las GPU NVIDIA, a costa de menos optimización específica de hardware pero con más flexibilidad e iteración más rápida.

Fuentes

← Volver a LLM locales avanzados