一句话总结：推测解码让小模型帮大模型「打草稿」已经是标准做法，但草稿模型还得等大模型验证完才能继续。SSD 说：别等了，猜一下验证结果直接往前跑。
推测解码回顾：快在哪，卡在哪
标准推测解码（Speculative Decoding）的核心思路在 2023 年被提出后迅速成为 LLM 推理优化的标配。简单回顾：
核心流程：
- 草稿阶段：用一个小而快的草稿模型（draft model）自回归生成 K 个候选 token
- 验证阶段：将这 K 个 token 一次性喂给大的目标模型（target model），通过一次前向传播并行验证所有位置
- 接受/拒绝：根据概率比较决定接受还是拒绝每个草稿 token，从第一个被拒绝的位置开始重新生成
为什么快：目标模型只需要一次前向传播就能验证 K 个 token，相比逐个生成节省了 K-1 次前向传播。验证和逐 token 生成使用同样的计算资源，但一次处理更多 token。
卡在哪：整个流程是严格串行的——
[草稿: 生成K个token] → [等待] → [验证: 一次前向传播] → [等待] → [草稿: 生成K个token] → ...草稿模型在等验证结果，验证模型在等草稿输出。两者交替执行，任何时刻只有一个在工作。对于部署在同一 GPU 上的场景，这意味着硬件利用率远低于理论上限。
SSD 的核心洞察：预判验证结果
Speculative Speculative Decoding（SSD）的关键思路用一句话概括：草稿模型不等验证结果，而是预判验证结果后直接开始下一轮推测。
具体来说，SSD 引入了一个新的时间重叠机制：
标准推测解码：
[草稿 1] ──────── [验证 1] ──────── [草稿 2] ──────── [验证 2]
SSD：
[草稿 1] ──[草稿 2（预判版）]──[草稿 3（预判版）]──...
[验证 1] ──────────── [验证 2] ──────────在目标模型验证第一批草稿 token 的同时，草稿模型已经假设这些 token 全部被接受，开始生成下一批。当验证结果返回时：
- 如果预判正确（大部分草稿 token 被接受）：下一批草稿直接可用，零等待
- 如果预判错误（某个位置被拒绝）：丢弃该位置之后的所有预判 token，从拒绝点重新开始
这和 CPU 的分支预测（branch prediction）思路如出一辙：预判正确就赚了一个周期，预判错误就付出回滚代价。只要预判正确率足够高（对应推测解码的「接受率」），整体就是净正收益。
算法细节
乐观预判策略
SSD 使用最简单的预判策略——乐观假设所有草稿 token 都会被接受。这基于一个经验观察：好的草稿模型-目标模型配对通常能达到 70-90% 的接受率。
在高接受率下，乐观预判大部分时候是对的。即使偶尔预判失败，回滚的代价也只是丢弃几个草稿 token——草稿模型推理成本很低，白算一些 token 不是大问题。
回滚机制
当验证结果返回后发现位置 i 被拒绝：
- 丢弃位置
i及之后的所有预判 token - 使用验证过程中目标模型在位置
i的采样结果作为正确 token - 从位置
i+1开始重新进入正常的推测-验证循环
并行流水线
SSD 的理想执行形态是一个三阶段流水线：
| 时间片 | 草稿模型 | 目标模型 | 状态管理 |
|---|---|---|---|
| T1 | 生成草稿批次 1 | 空闲 | - |
| T2 | 生成草稿批次 2（预判） | 验证批次 1 | - |
| T3 | 生成草稿批次 3（预判） | 验证批次 2 | 处理批次 1 的结果 |
| T4 | 生成草稿批次 4（预判） | 验证批次 3 | 处理批次 2 的结果，可能回滚 |
从 T2 开始，草稿模型和目标模型就完全并行运行。草稿模型的延迟被完全隐藏在目标模型的验证延迟之下。
数学保证
SSD 不改变输出分布。验证阶段仍然使用标准的推测解码验证算法（基于概率比较的接受/拒绝），预判只是一种调度优化。被接受的 token 序列的概率分布与直接从目标模型采样完全一致。
性能分析
加速上界
设草稿生成 K 个 token 的延迟为 T_d，验证延迟为 T_v，接受率为 α。
标准推测解码的每轮延迟：T_d + T_v
SSD 的每轮延迟：max(T_d, T_v) （理想情况，预判全部正确时）
当 T_d < T_v（草稿模型比目标模型快，通常成立）时，SSD 的理想加速比为：
加速比 = (T_d + T_v) / T_v = 1 + T_d / T_v如果草稿模型延迟是目标模型的 1/5（常见配置），理论加速比为 1.2 倍（相对标准推测解码）。加上标准推测解码本身相对自回归的 3-5 倍加速，SSD 的端到端加速可以达到 4-6 倍。
接受率的影响
接受率 α 直接决定 SSD 的实际收益。下表展示不同接受率下的预期表现：
| 接受率 | 回滚频率 | SSD 相对标准 SD 的加速 | 推荐 |
|---|---|---|---|
| >85% | 极低 | 1.3-1.5x | 强烈推荐 |
| 70-85% | 低 | 1.1-1.3x | 推荐 |
| 50-70% | 中等 | 1.0-1.1x | 边际收益 |
| <50% | 高 | <1.0x（可能变慢） | 不推荐 |
高接受率是 SSD 的生命线。选择草稿模型时必须确保足够高的接受率。
AMD MI300X 上的工程实现
AMD 在 ROCm 博客中公布了 SSD 在 MI300X 上的实现细节，是目前最完整的工程落地参考。
架构设计
MI300X 的实现利用了 AMD 的 HIP（Heterogeneous-Compute Interface for Portability）编程模型，关键设计包括：
- 双流并行：草稿模型和目标模型分配到不同的 HIP 流（stream），通过事件（event）同步
- KV cache 预分配：为预判 token 预分配 KV cache 空间，接受时直接使用，拒绝时标记为无效
- 零拷贝回滚：回滚时不实际删除 KV cache 数据，只修改有效长度指针
关键优化
- 预判深度自适应：根据运行时接受率动态调整预判的批次数量。接受率高时加深预判（预判 3-4 批），接受率低时减少预判（只预判 1 批）
- 异步内存管理：KV cache 的分配和释放在独立的内存管理流中执行，不阻塞计算流
- 批次大小对齐：将草稿批次大小对齐到 MI300X 的 wavefront 大小（64 threads），最大化 SIMD 利用率
实测数据
AMD 公布的数据显示（Llama 3.1 70B 目标模型 + Llama 3.1 8B 草稿模型）：
标准自回归： ~30 tokens/s
标准推测解码 (SD)： ~85 tokens/s (2.8x)
SSD： ~120 tokens/s (4.0x, 相对 SD 1.4x)SSD 相对标准推测解码的额外加速约 40%，与理论预估吻合。
与其他推测解码变体的关系
推测解码自 2023 年提出以来已经衍生出多个变体，SSD 在这个家族中的定位：
| 方法 | 核心改进 | 与 SSD 的关系 |
|---|---|---|
| EAGLE | 用目标模型的隐藏层特征辅助草稿生成 | 提高接受率，与 SSD 互补 |
| EAGLE-3 | 多头并行草稿生成 | 提高接受率 + 草稿多样性 |
| Medusa | 在目标模型上加多个预测头 | 无需独立草稿模型，可与 SSD 结合 |
| PARD | 并行自回归草稿 + 验证 | 思路类似但机制不同 |
| SSD | 草稿-验证异步流水线 | 正交优化，可叠加 |
SSD 的最大优势在于正交性——它不修改草稿模型或验证算法本身，只改变调度方式。这意味着 SSD 可以和任何提高接受率的方法（EAGLE、Medusa 等）组合使用，收益叠加。
实际部署建议
适用场景
- 延迟敏感的交互式应用：聊天、代码补全、实时翻译
- 草稿模型质量好的场景：同系列大小模型配对（如 Llama 70B + 8B）
- GPU 计算资源充足的环境：SSD 需要同时运行草稿和目标模型
不适用场景
- 草稿接受率低：不同系列或质量差距大的模型配对
- 批处理高吞吐：此时推测解码本身的收益就有限
- 资源受限环境：草稿-验证并行需要额外显存
草稿模型选择
草稿模型是 SSD 成败的关键。选择原则：
- 同系列优先：Llama 70B + Llama 8B 优于 Llama 70B + Phi-3
- 知识蒸馏版：专门为推测解码训练的草稿模型效果最好
- 接受率 >70%：低于此阈值 SSD 的收益可忽略
总结
SSD 的贡献在概念上很简洁：标准推测解码中草稿模型有一半时间在空等验证结果，SSD 让它预判结果后继续工作。这个看似简单的改变带来了 30-40% 的额外加速。
更重要的是，SSD 与其他推测解码优化完全正交。随着 EAGLE-3、Medusa 等方法不断提高草稿接受率，SSD 的收益也随之放大——接受率越高，预判正确的概率越大，浪费的计算越少。
对于 LLM 推理优化从业者来说，SSD 的信号很明确：当算法层面的单步优化逼近极限时，调度层面的并行化是下一个突破口。