ROCm平台确定性集合通信：从原理到多卡训练可复现实践

最近在调一个8卡多节点训练任务，卡了三天，现象很典型：同样的脚本、同样的种子、同样的数据顺序，跑两次，验证集上的loss总是差那么两三个小数点。一开始怀疑自己漏设了随机种子，后来把初始化、数据加载、dropout全部排了一遍，才意识到问题出在我一直当成“黑盒”的集合通信环节。

在 ROCm 平台上做分布式训练，集合通信绝对是绕不开的一环。所有卡上的梯度要汇总、平均、再分发回每张卡，这靠的就是 allreduce、broadcast、allgather 这类集体动作。训练吞吐、多机扩展性、结果可复现性，往往就取决于这些集体动作是否稳定。下面这些内容，是我在实际排查过程中的完整记录，会讲到确定性集合通信是什么、为什么会不确定、怎么在 ROCm 上配置出可复现的通信行为，以及我踩过的那些让人头大的坑。

适合看这篇文章的人，我大致分成三类：正在 ROCm 多卡环境上训练模型的工程师，他们会特别关心“换平台之后结果漂移”的问题；做分布式框架适配和通信优化的人，需要理解集合通信不确定性的来源；还有那些被“同一份代码两次结果不一样”折磨过，又不确定自己漏了什么环节的朋友。接下来不是理论串讲，而是一份从定位问题到落地配置的经验记录。

1. 为什么我会盯上“确定性集合通信”这件事

1.1 集合通信是一个容易被忽略的黑盒

在分布式训练里，集合通信说起来一句话：多卡协同，每张 GPU 把自己的梯度拿出来，大家做一个全局归约，再拿回最终结果。可它底层动作比训练本身复杂得多。一张卡的数据要切块，按某种拓扑传给下一张卡，中间节点做部分求和，最后广播回所有卡。为了性能，通信库会动态选择环状、树状甚至多通道并行。这种动态性在吞吐上赢了，却给可复现性埋了雷。

对一般业务开发来说，集合通信根本不需要理解内部实现，框架会帮你初始化通信库、封装算子。但只要走到多卡、多机，坑就会冒出来：通信库把数据切成多少块、走哪条路径、谁先到谁后到，都可能影响最终的浮点结果。普通情况下没人关心，可当你要做算法复现、缺陷排查、或者给外部交付固定输出时，这些细微差别会让你怀疑人生。

我见过不少同学遇到多卡结果不稳定，第一反应是改随机种子，或者怀疑数据增强写错了。但集合通信这一层的问题往往更隐蔽：它不是“报错”，而是每次运行都给你一个合理但不一样的结果。你很难确认是模型问题还是分布式同步问题，只能一层层剥离，最后才会撞上通信库。

1.2 两次训练结果不一致，卡了我三天

说回我自己的经历。我们在某个图像分类任务上做 ROCm 多卡迁移，8 卡单机。原先在另一套硬件上跑得好好的，换到 ROCm 后为了性能调整了通信配置，结果发现：固定所有种子，跑两次，训练到第 10 个 epoch，loss 开始出现第 6 位浮动的差异，到第 30 个 epoch，验证集准确率相差 0.02 个百分点。听起来差异很小，但一个要反复对比多个实验的任务完全无法接受：你到底在比较模型 A 和模型 B，还是在比较两次偶然的浮点抖动？

自查顺序是先怀疑框架的数据加载，洗牌线程、随机性来源；再怀疑算子实现是否有非确定性；全排完之后，才把注意力放到通信库。最后一查，那个动态算法开关在不同进程启动时有细微竞争，导致两次运行走了不完全一致的 reduce 顺序。这类问题的典型特征就是：问题不出现在单卡，只出现在多卡；不固定还好，越固定越玄。

那次的教训很直接：任何分布式训练的确定性，不能只看模型代码，通信层必须单独验证。从那以后，我再也不把集合通信当黑盒了。

1.3 ROCm 生态下的确定性现状

在 ROCm 生态下，这个问题比传统 N 卡生态更容易被忽略——并不是 ROCm 的集合通信库少了确定性设计，而是它的文档和调试工具相对更“硬核”，很多经验需要翻源码、跑实验才能总结出来。对于传统生态的集合通信库，大家已经积累了很多环境变量和配置经验；换到 ROCm 后，一部分开关沿用下来，一部分改了名字，还有一部分触发条件不一样。

