其实，把开源大模型跑成一个能扛并发的线上推理服务，远比“能对话”难得多。很多人本地用 Ollama 拉个 Qwen3 就能聊天，可一旦要把它接到业务里、撑住几十路并发、还要和 OpenAI 的接口一致，Ollama 就不够看了。我这次直接用 vLLM 把 Qwen3 部署成一个标准 OpenAI 兼容推理服务，从环境、启动、调用到压测，把每一步能复制的命令和踩过的坑都记下来。
一、为什么选 vLLM 而不是 Ollama
Ollama 胜在上手快，但它本质是单用户、单会话的本地工具，没有连续批处理（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-c"import 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.9，OOM 就往下调。--max-model-len：上下文长度，设太大显存会爆，按业务实际需要砍。--enable-prefix-caching：相同前缀的 prompt 复用 KV，多轮对话省算力。--max-num-seqs：并发序列数上限，调吞吐的旋钮。
启动后访问http://<机器IP>:8000/docs能看到 OpenAI 兼容的接口文档。
四、用 OpenAI SDK 调用
因为接口兼容 OpenAI，业务代码几乎零改动，只改 base_url：
fromopenaiimportOpenAI client=OpenAI(base_url="http://localhost:8000/v1",api_key="EMPTY",# vLLM 本地服务不校验 key)resp=client.chat.completions.create(model="Qwen/Qwen3-8B-Instruct",messages=[{"role":"user","content":"用一句话解释什么是连续批处理"}],stream=True,)forchunkinresp:ifchunk.choices[0].delta.content:print(chunk.choices[0].delta.content,end="")也可以直接用 curl 测通断：
curlhttp://localhost:8000/v1/chat/completions\-H"Content-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 Face），2026 年 10 月复查。
参考来源：华尔街见闻《微软新决策模型底座是阿里 Qwen》，2026 年 10 月 12 日，经公开资料交叉验证。
