推测解码详解：原理、关键指标与应用场景

一、概念定义：推测解码是什么

推测解码（Speculative Decoding，也译作投机解码、投机采样）是一类大模型推理加速技术的统称。它的核心思想是：先用一个开销很小的“草稿模型”（或其他轻量起草机制）快速生成若干候选 token，再让目标大模型对这一批候选 token 做一次并行验证，验证通过的部分直接采纳，不通过的位置则回退并改用大模型自身的输出修正。

从数学上看，只要接受/拒绝机制设计得当，最终输出的 token 分布与目标模型逐 token 生成的分布完全一致，因此推测解码通常被视为一种“无损加速”：它不牺牲生成质量，只改变生成的计算组织方式。

可以从三个视角理解这个定义：

• 技术视角：把自回归解码中“一次前向只产出一个 token”的串行过程，改造成“一次前向验证多个候选 token”的并行过程，用更大的单步计算量换取更少的解码步数。
• 系统视角：在解码阶段算力大量闲置、访存带宽才是真正瓶颈的前提下，把空闲算力用于验证草稿，从而提高每秒生成 token 数（TPS）。
• 业务视角：在不更换主模型、不降低回答质量的前提下压缩响应时延，直接改善交互式产品的用户体验。

二、背景与价值：为什么需要推测解码

1. 自回归解码存在访存瓶颈。 大模型逐 token 生成时，每生成一个 token 都要把全部模型参数从显存搬运一遍，算术强度极低，属于典型的访存受限负载。主流推理框架通过连续批处理、KV 缓存分页管理、算子融合等系统层手段已经把吞吐做到很高，但单个请求的解码速度仍然受限于“一步一个 token”的串行本质。

2. 深度推理模型放大了时延问题。 近年出现一类以长思维链著称的深度推理模型，它们用更长的推理过程换取更高的回答质量，单次回答往往需要远超以往的时间，达到分钟级。在这种场景下，用户对“每秒吐出多少 token”的敏感度显著上升，TPS 直接决定产品可用性。

3. 另一条硬件路线的对照。 部分自研推理芯片的厂商选择把模型参数放进片上 SRAM，用极高的访存带宽换取单流生成速度，据公开材料口径，面向 70B 量级模型可提供每秒两百 token 以上的服务能力。这说明“高速推理 API”存在真实需求。推测解码则给出了另一种可能：不依赖专用硬件，在基于 HBM 显存的通用 GPU 上，通过算法手段逼近类似的速度区间。有公开讨论给出过这样的估算：若草稿开销趋近于零，当验证树规模与批次规模相当（常见 64～128 量级），且平均接受长度能达到 10 左右时，通用 GPU 也能支撑高速服务。当然，现有以树形草稿为代表的算法距离这一目标还有明显差距，这正是该方向的研究价值所在。

三、核心组成与工作原理

1. 起草阶段。 用一个远小于主模型的草稿模型（例如为 7B 级主模型搭配 0.5B 级草稿模型），以普通自回归方式快速连出 K 个候选 token。起草的两个关键要求是“快”和“准”：快指单步开销小，准指候选 token 命中目标模型分布的概率高。除独立草稿模型外，草稿来源还可以是主模型附带的额外预测头、n-gram 查表、上下文缓存复用等轻量机制。

2. 验证阶段。 把“前缀 + K 个草稿 token”拼成一段输入，让目标模型只做一次前向计算。由于这段输入可以并行处理，一次前向就能同时得到每个位置上目标模型的分布，相当于用接近生成一个 token 的访存成本，换回了 K 个位置的判断能力。当系统算力有富余时，还可以把候选组织成树形结构（树形草稿），一次验证多分支候选，进一步拉高接受长度，代价是验证计算量变大。

3. 接受与拒绝。 从草稿第一个 token 开始逐位比对：若草稿 token 符合目标模型在该位置的分布（具体判据依算法而定），则接受并继续；一旦出现不一致，该位置起全部作废，改用目标模型在该位置的输出。由此保证每一步采样都严格来自目标模型分布，这就是推测解码“无损”性质的来源。

示意性伪代码如下：

def speculative_step(target, draft, prefix, K):
    # 1) 起草：小模型快速给出 K 个候选 token
    draft_tokens = draft.generate(prefix, num_tokens=K)
    # 2) 验证：大模型一次前向，得到各候选位置的分布
    dists = target.forward(prefix + draft_tokens)
    # 3) 接受/拒绝：从左到右比对，首个不一致处截断，
    #    并用大模型分布补一个修正 token，保证输出分布一致
    kept, fix = accept_and_repair(draft_tokens, dists)
    return prefix + kept + [fix]

四、关键指标：平均接受长度与净收益

判断推测解码是否划算，主要看三个量：

