vLLM Quickstart: Servicio de LLM de Alto Rendimiento - en 2026

vLLM es un motor de inferencia y servicio de alto rendimiento y eficiente en memoria para Modelos de Lenguaje Grande (LLMs) desarrollado por el Laboratorio de Cálculo en la Nube de UC Berkeley.

Con su revolucionario algoritmo PagedAttention, vLLM logra un rendimiento 14-24 veces mayor que los métodos tradicionales de servicio, convirtiéndose en la opción preferida para despliegues de LLM en producción. Para ver cómo se encaja vLLM entre Ollama, Docker Model Runner, LocalAI y proveedores en la nube —incluyendo consideraciones de costo e infraestructura— vea LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

¿Qué es vLLM?

vLLM (virtual LLM) es una biblioteca de código abierto para la inferencia rápida y el servicio de LLM que rápidamente se ha convertido en el estándar de la industria para despliegues en producción. Lanzado en 2023, introdujo PagedAttention, una técnica innovadora de gestión de memoria que mejora significativamente la eficiencia del servicio.

Características Clave

Alto Rendimiento de Tránsito: vLLM entrega un tránsito 14-24 veces mayor comparado con HuggingFace Transformers con la misma hardware. Este gran aumento de rendimiento proviene del empaquetamiento continuo, núcleos optimizados de CUDA y el algoritmo PagedAttention que elimina la fragmentación de memoria.

Compatibilidad con la API de OpenAI: vLLM incluye un servidor API integrado que es completamente compatible con el formato de OpenAI. Esto permite una migración sin problemas desde OpenAI a infraestructura autoalojada sin cambiar el código de la aplicación. Simplemente dirija su cliente de API a la dirección de vLLM y funcionará de forma transparente.

Algoritmo PagedAttention: La innovación principal detrás del rendimiento de vLLM es PagedAttention, que aplica el concepto de paginación de memoria virtual a los mecanismos de atención. En lugar de asignar bloques de memoria contiguos para cachés KV (lo que lleva a la fragmentación), PagedAttention divide la memoria en bloques de tamaño fijo que se pueden asignar según sea necesario. Esto reduce el desperdicio de memoria hasta 4 veces y permite tamaños de lote mucho más grandes.

Empaquetamiento Continuo: A diferencia del empaquetamiento estático donde debes esperar a que todas las secuencias se completen, vLLM utiliza empaquetamiento continuo (rolante). Tan pronto como una secuencia finaliza, una nueva puede agregarse al lote. Esto maximiza la utilización de la GPU y minimiza la latencia para las solicitudes entrantes.

Soporte Multigpu: vLLM admite paralelismo de tensores y paralelismo de canalización para distribuir modelos grandes entre múltiples GPUs. Puede servir modelos que no caben en la memoria de una sola GPU, soportando configuraciones desde 2 a 8+ GPUs.

Amplio Soporte de Modelos: Compatible con arquitecturas de modelos populares incluyendo LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma y muchos otros. Soporta tanto modelos ajustados a instrucciones como modelos base desde HuggingFace Hub.

¿Cuándo Usar vLLM

vLLM destaca en escenarios específicos donde sus fortalezas brillan:

Servicios de API de Producción: Cuando necesitas servir un LLM a muchos usuarios concurrentes a través de API, el alto tránsito y el empaquetamiento eficiente de vLLM lo hacen la mejor opción. Las empresas que operan chatbots, asistentes de código o servicios de generación de contenido benefician de su capacidad para manejar cientos de solicitudes por segundo.

Cargas de Alto Concurso: Si tu aplicación tiene muchos usuarios simultáneos haciendo solicitudes, el empaquetamiento continuo y PagedAttention de vLLM permiten servir más usuarios con la misma hardware comparado con alternativas.

