投机采样（Speculative Decoding）：草案模型、并行验证与加速原理

自回归解码：
□ 每个 token 依赖前一个 token → 严格串行
□ Decode 阶段计算量小（读 KV Cache + 算一个 token）
  → 计算密度低，主要受「显存带宽」限制
□ 大模型的带宽受限 → 单 token 延迟高

算力利用视角：
□ Prefill（处理 prompt）：计算密集，GPU 算力用满
□ Decode（生成 token）：带宽受限，算力利用率 < 10%
  → 大量算力在 Decode 阶段闲置

关键矛盾：
算力闲置 vs 解码串行 → 投机采样用「并行验证」补上

核心流程：
1. 草案模型（小/快）快速生成 γ 个候选 token
   （γ 通常 4-8 个）
2. 大模型一次性对 γ 个候选做「并行 forward」
   → 一次前向同时算 γ 个位置的概率分布
3. 逐 token 对比：大模型的分布决定「接受哪些」
4. 接受 k 个 → 这一次「一步走了 k 步」

关键洞察：
□ γ 个候选的 forward 是「并行」的（矩阵运算）
  → 一个 token 的延迟 ≈ 一次 forward 的延迟（并行批量）
□ 如果草案猜得准（接受率高）→ 有效步长 >> 1
  → 串行步数显著减少

直觉示例：
草案模型猜了 5 个 token：A B C D E
大模型一次 forward，算出这些位置的分布
接受 4 个（A B C D）→ 这一步实际走了 4 步
→ 原本 5 次串行 decode，压缩成 1 次并行 + 1 次修正

循环步骤（每轮）：
1. 草案模型基于「当前 KV Cache + 已生成序列」生成 γ 个候选 token
2. 把 γ 个候选「接在序列后」，大模型一次 forward
   → 得到每个候选位置的真实概率分布
3. 从第一个候选开始逐 token 验证：
   - 大模型采样位置 i 的 token t_i
   - 与草案的候选对比：相等 → 接受；不等 → 在此处打断
4. 如果中途被拒绝 → 用大模型自己的采样结果替换，重置草案上下文
5. 接受 k 个 token → 更新 KV Cache，继续下一轮

注意：
□ 草案模型也用 KV Cache（自己的，通常小得多）
□ 被拒绝的 token 处，草案的后续预测作废（重新草拟）

伪代码示意：
while 未结束:
  draft_tokens = draft_model.generate(seq, γ)
  probs = target_model.forward(seq + draft_tokens)  # 并行
  accept_len = verify(draft_tokens, probs)          # 逐 token 接受
  seq += draft_tokens[:accept_len] + (target_sample if rejected)

拒绝采样（Rejection Sampling）：
□ 草案的分布 q 与大模型的分布 p 不同
□ 接受规则要「校准」：让接受后的最终分布 == 大模型的 p
□ 关键：接受概率要按 p 与 q 的比例调整
  → 草案猜「低概率」的 token 时，被接受的概率也低

正确性定理：
□ 只要接受规则正确（按 q/p 校准），输出分布 == 大模型直接采样
□ 采样参数（temperature 等）要一致
□ 贪心（greedy）解码：接受「草案 token == 大模型 argmax」即保持贪心

工程含义：
□ 投机采样不改「模型能力」，只改「生成速度」
□ 可以安全用于生产（分布不变）
□ 但：自定义采样逻辑时不能乱改接受规则

接受规则示意：
target_prob = p(token)         # 大模型概率
draft_prob  = q(token)         # 草案概率
if draft_token == target_sample: 接受
else if target_prob > draft_prob: 接受（概率 = (p-q)/p）
else: 拒绝（概率 = 1 - q/p）

草案模型方案：
□ 独立小模型：同架构小 10-50x 的模型（如 Llama-70B 配 7B draft）
  → 接受率高，但加载两个模型（显存开销 + 管理复杂）
□ N-gram / 基于检索：用「前缀匹配历史文本」草拟
  → 零显存额外开销，但只在「可预测文本」接受率高
□ 自草拟（Self-Draft）：用大模型自身的浅层/子结构草拟
  → 无需第二个模型

