vLLM en 2026: Guía de inicio rápido para el servicio de LLM de alto rendimiento

Inferencia rápida de LLM con la API de OpenAI

Índice

vLLM es un motor de inferencia y servicio de alto rendimiento y eficiente en memoria para Modelos de Lenguaje Grandes (LLMs) desarrollado por el laboratorio Sky Computing de la Universidad de California en Berkeley.

Con su revolucionario algoritmo PagedAttention, vLLM logra un rendimiento hasta 14-24 veces mayor que los métodos de servicio tradicionales, convirtiéndolo en la opción preferida para implementaciones de LLMs en producción. Para ver cómo vLLM se posiciona entre Ollama, Docker Model Runner, LocalAI y proveedores de la nube, incluyendo compensaciones de costos e infraestructura, consulte Alojamiento de LLMs: Infraestructura local, autoalojada y en la nube comparada.

vllm logo

¿Qué es vLLM?

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

Características principales

Rendimiento de alto rendimiento: vLLM ofrece un rendimiento 14-24 veces mayor en comparación con HuggingFace Transformers utilizando el mismo hardware. Esta enorme ganancia de rendimiento proviene del loteo continuo, 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 totalmente 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 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 las cachés KV (lo que lleva a la fragmentación), PagedAttention divide la memoria en bloques de tamaño fijo que pueden asignarse bajo demanda. Esto reduce el desperdicio de memoria hasta en 4 veces y permite tamaños de lote mucho más grandes.

Loteo continuo (Continuous Batching): A diferencia del loteo estático, donde se espera a que todas las secuencias se completen, vLLM utiliza loteo continuo (o rodante). En cuanto una secuencia finaliza, se puede agregar una nueva al lote. Esto maximiza la utilización de la GPU y minimiza la latencia para las solicitudes entrantes.

Soporte Multi-GPU: vLLM admite paralelismo de tensor y paralelismo de pipeline para distribuir modelos grandes entre múltiples GPUs. Puede servir eficientemente modelos que no caben en la memoria de una sola GPU, soportando configuraciones desde 2 hasta más de 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 instruidos como modelos base desde HuggingFace Hub.

Cuándo usar vLLM

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

Servicios API de producción: Cuando necesite servir un LLM a muchos usuarios concurrentes mediante API, el alto rendimiento y el loteo 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 loteo continuo y PagedAttention de vLLM permiten servir a más usuarios con el mismo hardware en comparación con las alternativas.

Optimización de costos: Cuando los costos de GPU sean una preocupación, el rendimiento superior de vLLM significa que puede 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 el uso de instancias de GPU más pequeñas y baratas.

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

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

Cómo instalar vLLM

Requisitos previos

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

  • GPU: GPU NVIDIA con capacidad de cálculo 7.0+ (V100, T4, A10, A100, H100, serie 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 más reciente

Instalación mediante pip

El método de instalación más simple 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 instalación
python -c "import vllm; print(vllm.__version__)"

Para sistemas con versiones de CUDA diferentes, instale la rueda (wheel) apropiada:

# 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:

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

# Ejecutar vLLM con soporte para 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 rápida de inicio 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 que indica 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

Realizando solicitudes API

Una vez que el servidor esté en ejecución, puede realizar 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": "Explain what vLLM is in one sentence:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

Usando el cliente Python de OpenAI:

from openai import OpenAI

# Apuntar a su servidor de 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="Explain what vLLM is in one sentence:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API de Completions de Chat:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is 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 de la GPU
    --max-model-len 8192 \            # Longitud máxima de la secuencia
    --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

Explicación de parámetros clave:

  • --gpu-memory-utilization: Cuánta memoria de GPU utilizar (0.90 = 90%). Valores más altos permiten lotes más grandes pero dejan menos margen para picos de memoria.
  • --max-model-len: Longitud de contexto máxima. 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 a procesar en un lote.

vLLM vs Ollama

vLLM está diseñado para servir en producción de alto rendimiento y multiusuario con loteo continuo, PagedAttention y soporte multi-GPU. Ollama se optimiza para la configuración local rápida, la conveniencia de usuario único y la gestión de modelos sencilla.

Para una guía de decisión detallada que cubre señales de migración, pasos de planificación, configuración de Docker Compose y una lista de verificación práctica, consulte Ollama a vLLM: Cuándo migrar su servidor local de LLM.

vLLM vs Docker Model Runner

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

Filosofía arquitectónica

Docker Model Runner aspira a ser el “Docker para la IA”: una forma simple y estandarizada de ejecutar modelos de IA localmente con la misma facilidad que ejecutar contenedores. Abstractiza la complejidad y proporciona una interfaz consistente entre diferentes modelos y frameworks.

vLLM es un motor de inferencia especializado enfocado únicamente en el servicio de LLMs con rendimiento máximo. Es una herramienta de nivel inferior que usted containeriza 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 los desarrolladores que ya usan contenedores.

vLLM requiere más configuración inicial (Python, CUDA, dependencias) o el uso de imágenes Docker precompiladas:

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

Características de rendimiento

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

Docker Model Runner se enfoca en la facilidad de uso en lugar del rendimiento máximo. 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 comando a modelos populares. Soporta múltiples frameworks (no solo LLMs), 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 inferencia de LLMs 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 está probado en producción en empresas como Anthropic, Replicate y muchas otras que sirven miles de millones de tokens diarios. Sus características de rendimiento y estabilidad bajo carga pesada lo convierten en el estándar de facto para el servicio de LLMs en producción.

Docker Model Runner es más nuevo y se posiciona más para escenarios de desarrollo y pruebas locales. Si bien podría servir tráfico de producción, carece del historial probado y las optimizaciones de rendimiento que las implementaciones de producción requieren.

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 compatibilidad extensa con la API de OpenAI para aplicaciones existentes.

Docker Model Runner se integra naturalmente con el ecosistema de Docker y Docker Desktop. Para equipos estandarizados en Docker, esta integración proporciona una experiencia cohesiva pero con menos funciones especializadas de servicio de LLMs.

Cuándo usar cada uno

Use vLLM para:

  • Servicios API de LLMs de producción
  • Implementaciones de alto rendimiento y multiusuario
  • Implementaciones en la nube sensibles a los costos que necesitan máxima eficiencia
  • Entornos de Kubernetes y nativos de la nube
  • Cuando necesita escalabilidad y rendimiento probados

Use Docker Model Runner para:

  • Desarrollo y pruebas locales
  • Ejecutar varios tipos de modelos de IA (no solo LLMs)
  • Equipos fuertemente invertidos en el ecosistema de 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, y luego implementan con vLLM en producción por rendimiento. Las imágenes de Docker Model Runner también pueden usarse para ejecutar contenedores de vLLM, combinando ambos enfoques.

Mejores prácticas de implementación en producción

Implementación 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]

