大模型推理提速300%：推测解码原理与生产落地指南

只要部署过大模型推理服务的人，一说起“慢”这个字，八成都有点条件反射。用户那边发来一句话，服务端吭哧半天才吐出第一个字，后面虽然流畅些，也跟老式打字机似的，一个token一个token地往外蹦。我在某数据业务项目里维护过一个十几B参数规模的对话模型，第一批功能上线不到一周，业务方的反馈就很直接：这聊天体验不行，一句话平均要等两三秒才出来。后来我花了一段时间把推测解码（Speculative Decoding）搬上生产环境，端到端吞吐提了两倍多，长输出场景下甚至接近三倍——也就是标题里说的那个300%。这篇文章就把这套方案的原理和落地过程展开聊一聊，重点是哪些环节容易踩坑、为什么有的机器上提速不明显、以及怎么一步步调到理想的加速比。

1. 为什么大模型推理这么慢：自回归解码的宿命

1.1 大模型天生只能一个token一个token地生成

想理解推测解码，先得搞清楚常规的大模型推理为什么慢。很多人都知道大模型是“逐字生成”的，但这个逐字到底有多严格，可能没细想过。

Transformer架构的大模型，本质上是一个自回归模型（autoregressive model）。它的意思是：模型在生成第n个token时，必须把前n-1个token全部作为输入，然后预测下一个token是什么；生成完第n个token之后，再把它拼到输入里，去预测第n+1个token。整个过程中没有任何“并行吐字”的可能，因为后面的每一个字都严格依赖前面已经生成的字。

拿“今天天气真好”这句话来说，模型的实际生成路径是：

• 输入“开始符”，预测出“今”
• 输入“开始符、今”，预测出“天”
• 输入“开始符、今天”，预测出“天”（第二个天）
• 输入“开始符、今天天”，预测出“气”
• ……一路串行下去

一个7B参数的模型，在消费级GPU上大概每秒能生成20到40个token；哪怕放在更高级的GPU上，单用户场景通常也就是一秒钟几十个token。用户感知就是“卡”，尤其流式输出的时候，如果每秒只有十几个token，体验几乎没法看。人读中文大约每秒5到8个字，但大模型输出的字速往往比这个还慢，用户等得不耐烦是非常正常的。

1.2 真正的瓶颈不是算力，而是显存带宽

很多人一开始以为大模型慢是因为“计算量太大”，这个印象需要纠正。在生成阶段（decode阶段），大模型真正的时间开销大头不是计算，而是“从显存里读权重”。

拿7B模型举例。70亿参数，按FP16精度算，每个参数占2字节，那么全部权重大约是14GB。生成一个token，理论上需要的计算量大概是2 × 参数量 × token数，也就是大约14 GFLOPs。这个计算量对GPU来说真的不算什么，一张普通的GPU轻松可以跑出几TFLOPs甚至几十TFLOPs的算力。

真正的问题在于：你每生成一个token，都需要把这14GB权重从显存里完整读一遍，算完得到一个小结果，然后再读下一遍。显存的读取带宽是几百GB/s到几TB/s，14GB读一次就需要几十毫秒。于是整个生成过程的时间，几乎全耗在“搬运权重”上了，计算单元反而是闲着的。

业界管这种状态叫“访存受限”（memory-bound）。打个比方：仓库里有一堆14吨的货，你的任务是一次只挑出一件很小的小零件（一个token的计算量），但每次都必须把整堆14吨货先从仓库搬出来，看完再搬回去。装货卸货的时间远远大于挑零件的时间，效率当然低。

想通这一点，就明白为什么单纯堆算力解决不了单用户延迟问题。你必须想办法减少“每生成一个token就读取一次全部权重”的次数，这才是加速的关键。

1.3 提高吞吐和降低单条延迟，是两码事

顺带说一个很容易混淆的概念：吞吐（throughput）和单用户延迟（latency）不是一回事。

很多团队喜欢用增大batch size的方式提高吞吐，同一时间处理更多请求。这个做法是有效的，GPU利用率上去了，整体吞吐数据也好看。但单个用户拿到第一个token的时间、以及后续每个token之间的间隔（ITL，inter-token latency），并不会因为并发变高而变快。反而批太大时，单个请求在GPU队列里等的时间更长，用户感知可能更差。

推测解码解决的是另一个层面的问题：它让“多生成几个token”在一次模型前向里完成，直接降低每个token的平均成本和延迟，这才是用户能真正感知到的“快”。

2. 推测解码的核心思想：小模型打草稿，大模型做终审

2.1 一个很朴素的灵感

既然目标模型每生成一个token都要读一遍权重，那我们能不能让它“一次多验证几个token”？