另外，ROCm 平台上能跑的硬件种类、服务器拓扑也更杂，从消费级显卡到数据中心卡，PCIe switch、NUMA 节点、多路网卡，任意变化都可能影响通信库的拓扑探测结果。所以，至少在目前阶段，想要在 ROCm 上获得真正二进制级可复现的集合通信效果，不能只依赖某个框架里的一个开关，而要自己配环境、固定策略、再验证。这也正是我想把这篇实践记录留给后来者的原因。

2. 不确定性来自哪里：从浮点累加说到网络抖动

2.1 浮点运算本来就不满足结合律

先讲一个很多人忽略的事实：浮点数加法不满足结合律。(a+b)+c 和 a+(b+c) 在实数意义下相同，但在二进制浮点表示下，因为有限位数的舍入，结果可能不同。这个差异通常极小，但在像 allreduce 这样动辄几亿个梯度元素、每个元素被加几十次的场景里，累加顺序只要一变，结果就会变。

集合通信里的 reduce 就是“很多人把钱交到你手里，你按顺序清点”。你按小号到大号收，和按大号到小号收，最终几分钱可能不同。当所有卡同时把各自的梯度发给另外几张卡时，谁先到、谁后到、中间结果在哪保存，都会影响最终的求和顺序。这些顺序在分布式环境里几乎不可能靠运气稳定下来。

这个点听起来基础，但实际排查时极易被忽略，因为你在单卡上跑同样的计算，结果永远是确定的。只有多卡并行、数据被切分到多个通信路径之后，浮点结合律问题才会浮出水面。

2.2 通信算法和通道选择会“随缘”

为了性能，集合通信库实现了多种算法，最常见的是环状（Ring）和树状（Tree）。环状像传纸条，沿环形链路传递；树状像金字塔，先层内归约再汇总。不同算法下，每个元素被计算的路径完全不一样。默认情况下，库会按拓扑、数据量、网络带宽动态选一个“看起来最优”的算法。于是两次运行可能第一次用树、第二次用环，结果自然不一样。

更细一层，通信库内部还会决定开多少条通道、每个通道处理哪一段数据。通道多了，同一批数据被拆到多个并行的 reduce 流上，虽然理论上最终结果应该一样，但浮点累加顺序不同。所以只有算法固定还不够，通道数、数据切片策略也得固定，才能真正锁住行为。

还有一个容易被忽略的点：动态算法选择的触发条件可能不是显式的报错，而是在某个阈值附近自动切换。比如数据量刚好跨过某个边界时，第一次走 Ring，第二次走 Tree。这种“随缘”对性能是友好的，对确定性却是灾难。

2.3 多节点时序让规约顺序漂移

单机多卡，卡之间的顺序还相对可控；多节点一上来，交换机、网卡中断、网络拥塞都会引入抖动。通信库为了做流控，会把数据拆成很多小包，接收方不一定按发送方发出的顺序处理。于是每一步 reduce 节点的输入顺序可能不同，输出自然可能不同。

这种时序漂移不是“偶发 bug”，而是分布式系统的常态。你没法控制网线里的比特什么时候到，只能让通信库不要去“随机应变”。这也是确定性配置的核心思路：不是让网络变得有序，而是让通信算法忽略这些时序差异，或者在选择路径时不再依赖时序。

在 ROCm 上尤其要注意网络拓扑探测。通信库启动时会自动检测 GPU 之间的连接关系，如果某一次检测没有得到完全相同的拓扑，后面的路径选择就可能不一样。这也是为什么我后面会一直强调，要固定设备可见顺序，让通信库每次都“看到”同样的世界。

2.4 框架异步调度会放大不确定性

框架层通常采用异步执行模型，CPU 端把算子一个个提交到设备队列，设备端再异步执行。同一个训练步骤里，梯度计算和集合通信可能同时被调度。不同进程里 CPU 线程被操作系统调度的顺序不同，就会导致集合通信算子的提交时机有先后。通信库看到的是“上一批算子还没结束就来了下一条命令”，于是它的内部状态可能不同，例如选择等待或者重新规划通道。

所以，在做确定性配置时，框架层面也要尽量固定执行顺序：关闭算子融合中的随机选择、固定梯度桶的分桶策略、显式插入同步屏障。光靠通信库一个层面，往往按住了葫芦起了瓢。

