Cómo instalar vLLM en tu propio equipo, y qué manda por su cuenta

Para usar vLLM necesitas Linux (o WSL en Windows), una tarjeta NVIDIA con compute capability 7.5 o superior y Python 3.10 a 3.13. Después, 2 comandos: uv pip install vllm --torch-backend=auto y vllm serve. El servidor responde en el puerto 8000 en todas las interfaces de red, no solo en tu equipo: añade --host 127.0.0.1.

Eso último es lo que distingue a vLLM. De los 5 programas que comparamos, es el único que escucha en todas las interfaces de fábrica; Ollama, LM Studio, llama.cpp y MLX arrancan en 127.0.0.1. Además arranca sin clave, con el CORS abierto a cualquier web y con las estadísticas de uso activadas. Nada de eso cuesta cambiarlo, y esta página lo recorre en orden, con la versión estable actual, la 0.30.0, publicada el 22 de septiembre de 2026. Cada comando y cada valor de fábrica de esta página se comprobó el 28 de septiembre de 2026 contra el código de la 0.30.0 tal como está etiquetado en su repositorio público.

Qué es vLLM y para quién es

vLLM es un motor de inferencia hecho para servir modelos de lenguaje a mucha gente a la vez. Su sitio natural es un servidor Linux con GPU NVIDIA, y ahí es donde sus valores de fábrica tienen sentido: un servicio al que otros equipos llegan por la red, que se reserva la mayor parte de la tarjeta y que les cuenta a sus desarrolladores cómo se está usando. Es código abierto con licencia Apache 2.0. La ficha vLLM: qué manda a casa y si lo puedes auditar lo coloca en el extremo profesional de los 5 programas, y esta guía es la parte práctica de esa ficha.

Todo viene en 1 ejecutable, vllm. Los subcomandos que vas a usar son vllm serve, que arranca el servidor compatible con OpenAI, y vllm chat y vllm complete, que son clientes de consola que hablan con ese servidor. También están vllm bench, vllm collect-env, vllm run-batch y vllm launch, que esta página no necesita.

Lo que no es, porque cada una de estas cosas se da por hecha:

• No es una aplicación de escritorio. No hay ventana. vllm chat es un cliente de texto que necesita el servidor ya en marcha.
• No ejecuta GGUF de fábrica. El soporte de GGUF se ha ido a un complemento aparte, y el apartado de los modelos explica qué supone eso para los tamaños.
• No es un programa para la GPU del Mac. En Apple Silicon, vLLM en sí corre en la CPU. Si tienes un Mac, Cómo instalar MLX en un Mac con mlx-lm, y qué manda por su cuenta usa la GPU directamente.
• No cambia de modelo sobre la marcha. El servidor aloja 1 modelo cada vez. Para cambiarlo, reinicias el servidor con otro nombre.

Si lo que quieres es un modelo con el que charlar en tu propio ordenador, Cómo instalar Ollama en local y ver qué manda por su cuenta y Cómo instalar LM Studio y su servidor local, y qué manda por su cuenta te llevan ahí con menos decisiones. vLLM es para cuando quieres servir.

Qué necesitas: Linux, una NVIDIA con compute capability 7.5 y Python 3.10 a 3.13

Requisito	Qué significa en la práctica
Linux	Los paquetes precompilados de PyPI son solo para Linux, para x86_64 (314,9 MB) y aarch64 (310,0 MB). Windows pasa por WSL
GPU NVIDIA con compute capability 7.5 o superior	De la T4 y la serie RTX 20 en adelante. La serie RTX 30 es 8.6 y la RTX 40, 8.9. La serie GTX 10 se queda por debajo de la línea. El paquete de PyPI está compilado para CUDA 13.0; la versión en GitHub adjunta aparte un paquete para CUDA 12.9
Python 3.10 a 3.13	La documentación pide de la 3.10 a la 3.13; los metadatos del paquete aceptan de la 3.10 hasta la 3.15, sin incluirla. Usa la 3.12: está dentro de los dos rangos, y para ella se compilan los paquetes de AMD y el del Mac
Un entorno nuevo	vLLM 0.30.0 fija su propio PyTorch, torch==2.13.0, más el torchaudio y el torchvision que le corresponden, y por eso su documentación recomienda un entorno nuevo