常规自回归做不到，因为你不知道接下来的token是什么。但如果先找一个小模型，快速猜一串token出来，再让大模型一次性“审批”这串token呢？

这就是推测解码（Speculative Decoding）的核心思路：用一个又小又快的草稿模型（draft model）先生成一段候选序列，比如6个token，然后目标模型把这整个序列一次性读进去，进行一次前向，同时算出每个位置的真实预测分布，再逐个判断“猜得对不对”。

猜对的部分直接采用，相当于一次前向白拿了几个token；猜错的地方，用目标模型给出的token顶上，然后丢弃后面所有候选，重新开启下一轮循环。

这个思路其实在早年有一些类似概念，但真正在LLM上落地并引起广泛关注，是这两年的事。它最优雅的地方在于：它不是“近似加速”，而是严格的数学等价——最终输出的概率分布和直接用目标模型逐token生成是完全一致的。

2.2 接受/拒绝机制：为什么输出分布不变

这一步很多人容易看迷糊，但它恰恰是推测解码的“立身之本”。

假设目标模型是q，草稿模型是p。草稿模型按自己的分布p，生成了候选token t1、t2、t3……，并且在每个位置也保留了p(token)的具体数值。目标模型做一次前向，在同样的位置得到了自己的分布q。接下来不是简单地问“草稿猜的是不是q里概率最大的那个”，而是按照“拒绝采样”（rejection sampling）的规则逐位置判断：

• 对第i个token，计算接受概率 r = min(1, q(t_i)/p(t_i))
• 以r的概率接受草稿token t_i，让它作为最终生成的token，然后继续检查下一个位置
• 如果被拒绝，则不能直接取q中概率最大的token，而是需要从修正后的分布 q'(x) ∝ max(0, q(x) - p(x)) 中采一个token作为当前输出，然后这之后的候选token全部作废，重新让草稿模型从当前位置继续猜

这个规则看起来有点绕，但它的意义非常明确：经过这样处理后的最终生成分布，和直接用目标模型q做原生采样，在数学上是严格一致的。

当年我第一次看到这个证明时也觉得神奇。其实可以反过来理解：拒绝采样的本质就是“当草稿分布和目标分布在某个token上不一致时，用目标分布修正结果”。草稿分布低估了目标分布中概率较高的token，这些token会被更大概率接受；草稿分布高估了的token，则会被拒绝并重新采样。两边一抵消，最终分布还是q。

如果用的是greedy解码（每次取argmax），规则更简单：目标模型在每个位置上算出的最高概率token如果正好等于草稿token，就接受；否则就停下来，把目标模型认为最可能的token作为真正输出。

所以完全不用担心“草稿模型猜错了导致生成质量变差”——因为每一步都有目标模型这个“终审裁判”，错的token会被拦下来，最终质量不打折扣。

2.3 为什么目标模型一次能同时验证多个token

这里需要展开一个关键点：为什么目标模型把草稿序列一次性吃进去，就能同时得到所有位置的输出分布？

核心在于Transformer的结构。训练阶段，模型本来就是一整个序列一起输入的，并在每个位置都输出下一个token的预测（这种训练方式叫teacher forcing）。推理时，如果你已经有一个完整的候选序列，同样可以直接把它作为输入送进去，走一次前向，得到序列中每个位置上的logits——这和训练时看到完整句子的结构是一样的。

一次前向里，虽然输入序列变长了，但真正省钱的地方在于：权重只需要从显存读一次，而不是七次。注意力部分虽然要多计算候选位置对应的注意力分数，但这些额外计算相比权重访存的开销要小得多。对比“用目标模型逐token生成6个token要跑6次前向”，一次前向验证6个token的开销大概只有1次前向的1.x倍，这就实现了加速。

可以把目标模型想象成一位有经验的审核员。逐token生成模式好比每提交一两个字就审一次，审完一个才能提交下一个；推测解码模式下，小模型先交上六七个字，审核员一次性批下来，大部分字直接通过，只有不合格的才返工重写。审核员的工作次数从七次变成一次，速度自然上去了。

2.4 加速比由什么决定

理论上，推测解码能带来的加速比主要取决于三个变量：

• 草稿模型的接受率（acceptance rate）：猜得越准，加速越明显
• 草稿长度（number of speculative tokens）：一次猜多少个，越长潜在收益越大，但太长时后半段命中率会严重下降，反而浪费计算
• 草稿模型的生成成本：草稿模型本身的耗时越小越好，如果草稿模型跑太慢，就把前面的收益全吃光了

