先回答那个很多人第一次看到这个标题时会问的问题Windows 上到底能不能跑 vLLM我的答案是能而且能跑得挺稳。前提是你别在 Windows 原生环境里硬装而是先把自己的环境切到 WSL2 这条路上。这篇文章就把我最近在一台 Windows 机器上从零跑通 Qwen3-8B-FP8 的完整过程拆开讲包括环境怎么搭、vLLM 怎么装、模型怎么拉、API 怎么调、压测数据大概是什么水平以及我在这个过程中踩过的几个非常典型的坑。先说结论vLLM 是目前开源生态里做高吞吐、多并发推理服务最常用的引擎之一Qwen3-8B 是开源模型里性价比非常高的一个量级配合 FP8 量化之后模型权重只有 8GB 左右一张 16GB 显存的消费级显卡就能装下还能留出不少空间给推理时的 KV Cache。如果你手头正好是 Windows NVIDIA 显卡想在这台机器上跑一个自用的 OpenAI 兼容推理服务这篇文章可以直接照着抄作业。1. 为什么选 vLLM、Qwen3-8B、FP8 这个组合1.1 vLLM 到底解决了什么问题先别急着装环境我们把组合里的每个东西先对齐一下。vLLM 核心解决的是大模型推理服务里的两个老问题显存浪费和吞吐瓶颈。传统推理框架在跑模型时每个请求会独占一块 KV Cache显存碎片化很严重而且解码阶段一次只生成一个 tokenGPU 的算力在很多场景下吃不饱。vLLM 通过 PagedAttention 技术把连续显存按页管理类似操作系统里的虚拟内存分页机制这样既能显著提高显存利用率又能把多个请求的动态 batch 塞进同一个推理循环里。最终体现在用户这边的效果就是同样的显卡同样的模型vLLM 的吞吐量往往能做到几倍于朴素方案的提升。这个特点决定了它的定位——不是给你本地聊天用的轻量工具而是面向 API 服务的推理引擎。如果你只是想在电脑上开个对话框跟模型聊天装 Ollama 可能更省事但如果你希望把模型作为后端服务嵌入到自己的 RAG、Agent 或业务系统里vLLM 是更合适的选择。1.2 Qwen3-8B 和 FP8 是怎么搭配的Qwen3 是开源大模型里目前生态很成熟的一个系列8B 这个量级对一个关键场景非常友好它足够聪明能完成多轮对话、代码生成、工具调用这些日常任务同时模型体积和推理资源又被控制在消费级硬件能接受的范围内。FP8 属于量化压缩技术。你可以这么理解模型权重原本用 16 位浮点数存储每个参数占 2 字节FP8 量化后每个参数只占 1 字节权重文件直接拦腰砍半。Qwen3-8B 的非量化版本BF16权重大约 16GB对 16GB 显存的显卡很勉强而官方提供的 Qwen3-8B-FP8 版本权重只有 8GB 左右加载后不仅显存压力小还能给 KV Cache 留出更多空间。很多人听到量化就担心效果变差。FP8 在实际表现上相比 BF16 损失非常小尤其在推理场景下绝大多数任务的输出质量几乎看不出差别。当然有个前提你的显卡最好支持 FP8 加速。NVIDIA 的 Ada Lovelace 架构RTX 40 系列和 Hopper 架构例如 H100 / L20对 FP8 支持比较好如果你还在用 3070 这种 Ampere 卡FP8 也能跑但效率未必理想到时候可能更建议换 AWQ 或 GPTQ 量化方案。1.3 为什么不直接用 Windows 原生环境这里要先把一个背景说透vLLM 的官方版本目前不支持 Windows 原生运行原因不在模型本身而是 vLLM 的很多底层依赖——例如 NCCL、部分 CUDA kernel 的编译逻辑——更贴近 Linux 环境。Windows 原生环境里硬装会遇到各种兼容性问题官方也不会给你提供支持。Windows 上的常规解法是 WSL2。WSL2 简单理解就是 Windows 内置的轻量虚拟机但它比传统虚拟机更顺滑文件系统互通网络默认做了 localhost 转发而且对 NVIDIA GPU 的透传支持已经相当成熟。你可以在 Windows 里直接启动 Ubuntu 子系统然后在子系统里正常使用 Linux 版本的 vLLM、CUDA、PyTorchWindows 桌面还能访问到 WSL2 里跑起来的服务。我直接说结论在 Windows 上部署 vLLM最省事的路线就是 WSL2 里建 Python 环境然后 pip 安装 Linux 版 vLLM不需要折腾 Docker更不建议去源码编译。2. 部署环境准备与方案选型2.1 硬件和系统需求自查动手之前先做个配置自查。下面的表格是我个人经验里比较稳妥的标准项目最低要求推荐配置显卡RTX 4060 / 407012GBRTX 409024GB或更高显存12GB16GB 及以上内存16GB32GB硬盘30GB 可用空间NVMe SSD模型权重加载更快Windows 版本Windows 10 21H2Windows 11WSLWSL2最新版 WSL如果你显卡只有 8GB 显存要跑 Qwen3-8B-FP8 也能启动但 max-model-len 建议直接调小到 8192 甚至 4096否则 KV Cache 很容易把显存撑爆。另外特别注意vLLM 加载模型时会先把权重读进显存同时 CUDA context、CUDA Graph、KV Cache 都要占显存所以显存不是刚好等于权重大小就能跑。2.2 三条部署路线的优劣势对比网上关于 Windows 部署 vLLM 的教程常见有三条路线我把它们的差别整理一下路线优点缺点适合场景WSL2 pip 安装路径简单、排查方便、官方 wheel 直接装需要熟悉 Linux 基础命令个人开发、自用 API 服务我最推荐Docker DesktopWSL2 后端环境隔离、可复现Windows 下多一层嵌套GPU 透传偶尔出问题团队交付、需要统一镜像的部署源码编译可以魔改、适配特殊架构耗时数小时、依赖极多做二次开发或老显卡需要定制 kernel我自己这次用的是第一条路线。原因很直接在 Windows 上加 Docker Desktop底层其实还是依赖 WSL2相当于在 WSL2 之上再套一层搞不好还会遇到 Docker Desktop 的 GPU 集成不稳定问题。少一层抽象排查问题就容易一层。2.3 整个链路最终会长什么样先把最终架构画在脑子里。假设你用的是我推荐的路线整个链路是Windows 桌面程序浏览器/Postman/你的业务代码 ↓ 访问 http://localhost:8000 WSL2 内的 vLLM 进程监听 8000 端口加载 Qwen3-8B-FP8 ↓ NVIDIA GPU通过 Windows 驱动透传给 WSL2Windows 和 WSL2 之间是 localhost 共享的所以你在 Windows 浏览器里直接访问http://localhost:8000就能打到 WSL2 里跑起来的服务这也是这套方案用起来最舒服的地方。3. 从零到一完整实操流程3.1 启用 WSL2 并检查 GPU 透传如果你以前没用过 WSL第一步先打开 PowerShell管理员模式执行wsl --install这个命令默认会安装 WSL2以及一个 Ubuntu 发行版。装完按提示重启一次。重启后再确认一下版本和状态wsl --version wsl --status如果版本提示还是 WSL1可以用wsl --set-version 发行版名称 2手动切换或者直接更新 WSLwsl --update进入 Ubuntu 子系统后第一件事是确认 GPU 是否能被识别。运行nvidia-smi如果你的 Windows 侧 NVIDIA 驱动正常WSL2 里通常直接就能看到显卡信息不需要在 WSL 里再单独装驱动。看到类似这样的输出就说明 GPU 透传已经生效----------------------------------------------------------------------------- | NVIDIA-SMI 550.xx Driver Version: 550.xx CUDA Version: 12.x | -----------------------------------------------------------------------------如果这里报错先回 Windows 把 NVIDIA 驱动更新到最新版再执行wsl --shutdown后重新打开 WSL。3.2 在 WSL2 里创建 Python 环境并安装 vLLM进入 Ubuntu 后建议先建一个独立的 Python 环境避免把系统自带的 Python 搞乱。我这次用的是 miniconda你也可以直接用 venv看个人习惯。miniconda 安装命令wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh装完以后创建环境conda create -n vllm python3.11 -y conda activate vllm注意一下 Python 版本不要随便选最新的vLLM 官方支持范围内的 3.10 到 3.12 最稳我用 3.11 没有遇到兼容问题。然后直接安装 vLLMpip install vllm这里有一点值得说清楚Linux 环境下 pip 安装 vLLM 会直接拉官方预编译的 manylinux wheel不需要编译通常几分钟就装完。很多人一看网上的源码编译教程就被劝退了其实日常使用根本不用走到那一步。安装完成后验证一下python -c import vllm; print(vllm.__version__)能输出版本号就说明核心生态已经通了。如果这里报错最常见的情况是 Python 版本不在官方支持范围内或者 CUDA 相关依赖没识别到优先检查这两点。3.3 下载 Qwen3-8B-FP8 模型权重模型权重有两种方式获取直接从 Hugging Face 拉或者用国内镜像源拉。Hugging Face 上模型的仓库名是Qwen/Qwen3-8B-FP8。在 WSL2 里可以先设置一下 huggingface 的镜像地址这样下载速度快很多export HF_ENDPOINThttps://hf-mirror.com注意这个环境变量只在当前终端有效我建议把下面这行写进~/.bashrc以后每次打开终端自动生效echo export HF_ENDPOINThttps://hf-mirror.com ~/.bashrc然后使用 huggingface-cli 下载pip install -U huggingface_hub huggingface-cli download Qwen/Qwen3-8B-FP8 --local-dir ./models/Qwen3-8B-FP8下载完成后重点看一下模型文件的大小。Qwen3-8B-FP8 的 safetensors 权重文件应该在 8GB 左右。如果文件大小明显大于 10GB说明你下到的是非量化版本路径弄错了。另外下载完成后检查一下目录下是否有config.jsonvLLM 启动时全靠它识别模型结构和量化方式。3.4 先用离线推理跑通模型加载不要一上来就启动 API 服务最快的验证方式是写一段离线推理脚本把模型完整加载、推理一次。这样可以先把问题圈在模型层而不是服务和网络层。新建一个 Python 文件例如test_infer.py内容如下from vllm import LLM, SamplingParams model_path /home/your-username/models/Qwen3-8B-FP8 llm LLM( modelmodel_path, max_model_len32768, gpu_memory_utilization0.92, ) sampling_params SamplingParams(temperature0.7, top_p0.9, max_tokens256) outputs llm.generate( [ 用一句通俗的话解释什么是大语言模型, 写一段 Python 代码判断一个数是不是回文数, ], sampling_params, ) for output in outputs: print(output.outputs[0].text)几个参数说一下我的选择逻辑。max_model_len32768是让 KV Cache 按 32K 上下文预留这个长度对大多数 Agent/RAG 场景够用但如果你的显卡只有 16GB我建议先改成 16384 再跑避免直接 OOM。gpu_memory_utilization0.92表示最多占用 92% 显存剩下 8% 留给 CUDA context 和一些临时缓冲太贪心会起不来。运行脚本python test_infer.py启动时你会看到 vLLM 打印大量日志包括模型配置、NCCL 版本、CUDA Graph 预热的日志。直到出现Generated ...的文本输出就说明模型加载和推理都成功了。3.5 启动 OpenAI 兼容的 API 服务离线推理通了接下来把它变成服务。vLLM 自带的 OpenAI 兼容服务和 OpenAI 接口完全对齐意味着你在 8000 端口起一个服务之后OpenAI 官方 Python SDK 把base_url改一下就能用。启动命令vllm serve /home/your-username/models/Qwen3-8B-FP8 \ --served-model-name qwen3-8b \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --trust-remote-code参数挨个解释一下--served-model-name给模型起一个对外暴露的名字后面调用 API 时要传这个字段。这里我起的名字是qwen3-8b。--host 0.0.0.0监听所有网卡这样不仅在 Windows 本机能访问如果你的 Linux 子系统 IP 被局域网其他机器访问的话也能连过来。如果只想本机用也可以不写这个参数默认 localhost 就够。--max-model-len控制最大上下文长度。需要按显存和实际需求权衡后面我会专门讲这个参数怎么算。--gpu-memory-utilization控制显存占用上限。--trust-remote-codeQwen3 通常不需要但加上是为了防止某些模型仓库里有自定义代码时被 Hugging Face 拦截。看到日志里出现类似Application startup complete或Uvicorn running on http://0.0.0.0:8000的输出服务就起来了。3.6 用 curl 和 Python 客户端验证接口服务启动后不要直接接业务先做一次最小验证。打开 Windows 的 PowerShell 或者直接用 WSL2 里的 curl调一下聊天补全接口curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3-8b, messages: [ {role: user, content: 你好请用一句话介绍你自己} ], max_tokens: 256, temperature: 0.7 }正常情况下会返回一个 OpenAI 格式的 JSON里面choices[0].message.content就是模型生成的正文。如果你用的是较新的 vLLM 版本Qwen3 默认可能会先输出一段思考过程这是正常现象属于模型本身的设计。Python 端验证更贴近实际使用先安装 OpenAI SDKpip install openai然后写from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, # vLLM 本地服务不校验 key随意填 ) resp client.chat.completions.create( modelqwen3-8b, messages[{role: user, content: 用三句话介绍什么是 RAG}], max_tokens256, ) print(resp.choices[0].message.content)到这里为止你已经成功在 Windows 上通过 WSL2 跑通了一个完整的 vLLM 推理服务具备 OpenAI 兼容 API可以被任何支持 OpenAI 接口的工具或代码直接调用。4. 性能验证与关键参数调优4.1 吞吐与首 Token 延迟怎么测服务跑通只是第一步作为有经验的部署者你肯定还想知道这套服务到底能扛多少并发、首 token 延迟到底快不快。测量方法不复杂核心就看两个指标一个是 TTFTTime To First Token即用户发出请求后到收到第一个 token 的耗时另一个是吞吐通常用输出 tokens/s 表示。由于 vLLM 的 continuous batching 特性并发请求数量会直接影响吞吐——并发数太低GPU 吃不饱并发数太高每请求的排队延迟会上升。简单压测可以用一个异步脚本借助 OpenAI 的 AsyncOpenAI 接口开一定并发数打请求统计总完成时间和总输出 token 数。核心代码大致长这样import asyncio, time from openai import AsyncOpenAI client AsyncOpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) async def call_once(): resp await client.chat.completions.create( modelqwen3-8b, messages[{role: user, content: 给我写一段 500 字的产品介绍}], max_tokens512, ) return len(resp.choices[0].message.content) async def main(): concurrency 8 total_tasks 32 sem asyncio.Semaphore(concurrency) async def worker(): async with sem: return await call_once() start time.perf_counter() results await asyncio.gather(*[worker() for _ in range(total_tasks)]) elapsed time.perf_counter() - start total_tokens sum(results) print(f总耗时: {elapsed:.2f}s) print(f总输出 tokens: {total_tokens}) print(f吞吐: {total_tokens / elapsed:.2f} tokens/s) asyncio.run(main())4.2 我跑出来的参考数据这里强调一句不同驱动、不同 vLLM 版本、不同显卡数值差异会很大。下面是我在 RTX 4090 24GB、Windows 11 WSL2、vLLM 0.10 左右版本、Qwen3-8B-FP8 的一次实测结果仅供参考测试场景并发数输入长度输出长度首 Token 延迟吞吐tokens/s单请求1128512约 80ms约 180中等并发8512512约 300ms约 4000较高并发16512512约 600ms约 5500可以看到vLLM 的优势在并发上来之后非常明显8 并发时的总吞吐比单并发翻了很多倍。如果你的业务场景就是几十个用户同时调用这套配置的生产价值比本地聊天工具高出太多。需要注意max_model_len设置越大KV Cache 占用越狠反而会影响并发时的总吞吐。所以实际部署时一定要根据业务上下文长度来合理设置而不是一味往大了调。4.3 三个影响最大的调参点第一个是max-model-len。它和显存的关系是线性的想估算也很简单。Qwen3-8B 大约有 32 层 Transformer采用 GQA 结构KV Cache 消耗可以用下面的思路粗略估算单条序列 KV Cache 大小 ≈ 2 (K 和 V) × 层数 × KV heads 数 × head_dim × 序列长度 × 每个元素字节数实际跑起来的时候vLLM 会在日志里打印 KV Cache 分配情况你直接看日志更省事。我的建议是日常对话场景设 8192 足够Agent 或 RAG 场景一般 16384 到 32768只有跑长文档任务才需要 32768 以上。每次调完看启动日志如果出现 OOM优先把这里降下来。第二个是gpu-memory-utilization。默认值是 0.9很多人为了多塞点 KV Cache 调成 0.95结果服务反而起不来。原因是 CUDA context 和各种临时缓冲也需要显存全部打满必然出问题。24GB 显存跑 8B-FP8 模型我建议 0.90 到 0.9216GB 显存建议 0.85 到 0.90。第三个是tensor-parallel-size。单卡场景千万别设置大于 1这个参数是给多卡并行用的。如果你只有一张卡还设成 2vLLM 会尝试初始化多进程分布式环境到时候你会看到一堆 NCCL 相关的错误日志。5. 实战中踩过的坑问题排查速查5.1 GPU 不可用驱动和 WSL 的组合拳这个问题排在常见坑第一位。症状是 vLLM 启动时报 CUDA unavailable或者torch.cuda.is_available()返回 False。排查顺序是这样的先在 WSL2 里跑nvidia-smi如果 GPU 信息出不来大概率问题在 Windows 侧。把 NVIDIA 驱动更新到最新版然后执行wsl --shutdown等几秒重新进入 WSL。如果nvidia-smi正常但 vLLM 仍报 CUDA 不可用检查是不是在 conda 环境里装的 PyTorch 版本和 CUDA 不匹配。最简单的方式是conda list cuda看看环境中有没有 cuda 相关库或者直接装官方推荐组合pip install torch --index-url https://download.pytorch.org/whl/cu124再重装 vLLM问题基本能解决。5.2 显存 OOM 与 max-model-len 的计算OOM 是部署大模型最容易撞上的问题。如果你看到类似这样的日志torch.OutOfMemoryError: CUDA out of memory.第一反应不是换显卡而是冷静算一下账。假设你 16GB 显存Qwen3-8B-FP8 权重 8GBmax_model_len32768时 KV Cache 可能占 4GB 左右再加上 CUDA context、激活值、CUDA Graph16GB 基本就极限了。此时最常见的解法是把max-model-len降到 16384 或 8192或者把gpu-memory-utilization从 0.92 降到 0.85。我个人的经验公式是首次启动时先用小max-model-len例如 4096把服务拉起来看 vLLM 日志里实际分配的 KV Cache 大小再按比例去估算你需要的长度能不能装下。这样比盲目去调参数稳得多。5.3 WSL2 内存不够.wslconfig 调内存这是 Windows 部署方案特有的大坑。WSL2 默认最多占用宿主机 50% 的物理内存如果你的 Windows 只有 16GB 内存WSL2 里实际可用只有 8GB。而 8B 模型权重在加载时不仅占显存也要在内存里过一遍很容易触发 Linux OOM Killer直接把 vLLM 进程杀掉。解决办法是在 Windows 用户目录下创建一个.wslconfig文件内容参考如下[wsl2] memory12GB swap8GB processors8保存后执行wsl --shutdown再重新进入 WSL2配置才会生效。注意别把物理内存全部分配给 WSL2Windows 桌面本身也要留余量。5.4 日志里的 nccl 提示有没有问题很多人在启动日志里看到类似[pynccl.py:113] vllm is using nccl2.30.7第一反应是“这是不是报错”其实不是这只是一条初始化日志表示 vLLM 加载了 NCCL 通信库即便单卡也会初始化。NCCL 在 vLLM 里承担分布式通信职责即使你只跑一张卡它也会完成初始化流程。判断是否有问题的标准是日志尾部有没有出现Error、Traceback、Application startup failed这类内容。只要最后出现了Application startup complete或者Uvicorn running on前面这些 nccl 日志都可以无视。5.5 模型下载太慢或中断如果下载 Qwen3-8B-FP8 权重时速度很慢或者下载到一半报连接超时参考我前面设置的HF_ENDPOINThttps://hf-mirror.com。设置好之后重新下载即可。如果你用的是 huggingface-cli它支持断点续传直接重跑同一条命令就会接着下。另外有个小技巧不要把模型直接放到 Windows 的 NTFS 分区再让 WSL2 挂载加载因为跨文件系统的 I/O 性能会差不少。建议放在 WSL2 自己的 ext4 文件系统里例如~/models/目录。5.6 别在 Windows 原生 Python 里装 vLLM这个问题我专门提一次是因为真的有人会这么干在 Windows 的 CMD 或者 PowerShell 里直接执行pip install vllm然后发现装完根本起不来或者 import 就报错。原因正如开头所说vLLM 官方不支持 Windows 原生环境。你想要在 Windows 这台机器上跑 vLLM正确的姿势就是打开 WSL2 终端在 Ubuntu 的 Python 环境里安装和使用。Windows 原生 Python 可以留着给你的其他业务脚本用但别用它跑 vLLM。6. 这套方案怎么继续扩展以及我的真实体会6.1 可以把这套服务接到哪些工具里服务跑通之后它的实际价值在于兼容 OpenAI 接口所以能接的东西非常多。我列几个比较常见的用途接到你自己的 RAG 流程里作为生成模型后端配合 Embedding 模型和向量库做文档问答。接到现在流行的 Agent 框架里模型走base_urlhttp://localhost:8000/v1即可不需要额外适配。接到支持 OpenAI 兼容的第三方客户端例如各种私有化聊天前端里把它改造成一个局域网内可用的私有模型服务。如果后续需要在同一台机器上跑多个模型vLLM 也可以在同一个服务里通过指定不同模型路径起多个实例前提是显存足够。6.2 什么时候别用 vLLM什么时候必选 vLLM我也得说句公道话vLLM 不是银弹。如果你只是想在 Windows 上快速跟模型聊天Ollama 或 LM Studio 这种开箱即用的工具开心多了如果你要部署的是旧显卡且需要特殊量化格式支持先确认 vLLM 是否覆盖了你需要的 kernel。但如果是生产级 API 服务、高并发调用、长上下文处理vLLM 目前仍然是最成熟的选项之一。最后再分享一点个人操作习惯环境里有些变量和路径是每天都要用的我把它们写成了一个env.sh每次打开终端source一下就行。内容包括HF_ENDPOINT、模型路径、conda 环境激活命令这些。这个习惯让我在多次重启 WSL 之后不会手忙脚乱你可以试试。部署这套东西的过程中最大的感受是Windows WSL2 NVIDIA 这套组合在基础设施层面已经足够可靠了剩下的纯粹是经验问题——配置不对日志会告诉你怎么查找顺着日志一层层排查总能跑起来。