推测解码加速方案评测：两代并行草稿怎么选

一、评测概述

大模型解码阶段通常逐token自回归生成，延迟随输出长度线性增长，是在线服务的主要瓶颈之一。推测解码通过“草稿器先猜一块、目标模型一次前向验证”的方式，把部分串行解码转化为并行验证，在不改变输出分布的前提下提升效率。围绕草稿如何生成，目前存在两条主要技术路线：

• 纯并行草稿路线：复用目标模型已算出的隐状态，把一段掩码token放进同一次前向里并行预测，一次生成一整块草稿；
• 混合路线：在并行骨干之后引入顺序头逐位置修正，并把草稿质量预测与在线服务的验证调度联动。

本文以某团队第二版并行草稿方案（下称“方案B”）为主线，与一条“混合草稿+动态验证调度”路线（下称“方案A”）进行对比评测，并把第一代纯并行草稿方案（下称“基线方案”）作为参照。适合推理框架工程师、算法工程师、架构师与技术负责人阅读。需要强调：评测的目的不是给出“谁更好”的绝对结论，而是回答不同方案在什么条件下、哪些指标上、以多大代价取得优势，以及这些结论的适用边界在哪里。

二、评测目标

本次评测重点回答五个问题：

1. 有效性：并行草稿的块内连贯性问题，在两代方案中是否被有效缓解、缓解到什么程度；
2. 效率：接受长度的提升，是否以可接受的参数量与延迟代价换来；
3. 吞吐：单请求接受长度提升，能否转化为高并发下的端到端吞吐收益；
4. 工程成本：引入路径选择、局部卷积或顺序头后，接入与调试复杂度如何变化；
5. 场景适配：低并发长输出与高并发在线服务两类负载，分别更适合哪条路线。

三、评测对象说明

3.1 基线方案及其问题

推测解码有一个硬约束：验证阶段只接受连续正确前缀，草稿中间错一个token，后面即使碰巧猜对也不会被采纳。基线方案并行预测整块token后，每个位置独立取top-1。单看每个位置似乎都合理，拼起来却未必连贯；且块越长，尾部质量衰减越明显，因为尾部token的正确性越来越依赖前面的选择，而独立top-1切断了这种依赖。

3.2 方案B：并行草稿的第二代优化

方案B把问题拆成两类分别处理：

第一类：正确token已在候选里，只是top-1选错了。 方案B不再让每个位置只保留一个答案，而是保留top-16，再用候选路径选择器对相邻token组合打分，从中挑出一条更连贯的路径。其依据是位置级命中率统计（见第七节）：正确token落在top-16中的概率远高于top-1命中率，说明“选路”比“逐位置硬选”更划算。

第二类：块尾位置正确token连候选集都进不去。 此时再聪明的路径选择也无用。方案B引入动态深度卷积，让每个位置混合自身与前一个位置的表示，用廉价的局部信息传递修补块尾依赖。相对把五层草稿器直接加深到十五层，这一改法只增加约3%参数量和约0.7%的单轮草稿延迟，而块尾首命中率已接近十五层模型水平。

3.3 方案A：混合草稿与验证调度

方案A同样承认纯并行的块内依赖问题，但选择了另一条路径：在并行骨干后加马尔可夫型或RNN型顺序头，逐位置修正完整词表分布；同时预测不同前缀的接受置信度，结合硬件负载动态决定本轮值得验证多少个token。因此方案A更像一套从草稿器延伸到服务调度的完整方案，方案B则更聚焦草稿器本身的优化，尽量避免任何顺序计算。

四、评测维度设计

评测维度	关注指标	为什么重要
草稿有效性	平均接受长度、逐位置命中率、top-k覆盖率	决定单轮验证能“白拿”多少token
草稿开销	单轮草稿延迟、参数量增量、显存占用	接受长度收益必须扣除草稿成本
块内一致性	连贯性、块尾衰减曲线	决定块长上限与加速稳定性
并发吞吐	端到端tokens/s、验证token对batch容量的挤占	高并发下的真实收益
工程复杂度	接入改造量、调度逻辑、调试便利性	决定长期维护成本
可观测性	接受率、逐位置统计、退化告警	线上质量下滑的预警能力
成本结构	显存、算力、人力投入	不同部署规模下的经济性

五、评测环境与前提

• 模型与部署：统一基座模型（报告实验采用某4B参数规模的对齐模型），相同量化配置、相同推理框架版本与硬件；若在百度智能云的GPU计算实例上搭建统一环境，可配合云监控能力记录资源指标，保证数据可比。
• 数据集：覆盖数学推理、代码生成、通用对话与长文本生成，避免单一任务造成偏置。
• 控制变量：采样参数固定、验证策略固定、块长与top-k设置对齐，每组配置重复多次取均值。
• 边界声明：不接受跨硬件、跨框架的直接数值对比，只做同环境内部对比。

