昇腾CANN集群通信库hcomm：多机分布式训练的NCCL兼容通信方案

前言

做多机多卡分布式训练的工程师对NCCL不会陌生——NVIDIA生态里，NCCL几乎是多卡通信的默认选择，PyTorch的DistributedDataParallel底层就是调NCCL做梯度同步。迁移到昇腾NPU之后，最大的顾虑之一就是：我原来基于NCCL写的训练代码，要不要全部重写通信部分？hcomm就是昇腾CANN生态里回答这个问题的通信库——它提供了和NCCL兼容的API接口，让原有的分布式训练代码可以最小化改动地迁移到昇腾NPU上运行。CANN开源社区的hcomm仓库托管在atomgit.com/cann上，是昇腾多机集群通信能力的关键组件。

hcomm要解决的问题

先明确一个层次关系：昇腾CANN通信体系里有三个库——HCCL、hcomm、shmem。HCCL是集合通信库，提供AllReduce、Broadcast这些高级通信原语；shmem是共享内存通信库，提供点对点的单边读写；hcomm是集群通信库，提供多机多卡间的通信能力，同时兼容NCCL的API接口。

那hcomm和HCCL是什么关系？HCCL是hcomm的底层实现。hcomm可以理解为HCCL的上层封装——它把HCCL的集合通信能力包装成了NCCL兼容的接口形式，同时增加了多机组网的路由管理和拓扑感知能力。在单机多卡场景下，hcomm和HCCL的功能基本等价；在多机场景下，hcomm多了跨机组网的路由和调度能力。

NCCL兼容层的设计思路

hcomm最核心的设计目标是NCCL API兼容。这意味着什么？

NCCL的编程模型是这样的：初始化ncclComm_t通信子 → 在通信子内调用ncclAllReduce/ncclBroadcast等集合通信操作 → 销毁通信子。所有操作都通过ncclComm_t句柄来管理，通信子内包含了参与通信的GPU拓扑信息和路由策略。

hcomm复用了这套编程模型，把ncclComm_t替换为hccComm_t，API签名尽量保持一致。来看一个对比：

// NCCL原始代码ncclComm_tcomm;ncclCommInitRank(&comm,world_size,nccl_id,rank);ncclAllReduce(sendbuf,recvbuf,count,ncclFloat,ncclSum,comm,stream);ncclCommDestroy(comm);// hcomm兼容代码// 只需要把nccl前缀换成hcc，其余参数和调用方式完全一致hccComm_tcomm;hccCommInitRank(&comm,world_size,hcc_id,rank);hccAllReduce(sendbuf,recvbuf,count,hccFloat,hccSum,comm,stream);hccCommDestroy(comm);

API层面的迁移成本非常低——基本就是全局替换nccl为hcc。但底层实现完全不同：NCCL的通信走NVIDIA GPU的NVLink和PCIe，hcomm的通信走昇腾NPU的HCCS和RoCE。

hcomm在兼容NCCL接口的同时，也做了一些昇腾特有的扩展。比如hccCommInitRank支持指定通信域的物理拓扑——你可以告诉hcomm当前集群的NPU卡是如何通过HCCS和RoCE连接的，hcomm会根据物理拓扑选择最优的通信路径。NCCL也有类似的能力（通过NCCL_TOPO_FILE环境变量），但hcomm的拓扑描述格式是针对昇腾硬件设计的，支持HCCS环、RoCE交换机等多种连接方式。

多机组网的路由策略

多机场景下，hcomm的路由策略直接决定了通信性能。hcomm内部维护了一张物理拓扑图，每个节点记录了本机NPU卡的HCCS连接关系和跨机RoCE连接关系。

通信路径的选择遵循一个基本原则：能走HCCS就不走RoCE。HCCS是昇腾NPU卡之间的片间互连，带宽约392GB/s（双向），延迟在微秒级；RoCE是基于以太网的RDMA协议，带宽取决于网卡规格（100Gbps或200Gbps），延迟在十微秒级。两者差了一个数量级。

具体到AllReduce操作，hcomm的路径选择策略分三步：

第一步，机内聚合。同一台服务器上的NPU卡先通过HCCS做一次Reduce操作，把梯度聚合到一张卡上。这一步完全走HCCS，延迟最低。

第二步，跨机聚合。各台服务器的聚合卡之间通过RoCE做Reduce操作，得到全局的梯度。这一步是通信的瓶颈，因为RoCE的带宽远低于HCCS。

第三步，机内广播。把全局梯度通过HCCS广播到本机的所有NPU卡上。

这种"先机内后跨机"的分层策略，把跨机通信的数据量降到了最低——每台服务器只需要发送一次聚合后的梯度，而不是每张卡都独立发送。对于8卡服务器做4机32卡的AllReduce，数据量从32份降到4份，跨机通信量减少了87.5%。

