AllReduce 首先是一份集体合同：私有缓冲区连不成环

多个 rank 各自分配一份内存再不断检查“上一 rank 的完成标记”不会自然变成通信。若这些标记也在各自的私有分配中其他 rank 根本写不到它们等待就可能永远不结束。画了环形箭头不等于建立了共享可见性。NCCL 集合操作文档明确要求各 rank 以一致的数量和数据类型参与集合调用不匹配可能导致挂起或数据损坏。AllReduce 的 sum 合同则很简单每个 rank 都收到所有输入的逐元素和。AllReduce 把逐元素归约结果交给每个参与 rank。def allreduce_reference(inputs): if not inputs or len({len(x) for x in inputs})!1: raise ValueError(ranks need the same element count) result[sum(x[i] for x in inputs) for i in range(len(inputs[0]))] return [list(result) for _ in inputs] outallreduce_reference([[1.,2.],[3.,4.],[-1.,5.]]) assert out[[3.,11.]]*3 out[0][0]999. assert out[1][0]3. # independent receive buffers try: allreduce_reference([[1.],[2.,3.]]) raise AssertionError(mismatch accepted) except ValueError: pass print(AllReduce contract and mismatched-count rejection passed)这是中心化参考计算没有通信、并发和环形算法。它能给真实实现提供结果基准不能用于估计网络带宽。数据平面和同步平面都要连上共享内存实现要让所有参与者映射到同一底层对象并安排可见性和同步跨主机实现则要真的传输数据。一个本地地址不能直接作为其他进程的有效指针进程间共享还要用偏移或其他统一寻址约定。真正的 ring sum AllReduce 通常包含 reduce-scatter 和 all-gather 两个阶段块归属随步骤移动。任意一个 rank 的计数、轮次或退出行为不一致都会破坏集体合同。超时只能终止等待不能修好已经不一致的结果。张量并行的收益包含通信账拆分矩阵计算可以减少单设备权重压力同时增加同步。层数、batch、互连与消息大小会影响通信占比。不能把单进程数组求和的耗时换个标题就当成多卡 AllReduce 性能。一次挂起通常不是带宽太小集合通信在所有参与者共同进入协议后才有意义。若某个 rank 在前一阶段报错退出其余 rank 仍继续等待下一次集合就可能一直没有完整参与者。此时增加线程、扩大共享缓冲或更换分块大小都没有修复协议缺口。首先要核对各 rank 实际执行到第几次集合以及那次调用的类型和元素数量。通信日志可以带一个逻辑轮次。相同轮次的所有参与者必须对集合操作达成一致否则应在可控范围内终止或重建而不是继续消费下一条消息。轮次标识不能独自解决故障却能把“似乎卡住了”变成某个参与者缺席或参数不一致的具体问题。浮点归约还要接受加法次序的影响。中心参考顺序求和与环形或树形合并可能出现舍入差异不能只因逐位不同就判定错误。另一方面大量偏差或某个 rank 收到不同结果也不能靠放宽阈值解释。先检查输入、块归属和步骤再分析正常的数值误差。若自己实现共享内存教学版本可以从两个参与者开始先证明双方映射同一对象、相同偏移确实能相互观察再加入明确同步。跨进程对象的创建、销毁和异常退出也应有协议。一次成功求和无法证明多轮复用安全重复执行与中途退出才会暴露更多状态错误。PyTorch 2.14 发布说明提到集合后端和容错方向的进展。对实现者先固定参与者、数据类型、调用顺序和失败策略再选择库与拓扑。本文没有运行 NCCL、分布式进程或 GPU验证范围只到集合操作的结果合同。