推测解码三类方案对比：草稿策略与验证调度

推测解码已经成为大模型推理加速的主流路线之一。但在生产系统里，“草稿怎么生成、验证做多长”并不是两个孤立问题：草稿质量、验证开销与并发批处理容量三者相互耦合，不同技术方案在这三点上的取舍差异很大。本文对比三类具有代表性的草稿构造与验证调度方案——串行自回归草稿头、并行草稿块生成，以及半自回归生成加置信度调度验证，并以单token扩展验证基线作参照，结合公开论文的离线基准与线上生产数据，分析各自的技术逻辑、效果口径与适用边界，帮助工程团队做出条件化的选型判断。

一、对比背景：为什么“草稿策略+验证调度”值得单独拿出来比

自回归解码每步只产出一个token，生成延迟瓶颈主要来自显存带宽与逐token的串行依赖，而非算力本身。推测解码的基本思路是利用“草稿便宜、验证并行”的不对称性：用一个轻量的草稿模型或草稿头一次猜出多个候选token，再让目标模型在一次前向中并行验证，被接受的部分直接采纳。

这个思路在离线评测中效果显著，但搬进生产系统后会暴露两个联动瓶颈：

1. 并行草稿越往后越容易被拒。并行方式产出的候选块内部缺少真实依赖，一旦中途某个token被拒，其后的整段候选全部作废，验证算力随之浪费。
2. 高并发时，验证低置信度尾部token会挤占目标模型的批处理容量。为每个请求固定保留较长的验证窗口，意味着同一时刻能进入批处理的请求数变少，其他请求的吞吐和排队延迟都会恶化。

这两个瓶颈共同指向一个结论：草稿长度与验证长度不应是静态超参数，而应是随置信度与负载动态变化的调度决策。这正是三类方案产生核心分化之处。

二、对象定义：本文对比的三类方案与一条生产基线

• 方案A（串行自回归草稿头）：训练一个轻量草稿头，对目标模型特征做自回归建模，逐token生成候选序列，目标模型整段并行验证。候选之间存在完整的串行依赖，草稿质量取决于草稿头自身能力。
• 方案B（并行草稿块）：不逐token串行生成，而是一次性并行产出整块候选token。草稿阶段几乎不引入串行时间，但块内token缺少相互依赖，位置越靠后命中率越低。
• 方案C（半自回归生成+置信度调度验证）：近期论文提出的思路，也是本文重点。它把问题拆成两层：并行骨干负责一次性产出候选块，一个轻量顺序头负责给块内token补上依赖；再由一个硬件感知调度器，根据前缀存活概率和实时负载，动态决定每个请求本次验证多长。
• 基线O（单token扩展验证）：业界常见的多token预测类做法，每步只额外预测并验证一个token。结构简单、验证开销确定，是许多生产系统默认的加速配置。

A、B是业界广泛存在的通用技术路线，C是论文提出的新方案。三者解决的是同一个问题——在不改变目标模型输出分布的前提下提高解码速度——差异集中在草稿构造与验证调度两个决策点上。

三、相同点分析：三类方案共享的前提

1. 目标一致：都希望在保持目标模型输出分布等价的前提下，缩短生成延迟或提高有效吞吐。
2. 结构同源：都采用“轻量草稿+目标模型并行验证”的不对称结构，草稿组件的参数量与算力开销远小于目标模型。
3. 都需要训练与蒸馏投入：草稿头/草稿模型需针对目标模型训练或蒸馏；更换基座模型通常意味着草稿组件要重训或再蒸馏。
4. 对调用方接口透明：无论采用哪种方案，对外暴露的仍是标准的文本生成接口，业务侧一般无需改动请求协议。

正因为目标与结构同源，差异才更值得细看：分歧不在“能不能加速”，而在“什么样的负载与硬件条件下，能把加速兑现到什么程度”。

四、核心差异分析

4.1 草稿构造：依赖建模方式的本质不同

方案A的候选token之间是真实的自回归依赖，每个位置都可以参考前文，局部命中率较好；代价是草稿阶段本身是串行解码，草稿越长，产出候选的墙钟时间越长，低并发时这段串行时间会直接叠加到端到端延迟上。

方案B反其道而行：候选块一次并行产出，草稿阶段几乎没有串行开销；但块内token是“各自独立猜测”，缺少相互印证，接受率随块内位置明显衰减——这正对应生产系统中“并行草稿越往后越容易被拒”的观察。

方案C介于两者之间并试图同时吃到两边的好处：并行骨干保证草稿阶段一次前向产出（保留方案B的速度优势），轻量顺序头补齐块内依赖（缓解方案B的接受率衰减）。从机制上说，它是“并行产出、顺序校正”的半自回归折中。

