走完一轮 MTP 投机解码
只跟踪一个固定例子：MTP 提出三个 token，target 接受第一个、拒绝第二个并修正，然后系统提交真实前缀。
顺序 MTP 已经提出 y₁=吃。它预测 y₂ 时能看到哪个上下文？
这轮只回答一个问题
当前真实前缀是 我 喜欢。一轮结束后，哪些 token 会成为真实输出，哪些 KV 可以继续使用？不要先算；点击“下一步”跟着状态变化走一遍。
此时 token 状态和 target KV 都只覆盖 我 喜欢。MTP proposer 接下来会提出三个候选。
顺序 MTP 使用的候选概率是：
q₁(吃)=0.60，条件是我 喜欢；q₂(苹果)=0.50，条件是我 喜欢 吃；q₃(。)=0.70，条件是我 喜欢 吃 苹果。
| 位置 | 候选 | qᵢ(yᵢ) | pᵢ(yᵢ) | 接受概率 | 随机数 uᵢ |
|---|---|---|---|---|---|
| 1 | 吃 | 0.60 | 0.48 | 0.80 | 0.30 |
| 2 | 苹果 | 0.50 | 0.20 | 0.40 | 0.70 |
| 3 | 。 | 0.70 | 0.65 | 0.93 | 尚未使用 |
target 可以沿候选路径一次算出这些 pᵢ。但是 sampler 必须从左到右检查，因为第一个拒绝会改变后面位置的条件前缀。
吃 进入 accepted prefix。现在才能继续检查第二个候选。
苹果 被拒绝。这个位置的完整分布如下：
| token | target p₂ | draft q₂ | 缺口 (p₂-q₂)+ | 修正分布 |
|---|---|---|---|---|
| 苹果 | 0.20 | 0.50 | 0 | 0 |
| 香蕉 | 0.50 | 0.20 | 0.30 | 1 |
| 梨 | 0.30 | 0.30 | 0 | 0 |
因此修正 token 必然是 香蕉。拒绝的 苹果 不可能在 residual 中再次被采到。
y₃=。 原来是根据 我 喜欢 吃 苹果 提出的。现在真实前缀变成了 我 喜欢 吃 香蕉，所以旧的 q₃ 和 p₃ 都不再对应当前条件，不能继续验证。
我 喜欢 吃 香蕉
吃 是 accepted token，香蕉 是 correction token。
我 喜欢 吃
verification 已计算并确认了 吃 的 KV；候选 苹果、。 的 KV 必须丢弃。
香蕉 是从 p₂ 的 residual 采出来的，但它没有作为 verification 的输入 token。普通实现要在下一步处理它，或通过专门的融合/重算路径补出它的 KV。
把整轮压成四条规则
- MTP 先产生候选块和实际使用的
q₁…qγ。 - target 沿候选路径一次得到
p₁…pγ+1，sampler 再从左到右验收。 - 首次拒绝时，从该位置的 residual 采 correction，并立即停止本轮验证。
- 逻辑 token 提交 accepted prefix 与 correction；KV 只保留确实对应真实路径的部分。
y₂ 被拒绝并修正后，是否还能继续验证旧的 y₃？
对照 Leviathan et al., Section 2.3 的 Algorithm 1，只寻找三件事：draft block、首次拒绝和 extra token。然后回到本页，不看步骤，自己说出“吃、苹果、句号、香蕉”各自的去向。任何一步不确定，都可以继续问我。