投机解码草稿模型评测方法与结果解读

一、评测概述：为什么草稿模型必须被单独评测

投机解码（speculative decoding）的基本结构是“小模型提议、大模型裁决”：用一个参数量远小于目标模型的草稿模型一次性提出一段候选 token，再由目标模型做一次批量前向完成验证，被接受的 token 直接落地，被拒绝处回退重采样。这类方案的宣传口径通常集中在两个数字上——草稿模型参数量、以及相对自回归解码的吞吐倍数。某开源团队发布的、面向 27B 级目标模型、约 1.92B 参数的并行草稿模型即属于这一路线：沿用“一次前向传播并行预测整块 token”的草稿设计，并新增轻量路径选择器与双抽头动态卷积结构，材料给出的口径是单并发下约 2.7–3.4 倍于自回归解码的吞吐，且解码结果无损。

问题在于，这些数字是条件性结论，而不是普适属性。草稿模型的收益高度依赖目标模型规模、输出分布形态、上下文长度、并发度、量化策略与推理引擎实现。同一份权重在单并发、贪心解码、中等长度输出下可能接近宣传区间，在几十路并发、采样解码、结构化输出约束下则可能收益大幅收窄甚至转负。因此评测草稿模型的核心不是“确认它快”，而是界定它在什么条件下快、快多少、以及无损性主张在什么定义下成立。本文面向的读者包括：需要为线上推理服务选型的架构师、要在自有引擎上做集成验证的开发者、负责容量与成本评估的运维与技术负责人。

需要强调的是，评测不是判断“好不好”的二元结论，而是把技术指标映射回业务目标：如果业务是高并发在线服务，单并发倍数几乎不构成决策依据；如果业务是交互式长文本生成，接受率随上下文增长的衰减曲线才是关键。

二、评测对象拆解：草稿模型究竟改变了什么

在建立评测维度之前，必须明确被评测对象的作用机制，否则指标会失去解释力。这类草稿模型解决的是自回归解码的固有瓶颈：每生成一个 token 都要完整读取一遍目标模型权重，解码阶段属于显存带宽受限而非算力受限，因此单并发下加速卡（accelerator）的计算单元大量空闲。草稿模型的价值就是把这些空闲算力换成“每轮多落地几个 token”。

关键结构差异在于草稿方式。逐 token 自回归式草稿本身也要串行多步，收益被草稿开销吃掉大半；而“一次前向并行预测整块 token”的设计把草稿阶段的串行深度压到 1，理论上把加速上限提升到接近草稿块长度。轻量路径选择器解决的是并行草稿头在多候选分支下如何挑选可信路径的问题，双抽头动态卷积则是在有限参数预算内补充局部上下文建模能力，用以提升候选 token 的命中率。这些设计对应的可观测指标非常明确：平均接受长度（acceptance length）与单次草稿开销占比。评测的所有性能结论，最终都要能被这两个量解释。

三、评测维度框架

维度	核心问题	主要观测指标	验证方式
正确性/无损性	开启投机解码后输出是否与基线一致	逐 token 一致率、分布一致性指标	贪心对比、固定种子对照、困惑度对比
有效性	草稿提议是否真被采纳	平均接受长度、接受率、拒绝位置分布	逐轮日志统计
单并发性能	单请求端到端延迟与吞吐	TTFT、每 token 间隔、tokens/s	固定输入长度梯度压测
并发扩展性	多路并发下收益是否保持	聚合吞吐、P95/P99 延迟、加速比随并发变化曲线	阶梯式并发递增
资源成本	额外显存与算力占用	显存峰值、草稿阶段算力占用、可用批量上限	资源采样与对照
稳定性	长时运行与异常输入下的表现	错误率、崩溃/重启次数、内存增长趋势	长稳测试、模糊输入、边界长度
兼容性	与引擎能力及量化策略的适配	可启用组合矩阵、功能降级项	组合矩阵逐项验证
可观测性	能否定位收益损失原因	是否暴露接受率、草稿耗时、回退次数	日志与指标核查
易用性与可维护性	接入与升级成本	接入改动点数量、配置项、升级回归成本	实操记录与人工耗时统计

每个维度的必要性不同。正确性优先于性能：投机解码的合法性建立在“验证步骤保证输出分布不变”之上，若实现存在缺陷，加速倍数越大反而意味着偏差放大越快。接受率是性能的因，吞吐是性能的果：只看 tokens/s 无法判断该换个业务场景是否还成立，而接受率一旦被记录，性能差异就能被归因。并发扩展性往往是选型的分水岭：草稿模型的额外开销在低并发时被闲置算力吸收，在高并发时与真实业务请求争夺同一份算力。

