集合通信库VCCL释放GPU极致算力，创智、基流、智谱等重磅开源

来源：市场资讯

（来源：机器之心Pro）

机器之心发布

机器之心编辑部

在人工智能迅猛发展的今天，超大规模智算集群已成为推动技术突破的核心基础设施。

海外科技巨头纷纷布局，OpenAI 与甲骨文和软银正在推进「星际之门」项目，计划配备数百万个 GPU，预计耗资超千亿美元；微软、谷歌、xAI 陆续完成十万卡集群交付使用。

在国内，运营商也加速向 AI 基础底座供应商转型，累计投资已超百亿元，建成 4 个万卡级智能计算中心，智算规模增长超 2 倍。

超大规模智算集群需要应对诸多挑战：硬件配套投入大、运营维护费用高。更重要的是，单纯堆砌硬件并不能解决所有问题，如何设计软件系统，将成千上万个计算单元高度组织起来才是核心挑战。在万卡甚至百万卡规模的集群中，设备故障几乎成为常态而非例外，任何一个组件的失效都可能导致整个训练任务中断，算力利用率系统稳定性成为比纯粹算力更为关键的指标。

AI 基础设施由计算 + 通信构成，集合通信库作为智算集群的 “神经系统”，其重要性日益凸显。集合通信库是 GPU 计算芯片与高性能网络的交汇所在，是 GPU 软件栈基座组件。如英伟达的集合通信库（NVIDIA Collective Communication Library，NCCL），可提供高性能、拓扑感知型集合运算，包括 P2P（Point-to-Point） Send/Recv、AllReduce、AllGather 和 ReduceScatter 等。这些通信原语针对 NVIDIA GPU 和各种互连产品进行了优化，包括 PCIe、NVLink、RoCE 以太网和 InfiniBand。

在这种背景下，创智、基流、智谱、联通、北航、清华、东南联合打造了高效率、高可靠、高可视的 GPU 集合通信库 VCCL（Venus Collective Communication Library），VCCL 已部署于多个生产环境集群中。

VCCL 的系统架构如下图所示，作为通信中间件，支撑训练框架，兼容异构硬件设备。VCCL 基于 NCCL 开发，在通信组启动逻辑（拓扑搜索、网络图构建和信道建立）之上，引入三个关键组件：

设计 1：DPDK-like P2P 智能调度

问题挑战：P2P 通信的高 SM 占用和复杂操作。GPU SM（Streaming Multiprocessor）流式多处理器是英伟达 GPU 的核心计算单元，包含 CUDA 核心、寄存器、缓存等组件。编程人员编写核函数，由 CUDA 运行时来进行任务调度。我们发现，NCCL P2P 通信没有涉及规约操作，但仍然占用了不低的 SM 资源，同时 NCCL P2P 操作引入多步与通信无关的操作，拖慢了整体性能。下表是使用两台 GPU 服务器运行 NCCL-Tests 统计的 P2P SM 资源占用情况。下图是 P2P 操作中开销统计，其中约 25% 的时间用于显存拷贝。

计算机体系结构的演进具有周期性和相似性，一个技术方向演进总是从功能到性能，架构设计也倾向于从通用到专用。CUDA 是一个黑盒，计算通信的调度效率低，API 接口有限，优化难度大，与 Linux 内核相似。

15 年前，随着云计算发展，网络数据流量以前所未有的速度增长，对网络处理性能的要求也达到了极致。传统的基于内核的网络数据包处理方式已无法满足现代高速网络设备的需求。DPDK（Data Plane Development Kit） 应运而生，目前已运行于每一台云数据中心的 CPU 服务器中。DPDK 将网络数据平面处理从内核态迁移至用户态，采用轮询而非中断方式进行数据收发调度，并通过大页内存无锁零拷贝的方式加速数据传输。

VCCL 提出 DPDK-like P2P 设计，与 DPDK 优化 Linux 内核协议栈的网络处理一致，VCCL 对 CUDA 侧的通信处理进行优化：

设计 2：Primary-backup QP 原地恢复容错

问题挑战：网络抖动是发生最多的故障类别。在大规模分布式训练中，网络抖动相关的链路故障（如，网口 Down、交换机异常等）占比超过 GPU 故障和其他故障。我们统计了一个数千卡规模的 GPU 集群在 2024 年 3 月至 12 月的故障情况。一旦发生网络故障，对应的通信队列对（QP，Queue Pair）在超时后无法继续发送，会触发 AEQ 事件并立刻进入 ERR 状态，结果是整体集合通信操作被卡死（hang），大模型训练直接失败，待到超时时间结束，任务才会被 watchdog 强制退出。

面对网络链路故障，现有的业界方案往往难以满足训练过程中的即时恢复需求：

VCCL 提出更通用且成本更低的 Primary-backup QP 设计，进行原地恢复。在通信组启动过程中，VCCL 为每一个主通信队列对，建立一个备份通信队列对。当网络出现故障时，VCCL 能在底层实时检测，自动将流量无差别导向备份网口完成通信。整个过程无需应用层感知，无需额外干预。当原链路恢复后，VCCL 会检测并将流量切换回主通信队列对，集合通信性能完全恢复。

