NgramRL：用Rollout历史加速RL后训练的推测解码新方案

强化学习后训练让大模型推理能力大幅提升，但代价也相当沉重：自回归 rollout 生成可以占到整个训练时间的 70% 以上。围绕这一瓶颈，NgramRL 提出了一种利用近期 rollout 历史构建 n-gram 草稿器的思路，在不引入辅助模型的前提下显著提升解码吞吐。

推测解码为何难以直接搬进 RL 训练

现有推测解码在推理场景表现不错，放到 RL 后训练里却处处掣肘。基于模型的草稿器会占用本就紧张的 GPU 显存，更麻烦的是 policy 在训练中持续演化，草稿模型往往很快与目标模型失配。另一类无模型方法虽然轻量，却没有显式利用跨训练 epoch 的重复性——而 RL 训练恰恰是同一批 prompt 被反复 roll out 的过程。

一个被忽视的草稿源

论文的关键观察很直白：同一 prompt 近期的 rollout 本身就是高质量、且会自我更新的草稿来源。上一轮模型自己生成的延续，往往和这一轮高度相似。与其训练一个草稿模型去猜，不如直接把这部分历史用起来。这也是 NgramRL 与 SuffixDecoding、prompt-lookup decoding 等同类方法的根本分野：后者主要依赖 prompt 或后缀匹配，而没有把逐轮更新纳入设计。

推测解码（speculative decoding） 是一种无损加速解码的通用框架：用一个更轻量的"草稿"来源先连续猜出若干 token，再让目标大模型一次性并行验证这些猜测，接受前缀匹配的部分、拒绝首个不匹配处之后的 token。由于验证是并行前向，且被接受的 token 与目标模型自身采样结果分布一致，推测解码在理论上不改变输出分布，只减少目标模型的前向次数。草稿来源可以是小模型（基于模型的方法），也可以是基于文本匹配的无模型方法（如 prompt-lookup、SuffixDecoding）。加速比主要取决于"平均接受长度"，即每次目标前向能提交多少 token，而这又高度依赖草稿与目标分布的一致程度。

自回归 rollout 指 RL 后训练中让 policy 模型逐 token 生成完整轨迹的过程。与推理服务的单次请求不同，RL 训练要在每个 epoch 对同一批 prompt 反复采样多条轨迹用于计算优势与梯度，因此 rollout 是高频、重复且体量巨大的解码负载。这也是为什么 rollout 能占到训练时间七成以上——它是训练循环里最纯粹的生成环节，且无法像前向/反向那样被批处理摊薄。

SuffixDecoding 与 prompt-lookup decoding 都属于无模型推测解码：前者维护一个动态后缀树，用当前生成文本的最长后缀去匹配历史中出现过的续写；后者则直接在 prompt 内部做 n-gram 匹配，把 prompt 中已出现的片段当作草稿。两者的共同点是草稿源为静态或半静态文本，不感知训练过程中 policy 分布的变化。NgramRL 的差异在于把草稿源换成"近期 rollout 历史"并随 epoch 滚动更新，使其草稿分布能跟随 policy 演化，这也是它能在热缓存下取得更高接受长度的结构性原因。

NgramRL 的机制设计

NgramRL 的核心是按 prompt 构建 n-gram 草稿器，草稿来源限定为有界的近期 rollout 历史。这一设计带来几个直接好处：不需要辅助模型，不需要草稿器训练，也不需要在 GPU 上常驻草稿器状态。目标模型的验证环节照常执行，因此 rollout 分布得以保持，不会因为加速而引入分布偏移。

自适应 fan-out 预取

CPU 侧的缓存查找和调度会吃掉不少收益，论文为此引入自适应 fan-out 预取器，预测可能的验证结果 (j, b)——即被接受的草稿长度 j 与目标模型补出的 token b。因果预算分配器把预取集中在高概率结果上，未被覆盖的结果回退到顺序查找，且不影响已提交的 token。这一层工程优化，是纸面指标转化为真实吞吐的关键。

Fan-out 在此指一次缓存查找同时取出多个候选续写分支的数量。n-gram 草稿器在 CPU 侧查找时，若只顺序试探单条路径，一旦首个候选被目标模型拒绝，就要重新发起查找，CPU 与 GPU 之间的往返延迟会抵消加速收益。自适应 fan-out 预取器根据历史统计预测最可能出现的验证结果 (j, b)，提前并行取出多个候选放入缓冲区；因果预算分配器则在有限预算下把资源倾斜给高概率结果，保证预取不违反因果性（即不依赖尚未生成的 token），未命中时安全回退到顺序查找。这类 CPU-GPU overlap 工程是把理论接受长度转化为端到端吞吐的必要环节。

实测表现与数据解读

在两个模型家族、三类推理与结构化生成负载上，NgramRL 在热缓存场景下每次目标模型前向可提交 3.60–7.77 个 token，比 SuffixDecoding 最多高出 1.99 倍，比 prompt-lookup decoding 高出 7.0 倍。这个量级说明它并非边际优化，而是对 rollout 阶段效率的结构性改善。

在 Spider 结构化生成任务上，预取器在候选预算为 16 时覆盖了 Qwen3-8B 96.6% 的结果，实测 rollout 吞吐相比同步版 NgramRL 提升 1.38 倍，已逼近 1.40 倍的 overlap 上限。从这个数字看，剩余优化空间主要在于覆盖率的最后一小段，而不是整体架构的重构。

需要留意的是，3.60–7.77 的接受长度是在热缓存条件下取得的，冷启动或 prompt 历史稀疏时收益预计会缩水；论文的对比基线也集中在无模型推测解码方法，与基于模型的草稿器方案缺乏横向对照。对于关注 RL 训练成本的团队来说，NgramRL 的吸引力在于零额外显存与零草稿器训练，代价则是需要维护按 prompt 组织的 rollout 历史缓存，工程复杂度转移到了数据管线一侧。

热缓存（warm cache） 指草稿器已经积累了足够多的同 prompt 近期 rollout 历史、n-gram 命中率处于稳定高位的情形。RL 训练天然会产生热缓存：同一 prompt 在每个 epoch 被反复 roll out，历史迅速填满。冷启动阶段或 prompt 集合频繁变化时，草稿历史稀疏、命中率下降，接受长度会明显缩水。因此论文报告的 3.60–7.77 接受长度应理解为训练中后期的稳态指标，而非全流程平均值。

Spider 是跨库 Text-to-SQL 基准，其输出具有高度结构化、模板重复度高的特点，n-gram 命中率天然占优，这也是该任务上预取覆盖率达到 96.6% 的原因。overlap 上限 指 CPU 侧预取与 GPU 侧验证完全重叠时所能达到的吞吐理论上界，1.38 倍逼近 1.40 倍说明剩余瓶颈已不在预取调度，而在覆盖率与缓存命中本身。

对 RL 后训练工程的意义

rollout 占训练时间七成以上，意味着任何 rollout 侧的加速都会被训练总时长近乎等比例放大。NgramRL 把"训练历史即草稿"这一直觉做成了可落地的系统，且验证环节保证分布不变，属于低风险改造。对结构化生成这类重复度高的任务，收益尤其可观；而对开放式、低重复的生成场景，n-gram 命中率能否维持仍有待更多任务验证。