Gloo 存档落盘优化

背景与挑战

在大规模集群下，Gloo 通信存在规模限制和稳定性问题。一方面，容易出现 Gloo 通信组创建失败的情况；另一方面，与 HCCL 通信相比，Gloo 通信较慢。

对于Gloo通信组创建失败报错Gloo connectFullMesh failed with ...的问题，本质上是由于N张卡链接到主Master来完成建链，集群规模大时，Master处理能力不足，可能造成建链失败。可通过调整和网络建链相关参数进行规避（云上8k卡场景验证有效）：

net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog = 65536

此外，MindSpeed设计了 Gloo 通信优化方案使用HCCL通信替代Gloo。

解决方案

解决思路

[1] 采用 HCCL 通信组替换 Gloo 通信组，实现在原有功能基础上的替代。

[2] 采用切片方式减少单次通信的数据量，避免通信量过大导致的显存消耗。

使用场景

当 Gloo 通信频繁出现建链失败时，模型启动效率较低，此时需要通过替换 Gloo 通信组来提升效率。

使用方法

[1] 在训练脚本中加入 --disable-gloo-group，以启用该特性。

[2] 在脚本中定义 --hccl-slice-size N（可选），设置 DP 组保存和加载分布式优化器状态时的通信量大小。该参数的有效区间为 (0, bucket_size/dp]，其中 bucket_size 为分布式优化器中每个桶的大小。建议在显存允许的情况下，尽量增大该参数，以提高通信效率。

使用效果

通信效率分析

理论上，分布式优化器状态保存和加载的通信效率在一定范围内随着 hccl-slice-size 增加而提升。

显存增量分析

开启该特性后，显存的增加量为 hccl-slice-size * (2 * dp + 1) * 4B。