SPEC-RL: Accelerating On-Policy RL with Speculative Rollouts

3.2 Worked example: 一道数学题在 epoch 5 → 6 的演化

Prompt: x = "Solve x²=9, find y if y=x+0."。Epoch 5 cache 里的 y^prev 是 8 个 token: ["Let","x","=","3",",","so","y²","=9"],每个位置上 π_prev 的概率分别是 [0.45, 0.78, 0.91, 0.62, 0.55, 0.48, 0.30, 0.40]。

Epoch 6 时 πθ 微调过,在同样上下文下给出概率 p^curr = [0.50, 0.80, 0.92, 0.65, 0.58, 0.20, 0.31, 0.42]。注意位置 6 的 "so" 概率从 0.48 掉到 0.20——πθ 现在更倾向于直接说 "thus"。取 ℓ = e^0.5 ≈ 1.649,逐位算 α̃:

verified prefix = 5 个 token。从位置 6 起 πθ 接管自回归生成,可能给出 ["thus","y²","=9","…"]。最终拼起来的 y^curr:5 个旧 token + ~k 个新 token。如果 prev 长度是 800、reused 600、新生成 200,那就只解码了 200 个 token,加上 1 次 prefill 跑 800 token——prefill 在 GPU 上比逐 token decode 高效 1–2 个数量级,这就是加速的物理来源。

3.3 反向论证: 如果省掉 verify 直接拼接会怎样?

就成了 "Random Reuse" 消融——论文 Table 2 给出的对照: token 反而更多 (304.5M vs 182.7M),但 average accuracy 从 37.3 掉到 31.4。原因是无验证地拼接相当于把上一轮 πprev 的 sampling 噪声直接注入当前的训练数据,policy gradient 用错了 logπ,KL 爆炸,训练偏移。这条消融非常重要——它证明 "speculative verify 这一步" 不是装饰,是把"复用"和"on-policy"调和起来的关键。

4 · Lenience 参数 ℓ 的物理意义

ℓ 是 SPEC-RL 唯一新加的超参,直接控制"宁可激进复用还是宁可保 on-policy":

诊断指标 (Figure 5): 当 ℓ < e^0.5 时,clip fraction 稳定 < 0.0025、KL < 0.1、entropy 与 baseline 几乎重合;一旦 ℓ ≥ e^1.0 这三个量同时炸,训练失稳。这给了一个非常实用的经验:把 KL 当 ℓ 的早期警报。

反向论证: 为什么不能直接把 ℓ 设成 ∞?因为这等价于强制把 πprev 的整条 trajectory 当作 πcurr 的样本——用错了 log-prob,policy gradient 的方向直接错了。Table 3 里 ℓ→∞ 的 14.86× 速度看着很美,但 acc 29.2 比不训还差。这是"speedup ≠ benefit"的典型反例。

5 · 系统实现

5.1 Cache 模块

每个 prompt 维护一个最新 rollout(包括 token 序列和当时的 token-level log-prob)。"最新"意味着每个 epoch 把生成的 y^curr 写回去,覆盖前一个 y^prev。这一点很关键——消融里 "Delayed Reuse"(用 epoch t−2 而非 t−1 的轨迹)直接把 speedup 从 2.29× 降到 1.44×,因为 policy gap 越大,reuse rate 越低。

5.2 批量 verify

实现层面,作者把整个 batch 的 prompt + 对应 cached prefix 拼成一个 padded batch,左 pad 对齐,送进 vLLM 一次 forward 拿到 logits,所有 prompt 并行 verify。这避免了"每条 prompt 单独验证"导致的 GPU 利用率塌陷。完成 verify 后,只对那些"还要继续生成"的 prompt 再发起 vLLM continuation request。

5.3 Worked example: batch 维度的吞吐

设 batch=1024,平均 y^prev 长度 = 800,平均 reused = 600,新生成 = 200。

• baseline: 1024 × 800 token 的 autoregressive decode,GPU 利用率受 KV cache & batch size 限制,大约 N 秒。
• SPEC-RL Stage 1: 1024 × 800 的 prefill,在 H100 上几乎 free——FLOPs 跟 decode 同量级但无 sequential dependency,实测占用通常 < 0.1N。
• SPEC-RL Stage 2: 1024 × 200 的 decode,大约 0.25N。
• 合计: ~0.35N,~2.85× speedup,与论文 DAPO 的 2.88× 实测吻合。

6 · 公式推导与数值敏感性

原版 SD 的接受概率 (Leviathan et al. 2023):

SPEC-RL 把 (p, q) 替换成 (π_prev, π_curr) 并加入 lenience:

物理直觉: ratio = π_curr/π_prev 衡量"在新 policy 眼里这个 token 还有多自然"。当两个 policy 几乎一样时 ratio ≈ 1,token 几乎都被接受;当 policy 在某个位置剧烈分歧时 ratio ≪ 1,大概率拒绝。乘以 ℓ 相当于给 ratio 一个全局放大,鼓励"勉强还行的 token 也接受"。