Optimización de Costos: Cuando los costos de GPU son una preocupación, el tránsito superior de vLLM significa que puedes servir el mismo tráfico con menos GPUs, reduciendo directamente los costos de infraestructura. La eficiencia de memoria 4 veces mayor de PagedAttention también permite usar instancias de GPU más pequeñas y económicas.

Despliegues en Kubernetes: El diseño sin estado y la arquitectura amigable a contenedores de vLLM lo hacen ideal para clústeres de Kubernetes. Su rendimiento consistente bajo carga y gestión de recursos sencilla se integran bien con infraestructura nativa en la nube.

Cuándo No Usar vLLM: Para desarrollo local, experimentación o escenarios de usuario único, herramientas como Ollama ofrecen una mejor experiencia de usuario con una configuración más sencilla. La complejidad de vLLM se justifica cuando necesitas sus ventajas de rendimiento para cargas de trabajo en producción.

Cómo Instalar vLLM

Requisitos Previos

Antes de instalar vLLM, asegúrate de que tu sistema cumpla con estos requisitos:

• GPU: GPU NVIDIA con capacidad de cálculo 7.0+ (V100, T4, A10, A100, H100, RTX 20/30/40 series)
• CUDA: Versión 11.8 o superior
• Python: 3.8 a 3.11
• VRAM: Mínimo 16GB para modelos de 7B, 24GB+ para 13B, 40GB+ para modelos más grandes
• Controlador: Controlador NVIDIA 450.80.02 o más reciente

Instalación con pip

El método más sencillo de instalación es usando pip. Esto funciona en sistemas con CUDA 11.8 o más reciente:

# Crear un entorno virtual (recomendado)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Instalar vLLM
pip install vllm

# Verificar instalación
python -c "import vllm; print(vllm.__version__)"

Para sistemas con versiones diferentes de CUDA, instale la rueda adecuada:

# Para CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# Para CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Instalación con Docker

Docker proporciona el método más confiable de despliegue, especialmente para producción:

# Descargar la imagen oficial de vLLM
docker pull vllm/vllm-openai:latest

# Ejecutar vLLM con soporte a GPU
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

La bandera --ipc=host es importante para configuraciones multigpu ya que permite la comunicación interprocesos adecuada.

Construcción desde Fuente

Para las últimas características o modificaciones personalizadas, construye desde la fuente:

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

Guía de Inicio Rápido de vLLM

Ejecutando tu Primer Modelo

Inicia vLLM con un modelo usando la interfaz de línea de comandos:

# Descargar y servir Mistral-7B con API compatible con OpenAI
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM descargará automáticamente el modelo desde HuggingFace Hub (si no está caché) y iniciará el servidor. Verás una salida indicando que el servidor está listo:

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

Haciendo Solicitudes API

Una vez que el servidor esté en ejecución, puedes hacer solicitudes usando el cliente Python de OpenAI o curl:

Usando curl:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Explica qué es vLLM en una oración:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Usando el cliente de Python de OpenAI:

from openai import OpenAI

# Puntar a tu servidor vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM no requiere autenticación por defecto
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Explica qué es vLLM en una oración:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API de Completaciones de Chat:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Eres un asistente útil."},
        {"role": "user", "content": "¿Qué es PagedAttention?"}
    ],
    max_tokens=200
)

print(response.choices[0].message.content)

Configuración Avanzada

vLLM ofrece muchos parámetros para optimizar el rendimiento:

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Usar el 95% de la memoria de la GPU
    --max-model-len 8192 \            # Longitud máxima de secuencia
    --tensor-parallel-size 2 \        # Usar 2 GPUs con paralelismo de tensores
    --dtype float16 \                 # Usar precisión FP16
    --max-num-seqs 256                # Tamaño máximo de lote

Explicación de Parámetros Clave:

• --gpu-memory-utilization: Cuánta memoria de la GPU usar (0.90 = 90%). Valores más altos permiten lotes más grandes pero dejan menos margen para picos de memoria.
• --max-model-len: Longitud máxima de contexto. Reducir esto ahorra memoria para lotes más grandes.
• --tensor-parallel-size: Número de GPUs para dividir el modelo.
• --dtype: Tipo de datos para los pesos (float16, bfloat16 o float32). FP16 suele ser óptimo.
• --max-num-seqs: Número máximo de secuencias para procesar en un lote.

