HCCL Pipeline分级流水算法深度解析原理、时序编排与耗时模型【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl导读Pipeline分级流水算法是 CANN HCCLHuawei Collective Communication Library中面向分级网络拓扑设计的高性能集合通信算法。它通过挖掘通信算法内部的数据依赖、将数据切块后在 Server 内/Server 间链路上流水并发传输解决传统分级算法中两级链路轮流空闲造成的带宽利用率不足问题。本文以官方算法文档为主体结合仓库源码中 AllGather、AllReduce、ReduceScatter 的 OmniPipe 流水执行器实现与算法类型定义完整讲解 Pipeline 算法的动机、传输时序编排、LocalCopy 语义与 α–β 耗时模型并给出基于 HCCL_ALGO 环境变量的实际配置方法。Pipeline 算法要解决的问题分级网络架构下的带宽浪费为降低网络流量冲突AI 计算集群普遍采用分级网络架构Server 内通过直接连接的电缆如 HCCS/UBX 等高速片间链路完成互联带宽高、时延低Server 间同号卡通过交换机如 RoCE互联带宽相对受限。为适配这种拓扑传统集合通信采用分级算法策略将全局通信操作分解为多个层级的局部操作分阶段、分层递进执行。以 AllGather 算子为例常规分级做法是先在 Server 间执行一次同号卡间的 AllGather再在 Server 内执行一次 AllGather完成整个集群的数据集合。然而这种先外后内或先内后外的串行分级存在明显的链路浪费当 Server 间进行数据传输时Server 内的链路处于空闲状态反之亦然两级带宽无法同时被利用。Pipeline 的核心思想HCCL 采用细粒度的分级流水Pipeline算法解决上述问题将通信数据划分为多个细粒度数据块slice挖掘通信算法本身的数据依赖关系让 Server 间传输与 Server 内传输在时间上**重叠overlap**执行通过流水并行的方式让两级链路始终处于忙碌状态从而最大化带宽利用率。从源码视角看Pipeline 在 HCCL 中对应 src/common/alg_type.h 中的HCCL_ALGO_TYPE_PIPELINE算法类型以及 Server 间/超节点间层级枚举AlgTypeLevel1::ALG_LEVEL1_PIPELINE其名称映射表中明确登记为字符串pipeline见 HCCL_ALGO_LEVEL1_NAME_MAP这正与HCCL_ALGO环境变量中 level1/level2 的可配置取值保持一致。AllGather 算子的 Pipeline 时序编排算法组合Server 间 Ring Server 内 FullMesh以 AllGather 为例HCCL 选择Server 间通信使用 Ring 算法、Server 内通信使用 FullMesh 算法的组合整体流水过程如下图所示。图中绿色数据块从 Rank5 被发送到 Rank1 上图中仅描述部分 Rank 的行为其它 Rank 对称处理随后的流水步骤如下Ring 标准步Rank1 继续向 Rank3 发送绿色数据块Ring 算法标准步骤流水重叠步与此同时Rank1 向同 Server 中的 Rank0 发送绿色数据块循环推进继续执行 Ring 算法每一步在进行 Server 间数据传输的同时还会向 Server 内其它 Rank 传输上一步接收到的数据块收尾Ring 算法的最后一个步骤结束后仅需要在 Server 内再进行一次数据块的传输即可完成全部算法步骤。一个值得注意的优化细节是Rank 初始数据块的 Server 内传输操作可以隐藏在 Ring 算法的第一步中进行从而进一步压缩整体耗时。Rank0 视角的传输任务编排在 Rank0 视角上全部传输任务可按下图编排其中LocalCopy 操作仅在输入输出内存不同的场景中执行用于将数据块从输入内存移动到输出内存在输入输出内存相同in-place的场景中该操作无需执行。源码中的流水执行印证Pipeline 的执行逻辑在仓库中由OmniPipe 流水执行器落地例如ins_v2_all_gather_omnipipe_executor.ccInsV2AllGatherOmniPipeExecutor::OrchestrateLoop在日志中输出start all-gather pipeline loops负责编排 AllGather 的流水循环见第 529 行并在循环内调用LocalCopy(controlThread_, src, dst)完成数据块的本地搬运见第 675 行。ins_v2_all_reduce_omnipipe_executor.cc 与 ins_v2_reduce_scatter_omnipipe_executor.cc分别为 AllReduce、ReduceScatter 提供对称的流水编排后者同样输出start reduce-scatter pipeline loops见第 553 行。从OrchestrateLoop的代码可以看到流水实现的关键要素分级带宽建模执行器为 level0/level1/level2 分别维护等价带宽endpointAttrBw并按每级 rank 数折算单链路等价带宽eqBw1 / (rankSizeLevel_ - 1)用于切分数据块循环分块loop根据 scratch 内存上限maxTmpMemSize_与 UBX 传输上限计算maxCountPerLoop进而得到loopTimes将大数据量拆分为多个 loop 流水执行尾块tail slice单独计算 slice 信息切分计算调用CalcAGOmniPipeSliceInfo计算每个 loop 的 slice 布局并为 LocalCopy 单独计算一套 slice 参数localcopySliceParam印证了文档中LocalCopy 需要单独编排的说明。耗时计算模型HCCL 采用α–β 模型Hockney 模型评估算法耗时Pipeline 算法中各操作的耗时如下表所示。表1Pipeline 算法中各操作计算耗时操作耗时ReduceScatter$max(\frac{s}{p} * \beta_{inter} \alpha_{inter} , \frac{s}{p} * \beta_{intra} \alpha_{intra}) * (p_{inter} -1) \frac{s}{p} * \beta_{intra} \alpha_{intra}$AllGather$max(\frac{s}{p} * \beta_{inter} \alpha_{inter} , \frac{s}{p} * \beta_{intra} \alpha_{intra}) * (p_{inter} -1) \frac{s}{p} * \beta_{intra} \alpha_{intra}$AllReduce$2*(max(\frac{s}{p} * \beta_{inter} \alpha_{inter}, \frac{s}{p} * \beta_{intra}\alpha_{intra} ) * (p_{inter}-1) \frac{s}{p} * \beta_{intra} \alpha_{intra})$各符号含义p完成集合通信的总卡数p_interServer 数流水跨度的层级规模s集合通信操作总数据量Byteβ_interServer 间链路每 Byte 数据传输耗时s/Byteβ_intraServer 内链路每 Byte 数据传输耗时s/Byteα_interServer 间链路传输固定耗时sα_intraServer 内链路传输固定耗时s。对公式的解读要点瓶颈层决定单步耗时每个流水步的耗时由 Server 内/Server 间链路中较慢的一方决定因此公式中对两项取max流水步数为 (p_inter − 1)即 Server 间 Ring 的步数流水过程中每步都顺带完成 Server 内传输收尾步全部 Ring 步结束后仍需一次 Server 内传输$\frac{s}{p} * \beta_{intra} \alpha_{intra}$但初始数据块的 Server 内传输已隐藏在第一步中故只需在末尾补一次AllReduce 加倍AllReduce 可拆解为 ReduceScatter 与 AllGather 两个对称阶段因此整体耗时约为单阶段的两倍。关于 α、β 模型的通用背景可参见 算法简介 中的耗时评估一节α 为节点间固定时延sβ 为每 Byte 数据传输耗时s/Byte单步传输 n Byte 数据的耗时为 $D \alpha n\beta n\gamma$γ 为每 Byte 归约计算耗时。适用范围与配置方法适用场景根据 算法简介 与 HCCL_ALGO 文档的说明Pipeline 算法可并发使用 Server 内与 Server 间链路或超节点内与超节点间链路适合通信数据量较大且通信域内每机每个 Server/超节点包含多卡的场景与之相对的当通信数据量较小、Server 个数较少、网络存在明显拥塞等 Pipeline 不适用的场景下HCCL 自适应算法会选择 Ring、RHD、NHR、NB 等其它算法。通过 HCCL_ALGO 指定 Pipeline默认情况下 HCCL 会根据产品形态、数据量和 Server 个数自适应选择算法一般无需用户手工指定。若需显式指定 Pipeline 算法可通过环境变量 HCCL_ALGO 配置。全局配置方式export HCCL_ALGOlevel0:NA;level1:pipelinelevel0代表 Server 内通信算法当前版本仅支持配置为NA由 HCCL 内部根据硬件拓扑自动选择 Mesh、Ring 等level1代表 Server 间通信算法pipeline为合法取值level2代表超节点间通信算法同样支持pipeline可并发使用超节点内与超节点间链路适合每个超节点包含多卡的场景。按算子类型配置方式# AllGather 与 AllGatherV 使用 Pipeline 算法其他算子自适应选择 export HCCL_ALGOallgatherlevel0:NA;level1:pipeline其中算子类型支持allgather对应 AllGather/AllGatherV、reducescatter对应 ReduceScatter/ReduceScatterV、allreduce、broadcast、reduce、scatter、alltoall对应 AlltoAll/AlltoAllV/AlltoAllVC等多个算子之间使用/分隔。注意事项一旦通过 HCCL_ALGO 指定了 Server 间或超节点间算法自适应算法选择功能不再生效以用户指定为准在某些通信算子中当使用特定类型的 AI 处理器且数据量较小时通信算法仍由 HCCL 自适应选择不受该环境变量控制若通过HcclCommConfig的hcclAlgo参数在通信域粒度指定了算法则以通信域粒度的配置优先不同产品支持的 Server 间/超节点间算法集合不同配置前请查阅 Server间通信算法支持度列表 与 超节点间通信算法支持度列表。与其它分级算法的关系Pipeline 是 HCCL 分级通信策略中的一种实现形态。关于分级通信的整体框架可参见 分级通信原理以 Atlas A2 训练系列产品/Atlas A2 推理系列产品的单算子模式、节点内/节点间两级拓扑为例各算子的分级阶段如下AllGatherServer 内 AllGather → Server 间 AllGatherReduceScatterServer 间 ReduceScatter → Server 内 ReduceScatterAllReduceServer 内 ReduceScatter → Server 间 AllReduce → Server 内 AllGather。Pipeline 与普通分级算法的区别在于普通分级是串行利用两级链路先外后内或先内后外而 Pipeline 通过数据块流水让两级链路并行工作代价是需要更精细的切分编排与更复杂的执行逻辑——这正是仓库中 OmniPipe 流水执行器所承担的工作。此外HCCL 还提供了 Mesh、Ring、RHD、NHR、NB、Pairwise、AHC 等其它拓扑算法分别适配不同的网络拓扑、通信数据量与硬件资源完整算法清单可参见 算法简介。总结Pipeline 算法是 HCCL 面向分级网络拓扑的核心性能优化手段动机消除分级算法中 Server 内/Server 间链路轮流空闲造成的带宽浪费机制将数据细粒度切块在 Ring 等 Server 间算法每步传输的同时流水化地完成 Server 内传输仅需在收尾时补一次 Server 内传输且初始块的 Server 内传输可隐藏在第一步中LocalCopy仅在输入输出内存不同非 in-place时执行将数据块从输入内存搬运到输出内存耗时模型单步耗时由 Server 内/Server 间链路中较慢者决定取 max流水步数为 Server 数减一AllReduce 因拆解为 ReduceScatter 与 AllGather 两阶段而整体加倍使用方式默认自适应选择大数据量、每机多卡场景下可通过HCCL_ALGOlevel0:NA;level1:pipeline显式启用。如需深入理解实现细节可进一步阅读 ins_v2_all_gather_omnipipe_executor.cc、ins_v2_all_reduce_omnipipe_executor.cc 与 ins_v2_reduce_scatter_omnipipe_executor.cc 中的流水编排逻辑以及 alg_type.h 中的算法类型定义。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考