Requisitos de la guía de instalación de vLLM en la etiqueta v0.30.0, de los metadatos de PyPI de vllm 0.30.0 y de la tabla de compute capability de NVIDIA, leídos el 28 de septiembre de 2026.

Windows. vLLM no funciona en Windows de forma nativa. Su documentación remite al Subsistema de Windows para Linux (WSL), y dentro de WSL sigues los pasos de Linux de esta página.

Mac. vLLM admite Apple Silicon en la CPU, como soporte experimental: FP32 y FP16, macOS Sonoma o posterior, Xcode 15.4 y sus Command Line Tools. PyPI no tiene paquete para macOS, y la documentación explica cómo compilarlo desde el código fuente. La versión 0.30.0 en GitHub adjunta además un paquete listo para CPU macOS arm64 y Python 3.12, de 29,0 MB; no lo hemos probado. La GPU del Mac es otro proyecto: vLLM remite a vLLM-Metal, un complemento que mantiene la comunidad, que usa MLX por debajo y carga los modelos de mlx-community. Esta página no lo cubre.

AMD. vLLM admite GPU AMD con ROCm 6.3 o posterior, y para la 0.30.0 el paquete precompilado de https://wheels.vllm.ai/rocm/ está hecho para ROCm 7.2.3 y necesita glibc 2.39 o posterior. Esos paquetes existen solo para Python 3.12, y este es el paso que hay que hacer bien: con cualquier otro Python, el instalador recurre sin avisar al paquete CUDA de PyPI, que luego falla en la tarjeta AMD con libcudart.so: cannot open shared object file. La lista de compatibles incluye MI200, MI300 y MI350, las Radeon RX 7900 (gfx1100/1101) y RX 9000 (gfx1200/1201), y los Ryzen AI MAX y AI 300 (gfx1151/1150, ROCm 7.0.2 o posterior).

Solo CPU. En un equipo Linux x86 sin una GPU adecuada, vLLM corre en el procesador. Se recomienda AVX512; con AVX2 tienes funciones limitadas. La 0.30.0 adjunta un paquete para CPU x86_64 (147,4 MB) y otro para aarch64 (68,3 MB); los 2 necesitan glibc 2.39 o posterior.

Qué equipos de nuestro catálogo pueden ejecutarlo

Nuestro catálogo tiene 16 equipos. Leídos contra los requisitos de vLLM, se reparten en 4 grupos:

Equipo	Compute capability	Cómo corre vLLM en él
PC con RTX 4060 8 GB	8.9	CUDA, en Linux o WSL
PC con RTX 3060 12 GB	8.6	CUDA, en Linux o WSL
PC con RTX 4070 12 GB	8.9	CUDA, en Linux o WSL
Estación con RTX 4090 24 GB	8.9	CUDA, en Linux o WSL
Servidor con 2× RTX 3090 (48 GB)	8.6	CUDA repartido entre las 2 tarjetas con --tensor-parallel-size 2
Los 8 Mac, del M4 con 16 GB al Mac Studio con M5 Ultra y 512 GB	—	Solo CPU, experimental. La GPU, solo con el complemento vLLM-Metal
El portátil de oficina de 16 GB y la parte de CPU del mini-PC con NPU y 32 GB	—	CPU en Linux. Si su procesador es un Ryzen AI 300 o un Ryzen AI MAX, su GPU integrada está en la lista de ROCm de vLLM de más arriba. El repositorio principal de vLLM no tiene backend para la NPU
Xiaomi AI Cube, 80 GB	—	No verificable: es un prototipo de ingeniería cuyo procesador no está documentado frente a los requisitos de vLLM

