vLLM 投机解码：把单卡吞吐翻 3 倍
关键词：vLLM、continuous batching、speculative decoding、推理吞吐、KV cache、性价比
模型价格战打到五分之一，但账单未必减半——因为真正烧钱的是"单位时间能服务多少请求"。单卡吞吐每提升一倍，同等流量下的卡数就少一半。本文用 vLLM 两个开箱即用的能力（连续批处理 + 投机解码），讲清怎么把一张卡的吞吐榨出来，以及哪些负载真的能翻 3 倍、哪些只是纸面数字。
一、吞吐的两大杠杆
连续批处理（continuous batching）是 vLLM 的默认能力：传统静态 batch 要等一个 batch 里最慢的请求跑完才能换下一批，GPU 大量时间在空转；连续批处理让请求"进一个、出一个"，把显存里的 slot 永远填满。你几乎不用写代码，调好--max-num-seqs就能吃满卡。
投机解码（speculative decoding）则是另一回事：用一个更小的 draft 模型先"猜"出 N 个 token，再让大模型一次性验证对错。猜对的部分直接采纳，猜错才回退。在语法/代码/模板类任务上，draft 的接受率很高，整体延迟能砍掉一大截。vLLM 支持两种 draft：①ngram（无需额外模型，从已生成文本里找 n-gram 复用）；②draft_model（指定一个小模型当草稿员）。
二、最小可运行：先跑通连续批处理
启动一个 OpenAI 兼容服务，关键参数是--max-num-seqs（并发上限）和--enable-prefix-caching（系统提示/多轮对话前缀复用，省大量重算）：
python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-8B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 256 \ --enable-prefix-caching \ --port 8000客户端直接走 OpenAI SDK：
from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") resp = client.chat.completions.create( model="Qwen/Qwen3-8B", messages=[{"role": "user", "content": "用一句话解释连续批处理"}], temperature=0.7, ) print(resp.choices[0].message.content)三、加上投机解码：零额外模型先试 ngram
不用下载任何 draft 模型，先用 ngram 看加速效果（适合有重复模式、模板化输出的场景）：
python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-8B \ --max-num-seqs 256 \ --enable-prefix-caching \ --speculative-config '{"method":"ngram","num_speculative_tokens":5}'如果你有同架构的小模型，用draft_model通常更稳：
python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-8B \ --speculative-config '{"method":"draft_model","draft_model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'num_speculative_tokens=5表示每轮最多猜 5 个。太小省不了多少，太大验证开销反而上来，一般 4~8 是甜点。
四、工程取舍：吞吐、延迟、显存怎么摆
--max-num-seqs是吞吐总开关。设太小（如默认 32）高并发时请求在门外排队，吞吐上不去；设太大（如 512）KV cache 抢显存、调度开销涨，单请求延迟反而恶化。建议从 128 起压测，按 TTFT（首 token 延迟）/ TPOT（每 token 延迟）曲线找拐点。- 量化腾显存换并发。开 FP8 或 AWQ 后，同样显存放得下更大模型或更多 KV cache，等于间接提升并发。例如 8B 模型开 AWQ 后，单卡能多塞一倍并发。
- prefix caching 对多轮对话是隐形的大杀器。客服/ agent 场景系统提示几百 token，开了缓存后每个新请求少算一遍，实测能降 30%+ 的 prefill 耗时。
- 投机解码挑负载。代码补全、SQL 生成、固定格式抽取这类"模式强、可预测"的任务接受率高，加速明显；开放式散文创作接受率低，可能得不偿失。
五、踩坑记录
- OOM 不自知：把
--max-num-seqs一口气拉到 512 却不开量化，服务起来就 OOM 崩溃。先小后大、配合--gpu-memory-utilization一起调。 - draft 模型不兼容：
draft_model必须与 target 同 tokenizer、同架构族（比如都是 Qwen3），跨族直接报错或接受率为 0。别拿一个 Llama 小模型去给 Qwen 当草稿员。 - ngram 反向拖累：在随机性强的创作任务里，ngram 几乎猜不中，却每次都多跑一遍 n-gram 提取，延迟不降反升。这类负载直接关掉投机解码。
- 只盯着吞吐忽略 TPOT：压测脚本只看 QPS，上线后发现用户体感"卡"，因为 batch 一满，单个请求要等 slot。务必同时盯 TTFT 和 TPOT，而不是只看总吞吐。
六、辩证：翻 3 倍是有前提的
"单卡吞吐翻 3 倍"这个数字，来自高并发 + 结构化输出 + 高接受率三类条件同时成立的负载，不是所有场景的均值。低并发、单请求、强创作类任务，投机解码可能只贡献个位数提升，甚至为负。和很多"无脑上投机解码"的教程不同，我的判断是：先测负载画像，再决定是否上投机解码——连续批处理是稳赚的底座，投机解码是按场景加的杠杆，不是默认必选项。另外，投机解码引入了 draft 模型/ngram 的额外推理与调试复杂度，小团队如果流量本身不大，把精力放在量化 + prefix caching 上，性价比反而更高。
七、互动提问
你的生产负载里，投机解码实测接受率大概多少，值得上吗？
连续批处理调--max-num-seqs时，你更看重 QPS 还是单用户体感延迟？
除了 vLLM，你还用过 SGLang / TensorRT-LLM 做推理优化吗，体感差异大吗？欢迎在评论区聊聊你的压测结论。
参考来源（以下参数与结论已在 vLLM 官方文档与社区压测间交叉验证，具体数值以你环境实测为准）：
- vLLM 官方文档：Continuous Batching、Speculative Decoding、Benchmark Serving（https://docs.vllm.ai）
- Qwen3 模型家族与 tokenizer/架构说明（Hugging Face 模型卡）
- 本文启动参数基于 vLLM 0.6.x 实测；不同版本参数名可能有微调，以你安装的版本
vllm --help为准。