Comparación entre vLLM y Ollama

Tanto vLLM como Ollama son opciones populares para el alojamiento local de LLM, pero se centran en casos de uso diferentes. Entender cuándo usar cada herramienta puede tener un impacto significativo en el éxito de tu proyecto.

Rendimiento y Tránsito

vLLM está diseñado para el máximo tránsito en escenarios con múltiples usuarios. Su algoritmo PagedAttention y empaquetamiento continuo permiten servir eficientemente cientos de solicitudes concurrentes. Los benchmarks muestran que vLLM logra un tránsito 14-24 veces mayor que las implementaciones estándar y 2-4 veces mayor que Ollama bajo alta concurrencia.

Ollama optimiza para uso interactivo con un solo usuario, enfocándose en baja latencia para solicitudes individuales. Aunque no iguala el tránsito de vLLM para múltiples usuarios, proporciona un excelente rendimiento para desarrollo y uso personal con tiempos de inicio más rápidos y menor consumo de recursos en estado inactivo.

Facilidad de Uso

Ollama gana claramente en simplicidad. La instalación es un solo comando (curl | sh), y ejecutar modelos es tan simple como ollama run llama2. Incluye una biblioteca de modelos con versiones cuantizadas optimizadas para diferentes perfiles de hardware. La experiencia del usuario se asemeja a Docker – extraer, ejecutar y seguir adelante.

vLLM requiere más configuración: gestión del entorno de Python, instalación de CUDA, comprensión de parámetros de servicio y especificación manual del modelo. La curva de aprendizaje es más empinada, pero obtienes un control fino sobre la optimización del rendimiento. Esta complejidad es justificada para despliegues en producción donde necesitas extraer el máximo rendimiento de tu hardware.

API e Integración

vLLM proporciona APIs REST compatibles con OpenAI de forma nativa, convirtiéndose en una sustitución plug-and-play para la API de OpenAI en aplicaciones existentes. Esto es crucial para migrar servicios de producción de proveedores en la nube a infraestructura autoalojada sin cambios en el código.

Ollama ofrece una API REST más simple y una biblioteca dedicada para Python/JavaScript. Aunque funcional, no es compatible con OpenAI, requiriendo cambios en el código al integrar con aplicaciones que esperan el formato de OpenAI. Sin embargo, proyectos comunitarios como adaptadores Ollama-OpenAI puentean este gap.

Gestión de Memoria

El algoritmo PagedAttention de vLLM proporciona una eficiencia de memoria superior para solicitudes concurrentes. Puede servir 2-4 veces más usuarios concurrentes con la misma VRAM comparado con implementaciones naivas. Esto se traduce directamente en ahorros de costo en despliegues de producción.

Ollama usa una gestión de memoria más simple adecuada para escenarios de un solo usuario. Gestiona automáticamente la carga y descarga de modelos según la actividad, lo cual es conveniente para desarrollo pero no óptimo para uso de alta concurrencia en producción.

Soporte Multigpu

vLLM destaca con paralelismo nativo de tensores y canalización, distribuyendo eficientemente modelos entre 2-8+ GPUs. Esto es esencial para servir modelos grandes como LLMs de 70B parámetros que no caben en la memoria de una sola GPU.

Ollama actualmente tiene un soporte limitado para múltiples GPUs, funcionando mejor principalmente con una sola GPU. Esto lo hace menos adecuado para modelos muy grandes que requieren inferencia distribuida.

Recomendaciones para Casos de Uso

Elige vLLM cuando:

