> ¿Se puede ejecutar vLLM en Windows? Sí — mediante WSL2▋

93.632 estrellas en GitHub desde febrero de 2023, y los requisitos de instalación siguen abriendo con una línea: "SO: Linux. Python 3.10–3.13." Dos líneas más abajo, la nota que manda a todo el mundo a buscar: "vLLM no soporta Windows de forma nativa. Para ejecutar vLLM en Windows, puedes usar el Subsistema de Windows para Linux (WSL) con una distribución compatible, o usar algunos forks mantenidos por la comunidad." Esa nota es el post entero. El camino oficial es WSL2; el camino nativo es un fork con tu nombre en los reportes de bug. Este post vive en el clúster run-LLMs-locally, junto a la mitad de hardware del mismo candado — ¿puede vLLM ejecutar GGUF?

¿Cómo se ejecuta vLLM en Windows?

Mediante WSL2, y muy pronto deja de sentirse como Windows.

• ¿Windows 10/11 con GPU NVIDIA? AMD va por ROCm-on-WSL y el camino es más estrecho — tenlo previsto
• wsl --install -d Ubuntu desde un PowerShell de admin, y reinicia
• Driver NVIDIA instalado del lado Windows — ninguno dentro de WSL, la GPU pasa a través
• Dentro de Ubuntu: uv pip install vllm — el flujo Linux exacto de la documentación
• Sirve un modelo pequeño y llama al endpoint de models para confirmar — comando abajo

WSL2 es Microsoft admitiendo oficialmente que la mejor función de Windows es Linux. Viene con el SO, se instala en una línea, y una vez dentro de Ubuntu, cada instrucción de vLLM de internet te aplica sin cambios:

# PowerShell (admin) — reinicia cuando lo pida:
wsl --install -d Ubuntu

# dentro de Ubuntu — la instalación Linux normal, nada específico de Windows:
uv venv --python 3.12 && source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# sirve algo pequeño y demuestra que la GPU pasó:
vllm serve Qwen/Qwen3-0.6B --port 8000

verificación: curl http://localhost:8000/v1/models desde Windows — WSL2 reenvía localhost y tu modelo vuelve en JSON

El detalle que todos se pierden: el driver de la GPU vive del lado de Windows. El diseño CUDA-on-WSL de NVIDIA hace pasar la GPU a través del driver de Windows hacia cualquier distro, así que instalas el driver una vez, en Windows, y nunca dentro de Ubuntu. Instala un driver dentro de WSL igualmente y puedes gastarte una tarde destrabando una pila que nunca estuvo rota.

¿Puedes ejecutar vLLM en Windows sin WSL?

Solo mediante un fork comunitario — y el impuesto del fork es real: cambias el instalador por un compilador.

La documentación nombra la escena ella misma: "algunos forks mantenidos por la comunidad". Leí el registro de todos ellos, esta semana:

• SystemPanic/vllm-windows — el vivo. 663 estrellas, con push la víspera de este post. Wheels nativas de Windows, CUDA 13, soporte Blackwell, incluso multi-GPU vía NCCL en Windows. Un proyecto serio haciendo lo que el core se niega a hacer.
• devnen/vllm-windows — 28 estrellas, último push en mayo de 2026. Cinco meses de silencio en un proyecto que se mueve a esta velocidad es un aviso de jubilación.
• dexteri-ai/vllm-windows — un wrapper con GUI, creado en enero de 2026. Mira detrás de la interfaz: maneja vLLM dentro de WSL2 — el camino que dice evitar.

Incluso en el fork sano estás compilando kernels CUDA con parches de MSVC, pierdes FlashAttention-3, y vuelves a probar tras cada release de arriba. Ese es el impuesto del fork. Págalo cuando una política corporativa prohíbe WSL y un servidor está fuera de alcance — no porque la instalación de una línea pareciera demasiado fácil.

¿Por qué no existe ningún build nativo de Windows?

vLLM compila kernels CUDA y depende de NCCL — una toolchain que solo existe completa en Linux. La documentación lo dice sin rodeos: "vLLM solo puede correr por completo en Linux." Un port nativo significa rehacer el build de kernels para MSVC — exactamente el mantenimiento que el proyecto eligió no asumir, y los forks miden cuánto trabajo es por los pocos que sobreviven.

¿Funciona vLLM en Windows para modelos GGUF?

Sí — mediante WSL2, sobre una GPU NVIDIA o AMD. GGUF en vLLM es solo GPU, así que Windows apila el requisito de SO encima del de hardware. En una máquina Windows solo con CPU, ejecuta el mismo archivo en Ollama o llama.cpp — ambos nativos.

Dos candados, en orden. Primero el de hardware: ¿puede vLLM ejecutar GGUF? — sí, mediante el plugin oficial, solo GPU, CPU x86 y Arm rechazados. Después el de SO, este post: el camino solo-GPU tiene que correr en algún lado, y en Windows ese algún lado es WSL2 con CUDA de paso. Los dos candados se abren juntos o no se abren. ¿Sin GPU a la vista? El archivo igual corre — cómo ejecutar modelos GGUF localmente cubre las herramientas nativas, y el quant a elegir está en nuestra guía de cuantización.

¿vLLM en Windows — o mejor Ollama?

La mayoría de las preguntas sobre vLLM en Windows son en realidad preguntas de concurrencia. vLLM existe para servir a muchos usuarios desde GPUs grandes con batching continuo. Si el conteo de usuarios es "yo, en mi escritorio", la respuesta honesta es la última fila:

Camino	¿vLLM?	Instalación	Para
vLLM dentro de WSL2	motor completo	una línea + reinicio	servir a un equipo desde una GPU
fork nativo SystemPanic	casi completo, tú lo pruebas	compilar, perseguir CUDA	WSL prohibido por política, GPU conectada
vLLM en una box Linux, Windows de cliente	motor completo, en otro lado	cualquier cliente compatible OpenAI	la GPU ya vive en otra habitación
Ollama, nativo	no — otro motor	un instalador	uso en solitario, GGUF, puerto 11434
llama.cpp, nativo	no — otro motor	binarios de Windows	un usuario, la mayor cobertura de quant

La tabla de soporte de la documentación dice Linux. WSL2 dice: perfecto. Y si la pregunta de fondo nunca fue sobre vLLM — solo "correr un modelo en mi máquina Windows" — entonces nada estuvo nunca cerrado: Ollama se instala nativo, sirve en 127.0.0.1:11434, y cuando se niega a arrancar, también tenemos autopsiado ese fallo.