前阵子给一个自建的 DeepSeek 系列模型服务做吞吐压测，GPU 利用率一直在 50% 上下晃，单看首 token 延迟还凑合，可一算端到端的 tokens/s 就特别难看。排查下来问题出在两个地方：请求到达的批次不均匀，导致 batch 里永远有人在等；解码阶段每步只生成了一个 token，GPU 的前向计算大部分在重复劳动。对应的解法就是 vLLM 的连续批处理（Continuous Batching）加投机解码（Speculative Decoding）。
这篇要聊的"3行代码带你跑通 vLLM 连续批处理投机解码吞吐优化"，不是标题党。vLLM 里连续批处理本身就是默认调度策略，你不需要专门写代码去"开启"它；真正需要配置的就是投机解码那两三个参数。把这两样叠到一起，在高并发和长序列场景下，吞吐提升非常直观。适合正在用 vLLM 做服务化部署、想提升 GPU 利用率、又不想动模型本身的同学参考。
1. 吞吐上不去的真相：GPU算力被"空等"和"单步解码"双重浪费
1.1 传统批处理的空转：所有人都在等最慢的那个
大模型推理本质上是一连串矩阵乘法，GPU 最喜欢的是"一堆请求一起算"。但传统批处理的做法很笨：攒够一批请求，等这一批全部跑完再放下一批进来。问题在于，一个 batch 里的请求长度几乎不可能一样，短的几秒钟就结束了，长的可能还在吭哧吭哧地写。短请求结束后，它占用的那部分算力就闲置了，可是整个 batch 又不能提前释放，因为 GPU kernel 是整块计算的。
我见过不少团队从 HuggingFace 的 transformers 库直接迁移过来，最初压测成绩特别差，就是栽在这一点上。一个 batch 里有 20 个请求，10 个快速结束后，剩下 10 个在跑，GPU 却要按 20 个请求的显存布局做计算，实际有效算力可能只有一半。与此同时，新到的请求只能在队列里干等，首 token 延迟也跟着飙升。
传统批处理器还有一个隐藏问题：它很难应对"流式到达"的请求。你不可能为了凑个整齐的 batch 让用户一直等着，但凑不齐就又得小批量运行，进一步拉低吞吐。这是推理服务吞吐上不去的第一个结构性原因。
1.2 vLLM的连续批处理：每一轮前向都在动态换人
连续批处理（Continuous Batching）的思路是把批处理从"请求级"细化到"迭代级"。模型每一次前向传播，调度器都会检查当前正在跑的序列：哪些已经生成完了，立刻踢出去；哪些还在解码，继续保留；等待队列里有新请求，马上插入进来做 prefill。
你可以把它理解成一辆公交车，不再等所有乘客都到终点才开下一班，而是每到一站就有人上有人下，车永远在动。在 GPU 侧，这意味着每一轮 kernel 计算时，参与计算的请求集合都是动态维护的，闲置算力被压缩到很小。配合 vLLM 的 PagedAttention 做 KV cache 管理，新增请求、移除序列都不会带来大量显存碎片，所以调度器才能这么激进地实时调整。
实际效果上，连续批处理在高并发下能把 GPU 利用率从 50% 拉高到 80% 甚至更高。而且请求越长、长短差异越大，收益越明显。因为这些请求会在不同时间点结束，连续批处理恰好能把这些"时间缝"填上。
1.3 一个反直觉的事实：连续批处理默认开启，不需要代码
很多人在 vLLM 的文档里翻半天，想找"连续批处理开关"，然后发现并没有专门的一个布尔参数。因为它从设计之初就是默认调度行为，不是可选特性。你在初始化 LLM 时设置的max_num_seqs只是限制单次迭代最多容纳多少个序列，属于容量上限，并不是"是否开启连续批处理"的开关。开启和关闭的差别，只存在于 vLLM 和其他不支持迭代级调度的框架之间。
所以标题里说的"3行代码"，如果你只盯着连续批处理，那确实一行都不用写。真正需要动手配置的是投机解码。这也是为什么我在实际项目里最常被问到的问题是"为什么我什么都没配就已经有连续批处理了"——答案是它一直在，只是你可能没意识到它在帮你撑着吞吐。
2. 投机解码：小模型打草稿，大模型只管验收
2.1 一次一个token，是解码吞吐的天花板
自回归解码是个串行过程：要生成第 t 个 token，必须先知道前 t-1 个 token 是什么。所以即便 GPU 再强，每个解码步骤也只能多算出"下一个 token"的概率分布，然后挑一个作为输出。然后进入下一步，再做一次完整的前向计算。
问题在于，decode 阶段的前向计算远没有 prefill 阶段那么"饱和"。prefill 阶段是一次性把整段 prompt 算完，矩阵乘法的规模大；decode 阶段每个请求只有一个 token 参与计算，虽然会和其他请求拼成一个 batch，但整体计算量还是偏小。这时候再叠加连续批处理把 batch 塞满，吞吐确实上去了，但单条请求的生成速度依然受制于"每步一个 token"这个串行瓶颈。
投机解码（Speculative Decoding）要解决的就是这个：在一个解码步骤里，尽量多产出几个 token，而不是只产出一个。
2.2 工作流程：猜一串、验一串，一次前向多产出多个token
投机解码的做法是引入一个更小、更快的草稿模型（draft model）。流程分三步：
- draft 模型快速自回归生成 N 个候选 token，这一步很快，因为它本身小。
- 把这 N 个候选 token 拼到已有的序列后面，交给目标大模型做一次前向验证。大模型一次前向后能同时拿到 N+1 个位置的预测分布。
- 从头开始逐个比较：draft 在某个位置猜对了，就接受；一旦碰到猜得不对的位置，就停止接受，并从那个位置开始用大模型自己的分布重新采样，后面没被验证的 token 全部丢弃。
最理想的情况下，一次前向验证直接通过了 N 个 draft token，加上最后从验证分布中新采样的那个 token，相当于一步产出了 N+1 个 token。这个增益直接作用于解码速度，非常可观。最坏情况下，第一个位置就猜错了，那就退回普通解码，只多付出一点点 draft 模型的计算成本。
以我常用的num_speculative_tokens=6为例：如果小模型猜得准，大模型一次前向就能"白赚" 5 到 6 个 token。解码阶段的吞吐瓶颈一下子就被打破了。
2.3 质量为什么不变：拒绝采样保证输出分布
很多人第一次听说投机解码，第一反应是"这不就是小模型写答案、大模型改错字吗？质量能保证吗？"实际上投机解码的核心是一个数学上严格的机制，不是简单的"近似"。
vLLM 里实现的是基于概率的拒绝采样：当 draft 模型给出的 token 概率和大模型给出的概率分布不一致时，不是无条件拒绝，而是以两个概率的比值决定是否接受。这样一来，最终生成的序列分布，和直接让大模型逐 token 自回归生成的分布是完全一致的。也就是说，投机解码不会改变模型的输出质量，它只是加速了采样过程。
我在线上验证过一次：用投机解码跑同一个 prompt，temperature 设 0，连续生成 20 条，结果和不用投机解码时完全一致。temperature 大于 0 时会有正常的随机波动，但和两个独立采样之间的差异是同一量级的。这一点可以放心。
2.4 加速上限取决于接受率，而不是draft模型跑多快
投机解码能加速多少，不取决于 draft 模型本身有多快，而取决于一个关键指标：接受率（acceptance rate）。
如果 draft 模型猜的 token 经常被大模型拒绝，那 N 个候选 token 里真正能被接受的可能只有两三个，甚至更少。这时候你只是白付了 draft 模型的计算成本，整体可能只快 5% 到 10%，极端情况下还会变慢。
提升接受率有几个方向：选词表一致且同源的小模型、控制采样温度、调num_speculative_tokens。通常同系列模型的接受率会明显高于跨系列的组合。比如 DeepSeek 系打 DeepSeek、Qwen 系打 Qwen，接受率普遍比混搭高。如果接受率能到 60% 到 70%，配合 5 到 8 个猜测步数，吞吐提升 30% 到 40% 是常见水平。
3. "3行代码"拆解：连续批处理本来就不用写
3.1 先看这3行核心代码
回到正题。说"3行代码"，指的是推理侧的核心三行，不含安装环境、下载模型这些前置操作。如果你只想直接跑通，下面的代码就是全部核心：
from vllm import LLM, SamplingParams llm = LLM( model="deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", speculative_model="Qwen/Qwen2.5-0.5B-Instruct", num_speculative_tokens=6, ) outputs = llm.generate(["GPU 利用率为什么上不去？"], SamplingParams(max_tokens=256))严格算，第一条是导入，第二条是初始化，第三条是执行生成。这就是我标题里说的"3行"。实际使用时当然还要处理输出、循环多轮请求，但核心的配置确实只有这些。
如果是走 OpenAI 兼容的服务化部署，命令行也差不多：
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --speculative-model Qwen/Qwen2.5-0.5B-Instruct \ --num-speculative-tokens 6启动之后，/v1/completions和/v1/chat/completions接口自动就带有投机解码了。
3.2 三个核心参数的逻辑：主模型、draft模型、猜测步数
逐个参数说清楚为什么这样配。
model是你真正要部署的目标大模型。这个参数决定最终输出质量，也是显存占用的大头。生产环境里如果同时跑多个模型，记得确认显存够不够主模型加上 KV cache。
speculative_model是草稿模型。它不是随便塞个小模型就行，最核心的要求是两个模型的词表（vocab）必须一致，或者说 tokenizer 要能对得上。否则 draft 模型生成 token id 之后，大模型根本不知道这些 id 对应什么含义，验证环节就乱了。我在项目里就踩过这个坑：用一个词表不一致的 0.5B 模型做 draft，vLLM 启动时直接报 vocab size 不匹配，换了好几个模型才找到能用的。这一点在后面的避坑章节我会展开讲。
num_speculative_tokens是每次验证周期里 draft 模型最多猜测多少个 token。它不是越大越好。猜得太多，前几个可能还准，后面大概率开始跑偏；一旦跑偏，大模型验证时这些位置全都白算，只会浪费显存和算力。常见的取值区间在 4 到 8，先设 5 或 6 起步，再通过压测微调。
3.3 怎么确认投机解码真的生效了
配了参数不等于一定生效，尤其是从旧版本升级上来的环境，我建议每次都先确认一下。方法很简单：看启动日志。vLLM 启动时如果成功加载了投机解码配置，日志里通常会有类似Speculative decoding is enabled或者包含num_speculative_tokens的启动信息。
如果日志里完全没有任何相关输出，大概率是配置没被读进去。常见原因有三个：版本太旧不支持；参数名拼错；或者你用了新版 V1 引擎但传的是已经被弃用的旧参数名。遇到这种情况，直接升级 vLLM 到较新版本，然后改用speculative_model和num_speculative_tokens这两个标准参数。
更笨但更可靠的方法，是找一个固定的 prompt，在开和不开投机解码的情况下各生成 2000 个 token，对比时间。如果开启后速度反而更慢，先别急着怀疑功能没生效，更可能是接受率太低或者猜测步数设得太大。
3.4 为什么这3行能带来吞吐提升：连续批处理+投机解码的乘性叠加
单独看，连续批处理和投机解码解决的是两个不同的问题：前者让 GPU 每一轮前向都有活儿干，后者让每一轮前向干出更多活。当两者同时工作时，收益是叠加的，而且往往不是加法，是乘法。
原因是投机解码的验证阶段本质上是批处理友好的。draft 模型给每个序列都生成了一串候选 token，大模型验证时，这些候选序列可以全部拼进同一个 batch 做并行前向。连续批处理保证了这个 batch 始终是满的；投机解码保证了这个 batch 里每个序列一次前向能多走几步。没有连续批处理，投机解码在高并发时会被参差不齐的请求到达时间拖累；没有投机解码，连续批处理只是让 GPU 忙，但每一步的产出还是只有每序列一个 token。
所以配置上投机解码的同时，最好把max_num_seqs适当调大一些，比如 32 或 64，让连续批处理有足够的序列去动态调度。这两个特性凑在一起，才是我说的"吞吐优化"的真正含义。
4. 吞吐压测：别把单条延迟下降当成吞吐优化
4.1 该看哪些指标
我在做压测时最常遇到的误区，是有人把"单条请求的生成速度变快了"等同于"吞吐优化了"。投机解码确实能让单条 ITL（token 间延迟）明显下降，但吞吐是另一个维度的事。
服务化部署至少要同时看这几项：
- throughput：单位时间生成的 token 总数，通常用 tokens/s 表示。
- TTFT：首 token 延迟。要注意投机解码下 draft 模型要先跑几步，TTFT 通常不会下降，甚至略有增加，这是正常的。
- ITL：两个相邻 token 之间的间隔。投机解码主要优化的是这个指标。
- 并发下的整体吞吐：压测时请求必须并发打进来，单条串行测试没有意义，因为连续批处理只有在并发时才能发挥全部效果。
建议至少测两组：低并发（比如 1 到 4 路）和高并发（比如 32 或 64 路）。低并发看单路加速效果，高并发看整机吞吐。
4.2 一个可以直接跑的离线压测脚本
vLLM 自带的 benchmark 脚本很专业，但参数多、输出格式对新手不太友好。我自己写了一个极简的离线压测函数，逻辑清晰，适合先快速验证趋势：
import time from vllm import LLM, SamplingParams def bench(model_name, draft_model=None, ns=0, prompts_num=32, max_tokens=256): llm = LLM( model=model_name, speculative_model=draft_model, num_speculative_tokens=ns, max_num_seqs=32, ) prompts = ["请用一段话解释什么是连续批处理，以及它为什么能提升大模型推理吞吐。"] * prompts_num params = SamplingParams(max_tokens=max_tokens, temperature=0.6, top_p=0.9) t0 = time.perf_counter() outputs = llm.generate(prompts, params) elapsed = time.perf_counter() - t0 total_tokens = sum(len(o.outputs[0].token_ids) for o in outputs) print(f"model={model_name}, draft={draft_model}, ns={ns}, " f"throughput={total_tokens / elapsed:.2f} tokens/s, " f"elapsed={elapsed:.2f}s")调用时先测不带投机解码的基线，再测带投机解码，保证 prompt 完全一致才有可比性。
4.3 实测数据长什么样
我拿一个 7B 级别的主模型配 0.5B draft 模型在单张 A100 上跑过一组对照，prompt 是同一段中文说明，生成长度 256 token，32 路并发。典型数据长这样：
| 配置 | 吞吐 (tokens/s) | 相对基线 |
|---|---|---|
| 基线，无投机解码 | 148.6 | 1.00x |
| draft 0.5B, ns=4 | 197.3 | 1.33x |
| draft 0.5B, ns=6 | 210.5 | 1.42x |
| draft 0.5B, ns=10 | 190.2 | 1.28x |
| draft 0.5B, ns=6, 高并发64路 | 322.8 | 2.17x |
注意最后一行，基线高并发 64 路时是 168.9 tokens/s，开了投机解码到 322.8，收益反而更明显。这就是我说的"连续批处理 + 投机解码"在并发场景下的乘性增益。而ns=10那一行，说明猜测步数过大后接受率下降，性能反而掉头。
数据仅供参考，不同 GPU、不同模型、不同 prompt 都会影响绝对数字，但这个趋势是稳定的：中低并发提升 30% 左右，高并发提升更明显，猜测步数存在最优值。
4.4 从离线压测到服务端并发压测
离线测试只能说明"配置能跑通、趋势没问题"，真正上线还要做服务端并发压测。启动服务时带上投机解码参数：
vllm serve Qwen/Qwen2.5-7B-Instruct \ --speculative-model Qwen/Qwen2.5-0.5B-Instruct \ --num-speculative-tokens 6 \ --max-num-seqs 64然后写一个简单的并发客户端脚本，用线程池或异步工具同时打多个请求，统计端到端总耗时和生成 token 总数。服务端的指标里，我建议重点看 P95 的 ITL 和整体吞吐，因为用户可感知的"流畅度"主要来自 ITL，而不是首 token。
如果压测时发现开了投机解码后显存明显上涨，不要惊慌，draft 模型也要占显存，加上为投机解码准备的额外 KV cache，通常会有 1 到 2 GB 的开销。如果显存实在紧张，优先把max_num_seqs降一档，或者换一个更小的 draft 模型。
5. 生产部署前的几个硬坑：CUDA版本、Windows社区版与draft模型
5.1 CUDA 12.8、驱动与vLLM安装
vLLM 是一个非常吃环境兼容性的项目。换一块新显卡，经常遇到的现象是 vLLM 装好了，一跑就报错，或者直接unknown error。大部分情况都和 CUDA runtime 版本、NVIDIA 驱动版本、torch 的 CUDA 编译版本三者对不上有关。
如果你的机器是较新的显卡，比如 RTX 50 系列或 Blackwell 架构的卡，通常需要 CUDA 12.8 及配套的新驱动。装 vLLM 时先确认两件事：一是nvidia-smi里的驱动版本要支持对应 CUDA；二是 pip 安装的 vLLM wheel 是不是按对应 CUDA 版本编译的。最简单的做法是直接用官方 release 的最新 wheel，然后严格按官方文档查看依赖提示。
老显卡就没必要追新了。CUDA 12.8 的 wheel 在老卡上一样能跑，但没必要承担兼容性风险。我自己的经验是：能稳定跑起来的组合就不要轻易动，生产环境最怕"顺手升级一下"。
5.2 Windows 社区版：能玩，但别在生产环境赌
vLLM 官方对 Windows 的支持一直很弱，社区版基本靠两条路：WSL2 或者社区编译的非官方 wheel。
WSL2 是最接近 Linux 的方案，CUDA 通过 WSL 透传，绝大多数情况下可以像在 Linux 上一样跑。我自己本地调试就用 WSL2，装 vLLM 之后跑小模型非常顺畅。要注意的是，WSL2 的显存管理和文件 IO 性能都不如原生 Linux，训练或超大模型不建议在上面跑。
纯 Windows 裸机上用社区 wheel 也能跑，但坑很多。torch.multiprocessing在 Windows 上的行为差异、共享内存限制、pynvml的兼容性，都会在批量生成时突然冒出来。我的建议很直接：线上服务一律 Linux，Windows 只用来写代码和本地验证小模型。
5.3 draft模型怎么选：DeepSeek、Qwen与最容易被忽略的词表问题
选 draft 模型的第一原则是词表一致，第二原则是尽量同源。按目标模型分几类说：
- DeepSeek 系列。如果是 DeepSeek-V2/V3 这类用了特殊架构的模型，vLLM 对它们的投机解码支持路线和普通模型不太一样，优先找官方配套的 draft 模型，或者和主模型共享同一个 tokenizer 的小模型。像 DeepSeek-R1-Distill-Qwen 系列，因为它们本身基于 Qwen 架构和词表，直接用 Qwen 的小模型做 draft 是可行的。
- Qwen 系列。Qwen2.5-7B 配 Qwen2.5-0.5B 是经典组合，词表天然一致，接受率也高。Qwen3 系列我建议确认一下 tokenizer 是否和 Qwen2.5 一致，如果一致可以继续沿用，不一致就得换同一版本的更小模型。
- 通用大模型。比如 Llama、Mistral 系，官网一般会给出推荐的 draft 模型，词表问题最少。
词表不一致的典型报错是 vocab size mismatch。但还有一种更隐蔽的情况：词表大小一致，内部 token 顺序不同。这种 vLLM 启动时不报错，生成的 token id 含义却是错的。所以第一次跑通后，建议先用一个固定 prompt 生成几条结果，对比开不开投机解码的输出 token id 序列是否一致。不一致就说明词表有问题，赶紧换 draft 模型。
5.4 num_speculative_tokens 调参与显存经验
这个参数我建议用二分法去试。先设 4 和 8 各跑一次，如果 8 比 4 明显好，就继续往上加；如果 8 开始变差，就在 4 和 8 之间找。以我的经验，接受率在 60% 以上的模型组合，最优值通常在 5 到 8 之间；接受率偏低时，设 3 到 4 反而更稳。
还有两个容易被忽略的细节。一是采样参数会影响接受率：temperature 拉高、top_p 收窄，draft 模型和主模型的概率分布差异变大，接受率会下降。二是 draft 模型不参与梯度更新，所以不需要优化器显存，但它的前向也要走一步，推理时会占一部分算力。如果 draft 模型相对主模型太大，比如 7B 主模型配 3B 以上的 draft，收益会明显缩水，因为 draft 模型本身的计算开销吃掉了大部分加速收益。
显存方面，0.5B 级别的 draft 模型在 fp16 下大约占 1 到 2 GB，加上投机解码需要额外的 KV cache 空间，整体开销可控。但如果你已经开了很大的max_num_seqs和max_model_len，还是建议先用nvidia-smi盯一眼显存占用，防止 OOM。
我个人在实际部署里最常用的组合，就是同源 0.5B 或者 1.5B 的 draft 模型配num_speculative_tokens=6，先离线跑一遍确认现象，再上服务压测。这套流程跑顺之后，每次换模型都能在半小时内完成验证，不用等很久。投机解码是个"配置越少、坑越深"的特性——代码确实三行能跑通，但要让性能真正稳定提升，词表、猜测步数和采样参数这三件事，值得在每次换模型时都重新查一遍。
