11.4 收益边界与限制：接受率、精度风险与调度复杂度

11.4.1 每轮输出为什么是 1+α+…+α^γ

令 K 为接受的 Draft token 数，草稿长度为 γ，没有 EOS / 长度截断时还输出一个修正或 bonus token，所以输出数 N=K+1：

E[N] = 1 + Σ_i=1..γ Pr(K≥i)
若每个位置的条件接受概率都是 α：
E[N] = Σ_i=0..γ α^i = (1−α^(γ+1))/(1−α)
α=1 时 E[N]=γ+1

这是条件接受率恒定的简化模型，无需假定每个位置无条件独立。真实 α 随位置、请求与内容变化，直接统计 Pr(K≥i) 比代入总体接受率更可靠。

条件接受率与分布重叠有关：单位置 α=Σ_v min(p(v),q(v))=1−TV(p,q)。Draft 参数更少不一定更划算：提议耗时和 Target 分布的匹配程度必须一起考虑。投机解码的接受率与期望收益

11.4.2 加速需要每个有效 token 的成本下降

设普通 Target 单 token Decode 为 T₁，一轮 Draft 总耗时为 Dγ，验证耗时为 Vγ，验收、状态处理等额外耗时为 C：

投机每有效 token 的平均成本 ≈ (Dγ + Vγ + C) / E[N]
Speedup ≈ E[N] × T₁ / (Dγ + Vγ + C)
有收益条件：Dγ + Vγ + C < E[N] × T₁

Vγ 不等于单 token 前向耗时：多个候选能摊销权重读取并提高 GEMM 利用率，但也增加算术、Attention、KV 读写和 logits 处理。这也是「一次验证」不等于「只付一次单 token 成本」。

教学成本例：T₁=10 ms、γ=4、α=0.8，若 Dγ=4 ms、Vγ=14 ms、C=1 ms，则约 3.36×10/19=1.77×；若 Draft 总成本涨到 25 ms，加速比约 33.6/40=0.84×，接受率相同仍会变慢。

11.4.3 Serving 中怎么调 γ

小 batch Decode 原本利用率低，投机可能把多次权重读取合到一次验证；高并发已能复用权重时，验证候选会与其他请求争计算和 KV，单请求 TPOT 变好也可能降低整体吞吐。

按请求的近期接受长度、候选位置的存活概率和验证耗时调整 γ，而不是固定越大越好。监控至少包括 Draft 耗时、验证耗时、每轮实际输出、接受长度直方图、临时 KV、TPOT / tail latency 与负载下吞吐。只有同时计算分子和分母，才能判断方案有效。

量化和投机可以组合，但收益不能直接相乘：量化改变验证成本，Draft 量化可能改变接受率，KV 量化影响验证与回滚路径。应分别测「基线、仅量化、仅投机、组合」四组，并保持质量与 workload 条件一致。

11.4.4 代码 vs 开放对话：把经验变成待验证假设

代码经常有重复标识符、模板和可复用片段，可能同时有利于文本匹配和能力匹配的 Draft；开放对话的表达更自由，重复片段少时 Lookup 可能很少提出有效候选。但 代码不保证高接受率，对话不保证低接受率：新算法代码可能难猜，模板客服对话反而容易复用。

报告时同时给出 提议覆盖率与Draft 接受率。如果只有少量步骤能提出候选，即使这些候选接受率很高，对整体请求的收益也可能有限。

11.4.5 量化叠加：先明确无损的参照模型

只量化 Draft，在使用其实际 q 并精确验收时，理论上仍保持原 Target 分布；主要风险是接受率下降或提议计算路径变化。量化 Target 后，精确投机保持的是 量化 Target 分布，不会纠正它相对 BF16 的质量损失。KV 量化也会改变 Target 数值输出，应单独验证长上下文质量。

采用近似验收、错误 scale、不同位置偏移或不一致的采样处理时，原有分布证明不再适用。浮点运算与不同 batch shape 还可能造成数值差异；同一随机种子的输出逐 token 不同，不能单凭这一点证明随机采样有偏。

11.4.6 Continuous Batching：给候选预算，按实际进度提交

Scheduler 需要预留候选验证的 token / KV 预算，而一轮每个请求接受长度不同：请求 A 接受 4 个，B 接受 0 个，下一轮已计算长度和待计算边界 token 也不同。不能把所有请求统一推进 γ 个位置。

调度要处理 验证 batch 变长、临时 KV 预留、部分提交、回滚、EOS、抢占与 Prefix 共享；候选树还需要路径重排。把 γ 调大可能改善单请求 TPOT，却增加其他请求等待和 P99。分别测低 QPS 延迟与高 QPS 吞吐，必要时按负载限制投机预算或回退普通 Decode。

11.4.7 KV 状态：验证过不等于可以提交

候选前缀和正式前缀必须区分。Target 验证会生成所有候选位置的 KV，但拒绝后的 KV 不能进入下一轮 Attention。

正式前缀长度 n；候选 [a,b,c,d]
Target 验证后：临时拥有候选的 KV 与对应 logits
接受 a,b，拒绝 c，修正 token 为 e
逻辑输出：原前缀 + [a,b,e]
Target KV：仅保留原前缀 + [a,b] 的有效候选状态
待计算 token：e（本轮并未把 e 输入 Target，所以还没有它的 KV）
下一轮：先计算 / 携带 e 的状态，再验证新的候选

一轮可以输出 k+1 个 token，却只新增 k 个可直接保留的候选 KV。全部接受时，bonus token 同样没有在本轮输入中，其 KV 也要后续补算。实际实现可能保留一个尚未计算的边界 token，始终用 已输出 token 数与已计算 KV 长度两项进度描述，避免 off-by-one。

独立 Draft 的 KV 也要截断到接受前缀，并摄入修正 / bonus token，才能从正确上下文继续提议。分页管理可以只改有效长度并回收不再引用的块；末尾共用 block 中的无效槽位不能再被读取，共享 Prefix block 也不能误释放。