如果你在做大模型后训练、又被 RL/蒸馏流程的训练速度卡住，这篇 arXiv 论文（AsyncOPD）值得停下来看一眼。它研究的是一个正在变热的训练范式 on-policy distillation（OPD，在线策略蒸馏），并第一次系统地回答了一个工程上绕不开的问题：当你为了提速把它改成异步之后，"陈旧"的数据到底会带来多大伤害。 先把背景接上。所谓 OPD，是让学生模型先用当前自己的策略去生成 rollout（即模型自己跑出来的样本/轨迹），再由一个更强的 teacher 模型给出反馈来指导学生更新。它和强化学习（RL）共享同一个老大难的系统瓶颈：对推理类（reasoning）工作负载来说，光是生成 rollout 这一步就可能占掉训练的大部分时间，GPU 在等采样、利用率上不去。 业界对付这个瓶颈的常规思路是异步流水线——把"生成 rollout"和"用 rollout 更新参数"两件事解耦，让它们并行跑，不必一步一等。代价是：当学生权重已经更新了几步，手里那批 rollout 还是更早版本策略产出的，于是出现 stale-policy data（陈旧策略数据）。异步 RL 里 stale 数据已经被研究过不少，但作者指出，它在 OPD 场景下的影响一直没被认真研究透——而 OPD 有自己的特殊性：teacher 反馈是通过局部 KL 损失实现的，且存全量词表的 teacher logits 代价太高，实践中只能用有限的 teacher-score 缓存（finite teacher-score caches）。这正是这篇工作锁定的现实设定。 第一个核心发现是：KL 的方向会改变陈旧数据的问题性质。teacher 加权的前向 KL（forward KL）对 stale rollout 更鲁棒；而 student 加权的反向 KL（reverse KL）则很脆弱，陈旧数据一来就容易出问题。换句话说，你选哪个方向的 KL 散度作训练目标，直接决定了异步带来的陈旧性会不会反噬你。 第二，针对脆弱的反向 KL 情形，作者比较了"照搬异步 RL 里那套稳定化方法"和一个更简单的 OPD 专属做法：在 learner（更新）端，用当前学生重新计算一次反向 KL 信号，而不是直接信任陈旧 rollout 上算出来的旧信号。结果是这个更朴素的重算办法并不输给那些从异步 RL 移植过来的复杂方法——这是个对工程友好的结论：不必引入额外机制，回到 OPD 自身的结构去修。此外，有限的 teacher-score 缓存会给稀疏/采样式的反向 KL 估计带来偏差-方差权衡，作者据此倾向于多样本蒙特卡洛（Monte Carlo）式的估计来缓解。 落到收益上：作者报告其异步流水线相比严格同步训练取得了约 1.6 到 3.8 倍的训练吞吐提升，同时保持精度相当，并已开源实现。对正在搭 post-training pipeline、尤其要跑长推理任务的团队，这意味着一条可借鉴的提速路径——前提是 KL 方向选对、并在 learner 端重算信号。 诚实的保留：这是 v1 预印本、单一团队的工作，吞吐区间（1.6–3.8×）会随任务和并发设置波动，"精度相当"具体到哪些基准、与哪些 baseline 比，需读正文核对；本摘要层面也未给出绝对的精度数值。结论主要针对"teacher 反馈以局部 KL 损失实现、缓存有限"这一设定，迁移到其它 OPD 变体时要谨慎。