理想情况下，如果目标模型一次前向耗时T，草稿模型生成γ个token耗时t，平均接受率为α，那么生成一个目标token的平均耗时大约就是 (T + t) / (γ·α + 修正项)。接受率越高、草稿越便宜，吞吐越高。这也是为什么实测中2-3倍加速很常见，但很少能到10倍——收益被接受率和草稿成本卡住了。

3. 生产环境落地：从选模型到调参的完整实操

3.1 草稿模型怎么选：词表一致是铁律

选草稿模型，我踩的第一个坑就是词表。

草稿模型需要和目标模型共享同一个tokenizer/词表（vocabulary），否则它猜出的token ID在目标模型那边根本对不上。你也许可以做一层ID映射，但映射之后概率分布大概率也对不上，接受率会惨不忍睹。

如果你用的是同一个基座的模型家族，通常可以直接用同词表的小参数版本作为草稿模型。比如目标模型是某个系列里7B规模的版本，那么同系列的0.5B到2B版本往往就是很好的草稿模型。我在某内部项目里用的就是某个基座模型套件里的小参数版，词表天然一致，部署成本最低。

如果没有同词表小模型，有两个选择：

1. 自己用目标模型的checkpoint在大量通用语料上蒸馏一个小草稿模型，强制让它训练成“最懂目标模型的小模型”
2. 在推理框架中开启无草稿模型的方案，比如用历史生成的文本作为候选（有的框架支持N-gram投机），但效果通常不如专门的小模型

还有一个容易被忽略的点：草稿模型虽然小，但它在批量场景下也占显存。如果目标模型已经把显存占得比较满，草稿模型可能会挤占KV Cache的空间，反而降低整体吞吐。第4章我会专门说这个矛盾。

3.2 部署配置实操：以主流的开源推理框架为例

目前主流开源推理框架里，vLLM和TensorRT-LLM都已支持推测解码。我这里以vLLM的实践为主，因为它在社区用得最广、配置也最直观，但思路是通用的。

假设你已经有目标模型路径（比如 /models/xxx-7B）和草稿模型（/models/xxx-1B），启用推测解码只需要在启动引擎时多做两件事：

• 指定草稿模型：draft_model=xxx-1B
• 指定投机长度：num_speculative_tokens=6，这个具体数值需要实测调优

一个我实际用过的启动命令大概长这样（具体版本可能有差异，仅供参考）：

python -m vllm.entrypoints.openai.api_server \ --model /models/xxx-7B \ --draft_model /models/xxx-1B \ --num_speculative_tokens 6 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --swap-space 0

注意，如果草稿模型和目标模型词表一致，部分推理框架可以在显存上做优化，两套模型的embedding表可以复用，显著降低显存压力。如果不一致，可能会退回做ID映射，性能会有折损。

另外，vLLM还支持“动态投机长度”配置（不同版本的叫法可能不同），思路是：根据当前接受的token个数动态调整下一次草稿长度。比如这次接受了5个，下一次就试试猜8个；这次只接受了1个，就缩减到3个。这样能避免固定长度在后半段盲目浪费计算。我自己的经验是，动态方案在混合长短输出的业务场景里通常比固定6-8个token更稳定。

3.3 实测数据与调参心得

我在某内部测试环境里做过一组对比，目标是7B模型，草稿是同基座1B模型，硬件是单张80GB显存的GPU，场景是单请求流式输出800token：

• 原生自回归解码：大约27 token/s，平均生成延迟约30s
• 固定投机长度6：大约61 token/s，吞吐提升约2.26倍
• 固定投机长度12：大约69 token/s，但接受率从0.62掉到0.38，部分请求延迟抖动变大
• 动态投机长度：平均70 token/s，P99延迟比固定长度更好

这里有个反直觉的点：投机长度不是越长越好。换成8到12个token时，模型后半段命中率下降，多余的前向计算变成了浪费，甚至可能比6个token更慢。所以“先试6、再试8、最后看P99”是我建议的调参路径。

temperature的影响也很关键。我把temperature从默认的0.7调高到1.0，接受率直接降了约15个百分点，整体加速比从2.2降到1.7左右；反过来用greedy解码（temperature=0）时，有些测试集上接受率能到0.7以上，加速比更接近3倍。

原因不难理解：温度越低，分布越集中，小草稿模型和大模型的概率分布更容易“想到一块儿去”；温度越高，采样随机性变大，小模型就很难猜中目标模型的随机选择。

所以在生产里，如果你的业务允许低温度（比如客服问答、结构化抽取），推测解码的收益会非常明显；如果必须用高温度做创意写作，收益会打折扣，但通常也还有1.5倍以上。

还要留意停止条件：不要因为推测解码就放松对stop strings和EOS token的判断。目标模型验证时如果发现草稿序列里包含了EOS，必须立刻停止整段生成，而不是继续往后猜。这块处理不好会出现“用户都看到结束符号了还在生成”的怪异表现。主流框架会在内部处理，但如果你自己是手写流水线，一定要单独加分支。