Implementación en Kubernetes

Implemente 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 la 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 de GPU: Comience con --gpu-memory-utilization 0.90 y ajuste basándose en el comportamiento observado. Valores más altos permiten lotes más grandes pero conllevan riesgo de errores de OOM durante picos de tráfico.

Ajuste la longitud máxima de secuencia: Si su caso de uso no necesita la longitud de contexto completa, 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 apropiada: Para modelos que lo soportan, use versiones cuantizadas (8-bit, 4-bit) para reducir la memoria y aumentar el rendimiento:

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

Habilite la caché de prefijo (Prefix Caching): Para aplicaciones con prompts repetidos (como chatbots con mensajes de sistema), habilite la caché de prefijo:

--enable-prefix-caching

Esto cachea 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 cierra con errores de memoria insuficiente 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 el paralelismo de tensor para distribuir entre más GPUs

En una tarjeta de 16 GB sola, la mayoría de estos errores de OOM se deben al presupuesto de la caché KV en lugar de solo a los pesos — Caché KV en GPUs de 16 GB cubre la fórmula exacta, el tipo de datos de caché KV FP8 y las compensaciones de la caché de prefijo detrás de --max-model-len y --max-num-seqs antes de recurrir a un modelo más pequeño.

Bajo rendimiento

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

Soluciones:

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

Fallos en la carga de modelos

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
  • Compruebe la conectividad de red a HuggingFace Hub
  • Asegúrese de que haya espacio en disco suficiente en ~/.cache/huggingface
  • Para modelos restringidos, establezca la variable de entorno HF_TOKEN
  • Intente descargar manualmente con huggingface-cli download <model>

Funciones avanzadas

Decodificación especulativa

vLLM admite la decodificación especulativa, donde un modelo de borrador más pequeño propone tokens que un modelo objetivo más grande verifica. Esto puede acelerar la generación hasta 1.5-2 veces. Para una guía completa de métodos de decodificación especulativa — modelos de borrador, EAGLE-3, P-EAGLE y n-gramas — consulte Decodificación especulativa: Inferencia más rápida sin pérdida de calidad.

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=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Luego especifique qué adaptador usar por solicitud:

response = client.completions.create(
    model="sql-lora",  # Usar el adaptador SQL
    prompt="Convert this to SQL: Show me all users created this month"
)

Servicio Multi-LoRA

El servicio multi-LoRA de vLLM permite albergar docenas de adaptadores afinados con un costo de memoria mínimo. Esto es ideal para servir variantes de modelos específicas de cliente o de tarea:

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

Caché de prefijo

Habilite la caché de prefijo automática para evitar recalcular la caché KV para prefijos de prompt repetidos:

--enable-prefix-caching

Esto es particularmente efectivo para:

  • Chatbots con prompts de sistema fijos
  • Aplicaciones RAG con plantillas de contexto consistentes
  • Prompts de aprendizaje con pocos ejemplos repetidos entre solicitudes