四、评测环境与前提条件

评测开始前应把变量固定下来并写入记录，否则跨次结果不可比。需要明确的边界条件包括：目标模型的权重精度与量化方式（全精度、低比特权重量化、激活量化等）及其是否与草稿权重精度一致；硬件型号与显存容量；引擎侧关键配置（最大上下文长度、KV 缓存策略、批处理调度策略、是否启用分页缓存与前缀复用）；解码参数（温度、top-p、top-k、重复惩罚、是否强制贪心）；输入分布（长度分布、领域分布、是否长上下文）；以及采样口径（是否使用固定随机种子）。

一个常被忽略的前提是基线必须与实验组只差一个变量。同一份权重、同一份配置、同一批输入，一组关闭投机解码、一组开启，且两组使用同一引擎版本，否则得到的倍数无法归因于草稿模型。建议在百度智能云等环境中的云服务器或容器平台上执行时，把实例规格、网络条件、并发客户端配置一并归档，便于后续复现与横向比较。

五、评测方法：分阶段流程

阶段一：建立基线与冒烟验证。 先在关闭草稿模型的条件下跑通全流程，记录基础吞吐、延迟分布与输出样本，作为基线。随后开启草稿模型做小规模冒烟，确认可正常生成、无异常回退、显存未溢出。

阶段二：无损一致性验证。 这是必须单独设计的环节。贪心解码下，理论上开启前后应逐 token 完全一致；采样解码下，随机数消费顺序变化会导致单条轨迹不同，此时应转向分布层面的比对：固定提示集、统计多轮采样的输出分布差异，或对比开闭两组在相同数据集上的困惑度与人工/自动评测得分，判断是否存在系统性偏移。示意性伪代码如下：

def check_greedy_equivalence(prompts, generate):
    mismatched = 0
    for p in prompts:
        out_off = generate(prompt=p, speculative=False, greedy=True, seed=None)
        out_on  = generate(prompt=p, speculative=True,  greedy=True, seed=None)
        if out_off != out_on:
            mismatched += 1
            log_diff(p, out_off, out_on)   # 记录首个分叉位置
    return mismatched / len(prompts)      # 期望结果应为 0
def check_sampling_consistency(prompts, generate, runs=8):
    # 采样场景不做单条轨迹对比，改为统计量比对
    scores = {}
    for mode in (False, True):
        samples = [generate(prompt=p, speculative=mode, greedy=False,
                            temperature=0.7, top_p=0.9, seed=fixed_seed)
                   for p in prompts for _ in range(runs)]
        scores[mode] = evaluate(samples)   # 困惑度/任务得分/分布距离
    return scores

需要特别验证的兼容性组合包括：受约束解码与结构化输出（JSON、正则约束、工具调用参数格式），因为这些机制会在解码循环中插入额外校验逻辑，可能与投机提交的批量回退产生冲突；多轮对话与前缀缓存；以及草稿权重与目标权重的分词表是否严格一致——词表错位不会报错，但会静默拉低接受率。

阶段三：接受率与加速比拆解。 开启引擎侧统计（若未原生暴露，可在验证环节埋点），按“每轮提议 token 数、每轮接受 token 数、草稿前向耗时、目标验证耗时”四项分别累计，得到平均接受长度与草稿开销占比。判断依据是：若加速倍数高但草稿开销占比也高，说明该硬件或该并发档位下草稿模型相对目标模型仍偏重，扩展性存疑；若接受率随输入长度或领域明显下滑，说明收益依赖特定输出分布。

阶段四：单并发到并发的阶梯压测。 输入长度取短、中、长三档，并发按 1、2、4、8、16、32 等阶梯递增，每档稳定后记录聚合吞吐、平均延迟、P95/P99、显存峰值与加速比。重点观察加速比曲线是否存在拐点，以及拐点出现的并发档位是否落在业务实际负载区间内。

阶段五：长稳与异常测试。 连续运行数小时以上观察内存与显存增长趋势、错误率是否抬升；输入侧覆盖超长上下文、空输入、异常字符、极端温度参数、并发突增与客户端中途断开；依赖侧覆盖引擎重启、显存不足时的降级行为。记录重点是是否可自恢复，以及恢复期间是否影响正确性。

阶段六：可观测性与运维成本核查。 确认关键指标是否可导出到通用监控告警与日志服务，是否可区分“草稿阶段耗时”与“目标验证耗时”，是否有接受率跌破阈值时的告警手段。同时记录接入改动点数量、配置项含义清晰度、升级新版本时的回归测试范围。

