vLLM 跑 Windows：三扇门，只有一扇被支持

■ space · 机器车间 · fig 1

■ 先给答案

不存在原生 Windows 构建。安装文档只列出一个 OS：Linux——原文如此，不是我说的。

可以跑：走 WSL2。Ubuntu 装在 Windows 里面，NVIDIA 驱动留在 Windows 一侧，照常跑 pip install vllm。

跳过 WSL 要交 fork 税——测试员就是你自己。单人使用？Ollama 原生跑 Windows。

93,632GitHub 星——没有一颗属于 linux 之外

1文档支持的唯一门路：wsl2

2压在 gguf 上的两把锁：gpu + os

01过墙转运库

一面墙，两个院子，三扇门——gpu 从管道上翻过去，从不装进箱子

FIG 1 · 过墙转运库按键 1 · 2 · 3 —— 或用按钮

ROUTE 1 · WSL2 —— 过墙成功 · 驱动在 Windows 一侧 · 判定通过

木箱就是一次请求——按 1 让它从 WSL2 走过，头顶的管道负责 gpu 过墙；门 2 和门 3 的代价写在水牌上

"vLLM 不原生支持 Windows。要在 Windows 上跑 vLLM，可以用 Windows Subsystem for Linux（WSL）配一个兼容的 Linux 发行版，

或改用部分由社区维护的 fork。"——安装文档，一字未改。前半句是那面墙；后半句就是本文。

02门 1，一步一走

powershell 里一行命令，里面就是普通的 linux 安装——驱动一步都不挪

门——powershell（管理员）

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

ubuntu 之内——普通 linux 安装

# 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

验证——从 windows 发起

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

验证：在 Windows 上 curl http://localhost:8000/v1/models —— WSL2 会转发 localhost，你的模型以 JSON 返回

驱动—住在 Windows 一侧，只装一次——NVIDIA 的 CUDA-on-WSL 把 GPU 递给任何发行版

经典陷阱—又在 Ubuntu 里面装一份驱动——折腾一晚上，去修一套从来没坏过的东西

amd—走 ROCm-on-WSL——这条路更窄，得提前打算

03门 2，fork 之税

场景文档自己点了名："一些社区维护的 fork"——这份普查，读于 2026-10-12

fork	记录	verdict
SystemPanic/vllm-windows	663 颗星，在本篇发布前一天还有推送	活着的那一个——原生轮子、CUDA 13、Blackwell、NCCL 多卡
devnen/vllm-windows	28 颗星，最后一次推送 2026 年 5 月。	五个月没动静——在这个跑得飞快的项目里，等于一张退休通知书
dexteri-ai/vllm-windows	GUI 外壳，创建于 2026 年 1 月	在 WSL2 里开 vLLM——正是它口称要绕开的那条路

"vLLM 只有在 Linux 上才能完整运行。"

——文档解释原因：CUDA 内核与 NCCL 只有在那里才完整存在。fork 有多少挺过 MSVC 重做，就说明这道工序有多狠。

这项税—MSVC-patched CUDA kernels, FlashAttention-3 没了，上游每发一版都得重测

何时交—只在 WSL 被策略挡住、附近又没有服务器时才交——不然走门 1 每次都更省

04两把锁，一张道路表

gguf 在 OS 锁之上又压了一把硬件锁——两把一起转，或一把都不转

可以——走 WSL2，在 NVIDIA 或 AMD 显卡上。

vLLM 里的 GGUF 只认显卡。纯 CPU 的 Windows 机器上，同一个文件在 Ollama 或 llama.cpp 里照跑——两者都原生.

锁 1 · 硬件—GGUF 插件 只服务显卡——x86 与 Arm 的 CPU 一律拒收

锁 2 · 操作系统—只认显卡的路径总得有个地方跑——在 Windows 上，那个地方就是 WSL2，显卡从底下穿过去

规则—两把锁一起开，或一把都不开——而且锁 1 在纯 CPU 机器上永远不开

Path	能用 vLLM 吗？	配置	最适合
vLLM 装在 WSL2 里	完整引擎	一行命令 + 重启	用一张卡给整个团队供服务
SystemPanic 原生 fork	接近完整，自己测试	要编译、追着 CUDA 跑	WSL 被策略封掉、但显卡在手
vLLM 放 Linux 机器，Windows 当客户端	完整引擎，放在别处	任何兼容 OpenAI 的客户端	反正显卡本来就住在另一个房间
Ollama, native	不能——另一个引擎	一个安装包	单人使用，GGUF， `127.0.0.1:11434`
llama.cpp, native	不能——另一个引擎	Windows 二进制	单个用户，量化覆盖最全

如果问题只是"在我的 Windows 机器上跑一个模型"——ollama，原生，服务 127.0.0.1:11434。门 3 从来就不是通往 vllm 的门。

■ honest stamp 出处：公开记录——vLLM 文档 v0.24.0 + 各 Windows fork 仓库 · 核对于 2026-10-12。 "OS: Linux" 这一行、WSL 说明与 fork 普查均引自文档和各仓库页面——星数、推送日期与功能都按那一周的实况记录。我读的是记录，没有实跑；WSL2 流程本身就是一行命令大门背后的那份照文档走的 Linux 安装。

三扇门到此为止 · 什么都没联网取 · 全程本地