• Servir APIs de producción con muchos usuarios concurrentes
• Optimizar el costo por solicitud en despliegues en la nube
• Ejecutar en Kubernetes o plataformas de orquestación de contenedores
• Necesitar compatibilidad con la API de OpenAI para aplicaciones existentes
• Servir modelos grandes que requieren soporte multigpu
• El rendimiento y el tránsito son requisitos críticos

Elige Ollama cuando:

• Desarrollo local y experimentación
• Uso interactivo con un solo usuario (asistentes personales, chatbots)
• Prototipado rápido y evaluación de modelos
• Aprender sobre LLMs sin complejidad de infraestructura
• Ejecutar en computadoras personales o laptops
• Priorizar simplicidad y facilidad de uso

Muchos equipos usan ambos: Ollama para desarrollo y experimentación, luego vLLM para despliegue en producción. Esta combinación proporciona productividad del desarrollador mientras se mantiene el rendimiento en producción.

Comparación entre vLLM y Docker Model Runner

Docker recientemente introdujo Model Runner (anteriormente GenAI Stack) como su solución oficial para el despliegue local de modelos de IA. ¿Cómo se compara con vLLM?

Filosofía de Arquitectura

Docker Model Runner busca ser el “Docker para IA” – una forma simple y estandarizada de ejecutar modelos de IA localmente con la misma facilidad que ejecutar contenedores. Abstrae la complejidad y proporciona una interfaz coherente a través de diferentes modelos y marcos.

vLLM es un motor de inferencia especializado enfocado únicamente en el servicio de LLM con máximo rendimiento. Es una herramienta de nivel inferior que contenerizas con Docker, en lugar de una plataforma completa.

Configuración y Comienzo

Docker Model Runner la instalación es sencilla para usuarios de Docker:

docker model pull llama3:8b
docker model run llama3:8b

Esta similitud con el flujo de trabajo de imágenes de Docker hace que sea inmediatamente familiar para desarrolladores que ya usan contenedores.

vLLM requiere más configuración inicial (Python, CUDA, dependencias) o usar imágenes Docker preconstruidas:

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-name>

Características de Rendimiento

vLLM entrega un tránsito superior para escenarios con múltiples usuarios debido a PagedAttention y empaquetamiento continuo. Para servicios de API de producción que manejan cientos de solicitudes por segundo, las optimizaciones de vLLM proporcionan un 2-5 veces mejor tránsito que enfoques generales de servicio.

Docker Model Runner se centra en la facilidad de uso en lugar del máximo rendimiento. Es adecuado para desarrollo local, pruebas y cargas de trabajo moderadas, pero no implementa las optimizaciones avanzadas que hacen destacar a vLLM a gran escala.

Soporte de Modelos

Docker Model Runner proporciona una biblioteca de modelos curada con acceso de un solo comando a modelos populares. Soporta múltiples marcos (no solo LLMs) incluyendo Stable Diffusion, Whisper y otros modelos de IA, lo que lo hace más versátil para diferentes cargas de trabajo de IA.

vLLM se especializa en la inferencia de LLM con un profundo soporte para modelos de lenguaje basados en transformadores. Soporta cualquier modelo de LLM compatible con HuggingFace pero no se extiende a otros tipos de modelos de IA como generación de imágenes o reconocimiento de voz.

Despliegue en Producción

vLLM está probado en producción en empresas como Anthropic, Replicate y muchas otras que sirven miles de millones de tokens diariamente. Sus características de rendimiento y estabilidad bajo carga pesada lo hacen el estándar de facto para el servicio de LLM en producción.

Docker Model Runner es más nuevo y se posiciona más para escenarios de desarrollo y pruebas locales. Aunque podría servir tráfico de producción, carece del historial comprobado y optimizaciones de rendimiento que requieren los despliegues de producción.

Ecosistema de Integración

vLLM se integra con herramientas de infraestructura de producción: operadores de Kubernetes, métricas de Prometheus, Ray para servir distribuido y una amplia compatibilidad con la API de OpenAI para aplicaciones existentes.

