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

• 开源代码与文档仓库：https://github.com/sii-research/VCCL

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

• VCCL 的目标不仅是提升通信效率，更是要让 GPU 算力得到最大化释放，通过 DPDK-like P2P 智能调度，VCCL 将通信任务合理卸载至 CPU，并在 PP（Pipeline Parallel） 工作流中实现深度交叠和全局负载均衡，大幅缩短 GPU 空闲时间。实测显示基于开源框架 Megatron-LM 的 SOTA 性能，使用 VCCL 后的 Dense 模型训练端到端算力利用率可进一步提升 2%-6%。

• 超大规模智算集群中，网络故障几乎是不可避免的风险源，VCCL 设计了一套基于 Primary-backup QP 链接的容错机制，在不增加系统负担的前提下，大幅提升整体稳定性。通过这一机制，VCCL 能够将集群故障率降低超过 50%，真正做到 “网络出故障了也能原地拉回”，让大模型训练不再轻易被打断。

• VCCL 设计了 Flow Telemetry，一种微妙级的 GPU 间点对点流量观测机制，能够清晰捕捉训练过程中通信速率的细微变化，为研发团队提供更细粒度的网络可观测能力，可有效解决传统基于计数的统计方式粒度粗、准确度差的问题，支持定位训练过程中的慢节点或慢链路。

设计 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 侧的通信处理进行优化：

• SM-Free P2P，在训练过程中 GPU 服务器的 CPU 利用率往往很低，VCCL 绕过 CUDA 内部对 P2P 的调度和处理机制，将 P2P 操作卸载至 CPU 运行，无需启动任何 CUDA 核函数，实现 SM-Free。SM-Free 的实现并不直接，P2P 在 CPU 侧运行缺少同步机制，无法保证 GPU 计算流的依赖关系。VCCL 采用 CUDA cudaLaunchHostFunc 编程接口，通过 CPU 侧轮询机制进行操作同步，并在工程上解决了多种隐藏卡死（Hang）问题。

• Zero-Copy P2P，传统 CUDA 通信中，会分配块缓存（chunk buffer），将应用缓存（application buffer）拷贝至块缓存，VCCL 使用 User Buffer Registration 机制，通过 ncclMemAlloc 接口，直接将应用数据映射至网卡。Zero-Copy 设计也有效防止了因为多方 I/O 访问带来的卡死问题。

• Deep PP Overlap，VCCL SM-Free P2P 设计可以进一步消除传统 GEMM 计算和 P2P 通信的 SM 竞争。这部分竞争，受限于 CUDA 调度机制，在传统 PP 计算通信交叠中无法消除。VCCL SM-Free P2P 可以给计算分配更多 SM 资源，同时 VCCL 在 PP 切分中使能全局负载均衡，最终将通信深度交叠于计算之内。

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

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

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

• NCCL，依赖 timeout 参数，往往意味着训练中断与长时间等待。

• checkpoint，虽然可以缩短故障恢复时间，但依然需要重启或回滚，无法保证训练的连续性。

• 网口聚合，适合应对突发的网口 Down，无法适用于单端口集群场景，不支持交换机故障容忍。

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 等模型结构、新型硬件架构。