数值敏感性 (固定 ratio = 0.5,看 ℓ 变化):

关键观察:对 ratio = 0.5 这种"中等分歧"的 token,ℓ 从 1 涨到 2 就把接受率从 50% 拉到 100%——非线性放大。这也是为什么 ℓ = e^0.5 ≈ 1.65 已经显著改善 reuse rate。

反向: 当 ratio > 1/ℓ 时永远 accept。 也就是只要新 policy 在该 token 的概率不比旧 policy 低太多,就直接接受。具体边界: ℓ = e^0.5 ⇒ 只要 π_curr ≥ 0.607 · π_prev 就 100% accept。

7 · 实验关键结果

7.1 主表 (Table 1) 摘录

读表: 9 个组合全部加速 1.94×–2.88×,平均 2.31×。准确率没掉,常常还有 +1~2 分提升 (尤其 OOD: Qwen3-8B GRPO 的 IFEval 从 41.2 → 47.7,+6.5)。这与"reuse old prefix → 训练数据多样性下降"的直觉相反——Figure 6 给出解释: 早期 epoch 的 prefix 比晚期更多样(那时 policy 还没收敛),复用早期 prefix 反而保住了 trajectory diversity。

7.2 关键消融 (Table 2)

这两个消融在我看是论文最重要的——它们分别证伪了两种"看起来更简单"的选择: 不验证(直接拼接)、不及时更新 cache(用更旧的 trajectory)。两条都比 SPEC-RL 差。

7.3 训练动力学 (Figure 4-5)

• verified prefix length 在训练初期下降(policy 大步更新)、中期回升(policy 趋稳)。这是个 U 形曲线,意味着一个 fixed ℓ 在不同训练阶段的实际 reuse rate 是变化的——adaptive ℓ scheduling 是显然的后续。
• ℓ < e^0.5 时 KL/entropy/clip ratio 都和 baseline 几乎重合; ℓ ≥ e^1.0 时三者同时飙升,训练就开始崩。

8 · 与同类工作对比

纵观三篇:

• NeMo-RL EAGLE-3 走"通用 SD 工程化"路线——花最大力气把 draft model 维护起来,获得理论上最干净的 lossless 加速。代价是工程复杂度。
• ReSpec 在 NeMo-RL 同期但 focus 在"训练 draft 时怎么和 RL 兼容"的细节上,介于 SPEC-RL 和 NeMo-RL 之间。
• SPEC-RL 走"系统极简"路线——不要 draft model、不要 suffix tree、不要重训任何东西,只要"上一轮的自己"就行了。
• DAS / RhymeRL 走"信息抽取最大化"路线——挖掘所有 historical responses 里能匹配的 token n-gram。理论上 reuse rate 上限更高,但工程量大。

四者并不严格冲突:SPEC-RL 的"上一 epoch 整条 cache" 可以看作 DAS 的特例 (匹配整条 history, 不分 token);反过来 SPEC-RL 也可以叠加 EAGLE-3 做"小段填充"。论文没做这种组合实验,但这是显然的后续。

9 · 局限 / 个人 take / 待验证问题

• 第一个 epoch 没加速。cache 是空的,得先跑一遍 baseline rollout 才能开始 SD。如果训练只跑 2-3 个 epoch,SPEC-RL 的均摊收益打折扣。论文实验都是几十个 epoch,这是隐含前提。
• 多轮 / agentic / 多模态没覆盖。论文明确说只处理 single-turn reasoning。当 trajectory 包括 tool call、外部环境观察时,"上一 epoch 的相同 prompt 仍能匹配同一条 trajectory" 这个假设不成立——环境是 stochastic 的。
• fixed ℓ 在动力学上不是最优。Figure 4c 那个 U 形曲线说明 reuse rate 自身在变,如果 ℓ 自适应跟着调(比如根据 KL 反馈),理论上可以再榨一点速度而不掉点。
• OOD 涨点机制存疑。论文的解释("早期 epoch prefix 更多样所以保 diversity")合理但偏故事化。需要更细的对照才能确认到底是 (a) regularization 效果 (b) implicit replay (c) 还是单纯 lucky seed。
• cache 占用。每个 prompt 存一条 ~4k token 的轨迹和 token-level log-prob。1024 batch × 4096 tok × float32 × 几个 prompt set 加起来大约几个 GB,不致命但也不可忽略。
• 个人 take: 这是这个系列里最"道法自然"的一篇——idea 几乎是显然的,但显然的事情有人认真做出来才是工程贡献。它揭示的事实(连续 epoch 50–70% token overlap)更值得关注:这意味着 RLVR 训练系统里大量算力在 deterministic 重生成,真正有信息的探索只发生在 30–50% 的尾部 token。

10 · 记忆点