六、评测方法

通用测试流程建议如下：

1. 建立基线：先跑纯自回归解码，记录延迟与吞吐，作为加速比参照；
2. 位置级分析：逐位置统计top-1命中率与top-k覆盖率，定位质量衰减区间；
3. 接受长度统计：按数据集分组统计平均接受长度与其分布，而非只看均值；
4. 端到端压测：设置低、中、高三档并发，分别测短输出与长输出负载；
5. 资源观测：记录草稿器参数量、单轮草稿延迟、显存增量；
6. 长尾与异常：观察领域外输入、极端格式下的接受率波动。

示意性伪代码（通用逻辑，不绑定任何具体工具）：

# 评测主循环：统计接受长度与端到端加速比
for prompt in eval_set:
    t0 = now()
    draft = drafter.block_generate(hidden=prompt_state, k=BLOCK, topk=16)
    path  = path_selector.choose(draft)        # 方案B：候选路径打分
    t_draft = now() - t0
    out, n_accept = target.verify(prefix, path)  # 只接受连续正确前缀
    record(n_accept, t_draft, t_verify, tokens_per_sec)
report(mean_accept_len, p50_latency, p99_latency, speedup)

七、结果解读

以下引用数据均来自单一报告的实验设置，具体数值会随模型、数据与配置变化，仅作解读示范。

1. 位置级命中率解释了方案B的设计依据。 在某公开数学推理评测集的样例统计中，第一个位置top-1命中率为85.4%，正确token落在top-16中的概率达99.5%；到第七个位置，top-1降到72.9%，top-16仍有87.8%。两个读数分别支撑两项设计：前中部位置“对的多但选不对”，适合路径选择；尾部位置“对的根本不在候选里”，必须修补表示本身。
2. 接受长度对比。 同一4B规模模型的实验报告显示：基线方案平均接受长度4.92，方案A为5.49，方案B为5.97，方案B相对基线提升约21%。解读时须注意：接受长度是单请求效率指标，不等于端到端加速比，收益还会被草稿延迟、验证成本与显存带宽摊薄。
3. 开销侧对比。 方案B的块尾卷积仅带来约3%参数增量与约0.7%的单轮草稿延迟，属于“小代价换尾部质量”的改法；方案A的顺序头与完整词表修正计算量更大，但其动态验证长度决策在高并发下可节省batch容量——这类收益只能通过压测体现，单请求接受长度看不出来。
4. 定位差异决定指标侧重。 方案A是“草稿到调度”的系统方案，应重点看高并发吞吐与稳定性；方案B是草稿器内部优化，应重点看低并发长输出下的接受长度与端到端延迟。

八、适用场景分析

场景特征	建议侧重	理由
低并发、长输出、显存有余量	方案B	并行草稿快、接受长度高，长输出可摊薄固定开销
高并发在线服务	方案A	每多验证一个token都会挤占batch容量，动态验证长度更划算
离线批量生成	方案B或基线+块长调优	吞吐优先，接受长度收益可直接兑现
实时对话、代码补全	视并发档位压测决定	首token与尾延迟敏感，需实测确认

九、风险与限制

• 数据来源单一：文中数值来自特定报告的实验设置，模型规模、数据分布、块长与top-k设置都会改变结论，落地前应在自有负载上复测；
• 接受长度不等于加速比：草稿延迟、验证开销、显存带宽与采样温度都影响最终收益，温度越高接受率通常越低；
• 长尾风险：领域外输入、极端格式、超长上下文下接受率可能显著波动，需要线上监控逐位置统计；
• 工程成本：路径选择器与动态调度都增加了调试与可观测性复杂度，小团队需评估维护能力。

十、选型与使用建议

1. 先测再选：用自有典型负载跑完“位置级命中率+接受长度+端到端压测”三件套，再决定路线；
2. 联合调优块长与top-k：块长越长尾部衰减越明显，top-k越大路径空间越足但打分成本越高，两者需一起搜索；
3. 把接受率纳入监控与告警：线上退化往往先表现为接受长度下滑，早发现早回滚；
4. 条件化决策：不追求单一方案通吃，可在不同服务层级部署不同草稿策略，按负载动态切换。

十一、总结

本文以两代并行草稿方案与一条混合调度路线为对象，建立了覆盖草稿有效性、单轮开销、并发吞吐、工程复杂度与可观测性的评测框架。核心结论是条件化的：在低并发、长输出、显存有余量的负载下，方案B以极小的参数与延迟代价换取更高的接受长度，性价比突出；在高并发在线服务中，验证token对batch容量的挤占成为主要矛盾，方案A的动态验证调度更具价值。任何选型结论都应回到自身负载与环境中复测验证，评测的价值在于提供一套可复用的验证方法与解读视角，而非替代业务侧的实测判断。