Compute capability de la tabla de NVIDIA, leída el 28 de septiembre de 2026. Vías de instalación de la guía de vLLM en la etiqueta v0.30.0.

Los 5 equipos NVIDIA son el caso para el que está hecho vLLM. En el resto, donde llega a funcionar, lo hace en el procesador.

Cómo instalar vLLM y comprobar qué versión tienes

La documentación de vLLM recomienda uv y un entorno nuevo. Con Python 3.12:

uv venv --python 3.12
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm --version

--torch-backend=auto mira qué controlador de NVIDIA tienes instalado y elige el índice de PyTorch que le corresponde. --torch-backend=cu129 o cu130 pide una variante de forma explícita. Con pip a secas, la línea es simplemente:

pip install vllm

El paquete de vllm pesa por sí solo 314,9 MB, y se trae PyTorch 2.13.0, torchaudio 2.11.0, torchvision 0.28.0 y FlashInfer: la descarga completa es mayor que el paquete, y no la hemos medido. vllm --version debería imprimir 0.30.0.

Fija la versión. vLLM va deprisa: 32 versiones estables en los 12 meses anteriores al 28 de septiembre de 2026, y las 3 últimas llegaron 15, 14 y 13 días después de la anterior (la 0.28.0 el 26 de agosto, la 0.29.0 el 9 de septiembre y la 0.30.0 el 22 de septiembre). Para instalar exactamente la versión que describe esta página:

uv pip install vllm==0.30.0 --torch-backend=auto

El camino de Docker. La imagen oficial es vllm/vllm-openai. La etiqueta v0.30.0 se publicó el 22 de septiembre de 2026 y pesa 8,1 GiB comprimida para amd64 y 9,0 GiB para arm64:

docker run --rm \
  --runtime nvidia \
  --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 127.0.0.1:8000:8000 \
  --ipc=host \
  vllm/vllm-openai:v0.30.0 \
  --model Qwen/Qwen3-0.6B

Es el comando de la propia vLLM con una etiqueta fija en lugar de latest, 127.0.0.1 delante del puerto, para que Docker lo publique solo en tu equipo, y --rm; la línea de HF_TOKEN se queda fuera porque Qwen/Qwen3-0.6B es público. El volumen comparte tu caché de Hugging Face con el contenedor, así que los modelos no se descargan dos veces. La imagen corre como root de fábrica; también trae un usuario vllm ya creado, con UID 2000, y la página de Docker de la documentación de vLLM explica cómo pasarte a él.

Tu primer modelo: vllm serve en el puerto 8000

vllm serve

Sin nombre de modelo, vLLM carga Qwen/Qwen3-0.6B: 751.632.384 parámetros en BF16, 1,41 GiB que descargar de Hugging Face, un contexto de hasta 40.960 tokens y licencia Apache 2.0. Para elegir el modelo, dale su nombre de Hugging Face:

vllm serve Qwen/Qwen3-0.6B --max-model-len 8192

El apartado de la memoria explica por qué está ahí esa segunda opción. Cuando el registro diga que el servidor está en marcha, haz 2 comprobaciones desde otra terminal:

curl http://127.0.0.1:8000/v1/models
curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-0.6B", "messages": [{"role": "user", "content": "How tall is Mt Everest?"}]}'

La primera lista el modelo cargado; la segunda devuelve una respuesta en el formato de OpenAI. Las rutas principales son POST /v1/chat/completions, POST /v1/completions y GET /v1/models, además de GET /health y GET /version. Para un cliente de OpenAI, la URL base es http://127.0.0.1:8000/v1. Para charlar un momento en la terminal:

vllm chat

Se conecta a http://localhost:8000/v1 salvo que le des otra --url. El servidor no guarda ningún registro de tus peticiones.

La memoria: por qué vLLM se queda el 92 % de la tarjeta, y –max-model-len

