投机采样推理吞吐评测方法：指标、流程与选型清单

一、本文的定位

本文是一套评测方法框架，不包含任何具体产品或模型的实测数据。文中的指标定义、测量步骤和判断标准，可直接用于自有环境的验证。读者需要自行在目标硬件和业务负载下运行测试，才能得到可用于选型的结论。

阅读对象是推理服务的开发者、系统架构师、运维人员和技术负责人。评测的目的不是回答”快不快”，而是回答三个更具体的问题：在什么条件下变快，变快之后是否稳定，以及付出的代价是否值得。

二、投机采样的基本机制

投机采样（speculative decoding）也称推测解码，其核心是”草稿生成加并行验证”。具体流程如下：

1. 使用一个较小的草稿模型，从当前位置向后连续预测 k 个令牌。
2. 主模型把这 k 个草稿令牌与当前上下文拼接，在一次前向计算中并行得到每个位置的概率分布。
3. 从前往后逐个检查草稿令牌。若主模型接受某个令牌，则保留它并继续检查下一个。
4. 遇到第一个被拒绝的位置时，停止接受，并从修正后的分布中采样一个令牌作为替代，然后开始下一轮草稿。

收益来自于同一次主模型前向计算能产出多个令牌。接受的草稿越多，每次主模型调用的有效产出越高。若草稿全部被拒绝，每轮至少还能得到一个令牌，但草稿模型的计算已经白费，这是主要的开销来源。

采样条件对结果的影响

在随机采样下，标准实现采用拒绝采样。对草稿令牌 x，若主模型概率为 p(x)，草稿模型概率为 q(x)，则以 min(1, p(x)/q(x)) 的概率接受。被拒绝时，从归一化的 max(0, p−q) 分布中重新采样。在这种实现下，输出分布与主模型单独生成时一致。

如果某个实现在验证阶段省略了修正步骤，输出分布可能发生偏移。因此，质量验证是必要的，不能只看速度。

温度（temperature）和 top-p 会直接影响接受率。温度越高，分布越平坦，两个模型的预测越容易分歧，接受率通常下降。top-p 截断会改变实际参与采样的分布。评测时应确认草稿阶段和验证阶段使用相同的温度和截断规则，否则接受率的统计会失去意义。

此外，草稿模型与主模型必须使用相同的词表和分词方式。词表不一致时，令牌无法逐位对齐，接受率没有可比性。

贪心解码的特例

在贪心解码（temperature 为 0）下，验证规则退化为判断草稿令牌是否等于主模型在该位置的 argmax。输出与基线应当完全一致。若在贪心模式下输出不一致，应优先排查实现问题。

三、核心指标定义

评测前应把下列指标写成统一口径，所有对比都基于同一套定义。

指标	定义	测量口径	注意事项
接受率 α	被接受的草稿令牌数 / 草稿提出的令牌数	按任务类型分组统计	样本量不足时波动大，需累积足够的草稿令牌
每次验证产出 E	最终输出令牌数 / 主模型验证次数	从请求日志中统计	直接反映”一次前向产出多少令牌”
回退率	发生拒绝的验证轮次 / 总验证轮次	按输入长度和输出长度分段统计	回退集中出现时会放大尾延迟
净吞吐	最终输出令牌数 / 总耗时	总耗时包含草稿生成、主模型验证、回退重算与调度	不能只计算主模型耗时
加速比	方案净吞吐 / 基线吞吐	同硬件、同参数、同负载下对比	基线必须在同一时间段内采集
首令牌延迟 TTFT	请求发出到第一个输出令牌返回的时间	流式与非流式分别统计	草稿阶段可能增加首令牌延迟
尾延迟 P95、P99	请求级端到端延迟的分位数	对重复运行的全部请求统计	不用平均值代替分位数
显存增量	方案峰值显存 − 基线峰值显存	同一批请求下的峰值监控	草稿模型权重和 KV cache 都要计入

净吞吐的计算公式为：

净吞吐 = 有效输出令牌数 / （主模型总耗时 + 草稿模型总耗时 + 回退重算耗时 + 调度开销）

只有在这个口径下，加速比才能反映真实收益。若草稿模型开销很大，接受率再高，净收益也可能很小。

四、评测前提与环境控制

为避免结论失真，开展评测前应满足以下条件。

1. 硬件与并行策略一致：基线和方案运行在相同的 GPU 型号、卡数、张量并行和流水并行配置下。
2. 精度设置一致：权重精度、KV cache 精度和算子实现应完全相同。草稿模型的精度也要记录。
3. 采样参数一致：温度、top-p、top-k、随机种子在两组实验中保持一致。
4. 批量与并发可控：明确 batch size 与并发数，两者对接受率和回退开销都有影响。通常批量越大，主模型计算越接近饱和，投机采样的边际收益会下降。
5. 预热与重复：每组配置先做若干次预热请求，再正式记录。每组配置重复多次运行，以观察结果的波动范围。
6. 负载隔离：测试期间避免其他任务抢占算力和带宽，记录背景负载。
7. 测试样本代表性：样本应覆盖短问答、长文本生成、结构化输出和代码生成等任务类型，并记录各类型的占比。

测试结论只适用于所测的模型组合、硬件和负载条件，不应直接外推到其他参数规模或部署环境。

五、测试流程

5.1 建立基线

先关闭草稿预测，在常规逐令牌生成模式下测量。测量维度包括不同输入长度、输出长度和并发级别下的净吞吐、TTFT 和 P95、P99 延迟。基线曲线是所有后续对比的参照。没有基线，任何加速数字都没有意义。

5.2 分维度验证

