先说结论Windows 上部署 vLLM 不是能不能的问题而是怎么选路线的问题。vLLM 官方并不支持 Windows 原生运行但借助 WSL2我们可以在一台 Windows 主力机上完整跑通 Qwen3-8B-FP8 的推理服务并且拿到接近 Linux 原生的性能。我花了差不多一个下午把这条路从零走到通过程中踩了不少坑也把一些教程里不会写但早晚会遇到的细节摸清了。这篇博文就是完整记录Windows 用户照着做就行。先说清一个事实Qwen3-8B-FP8 是 Qwen3 系列 8B 模型的 FP8 量化版本权重占用比 BF16 版本少一半配合 vLLM 的高吞吐推理能力能在 16GB 到 24GB 显存的消费级显卡上跑出不错的性能。如果你手头正好是 Windows NVIDIA 显卡又不想为了部署一个模型去装双系统这篇文章就是你需要的。1. 为什么 Windows 原生跑不起来vLLM 的 Linux 依赖决定了路线很多人第一次接触 vLLM 就卡在第一步pip install vllm在 Windows 上要么直接失败要么装上之后运行报一堆底层错误。这不是姿势问题而是 vLLM 的架构设计本身就深度绑定 Linux 生态。1.1 vLLM 底层依赖的Linux 专属组件到底有哪些vLLM 不是简单的 PyTorch 封装它内部依赖了三类在 Windows 上很难绕过去的东西NCCLNVIDIA Collective Communications Library多卡通信库vLLM 在初始化阶段即使单卡也会加载 NCCL。NCCL 官方只提供 Linux 版本Windows 上虽然有第三方移植但 vLLM 跟 NCCL 的版本绑定很严格经常出现 ABI 不兼容。CUDA 驱动模型vLLM 依赖 PyTorch 的 CUDA 运行时而 PyTorch 在 Windows 上的 CUDA 支持虽然存在但某些底层 Kernel尤其是 FlashAttention 相关的扩展在 Windows 上编译极易出问题。文件系统和内存映射vLLM 的 PagedAttention 依赖mmap类机制管理 KV cacheWindows 的内存映射语义和 Linux 差异不小导致很多代码路径在 Windows 上无法直接工作。搞懂了这层你就能理解为什么 vLLM 官方文档直接写着推荐 Ubuntu 22.04 以上版本。这不是傲慢是技术栈的客观约束。1.2 Windows 上可选的部署路线对比既然原生不行实际可选的路线主要有三条。我整理了一个表直接说结论路线实现方式性能损耗上手难度适合场景双系统装 Linux独立分区重启切换无中等需要重启长期稳定使用WSL2Windows Subsystem for LinuxWindows 内置的轻量虚拟机极低GPU 直通低命令即用个人开发验证、日常部署Docker Desktop基于 WSL2容器化封装环境低另有容器层开销低但镜像调试稍麻烦需要环境隔离、多人协作说实话双系统性能最干净但每次切换要重启成本太高。Docker Desktop 本质还是在 WSL2 里跑的相当于在 WSL2 上面再套一层容器。对新手来说直接 WSL2 反而是最少中间层、最好排查问题的方案。1.3 为什么我选了 WSL2理由和取舍我最终选了 WSL2核心原因有三个第一WSL2 的 GPU 直通是微软和 NVIDIA 官方合作的成熟方案。只要 Windows 侧装了支持 WSL 的 NVIDIA 驱动WSL 内部就能直接调用 CUDA性能和原生 Linux 差距非常小。实测跑推理任务差距通常控制在 3% 以内体感上几乎无差。第二WSL2 和 Windows 共享文件系统、共享网络端口这对日常开发太方便了。你在 Windows 浏览器里直接访问http://localhost:8000就能调到 WSL 里跑的 vLLM 服务不需要额外配端口转发。模型文件也可以放在 Windows 盘符下WSL 里通过/mnt/c/直接读取。第三出了问题好回滚。WSL2 是一个可销毁可重建的发行版环境折腾坏了wsl --unregister再来一遍也就几分钟比双系统折腾引导恢复要省心太多。2. 环境准备驱动、WSL2、Python 三件事一次搞定开始装东西之前先说一个很多教程不会点破的细节WSL2 里的 CUDA 并不是你在 Ubuntu 里通过apt install装出来的而是通过/usr/lib/wsl/lib映射到 Windows 驱动的。也就是说Windows 侧的显卡驱动版本决定了 WSL 里 CUDA 能力的上限。2.1 先把 Windows 侧显卡驱动更新到支持 WSL CUDA 的版本这一步极其重要建议放在最开始做。打开 Windows 的 PowerShell输入nvidia-smi看右上角的 CUDA 版本号。如果驱动版本过老WSL 里很可能出现nvidia-smi能显示但 PyTorch 认不到 GPU 的诡异情况。我当时踩的第一个坑就在这里Windows 驱动停留在 47x 版本WSL 里nvidia-smi正常输出但torch.cuda.is_available()一直返回False。排查半天去 NVIDIA 官网下载最新 Game Ready 驱动或 Studio 驱动装上之后问题立刻消失。提示不用特意在 WSL 里安装 NVIDIA Linux 驱动官方推荐方式是Windows 装驱动WSL 自动继承。如果你在 WSL 里手动装了 NVIDIA 驱动反而可能覆盖掉这个继承机制引起冲突。2.2 安装 WSL2 和 Ubuntu并确认 GPU 直通Win10 较新版本和 Win11 都支持一行命令安装wsl --install这个命令默认会装 WSL2 和 Ubuntu 发行版。如果你的机器上已经有 WSL1或者之前装过其它发行版可以用下面的命令确认版本并切换wsl --set-default-version 2安装完成后进入 Ubuntu 终端先跑nvidia-smi。如果能看到类似下面的输出说明 GPU 直通已经生效--------------------------------------------------------------------------------------- | NVIDIA-SMI 550.xx Driver Version: 550.xx CUDA Version: 12.4 | ---------------------------------------------------------------------------------------注意一个细节WSL 里的nvidia-smi显示的内存大小代表物理显卡的完整显存但它只是一个能力上限并不是说 WSL 独占整张显卡。Windows 侧的进程和 WSL 里的进程共享这块显存如果 Windows 侧有大量显存占用WSL 里的 CUDA 申请显存时就会 OOM。2.3 在 Ubuntu 里搭建 Python 环境vLLM 对 Python 版本有明确要求目前推荐的版本是 3.10 到 3.12。我建议直接用 Miniconda 管理环境不要用系统自带的 Python避免日后装别的项目时相互污染。wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh装完 conda 之后创建独立环境conda create -n vllm python3.11 -y conda activate vllm为什么不直接用 Python 3.12因为 vLLM 的部分编译依赖在 3.12 上曾经出现过兼容性问题3.11 是目前最稳的版本。这个选择能让后面省掉不少编译报错。2.4 安装 vLLM 的版本选择与验证环境激活后直接安装 vLLMpip install vllm如果你在中国大陆还可以配置国内 PyPI 镜像加速pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple这里有个容易犯的错pip install vllm会自动安装对应版本的 PyTorch 和 CUDA 依赖理论上不需要你手动装 torch。但如果你之前为了别的项目已经装了 CPU 版 torchconda 环境隔离做不到位时会出现vLLM 装好了import 时却报 torch 版本冲突的问题。所以建议在干净的 conda 环境里安装。安装完成后做一次最小验证python -c import torch; print(torch.__version__, torch.cuda.is_available())如果输出2.x.xcu12x True说明环境已经通了。如果输出False大概率是 torch 装成了 CPU 版或者显卡驱动的问题后面专门讲排查。3. 拉取 Qwen3-8B-FP8 模型并搞懂 FP8 到底省了什么环境准备好之后下一步是拿模型。但在下载之前我建议你先花两分钟理解 Qwen3-8B-FP8 这个名称的含义这直接关系到你后面在显存参数上怎么调。3.1 Qwen3-8B 和 FP8 量化版的关系Qwen3-8B 是通义千问 3 代目里一个全尺寸 Dense 模型参数规模约 8B。FP8 版则是在权重上做了 8 位浮点量化。FP8 最常用的格式是 E4M3即 1 位符号、4 位指数、3 位尾数。相比 BF1616 位浮点每个权重占用 2 字节FP8 每个权重只要 1 字节权重占用直接减半。8B 模型 BF16 版本光权重就有大约 16GBFP8 版本压缩到约 8GB。省下来的显存都成了你的 KV cache 和并发容量。精度上E4M3 牺牲了一部分尾数精度换来更大的数值范围和更低的显存占用。对 LLM 推理来说这种量化方式对输出质量的影响通常很小体感上基本感知不到和 BF16 的差别。这也是为什么 FP8 成为当前消费级显卡跑大模型的甜点精度。3.2 模型下载海外仓库速度慢的解决办法Qwen3-8B-FP8 托管在 Hugging Face 和 ModelScope魔搭上。如果你能稳定访问 Hugging Face直接用官方工具下载pip install huggingface_hub huggingface-cli download Qwen/Qwen3-8B-FP8 --local-dir ./qwen3-8b-fp8如果下载速度很慢或者断流有两个方案。第一个是使用 Hugging Face 镜像环境变量export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download Qwen/Qwen3-8B-FP8 --local-dir ./qwen3-8b-fp8第二个方案是直接从 ModelScope 下载Qwen 系列在魔搭上有官方仓库速度快且稳定pip install modelscope modelscope download --model Qwen/Qwen3-8B-FP8 --local_dir ./qwen3-8b-fp8我个人更推荐 ModelScope国内网络的下载体验要好一个档次。下载下来的目录里通常包含config.json、model.safetensors一个或分片多个、tokenizer.json、tokenizer_config.json等文件不需要额外整理vLLM 直接认这个目录结构。3.3 显存估算8B FP8 模型需要多大的卡先给一个粗略公式模型权重显存 ≈ 参数量 × 每参数字节数。8B × 1 字节 ≈ 8GB。再加上激活值、KV cache、CUDA graph 的开销实际运行最低建议 16GB 显存。具体到显卡16GB 显卡RTX 4080 笔记本版、RTX 4060 Ti 16G、部分专业卡可以跑但建议把上下文长度限制在 8192 或 16384并发数保守一些。24GB 显卡RTX 4090、RTX 3090很舒服可以把上下文拉到 32768并发开大。12GB 及以下不建议用 vLLM 硬跑FP8 版也有可能 OOM不如换 Ollama 这类更省显存的推理框架。另外注意一个架构层面的差异RTX 30 系Ampere没有原生支持 FP8 的 Tensor CorevLLM 会走一层反量化或软件模拟路径性能提升不明显RTX 40 系Ada Lovelace开始原生支持 FP8收益是最明显的。所以如果你手持 30 系卡FP8 更多是省显存意义而不是提速意义。4. 启动 vLLM 服务命令参数逐个说清楚模型下载完成环境验证通过接下来就是最核心的一步启动服务。我第一次启动时也踩了些坑这里直接给出完整命令和参数解释。4.1 我的启动命令从最短到可用假设你的模型存放在~/qwen3-8b-fp8目录下进入 conda 环境后执行vllm serve ~/qwen3-8b-fp8 \ --served-model-name qwen3-8b-fp8 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92 \ --port 8000逐项拆解~/qwen3-8b-fp8本地模型路径vLLM 会直接读取该目录下的权重文件也可以填 Hugging Face 仓库 ID 让它自动下载但本地路径更可控。--served-model-name qwen3-8b-fp8指定 OpenAI 兼容 API 中model字段的名称。不设的话API 里的 model 名称会默认是路径或仓库名不规范。--max-model-len 16384最大上下文长度。这个参数决定 KV cache 能申请多大并非越大越好。默认值通常较高如果你的显存是 16GB建议先设 8192跑通之后再往上加。--gpu-memory-utilization 0.92允许 vLLM 最多占用 92% 的显存。留一点余量给 CUDA context 和其它小开销避免满显存时 PyTorch 分配失败。--port 8000服务监听端口。如果你已经有服务占用 8000改成 8001 即可。如果你进一步追求显存优化还可以加--enforce-eager。这个参数会关闭 CUDA graph减少显存占用但副作用是推理速度明显下降。我的做法是先跑通默认模式如果 OOM 再加这个参数而不是一开始就用。4.2 第一次启动为什么要等很久第一次执行vllm serve时你会看到终端里不断滚动编译日志甚至有几行看起来像报错的 warning。这是正常的不是出问题了。vLLM 在首次运行时会针对你的显卡型号和 CUDA 版本现场编译一部分 Kernel 算子尤其是 FlashAttention 相关的模块这个过程根据机器性能不同可能需要几分钟。编译产物会缓存在~/.cache/vllm目录下第二次启动就会明显变快。所以如果你第一次启动时等了很久不要中途 CtrlC耐心等。启动成功的标志是日志中出现类似这样的信息INFO: Started server process [12345] INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000看到Application startup complete这行基本就稳了。这时候就算你什么都不做终端也不要关闭它是服务进程本身关掉终端服务就停了。4.3 启动成功后的日志怎么看服务跑起来后日志里最关键的信息有几个Loading model weights took xx.xx seconds权重加载耗时正常情况几十秒左右。GPU 0 memory: xx GB used / xx GB total显存占用情况可以用来核对你的显存估算是否准确。Maximum concurrency for x/y requests当前配置下的最大并发估算值这个数值可以指导你后续压测时开多大并发。vLLM is using nccl2.x.xNCCL 初始化信息看到它说明多卡相关组件已完成加载。我建议把启动日志完整保存一份后续如果服务异常退出排查起来会很方便。5. 接口验证与实测OpenAI 兼容 API 和性能数据服务启动不是终点。你得真正发一个请求确认推理结果正确再测一下吞吐能力这时候才是跑通了。5.1 用 curl 跑通第一个对话请求vLLM 提供 OpenAI 兼容接口这意味着你几乎可以把任何基于 OpenAI SDK 写的代码无缝切换到这个本地服务。最简单的验证方式是在 Windows 的 PowerShell 或 WSL 终端里执行 curlcurl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3-8b-fp8, messages: [{role: user, content: 用一句话解释什么是 vLLM}], max_tokens: 256, temperature: 0.7 }响应会是一个标准的 JSON里面包含choices数组和usage字段。usage里的completion_tokens和total_tokens可以帮你确认生成长度是否符合预期。注意两点请求里的model字段必须和启动时--served-model-name设置的名字一致否则 API 会报 model not foundmax_tokens不要超过启动时配置的--max-model-len。5.2 用 vllm bench 和服务日志看吞吐单条请求只是功能验证要评估部署效果得看吞吐量。vLLM 自带的vllm bench serve命令可以直接对正在运行的服务的/v1/chat/completions接口做压测vllm bench serve \ --model qwen3-8b-fp8 \ --tokenizer ~/qwen3-8b-fp8 \ --base-url http://localhost:8000 \ --request-rate 8 \ --num-prompts 40 \ --max-tokens 256这里面request-rate 8表示每秒发 8 个请求num-prompts 40表示总共打 40 个请求。压测结束后会输出一系列统计指标包括Output token throughput输出 token 吞吐量表示整个推理系统每秒能产出多少 token这是最核心的指标。Total request latency和TTFTTTFTTime To First Token表示首 token 延迟对对话类应用很关键。在 4090 上Qwen3-8B-FP8 输出吞吐做到几千 tokens/s 并不夸张。单请求指的是一路请求的生成速度体感大约在每秒几十到上百 token 之间。不同长度、不同并发配置下差异很大建议以自己的实测为准。5.3 FP8 在消费级显卡上的实际效果我实测 FP8 版本相比 BF16 版本最直观的收益是同样一张 4090BF16 版本在长上下文场景下很容易把显存顶满导致 OOM而 FP8 版本能稳定开出更高并发、更长上下文。如果你问精度单从对话质量上我没有发现明显劣化。Qwen3 本身有较强的指令跟随能力量化之后这种能力保持得相当完整。对绝大多数应用场景来说FP8 是既要又要还要的折中选择。5.4 和 LM Studio、Ollama 的定位差异很多 Windows 用户可能用过 LM Studio 或 Ollama这两个工具做得非常友好几乎一键就可以本地跑模型。但它们和 vLLM 的定位有很大差别对比项vLLMOllama / LM Studio底层引擎自研 PagedAttention、continuous batching多基于 llama.cpp核心优势高并发、高吞吐、生产级 API安装简单、资源占用低适用场景本地服务、多人并发、二次开发个人使用、轻量体验配置复杂度较高需要命令行低界面化对 Windows 的原生支持不支持需 WSL2支持原生 Windows如果你只是想在电脑上跟模型聊天用 Ollama 或 LM Studio 就行但如果你想做一个本地 API 服务接入自己的程序、处理多个并发请求vLLM 这种面向生产的引擎更有价值。6. 从零跑通后的坑位清单照着排查能省一个下午最后这部分是全文最值钱的地方。我把实际部署过程中遇到的、以及身边朋友最常见的排错场景整理成清单每个问题都给出完整的排查链路。6.1 torch.cuda.is_available() 为 False这个问题出现时通常 WSL 里nvidia-smi是正常的但 Python 认不到 GPU。排查顺序确认 Windows 侧驱动版本够新建议直接去 NVIDIA 官网下载最新版安装。确认你激活的是 conda 的 vllm 环境用which python看路径。查看 torch 的版本和编译信息python -c import torch; print(torch.__version__); print(torch.version.cuda)如果输出里没有cu121或cu124这样的 CUDA 标识说明 torch 是 CPU 版。解决办法是卸载重装 CUDA 版pip uninstall torch torchvision -y pip install torch torchvision --index-url https://download.pytorch.org/whl/cu1246.2 WSL 睡眠或重启后 CUDA 掉线这是 WSL2 特有的问题。你的 Windows 笔记本合盖睡眠再打开后WSL 里的 vLLM 服务还在跑但请求变得超慢或者直接报 CUDA error。原因是 GPU 在睡眠恢复后WSL 里的 CUDA context 失效了。排查和解决方案先试nvidia-smi如果显示 No devices found说明 GPU 直通需要重新初始化。最简单的处理退出 vLLM 服务执行wsl --shutdown注意这个命令会关闭整个 WSL 发行版然后重新打开 WSL 并启动服务。如果你打算让服务长时间运行建议在 Windows 电源设置里把睡眠关掉或者至少保证睡眠恢复后有一个自动重启服务的脚本。6.3 显存不足OOM 与参数调整启动时报 CUDA OOM或者跑着跑着一到某个长上下文就挂掉多半是max-model-len和gpu-memory-utilization配合不当。排查思路先看启动日志中显示的显存占用确认权重占了多大。如果不是 24GB 大显存卡把--max-model-len降到 8192 再试。如果还不行加--enforce-eager减少显存开销。注意 Windows 侧如果有 Chrome 浏览器、设计软件占着显存也会导致 WSL 里申请显存失败。可以临时关掉一些占显存的程序再启动。6.4 模型下载断流或文件损坏用huggingface-cli download下载大模型时中途断流很常见。有些时候下载完文件不完整vLLM 启动时safetensors加载失败。解决办法是优先用 ModelScope或者加镜像环境变量重试。下载完成后建议核对一下目录下文件大小尤其是model.safetensors的总大小。如果本地路径下存在.cache或.incomplete这类临时文件说明上次下载未完成删掉重下更稳妥。6.5 端口占用与 WSL 内存限制启动时报[Errno 98] Address already in use是端口冲突。用lsof -i :8000查看占用进程或者直接换端口vllm serve ~/qwen3-8b-fp8 --port 8001 ...另外 WSL2 默认会限制内存使用量默认是宿主机内存的 50% 左右。如果服务启动到一半进程被 kill可以检查一下.wslconfig文件并调大内存上限[wsl2] memory24GB processor8 swap8GB修改完wsl --shutdown重启 WSL 生效。6.6 关闭 WSL 才能释放显存WSL 里跑的进程占用的显存在 WSL 发行版关机之前可能不会完全释放。有时候明明服务已经停了Windows 侧看显存还是被占着十几个 GB就是 WSL 的遗留进程在作怪。解决办法是彻底关闭 WSLwsl --shutdown这个命令会停止所有正在运行的 WSL 发行版释放全部 GPU 显存和内存。代价是下次启动 WSL 需要重新手动启动你的 vLLM 服务。如果你需要服务常驻建议配合 systemd 或者写一个启动脚本。最后再说几句整个流程跑通之后我的感受是Windows 部署 vLLM 最大的障碍不是技术而是路线选择。只要选对 WSL2 这条路后面的步骤基本就是按部就班。如果你拿的是 16GB 显存级别的显卡Qwen3-8B-FP8 非常适合作为第一个真正能在本地跑起来的正经服务模型如果你只有 12GB 以下显存我更推荐你试 Ollama 走 llama.cpp 路线别在 vLLM 上死磕。vLLM 的价值在高吞吐和服务化单张低显存卡跑一个小模型收益确实有限。先跑通再谈优化这是所有部署工作的通用法则。