vLLM no se limita a cargar un modelo. Al arrancar reserva una parte fija de la tarjeta, 0,92 de su memoria total de fábrica, para el modelo, su memoria de trabajo y la caché que guarda tus conversaciones (la caché KV). De cómo lo hace el código de la 0.30.0 salen 2 consecuencias.

Cuenta la memoria libre, no la total. Si al arrancar hay libre menos del 92 % de la tarjeta, vLLM se niega a arrancar con Free memory on device … on startup is less than desired GPU memory utilization (0.92, X GiB). Decrease GPU memory utilization or reduce GPU memory used by other processes. En una tarjeta de 8 GB eso son 7,36 GiB libres. Si esa misma tarjeta mueve también tu escritorio, el escritorio y el contexto CUDA que abre la propia vLLM tienen que caber juntos en unos 0,64 GiB, o la comprobación falla antes de que se cargue ningún modelo. El arreglo es el que da el propio mensaje:

vllm serve --gpu-memory-utilization 0.85

El valor es un límite por proceso: 2 servidores vLLM en 1 tarjeta necesitan algo como 0,5 cada uno. En el backend de CPU, la misma opción reserva memoria RAM del sistema, aunque su nombre diga otra cosa.

El contexto de fábrica es el máximo del modelo. --max-model-len se toma de la configuración del propio modelo salvo que lo fijes tú, y vLLM se niega a arrancar si la caché KV para esa longitud completa no cabe. El error da las cifras: To serve at least one request with the model’s max seq len (N), (X GiB KV cache is needed, which is larger than the available KV cache memory (Y GiB), seguido de la longitud máxima estimada que sí cabría y del consejo de subir gpu_memory_utilization o bajar max_model_len. Si no queda nada de memoria, el mensaje es No available memory for the cache blocks.

Cuánto crece esa caché, calculado a partir de la arquitectura de cada modelo con una caché KV de 16 bits:

Modelo	Contexto máximo	Caché KV en el máximo	Caché KV con –max-model-len 8192
qwen3-1.7b	40.960	4,38 GiB	0,875 GiB
qwen3-8b	40.960	5,63 GiB	1,125 GiB
qwen3-4b-2507	262.144	36,0 GiB	1,125 GiB

Cálculo propio: 2 × capas × cabezas KV × tamaño de cabeza × 2 bytes por token, con los datos de modelos que usa nuestro buscador de modelos. Gemma 4 y gpt-oss usan capas de ventana deslizante, donde esta fórmula no vale, así que se quedan fuera.

El modelo de 4B es el que te pilla. A 8.192 tokens, qwen3-4b-2507 necesita 1,125 GiB de caché; con su contexto de fábrica pide 36,0 GiB solo de caché, más que la memoria entera de cualquier tarjeta suelta de nuestro catálogo. Nuestro buscador de modelos y nuestras fichas de equipo lo calculan todo con 8.192 tokens de contexto. --max-model-len 8192 (u 8K, con K mayúscula: 8k en minúscula son 8.000) hace que vLLM se comporte como la cifra de nuestra web. Con --max-model-len auto, o -1, vLLM coge el contexto más largo que quepa.

Qué modelos caben y por qué nuestros tamaños GGUF son solo orientativos

Nuestras fichas de equipo apartan 0,8 GiB para el sistema en las tarjetas NVIDIA y comparan el resto con los 19 modelos que medimos. vLLM traza su propia línea en el 92 %, así que los 2 presupuestos difieren un poco:

Equipo	Lo que nuestra ficha deja para el modelo	Presupuesto de vLLM (0,92 × memoria), para el modelo, su memoria de trabajo y la caché KV	Modelos que caben (ficha, 8K)	El mayor que cabe (ficha)
RTX 4060 8 GB	7,20 GiB	7,36 GiB	6 de 19	granite-4.2-8b
RTX 3060 12 GB y RTX 4070 12 GB	11,20 GiB	11,04 GiB	7 de 19	gemma4-12b
RTX 4090 24 GB	23,20 GiB	22,08 GiB	15 de 19	qwen3.6-35b-a3b
2× RTX 3090 48 GB	47,20 GiB	2 × 22,08 = 44,16 GiB, con --tensor-parallel-size 2	15 de 19	qwen3.6-35b-a3b

Cifras que servía cada ficha de equipo el 28 de septiembre de 2026, con el dato de equipos del 23 de septiembre. El presupuesto de vLLM es cálculo propio a partir de su 0,92 de fábrica.

En la tarjeta de 24 GB, vLLM se deja 1,12 GiB menos de lo que cuenta nuestra ficha; en la de 8 GB, 0,16 GiB más. Un modelo que entra justo según la ficha puede necesitar que subas --gpu-memory-utilization en una tarjeta de 24 GB.

La diferencia grande es el fichero. Nuestros tamaños son de ficheros GGUF en Q4_K_M. vLLM no carga GGUF por sí solo: ese soporte vive ahora en un complemento aparte, vllm-gguf-plugin, que la documentación califica de muy experimental y poco optimizado. Si quieres probarlo:

uv pip install vllm-gguf-plugin

Los modelos se nombran entonces como repo_id:quant_type, por ejemplo con Q4_K_M. El camino habitual en vLLM es otra compresión: ficheros AWQ, GPTQ o FP8 de Hugging Face, o MXFP4 en gpt-oss. No hemos medido esos tamaños para nuestros 19 modelos, así que toma el veredicto del buscador como una orientación para vLLM, no como la misma cifra.

Cómo cerrarlo: 0.0.0.0, sin clave y con CORS abierto

De fábrica, vllm serve escucha en 0.0.0.0:8000, y su registro de arranque lo imprime tal cual. Responde en localhost y en cualquier otra interfaz de red del equipo: cualquiera de tu red, o de internet si el puerto está abierto, puede usarlo. No comprueba ninguna clave. Y el CORS está abierto a cualquier origen, cualquier método y cualquier cabecera, así que una página web que abras en tu navegador puede mandarle peticiones y leer las respuestas.

Lo que lo cierra:

export VLLM_API_KEY="una-cadena-larga-y-aleatoria"
vllm serve Qwen/Qwen3-0.6B --host 127.0.0.1 --max-model-len 8192

• --host 127.0.0.1 deja fuera a los demás equipos. Si alguno necesita el servidor, que llegue por un túnel SSH (ssh -L 8000:127.0.0.1:8000 tu-usuario@tu-servidor).
• --api-key, o la variable VLLM_API_KEY, obliga a los clientes a mandar la clave como token Bearer. Con la variable, la clave no aparece en la línea de comandos, donde cualquier usuario del equipo puede leerla en la lista de procesos.
• --allowed-origins '["http://localhost:3000"]', una lista JSON, dice qué páginas pueden llamarlo en vez del * de fábrica.

Lo que la clave no cubre. La clave protege solo las rutas que empiezan por 4 prefijos: /v1, /v2, /inference y /cohere. Todo lo demás en el mismo puerto responde sin ella: /health, /version, /tokenize, /metrics (Prometheus, siempre montado) y /invocations, que llega a las mismas funciones de inferencia que /v1. Y lo mismo las páginas interactivas de la API, /docs y /redoc, y el esquema en /openapi.json, salvo que arranques con --disable-fastapi-docs. La página de seguridad de vLLM también cita /pause, que detiene la generación, y /update_weights; en el código de la 0.30.0 solo se montan si pones VLLM_SERVER_DEV_MODE=1, así que deja esa variable sin poner. La página de seguridad de vLLM lo dice sin rodeos: Do not rely exclusively on --api-key, es decir, no te fíes solo de la clave. Para cualquier cosa a la que lleguen otros, recomienda poner delante de vLLM un proxy inverso que deje pasar solo las rutas que quieras exponer.

Un segundo puerto a la escucha. vLLM usa torch.distributed de PyTorch, y cuando lo monta sobre TCP, como hace entre varios equipos o en tarjetas AMD con el all-reduce de AITER, el TCPStore de PyTorch escucha de fábrica en todas las interfaces de red. En 1 equipo con tarjetas NVIDIA, el código de la 0.30.0 usa un fichero en su lugar. La recomendación de la propia vLLM es un cortafuegos que bloquee toda conexión entrante salvo la del puerto del servidor de la API. --host 127.0.0.1 cierra la API; la regla del cortafuegos cubre lo que las opciones de vLLM no alcanzan.

Qué manda vLLM por su cuenta y cómo apagarlo

Las estadísticas de uso vienen activadas de fábrica y van a https://stats.vllm.ai. En el código de la 0.30.0 salen de 2 formas:

• 1 informe completo al arrancar el motor, desde un hilo aparte: un identificador aleatorio de la ejecución; el número de GPU, su modelo y su memoria; la versión de CUDA; el proveedor de nube, si detecta uno; la arquitectura del procesador y la cadena del sistema operativo; la memoria total; el número de núcleos, la marca, la familia, el modelo y el stepping del procesador; la versión de vLLM; la arquitectura del modelo, no su nombre; la longitud de contexto; 5 variables de entorno de vLLM, y parámetros de arranque como el tipo de datos, gpu_memory_utilization, la cuantización, el paralelismo, max_model_len y max_num_seqs.
• Un latido cada 10 minutos mientras el servidor esté en marcha, que lleva solo el identificador de la ejecución y una marca de tiempo. Son 144 latidos al día.

Los errores de red se ignoran sin avisar. Como comparación, la guía de Ollama cuenta 30 llamadas al día con su aplicación de escritorio abierta.

Puedes leer lo que se ha enviado. Cada informe se añade también a un fichero en tu disco:

tail ~/.config/vllm/usage_stats.json

Hay 4 maneras de apagarlo, y basta con una cualquiera:

export VLLM_NO_USAGE_STATS=1
export DO_NOT_TRACK=1
export VLLM_DO_NOT_TRACK=1
mkdir -p ~/.config/vllm && touch ~/.config/vllm/do_not_track

El valor tiene que ser exactamente 1. El código compara el texto con "1", así que DO_NOT_TRACK=true deja las estadísticas activadas. En Docker, pásalo con -e VLLM_NO_USAGE_STATS=1.

Hugging Face. El otro tráfico es la descarga de modelos. vLLM se identifica ante Hugging Face como vllm, y descarga cualquier modelo que nombres y que aún no esté en la caché. Cuando tengas tus modelos descargados:

export HF_HUB_OFFLINE=1

Con esa variable puesta, no sale ninguna llamada a Hugging Face y un modelo que falte da error en vez de descargarse. vLLM no comprueba actualizaciones ni pide cuenta.

Lo que se queda en el disco. Los modelos van a la caché de Hugging Face, en ~/.cache/huggingface, que se cambia de sitio con HF_HOME. Los ficheros de la propia vLLM viven en ~/.config/vllm (el fichero de estadísticas y el interruptor do_not_track) y en su carpeta de caché, ~/.cache/vllm. No hay chats: el servidor no guarda ninguna copia de tus peticiones.

En este orden acabas con un vLLM que funciona y está cerrado:

1. Comprueba la tarjeta: NVIDIA con compute capability 7.5 o superior, en Linux o WSL.
2. Crea un entorno con Python 3.12 usando uv, instala vllm==0.30.0 con --torch-backend=auto y confírmalo con vllm --version.
3. Pon VLLM_NO_USAGE_STATS=1 antes del primer vllm serve, para que no salga ni el informe de arranque.
4. Arranca con --host 127.0.0.1, --max-model-len 8192 y una clave en VLLM_API_KEY.
5. Si la tarjeta también mueve tu pantalla, baja --gpu-memory-utilization hasta que arranque.
6. Cuando el modelo esté descargado, pon HF_HUB_OFFLINE=1.

Los 5 programas se comparan justo en esto en 5 programas de IA local: telemetría, llamadas y auditoría.