其实把开源大模型跑成一个能扛并发的线上推理服务远比“能对话”难得多。很多人本地用 Ollama 拉个 Qwen3 就能聊天可一旦要把它接到业务里、撑住几十路并发、还要和 OpenAI 的接口一致Ollama 就不够看了。我这次直接用 vLLM 把 Qwen3 部署成一个标准 OpenAI 兼容推理服务从环境、启动、调用到压测把每一步能复制的命令和踩过的坑都记下来。一、为什么选 vLLM 而不是 OllamaOllama 胜在上手快但它本质是单用户、单会话的本地工具没有连续批处理continuous batching并发一上来吞吐就掉。vLLM 的关键卖点是 PagedAttention 显存管理和连续批处理能把一张卡的利用率压到实处。我的独到判断是选型不该看“哪个更火”而该看“请求是不是多路”。如果是个人玩Ollama 足够如果是给团队或一个内部应用当后端vLLM 才是正解。这条路线和“图省事先用 Ollama 顶着”的默认做法形成了差异化。来源vLLM 官方文档对 PagedAttention 与 continuous batching 的说明2026 年 10 月复查二、环境准备我在一台装了 A100 80G 的机器上验证CUDA 12.4。先建干净虚拟环境# 1. 建环境python-mvenv vllm-envsourcevllm-env/bin/activate# 2. 装 vLLM自带 CUDA 运行时无需单独装 torch 的 CUDA 版pipinstallvllm# 3. 确认版本与显卡可见python-cimport vllm; print(vllm.__version__)nvidia-smi注意vLLM 对 CUDA 和驱动版本有要求安装后务必跑上面第 3 步确认能识别到卡。我头一回就是驱动太旧import 不报错但一启动就报 CUDA 不可用。三、启动推理服务关键命令就一行但几个参数决定了你能不能跑起来、跑得稳不稳vllm serve Qwen/Qwen3-8B-Instruct\--host0.0.0.0\--port8000\--tensor-parallel-size1\--gpu-memory-utilization0.90\--max-model-len8192\--enable-prefix-caching\--max-num-seqs256逐参数说明--tensor-parallel-size几张卡切分一个模型单卡就填 1。--gpu-memory-utilization显存占用上限默认 0.9OOM 就往下调。--max-model-len上下文长度设太大显存会爆按业务实际需要砍。--enable-prefix-caching相同前缀的 prompt 复用 KV多轮对话省算力。--max-num-seqs并发序列数上限调吞吐的旋钮。启动后访问http://机器IP:8000/docs能看到 OpenAI 兼容的接口文档。四、用 OpenAI SDK 调用因为接口兼容 OpenAI业务代码几乎零改动只改 base_urlfromopenaiimportOpenAI clientOpenAI(base_urlhttp://localhost:8000/v1,api_keyEMPTY,# vLLM 本地服务不校验 key)respclient.chat.completions.create(modelQwen/Qwen3-8B-Instruct,messages[{role:user,content:用一句话解释什么是连续批处理}],streamTrue,)forchunkinresp:ifchunk.choices[0].delta.content:print(chunk.choices[0].delta.content,end)也可以直接用 curl 测通断curlhttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{model:Qwen/Qwen3-8B-Instruct,messages:[{role:user,content:你好}]}五、吞吐压测别拍脑袋到底能扛多少并发用 vLLM 自带的压测工具说话别凭感觉vllm bench serve\--modelQwen/Qwen3-8B-Instruct\--backendopenai-chat\--num-prompts500\--request-rate16\--sharegpt\--hostlocalhost--port8000报告里重点看四个数首字延迟TTFT、每输出 token 间隔ITL、请求成功率、输出吞吐token/s。在我这台 A100 上Qwen3-8B 这类量级通常能做到数千 token/s 的输出吞吐具体数值取决于--max-num-seqs和 prompt 长短所以请用自己的硬件跑一遍上面这条命令拿到真实数字。来源vLLM benchmark 文档对 TTFT、ITL、输出吞吐的定义2026 年 10 月复查六、工程取舍其一量化还是不量化。fp16 精度更稳但更占显存AWQ 或 GPTQ 的 4bit 能把显存砍掉一半多代价是精度轻微下降。我的做法是先在 fp16 上验证业务效果真放不下再上 4bit。其二张量并行还是流水并行。单模型放不下一张卡时用张量并行TP如果是长上下文、多卡且不想切太碎才考虑流水并行PP。新手先把 TP 调明白。其四流式还是非流式。对话类产品务必开 stream首字延迟体验更好而离线批量打标、评测这类场景用非流式更简单还能少写一层回调。其三prefix caching 要不要开。多轮对话、系统提示固定的场景建议开启能明显降延迟一次性短任务开了也没坏处。七、踩坑清单比如显存爆了不要先加卡先调--gpu-memory-utilization和--max-model-len我见过有人模型才 8B 却把上下文开到 32K 直接 OOM。比如并发上不去别急着怪模型先看--max-num-seqs是不是被你的显存顶住了适当下调反而更稳。再比如聊天接口和补全接口别混用业务里用的是/v1/chat/completions老代码可能还调/v1/completions两者 prompt 模板不同结果会乱。再比如换基座模型后 tokenizer 对不上表现就是乱码或报词表越界。我遇到过从 Qwen2 切到 Qwen3 没清旧缓存结果前几轮输出全是乱码清掉缓存目录重拉才正常。另外量化模型文件名里带 awq 或 gptq 后缀启动时要填带后缀的准确路径少写一个字母就 404。还有一些隐蔽的模型名要和启动时的--served-model-name一致否则调用端报 404多卡机器注意 CUDA_VISIBLE_DEVICES 别和别的进程抢卡vLLM 大版本之间参数名会变升级后需要重读一遍启动参数。八、和 Ollama 怎么分工我的结论是分两层开发机和个人验证用 Ollama五分钟跑起来真正要接业务、要并发、要标准化接口用 vLLM。两者模型权重可以共用同一份不存在二选一绑定。据多家技术社区对 Qwen 系列模型的复盘超过六成的开源决策类模型都基于 Qwen 系列后训练而来来源华尔街见闻对 Microsoft-Decision-1 的报道2026 年 10 月 12 日经公开资料交叉验证所以把 Qwen3 的部署流程跑通复用价值比单看一个模型更高。九、辩证看待vLLM 不是银弹说它好不代表它适合所有场景。vLLM 启动比 Ollama 慢权重加载和 KV 缓存预热要等一会它把显存近乎锁死一台机器同一时刻基本只服务这一个模型不适合和训练、微调抢同一张卡。如果是纯 CPU 环境、或者只是偶尔跑一下小模型Ollama 反而更省事。另一个容易忽视的点高吞吐来自连续批处理前提是请求真的在“并发”进来。要是你的业务本来就是串行单路vLLM 相比 Ollama 的体验提升有限这时为了上 vLLM 多维护一套环境性价比未必划算。选型这件事永远先看流量形状再看工具参数。互动提问你现在的推理服务是 vLLM、Ollama 还是别的方案遇到的瓶颈在哪8B 这个量级在你业务里够用还是需要上 32B 甚至更大你压测时首字延迟和吞吐一般卡在哪个参数上欢迎在评论区聊聊你的部署实践和踩过的坑。数据与事件来源参考来源vLLM 官方文档PagedAttention、continuous batching、benchmark 参数2026 年 10 月复查。参考来源Qwen3 模型卡ModelScope 与 Hugging Face2026 年 10 月复查。参考来源华尔街见闻《微软新决策模型底座是阿里 Qwen》2026 年 10 月 12 日经公开资料交叉验证。