尧图网页设计 
HCCL 环境变量 HCCL_UB_MULTI_CHANNEL_NUM 详解CLOS 拓扑下 UB 协议多 channel 并行通信调优【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl导读HCCL_UB_MULTI_CHANNEL_NUM是华为 CANN 集合通信库HCCL提供的通信性能调优环境变量用于在CLOS 拓扑 UB 协议CTP/RTP的通信场景下控制同一对 eid通信实体之间建立的 channel 数量。配置多个 channel 后数据可由多个独立 jetty 并行搬运从而在单 jetty 成为带宽瓶颈时提升通信带宽——其原理与 RoCE 多 QP 机制类似。读完本文你将掌握该变量的取值范围、生效前提、配置方法、底层实现原理、资源约束与性能收益边界并能在实际集群中正确评估与设置该参数。功能描述为 UB 协议通信并行化建立多条 channel在 HCCL 的通信域comm建立过程中HCCL 需要为参与通信的 rank 之间创建通信通道channel。对于采用 CLOS 拓扑并通过 UB 协议包括 CTP——Communication Transport Protocol、RTP——RDMA-like Transport Protocol具体以版本支持为准承载数据搬运的通信场景同一对 eid 之间默认只建立 1 条 channel数据搬运由该 channel 对应的单个 jettyUB 硬件搬运单元完成此时 channel 的搬运能力受单个 jetty 的带宽上限约束。通过配置HCCL_UB_MULTI_CHANNEL_NUM开发者可以要求 HCCL 在同一对 eid 之间建立多条 channel每条 channel 对应一个独立的 jetty多个 jetty 并行搬运数据从而突破单 jetty 的带宽上限提升通信带宽。这一设计思路与 ROCE 网络中的多 QPQueue Pair机制类似——都是通过把数据流拆分为多条并行通路来榨取底层硬件的并发能力。该环境变量需要配置为整数取值范围[1, 16]默认值1即不使能多 channel保持单 jetty 搬运配置示例在启动训练任务前通过 shell 导出该环境变量即可生效export HCCL_UB_MULTI_CHANNEL_NUM4配置后HCCL 会为符合条件的通信对eid 对建立 4 条 channel由 4 个 jetty 并行参与数据搬运。需要注意的是该变量属于任务级环境变量需要在 HCCL 初始化通信域建立之前完成设置且同一任务内所有参与通信的 rank 建议保持一致配置避免通信域建立阶段出现配置不一致问题。使用约束生效前提与限制根据官方文档使用该环境变量必须同时满足以下条件拓扑与协议约束仅在CLOS 拓扑 UB 协议CTP/RTP通信场景下生效引擎约束仅在算法运行于 AICPU 引擎AICPU TS 执行模式时生效算子类型约束仅支持集合通信算子配置通过HcclConfigGetInfo从通信域配置中读取而非 P2P 算子取值范围约束取值超出[1, 16]时HCCL 初始化或读取阶段会报错——解析阶段上报故障码EI0001读取阶段返回HCCL_E_PARA。在配置前建议通过 HCCL_OP_EXPANSION_MODE 等相关文档确认当前算子的执行引擎并确认集群组网为 CLOS 拓扑否则该变量不会生效。产品支持情况该环境变量的支持情况与硬件产品强相关同一产品不同型号也可能存在差异具体如下Ascend 950PR / Ascend 950DT支持Atlas A3 训练系列产品 / Atlas A3 推理系列产品不支持Atlas A2 训练系列产品 / Atlas A2 推理系列产品不支持Atlas 训练系列产品910 系列不支持Atlas 推理系列产品310P 等不支持说明以上支持情况来自 HCCL_UB_MULTI_CHANNEL_NUM.md 的产品支持清单。由于硬件形态持续演进实际部署前请以所购产品对应版本的官方支持矩阵为准。源码视角多 channel 的创建与读取机制为了准确理解该变量的行为可以从本开源仓库的源码中还原其完整链路。1. 配置类型的定义在 src/common/hcomm_dlsym/hccl_host_comm_dl.h 中定义了该配置项的枚举值#define HCCL_CONFIG_TYPE_UB_MULTI_CHANNEL_NUM 2该枚举用于在读取通信域配置时标识UB 多 channel 数量这一配置项是上层封装与底层实现之间的契约。2. 从通信域配置读取多 channel 数量HCCL 通过HcclConfigGetInfo接口从通信域comm中读取该配置。在 src/ops/op_common/op_common.cc 中实现了GetUbMultiChannelNumHcclResult GetUbMultiChannelNum(HcclComm comm, u32 multiChannelNum) { multiChannelNum 1; // 默认值不使能多 channel auto hcommFunction ops_hccl::DlHcommFunction::GetInstance(); if (!hcommFunction.dlHcclConfigGetInfo) { HCCL_INFO([GetUbMultiChannelNum] HcclConfigGetInfo not supported, use default.); return HCCL_SUCCESS; } u32 cfgNum 0; uint32_t infoLen sizeof(u32); HcclResult ret hcommFunction.dlHcclConfigGetInfo( comm, static_castHcclConfigType(HCCL_CONFIG_TYPE_UB_MULTI_CHANNEL_NUM), infoLen, cfgNum); if (ret ! HCCL_SUCCESS) { HCCL_WARNING([GetUbMultiChannelNum] HcclConfigGetInfo failed, ret[%d], use default., ret); return HCCL_SUCCESS; } multiChannelNum cfgNum; return HCCL_SUCCESS; }该实现体现了两个关键设计优雅降级当HcclConfigGetInfo接口不可用例如运行环境不支持或读取失败时不会中断流程而是回退到默认值1即不使能多 channel保证通信功能可用默认值兜底变量默认值1在代码层面通过multiChannelNum 1显式兜底与文档描述一致。3. channel 描述符的复制Duplicate多 channel 的核心机制在于通信域建立阶段对 channel 描述符HcclChannelDesc的复制。在 src/ops/op_common/algorithm/executor/channel/channel.cc 中static bool IsUbMultiChannelProtocol(CommProtocol protocol) { if (protocol CommProtocol::COMM_PROTOCOL_UB_CTP) { return true; } #if CANN_VERSION_NUM CANN_VERSION(9, 2, 0) if (protocol CommProtocol::COMM_PROTOCOL_UB_RTP) { return true; } #endif return false; } static void DuplicateUbMultiChannelDescs(std::vectorHcclChannelDesc channels, size_t channelCountBefore, u32 multiChannelNum) { if (multiChannelNum 1) { return; } std::vectorHcclChannelDesc newChannels(channels.begin() channelCountBefore, channels.end()); for (const auto desc : newChannels) { u32 duplicateCount (IsUbMultiChannelProtocol(desc.channelProtocol)) ? (multiChannelNum - 1) : 0; for (u32 n 0; n duplicateCount; n) { channels.push_back(desc); } } }这里可以观察到几个重要实现细节协议门控只有 channel 使用的协议为 UB 协议族CTP以及 CANN 9.2.0 起加入的 RTP由编译宏CANN_VERSION_NUM CANN_VERSION(9, 2, 0)控制时才会进行复制非 UB 协议的 channel 不会被多复制这与仅在 UB 协议场景生效的约束一一对应复制逻辑对每条新建立的 channel额外复制multiChannelNum - 1份描述符从而在channelCountBefore之后追加出multiChannelNum条同构 channel每条 channel 在底层对应一个独立 jetty线程/进程级并行多 channel 建立后数据可在多个 channel 上并行搬运提升聚合带宽。4. 多 channel 的触发条件复制动作发生在CalcChannelRequestNhrNHR 算法 channel 计算中见 src/ops/op_common/algorithm/executor/channel/channel.cc。其中关键代码如下u32 multiChannelNum 1; if (param.engine CommEngine::COMM_ENGINE_AICPU_TS) { CHK_RET(GetUbMultiChannelNum(comm, multiChannelNum)); } ... DuplicateUbMultiChannelDescs(channels, channelCountBefore, multiChannelNum);可以看到只有当算子的执行引擎为COMM_ENGINE_AICPU_TSAICPU 时间戳引擎即 AICPU 执行模式时才会读取HCCL_UB_MULTI_CHANNEL_NUM并执行多 channel 复制其他引擎如 AIV、CCU下multiChannelNum保持默认值 1不会触发多 channel。这与文档中算法运行于 AICPU 引擎时生效的约束完全吻合也从代码层面解释了为何该变量对 AIV/CCU 引擎无效。此外从 src/ops/op_common/algorithm/executor/channel/channel.h 的接口列表中可以看到ProcessLinksForChannelMutiJetty、CalcChannelRequestNhrMultiJetty、CalcChannelRequestNhrMultiJettyUbx、CalcChannelRequestMeshClosMultiJetty等多个与多 jetty 相关的 channel 计算接口说明多 jetty/多 channel 机制在代码层面被广泛应用于 NHR、Mesh、CLOS 等多种拓扑形态的 channel 建立流程中本文所述变量是该机制面向用户开放的一个可配置入口。5. 关联的多 jetty 算法模板在算法模板层面仓库中存在大量multi_jetty命名实现例如src/ops/all_gather/algorithm/template/ccu/ccu_temp_all_gather_nhr_1D_multi_jetty_mem2mem.ccsrc/ops/all_reduce/algorithm/template/ccu/ccu_kernel_all_reduce_nhr_mem2mem_1D_multi_jetty.ccsrc/ops/reduce_scatter/algorithm/template/ccu/ccu_temp_reduce_scatter_nhr_1D_multi_jetty_mem2mem.ccsrc/ops/all_to_all_v/algorithm/template/ccu/ccu_temp_all_to_all_v_mesh_1D_multi_jetty.cc这些模板与多 channel 机制共同构成了多 jetty 并行搬运的软件实现面channel 描述符复制保证通信域层面具备多条并行的通信链路而多 jetty 算法模板则负责在算子执行层面按多条 jetty 拆分与调度数据搬运。6. 多 channel 与算法选择的联动值得注意的还有算法选择层面的联动逻辑。在 src/ops/all_to_all_v/selector/alltoall_auto_selector.cc 中定义了constexpr uint64_t ALLTOALL_ENABLE_MULTI_CHANNEL_DATA_SIZE_LIMIT 150 * 1024 * 1024;并在数据量超过该阈值时启用多 channel 相关算法alltoall_auto_selector.cc。这说明 HCCL 在选择器层面同样会根据数据量大小决定是否启用多 channel 路径——多 channel 并非总是最优而是主要面向大数据量、单 jetty 成为瓶颈的场景。性能调优建议何时该调大 channel 数量1. 资源开销每个 channel 都占用 jetty 等硬件资源每个 channel 在底层均对应一个独立的 jetty 等硬件资源。channel 数量配置过大时会挤压同一设备上其它通信域的资源可能导致其它通信域带宽下降或资源申请失败。因此官方建议按需设置例如设置为2或4而不是盲目配置最大值16。2. 性能收益边界只有单 jetty 是瓶颈时才有效多 channel 的收益来源于多个 jetty 并行搬运对单 jetty 带宽上限的突破。因此若单个 jetty 的搬运能力是当前通信带宽的瓶颈例如大消息、多 rank 聚合通信导致单 jetty 吞吐饱和增加 channel 数量可以有效提升通信带宽若单个 jetty 已经达到链路带宽上限例如网络链路本身成为瓶颈多 channel 无法带来额外增益配置该变量只会徒增 jetty 资源占用。因此配置该变量的正确姿势是结合性能验证结果Profiling 采集的通信带宽、jetty 利用率等指标判断瓶颈位置再决定是否调大以及调大到多少。可以参考 性能分析指南 中的采集与分析流程先量化当前瓶颈再进行针对性调优。常见问题FAQQ1配置了该变量但没有效果请依次检查① 集群是否为 CLOS 拓扑② 通信是否走 UB 协议CTP/RTP③ 算法是否运行在 AICPU 引擎可查看 HCCL_OP_EXPANSION_MODE 相关配置④ 当前产品是否支持见上文产品支持情况。任一条件不满足变量都不会生效HCCL 会按默认值 1 运行。Q2取值超出 [1,16] 会发生什么取值非法时HCCL 初始化或读取阶段会报错解析阶段上报故障码EI0001环境变量配置错误读取阶段返回HCCL_E_PARA参数错误。若遇到 EI0001可参考 env_config_error_EI0001_troubleshooting.md 进行排查。Q3P2P 算子如 Send/Recv可以使用该变量吗不可以。该变量仅支持集合通信算子配置通过HcclConfigGetInfo从通信域配置中读取见 hccl_host_comm_dl.hP2P 通信不在支持范围内。Q4调大 channel 数量是否一定能提升性能不一定。多 channel 只有在单个 jetty 成为带宽瓶颈时才有效若链路带宽已饱和多 channel 无增益反而增加 jetty 等硬件资源占用可能影响其它通信域。建议从2或4开始实验并结合性能数据验证收益。总结HCCL_UB_MULTI_CHANNEL_NUM是 CLOS 拓扑 UB 协议CTP/RTP通信场景下、AICPU 引擎运行的集合通信算子的专用带宽调优开关取值范围[1, 16]默认值1。它通过在通信域建立阶段对 UB 协议 channel 描述符进行复制channel.cc使同一对 eid 之间建立多条 channel、由多个 jetty 并行搬运数据从而突破单 jetty 带宽瓶颈。其收益边界清晰仅在单 jetty 为瓶颈时有效配置过大反而会挤压其它通信域的 jetty 资源。当前该特性仅得到 Ascend 950 系列产品的支持建议开发者结合自身硬件形态、引擎模式与性能实测数据按需如2或4谨慎配置。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 HCCL 环境变量 HCCL_UB_MULTI_CHANNEL_NUM 详解：CLOS 拓扑下 UB 协议多 channel 并行通信调优
HCCL 环境变量 HCCL_UB_MULTI_CHANNEL_NUM 详解CLOS 拓扑下 UB 协议多 channel 并行通信调优【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl导读HCCL_UB_MULTI_CHANNEL_NUM是华为 CANN 集合通信库HCCL提供的通信性能调优环境变量用于在CLOS 拓扑 UB 协议CTP/RTP的通信场景下控制同一对 eid通信实体之间建立的 channel 数量。配置多个 channel 后数据可由多个独立 jetty 并行搬运从而在单 jetty 成为带宽瓶颈时提升通信带宽——其原理与 RoCE 多 QP 机制类似。读完本文你将掌握该变量的取值范围、生效前提、配置方法、底层实现原理、资源约束与性能收益边界并能在实际集群中正确评估与设置该参数。功能描述为 UB 协议通信并行化建立多条 channel在 HCCL 的通信域comm建立过程中HCCL 需要为参与通信的 rank 之间创建通信通道channel。对于采用 CLOS 拓扑并通过 UB 协议包括 CTP——Communication Transport Protocol、RTP——RDMA-like Transport Protocol具体以版本支持为准承载数据搬运的通信场景同一对 eid 之间默认只建立 1 条 channel数据搬运由该 channel 对应的单个 jettyUB 硬件搬运单元完成此时 channel 的搬运能力受单个 jetty 的带宽上限约束。通过配置HCCL_UB_MULTI_CHANNEL_NUM开发者可以要求 HCCL 在同一对 eid 之间建立多条 channel每条 channel 对应一个独立的 jetty多个 jetty 并行搬运数据从而突破单 jetty 的带宽上限提升通信带宽。这一设计思路与 ROCE 网络中的多 QPQueue Pair机制类似——都是通过把数据流拆分为多条并行通路来榨取底层硬件的并发能力。该环境变量需要配置为整数取值范围[1, 16]默认值1即不使能多 channel保持单 jetty 搬运配置示例在启动训练任务前通过 shell 导出该环境变量即可生效export HCCL_UB_MULTI_CHANNEL_NUM4配置后HCCL 会为符合条件的通信对eid 对建立 4 条 channel由 4 个 jetty 并行参与数据搬运。需要注意的是该变量属于任务级环境变量需要在 HCCL 初始化通信域建立之前完成设置且同一任务内所有参与通信的 rank 建议保持一致配置避免通信域建立阶段出现配置不一致问题。使用约束生效前提与限制根据官方文档使用该环境变量必须同时满足以下条件拓扑与协议约束仅在CLOS 拓扑 UB 协议CTP/RTP通信场景下生效引擎约束仅在算法运行于 AICPU 引擎AICPU TS 执行模式时生效算子类型约束仅支持集合通信算子配置通过HcclConfigGetInfo从通信域配置中读取而非 P2P 算子取值范围约束取值超出[1, 16]时HCCL 初始化或读取阶段会报错——解析阶段上报故障码EI0001读取阶段返回HCCL_E_PARA。在配置前建议通过 HCCL_OP_EXPANSION_MODE 等相关文档确认当前算子的执行引擎并确认集群组网为 CLOS 拓扑否则该变量不会生效。产品支持情况该环境变量的支持情况与硬件产品强相关同一产品不同型号也可能存在差异具体如下Ascend 950PR / Ascend 950DT支持Atlas A3 训练系列产品 / Atlas A3 推理系列产品不支持Atlas A2 训练系列产品 / Atlas A2 推理系列产品不支持Atlas 训练系列产品910 系列不支持Atlas 推理系列产品310P 等不支持说明以上支持情况来自 HCCL_UB_MULTI_CHANNEL_NUM.md 的产品支持清单。由于硬件形态持续演进实际部署前请以所购产品对应版本的官方支持矩阵为准。源码视角多 channel 的创建与读取机制为了准确理解该变量的行为可以从本开源仓库的源码中还原其完整链路。1. 配置类型的定义在 src/common/hcomm_dlsym/hccl_host_comm_dl.h 中定义了该配置项的枚举值#define HCCL_CONFIG_TYPE_UB_MULTI_CHANNEL_NUM 2该枚举用于在读取通信域配置时标识UB 多 channel 数量这一配置项是上层封装与底层实现之间的契约。2. 从通信域配置读取多 channel 数量HCCL 通过HcclConfigGetInfo接口从通信域comm中读取该配置。在 src/ops/op_common/op_common.cc 中实现了GetUbMultiChannelNumHcclResult GetUbMultiChannelNum(HcclComm comm, u32 multiChannelNum) { multiChannelNum 1; // 默认值不使能多 channel auto hcommFunction ops_hccl::DlHcommFunction::GetInstance(); if (!hcommFunction.dlHcclConfigGetInfo) { HCCL_INFO([GetUbMultiChannelNum] HcclConfigGetInfo not supported, use default.); return HCCL_SUCCESS; } u32 cfgNum 0; uint32_t infoLen sizeof(u32); HcclResult ret hcommFunction.dlHcclConfigGetInfo( comm, static_castHcclConfigType(HCCL_CONFIG_TYPE_UB_MULTI_CHANNEL_NUM), infoLen, cfgNum); if (ret ! HCCL_SUCCESS) { HCCL_WARNING([GetUbMultiChannelNum] HcclConfigGetInfo failed, ret[%d], use default., ret); return HCCL_SUCCESS; } multiChannelNum cfgNum; return HCCL_SUCCESS; }该实现体现了两个关键设计优雅降级当HcclConfigGetInfo接口不可用例如运行环境不支持或读取失败时不会中断流程而是回退到默认值1即不使能多 channel保证通信功能可用默认值兜底变量默认值1在代码层面通过multiChannelNum 1显式兜底与文档描述一致。3. channel 描述符的复制Duplicate多 channel 的核心机制在于通信域建立阶段对 channel 描述符HcclChannelDesc的复制。在 src/ops/op_common/algorithm/executor/channel/channel.cc 中static bool IsUbMultiChannelProtocol(CommProtocol protocol) { if (protocol CommProtocol::COMM_PROTOCOL_UB_CTP) { return true; } #if CANN_VERSION_NUM CANN_VERSION(9, 2, 0) if (protocol CommProtocol::COMM_PROTOCOL_UB_RTP) { return true; } #endif return false; } static void DuplicateUbMultiChannelDescs(std::vectorHcclChannelDesc channels, size_t channelCountBefore, u32 multiChannelNum) { if (multiChannelNum 1) { return; } std::vectorHcclChannelDesc newChannels(channels.begin() channelCountBefore, channels.end()); for (const auto desc : newChannels) { u32 duplicateCount (IsUbMultiChannelProtocol(desc.channelProtocol)) ? (multiChannelNum - 1) : 0; for (u32 n 0; n duplicateCount; n) { channels.push_back(desc); } } }这里可以观察到几个重要实现细节协议门控只有 channel 使用的协议为 UB 协议族CTP以及 CANN 9.2.0 起加入的 RTP由编译宏CANN_VERSION_NUM CANN_VERSION(9, 2, 0)控制时才会进行复制非 UB 协议的 channel 不会被多复制这与仅在 UB 协议场景生效的约束一一对应复制逻辑对每条新建立的 channel额外复制multiChannelNum - 1份描述符从而在channelCountBefore之后追加出multiChannelNum条同构 channel每条 channel 在底层对应一个独立 jetty线程/进程级并行多 channel 建立后数据可在多个 channel 上并行搬运提升聚合带宽。4. 多 channel 的触发条件复制动作发生在CalcChannelRequestNhrNHR 算法 channel 计算中见 src/ops/op_common/algorithm/executor/channel/channel.cc。其中关键代码如下u32 multiChannelNum 1; if (param.engine CommEngine::COMM_ENGINE_AICPU_TS) { CHK_RET(GetUbMultiChannelNum(comm, multiChannelNum)); } ... DuplicateUbMultiChannelDescs(channels, channelCountBefore, multiChannelNum);可以看到只有当算子的执行引擎为COMM_ENGINE_AICPU_TSAICPU 时间戳引擎即 AICPU 执行模式时才会读取HCCL_UB_MULTI_CHANNEL_NUM并执行多 channel 复制其他引擎如 AIV、CCU下multiChannelNum保持默认值 1不会触发多 channel。这与文档中算法运行于 AICPU 引擎时生效的约束完全吻合也从代码层面解释了为何该变量对 AIV/CCU 引擎无效。此外从 src/ops/op_common/algorithm/executor/channel/channel.h 的接口列表中可以看到ProcessLinksForChannelMutiJetty、CalcChannelRequestNhrMultiJetty、CalcChannelRequestNhrMultiJettyUbx、CalcChannelRequestMeshClosMultiJetty等多个与多 jetty 相关的 channel 计算接口说明多 jetty/多 channel 机制在代码层面被广泛应用于 NHR、Mesh、CLOS 等多种拓扑形态的 channel 建立流程中本文所述变量是该机制面向用户开放的一个可配置入口。5. 关联的多 jetty 算法模板在算法模板层面仓库中存在大量multi_jetty命名实现例如src/ops/all_gather/algorithm/template/ccu/ccu_temp_all_gather_nhr_1D_multi_jetty_mem2mem.ccsrc/ops/all_reduce/algorithm/template/ccu/ccu_kernel_all_reduce_nhr_mem2mem_1D_multi_jetty.ccsrc/ops/reduce_scatter/algorithm/template/ccu/ccu_temp_reduce_scatter_nhr_1D_multi_jetty_mem2mem.ccsrc/ops/all_to_all_v/algorithm/template/ccu/ccu_temp_all_to_all_v_mesh_1D_multi_jetty.cc这些模板与多 channel 机制共同构成了多 jetty 并行搬运的软件实现面channel 描述符复制保证通信域层面具备多条并行的通信链路而多 jetty 算法模板则负责在算子执行层面按多条 jetty 拆分与调度数据搬运。6. 多 channel 与算法选择的联动值得注意的还有算法选择层面的联动逻辑。在 src/ops/all_to_all_v/selector/alltoall_auto_selector.cc 中定义了constexpr uint64_t ALLTOALL_ENABLE_MULTI_CHANNEL_DATA_SIZE_LIMIT 150 * 1024 * 1024;并在数据量超过该阈值时启用多 channel 相关算法alltoall_auto_selector.cc。这说明 HCCL 在选择器层面同样会根据数据量大小决定是否启用多 channel 路径——多 channel 并非总是最优而是主要面向大数据量、单 jetty 成为瓶颈的场景。性能调优建议何时该调大 channel 数量1. 资源开销每个 channel 都占用 jetty 等硬件资源每个 channel 在底层均对应一个独立的 jetty 等硬件资源。channel 数量配置过大时会挤压同一设备上其它通信域的资源可能导致其它通信域带宽下降或资源申请失败。因此官方建议按需设置例如设置为2或4而不是盲目配置最大值16。2. 性能收益边界只有单 jetty 是瓶颈时才有效多 channel 的收益来源于多个 jetty 并行搬运对单 jetty 带宽上限的突破。因此若单个 jetty 的搬运能力是当前通信带宽的瓶颈例如大消息、多 rank 聚合通信导致单 jetty 吞吐饱和增加 channel 数量可以有效提升通信带宽若单个 jetty 已经达到链路带宽上限例如网络链路本身成为瓶颈多 channel 无法带来额外增益配置该变量只会徒增 jetty 资源占用。因此配置该变量的正确姿势是结合性能验证结果Profiling 采集的通信带宽、jetty 利用率等指标判断瓶颈位置再决定是否调大以及调大到多少。可以参考 性能分析指南 中的采集与分析流程先量化当前瓶颈再进行针对性调优。常见问题FAQQ1配置了该变量但没有效果请依次检查① 集群是否为 CLOS 拓扑② 通信是否走 UB 协议CTP/RTP③ 算法是否运行在 AICPU 引擎可查看 HCCL_OP_EXPANSION_MODE 相关配置④ 当前产品是否支持见上文产品支持情况。任一条件不满足变量都不会生效HCCL 会按默认值 1 运行。Q2取值超出 [1,16] 会发生什么取值非法时HCCL 初始化或读取阶段会报错解析阶段上报故障码EI0001环境变量配置错误读取阶段返回HCCL_E_PARA参数错误。若遇到 EI0001可参考 env_config_error_EI0001_troubleshooting.md 进行排查。Q3P2P 算子如 Send/Recv可以使用该变量吗不可以。该变量仅支持集合通信算子配置通过HcclConfigGetInfo从通信域配置中读取见 hccl_host_comm_dl.hP2P 通信不在支持范围内。Q4调大 channel 数量是否一定能提升性能不一定。多 channel 只有在单个 jetty 成为带宽瓶颈时才有效若链路带宽已饱和多 channel 无增益反而增加 jetty 等硬件资源占用可能影响其它通信域。建议从2或4开始实验并结合性能数据验证收益。总结HCCL_UB_MULTI_CHANNEL_NUM是 CLOS 拓扑 UB 协议CTP/RTP通信场景下、AICPU 引擎运行的集合通信算子的专用带宽调优开关取值范围[1, 16]默认值1。它通过在通信域建立阶段对 UB 协议 channel 描述符进行复制channel.cc使同一对 eid 之间建立多条 channel、由多个 jetty 并行搬运数据从而突破单 jetty 带宽瓶颈。其收益边界清晰仅在单 jetty 为瓶颈时有效配置过大反而会挤压其它通信域的 jetty 资源。当前该特性仅得到 Ascend 950 系列产品的支持建议开发者结合自身硬件形态、引擎模式与性能实测数据按需如2或4谨慎配置。【免费下载链接】hccl集合通信库Huawei Collective Communication Library简称HCCL是基于昇腾AI处理器的高性能集合通信库为计算集群提供高性能、高可靠的通信方案项目地址: https://gitcode.com/cann/hccl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考