我见过一个特别典型的例子：通信配置全部固定，哈希还是偶尔不一致。后来发现是框架的异步数据加载线程每次跑出来的数据顺序不同，虽然随机种子固定了，但线程调度导致 batch 拼装顺序变化，输入变了，输出自然变。把数据加载线程数固定后，问题立刻消失。

3. 确定性集合通信的落地操作：从环境变量到源码

3.1 先把训练基线固定下来

在动通信库之前，先把训练自身的随机性全部关掉。这一步看起来简单，实际很容易漏：数据加载的 shuffle 种子、多进程的采样偏移、随机数生成器都要单独设置；还有 CPU 多线程的算子，某些库会用 OpenMP，线程数一变化，累加顺序就变。所以我在每次实验前，会把 CPU 线程数固定成一个值。

还有一个不太容易被想到的：设备顺序。多卡环境下，进程被分到哪几张卡，通信库看到的拓扑就不同。要用固定规则把每个进程绑定到固定的设备索引，别让系统随便分。这一步相当于给集合通信一个“稳定的世界模型”，否则后面怎么做都可能白搭。

我通常的做法是写一个环境准备脚本，把所有固定项放在一起：随机种子、线程数、设备列表、库版本、容器镜像 ID。这样任何一次复现实验，都能明确知道“我是在哪个固定点上跑的”，而不是凭记忆去猜。

3.2 固定算法、协议与通道数

在 ROCm 上，集合通信库大量沿用一套环境变量体系，常见操作是设置算法列表、协议列表和最小/最大通道数。以我使用的版本为例，会把 allreduce 的算法候选限定为树状（Tree），协议类型限定为简单模式（Simple），并把通道数的最小值和最大值都设为 1。协议多说一句：协议指的是数据在内存和网络之间的搬运方式，不同协议对数据切分粒度和对齐方式不同，只固定算法不固定协议，等于只锁了一半的门。

需要提醒的是，不同 ROCm 版本的变量名前缀可能不一样，有些沿用NCCL_前缀，有些改用RCCL_前缀，个别参数在部分版本里还不生效。我的习惯是先用一个最小脚本把所有候选变量打出来，确认哪些生效，再写进容器的启动脚本里。不要看一眼文档就照抄，环境变量如果不生效，问题排查会比不设置更痛苦。

这里有个小技巧：验证环境变量是否生效，不一定要跑完整训练。启动一个单机多卡的通信算子自测程序，打印每次运行时的实际算法和通道数，对比环境变量设置前后是否变化，就能很快定位是变量名不对还是库没编译进对应功能。

3.3 用“分层规约”把计算顺序焊死

即使做了算法和通道固定，某些极端场景下还是会出现微小的不一致，这通常是因为数据切块后，不同通道之间的完成顺序不稳定。遇到这种情况，我的做法是绕开库里的并行 reduce，自己实现“分层规约”：先把所有卡按固定顺序分成若干小组，组内先用广播确定一个固定的聚合顺序，再在组间做第二次规约。

听上去很土，但非常有效。相当于把原本由网络时序决定的“谁先到”改成由你写死的代码决定。代价是少了一些并行度，吞吐可能下降。可如果是做调试或交付复现，这种确定性比绝对性能更值钱。实际操作中，我会先量化默认通信库的不确定性有多大，只在发现同一个输出哈希反复跳动时才采用这招，避免过度设计。

实现分层规约时要注意一个细节：中间结果的保存位置和数据类型必须固定。如果第一次中间结果放在 GPU 显存里，第二次放在主机内存里，精度可能不同，哈希照样会跳。细小处的稳定，才是整体确定性的基础。

3.4 在框架层固定梯度桶与同步点

还要处理框架这一侧。很多深度学习框架在梯度回传时会先把参数分组，凑满一个桶后触发一次集合通信，称为梯度桶。桶的划分方式和触发时机如果不固定，两次运行的通信顺序就会不一样：第一次可能桶 A 先发，第二次可能桶 B 先发。多数框架的默认行为在一台机器上是确定的，但在多进程调度紧张时会变化。

做法是显式关闭某些性能优化选项，例如自动选择的桶大小、动态分桶、算子融合等，把梯度桶大小设成固定值，尽量让每个反向传播步骤都有相同的集合通信调用序列。同时，在需要严格复现的任务里，可以在每个 epoch 结束插入一次全节点同步，把异步执行的跑偏拉回来。

框架层还有一点容易被忽略：checkpoint 保存和加载的顺序如果不同，模型参数的恢复顺序也可能影响后续计算。虽然这不算集合通信本身的确定性，但它会和一个不确定的通信层叠加在一起，让排查复杂度翻倍。

