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 Grandes (LLM), desarrollado por el Laboratorio de Computación Sky de la Universidad de California, Berkeley.

Con su revolucionario algoritmo PagedAttention, vLLM logra una productividad 14-24 veces mayor que los métodos de servicio tradicionales, convirtiéndose en la opción preferida para implementaciones de LLM en producción. Para ver cómo encaja vLLM entre Ollama, Docker Model Runner, LocalAI y proveedores en la nube, incluyendo los intercambios de costes y recursos, consulte Alojamiento de LLM: Local, Autoalojado y Comparativa de Infraestructura en la Nube.

¿Qué es vLLM?

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

Características Principales

Rendimiento de Alto Throughput: vLLM ofrece un rendimiento 14-24 veces mayor en comparación con HuggingFace Transformers con el mismo hardware. Esta gran mejora de rendimiento proviene del agrupamiento continuo (continuous batching), kernels de CUDA optimizados y el algoritmo PagedAttention que elimina la fragmentación de memoria.

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

Algoritmo PagedAttention: La innovación central 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 los cachés KV (lo que lleva a la fragmentación), PagedAttention divide la memoria en bloques de tamaño fijo que se pueden asignar bajo demanda. Esto reduce el desperdicio de memoria hasta en un 4x y permite tamaños de lote mucho mayores.

Agrupamiento Continuo: A diferencia del agrupamiento estático donde espera a que todas las secuencias se completen, vLLM utiliza un agrupamiento continuo (o rodante). Tan pronto como una secuencia termina, una nueva se puede agregar al lote. Esto maximiza la utilización de la GPU y minimiza la latencia para las solicitudes entrantes.

Soporte Multi-GPU: vLLM soporta paralelismo de tensor y paralelismo de pipeline para distribuir modelos grandes a través de múltiples GPUs. Puede servir eficientemente modelos que no caben en la memoria de una sola GPU, soportando configuraciones de 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 para instrucciones como modelos base de HuggingFace Hub.

Cuándo Usar vLLM

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

Servicios de API en Producción: Cuando necesita servir un LLM a muchos usuarios concurrentes a través de una API, el alto rendimiento y el agrupamiento eficiente de vLLM lo convierten en la mejor opción. Las empresas que ejecutan chatbots, asistentes de código o servicios de generación de contenido se benefician de su capacidad para manejar cientos de solicitudes por segundo.

Cargas de Trabajo de Alta Concurrencia: Si su aplicación tiene muchos usuarios simultáneos haciendo solicitudes, el agrupamiento continuo y PagedAttention de vLLM permiten servir a más usuarios con el mismo hardware en comparación con las alternativas.

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

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

Cuándo NO Usar vLLM: Para desarrollo local, experimentación o escenarios de un solo usuario, herramientas como Ollama o llama.cpp ofrecen una mejor experiencia de usuario con una configuración más sencilla. La complejidad de vLLM está justificada cuando necesita sus ventajas de rendimiento para cargas de trabajo en producción.

Cómo Instalar vLLM

Prerrequisitos

Antes de instalar vLLM, asegúrese de que su sistema cumple con estos requisitos:

• GPU: GPU NVIDIA con capacidad de cómputo 7.0+ (V100, T4, A10, A100, H100, series RTX 20/30/40)
• 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 superior

Instalación vía pip

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

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

# Instalar vLLM
pip install vllm

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

Para sistemas con versiones de CUDA diferentes, instale el wheel apropiado:

# 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 de implementación más fiable, especialmente para producción:

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

# Ejecutar vLLM con soporte de 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 multi-GPU ya que habilita la comunicación interproceso adecuada.

Compilación desde el código fuente

Para las últimas funciones o modificaciones personalizadas, compile desde el código fuente:

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

Guía de Inicio Rápido de vLLM

Ejecutando su Primer Modelo

Inicie 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á en caché) e iniciará el servidor. Verá 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

Hacer Solicitudes API

Una vez que el servidor esté ejecutándose, puede 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": "Explique qué es vLLM en una oración:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Usando el Cliente Python de OpenAI:

from openai import OpenAI

# Apuntar a su 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="Explique 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 numerosos 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 GPU
    --max-model-len 8192 \            # Longitud de secuencia máxima
    --tensor-parallel-size 2 \        # Usar 2 GPUs con paralelismo de tensor
    --dtype float16 \                 # Usar precisión FP16
    --max-num-seqs 256                # Tamaño de lote máximo

Parámetros Clave Explicados:

• --gpu-memory-utilization: Cuánta memoria 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 del contexto. Reducir esto ahorra memoria para lotes más grandes.
• --tensor-parallel-size: Número de GPUs para dividir el modelo a través.
• --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 vLLM vs Ollama