Docker Model Runner se integra naturalmente con el ecosistema de Docker y Docker Desktop. Para equipos ya estandarizados en Docker, esta integración proporciona una experiencia cohesiva pero con menos características especializadas para el servicio de LLM.

Cuándo Usar Cada Uno

Use vLLM para:

• Servicios de API de LLM en producción
• Despliegues de alta capacidad con múltiples usuarios
• Despliegues en la nube con sensibilidad al costo que necesitan máxima eficiencia
• Entornos de Kubernetes y nativos en la nube
• Cuando necesitas escalabilidad y rendimiento comprobados

Use Docker Model Runner para:

• Desarrollo y pruebas locales
• Ejecutar varios tipos de modelos de IA (no solo LLMs)
• Equipos profundamente invertidos en el ecosistema de Docker
• Experimentación rápida sin configuración de infraestructura
• Propósitos educativos y de aprendizaje

Enfoque Híbrido: Muchos equipos desarrollan con Docker Model Runner localmente para comodidad, luego despliegan con vLLM en producción para el rendimiento. Las imágenes de Docker Model Runner también pueden usarse para ejecutar contenedores de vLLM, combinando ambos enfoques.

Mejores Prácticas para Despliegue en Producción

Despliegue con Docker

Crea una configuración Docker Compose lista para producción:

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Despliegue en Kubernetes

Despliega vLLM en Kubernetes para escala de producción:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

Monitoreo y Observabilidad

vLLM expone métricas de Prometheus para monitoreo:

import requests

# Obtener métricas
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Métricas clave para monitorear:

• vllm:num_requests_running - Solicitudes activas
• vllm:gpu_cache_usage_perc - Uso de caché de GPU
• vllm:time_to_first_token - Métrica de latencia
• vllm:time_per_output_token - Velocidad de generación

Optimización de Rendimiento

Optimizar el Uso de Memoria de GPU: Comience con --gpu-memory-utilization 0.90 y ajuste según el comportamiento observado. Valores más altos permiten lotes más grandes pero corren el riesgo de errores OOM durante picos de tráfico.

Ajustar la Longitud Máxima de Secuencia: Si su caso de uso no necesita longitud completa de contexto, reduzca --max-model-len. Esto libera memoria para lotes más grandes. Por ejemplo, si solo necesita 4K de contexto, establezca --max-model-len 4096 en lugar de usar la longitud máxima del modelo (a menudo 8K-32K).

Elegir la Cuantización Apropiada: Para modelos que lo soporten, use versiones cuantizadas (8-bit, 4-bit) para reducir la memoria y aumentar el tránsito:

--quantization awq  # Para modelos cuantizados AWQ
--quantization gptq # Para modelos cuantizados GPTQ

Habilitar Caché de Prefijos: Para aplicaciones con prompts repetidos (como chatbots con mensajes de sistema), habilite el caché de prefijos:

--enable-prefix-caching

Esto almacena los valores KV para prefijos comunes, reduciendo la computación para solicitudes que comparten el mismo prefijo de prompt.

Solución de Problemas Comunes

Errores de Memoria Insuficiente

Síntomas: El servidor se cae con errores de memoria de CUDA.

Soluciones:

• Reduzca --gpu-memory-utilization a 0.85 o 0.80
• Disminuya --max-model-len si su caso de uso lo permite
• Baje --max-num-seqs para reducir el tamaño del lote
• Use una versión cuantizada del modelo
• Habilite paralelismo de tensores para distribuir en más GPUs

Bajo Tránsito

Síntomas: El servidor maneja menos solicitudes de lo esperado.

Soluciones:

• Aumente --max-num-seqs para permitir lotes más grandes
• Eleve --gpu-memory-utilization si tiene margen
• Verifique si el CPU es el cuello de botella con htop – considere CPUs más rápidas
• Verifique la utilización de GPU con nvidia-smi – debe ser 95%+
• Habilite FP16 si está usando FP32: --dtype float16