3.5 用源码构建兜底

如果上面的环境变量还压不住，或你发现某几个参数根本没有生效，那就只能看源码。ROCm 生态的集合通信库是开源的，你可以基于源码构建一个定制版本：把算法探测函数直接改写成固定返回 Tree、把通道数初始化写死、甚至注释掉部分自适应的拓扑探测逻辑。

做这种事要控制改动面：不要动通信协议核心，只改“选择逻辑”。选择逻辑相对独立，改了不会影响数值正确性。构建完之后，再用哈希验证脚本证明改动是对的。源码构建的好处是，你不仅知道“稳定了”，还知道“为什么稳定了”；坏处是升级时得自己重新适配，所以我通常只在环境变量无法完全锁定时才走这一步。

还记得我第一次改源码时，把拓扑探测函数注释掉后，通信库启动直接报错。后来才发现代码里还有另一处校验逻辑依赖拓扑结果。这种问题只能靠耐心读调用链，没有捷径。源码级的确定性方案，注定是给那些把复现性当硬指标的人准备的。

4. 实测配置模板与验证方法

4.1 环境变量配置模板

下面是我在某个 8 卡单机任务上验证可行的配置模板，以“常见版本的集合通信库”为例。变量名不一定在所有版本通用，但思路是通用的。

# 固定通信算法候选：只保留 Tree export RCCL_ALGO=Tree # 固定协议：Simple，避免不同协议带来的切分差异 export RCCL_PROTO=Simple # 固定通道数，不动态调整 export RCCL_MIN_NCHANNELS=1 export RCCL_MAX_NCHANNELS=1 # 固定通信超时和重试，避免运行时的偶发路径切换 export RCCL_TIMEOUT=600 # 固定设备可见顺序，保持每轮进程的设备映射一致 export ROCR_VISIBLE_DEVICES=0,1,2,3,4,5,6,7

注意，RCCL_前缀在不同版本上可能不生效，有些版本沿用NCCL_前缀。如果你的环境变量打出来是空，就尝试另一套前缀，或者在启动脚本里同时设置两套，但以实际生效的那个为准。所有计算节点都必须使用同一份配置，容器镜像和库的版本也最好完全一致，否则你就是在给复现实验埋雷。

4.2 哈希验证脚本的思路

配置完之后，怎么证明集合通信真的确定？不是肉眼看 loss 曲线，而是直接在通信算子的输出 buffer 上做哈希。用一个最小化验证脚本，做 10 次独立的 allreduce，每次输入相同，记录输出缓冲区的哈希。如果 10 次哈希值完全一样，说明在当前配置下集合通信是二进制级确定。

import hashlib def compute_hash(tensor_bytes): return hashlib.sha256(tensor_bytes).hexdigest() # 伪代码示意：实际通过通信算子获取输出 buffer for trial in range(10): output = collective_allreduce(identical_input) hashes.append(compute_hash(output.view_bytes())) print(set(hashes)) # 长度应为 1

真实训练时，把那 10 次 allreduce 替换成完整的训练流程，至少跑两个 epoch，在若干固定步数采集模型参数快照并哈希。只要两个独立进程在相同输入下能产出相同参数哈希，那把种子、设备绑定、集合通信配置再固化到工程脚本里，整套流程就算是被焊住了。

哈希验证最容易犯的错是只在最后一次比对。如果训练了 100 个 step，你只对比第 100 步的结果，前面某个 step 出现偏差又恢复，你根本不知道哪里开始变的。我会在每 10 个 step 打一个模型参数哈希，把“发生变化的位置”精确到小范围。

4.3 性能代价与取舍

确定性不是免费的。把通道数固定为 1、只用 Tree、关闭动态算法，本质上是在牺牲一部分并行度换取固定顺序。我实测下来，单机 8 卡、模型是常见图像分类网络，通信时间占比约 15% 时，确定性模式整体训练吞吐下降约 18% 到 25%。但在通信占比更高的规模上，比如多节点小 batch 模型，这个代价可能接近 40%。

所以我一般不会把确定性配置直接用在大规模生产训练上，而是准备两套配置：日常跑实验用确定性配置，保证结果可复现；确认模型没问题后，再切回默认性能配置做正式训练。这两套配置只差环境变量，不会改动代码，切换成本很低。真正无法接受性能损耗的场景，比如超大模型预训练，就只对关键的调试节点单独开确定性开关。