Tanto vLLM como Ollama son opciones populares para el alojamiento local de LLM, pero apuntan a casos de uso diferentes. Entender cuándo usar cada herramienta puede impactar significativamente el éxito de su proyecto.

Rendimiento y Throughput

vLLM está diseñado para un throughput máximo en escenarios multiusuario. Su PagedAttention y agrupamiento continuo permiten servir cientos de solicitudes concurrentes de manera eficiente. Los resultados de pruebas muestran que vLLM logra un throughput 14-24 veces mayor que las implementaciones estándar y 2-4 veces mayor que Ollama bajo alta concurrencia.

Ollama se optimiza para el uso interactivo de un solo usuario con enfoque en baja latencia para solicitudes individuales. Aunque no iguala el throughput multiusuario de vLLM, proporciona un excelente rendimiento para desarrollo y uso personal con tiempos de inicio en frío más rápidos y menor consumo de recursos en inactividad.

Facilidad de Uso

Ollama gana decisivamente 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 de usuario se asemeja a Docker: obtener, ejecutar y listo.

vLLM requiere más configuración: gestión de entorno 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 gana control fino sobre la optimización de rendimiento. Esta complejidad está justificada para implementaciones en producción donde necesita exprimir el máximo rendimiento de su hardware.

API e Integración

vLLM proporciona APIs REST compatibles con OpenAI de forma nativa, convirtiéndolo en un reemplazo directo para la API de OpenAI en aplicaciones existentes. Esto es crucial para migrar servicios de producción desde proveedores de la nube a infraestructura autoalojada sin cambios de código.

Ollama ofrece una API REST más sencilla y una biblioteca dedicada de Python/JavaScript. Aunque funcional, no es compatible con OpenAI, requiriendo cambios de código al integrar con aplicaciones que esperan el formato de OpenAI. Sin embargo, proyectos de la comunidad como adaptadores Ollama-OpenAI cubren esta brecha.

Gestión de Memoria

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 en comparación con implementaciones ingenuas. Esto se traduce directamente en ahorros de costes en implementaciones en producción.

Ollama utiliza una gestión de memoria más sencilla adecuada para escenarios de un solo usuario. Gestiona automáticamente la carga/descarga de modelos basándose en la actividad, lo cual es conveniente para el desarrollo pero no óptimo para uso de producción de alta concurrencia.

Soporte Multi-GPU

vLLM destaca con paralelismo de tensor nativo y paralelismo de pipeline, distribuyendo eficientemente modelos a través de 2-8+ GPUs. Esto es esencial para servir modelos grandes como LLM de 70B parámetros que no caben en una sola GPU.

Ollama actualmente tiene soporte limitado multi-GPU, funcionando mejor principalmente con una sola GPU. Esto lo hace menos adecuado para modelos muy grandes que requieren inferencia distribuida.

Recomendaciones de Caso de Uso

Elija vLLM cuando:

• Sirviendo APIs de producción con muchos usuarios concurrentes
• Optimizando coste por solicitud en implementaciones en la nube
• Ejecutando en Kubernetes o plataformas de orquestación de contenedores
• Necesita compatibilidad con API de OpenAI para aplicaciones existentes
• Sirviendo modelos grandes que requieren soporte multi-GPU
• El rendimiento y throughput son requisitos críticos

Elija Ollama cuando:

• Desarrollo local y experimentación
• Uso interactivo de un solo usuario (asistentes personales, chatbots)
• Prototipado rápido y evaluación de modelos
• Aprendizaje sobre LLM sin complejidad de infraestructura
• Ejecutando en estaciones de trabajo personales o laptops
• La simplicidad y facilidad de uso son prioridades

Muchos equipos usan ambos: Ollama para desarrollo y experimentación, luego vLLM para implementación en producción. Esta combinación proporciona productividad del desarrollador manteniendo el rendimiento de producción.

vLLM vs 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 pretende ser el “Docker para IA” – una forma sencilla y estandarizada de ejecutar modelos de IA localmente con la misma facilidad que ejecutar contenedores. Abstrae la complejidad y proporciona una interfaz consistente 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 Primeros Pasos

La instalación de Docker Model Runner 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 lo hace instantáneamente 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 <nombre-del-modelo>

Características de Rendimiento

vLLM ofrece un throughput superior para escenarios multiusuario debido a PagedAttention y agrupamiento continuo. Para servicios de API de producción que manejan cientos de solicitudes por segundo, las optimizaciones de vLLM proporcionan 2-5 veces mejor throughput que enfoques de servicio genéricos.

Docker Model Runner se enfoca 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 que vLLM destaque a 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 LLM) incluyendo Stable Diffusion, Whisper y otros modelos de IA, haciéndolo más versátil para diferentes cargas de trabajo de IA.

vLLM se especializa en la inferencia de LLM con soporte profundo para modelos de lenguaje basados en transformadores. Soporta cualquier 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.

Implementación en Producción