Tiempo de Primer Token Lento

Síntomas: Alta latencia antes de que comience la generación.

Soluciones:

• Use modelos más pequeños para aplicaciones críticas de latencia
• Habilite el caché de prefijos para prompts repetidos
• Reduzca --max-num-seqs para priorizar latencia sobre tránsito
• Considere la decodificación especulativa para modelos compatibles
• Optimice la configuración de paralelismo de tensores

Errores de Carga de Modelo

Síntomas: El servidor no puede iniciar, no puede cargar el modelo.

Soluciones:

• Verifique que el nombre del modelo coincida exactamente con el formato de HuggingFace
• Verifique la conectividad de red a HuggingFace Hub
• Asegúrese de que haya suficiente espacio en disco en ~/.cache/huggingface
• Para modelos restringidos, establezca la variable de entorno HF_TOKEN
• Intente descargar manualmente con huggingface-cli download <model>

Características Avanzadas

Decodificación Especulativa

vLLM admite decodificación especulativa, donde un modelo más pequeño propone tokens que un modelo objetivo más grande verifica. Esto puede acelerar la generación en un 1,5-2 veces:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

Adaptadores LoRA

Sirve múltiples adaptadores LoRA sobre un modelo base sin cargar múltiples modelos completos:

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Luego especifique qué adaptador usar por solicitud:

response = client.completions.create(
    model="sql-lora",  # Use the SQL adapter
    prompt="Convierte esto a SQL: Muestra a todos los usuarios creados este mes"
)

Servicio Multi-LoRA

El servicio multi-LoRA de vLLM permite alojar docenas de adaptadores finos con mínimo sobrecoste de memoria. Esto es ideal para servir variantes de modelos específicas de clientes o tareas:

# Solicitud con adaptador LoRA específico
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Escribe una consulta SQL"}],
    extra_body={"lora_name": "sql-lora"}
)

Caché de Prefijos

Habilite el caché de prefijos automático para evitar recomputar la caché KV para prefijos de prompt repetidos:

--enable-prefix-caching

Esto es especialmente efectivo para:

• Chatbots con mensajes de sistema fijos
• Aplicaciones RAG con plantillas de contexto consistentes
• Prompts de aprendizaje por pocos ejemplos repetidos en solicitudes

El caché de prefijos puede reducir el tiempo hasta el primer token en un 50-80% para solicitudes que comparten prefijos de prompt.

Ejemplos de Integración

Integración con LangChain

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Explica PagedAttention en términos simples")
print(response)

Integración con LlamaIndex

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("¿Qué es vLLM?")
print(response)

Aplicación FastAPI

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Benchmarks de Rendimiento

Datos de rendimiento reales ayudan a ilustrar las ventajas de vLLM:

Comparación de Tránsito (Mistral-7B en GPU A100):

• vLLM: ~3,500 tokens/segundo con 64 usuarios concurrentes
• HuggingFace Transformers: ~250 tokens/segundo con la misma concurrencia
• Ollama: ~1,200 tokens/segundo con la misma concurrencia
• Resultado: vLLM proporciona una mejora de 14 veces sobre las implementaciones básicas

Eficiencia de Memoria (LLaMA-2-13B):

• Implementación estándar: 24GB VRAM, 32 secuencias concurrentes
• vLLM con PagedAttention: 24GB VRAM, 128 secuencias concurrentes
• Resultado: 4 veces más solicitudes concurrentes con la misma memoria

Latencia bajo Carga (Mixtral-8x7B en 2xA100):

• vLLM: Latencia P50 180ms, P99 420ms a 100 req/s
• Servicio estándar: Latencia P50 650ms, P99 3,200ms a 100 req/s
• Resultado: vLLM mantiene latencia consistente bajo alta carga

Estos benchmarks demuestran por qué vLLM se ha convertido en el estándar de facto para el servicio de LLM en producción donde el rendimiento importa.

Análisis de Costos