4. 常见问题与排查技巧实录

4.1 加速比达不到预期，先查接受率

这是我在生产中最常被问到的问题：“明明开了推测解码，为什么线上没快多少？”

第一步永远是看草稿token接受率。如果服务端能导出token级别的日志，或者推理框架提供了统计接口，把接受率拉出来：

• 接受率在0.5到0.6以上，通常收益明显
• 低于0.3，可能草稿模型选得不对，或者投机长度过长
• 接受率正常但加速不明显，可能是草稿模型本身延迟太高，或者和目标模型共享GPU导致互相抢占

我调试过一个案例，接受率有0.55，但端到端只快了1.2倍。最后定位到问题：草稿模型在CPU/GPU之间的数据传输开销太大，草稿每次生成要500ms。解决办法是换了一块能容纳下草稿模型的GPU，把草稿生成也放到GPU上，延迟从500ms降到40ms，整体加速立刻来到2倍以上。这个经验说明：草稿模型“快”不只是参数量小，执行延迟本身也要压下来。

4.2 显存不够：草稿模型和KV Cache打架怎么办

前面说过，草稿模型也占显存，而KV Cache又要占显存，两者天然冲突。

实际生产中，尤其当目标模型规模比较大（比如70B量级），批次又比较高时，显存非常紧张。这时候有几个出路：

1. 把草稿模型压缩到极致。选更小的参数版本，甚至直接量化（如INT8、INT4）。草稿模型的精度对接受率影响很小，因为它只负责猜候选，真正的输出校准靠目标模型兜底，所以量化草稿模型是一个几乎无损的操作
2. 降低max-model-len或gpu-memory-utilization，给草稿模型留出空间
3. 如果服务是多副本部署，可以让部分副本开推测解码、部分副本不开，按请求类型路由——长输出请求走加速副本，短请求走原生副本，显存利用率最合理

我自己的偏好是优先量化草稿模型。比如1B模型量化后大约0.5到0.8GB显存，通常在可控范围内。

4.3 输出很短时没有收益：别硬上

推测解码的收益来自“一次前向级联多个token”。如果你的典型请求只输出几个token（比如标题生成、短分类），草稿模型还没猜够候选，目标模型就要停了，加速比很难体现，甚至可能更慢。

这种情况下我的建议是不要硬上推测解码。你可以用规则或者小模型先把第一批候选做出来，或者干脆保持原生解码；只有当输出长度较长（比如几十到几百token）的业务场景，才值得引入推测解码。

判断标准很粗暴：输出长度大于5到10倍的投机长度，收益才有可能显现。

4.4 大批次在线推理还会遇到什么坑

最后说一个容易被忽略的点：使用动态批处理（continuous batching）的框架时，一个batch里可能有多个请求都在被推测解码加速，这时候调度器需要让它们执行“验证步骤”时对齐、互相等待，处理不好会拖慢整体吞吐。

在vLLM中这类问题框架基本已经处理了，但如果你是基于TensorRT-LLM或自研推理引擎做二次开发，需要特别注意投机解码和batching逻辑之间的交互。实测中，如果batch size特别大（比如并发了几十个请求），推测解码的加速倍数通常会比单请求场景低一些，因为GPU已经基本吃饱了，草稿模型的额外计算和验证计算开始“抢资源”。但即便如此，只要接受率正常，总吞吐依然会优于不使用推测解码。

这其实引出一个结论：推测解码在“单用户延迟敏感”场景（如对话、流式输出）里的价值，比在“纯吞吐场景”里更高。因为纯吞吐场景你本就可以用大batch吃满GPU；但延迟这事，batch拉不起来，只能靠算法层面的思路来降。

4.5 常见问题速查表

5. 一些经验体会

最后说点个人的体会。推测解码是我近两年在生产里用过“性价比”最高的推理优化手段之一——它不需要重训目标模型，不改变输出分布，接入框架后改改配置就能跑。但它确实不是一个银弹，它对场景、模型、参数都敏感。我的建议是：先从接受率入手，用数据说话，不要迷信固定数值；草稿模型能小则小，能量化则量化；优先在长输出、延迟敏感的业务里用，短输出任务就别勉强了。

我在几个项目里反复调了几轮之后，现在反而更喜欢先跑一个简单的离线benchmark：用业务里最典型的500条样本，量出原生解码和推测解码的P50/P99延迟、接受率曲线，再决定上不上、怎么上。这套流程下来，基本不会再被“为什么没提速”这类问题打回票。希望这些经验能让你少踩几个坑。