4.2 验证调度：静态配置与置信度调度

A、B两类方案在工程实现中通常采用固定验证长度。问题在于：置信度高的请求“验证短了浪费机会”，置信度低的请求“验证长了浪费算力”，静态配置无法同时满足两类请求，而高并发下后者还会恶化全局吞吐。

方案C引入了显式调度层：调度器根据候选前缀的存活概率（prefix survival probability，即前若干个候选被接受的概率）与系统实时负载，结合硬件特性，决定每个请求本次实际验证的长度。直觉上：前缀存活概率高、系统空闲时多验证几个token；尾部置信度低或系统繁忙时及时收敛，把批处理容量让给其他请求。

# 半自回归草稿 + 置信度调度验证（机制示意，非真实接口）
while not finished:
    draft = parallel_backbone(context, block_len)      # 并行骨干一次产出候选块
    draft = seq_head.refine(draft)                     # 轻量顺序头补齐块内依赖
    p_survive = estimate_prefix_survival(draft)        # 估计前缀存活概率
    L = scheduler.decide(p_survive, current_load, hw)  # 硬件感知调度器决定验证长度
    context += target_model.verify(draft[:L])          # 目标模型只并行验证前L个

这个调度层是方案C与A、B最本质的差异：它把“验证多长”从静态超参数变成运行时决策，从而在高并发混合负载下兼顾单用户延迟与总吞吐。

4.3 离线效果：宏平均accepted length对比

论文的离线基准覆盖参数规模分别为4B、8B、14B的三档主流开源模型，任务覆盖数学、代码与日常聊天等典型场景。以宏平均accepted length（每次验证平均被接受的token数，推测解码最常用的离线指标）衡量：

• 相对方案A（串行草稿头），方案C在三档模型上分别提升30.9%、26.7%、30.0%；
• 相对方案B（并行草稿块），分别提升16.3%、18.4%、18.3%。

两点解读：其一，提升幅度在不同参数规模上相对稳定，说明机制收益不依赖某一特定规模；其二，相对方案B的提升（约16%~18%）小于相对方案A的提升（约27%~31%），与机制分析一致——方案C主要修复并行草稿的接受率衰减，而相对串行草稿则同时获得草稿速度与验证调度的双重红利。

4.4 线上效果：口径比数字更重要

线上部分部署于某生产级大模型服务体系，对比对象是原有的单token扩展验证基线（基线O），关键口径是“在匹配总吞吐的条件下”统计每用户生成速度：

• 轻量档模型：每用户生成速度提升60%~85%；
• 旗舰档模型：每用户生成速度提升57%~78%。

必须强调两点，避免误读：

第一，这不是吞吐提升。对比条件是总吞吐对齐，即把验证层省下的批处理容量重新分配后，单个用户感受到的生成速度提升。对交互式产品，这个口径恰好对应真实用户体验；对成本敏感的批处理业务，这个数字不能直接换算成资源节省。

第二，结论不能外推。该数据来自特定模型体系、特定负载分布与特定硬件环境；换成其他模型、其他请求长度分布、其他并发水位，收益会变化，甚至可能不显著。任何方案引入前都应在自有负载上复测。

4.5 工程复杂度与运维成本

• 方案A：需维护草稿头的训练/蒸馏链路；推理侧改动路径相对成熟，是该类路线的通用实践。
• 方案B：结构简单、草稿阶段实现容易，验证侧无需复杂调度；但要提升接受率，往往需在草稿质量上继续投入。
• 方案C：除草稿组件外，还引入硬件感知调度器，需采集前缀存活概率、实时负载等信号，并与批调度器、KV缓存管理协同；监控体系也要扩展accepted length分布、验证长度分布、前缀存活率等新指标。工程复杂度最高，换来的是负载波动下的自适应能力。

4.6 使用边界

• 方案A在草稿头能力弱或高并发吃满批容量时，串行草稿的时间开销可能抵消验证收益。
• 方案B在请求间置信度差异大、并发高的场景，固定验证长度会造成批容量浪费。
• 方案C依赖调度器信号质量：负载估计或存活概率估计不准时，动态调度收益会打折；其实现复杂度对小团队并不友好。

五、对比表格