4.4 出现问题时的排查顺序

如果配置完之后哈希还是不一致，我建议按这个顺序排查：

• 第一步，看每一次运行日志里通信库打印的算法、通道数、拓扑信息，对比有没有变化；
• 第二步，确认所有节点的环境变量是否一致，容器镜像的集合通信库版本是否一致；
• 第三步，检查是否有非集合通信的算子引入了随机性，比如某些融合算子内部使用了原子操作；
• 第四步，物理层：检查 PCIe 拓扑、网卡型号、交换机链路是否对称。拓扑探测结果不同，通信库就会用不同路径，哈希自然不同。

前两步能解决 90% 的问题。剩下的才值得去翻源码。排查时别一次改一堆变量，每次只动一个，跑完哈希对比，再动下一个，否则你根本分不清是哪一项起了作用。

我自己的记录里，第一次做确定性排查时一口气改了五个配置项，结果哈希仍然跳。后来用二分法逐个撤销，才发现真正生效的只有两个变量，另外三个根本没起作用。从此我给自己定了个规矩：环境变量的验证，必须配合“打日志+哈希”两步走，肉眼看到设置不等于库真的用了。

5. 几个容易忽略的坑和我的最终建议

5.1 坑一：只固定算法，没固定协议

我最初踩的坑就是这样。设置完算法列表后发现还是不稳定，排查了三天，后来才发现协议没固定。集合通信输出的不同，有时候不是算法变了，而是协议变了。数据在显存与内存之间如何切块、如何对齐、用哪种拷贝方式，都会影响 reduce 的中间结果。所以我现在每次都把算法、协议、通道数三件套一起设置，并统一在哈希脚本里验证。

5.2 坑二：只改主节点，忘了所有计算节点

多节点训练里，主控节点配置上很容易，但实际计算任务跑在工作节点上。如果你只是在启动脚本的主节点部分设置变量，工作节点跑的还是默认动态模式，那么即便主节点是确定的，通信库的综合行为仍然不一致。最稳妥的办法是：把通信配置写进镜像的环境变量文件，而不是启动命令里，这样每个节点天然一致。

我在一次多节点任务里就犯过这个错：明明主控节点日志里显示 Tree 算法，工作节点日志里却是 Ring，但任务没有报错，结果哈希完全对不上。后来检查容器环境才发现，工作节点用的镜像是旧版本，环境变量文件根本没被加载进去。版本和配置双重不一致，排查起来特别折磨人。

5.3 坑三：认为“固定种子”就等于“确定性”

固定随机种子只是固定了随机数的来源，不会让浮点累加顺序变固定。它确实很重要，但和集合通信的确定性是两条平行线。我自己就犯过“只要设了种子就不查其他随机性”的错误。正确姿势是把随机种子、数据顺序、线程数、设备绑定、通信配置几个维度列成清单，逐项打勾，而不是默认某个框架的“确定性开关”把所有事都包了。

框架提供的“确定性模式”通常能管住算子层面的随机性，但不一定能管住通信库内部的路径选择。我见过有人把框架确定性开关打开后，就认为一切稳定了，结果换了一台服务器、换了 PCIe 拓扑，结果又开始跳动。确定性永远是一个系统工程，不是一个开关的事。

5.4 一些值得尝试的扩展方向

确定性集合通信不是只能用在训练分类模型。做强化学习、模拟仿真、或者要上报给监管的回测结果时，二进制级可复现几乎是硬需求。我在后续项目里还会尝试把同样的确定性配置推到推理服务上，比如多副本模型服务要保证同一请求返回逐比特相同的结果，集合通信的确定性配置就能避免多副本结果不一致带来的运维困扰。

另外，确定性配置也可以作为容错的辅助手段。当训练中断后要从 checkpoint 恢复时，如果每次恢复后的通信行为都不确定，你很难判断恢复逻辑是否真的正确。先把通信行为固定住，再去做故障注入，才能把“恢复是否正确”和“偶然抖动”分开。这是我接下来最想做的事。

踩过这一轮坑之后，我现在的习惯是：任何 ROCm 多卡任务，第一周里先花两个小时搭一个最小集合通信哈希验证用例，把它并到持续集成里。配置模板已经沉淀成团队里的一页文档，新任务先跑通确定性验证，再去看训练效果。这个过程多花的时间，总能从后续排查 bug 的时间里加倍省回来。