Entender las implicaciones de costo al elegir vLLM:

Escenario: Servir 1M solicitudes/día

Con Servicio Estándar:

• Requerido: 8x GPUs A100 (80GB)
• Costo en AWS: ~$32/hora × 24 × 30 = $23,040/mes
• Costo por 1M tokens: ~$0.75

Con vLLM:

• Requerido: 2x GPUs A100 (80GB)
• Costo en AWS: ~$8/hora × 24 × 30 = $5,760/mes
• Costo por 1M tokens: ~$0.19
• Ahorro: $17,280/mes (75% reducción)

Esta ventaja de costo crece con la escala. Las organizaciones que sirven miles de millones de tokens mensuales ahorran cientos de miles de dólares usando el servicio optimizado de vLLM en lugar de implementaciones básicas.

Consideraciones de Seguridad

Autenticación

vLLM no incluye autenticación por defecto. Para producción, implemente la autenticación en el nivel del proxy inverso:

# Configuración de Nginx
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

O use pasarelas de API como Kong, Traefik o AWS API Gateway para autenticación y limitación de tasa de nivel empresarial.

Aislamiento de Red

Ejecute vLLM en redes privadas, no expuesto directamente a Internet:

# Ejemplo de NetworkPolicy de Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

Limitación de Tasa

Implemente limitación de tasa para prevenir abusos:

# Ejemplo usando Redis para limitación de tasa
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # Ventana de 60 segundos
    
    if requests > 60:  # 60 solicitudes por minuto
        raise HTTPException(status_code=429, detail="Límite de tasa excedido")
    
    return await call_next(request)

Control de Acceso a Modelos

Para despliegues multiinquilino, controle qué usuarios pueden acceder a qué modelos:

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Todos los modelos
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

Guía de Migración

De OpenAI a vLLM

Migrar de OpenAI a vLLM autoalojado es sencillo gracias a la compatibilidad de la API:

Antes (OpenAI):

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Hola"}]
)

Después (vLLM):

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Si añadiste autenticación
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hola"}]
)

Solo dos cambios necesarios: actualizar base_url y model name. Todo el resto del código permanece igual.

De Ollama a vLLM

Ollama usa un formato de API diferente. Aquí está la conversión:

API de Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': '¿Por qué es azul el cielo?'
    })

Equivalente de vLLM:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="¿Por qué es azul el cielo?"
)

Necesitarás actualizar las llamadas API a través de tu código base, pero las bibliotecas de cliente de OpenAI proporcionan un mejor manejo de errores y características.

De HuggingFace Transformers a vLLM