六、结果解读：什么结果能支撑什么判断

第一，加速倍数必须与并发档位绑定表述。“单并发下约 2.7–3.4 倍”是一个有意义的上界参考，但它不能被外推到高并发在线服务。技术原因在于：单并发时解码阶段算力大量空闲，草稿带来的额外计算被闲置资源吸收；并发上升后，批量矩阵运算把算力填满，草稿模型的额外前向与更宽的验证批量开始与真实请求竞争资源，同时批内不同序列接受长度不一致会带来对齐浪费，收益随之递减。若你的业务集中在高并发区间，应当把评测权重压在第 8–16 档并发的数据上。

第二，无损主张要看定义与验证范围。贪心解码下的逐 token 一致是最强的表述；采样解码下的“分布无损”属于统计意义上的等价，需要在自己的提示集与任务上验证，尤其要检查结构化输出、长上下文和量化组合这三类高风险场景。评测报告里应写明“在何种精度、何种长度、何种约束条件下验证为一致”，而不是笼统写“无损”。

第三，接受率是场景相关量。代码生成、结构化输出、格式化模板填充这类模式化程度高的输出通常接受长度较长；开放式创意写作、多语言混杂、强推理链条的输出接受长度通常偏低。因此同一模型在不同业务线的收益可能差异明显，评测时应按业务真实流量分布构造提示集，而不是只用通用短问答。

第四，资源成本要计入结论。草稿模型常驻显存、占用可用批大小、增加单次迭代耗时，这些会反过来压低高并发吞吐。评测应给出“开启前后最大可支撑并发数”的对照，这才是容量规划真正需要的数字。

七、适用场景分析

场景	首要指标	关注理由
交互式对话、长文本创作	单并发每 token 延迟、长上下文接受率	用户直接感知流式输出速度，并发相对可控
代码补全与结构化生成	接受率、受约束解码兼容性	输出模式化程度高，理论收益大，但需验证约束兼容
高并发在线 API	加速比随并发变化曲线、P99 延迟、可支撑并发数	收益可能被算力竞争抵消，甚至转负
离线批量生成与数据处理	聚合吞吐、单位产出资源成本	无延迟敏感性，可接受更高草稿开销换吞吐
端侧或显存受限部署	显存峰值、权重加载开销	1.9B 级草稿权重与 KV 缓存占用需实测

八、风险与限制

评测结论的边界必须写清。样本偏差方面，提示集若只覆盖单一领域或短输出，会系统性高估收益；环境差异方面，不同硬件、不同引擎版本、不同调度策略下结果不可直接迁移；量化组合方面，低比特目标模型本身会缩小与草稿模型的差距，改变收益空间；统计口径方面，若平均接受长度按“每轮”统计而分母含被完全拒绝的轮次，指标含义会与按 token 统计不同，跨报告比较需先对齐口径；长期不确定性方面，引擎版本升级可能改变批处理与缓存策略，历史评测结论需要定期回归。此外，草稿模型通常只针对特定目标模型规格训练，换用同家族不同规模或不同词表的目标模型时，接受率可能显著下降，这一点必须在评测中显式验证，不能默认通用。

九、选型与使用建议

1. 先验证正确性，再看性能：把无损一致性检查作为准入门槛，未通过的候选直接排除。
2. 用真实流量分布构造提示集，至少覆盖短问答、长生成、结构化输出三类，并按业务占比加权。
3. 把并发阶梯压测作为必做项，找到加速比拐点并与其业务负载区间比对。
4. 建立“关闭/开启”双基线台账，长期跟踪接受率与加速比，作为版本升级的回归依据。
5. 若并发长期高于拐点，优先考虑其他降本路径（提高批处理效率、缓存复用、模型量化、请求路由分级）而非默认开启草稿模型。
6. 在自有环境（例如基于百度智能云的云服务器、容器平台、监控告警与日志服务等通用云产品能力）完成上述流程后再做容量与成本决策，避免直接采信单一口径的公开数据。

十、总结

这类“一次前向并行预测整块 token + 轻量路径选择器 + 双抽头动态卷积”的草稿模型，本质上是用空闲算力换取每轮更多落地 token，其收益由接受率与草稿开销共同决定，并随并发上升而衰减。评测的正确姿势是：以无损一致性为门槛，以平均接受长度为因、以吞吐与延迟为果，以并发阶梯曲线为选型依据，把资源成本与可观测性纳入结论。公开材料给出的单并发倍数可以作为上界参考，但只有在自己的模型规格、精度配置、输入分布与并发档位上完成验证，才能形成可支撑容量规划与成本决策的判断。