vLLM ha sido probado en producción en compañías como Anthropic, Replicate y muchas otras sirviendo miles de millones de tokens diariamente. Sus características de rendimiento y estabilidad bajo carga pesada lo convierten en 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 probado y las optimizaciones de rendimiento que requieren las implementaciones en 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 servicio distribuido y extensa compatibilidad con 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 menos características especializadas de servicio de LLM.

Cuándo Usar Cada Uno

Use vLLM para:

• Servicios de API de LLM en producción
• Implementaciones multiusuario de alto throughput
• Implementaciones en la nube sensibles al coste que necesitan máxima eficiencia
• Entornos nativos de la nube y Kubernetes
• Cuando necesita escalabilidad y rendimiento probados

Use Docker Model Runner para:

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

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

Mejores Prácticas de Implementación en Producción

Despliegue con Docker

Cree una configuración de 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

Despliegue 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 - Utilización de caché KV
• vllm:time_to_first_token - Métrica de latencia
• vllm:time_per_output_token - Velocidad de generación

Ajuste de Rendimiento

Optimice la Utilización de Memoria 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 riesgo de errores OOM durante picos de tráfico.

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

Elija Cuantización Adecuada: Para modelos que lo soporten, use versiones cuantizadas (8-bit, 4-bit) para reducir memoria y aumentar throughput:

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

Habilite Caché de Prefijo: Para aplicaciones con prompts repetidos (como chatbots con mensajes del sistema), habilite el caché de prefijo:

--enable-prefix-caching

Esto almacena en caché los valores KV para prefijos comunes, reduciendo el cómputo para solicitudes que comparten el mismo prefijo de prompt.

Solución de Problemas Comunes

Errores de Agotamiento de Memoria

Síntomas: El servidor se cae con errores de CUDA out of memory.

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 de modelo cuantizada
• Habilite el paralelismo de tensor para distribuir en más GPUs

Bajo Throughput

Síntomas: El servidor maneja menos solicitudes de las esperadas.

Soluciones:

• Aumente --max-num-seqs para permitir lotes más grandes
• Eleve --gpu-memory-utilization si tiene margen
• Verifique si la CPU es un cuello de botella con htop – considere CPUs más rápidas
• Verifique la utilización de GPU con nvidia-smi – debería 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 caché de prefijo para prompts repetidos
• Reduzca --max-num-seqs para priorizar latencia sobre throughput
• Considere descodificación especulativa para modelos compatibles
• Optimice la configuración de paralelismo de tensor

Fallos de Carga de Modelo

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

Soluciones:

• Verifique que el nombre del modelo coincida exactamente con el formato de HuggingFace
• Verifique la conectividad de red al HuggingFace Hub
• Asegure suficiente espacio en disco en ~/.cache/huggingface
• Para modelos con acceso restringido, establezca la variable de entorno HF_TOKEN
• Pruebe descargar manualmente con huggingface-cli download <modelo>

Características Avanzadas

Descodificación Especulativa

vLLM soporta descodificación especulativa, donde un modelo borrador más pequeño propone tokens que un modelo objetivo más grande verifica. Esto puede acelerar la generación en 1.5-2x:

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

Sirva 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=./ruta/al/adapter-de-sql \
                   code-lora=./ruta/al/adapter-de-codigo

Luego especifique qué adaptador usar por solicitud:

response = client.completions.create(
    model="sql-lora",  # Use el adaptador SQL
    prompt="Convierta esto a SQL: Muéstrame todos los usuarios creados este mes"
)

Servicio Multi-LoRA

El servicio multi-LoRA de vLLM permite alojar docenas de adaptadores ajustados finamente con mínima sobrecarga de memoria. Esto es ideal para servir variantes de modelos específicas de cliente o tarea:

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

Caché de Prefijo

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

--enable-prefix-caching

Esto es particularmente efectivo para:

• Chatbots con prompts del sistema fijos
• Aplicaciones RAG con plantillas de contexto consistentes
• Prompts de aprendizaje few-shot repetidos a través de solicitudes

El caché de prefijo puede reducir el tiempo al 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("Explique 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

Los datos de rendimiento del mundo real ayudan a ilustrar las ventajas de vLLM:

Comparación de Throughput (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 14x sobre 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, Latencia P99 420ms a 100 req/s
• Servicio estándar: Latencia P50 650ms, Latencia 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 Costes

Entender las implicaciones de costes de elegir vLLM:

Escenario: Servir 1M solicitudes/día

Con Servicio Estándar:

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

Con vLLM:

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

Esta ventaja de costes crece con la escala. Las organizaciones que sirven miles de millones de tokens mensualmente ahorran cientos de miles de dólares usando el servicio optimizado de vLLM en lugar de implementaciones ingenuas.

Consideraciones de Seguridad

Autenticación

vLLM no incluye autenticación por defecto. Para producción, implemente autenticación en el nivel de 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 API como Kong, Traefik o AWS API Gateway para autenticación de nivel empresarial y limitación de velocidad.

Aislamiento de Red

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

# Ejemplo de Kubernetes NetworkPolicy
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 Velocidad (Rate Limiting)

Implemente limitación de velocidad para prevenir abuso:

# Ejemplo usando Redis para limitación de velocidad
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 velocidad excedido")
    
    return await call_next(request)

Control de Acceso a Modelos

Para implementaciones 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 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ñadió autenticación
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hola"}]
)

Solo dos cambios necesarios: actualice base_url y el nombre del modelo. Todo el otro código permanece idéntico.

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é el cielo es azul?'
    })

