如果你问我，在 RL 训练系统里最容易藏雷的地方是哪里，我不会先说分布式采样、内存泄漏或者梯度过大，而是“训练和 rollout 在数值上差了最后几个 bit”。尤其是当训练侧跑在 RL-Kernel 这类自研内核上，环境侧跑在 vime 这类模拟执行环境上，底层又是 AMD 平台时，CPU 与 GPU、编译选项、数学库乃至线程调度，任何一环没对齐，都会让 rollout 产出的轨迹和训练端重算出的分母出现肉眼看不见却又致命的偏差。我见过太多人把学习曲线突然崩掉归因于探索噪声，最后定位到“训练侧 PPO 更新用的一批 advantage 和 rollout 侧当时计算的那批在 float32 的尾部有 1 bit 不同”。
这篇文章想聊的就是：怎么在 AMD 平台上，通过 RL-Kernel 与 vime 的组合，把训练与 rollout 做成 Bitwise 一致。适合正在搭 RL 训练基础设施的工程师、被复现性问题折磨的算法研究员，以及所有不想再被“玄学随机性”坑一愣的人。
1. 为什么“Bitwise 一致”，是 RL 工程的隐形地基
1.1 一次训练事故：一切正常但曲线像刀切一样崩
去年我在一套 AMD EPYC + Radeon ROCm 的机器上跑 PPO，算法组反馈说训练到 20k 步左右，loss 会突然往上跳一截，然后长时间不恢复。最开始怀疑是 reward scaling 或 GAE lambda 的问题，但把超参来回扫了几遍都没有改善。后来我们把 rollout 端的 transition 和训练端重算出来的 transition 做了逐字节对比，发现 action 和 reward 完全一致，obs 也一致，唯独 advantage 的中间变量——价值网络预测的 bootstrap value——在 float32 的末位有细微差异。
这个差异很小，换算成浮点相对误差可能只有 1e-7 级别，但 PPO 的 clip 操作是分段线性的，只要 value 差异跨过一个阈值，同样一组样本在训练端算出的 ratio 就和 rollout 端当时记录的对不上。几千步的偏差累积下来，policy loss 曲线就出现“刀切”一样的突变。这不是偶发，只要训练侧和 rollout 侧不共享同一条数值路径，这种问题迟早会出现。
1.2 不一致从哪里来：浮点数的“非结合性”被低估了
浮点数不是数学上的实数。(a + b) + c和a + (b + c)在 float32 下可能不相等，因为每一步加法都会对阶、舍入。更麻烦的是，编译器喜欢把乘加融合成 FMA 指令，FMA 的结果比“先乘后加”更精确，但和没有融合的实现不一致。这就是个很形象的比喻：三个人分一杯水，你按不同的倒水顺序倒来倒去，最后一次的分量总会因为“杯壁残留”差一点；浮点运算是按二进制尾数舍入，每一步都在“留残渣”。
具体到 RL 系统里，来源可以列成一串：
- CPU 和 GPU 各自实现数学函数，比如 exp、log、sin、sqrt，结果可能不同。ROCm 的设备端数学库和 NVIDIA CUDA 数学库的迭代次数、多项式展开阶数不一样，连 glibc 的 libm 和你手工内联的 SIMD 实现都不一样。
- 并行归约的顺序不确定。多个线程各自算局部和，再合并成一个全局和，谁先谁后完全取决于调度，求和结果就不一样。
- 编译器开了
-ffast-math或自动启用 FMA 收缩后，表达式被重新结合，数值路径就变了。 - GPU 上非正规浮点数（denormal）的处理策略不同，TF32、FP16 这种低精度中间格式也可能被隐式使用。
- 多线程环境下，环境步进里的随机噪声、物理模拟的积分顺序，也会被线程调度打乱。
“训练和 rollout 不一致”本质上不是精度不够，而是这两条路径产生了不同的浮点舍入序列。你需要的不是把误差压小，而是把“舍入路径”固定下来。
1.3 Bitwise 一致的本质：把隐性选择全部显式化
很多人以为 bitwise 一致就是固定随机种子。实际上随机种子只是最容易控制的一环。我要做的，是把系统里所有“隐式选择”都变成“显式配置”：用哪套数学库、是否启用 FMA、归约顺序是什么、环境状态用什么字节表示、策略前向跑在哪个设备、线程数量是多少、GPU 工作频率是否固定。只有当这些变量全部冻结，训练和 rollout 才能达到逐位一致。
这个概念说起来不难，落地却很繁琐。下面我会拆开讲，从架构上怎么分工，到 AMD 平台上的具体细节，再到完整实操流程。
2. 整体方案：RL-Kernel 与 vime 怎么分工
2.1 RL-Kernel：训练侧确定性内核
我们把训练侧的核心运行时称为 RL-Kernel。它不是一个很强的框架概念，而是一层贴近硬件和调度器的“内核壳子”，负责策略网络前向、损失计算、优化器更新、梯度同步。要让训练侧可复现，RL-Kernel 的原则很粗暴：所有矩阵乘、卷积、归约、激活函数，都固定到同一套 kernel 实现，不允许在不同加速库之间自动切换。
实际落地时，第一步就是关掉算子自动搜索。在 PyTorch 里，这意味着torch.backends.cudnn.benchmark = False，在 ROCm 侧同样要关闭类似 benchmark 行为，因为自动搜索会针对输入尺寸挑选不同的 kernel，不同 kernel 的归约顺序和分块策略不同，结果就是同样输入跑两次，输出字节不完全一致。第二步是启用确定性算法开关，PyTorch 提供torch.use_deterministic_algorithms(True)，它会让框架在遇到无确定性的算子时直接报错，而不是悄悄给你一个不确定结果。
这听起来像牺牲性能换确定性，其实未必。RL 训练中 rollout 和训练往往不是同时跑满算力，让 RL-Kernel 把关键计算固定到少数几个经过验证的 kernel 上，之后做性能优化的回旋余地反而更大。我见过不少团队为了 5% 的吞吐提升打开了自动调优，结果浪费一周在排查“为什么同一个 seed 复现不了”。
2.2 vime：环境模拟层的确定性沙盒
vime 在这里充当环境模拟执行层，我习惯叫它“沙盒”。它和 RL-Kernel 的分界线非常清晰：RL-Kernel 管的是策略和梯度，vime 管的是环境状态推进、奖励计算、观测序列化。只要涉及环境本体，每一步都要在 vime 里面完成，不能让环境代码直接跑在裸的多线程进程里。
vime 的核心设计有三点。第一，状态表示固定：环境内部一律用 float32 或整形计数，不允许隐式转 float64 再转回 float32。第二，随机源固定：用独立的 PRNG 实例管理环境随机性，不允许调用依赖全局状态或系统时间的随机函数。第三，序列化固定：每一步输出的 obs、reward、done、info，都按约定好的字节序和类型宽度序列化，训练端拿到的就是这套字节，而不是重新算一遍环境。
这个方法相当于给整个环境交互过程拍了一张又一张“底片”，训练端不再负责“理解环境”，只负责消费 vime 吐出来的字节流。只要 vime 在 rollout 侧生成的字节流是确定的，训练侧重放到这几个字节上就不会产生环境相关的差异。
2.3 双端一致性校验：Bitwise 基准线
RL-Kernel 和 vime 各自确定性还不够，必须有一个“双端校验”机制来证明它们之间按字节一致。我的做法是在管线里埋一个审计节点：每一批 rollout 数据落库之前，对 obs、action、reward、done、value 五个张量的原始字节做 SHA-256 哈希，同时记录哈希链；训练端读取这批数据并做完策略前向之后，再用同一逻辑重新计算哈希，和 rollout 侧的哈希链做比对。
这里的重点是“同一逻辑”四个字。哈希函数本身容易保持一致，真正麻烦的是数据在内存里的布局。我要求所有传输层在数据送到训练端之前，必须克隆成连续内存块，不能带 torch tensor 的 stride 信息，不能是 non-contiguous 视图。只有拿到完全相同的字节序列，哈希比较才有意义。双端哈希一旦不一致，训练流程直接挂起，而不是继续带着错数据跑下去。
3. 在 AMD 平台落地的关键细节
3.1 先摸清 AMD 的浮点行为，不要拿 Intel 经验硬套
AMD 平台和 Intel 平台在浮点行为上确实有差异，但不是“谁更准”的问题，而是“路径不同”。AMD EPYC 处理器支持 FMA3、AVX2，某些新代际还有 AVX-512，但这些指令是否能被用到，取决于编译器怎么选择。跨平台编译时，如果一台机器用了-march=native，另一台没有，生成代码里的 FMA 收缩情况就可能不一样，结果自然对不上。
更麻烦的是数学库。同一套 glibc 版本下，libm 的expf、logf等函数在 AMD 和 Intel 上可能走不同分支，因为内核会根据 CPU 特性选择不同实现。ROCm 侧的 device 数学库和 CUDA 的数学库也不是同一个东西，GPU 上的exp、tanh和 CPU 上的同名函数，字节级结果几乎不可能一致。所以我在 AMD 上做 RL 项目时，第一件事就是在所有训练机器和 rollout 机器上统一操作系统镜像、统一 glibc 版本、统一 ROCm 版本，并且明确规定：策略网络相关计算只允许经过框架提供的确定性子程序，不要自己再写一层数学包装。
3.2 编译与运行时：把 FMA 和线程调度钉死
编译侧我有一套固定的 flags。开发调试和 bitwise 校验场景下，使用-O2 -ffp-contract=off，关闭自动 FMA 收缩；-fno-unsafe-math-optimizations防止编译器把浮点运算当成可交换、可结合的普通代数运算；也不要开-ffast-math，那等于告诉编译器“我不关心 NaN、Inf、精度和符号，随便重排”，对于需要 bitwise 一致的系统来说全面崩盘。
运行时侧，我会固定线程数，OMP_NUM_THREADS=1配合torch.set_num_threads(1)，让环境步进和策略前向不因为多线程调度产生微小时序差异。物理模拟尤其敏感，两个线程同时推进两个动作时，如果某个碰撞检测内部用了共享的工作队列，线程执行顺序变了，next state 就可能变。把线程数压到最少，是最粗暴也最有效的确定性手段。
CPU 频率波动也会间接影响结果。虽然频率不影响浮点运算本身，但会影响并发调度时序，进而影响多线程归约顺序。实践中我用taskset固定 CPU 亲和性，并关闭 BIOS 里的 turbo boost，或者用系统工具锁定 CPU governor 为 performance。GPU 侧同理，训练期间用 rocm-smi 把 GPU 工作时钟固定在一个稳定档位，避免自动升降频。
3.3 GPU/ROCm 侧：别让底层悄悄换算法
AMD GPU 上跑 PyTorch，环境变量和 NVIDIA 侧不一样。常见的ROCR_VISIBLE_DEVICES用于指定可见设备，HIP_VISIBLE_DEVICES在旧版中也可能遇到。训练脚本里加一句os.environ["ROCR_VISIBLE_DEVICES"] = "0"就能保证进程只看到固定的一块卡，防止多卡环境里设备编号漂移。
ROCm 侧没有cudnn.benchmark这个说法，但在 PyTorch 中相关开关仍然会影响后端选择。我建议统一关闭 benchmark 类型的自动调优，并且显式关闭 TF32：torch.backends.cuda.matmul.allow_tf32 = False和torch.backends.cudnn.allow_tf32 = False。对 RL 训练来说，矩阵乘法的输入维度通常不会特别巨大，TF32 带来的性能收益有限，可它会在价值网络和策略网络前向中引入额外的不确定性，一旦两张卡因为驱动设置不同走了不同的 low-precision 路径，bitwise 就不可能成立。
ROCm 上还要注意算子实现版本。驱动或 ROCm 版本升级后，同一个算子的底层 kernel 可能变化，前一天能复现的实验第二天就失真。所以我在 CI 里把 ROCm 版本固定成了构建环境的一部分，升级必须有完整的 bitwise 回归测试。
3.4 谁校准谁：用标量参考实现定基准
当 CPU 和 GPU 的数值路径确实无法做到点对点完全一致时，必须选一个基准来校准。一般做法是让 vime 端生成一套“黄金字节流”，由 CPU 标量实现（不开 FMA，严格按单栈顺序运算）算出，RL-Kernel 训练侧在加载这批数据后，也先跑一次同样的标量参考路径，验证哈希匹配，再切换到 GPU 快速路径。
这不是为了证明 GPU 高速路径和标量路径结果一模一样，而是为了建立信任链：环境状态阶段，标量参考是“真值”；策略网络阶段，我们只要求 GPU 快速路径在相同输入下保持自身可复现。换句话说，环境推进必须 bitwise 一致，策略网络只需要“同设备同版本可复现”。这样做的原因是环境推进往往是 RL 复现性事故的主要来源，而策略网络本身只要固定 kernel 版本和配置，跨设备一致性可以靠后续 rollout 数据哈希来约束。
4. 实操流程：从零搭一套 Bitwise 可复现的 RL 管线
4.1 第一步：建立字节级哈希审计
审计节点是整套方案的骨架。代码逻辑很简单，关键是运行时机。我在 rollout 写 buffer 之前插入一段逻辑，把每个 transition 的 obs、action、reward、done、value 的浮点数组转换成连续字节，然后取 SHA-256，串成哈希链。伪代码大概长这样：
import hashlib def hash_bytes(arrays): digest = hashlib.sha256() for arr in arrays: # 强制连续内存 arr = arr.contiguous().cpu() # 用内置的 bytes 方法拿原始内存表示 digest.update(arr.numpy().tobytes(order="C")) return digest.hexdigest() def chain_hash(prev, cur): return hashlib.sha256(prev.encode() + cur.encode()).hexdigest()这里有个很容易忽略的坑：一定用tobytes(order="C")这种明确布局，不要用 Python 默认的序列化。numpy 的默认序列化带对象头信息，不同 numpy 版本可能序列化结果不同；.tobytes()是纯内存字节，稳。每次训练从 buffer 取 batch 时，也跑同一套哈希逻辑，两边对不上就打日志并终止本回合训练。
4.2 第二步：冻结环境随机源与物理引擎设置
不确定性的最大来源常常不是神经网络，而是环境。MuJoCo 这类物理引擎的求解器迭代次数、碰撞处理顺序，都会影响状态。vime 的职责就是把这些参数锁死。
我实际操作时会做三件事。第一，把所有随机数发生器换成显式实例化的 PRNG，比如np.random.Generator(np.random.MT19937(seed))，并且每个环境一个独立实例，不允许共享全局状态。第二，物理引擎的固定时间步长dt、子步数n_substeps在配置文件中写死，环境重启时从同一个配置读取，代码里不提供运行时修改入口。第三，环境代码里所有随机向量（扰动、初始位置抖动）都通过同一个Generator按固定顺序生成，不能出现“某一行代码先调 random 再调 physics step、另一处因为线程乱序而先 step 后 random”。
随机种子本身也可以纳入哈希链。我习惯把每个 rollout 分段器对应的 seed 和该段第一个 transition 的哈希绑定，训练端重放时如果发现 seed 哈希链对不上，说明某个环境被外部因素改了状态。
4.3 第三步：让训练与 rollout 共享同一套数值路径
接下来是架构层面的关键选择。理想情况下，策略网络的前向计算在 rollout 和训练中应该使用完全相同的 kernel 实现。我采取的折中方案是“按设备分区”：rollout 侧如果跑 CPU，那么训练侧不会只因为能上 GPU 就优先把前向也放 GPU；而是先确认 CPU 和 GPU 上的同一层实现已经通过 bitwise 测试。如果暂时做不到，就强制 rollout 和训练共用 CPU，牺牲一点速度，换回确定性。
共享数值路径还包括优化器更新顺序。PPO 这类算法中，旧策略、新策略、importance ratio 的计算顺序如果不同，梯度就有差异。我在 RL-Kernel 中把“旧策略前向、新策略前向、GAE 计算、clip 损失”严格编排成固定 pipeline，每一步的输出 tensor 不允许被 in-place 操作覆盖。这不仅是代码风格问题，更是在保护数值路径不被意外改写。
4.4 第四步：双端差分与容差策略
严格模式下，训练端和 rollout 端的所有关键张量必须完全一致，不允许“接近就好”。但在工程落地中，有些算子是数学上等价、位级上不等价的，比如在不同 GPU 型号之间做分布式 rollout。这时候我会开启“受控容差”回归模式：记录每个张量的最大绝对误差、最大相对误差、不一致元素占比，作为特征值写入监控系统。
容差不是给不一致开绿灯，而是为了暴露“该一致的地方不一致”。我设置的阈值通常是：关键决策张量（action、done）必须 100% bitwise 一致；非关键统计张量（reward 的 debug 版本）允许相对误差低于 1e-6，且不一致率低于 1%。一旦某天 rollout 数据哈希比对超过阈值，训练立即暂停并触发告警，避免带病训练几个小时。
5. 常见问题与排查技巧实录
5.1 先从环境变量与版本指纹查起
遇到不一致，第一反应不要去看算法代码，先收集环境指纹。我总结了一张速查表：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 同一台机器每次运行结果一致，换机器不一致 | 编译选项或数学库不同 | 比对gcc -v、glibc版本、-march参数 |
| GPU 和 CPU rollout 结果差几个 bit | 设备数学库不同或 TF32 开启 | 统一前向设备，显式关闭低精度格式 |
| 多线程 rollou t不稳定 | 物理引擎或随机源受线程调度影响 | 固定OMP_NUM_THREADS=1，固定 CPU 亲和性 |
| 每次重启结果不一致，但在同一进程内一致 | 全局随机状态或环境初始化使用了当前时间 | 检索代码中的random()、np.random.seed、time.time |
| 升级 ROCm 后结果变了 | 算子 kernel 实现版本变化 | 回归测试，冻结 ROCm 版本 |
经验是，把版本指纹写成文件跟随日志一起保存。.gpu-info里至少包含rocminfo、rocm-smi --showproductname、PyTorch 版本、GCC 版本。追查不一致时，先看这些，再谈算法。
5.2 我踩过的坑：单卡确认可复现，双机又翻车
最折磨人的一种情况是，单卡环境下 RL-Kernel 和 vime 的 bitwise 测试全绿，部署到双机分布式以后立刻翻车。我排查了很久，最后发现不是浮点问题，而是网络通信层的缓冲顺序。分布式 rollout 把 transition 打成批次后通过 gRPC 发送，接收端拼接 batch 时依赖了 unordered_map，某个节点的乱序导致同一个 batch 里数据排列不同，后面哈希自然对不上。
修复方案是在 vime 的序列化层引入“全局批次序号”：每个 rollout chunk 从 0 开始编号，接收端按序号严格落位，拒绝任何乱序合并。从那以后，双机和单机的结果完全一致。这也再次验证了一个道理：bitwise 一致不仅是数值问题，更是整个数据链路的一致性问题。
5.3 把一致性测试做成 CI 门禁
最后一个小建议：把 “rollout 重现一致性测试” 放进 CI。每次改动环境代码、策略网络实现、编译选项、驱动版本，都要跑一组标准样例，对比新的 rollout 字节哈希与基线哈希。这组样例不需要大，但必须覆盖随机噪声、终止截断、稀疏奖励这几个敏感场景。
我见过团队在本地辛苦手动配置全部确定性，结果某天有同事为了调试把某个环境变量注释掉推上了主分支，训练静默跑了两天。有了 CI 门禁，这种回归会被立刻拦住。确定性不是一次性配置出来的，而是靠每次变更时不断验证保持下来的。
5.4 训练期最危险的三个“善意优化”
在 RL 管线里，有三个看似无害的优化动作会毁掉一致性。第一个是把 reward 从 float32 转成 float16 以减少显存占用，转回去之后尾部 bit 已经变了。第二个是在做奖励归一化时用所谓的“指数滑动平均”代替固定窗口统计，虽然单步误差很小，但长序列下误差会积累到可见水平。第三个是自动调优算子时对相同输入重复运行选取“最快”kernel，这会让同一次训练中不同 iteration 用的 kernel 都可能不同，复现性无从谈起。
如果你的系统已经上线了其中任何一个，又不方便彻底移除，建议至少把它们的开关纳入 bitwise 测试覆盖范围，让每次出现不一致时能够第一时间判断是不是这几个环节造成的。
根据我个人的经验，做 bitwise 一致不是为了“强迫症式”地追求两个输出相等，而是为了逼着整个系统把所有隐式选择全部摊到桌面上。FMA 收缩要不要关、数学库用哪套、线程数多少、是否开启 benchmark、GPU 时钟是否固定、网络包是否乱序——这些在普通训练系统里没人会管的细节，一旦被 bitwise 测试盯上，就会被一条一条暴露出来。等你想办法把它们全部显式化并钉死之后，你会发现自己对 RL 训练系统的掌控力比原来强了一个量级，那些曾经“过几天就复现不了”的实验，也终于变得像普通软件开发一样可以 debug 了。
