> 能在 Windows 上运行 vLLM 吗？可以——通过 WSL2▋

自 2023 年 2 月以来拿下 93 632 个 GitHub 星标，而安装要求至今仍以一行开头：“OS: Linux. Python 3.10–3.13.” 再往下两行，就是让所有人跑去搜索的那条备注：“vLLM 不原生支持 Windows。要在 Windows 上运行 vLLM，可以使用适用于 Linux 的 Windows 子系统（WSL）搭配兼容的发行版，或者使用一些社区维护的 fork。”这条备注就是整篇文章。官方道路是 WSL2；原生道路是 fork，而且 bug 报告上写的是你的名字。本文属于本地运行 LLM 集群，就在同一把锁的硬件那一半旁边——vLLM 能跑 GGUF 吗。

怎么在 Windows 上运行 vLLM？

走 WSL2，而且很快你就感觉不到这是 Windows 了。

• Windows 10/11 加 NVIDIA GPU？AMD 要走 ROCm-on-WSL，路更窄——先有心理准备
• 在管理员 PowerShell 里执行 wsl --install -d Ubuntu，然后重启
• NVIDIA 驱动装在 Windows 侧——WSL 里一个都不装，GPU 穿透过去
• 在 Ubuntu 里：uv pip install vllm——和文档里一模一样的 Linux 流程
• 起一个小模型并请求 models 端点确认——命令在下面

WSL2 等于 Microsoft 官方承认：Windows 最好的功能是 Linux。它随系统附带，一行命令装好，进了 Ubuntu 之后，网上任何 vLLM 教程对你原样适用：

# PowerShell（管理员）——提示后重启：
wsl --install -d Ubuntu

# 在 Ubuntu 里——普通的 Linux 安装，没有任何 Windows 特殊步骤：
uv venv --python 3.12 && source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# 起一个小模型，证明 GPU 穿透成功：
vllm serve Qwen/Qwen3-0.6B --port 8000

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

大家都漏掉的细节：GPU 驱动住在 Windows 侧。NVIDIA 的 CUDA-on-WSL 设计让 GPU 穿透 Windows 驱动进入任意发行版，所以驱动只装一次，在 Windows 里装，永远不要装进 Ubuntu。偏要在 WSL 里也装一个驱动，你就能花一整晚去“修”一套从来没坏过的东西。

不用 WSL 能在 Windows 上跑 vLLM 吗？

只能靠社区 fork——“分叉税”是真实存在的：你把安装器换成了编译器。

文档自己点名了这个局面：“一些社区维护的 fork”。这周我把它们的记录都读了一遍：

• SystemPanic/vllm-windows——活着的那一个。663 星，本帖发布前一天还在提交。原生 Windows wheel、CUDA 13、Blackwell 支持，甚至在 Windows 上通过 NCCL 做多卡。一个认真的项目，做着核心拒绝做的事。
• devnen/vllm-windows——28 星，最后提交 2026 年 5 月。在更新这么快的项目里沉默五个月，等于一张退休通知。
• dexteri-ai/vllm-windows——一个 GUI 壳，2026 年 1 月创建。看穿界面：它驱动的是 WSL2 里的 vLLM——正是它声称要替你跳过的那条路。

就算在健康的 fork 上，你也是在用 MSVC 补丁编译 CUDA kernel、失去 FlashAttention-3、每次上游发版都要重新测。这就是分叉税。只在公司政策禁 WSL 又够不着服务器时才付——而不是因为一行命令的安装显得太容易。

为什么根本没有原生 Windows 版本？

vLLM 要编译 CUDA kernel，还依赖 NCCL——一套只在 Linux 上完整的工具链。文档说得直白：“vLLM 只能在 Linux 上完整运行。”原生移植意味着为 MSVC 重做 kernel 构建——正是项目选择不背的维护负担；各 fork 的存活数量就是这项工作量的度量。

Windows 上的 vLLM 能跑 GGUF 模型吗？

可以——通过 WSL2，在 NVIDIA 或 AMD GPU 上。vLLM 里的 GGUF 只支持 GPU，所以 Windows 是在硬件要求之上再叠一层系统要求。纯 CPU 的 Windows 机器，请把同一个文件交给 Ollama 或 llama.cpp——两者都是原生的。

两把锁，按顺序。先是硬件锁：vLLM 能跑 GGUF 吗——能，走官方插件，仅限 GPU，x86 和 Arm CPU 拒收。然后是系统锁，也就是本文：GPU-only 的路径总得在某个系统上跑，在 Windows 上这个“某处”就是带着 CUDA 穿透的 WSL2。两把锁要么一起开，要么都别开。完全没有 GPU？文件照样能跑——本地运行 GGUF 模型覆盖了原生工具，选哪个量化见我们的量化指南。

在 Windows 上用 vLLM——还是直接 Ollama？

大多数关于 Windows 上 vLLM 的问题，其实是并发问题。vLLM 存在的意义是用持续 batching 让一块大 GPU 服务很多用户。如果用户数是“我，在我桌面上”，诚实的答案就是最后一行：

路径	vLLM？	安装	适合
WSL2 里跑 vLLM	完整引擎	一行命令 + 重启	用一块 GPU 服务一个团队
SystemPanic 原生 fork	接近完整，测试靠你	编译，追着 CUDA 跑	政策禁 WSL 但有 GPU
Linux 机器上跑 vLLM，Windows 当客户端	完整引擎，在别处	任何 OpenAI 兼容客户端	GPU 本来就住在另一个房间
Ollama，原生	不——另一个引擎	一个安装器	单人使用、GGUF、端口 11434
llama.cpp，原生	不——另一个引擎	Windows 二进制	一个用户，最广的量化覆盖

文档的支持表写着 Linux。WSL2 说：没问题。如果背后的问题从来不是 vLLM——只是“在我的 Windows 机器上跑个模型”——那从来就没有哪扇门锁上过：Ollama 原生安装，监听 127.0.0.1:11434，它要是不肯启动，那次失败我们也解剖过。