• 平均接受长度（MAL）：每轮验证平均能采纳多少个 token，是整个体系的核心杠杆。业界讨论中常见的估算口径是：树形草稿规模取 64 时，单点命中率约 80% 对应 MAL 大致在 4 上下；若命中率提升到 90%，MAL 有望接近 10。
• 草稿开销：起草本身消耗的时间，理想情况是趋近于零。若草稿模型较大或需要多步串行生成，开销会侵蚀收益。
• 验证开销：验证树规模越大，单次前向计算量越大。只有当“一次验证 K 个候选的耗时”明显小于“逐个生成 K 个 token 的耗时”时，加速才有净收益。

直观地说，加速比大致正比于 MAL，再扣除草稿与验证的开销折损。工程优化的本质，就是在这三者之间寻找平衡点。

五、典型应用场景

1. 低时延交互与智能体应用。 对话助手、代码补全、智能体多轮工具调用等场景对首字时延和逐 token 速度都很敏感。草稿模型可以针对领域高频模式做对齐（代码等强模式场景命中率天然较高），MAL 容易做上去，收益明显。

2. 深度推理、长思维链场景的 TPS 提升。 当主模型采用“延长推理换质量”的策略后，单次回答的 token 数量大增，此时把资源投向提升 TPS 比继续堆吞吐更划算。推测解码与推理型模型是天然互补：前者加快单位 token 的产出速度，后者提高单位 token 的价值密度。这也是当前推测解码最受关注的应用方向。

3. 小批量、单流场景下的高速推理服务。 当在线服务并发批较小、GPU 算力有富余时，富余算力正好可以用于验证较大的草稿树。这意味着在不引入专用 SRAM 推理硬件的情况下，通用 GPU 集群也有机会通过算法把单流速度抬升一个量级。无论基于自建 GPU 集群，还是使用百度智能云等云服务商提供的大模型推理能力，这一逻辑同样适用。

4. 端侧与边缘推理。 在算力受限的端侧环境里，用很小的草稿模型配合压缩后的主模型，也能在可接受的显存开销内获得加速，但需更精打细算地权衡显存占用与草稿开销。

六、与相关概念的区别

1. 与主流推理框架：互补而非替代。 主流推理框架的优化重点在系统层——连续批处理、KV 缓存分页管理、内核与算子优化，主要提升系统吞吐与显存效率；推测解码是算法层面对解码方式的改造，主要提升单请求的生成速度。二者作用层面不同，通常在同一套服务栈内叠加使用，这正是“框架已经成熟，推测解码仍有独立价值”的原因。

2. 与量化、蒸馏、剪枝：无损与有损之分。 量化、蒸馏、剪枝都会改动模型本身，可能带来一定程度的质量损失；推测解码不修改主模型权重、不改变输出分布，属于无损加速。若业务对质量红线敏感，推测解码的优先级应当更高。

3. 与专用推理芯片路线：用算法换速度。 SRAM 路线通过芯片设计获得极高访存带宽，属于“用硬件换速度”；推测解码属于“用算法换速度”。两者面向同一需求：让大模型单流生成速度追上交互式产品的体验要求。至于哪种路线系统级成本更低，不能只看硬件物料：采用自研芯片并自营服务的垂直整合模式，厂商在毛利结构与定价策略上有更大腾挪空间，低价未必等价于低成本。评价两条路线，最终还是要回到单位 token 的综合服务成本。

七、使用注意事项

• 草稿质量决定收益上限。 MAL 不足是当前最主要的短板。公开讨论中，为 7B 级主模型搭配 0.5B 级草稿模型，在树形草稿、树规模 64 的设定下，MAL 往往只有 3～4，距理想目标仍有差距。选型时应重点评估草稿机制在自家业务数据上的命中率。
• 批量越大收益越小。 推测解码最适合算力有富余的小批量场景；批量大时，验证草稿会与正常请求争抢算力，甚至拖累吞吐，需要动态开关或自适应调度策略。
• 工程复杂度不低。 需要处理草稿模型加载、KV 缓存协同、树形验证的调度与掩码构造等问题，对推理框架的集成成熟度有一定要求。
• 评测要贴近真实分布。 草稿命中率高度依赖业务文本分布，通用基准上的结论未必能平移到具体场景，建议用真实流量做离线与在线双重验证。
• 优化目标要拆开看。 算法侧的核心是提高单点命中率（例如从 80% 提升到 90%，可把树规模 64 下的 MAL 从 4 拉向 10）；系统侧的核心是继续压缩起草与验证的开销。两条线同时到位，“通用 GPU 上的高速推理服务”才能真正成立。

八、总结

推测解码是一种“用小模型起草、大模型验证”的无损推理加速技术：它不改动主模型、不改变输出分布，通过把串行的逐 token 生成改造为“批量起草 + 并行验证”，用富余算力换取更高的每秒生成 token 数。在深度推理模型兴起、时延成为核心体验指标的背景下，它的价值被显著放大；其适用边界同样清晰——草稿命中率决定收益上限，批量大小决定算力余量，草稿与验证开销决定净加速。对开发者而言，判断是否引入推测解码，本质上就是回答三个问题：业务是否对单流 TPS 敏感、部署形态是否留有算力富余、能否为自家场景找到足够“准”的草稿机制。