Equivalente 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é el cielo es azul?"
)

Necesitará actualizar las llamadas API en toda su base de código, pero las bibliotecas cliente de OpenAI proporcionan mejor manejo de errores y características.

De HuggingFace Transformers a vLLM

Migración de uso directo de 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 sencilla y mucho más rápida para inferencia por lotes.

Futuro de vLLM

vLLM continúa un desarrollo rápido con características emocionantes en la hoja de ruta:

Servicio Disagregado: Separar el relleno (procesamiento de prompt) y la descodificación (generación de tokens) en diferentes GPUs para optimizar la utilización de recursos. El relleno es computacionalmente intensivo mientras que la descodificación es intensiva en memoria, por lo que ejecutarlos en hardware especializado mejora la eficiencia.

Inferencia Multi-Nodo: Distribuir modelos muy grandes (100B+ parámetros) a través de múltiples máquinas, habilitando el servicio de modelos demasiado grandes para configuraciones de un solo nodo.

Cuantización Mejorada: Soporte para nuevos formatos de cuantización como GGUF (usado por llama.cpp) y mejora de la integración AWQ/GPTQ para mejor rendimiento con modelos cuantizados.

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

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

Mejor Cobertura de Modelos: Expansión del soporte a modelos multimodales (modelos de visión-lenguaje), 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 vuelve más crítico para 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 otra infraestructura de LLM local y en la nube, consulte nuestra Alojamiento de LLM: Local, Autoalojado y Comparativa de Infraestructura en la Nube.

Enlaces Útiles

Artículos Relacionados en Este Sitio

• Alojamiento Local de LLM: Guía Completa 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio y Más - Comparación exhaustiva de 12+ herramientas de alojamiento local de LLM incluyendo análisis detallado de vLLM junto a Ollama, LocalAI, Jan, LM Studio y otros. Cubre madurez de API, soporte de llamada de herramientas, compatibilidad GGUF y benchmarks de rendimiento para ayudar a elegir la solución correcta.

• Hoja de Trucos de Ollama - Referencia completa de comandos de Ollama y hoja de trucos que cubre instalación, gestión de modelos, uso de API y mejores prácticas para implementación local de LLM. Esencial para desarrolladores que usan Ollama junto o en lugar de vLLM.

• Inicio Rápido de llama.cpp con CLI y Servidor - Inferencia ligera en C/C++ para modelos GGUF con llama-cli y llama-server compatible con OpenAI. Ideal cuando necesita control fino, despliegue offline o una pila mínima sin Python.

• Docker Model Runner vs Ollama: ¿Cuál Elegir? - Comparación en profundidad de Model Runner de Docker y Ollama para implementación local de LLM, analizando rendimiento, soporte de GPU, compatibilidad de API y casos de uso. Ayuda a entender el panorama competitivo donde opera vLLM.

• Hoja de Trucos de Docker Model Runner: Comandos y Ejemplos - Hoja de trucos práctica de Docker Model Runner con comandos y ejemplos para despliegue de modelos de IA. Útil para equipos comparando el enfoque de Docker con las capacidades especializadas de servicio de LLM de vLLM.

Recursos Externos y Documentación

• Repositorio GitHub de vLLM - Repositorio oficial de vLLM con código fuente, documentación exhaustiva, 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 configuración básica hasta avanzada. Incluye referencias de API, guías de ajuste de rendimiento y mejores prácticas de implementación.

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

• Blog de vLLM - Blog oficial de vLLM con anuncios de lanzamientos, benchmarks de rendimiento, análisis técnicos profundos y estudios de casos de comunidad de implementaciones en producción.

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

• Documentación de Ray Serve - Documentación del marco Ray Serve para construir implementaciones escalables y distribuidas de vLLM. Ray proporciona características avanzadas como escalado automático, servicio multi-modelo y gestión de recursos para sistemas de producción.

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

• Referencia de API de OpenAI - Documentación oficial de API de OpenAI con la que es compatible la API de vLLM. Consulte esto al construir aplicaciones que necesitan trabajar con endpoints de OpenAI y vLLM autoalojados indistintamente.