Migración directa de uso en Python:

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("Hola", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Hola", sampling_params)
result = outputs[0].outputs[0].text

La API de Python de vLLM es más simple y mucho más rápida para inferencia por lotes.

Futuro de vLLM

vLLM continúa su desarrollo rápido con características emocionantes en el roadmap:

Servicio Desagregado: Separar el prellenado (procesamiento de prompts) y el descodificación (generación de tokens) en diferentes GPUs para optimizar la utilización de recursos. El prellenado es limitado por cálculo mientras que la descodificación es limitada por memoria, por lo que ejecutarlos en hardware especializado mejora la eficiencia.

Inferencia Multinodo: Distribuir modelos muy grandes (100B+ parámetros) entre múltiples máquinas, permitiendo el servicio de modelos demasiado grandes para configuraciones de un solo nodo.

Mejora de Cuantización: Soporte para nuevos formatos de cuantización como GGUF (usado por llama.cpp) e integración mejorada de AWQ/GPTQ para un mejor rendimiento con modelos cuantizados.

Mejoras en Decodificación Especulativa: Modelos de borrador más eficientes y estrategias adaptativas de especulación para lograr mayores aceleraciones sin pérdida de precisión.

Optimizaciones de Atención: FlashAttention 3, atención en anillo para contextos extremadamente largos (100K+ tokens) y otros mecanismos de atención de vanguardia.

Mejor Cobertura de Modelos: Expandir el soporte a modelos multimodales (modelos de lenguaje y visión), modelos de audio y arquitecturas especializadas a medida que surjan.

El proyecto vLLM mantiene desarrollo activo con contribuciones de UC Berkeley, Anyscale y la comunidad de código abierto más amplia. A medida que el despliegue de LLM se vuelva más crítico para los sistemas de producción, el papel de vLLM como estándar de rendimiento continúa creciendo. Para una comparación más amplia de vLLM con otras infraestructuras locales y en la nube de LLM, consulte nuestro LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

Enlaces Útiles

Artículos Relacionados en Este Sitio

• Anfitrion en Local de LLM: Guía Completa 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio & Más - Comparación completa de 12+ herramientas para alojar LLM en local, incluyendo un análisis detallado de vLLM junto con Ollama, LocalAI, Jan, LM Studio y otros. Cubre la madurez de la API, el soporte para llamada de herramientas, la compatibilidad con GGUF y los benchmarks de rendimiento para ayudar a elegir la solución adecuada.

• Guía de Comandos de Ollama - Referencia completa de comandos de Ollama y guía de trucos que cubre la instalación, el manejo de modelos, el uso de la API y las mejores prácticas para el despliegue local de LLM. Esencial para desarrolladores que usan Ollama junto con o en lugar de vLLM.

• Docker Model Runner vs Ollama: ¿Cuál Elegir? - Comparación detallada del Model Runner de Docker y Ollama para el despliegue local de LLM, analizando el rendimiento, el soporte de GPU, la compatibilidad de API y los casos de uso. Ayuda a entender el entorno competitivo en el que opera vLLM.

• Guía de Comandos de Docker Model Runner: Ejemplos y Comandos - Guía práctica de Docker Model Runner con comandos y ejemplos para el despliegue de modelos de IA. Útil para equipos que comparan el enfoque de Docker con las capacidades especializadas de servir LLM de vLLM.

Recursos Externos y Documentación

• Repositorio de GitHub de vLLM - Repositorio oficial de vLLM con código fuente, documentación completa, guías de instalación y discusiones activas de la comunidad. Recurso esencial para mantenerse actualizado con las últimas características y solucionar problemas.

• Documentación de vLLM - Documentación oficial que cubre todos los aspectos de vLLM desde la configuración básica hasta la configuración avanzada. Incluye referencias de API, guías de optimización de rendimiento y mejores prácticas de despliegue.

• Paper de PagedAttention - Artículo académico que introduce el algoritmo PagedAttention que impulsa la eficiencia de vLLM. Lectura esencial para comprender las innovaciones técnicas detrás de las ventajas de rendimiento de vLLM.

• Blog de vLLM - Blog oficial de vLLM con anuncios de lanzamiento, benchmarks de rendimiento, análisis técnicos profundos y estudios de caso de la comunidad de despliegues en producción.

• HuggingFace Model Hub - Repositorio completo de modelos de LLM de código abierto compatibles con vLLM. Busque modelos por tamaño, tarea, licencia y características de rendimiento para encontrar el modelo adecuado para su caso de uso.

• Documentación de Ray Serve - Documentación del marco Ray Serve para construir despliegues escalables y distribuidos de vLLM. Ray proporciona características avanzadas como escalado automático, servicio de múltiples modelos y gestión de recursos para sistemas de producción.

• TensorRT-LLM de NVIDIA - TensorRT-LLM de NVIDIA para inferencia altamente optimizada en GPUs de NVIDIA. Alternativa a vLLM con estrategias de optimización diferentes, útil para comparación y comprensión del paisaje de optimización de inferencia.

• Referencia de API de OpenAI - Documentación oficial de la API de OpenAI con la cual la API de vLLM es compatible. Refiérase a esta documentación al construir aplicaciones que necesiten trabajar con endpoints de OpenAI y vLLM alojados localmente de forma intercambiable.