• 吞吐验证：固定输出长度，逐步提高并发，观察吞吐随并发的变化。重点看拐点位置和饱和区间。
• 接受率验证：按任务类型分组统计接受率。开放式生成和结构化生成的接受率通常差异明显，应分开报告。
• 草稿长度验证：对不同的 k 值分别测试，找到使净吞吐最高的草稿长度。k 过大时，末尾草稿被拒绝的概率增加，浪费更多计算。
• 延迟验证：分别测量 TTFT 和完整响应时间，判断加速是否以交互体验为代价。
• 质量验证：对加速前后的输出做抽样比对，检查语义一致性和格式正确性。贪心模式下应做逐字比对。随机模式下可用固定种子比对，或用统计检验比较输出分布。
• 稳定性验证：进行长时间连续请求测试，观察接受率、回退率和显存占用是否随时间漂移。
• 异常验证：注入超长输入、空输入和格式错误的请求，检查回退逻辑是否健壮，有没有异常中断或结果错乱。

5.3 记录字段与采样方式

测试过程中，每次请求至少应记录下列字段：

• 标识与分组：case_id、task_type、repeat_idx
• 输入输出：input_len、output_len
• 采样参数：temperature、top_p、random_seed
• 系统配置：draft_len（k）、batch_size、concurrency
• 验证统计：drafted_tokens、accepted_tokens、verify_rounds、rollback_count
• 耗时：ttft、total_time、draft_time、verify_time
• 资源：gpu_mem_peak

记录逻辑可以按如下方式组织：

配置: warmup_runs = 3, repeat = 5, 每组固定随机种子
for each case in test_set:
    for r in 1..repeat:
        t0 = now()
        out, stats = generate(case.input, config, seed)
        t_end = now()
        record({
          case_id, task_type, input_len, output_len,
          temperature, top_p, draft_len, batch_size, concurrency,
          drafted_tokens, accepted_tokens, verify_rounds, rollback_count,
          ttft, total_time, draft_time, verify_time,
          gpu_mem_peak, repeat_idx
        })

分位数应基于请求级的全部记录计算，而不是先对每轮平均再取分位。流式和非流式的测量口径要分别统计，不要混合。

六、结果解读

结果解读应附带条件，不能只给出一个加速比。以下是常见的解读方式：

• 若接受率在结构化任务上明显高于开放式任务，说明该方案更适合输出模式较固定的场景。
• 若并发提高后加速比下降，瓶颈可能已经转移到调度、显存带宽或批处理策略。
• 若 TTFT 上升而净吞吐提升，该方案更适合离线批处理，不适合对首令牌敏感的交互场景。
• 若长时间测试中接受率逐步下降，需排查草稿模型与主模型的状态一致性，以及缓存是否正确复用。

常见问题

接受率高，但净吞吐没有提升。 通常是草稿模型开销过大，或 batch size 已经让主模型接近算力饱和。应分别测量草稿耗时和验证耗时，看哪一部分占比过高。

净吞吐提升，但 P99 变差。 多见于回退集中爆发的情况。按输入长度和输出长度分段统计回退率，判断是否某类请求触发了大量拒绝。

输出质量下降。 先检查验证阶段是否正确实现了修正采样，再检查温度和 top-p 是否在两个阶段一致。贪心模式下可以逐字比对，能快速定位问题。

并发提高后收益消失。 这通常说明瓶颈已经转移。可以对比基线的显存带宽占用和 GPU 利用率，判断加速方案是否还能在该负载下带来正收益。

七、与其他优化手段的比较

投机采样不是唯一的推理优化手段，也不必然是最优选择。下表列出几类常见方案的特点，便于做组合判断。

方案	主要收益	主要代价或风险	适合场景
投机采样	降低单请求解码延迟，提高低并发下的吞吐	草稿模型开销、接受率波动、回退尾延迟	长输出、固定模式、低到中等并发
量化	降低显存占用和计算量	可能影响输出质量，需要单独验证	显存紧张、对精度容忍度较高
KV cache 优化	提高显存利用率，支持更长上下文和更大批量	实现复杂度较高，调度需配合	长上下文、高并发服务
连续批处理	提高 GPU 利用率和整体吞吐	单请求延迟可能增加	高并发在线服务

一般而言，投机采样在解码受显存带宽限制时收益较明显，即小批量或低并发场景。批量增大后，主模型本身的计算量上升，草稿带来的边际收益会减少。因此，投机采样与连续批处理组合使用时，调度器需要支持按请求设置不同的草稿长度，否则难以兼顾两者。

八、上线前检查清单

• 基线可复现：同一配置重复运行，关键指标的波动在预期范围内。
• 词表、分词方式和模型版本在草稿模型与主模型之间一致。
• 采样参数在基线与方案之间完全一致。
• 接受率按任务类型分组统计，并且样本量足够。
• 净吞吐计算包含草稿耗时和回退重算耗时。
• 尾延迟的 P95 和 P99 已对照业务 SLO 进行判断。
• 显存增量和单位吞吐成本已核算。
• 灰度发布的比例已确定，并配置回退率和接受率的告警。
• 质量抽样比对机制已建立，贪心模式下有逐字比对结果。
• 存在一键关闭草稿预测的开关，能快速回到基线路径。

九、适用与不适用场景

该类方案较适合输出较长、格式相对固定、对吞吐敏感而对首令牌延迟不敏感的批处理和内容生成任务。在低到中等并发下，它的收益更容易体现。

以下场景需要谨慎评估：

• 高并发且已接近算力饱和，加速收益可能很小。
• 输出很短，草稿和验证的固定开销难以被摊薄