VCCL Primary-backup QP 设计的核心在于状态同步和迁移。如下图所示，VCCL 使用三个指针代表收发两端的传输和接受状态。在发送端，posted 代表应用准备好的数据，transmitted 代表网络代理准备在网卡发送的数据，acked 代表已发送并确认收到的数据。在接收端，posted 含义一致，received 与 transmitted 对应代表准备接收的数据，done 与 acked 对应代表确认收到的数据。网络链路故障时，VCCL 采用接收端驱动的机制，从最后一个确认的数据块开始重传。VCCL 采用定时检测的机制，在完成网络链路恢复时，切换回主通信队列对。

设计 3：Flow Telemetry 细粒度可视化

问题挑战：集群故障定位与性能分析缺少有效工具。由于集合通信操作同时涉及 GPU 计算与网络传输，集群任务故障发生时的大部分报错都与 NCCL error 相关，包括训练任务卡死、降速等问题。传统手段需要大量人工介入，而且故障难以复现，对于大任务停集群排障是一件代价极高的事情。造成当前问题的核心在于，缺少对集合通信的细粒度且在线监测工具，现有的网络监控工具都处在秒级粒度，而集合通信操作通常在毫秒级甚至微秒级完成。

VCCL 提出 Flow Telemetry 设计，利用 RDMA 编程的细腰抽象，所有集合通信操作都可以拆解为微秒级 RDMA verbs 代表的网卡侧数据发送传输语义。基于集合通信消息的监测采集机制，会因为多个消息共享链路带宽而造成统计不准确问题。VCCL 进一步采用滑动窗口机制，在同一通信队列对中，统计所有相关消息的平均瞬时带宽，得到集合通信层的微秒级统计数据。

VCCL Flow Telemetry 支持 GPU 间微秒级别流量探测，能够清晰捕捉训练过程中通信速率的细微变化，以此作为基准可进一步确定计算和通信操作的运行时间点，定位集群任务卡死原因，分析慢节点。同时，Flow Telemetry 能够实时统计端口上未完成的 RDMA WR（Work Request）数量，并据此推测工作队列长度变化，从而精准判断网络是否出现拥塞。

实验评测

VCCL 基于 NCCL v2.21.5 实现，采用千卡英伟达 Hopper GPU RoCEv2 集群进行评测，以最佳实践超参数运行 Megatron-LM 自带的 GPT-2 6B、32B、70B、177B、314B 大小模型。

DPDK-like P2P 对效率的提升

比较 VCCL 和 NCCL 的 P2P 性能。在不同消息大小下，通过 NCCL-Test 测试 VCCL 和 NCCL 的 send/recv 操作，VCCL 在 1GB 消息大小下算法带宽比 NCCL 提升 20.12%，VCCL 在小消息下时延比 NCCL 降低至少 28.5%。VCCL 在实现 P2P 操作 SM 零占用的前提下，对于 CPU 的使用，只比 NCCL 增加了 4%。

分别使用 VCCL 和 NCCL 运行 Megatron-LM，测试训练准确性和算力利用率。VCCL 与 NCCL 的 Loos 收敛曲线一致，VCCL DPDK-like P2P 的设计保证了计算和通信的正确调用顺序。在不同模型大小和集群规模下，端到端算力利用率 VCCL 比 NCCL 有 2%-6% 提升，体现出 SM-Free、Zero-Copy 以及 PP 深度交叠带来的新的性能增益。

Primary-backup QP 对可用性的提升

采用手动方式在第 4 秒和第 19 秒之间 Down 掉网卡端口，在第 4 秒和第 19 秒之间，VCCL 和 NCCL 同时在执行重试机制，第 14 秒后重试机制结束，NCCL 的集合通信带宽无法恢复，而 VCCL 通过切换备用通信队列对，仍然可以保持，76.6% 的 AllReduce 带宽和 58.1% 的 ReduceScatter 带宽，19 秒后 VCCL 切换回主通信队列对，性能恢复正常。在采用备用通信队列对时，Down 掉一个网卡端口，VCCL 只引入 0.38% 的算力利用率下降，与正常运行时的算力利用率基本一致。

Flow Telemetry 对可视化的提升

验证 VCCL Flow Telemetry 的毫秒级监测功能，分别在窗口大小为 1、8、32 的情况下，以 10 微妙粒度呈现 P2P 吞吐量。当窗口大小设为 1 时，等价于消息粒度的监测，波动较大；当窗口大小为 32 时，VCCL 可以平滑展示吞吐量，但缺少瞬时波动的呈现。实验显示，窗口大小设置为 8 时，可以平衡监测的准确度和平滑性。

VCCL 部署与展望

VCCL 在实际部署过程中，还解决了服务器机型异构的问题。不同厂商的服务器，因 PCIe 拓扑结构差异导致跨设备连接不通及多网卡端口间流量不均衡，致使 RDMA 性能未达预期。为系统性地解决此问题，VCCL 针对不同硬件配置设计了相应的优化方案。

VCCL 在线运行过程中，用户会遇到一些集群问题，包括集合通信报错或者训练性能下降。但会存在定位出的根因与通信无关的情况，相关案例包括：云平台参数配置错误导致 CPU 核心分配不足；GPU 服务器风扇转速配置错误；GPU 单卡执行任务故障等。这些问题字面上看似简单，但集群黑盒分析起来挑战很大，多维度在线故障定位与性能分析工具需要持续迭代优化。

VCCL 的容错机制可以更好地包容网络硬件设备的故障，也为创新或国产化网络组件上线部署提供冗余度空间，有效助力于算力生态发展。

VCCL 让团队看到了更高性能、更高稳定性的集合通信库发展机遇，未来 VCCL 会支持适配更多并行工作流、MoE 等模型结构、新型硬件架构。