■ the answer first

No native Windows build exists. The install docs list one OS: Linux — their words, not mine.

Yes, you can run it: WSL2. Ubuntu inside Windows, the NVIDIA driver on the Windows side, the same pip install vllm.

Skipping WSL costs the fork tax — you are the QA. Solo user? Ollama runs Windows natively.

93,632github stars — every one of them linux

1door the docs support: wsl2

2locks on gguf: gpu + os

01THE PASS-THROUGH DEPOT

one wall, two yards, three doors — the gpu crosses over on the pipe, never in a suitcase

FIG 1 · THE PASS-THROUGH DEPOTkeys 1 · 2 · 3 — or the buttons

ROUTE 1 · WSL2 — PASS-THROUGH OK · DRIVER ON THE WINDOWS SIDE · VERDICT PASS

the crate is one request — key 1 walks it through WSL2 while the pipe overhead passes the gpu; doors 2 and 3 cost what the signs say

"vLLM does not support Windows natively. To run vLLM on Windows, you can use the Windows Subsystem for Linux (WSL) with a compatible Linux distribution,

or use some community-maintained forks." — the install docs, verbatim. The first half is the wall; the second half is this post.

02DOOR 1, STEP BY STEP

one line in powershell, the normal linux install inside — the driver never moves

the door — powershell (admin)

# PowerShell (Admin) — then reboot when it asks:
wsl --install -d Ubuntu

inside ubuntu — the normal linux install

# inside Ubuntu — the normal Linux install, nothing Windows-specific:
uv venv --python 3.12 && source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# serve something small and prove the GPU passed through:
vllm serve Qwen/Qwen3-0.6B --port 8000

verify — from windows

curl http://localhost:8000/v1/models
# WSL2 forwards localhost — the model comes back as JSON

verify: curl http://localhost:8000/v1/models from Windows — WSL2 forwards localhost, your model comes back in JSON

the driver—lives on the Windows side, installed once — NVIDIA's CUDA-on-WSL passes the GPU into any distro

the classic trap—installing a driver inside Ubuntu too — an evening spent unsticking a stack that was never broken

amd—rides ROCm-on-WSL — the road is thinner, plan for it

03DOOR 2, THE FORK TAX

the docs name the scene themselves: "some community-maintained forks" — the census, read 2026-10-12

fork	the record	verdict
SystemPanic/vllm-windows	663 stars, pushed the day before this post	the living one — native wheels, CUDA 13, Blackwell, NCCL multi-GPU
devnen/vllm-windows	28 stars, last push May 2026.	five months quiet — a retirement notice in a project this fast
dexteri-ai/vllm-windows	GUI wrapper, created January 2026	drives vLLM inside WSL2 — the road it pretends to skip

"vLLM can fully run only on Linux."

— the docs, on why: CUDA kernels and NCCL only fully exist there. The forks prove the MSVC rework by how few survive it.

the tax—MSVC-patched CUDA kernels, FlashAttention-3 gone, re-testing after every upstream release

when to pay—only when policy blocks WSL and no server is in reach — otherwise door 1 is cheaper every time

04THE TWO LOCKS, THE LANE TABLE

gguf stacks a hardware lock on top of the os lock — both turn, or none

Yes — through WSL2, on an NVIDIA or AMD GPU.

GGUF in vLLM is GPU-only. On a CPU-only Windows box, the same file runs in Ollama or llama.cpp — both native.

lock 1 · hardware—the GGUF plugin serves GPU only — x86 and Arm CPUs refused

lock 2 · the os—the GPU-only path must run somewhere — on Windows that somewhere is WSL2, gpu passing through

the rule—both locks open together or not at all — and lock 1 never opens on a CPU-only box

Path	vLLM?	Setup	Best for
vLLM inside WSL2	full engine	one line + reboot	serving a team from one GPU
SystemPanic native fork	near-full, you test it	compile, chase CUDA	WSL blocked by policy, GPU attached
vLLM on a Linux box, Windows as client	full engine, elsewhere	any OpenAI-compatible client	the GPU lives in another room anyway
Ollama, native	no — different engine	one installer	solo use, GGUF, `127.0.0.1:11434`
llama.cpp, native	no — different engine	Windows binaries	one user, widest quant coverage

if the question was only "run a model on my windows box" — ollama, native, serving 127.0.0.1:11434. door 3 was never a door into vllm.

■ honest stamp Source: the public record — vLLM docs v0.24.0 + the Windows fork repos · checked 2026-10-12. The "OS: Linux" line, the WSL note and the fork census are quoted from the docs and the repos' own pages — stars, push dates and features as they stood that week. I've read the record, not run it; the WSL2 flow itself is the documented Linux install behind a one-line door.

end of the three doors · nothing fetched · everything local