选型权衡：
□ 小模型：通用性最好，接受率最稳
□ N-gram：零成本，适合「对话/代码补全」这类可预测文本
□ 自草拟：无额外显存，但实现复杂

γ（草拟长度）选择：
□ 太短：一次验证的收益小
□ 太长：草案后面容易猜错（接受率下降）→ 一般 4-8

Medusa（多头草拟头）：
□ 在模型「最后一层」加多个「草拟头」（Medusa heads）
□ 每个 head 预测「后第 k 个 token」的分布（并行）
□ 微调 Medusa heads（很小，不动主模型）
□ 优点：无独立草案模型、显存小、垂直集成

EAGLE（无独立模型草拟）：
□ 利用「主干模型的特征」草拟（在隐藏层做草拟）
□ 结构：一个轻量草拟头 + 特征拼接
□ 接受率比独立小模型还高（特征更准）

对比：
□ 独立草案模型：通用、实现简单、双模型管理
□ Medusa/EAGLE：显存省、集成好、接受率更高
  → 但需要额外训练（Medusa heads / EAGLE 模块）

选型场景：
□ 快速部署/通用场景 → 独立草案模型（现成）
□ 显存紧张/追求集成 → Medusa（训练成本低）
□ 追求最高接受率 → EAGLE（需训练草拟模块）

加速公式（理论）：
有效步长 = E[接受数] ≈ γ × 接受率
加速比 ≈ 有效步长（理想情况，忽略草案模型开销）

实测量级（社区报告）：
□ 接受率 0.6-0.8、γ=4 → 加速 2-3x（常见水平）
□ EAGLE/Medusa 类 → 更高（可达 3x+）
□ 依赖场景：代码/结构化文本接受率高，随机文本接受率低

影响加速的因素：
□ 草案模型质量：越准加速越大
□ 场景可预测性：代码补全 > 自由对话
□ γ 与接受率的匹配：γ 超草案能力 → 加速打折
□ 硬件：草案模型也要占算力，预算紧张时加速缩水

加速瓶颈：
□ 草案模型本身的 forward 时间（草拟 5 个 token 也要算）
□ 大模型 γ 个候选的 forward（比单 token 慢一点）
→ 净加速 = 减少的串行步数 - 草拟/验证的开销

与连续批处理集成（vLLM）：
□ 投机解码要融入 scheduler：草案模型与大模型共用资源
□ 批内多请求各自草拟 → 大模型「批量验证多个请求的候选」
  → 并行验证的批量效应进一步提升吞吐

采样参数一致性：
□ temperature/top_p 等参数要在草案与大模型间一致
□ 草案的采样分布要与验证规则匹配（否则拒绝采样失真）

KV Cache 处理：
□ 草案模型用自己的小 KV Cache
□ 大模型在验证时扩展 γ 个位置的 KV Cache
□ 被拒绝位置的 KV Cache 要「截断/回滚」

易集成点：
□ 贪心解码：实现最简单（比较 argmax）
□ 采样解码：拒绝采样规则要精确实现

调度示意：
请求 1 草案 5 候选 + 请求 2 草案 5 候选
→ 大模型一次前向，同时验证两个请求的候选
→ 批量并行验证：吞吐更高

局限性：
□ 随机/高熵文本：草案猜不准 → 接受率低 → 加速接近 0
□ 草案模型的显存/算力成本：显存紧张时上不起
□ 长上下文场景：草案模型的 KV Cache 也随上下文增长

踩坑：
□ γ 设得太大：草案后段全错，浪费验证算力
□ 采样参数不一致：分布被破坏（看似加速实则改变输出）
□ 把「有效步长」当「净加速」：忘了草拟开销
□ 冷启动/首 token：投机采样主要加速 decode，不加速 prefill

适用判断：
□ 高吞吐、可预测文本（代码/补全/结构化）→ 强适用
□ 低延迟交互（首 token 敏感）→ 收益有限
□ 显存已满 → 考虑 Medusa/自草拟（省显存方案）

评估指标：
□ 接受率（草案被接受的比例）
□ 有效步长（每轮实际接受的 token 数）
□ 净加速（端到端 tokens/sec，含草拟开销）
→ 只看接受率不够，要端到端测净加速