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 SDKfrom openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelQwen/Qwen3-8B, messages[{role: user, content: 用一句话解释连续批处理}], temperature0.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_tokens5表示每轮最多猜 5 个。太小省不了多少太大验证开销反而上来一般 4~8 是甜点。四、工程取舍吞吐、延迟、显存怎么摆--max-num-seqs是吞吐总开关。设太小如默认 32高并发时请求在门外排队吞吐上不去设太大如 512KV 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 Servinghttps://docs.vllm.aiQwen3 模型家族与 tokenizer/架构说明Hugging Face 模型卡本文启动参数基于 vLLM 0.6.x 实测不同版本参数名可能有微调以你安装的版本vllm --help为准。