La caché de prefijo puede reducir el tiempo hasta el primer token (time-to-first-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("Explain PagedAttention in simple terms")
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("What is 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 rendimiento (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 de VRAM, 32 secuencias concurrentes
  • vLLM con PagedAttention: 24GB de 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 de 180ms, latencia P99 de 420ms a 100 req/s
  • Servicio estándar: Latencia P50 de 650ms, latencia P99 de 3.200ms a 100 req/s
  • Resultado: vLLM mantiene una latencia consistente bajo carga alta

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

Análisis de costos

Entender las implicaciones de costo de elegir vLLM:

Escenario: Sirviendo 1M de 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 de tokens: ~$0,75

Con vLLM:

  • Requerido: 2x GPUs A100 (80GB)
  • Costo en AWS: ~$8/hora × 24 × 30 = $5.760/mes
  • Costo por 1M de tokens: ~$0,19
  • Ahorro: $17.280/mes (reducción del 75%)

Esta ventaja de costos 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 la autenticación a 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 puertas de enlace API como Kong, Traefik o AWS API Gateway para autenticación y limitación de velocidad de grado 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 velocidad

Implemente limitación de velocidad para prevenir abusos:

# 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="Rate limit exceeded")
    
    return await call_next(request)

Control de acceso a modelos

Para implementaciones multi-inquilino, 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": "Hello"}]
)

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": "Hello"}]
)

Solo se necesitan dos cambios: actualizar base_url y el nombre del model. Todo el resto del código permanece idéntico.

De Ollama a vLLM

Ollama usa un formato de API diferente. El cambio básico en el lado del cliente es cambiar del endpoint REST de Ollama a la API compatible con OpenAI de vLLM:

API de Ollama:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Why is the sky blue?'})

Equivalente en 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="Why is the sky blue?"
)

Para una guía de migración exhaustiva que cubre selección de modelos, plantillas de chat, migración por etapas y una lista de verificación práctica, consulte Ollama a vLLM: Cuándo migrar su servidor local de LLM.

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("Hello", 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("Hello", 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 un desarrollo rápido con emocionantes funciones en el camino:

Servicio segregado (Disaggregated Serving): Separar el prellenado (procesamiento de prompt) y la decodificación (generación de tokens) en GPUs diferentes para optimizar la utilización de recursos. El prellenado está limitado por la computación, mientras que la decodificación está limitada por la memoria, por lo que ejecutarlos en hardware especializado mejora la eficiencia.

Inferencia multi-nodo: Distribuir modelos muy grandes (100B+ de parámetros) entre varias 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 mejor integración AWQ/GPTQ para un mejor rendimiento con modelos cuantizados.

Mejoras en la decodificación especulativa: Modelos de borrador más eficientes y estrategias de especulación adaptativas para lograr aceleraciones más altas 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: Expansión del soporte a modelos multimodales (modelos de visión-lenguaje), modelos de audio y arquitecturas especializadas a medida que emergen.

El proyecto vLLM mantiene un desarrollo activo con contribuciones de UC Berkeley, Anyscale y la comunidad de código abierto en general. A medida que la implementación de LLMs se vuelve más crítica 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 de LLM locales y en la nube, consulte nuestra Alojamiento de LLMs: Infraestructura local, autoalojada y en la nube comparada.

Enlaces útiles

Artículos relacionados en este sitio

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

  • Hoja de referencia de Ollama - Referencia completa de comandos y hoja de referencia de Ollama que cubre instalación, gestión de modelos, uso de la API y mejores prácticas para la implementación local de LLMs. Esencial para desarrolladores que usan Ollama junto con 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, implementación offline o un stack mínimo sin Python.

  • Docker Model Runner vs Ollama: ¿Cuál elegir? - Comparación a fondo de Docker Model Runner y Ollama para la implementación local de LLMs, analizando rendimiento, soporte GPU, compatibilidad de API y casos de uso. Ayuda a comprender el panorama competitivo en el que opera vLLM.

  • Hoja de referencia de Docker Model Runner: Comandos y ejemplos - Hoja de referencia práctica de Docker Model Runner con comandos y ejemplos para la implementación de modelos de IA. Útil para equipos que comparan el enfoque de Docker con las capacidades especializadas de servicio de LLMs de vLLM.

Recursos externos y documentación

  • Repositorio de 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 al día con las últimas funciones 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 ajuste de rendimiento y mejores prácticas de implementación.

  • Papel de PagedAttention - Papel 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 que presenta anuncios de lanzamientos, benchmarks de rendimiento, análisis técnicos profundos y casos de estudio de la comunidad desde implementaciones de producción.

  • Hub de modelos de HuggingFace - Repositorio exhaustivo de LLMs de código abierto que funcionan 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 framework Ray Serve para construir implementaciones escalables y distribuidas de vLLM. Ray proporciona funciones avanzadas como autoescalado, servicio de múltiples modelos y gestión de recursos para sistemas de producción.

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

  • Referencia de la API de OpenAI - Documentación oficial de la API de OpenAI con la que la API de vLLM es compatible. Consulte esto al construir aplicaciones que necesitan funcionar tanto con OpenAI como con endpoints autoalojados de vLLM de forma intercambiable.

Suscribirse

Recibe nuevas publicaciones sobre sistemas, infraestructura e ingeniería de IA.