实际使用中的关键配置

hcomm的多机通信性能高度依赖配置的正确性。几个关键的配置项：

HCCS拓扑配置。hcomm需要知道每台服务器内部NPU卡的HCCS连接关系。通常通过hcc topo命令获取，输出类似：

NPCM 0 -- HCCS -- NPCM 1 -- HCCS -- NPCM 2 -- HCCS -- NPCM 3 | | | | HCCS HCCS HCCS HCCS | | | | NPCM 4 -- HCCS -- NPCM 5 -- HCCS -- NPCM 6 -- HCCS -- NPCM 7

如果你的服务器的HCCS拓扑和hcomm默认假设的不一样（比如非标准的级联方式），需要通过配置文件显式指定，否则hcomm可能选择次优的通信路径。

RoCE网卡配置。跨机通信依赖RoCE，RoCE的配置对性能影响很大。关键参数包括：MTU大小（建议9000以减少分片）、交换机PFC优先级流控（防止丢包重传）、网卡队列深度（影响RoCE的并发能力）。这些配置不在hcomm内部，需要操作系统的网络配置层面来设置。

通信算法选择。hcomm的AllReduce支持Ring和Tree两种算法。Ring-AllReduce的延迟和卡数成正比，适合卡数较少（<=8）的场景；Tree-AllReduce的延迟和log2(卡数)成正比，适合卡数较多的场景。hcomm默认会根据卡数自动选择算法，但也可以通过环境变量HCC_ALLREDUCE_ALGO手动指定。

使用前后效率对比

以一个典型的4机32卡LLaMA-7B训练场景为例，对比不同配置下的通信性能：

hcomm默认配置和NCCL之间有约15%的吞吐差距，主要来自RoCE通信的带宽利用率偏低。经过优化配置后差距缩小到约7%。

优化配置的具体内容：MTU从1500改为9000、启用PFC流控、AllReduce算法从Ring改为Tree（32卡场景Tree更优）、调整RoCE网卡队列深度从1024改为4096。

再看单机多卡场景下的对比，此时不存在跨机通信，hcomm和HCCL的性能基本一致：

单机场景下hcomm几乎等价于HCCL，因为底层都走HCCS，没有RoCE的开销。这也验证了hcomm是HCCL的上层封装这个关系。

从NCCL迁移到hcomm的实操要点

迁移过程分三步：

第一步，替换通信库初始化代码。把ncclCommInit替换为hccCommInit，ncclGetUniqueId替换为hccGetUniqueId。这一步是纯文本替换，没有逻辑变化。

第二步，替换集合通信调用。ncclAllReduce → hccAllReduce，ncclBroadcast → hccBroadcast，以此类推。参数类型和语义完全一致，不需要改业务逻辑。

第三步，调整启动脚本。多机启动方式从mpirun + NCCL改为mpirun + hcomm。环境变量从NCCL_前缀改为HCC_前缀，比如NCCL_SOCKET_IFNAME改为HCC_SOCKET_IFNAME。

实际迁移中最常见的问题是RoCE网络配置不当导致通信超时。NCCL在NVIDIA生态里经过了大量调优，默认配置就能工作得很好；hcomm在昇腾生态里相对年轻，默认配置偏保守，需要根据实际网络环境做调整。建议迁移前先用hcc-test-allreduce_bandwidth工具测试AllReduce的实际带宽，如果带宽利用率低于60%，说明网络配置需要优化。

hcomm和HCCL的选型建议

什么时候用HCCL，什么时候用hcomm？

单机多卡场景——直接用HCCL。HCCL的API更简洁，性能一致，不需要NCCL兼容层。

从NVIDIA生态迁移到昇腾的场景——用hcomm。NCCL API兼容可以大幅降低代码迁移成本，而且hcomm的NCCL兼容层经过大量模型验证，稳定性有保障。

新建昇腾原生项目——用HCCL。HCCL是昇腾原生通信库，API设计更贴合昇腾的编程模型，新项目没有必要为了兼容NCCL引入额外的封装层。

多机场景且对延迟敏感——hcomm和HCCL都可以。hcomm的多机路由管理更成熟，HCCL在新版本中也增加了多机支持。建议都测试一下，选择性能更好的方案。

结尾

hcomm的核心价值在于降低了从NVIDIA NCCL生态迁移到昇腾CANN生态的门槛。它的NCCL API兼容层让现有的分布式训练代码可以几乎零改动地跑在昇腾NPU上，同时提供了针对昇腾硬件拓扑的通信优化能力。如果你正在做训练框架的跨平台迁移，hcomm是一个值得优先评估的通信方案。多机场景下的性能调优需要关注RoCE网络配置和通信算法选择，调优后的性能和NCCL的差距在可接受范围内。

仓库地址：https://atomgit.com/cann/hcomm