集合通信算法

针对同一个通信算子，随着网络拓扑、通信数据量、硬件资源等的不同，往往会采用不同的通信算法，从而最大化集群通信性能。HCCL提供了Mesh、Ring、Recursive Halving-Doubling（RHD）、Pipeline、Pairwise等拓扑算法用于Server内、Server间和超节点间的集合通信。

Server内通信算法

HCCL通信域Server内支持Mesh、Ring、Double-Ring和Star算法，具体使用的算法根据硬件拓扑自动选择，用户无须配置也不支持配置。

Server间/超节点间通信算法

HCCL通信域Server间/超节点间支持如下算法的自适应选择，自适应算法会根据产品形态、数据量和Server个数进行选择，用户默认无需配置。

Ring算法：基于环结构的通信算法，通信步数多（线性复杂度），时延相对较高，但通信关系简单，受网络拥塞影响较小。适合通信域内Server个数较少、通信数据量较小、网络存在明显拥塞、且Pipeline算法不适用的场景。
RHD（Recursive Halving-Doubling）算法：递归二分和倍增算法，通信步数少（对数复杂度），时延相对较低，但在非2次幂节点规模下会引入额外的通信量。适合通信域内Server个数是2的整数次幂且Pipeline算法不适用的场景，或Server个数不是2的整数次幂但通信数据量较小的场景。
NHR（Nonuniform Hierarchical Ring）算法：非均衡的层次环算法，通信步数少（对数复杂度），时延相对较低。适合通信域内Server个数较多且Pipeline算法不适用的场景。
NB（Nonuniform Bruck）算法：非均匀的数据块通信算法，通信步数少（对数复杂度），时延相对较低。适合通信域内Server个数较多且Pipeline算法不适用的场景。
Pipeline算法：流水线并行算法，可并发使用Server内与Server间的链路，适合通信数据量较大且通信域内每机包含多卡的场景。
Pairwise算法：逐对通信算法，仅用于AlltoAll、AlltoAllV与AlltoAllVC算子，通信步数较多（线性复杂度），时延相对较高，但可以避免网络中出现一打多现象（指一个rank通过同一个端口给多个rank发送数据），适合通信数据量较大、需要规避网络一打多现象的场景。
AHC（Asymmetric Hierarchical Concatenate）算法：层次化集合通信算法，仅用于ReduceScatter、AllGather、AllReduce算子，适用于通信域内NPU分布存在多个层次、同时支持多个层次间NPU对称或者非对称分布的场景，当通信域内层次间存在带宽收敛时相对收益会更好。

以上算法实现代码都已经在cann-hccl仓开放，开发者可访问Gitee-cann-hccl详细了解对应实现。
开发者若想指定Server间或超节点间通信算法，可通过环境变量HCCL_ALGO进行设置。需要注意，若通过环境变量HCCL_ALGO指定了Server间或超节点间通信算法，通信算法的自适应选择功能不再生效，以用户指定的算法为准。
每种算法支持的算子以及产品型号可参见环境变量HCCL_ALGO。

特殊说明

分组Full Mesh算法：分组全连接通信算法，仅用于 Atlas A3 训练系列产品 / Atlas A3 推理系列产品的AlltoAll、AlltoAllV与AlltoAllVC算子，在集群规模较大时，以一定的并发度分多组完成通信，在超节点内的并发度高、时延小，超节点间的并发度低、时延相对较高（以避免网络中出现一打多现象）。该算法不支持通过环境变量HCCL_ALGO进行设置。
NHR-HCF（NHR Highest Common Factor）算法：最大公约数算法，仅适用于 Atlas A3 训练系列产品 / Atlas A3 推理系列产品，在超节点间Server数不一致但Server间卡数一致的场景默认生效，不支持通过环境变量HCCL_ALGO进行设置，该算法通过计算超节点间Server数的最大公约数将通信域切分为多个对称分布的逻辑超节点，并基于新的逻辑拓扑形态选择通信算法，在“超节点间Server数的最大公约数大于1”的场景相对收益会更好。