推测解码为何能加速，接受率由什么决定？

图：用于辅助理解本题的数据流或工程结构。来源：Beam search，作者 D2L.ai authors，许可 CC BY-SA 4.0。

考察意图

面试官希望确认候选人能否解释“推测解码为何能加速，接受率由什么决定”中的因果关系，并把公式或流程落实到可测量的工程结果。

60–90 秒口述答案

推测解码先让便宜的 draft 模型连续提议多个 token，再由 target 模型一次前向并行验证。通过拒绝采样修正后可保持 target 模型的输出分布；加速来自减少串行 target 次数，而不是跳过验证。收益由 draft 成本、提议长度、接受率、target batch 和额外调度开销共同决定。

深入解释

若每轮提议 γ 个 token，理想接受数随接受率 α 增长；但 γ 太大时被拒后的无效 draft 工作和验证张量也增长。不能只用模型参数比估算加速。

白板回答时先声明输入规模、张量或请求状态，再推到输出与瓶颈；不要只罗列术语。

工程权衡

同族小模型、prompt lookup 或 n-gram 可作 draft。温度、任务领域和长尾词会改变接受率；高并发服务中 target 已充分批处理时，单请求加速可能挤压总体吞吐，需要同时测延迟与 tokens/s。

关键指标包括：TTFT、TPOT/ITL、端到端 P50/P95/P99、tokens/s、并发、队列时间、显存水位与单位 token 成本。

完整复习答案

先拆开一次请求

围绕“推测解码为何能加速，接受率由什么决定”，推理题需要把排队、Prefill 和逐 token Decode 分开。GPU 算力、显存容量、内存带宽与调度空槽可能同时成为约束，一个总体吞吐数字无法定位瓶颈。

用数量级定位瓶颈

draft 每轮提议 5 个 token，平均接受 4 个，target 一次验证可推进约 4 个位置；若领域变化使平均只接受 1 个，draft 与验证开销可能抵消收益。接受率必须按任务、温度和并发分群监控。

这个估算给出量级。代入项目参数时需要写明忽略项，并保持单位一致。

压测应回答什么

围绕“推测解码为何能加速，接受率由什么决定”，压测写明模型、dtype、并行度、硬件、输入输出长度分布和到达方式，同时报告 TTFT、TPOT、端到端尾延迟、tokens/s 与显存水位。容量取满足 SLO 的安全点。

追问参考

吞吐提升但 P99 变差，调度器可能做了什么？

对“推测解码为何能加速，接受率由什么决定”而言，吞吐提高而 P99 变差通常来自更大批次、更长等待窗口或 Prefill 抢占 Decode；查看 queue time、batch token 数和每阶段时间即可区分。

OOM 是权重、激活、临时 workspace 还是 KV Cache 导致？

回到“推测解码为何能加速，接受率由什么决定”，需要区分：OOM 要按权重、KV、激活、workspace 与碎片拆账，并用输入/输出长度、并发和块水位复现，不能只归因于“模型太大”。

怎样判断方案已经达到上线条件？

“推测解码为何能加速，接受率由什么决定”进入发布方案前，性能结论需绑定硬件、dtype、模型、并行度、长度分布、并发模型和 SLO；离线峰值不能直接当线上容量。

常见错误回答

只复述“推测解码为何能加速，接受率由什么决定”涉及的术语，没有说明输入、运算和输出之间的关系。
讨论解码优化时省略模型规模、数据分布或硬件条件，使结论失去适用范围。
只讲收益，没有检查 Speculative Decoding 带来的精度、资源或可靠性代价。

连续追问

若改变 Speculative Decoding 的关键配置，哪些中间量会先发生变化？
如何设计对照，检验观察到的差异是否来自解码优化？
哪类输入或负载最容易使这一方案失效？

项目结合

准备一个与解码优化直接相关的测量或排障案例。讲清基线、异常指标、被排除的假设和最终判定；没有亲历时，说明会采集哪些数据，不虚构结果。

复习自测

能否脱离笔记解释推测解码为何能加速，接受率由什么决定的关键运算？
能否把文中的数量级例子换成自己的模型或业务参数？
能否指出一种不适用场景，并给出可观测的判定条件？