HCCL AHC算法详解:面向非对称层次拓扑的集合通信拼接方案
【免费下载链接】hccl集合通信库(Huawei Collective Communication Library,简称HCCL)是基于昇腾AI处理器的高性能集合通信库,为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl
导读
AHC(Asymmetric Hierarchical Concatenate,非对称层次化拼接)是 CANN HCCL 集合通信库中面向层次化网络拓扑的 AllReduce 加速算法。当通信域横跨多个超节点、且各超节点卡数不一致(如 64 卡与 128 卡并存)、层次间存在带宽收敛时,传统层次化算法会因卡数不对称而失效,AHC 通过"拓扑分组 + 逻辑同号卡非对称拼接"将数据切片重组为可并行执行的 ReduceScatter / AllReduce / AllGather 流水,从而在非对称拓扑下保持高性能。读完本文,你将掌握 AHC 的核心思想、三阶段执行流程、逻辑同号卡划分原理、耗时模型,以及如何通过 HCCL_ALGO 环境变量在 HCCL 中启用该算法。
一、背景与挑战:为什么需要 AHC
现代大规模训练集群通常呈现层次化的网络特征:超节点内部(如单超节点 64 卡或 128 卡)使用高速互联,超节点之间通过网络互联,且层间带宽相对层内存在收敛。这种拓扑给集合通信带来两大技术挑战(依据 AHC.md 的算法描述):
- 带宽收敛导致单层算法性能下降:由于不同区域之间存在带宽收敛,传统单层集合通信算法(如全局 Ring)会把瓶颈暴露在收敛链路上,整体性能被严重拉低。
- 卡数非对称使常规层次化算法失效:不同区域的计算单元数量不同。例如一个通信域横跨两个超节点,一个超节点有 64 张卡、另一个有 128 张卡。常规层次化算法(如先组内规约再组间规约的固定分桶方式)依赖各组卡数一致或按固定比例分配数据,面对非对称分组时负载无法均衡,性能面临巨大挑战。
AHC 正是为**同时解决"带宽收敛"与"卡数非对称"**这两个问题而设计的:组内充分利用高速网络带宽,组间通过"逻辑同号卡"实现非对称拼接,让不同大小的分组之间仍能高效协同完成全量数据规约。
二、算法核心思想与执行流程
AHC 的核心思想是:基于拓扑将通信域内 NPU 及 NPU 上的数据重新分组,组内充分利用高速网络带宽,组间实现基于"逻辑同号卡"的非对称拼接。整体流程如下图所示(5 个 rank,划分为 2 + 3 两个分组):
AHC基于逻辑同号卡实现AllReduce过程(5个rank,2+3两个分组)
算法实现分为三个步骤:
步骤一:基于物理拓扑分组并执行组内 ReduceScatter
- 拓扑分组:临近的 NPU 划分为一个 group。各组内卡数无需一致(这正是与常规层次化算法的关键差异),组间带宽相比组内可能存在收敛。
- 求解最小公倍数并切分数据:求解所有分组数的最小公倍数 LCM(Least Common Multiple)。若有 G 个分组,则将数据划分为
LCM × G个切片。以文档示例为准:分组为 2 和 3,则 LCM = 6、G = 2,数据被切分成 12 份切片。这里的数学意义在于:LCM 保证每个分组都能把数据按自身卡数均分为整数份,从而让后续的"逻辑同号卡"一一对应成立。 - 组内并行执行标准 ReduceScatter:每个分组内部并行执行标准的 ReduceScatter,将本组负责的数据块规约到组内各卡。
步骤二:划分"逻辑同号卡"并执行组间 AllReduce
这是 AHC 最核心、最具辨识度的环节:
- 按数据边界切分:将每个 group 中待执行 reduce 操作的数据,按照 group 内各 NPU 卡间的数据边界进行切分,形成若干不均匀的数据块(由于各组卡数不同,数据块天然不均匀)。
- 建立跨组对应关系:每个 group 中的每份数据,在其他所有 group 中各有一份对应的、大小相同的数据。按照这种数据对应关系,group 之间的 NPU 也建立起一一对应的关系,存在对应关系的 NPU 被称为"逻辑同号卡"。
- 逻辑同号卡间执行 AllReduce:在所有 group 对应的"逻辑同号卡"之间执行 AllReduce 操作,把分散在不同分组中的同号数据汇聚规约。
逻辑同号卡机制的精妙之处在于:它把"非对称分组"重新映射为"对称的同号卡集合"。尽管每个分组内卡数不同,但通过 LCM 切分与数据边界对齐,每个分组的每份数据都能在其他分组中找到大小完全相同的对应数据,从而将非对称问题转化为一组对称的 AllReduce 子问题。
步骤三:组内 AllGather 还原全量数据
各 group 内的 NPU 之间执行 AllGather 操作,将规约后的结果广播回组内每张卡,完成整个 AllReduce 语义。
内部拼接算法的可替换性
文档明确指出:具体的组内和组间的 ReduceScatter、AllGather、AllReduce 等操作,其实现算法可以是任意已知算法,如 NB、NHR、Ring 等。当前 AHC 算法内部会根据具体场景和策略选择性能更优的拼接算法类型。这意味着 AHC 本质是一个"编排框架",而非固定不变的通信原语,其底层原语的选择与 NB、NHR、Ring 等算法相互解耦、灵活组合。
三、耗时计算模型
当组内和组间都采用 NB 算法时,AllReduce 算子的算法耗时如下表所示:
| 操作 | 耗时 |
|---|---|
| ReduceScatter | $2(\lceil \log(m+d)\rceil + \lceil \log(G)\rceil)\alpha + 2(\frac{m+d-1}{m+d} + \frac{(G-1)\cdot C}{Gm})n\beta + (\frac{m+d-1}{m+d} + \frac{G-1}{Gm})n\gamma$ |
其中各符号含义为:
- m:最小分组数;
- m + d:最大分组数(d 表示最大与最小分组数之差);
- G:分组数;
- C:组间带宽相对于组内带宽的收敛比;
- α:单次通信的启动开销(时延项);
- β:单位数据的传输时间(带宽项,反比于带宽);
- γ:单位数据的计算时间(计算项);
- n:数据总量。
从公式结构可以直观看出 AHC 的耗时构成(此分析依据文档公式推导,属于从公式结构可推断的结论):
- 时延项$2(\lceil \log(m+d)\rceil + \lceil \log(G)\rceil)\alpha$:由组内 NB 的 $\log(m+d)$ 层级与组间跨 G 个分组的 $\log(G)$ 层级共同决定,呈对数增长,说明 AHC 对大规模分组数的扩展性较好;
- 带宽项$2(\frac{m+d-1}{m+d} + \frac{(G-1)\cdot C}{Gm})n\beta$:组间部分被收敛比 C 放大,C 越大(层间带宽收敛越严重),组间传输代价越高,这也解释了文档中"层次间存在带宽收敛时 AHC 相对收益会更好"的判断前提——收敛场景下,相比单层算法把所有数据压到收敛链路,AHC 仅在"逻辑同号卡"之间搬运经过组内预规约后的数据,收敛链路承载量大幅减少;
- 计算项$(\frac{m+d-1}{m+d} + \frac{G-1}{Gm})n\gamma$:随分组数 G 增加而增加,但被 m 稀释,体现了组内预规约带来的计算分摊效果。
四、在 HCCL 中的配置与源码映射
4.1 环境变量配置
AHC 属于**拓扑组合第 1 层(level1,Server 间通信算法)**的算法类型,通过 HCCL_ALGO 环境变量配置。依据 HCCL_ALGO.md 的说明:
- 适用场景:通信域内 NPU 分布存在多个层次、多个层次间 NPU 对称或非对称分布(即卡数非对称)的场景;当通信域内层次间存在带宽收敛时相对收益会更好。
- 关键约束:当 level1(Server 间通信算法)配置为 "AHC" 时,level2(超节点间通信算法)将自动采用 AHC 算法,无需另行配置;即使 level2 设置了其他算法,这些设置也不会生效。
配置示例(以命令行形式传入):
export HCCL_ALGO="level0:NA;level1:AHC"若需要对特定算子单独配置,可使用HCCL_ALGO=<op>=<level配置>的分段语法,例如:
export HCCL_ALGO="AllReduce=level0:NA;level1:AHC"注意:level0 通常配置为NA(不指定),表示节点内算法由 HCCL 根据拓扑自动选择,这与 alg_env_config.cc 中 "expect: level0:NA;level1: " 的合法格式约束一致。
4.2 源码中的算法类型映射
在仓库源码中,AHC 有完整的类型定义与解析链路:
- 对外算法枚举:alg_type.h 中定义
HCCL_ALGO_TYPE_AHC与HCCL_ALGO_TYPE_AHC_BROKE(AHC_BROKE 为 AHC 的变体,同样属于拓扑组合 1 层算法,见 alg_type.h 中ALG_LEVEL1_AHC与ALG_LEVEL1_AHC_BROKE的注释"拓扑组合1层")。 - 字符串映射:对内算法名映射表中将
ALG_LEVEL1_AHC映射为字符串 "AHC"(alg_type.h)。 - 环境变量解析:alg_env_config.cc 中,解析器
ParserHcclAlgoLevel将配置字符串"AHC"与"AHC_BROKE"分别解析为HCCL_ALGO_TYPE_AHC与HCCL_ALGO_TYPE_AHC_BROKE;同时 alg_env_config.h 中也登记了二者的名称映射。 - 算子侧应用:以 Scatter 算子为例,scatter.cc 在处理
HCCL_ALGO_TYPE_AHC与HCCL_ALGO_TYPE_AHC_BROKE时,会将对应的内部算法类型置为ALG_LEVEL1_AHC/ALG_LEVEL1_AHC_BROKE,进而驱动后续拓扑编排与执行。
从源码结构可以推断,AHC 在 HCCL 内部被纳入"三层次算法类型"(level0 节点内 / level1 Server 间 / level2 超节点间)的层级体系(alg_type.h),其默认的三层组合由TagAlgType构造时初始化为 Whole Ring,当用户通过环境变量显式指定 level1 为 AHC 时,即覆盖该层默认值。
五、与其他算法的关系
AHC 在算法家族中定位为面向非对称层次拓扑的拼接型算法,与同文档体系下的其他算法互补:
- 与 Ring、Mesh 等单层基础算法相比,AHC 解决的是多层级、非对称场景;
- 与 NHR、NB 等层次化算法相比,AHC 不要求各分组卡数一致,且其内部底层原语可以动态选择 NB、NHR、Ring 等实现;
- 与 Pipeline 等同样面向超节点互联的算法相比,AHC 通过"逻辑同号卡"把非对称分组映射为对称子问题,而非依赖对称分桶假设。
关于更广义的"分组内 / 分组间"层次化通信原理,可参考 分级通信原理 以及完整的 集合通信算法介绍 索引。
结语
AHC 是 HCCL 针对带宽收敛 + 卡数非对称双挑战给出的工程化答案:用拓扑分组规避带宽收敛瓶颈,用 LCM 切分与逻辑同号卡化解非对称难题,再用可替换的底层算法(NB/NHR/Ring 等)保证组内组间原语的性能弹性。理解 AHC 的"同号卡拼接"模型,不仅有助于在实际集群(如 64 卡与 128 卡超节点混布场景)中正确配置 HCCL_ALGO 环境变量,也能为设计其他非对称拓扑下的集合通信算法提供直接的参考范式。
【免费下载链接】hccl集合通信库(Huawei Collective Communication Library,简称HCCL)是基于昇腾AI处理器的高性能集合通信库,为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考