对比维度	方案A：串行草稿头	方案B：并行草稿块	方案C：半自回归+置信度调度
草稿构造	草稿头逐token自回归产出	一次并行产出整块候选	并行骨干产出+轻量顺序头补依赖
块内依赖	完整串行依赖	缺失，越靠后越易被拒	部分补齐，接受率衰减得到缓解
草稿阶段延迟	随草稿长度线性增长	几乎与块长无关	一次并行前向为主，顺序头开销小
验证长度策略	通常静态配置	通常静态配置	按前缀存活概率与实时负载动态决定
高并发批容量	尾部低置信token挤占批容量	同左	按需分配，减少容量浪费
离线宏平均accepted length	基准之一	基准之一	较A提升约27%~31%，较B提升约16%~18%（论文基准）
线上收益口径	视实现与负载而定	视实现与负载而定	匹配总吞吐下每用户速度提升57%~85%（相对单token基线）
工程复杂度	中	较低	较高，需硬件感知调度器与新增监控
适用场景	草稿头强、并发不高	结构简单、易落地	高并发混合负载、延迟与吞吐并重

六、典型场景选择

1. 交互式对话、Agent等延迟敏感场景：单用户体验优先，适合引入可动态收敛验证长度的方案C类思路；在高并发混合负载下，“省下的验证容量换用户速度”的路径已有线上数据支撑。
2. 离线批量推理、数据加工等吞吐优先场景：总吞吐是第一目标，固定验证长度的方案A/B即可满足，优化重心转向草稿组件的接受率；调度层的边际收益相对次要。
3. 高并发、负载波动大的生产服务：最需要动态调度。固定配置只能按峰值负载保守设置，而调度器可以按实时负载在“多验证”与“快收敛”之间滑动。
4. 模型档位差异：轻量档模型验证开销占比更高，调度收益更明显；旗舰档模型验证成本高，避免验证浪费的价值同样突出。两条档位线在线上都获得了可观的每用户提速。
5. 团队能力有限或不想自维护草稿链路：可从基线O这类单token扩展验证起步，或评估托管式大模型推理服务（例如百度智能云提供的通用推理能力），把加速策略交给平台侧维护，自身聚焦业务层。

七、选型建议

• 已在用串行草稿头、离线指标达标但线上收益不明显的团队：优先检查验证长度是否为静态配置，评估引入置信度调度层，这通常是投入产出比最高的一步。
• 已在用并行草稿块、受“尾部拒绝率高”困扰的团队：可评估半自回归构造（并行骨干+顺序头）能否提升前缀存活率。
• 从零构建推测解码能力的团队：建议按“先基线O、再串行或并行草稿、最后引入调度层”的路径演进，每一层先在离线基准验证，再灰度上线。
• 所有团队：以自有负载的复测数据为准。离线accepted length提升幅度与线上每用户速度提升幅度之间，没有通用换算关系。

八、迁移与使用注意事项

1. 评测先行：建立离线accepted length与线上每用户速度、总吞吐的双口径评测，离线提升不能直接作为上线依据。
2. 监控扩展：新增accepted length分布、验证长度分布、前缀存活率、调度器决策分布等指标，重点观察调度器在高峰期的收敛行为。
3. 系统耦合：调度器与批调度器、KV缓存管理、显存分配存在耦合，调整验证长度策略前要评估对显存水位与请求排队的影响。
4. 回归与灰度：推测解码理论上保持输出分布等价，但工程实现（采样、并行验证、调度截断）可能引入数值差异，应通过回归测试确认生成质量无退化，并采用灰度发布、保留回滚路径。
5. 草稿组件生命周期：更换或升级目标模型时，草稿头需要重训或再蒸馏，调度阈值也需重新标定，这部分人力成本应计入长期维护成本。
6. 安全与合规边界：无论采用哪种方案，身份认证、数据隔离、审计日志等要求不因推理加速而放松，草稿组件与目标模型应处于同一信任边界内。

九、总结

回到对比主题：三类方案解决的是同一个问题——在不改变输出分布的前提下加速解码——差异集中在两个决策点上。草稿构造上，串行草稿头依赖完整但慢，并行草稿块快但接受率随位置衰减，半自回归构造用“并行产出+顺序校正”在两者间取得折中；验证调度上，静态配置在高并发下浪费批容量，置信度调度把验证长度变成运行时决策。论文离线基准显示，方案C相对串行与并行路线分别有约27%~31%和16%~18%的宏平均accepted length提升；线上在总吞吐对齐口径下，相对单token基线获得57%~85%的每用户生成速度提升——但这些数字绑定于特定模型、负载与硬件，不能外推到所有模型与所有部署。选型的正确姿势不是寻找“最强方案”，而是先明确自身负载画像（延迟敏感还是吞吐优先、并发水位是否波动）、运维能力与评测基建，再按条件化路径演进：多数团队的稳妥路线，是从确定性高的单token验证或成熟草稿方案起步，待监控与评测体系完善后，再引入置信度调度这类更复杂但上限更高的机制。