长程强化学习的隐性杀手：训练与评分引擎的数值漂移
大模型长程强化学习中最隐蔽的Bug是采样与评分引擎间的数值不一致，根源常在Tokenization错位。
本文聚焦大模型强化学习（RL）工程实践中一个被低估的核心挑战：当负责生成轨迹（rollout）的采样引擎与负责计算奖励/梯度的评分引擎，对同一批token分配的概率出现分歧时，训练信号会发生隐性漂移。这种漂移不会立即导致训练崩溃，而是随时间推移侵蚀信号可信度，在长程RL任务中尤为致命。造成不一致的来源包括：tokenization逻辑的微小差异、浮点精度与算子实现的不同，以及推理引擎为提速引入的量化和算子融合等优化。文章指出，确保两套引擎共享完全相同的tokenizer配置，并建立定期验证机制，是保证训练正确性的关键工程实践。
被忽视的数值 Bug
在大模型强化学习（RL）的工程实践中，最难缠的问题往往不是算法本身，而是隐藏在底层的数值一致性问题。一条来自 Twitter 的分享点破了这个痛点：长程强化学习（Long-horizon RL）中最棘手的 bug 都是数值型的。当负责生成 rollout（轨迹采样）的引擎与负责打分的引擎，对同一批 token 分配的概率不再一致时，训练就会悄然发生漂移（drift）。
这种漂移不会立刻让训练崩溃，而是像慢性病一样逐渐侵蚀训练信号的可信度，最终导致模型行为偏离预期。对于需要在长序列上进行奖励优化的任务而言，这类问题尤其致命。
为什么会出现概率不一致
在典型的 RLHF 或 RL 训练流水线中，通常存在两套（甚至更多）执行路径：一套是推理/采样引擎，负责高效地生成模型输出的 rollout；另一套是训练/评分引擎，负责对这些输出计算 log 概率、优势函数或奖励。
理想情况下，同样的 token 序列输入这两套引擎，应该得到完全相同的概率分布。但现实中，两者可能在以下环节产生分歧：
- Tokenization（分词）差异：采样端与评分端使用的分词逻辑若不完全对齐，同一段文本可能被切分成不同的 token 序列，导致概率对不上。
- 数值精度差异：不同引擎在浮点计算、kernel 实现、批处理方式上的细微差别，会在长序列上累积成显著误差。
- 推理优化带来的偏差：采样引擎为了速度往往采用各种优化（如量化、算子融合），这些优化可能改变输出概率的精确值。
在短序列任务中，这些微小差异可能被容忍；但在长程 RL 中，误差会沿着时间维度不断放大，让训练信号失真。
这一问题在使用 vLLM、TensorRT-LLM 等专用推理引擎做 rollout、再用 PyTorch/DeepSpeed 做训练的异构架构中尤为突出。以 PPO（近端策略优化）为例，算法需要计算「旧策略概率」与「新策略概率」的比值（importance ratio），两套引擎的任何微小分歧都会直接污染这个比值。当 importance ratio 出现系统性偏差时，PPO 的 clip 机制会错误地截断正常的梯度更新，或者放行本应被压制的异常更新，最终表现为训练曲线莫名震荡或奖励停滞。KV cache 的复用策略也可能引入隐患：缓存的中间激活值在批大小或序列拼接方式改变时，可能导致相同输入得到略微不同的 logit 输出，这在单次推理中几乎不可察觉，但在长程 RL 的多轮迭代中会持续积累。
对齐 Tokenization 是关键一环
分享者给出的解决方向很明确：让两套引擎的 tokenization 保持一致，是保证训练信号可信的核心。
这看似是个工程细节，实则关系到整个 RL 训练的正确性。如果生成 rollout 时用的是一种分词，而评分时 token 边界发生了变化，那么模型看到的"自己的输出"与实际打分对象就产生了错位。基于这种错位算出的梯度，本质上是在优化一个错误的目标。
对齐 tokenization 意味着：
- 确保采样端与评分端共享完全相同的 tokenizer 版本与配置；
- 在特殊 token、边界处理、编码/解码往返上保持严格一致；
- 建立验证机制，定期比对两端对相同输入的 token 化结果与概率输出。
Tokenization 的「往返一致性」（round-trip consistency）是一个常被忽略的验证维度：将文本编码为 token ID 后再解码回文本，得到的字符串未必与原始输入完全相同。当采样端生成的 token 序列经过解码再重新编码（例如用于存储、传输或 prompt 拼接时），可能产生不同的 token 边界，尤其在中文、日文、代码等场景下，同一语义单元可能有多种合法的分词方式。特殊 token（如 <|im_start|>、<eos>）的处理方式也因框架而异，部分推理引擎会自动剥离或追加这些 token，而训练框架侧若未做相同处理，就会引入长度错位。建议在流水线中设置断言检查：对任意一条 rollout，验证「采样端输入 token ID → 解码 → 评分端重编码」前后的 token 序列完全一致，将这一检查作为数据流水线的标准健康检查项。
给 RL 工程实践的启示
这条经验对正在搭建大模型 RL 系统的团队有直接的参考价值。当训练出现难以解释的性能退化时，除了怀疑算法超参，更应优先排查采样与评分引擎之间的数值一致性。
一个实用的诊断方法是：取一批固定的 token 序列，分别送入两套引擎，对比它们输出的 per-token 概率。如果发现系统性偏差，问题往往就出在 tokenization 或数值实现层面，而非算法逻辑。
在追求训练效率、大量使用异构推理引擎的今天，保持数据在不同引擎间流转时的"数值可信度"，正成为长程 RL 落地的隐性门槛。谁能把这些底层的一致性问题处理干净，谁的训练信号就更可靠。
「数值一致性测试」可以系统化为一套回归测试套件，而不仅仅是临时的诊断手段。具体做法包括：构建一个包含边界案例（超长序列、含特殊字符的输出、多语言混合文本）的固定测试集，在每次引擎版本升级或配置变更后自动运行，计算两端 per-token log 概率的最大绝对误差和 KL 散度，设定容忍阈值（例如 KL < 1e-4）并在超出时阻断训练。这种「数值 CI/CD」的思路已在部分头部实验室的 RL 基础设施中付诸实践，本质上是将隐性的数值风险转化为可量化、可监控的工程指标。对于使用 FSDP 或张量并行等分布式训练策略的团队，还需额外验证不同并行度下同一序列的 logit 输出是否位确定性（deterministic），因为通信算子的浮点累加顺序可能因并行配置不同而改变。
