九源开源技术周 03｜InfiniCCL：让不同的卡一起工作

搭建多机训练或推理环境时，我们常会遇到这样的情况：单台服务器上的卡已经跑起来了，但换一类卡、再加几台机器，通信却出了问题。有的操作不支持，有的接口没有报错，数据却不对；还有的机器接着高速网络，实际传输仍只能走普通以太网。

这些问题不解决，设备再多，也很难真正一起工作。

为什么需要 InfiniCCL？

多张卡协作时，需要不断交换数据。比如把各张卡算出的梯度汇总起来，再把结果交给所有参与者。完成这些工作的，是底层通信库。

不同硬件通常有各自的通信库，支持的功能和使用方式也有差别。只把接口名称统一起来，还不足以解决这些问题：应用需要的操作能不能用，结果是否正确，现有网络能不能利用起来，都需要继续处理。

InfiniCCL 是我们为此开发的统一异构通信库： 让应用通过同一套接口使用不同平台，并在底层补齐功能、优化性能、组织跨机器的数据交换。

让不同平台的设备协同工作

实际部署中的集群，可能由不同批次、不同平台的设备组成。统一通信不应只适用于某一种卡，也不应被限定在某一种固定的节点组合上。

InfiniCCL 的异构实现会在合适的情况下在节点内利用厂商通信库，在节点间通过例如 MPI 等后端交换数据。同一台机器里的卡继续发挥本平台的通信能力，不同机器之间则通过统一的方式协作。

例如，我们使用四台服务器组成异构集群，每台分别搭载 A 卡、B 卡、C 卡或 D 卡，检验不同平台之间的通信。

应用关心的是把数据发给谁、做什么操作，不必分别拼接每个平台的通信流程。通信库也可以根据具体的硬件特性进行通信优化。

补齐底层尚不具备的功能

统一接口之外，InfiniCCL 也会补齐底层通信库尚未直接提供的能力，让应用少为后端差异编写额外逻辑。

以多卡数据并行训练中的平均归约梯度为例：三张卡分别给出 2、4、6，应用希望每张卡都拿到平均值 4。这是一个直接的需求，但并非所有底层通信库都原生支持。

InfiniCCL 为不支持该操作的后端提供了平均归约，补齐了这一功能，并完成了不同数据类型的验证。在某厂商平台的单机实验中，我们测试覆盖了 FP16、BF16、FP32 三种精度。以下摘录 16 个逻辑设备、每个设备 128 MiB 数据的 AllReduce AVG 结果：

数据类型	InfiniCCL：正确求平均的耗时	业界参考实现
FP16	1.637 ms	返回求和结果，未通过校验
BF16	1.642 ms	返回求和结果，未通过校验
FP32	1.625 ms	返回求和结果，未通过校验

这组结果的关键，不是“平均比谁更快”，而是应用要求求平均时，通信库确实完成了求平均。业界现有实现的被测版本虽然返回成功，结果却是求和，因此不能把它的耗时当作有效的 AVG 性能。

底层有差异，不必让每个使用者都各自绕过一次。

多条通信路径，适应不同部署条件

实际环境不总能满足理想通信路径的全部条件。InfiniCCL 的思路是提供分层的路径选择：

具备条件时利用设备直连；
直连受限时，仍可通过主机内存中转使用 IB/RoCE；
没有可用的 RDMA 链路时，再使用 TCP。

这不是只有“最佳路径”和“普通网络”两个选项，而是尽量保留中间层的可用能力，根据实际配置与链路条件选择通信方式。 不同链路也不必采用完全相同的路径，而是可用共存。

例如，有时 IB 网络本身可用，但驱动或运行环境不允许网卡直接访问显存。这时 InfiniCCL 可以退而求其次地让数据先经过主机内存，再通过 IB 传输：

卡上数据 → 主机内存 → IB 网络 → 主机内存 → 目标卡

在本次一个两类卡组合中，业界参考实现的显存注册失败，有效对比测试只能退化到使用普通以太网 TCP；而 InfiniCCL 则通过主机内存中转，继续使用 IB。

两台异构服务器、每台 8 张卡的实验中，每张卡处理 1 MiB 数据，AllReduce 耗时如下：

本环境可用的传输路径	InfiniCCL	业界参考实现
IB 主机中转 / 普通以太网 TCP	2.14 ms	10.95 ms

其中，InfiniCCL 使用 200 Gb/s IB，业界参考实现使用 1 Gb/s 以太网。这里对比的是该环境下两者可用的通信路径，不是相同网络下的纯算法速度。

为区分网络条件与实现差异，我们又补做了双方都使用普通以太网 TCP 的对照：

同以太网补充对照	InfiniCCL	业界参考实现
4 次独立启动的耗时中位数	11.68 ms	11.75 ms

一条路径受限，不等于通信能力只能一步降到底。

一组小实验

先看结果是否正确。我们对三类卡的三个两节点组合和一个三节点组合，测试了数据汇总（AllReduce）、数据收集（AllGather）和点对点收发（Send/Recv），覆盖多种数据大小，并逐个检查接收到的数据元素。

测试结果	InfiniCCL	业界参考实现
正确完成	40 / 40	19 / 40
数据校验失败	0	17
接口报错	0	4

InfiniCCL 还通过了 15 项补充正确性检查，包括节点卡数不一致、进程顺序交错、输入输出复用等情况。

实验结论:
算对结果是前提，保留更多可用路径则让已有硬件更有机会发挥作用。
本次异构测试中，InfiniCCL 的 40 项结果全部通过；显存直连受限时，主机中转路径仍能利用 IB，带来了实际的通信耗时改善。

上面展开的，只是 InfiniCCL 功能中的几个例子。不同通信操作、平台适配和运行时能力，还有不少细节没有在这里一一介绍。完整支持范围与使用方式可查阅项目说明。

后续还会做些什么？

InfiniCCL 仍在持续开发。后续还有很多工作会继续推进，比如：

1. 接入更多平台与后端

扩大硬件与通信后端支持，并在不同设备、驱动和网络组合上持续验证，让更多已有设备能够参与协作。

2. 补齐更多功能

继续进行功能的完善与合入，扩大操作、数据类型和边界场景覆盖，让统一接口背后的功能更完整。

3. 继续优化性能

减少不必要的数据搬运，优化通信调度，探索更多计算与通信重叠的机会等。既让理想条件下的通信更快，也让条件受限时仍有实用的选择。

我们希望，使用者少花一些时间处理平台差异，多把精力放在模型和应用本身。也欢迎带着实际的硬件环境与使用需求，一起参与验证和改进。