全文笔记 - GPU-Initiated Networking for NCCL

面向 NCCL 的 GPU 发起式网络（GPU-Initiated Networking for NCCL）

原文

摘要

现代 AI 工作负载------尤其是混合专家（Mixture-of-Experts，MoE）架构------日益需要低延迟、细粒度且由设备端控制的 GPU 到 GPU 通信。传统 GPU 通信遵循主机发起（host-initiated）模型，由 CPU 编排所有通信操作------这是 CUDA 运行时模型的固有特征。尽管该模型对集合通信操作而言足够稳健，但对于需要计算与通信紧密集成的应用，采用设备发起（device-initiated）的通信以消除 CPU 协调开销将带来显著收益。

NCCL 2.28 引入了 Device API（设备 API） ，包含三种操作模式：面向 NVLink/PCIe 的 Load/Store Accessible（LSA，可加载/存储访问）、面向 NVLink SHARP 的 Multimem，以及面向网络 RDMA 的 GPU-Initiated Networking（GIN，GPU 发起式网络）。本文介绍 GIN 的架构、设计与语义，并重点阐述其对 MoE 通信的影响。GIN 采用三层架构：

NCCL Core 的主机端 API，用于设备通信器（device communicator）的建立与集合式内存窗口注册；
可从 CUDA 内核中调用的设备端远程内存操作 API；
具有双语义（GPUDirect Async Kernel-Initiated 与 Proxy）的网络插件架构，以实现广泛的硬件支持。

GPUDirect Async Kernel-Initiated（GDAKI）后端利用 DOCA GPUNetIO 实现 GPU 与 NIC 的直接通信；Proxy 后端则通过基于无锁 GPU→CPU 队列的方式，在标准 RDMA 网络上提供等价功能。我们通过与 MoE 通信库 DeepEP 的集成验证了 GIN 的实用性。全面的基准测试表明：GIN 在 NCCL 统一运行时内提供了设备发起的通信能力，将低延迟操作与 NCCL 的集合算法及生产级基础设施结合在一起。

关键词：NCCL Device API；GPU-Initiated Networking；Load/Store Accessible；Multimem；RDMA；单边通信（One-Sided Communication）；设备发起的通信；DeepEP

一、引言

大语言模型（LLM）的快速发展为 GPU 通信库带来了新的性能要求。现代 AI 工作负载所需的已不仅仅是传统的集合通信：它们需要面向推理 token 生成的低延迟点对点操作 $1$ $2$ 、面向 MoE 架构的自定义通信模式 $3$ ，以及在编译器生成的内核中实现计算与通信的紧密集成 $4$ $5$ 。这些工作负载都将受益于 GPU 无需 CPU 参与即可直接发起并控制网络通信 的能力。

NCCL $6$ 已成为基于 GPU 的机器学习领域事实上的通信运行时，为分布式训练与推理提供了优化的集合算法和稳健的基础设施。传统 GPU 通信遵循主机发起模型，由 CPU 编排所有通信操作。这种方式要求显式的主机---设备同步（这是 CUDA 运行时模型的特征），且每次通信调用都需单独启动内核。尽管该模型在大规模集合通信上已被证明足够稳健，但那些要求计算与通信紧密集成的应用------例如 MoE 推理中的动态 token 路由 $3$ 、JAX $5$ 与 Triton $4$ 内核中由编译器生成的通信------则需要设备发起的通信，以消除源于 CUDA 主机侧同步的 CPU 协调开销。另一方面，NVSHMEM 库 $7$ $8$ 已经成功验证了 GPUDirect Async Kernel-Initiated（GDAKI）能力的可行性与性能影响，提供了可实现 AI 工作负载通信---计算融合的设备端原语。
图 1（原文图 1）：NCCL Device API 架构，展示三种操作模式及其底层互联技术。Load/Store Accessible（LSA）使用 PCIe 与 NVLink 实现节点内内存操作；Multimem 利用 NVLink SHARP 实现硬件组播；GPU-Initiated Networking（GIN）通过双后端实现（GDAKI 与 Proxy）在 InfiniBand 和 RoCE 上提供基于网络的通信。

为满足现代 AI 工作负载对计算---通信紧密集成的需求，NCCL 2.28 引入了 Device API $9$ ，使 GPU 能够直接在内核内部发起通信操作。Device API 支持三种设备发起通信的操作模式（图 1）：Load/Store Accessible（LSA） ，通过内存 load/store 操作在 NVLink 与 PCIe 上实现节点内通信；Multimem ，通过 NVLink SHARP 实现硬件组播；GPU-Initiated Networking（GIN） ，在 InfiniBand 与 RoCE 网络上实现节点间通信。本文聚焦于 GIN，它使 GPU 能够在 GPU 内核内部直接发起网络操作。GIN 为单边操作提供设备端 API，允许 CUDA 内核完全在设备代码中执行远程内存操作、点对点同步以及完成事件轮询。NCCL Device API 及其 GIN 能力为 AI 工作负载提供了低延迟原语、融合与自定义的机会，同时使这些应用能够利用 NCCL 的既有基础设施，例如分层通信器（hierarchical communicators）、弹性（elasticity）以及面向大规模生产部署的容错机制。
图 2（原文图 2）：高层架构对比：左侧的 NCCL Device API 具有三种操作模式（面向 NVLink/PCIe 的 Load/Store Accessible、面向 NVLink SHARP 的 Multimem、面向网络 RDMA 的 GIN），基于集合式对称内存实现单趟（single-shot）集合算法；右侧的传统 NCCL 则基于常规内存，采用主机发起的算法与流水化原语。

图 2 对比了 NCCL Device API 架构与传统主机发起式 NCCL。应用（PyTorch $10$ 、TRT-LLM $1$ 、vLLM $2$ 、SGLang $11$ ）既可以使用 NCCL 基于 Device API 实现的单趟集合算法，也可以直接调用 Device API 原语，在 GPU 内核中实现自定义通信模式。Device API 在集合式对称内存（collective symmetric memory）上运行，这与传统 NCCL 在常规内存上使用流水化原语（Simple、LL、LL128）的主机发起式集合通信形成对比。

GIN 通过三层架构实现这一目标：

主机端 API：扩展 NCCL Core，负责通信器初始化、GIN 资源管理与集合式内存窗口注册；
设备端 API ：暴露可直接从 CUDA 内核调用的 put/signal 远程内存操作原语，并具有灵活的完成语义；
可插拔的网络后端架构：同时支持通过 DOCA GPUNetIO 实现的 GPU---NIC 直接通信（GDAKI 后端），以及通过无锁队列实现的 CPU 辅助操作（Proxy 后端）。

通过同时提供硬件直通与 CPU 辅助两类插件接口，GIN 能在多样化的部署场景中提供功能，同时保持与 NCCL 既有生态系统的兼容性。与典型的分层架构不同，GIN 通过编译期优化与直接硬件访问，引入的开销极小。

1.1 GIN 的关键设计要素

GIN 的设计与实现融合了若干关键技术要素：

Device API 设计。 GIN 提供的设备端 API 支持灵活的协作模型（线程级与 warp 级集合操作），具有针对小型内联值（inline values）优化的原语、基于窗口加字节偏移的内存寻址，以及灵活的本地完成（flush 与 counter）和远程完成（signal）机制。这使应用能够表达自定义通信模式，并在内核内将通信与计算融合。
双插件架构。 NCCL GIN 实现了两种插件架构：GDAKI 接口利用 DOCA GPUNetIO 后端，使 GPU 线程能够通过设备端 verbs 直接编程 InfiniBand/RoCE 网卡；Proxy 接口则使用携带 64 字节描述符的无锁 GPU→CPU 队列，使 GIN 功能可在任何支持 RDMA 的网卡上运行。
同步机制。 GIN 提供本地与远程完成通知原语：signal（用于远程通知）与 counter（本地完成跟踪）。这些机制基于线程作用域（thread scope）标注自动插入 fence，从而与 CUDA 内存模型集成。
内存管理。 GIN 使用集合式窗口注册（ncclCommWindowRegister）：每个 rank 贡献一个本地缓冲区，并获得包含所有对端远程密钥（remote key）的句柄，从而实现零拷贝的单边操作。

1.2 贡献

概括而言，本文的主要贡献如下：

在 NCCL 中设计并实现了 GIN，包括统一的主机端与设备端 API、用于异步完成的模块化同步原语（signal 与 counter），以及两种可互换的后端架构：基于 DOCA GPUNetIO 实现 GPU---NIC 直接通信的 GDAKI，和在标准 RDMA 上实现 CPU 辅助操作的 Proxy。
与 DeepEP（一个专用的 MoE 通信库）完成集成，验证了 GIN 的实际适用性及其与既有基于 NVSHMEM 的设备发起通信的兼容性。
通过微基准测试和基于 DeepEP 内核的应用级实验，对 GIN 进行了全面的性能评估，并通过对比分析确立了其性能特征。

本文其余部分组织如下：第二节介绍 GPU 通信的背景并阐明 GIN 的动机；第三节介绍 GIN 的架构、设计原则、设备端 API 语义与实现------包括三层设计、GDAKI 与 Proxy 两种后端，以及同步原语与内存管理；第四节描述 GIN 与 DeepEP 的集成，展示其在动态 MoE 工作负载中的实际应用；第五节通过微基准测试与多节点 GPU 集群上的 DeepEP 应用级基准测试评估 GIN 的性能；第六节回顾 GPU 直通通信与单边编程模型的相关工作；第七节总结经验教训与 GIN 的未来方向。

二、背景

OpenSHMEM 等传统通信库在对称内存区域上提供单边原语（put、get、原子操作），使数据移动无需发送方---接收方协调即可异步进行 $12$ 。然而，这些规范假定以 CPU 为中心的执行方式，即所有通信原语均从主机代码发起调用。GPU 进入 HPC 系统后暴露了该模型的低效之处：细粒度的 GPU 到 GPU 通信会产生内核启动开销、经由主机内存暂存数据的 PCIe 传输，以及 CPU 调度延迟 $13$ 。这些瓶颈推动了 GPU 感知（GPU-aware）扩展的发展，使设备发起的通信可以直接在 CUDA 内核中进行 $14$ $13$ 。

2.1 GPUDirect 技术

GPUDirect RDMA （2013） $15$ $16$ 使支持 RDMA 的网络接口能够通过 PCIe 基址寄存器（Base Address Register，BAR）映射直接访问 GPU 内存，从而将 CPU 与主机内存从节点间传输的数据通路中移除。NIC 的 DMA 引擎对 GPU BAR 执行 PCIe 点对点事务，访问通过 nvidia_p2p 内核模块注册的内存区域。然而，GPUDirect RDMA 仅在内核边界（kernel boundaries）处提供一致性保证。GPU 内存模型语义（宽松排序、写回缓存）使正在执行的内核无法安全地并发访问 RDMA 注册的内存，迫使应用将计算与通信分离开来 $17$ 。

GPUDirect Async（2016） $18$ 引入了部分控制通路卸载：GPU 线程通过写入映射到 GPU 地址空间中的 NIC doorbell 寄存器，触发预先配置好的网络操作。但通信描述符必须由 CPU 预先构造，操作被限制在主机预先配置的范围内，无法实现完全自治的设备驱动网络。

2.2 设备发起的通信原语

完全由设备发起的网络通信要求在 GPU 代码中直接实现网络编程接口。早期原型如 GPUrdma $19$ 与 GIO $17$ 将 InfiniBand verbs 暴露为设备可调用函数，但面临 GPU---NIC 内存一致性的挑战。

NVSHMEM $8$ 将 OpenSHMEM 语义扩展到 GPU 集群，提供可从 CUDA 内核调用的设备端单边操作（put、get、原子操作）。这使设备代码能够在不产生内核启动开销的情况下交织计算与通信，其传输后端包括用于节点间传输的 IBGDA（InfiniBand with GPUDirect Async），以及用于节点内通信的对称内存机制。

DOCA GPUNetIO 为 InfiniBand 与 RoCE 网络（IBGDA）提供 GPU 侧 RDMA API，暴露使 GPU 内核能够直接编程 NIC 的设备函数 $20$ 。具体而言，它实现了 GPUDirect RDMA（GPU 数据直接移动）与 GPUDirect Async Kernel-Initiated（GPU 控制网络通信）两项技术。它构成了 GIN 之 GDAKI 后端的基础，通过硬件支持的设备端 verbs 实现 GPU 与 NIC 的直接通信。

2.3 面向 GPU 发起通信的网络硬件

GPU 发起式网络要求网卡支持通过若干 RDMA 技术之一的直接设备访问：InfiniBand、RoCE 或 iWARP $21$ 。

InfiniBand 提供原生 RDMA 支持与基于信用（credit-based）的流控，端口到端口延迟约为 130 ns，每个子网可支持数万个节点 $22$ 。InfiniBand 适配器通过 PCIe BAR 暴露内存映射的队列对（Queue Pair，QP）、完成队列（Completion Queue，CQ）与 doorbell 寄存器，与 GPUDirect RDMA 结合后可实现 GPU 直接访问 $13$ $15$ 。

RoCE 在标准以太网上实现 RDMA，成本更低，与现有数据中心基础设施的兼容性更广 $22$ $21$ 。主流变体 RoCEv2 将 InfiniBand 传输层封装在 UDP/IP 之上，端口到端口延迟约为 400 ns------高于原生 InfiniBand，但对许多工作负载已经足够 $22$ 。RoCE 要求使用优先级流控（PFC）与显式拥塞通知（ECN）配置无损以太网以防止丢包，这在多租户环境中可能使部署复杂化 $22$ 。InfiniBand 与 RoCE 共享同一套用户态 verbs API，因而具备互联可移植性 $21$ 。

对于 GPU 发起的通信，硬件要求是 NIC 支持设备可访问的控制结构。NVIDIA ConnectX 系列适配器（ConnectX-6 Dx 及更新型号）与 BlueField DPU 通过 DOCA GPUNetIO 提供该能力 $20$ 。缺乏此类硬件支持的系统无法启用 GPU---NIC 直接通信，必须回退到 CPU 中介机制。在 GIN 的架构中，这一约束促成了双后端设计：GDAKI 后端在受支持的硬件上利用 DOCA GPUNetIO 实现设备直接通信；Proxy 后端则通过无锁 GPU→CPU 队列与 CPU 驱动的网络操作，在任意支持 RDMA 的网卡上提供功能等价的语义。

最优性能要求 GPU 与 NIC 位于同一 PCIe root complex 之下，以最小化点对点延迟并最大化带宽 $15$ $23$ 。采用分布式 PCIe 拓扑的多路（multi-socket）系统可能产生跨路（inter-socket）穿越惩罚，降低 GPUDirect RDMA 的效率。此外，GPU 发起式网络还需要 nv_peer_mem 内核模块（用于 GPUDirect RDMA）以及相应的驱动栈（InfiniBand 使用 OFED，Mellanox 适配器使用 MOFED），以在 GPU 与 NIC 地址空间之间建立内存映射 $23$ 。

2.4 NCCL 架构与网络插件

NCCL 是多 GPU 机器学习的标准集合通信运行时，提供拓扑感知的 allreduce、allgather、reduce-scatter 与 broadcast 操作实现 $24$ 。NCCL 的架构使用 CPU 代理（proxy）线程编排网络操作：GPU 内核将通信描述符 enqueue 到主机可见的队列中，由 CPU 线程通过网络插件执行。尽管该设计在大规模集合通信上已被证明足够稳健，NCCL 2.28 的 Device API $9$ 在此基础上扩展了设备端原语，使应用可以直接在 GPU 代码中实现自定义通信模式、将通信集成进计算内核，并为新兴工作负载实现细粒度的计算---通信重叠。

NCCL 在生产框架中的广泛采用，正是此次设备发起通信能力集成的动机------在保持生态系统兼容的同时启用新的用例。

NCCL 网络插件 架构提供了一个抽象层，将核心库与具体网络实现解耦。NCCL 同时支持直接内建于库中的内部插件（如 Socket 与 InfiniBand），以及以共享库（libnccl-net.so）形式实现 NCCL 网络 API 的外部插件。该设计允许网络厂商与硬件提供方在不修改 NCCL 核心的情况下，为 NCCL 扩展专用的传输实现。外部插件在运行时动态加载，通过 NCCL_NET_PLUGIN 环境变量选择，在通过带版本号的 API 接口保持版本兼容的同时，实现多样化网络技术的无缝集成。

2.5 专用 MoE 通信库

LLM 中的 MoE 架构需要动态的、负载均衡的、消息大小不可预测的全交换（all-to-all）token 路由，这产生了不规则的通信模式，传统集合通信 $25$ 并不擅长处理。DeepEP $26$ 与 Perplexity 的 pplx-kernels $27$ 等专用库以 CUDA 优化的、GPU 发起的低延迟全交换传输原语来服务这类工作负载。这些工作证明了以 GPU 为中心的通信对 MoE 工作负载的价值，但仍游离于 NCCL 生态系统之外。

GIN 将 GPU 发起的 RDMA 操作引入 NCCL，使应用能够在统一运行时内同时利用主机优化的集合通信与设备驱动的点对点通信。

基于这些设备发起的网络技术与 NCCL 的插件架构，下一节将介绍 GIN 的设计与实现。

三、NCCL GIN：GPU 发起式网络

本节介绍 NCCL GIN 的设计与实现。如第二节所述，为 NCCL 扩展设备端原语可使现代 AI 工作负载实现计算与通信的紧耦合。GIN 通过将设备发起的单边原语集成进 NCCL 来提供这一能力，允许 GPU 线程直接从 CUDA 内核发起网络操作，全程无需 CPU 参与。

该设计在保留 NCCL 既有编程模型与生态系统集成的同时，为设备驱动的通信增加了一条并行的低延迟路径。这使 TensorRT-LLM、vLLM、SGLang 等生产系统以及 DeepEP 等通信库能够实现传统 NCCL 无法达成的自定义集合算法与内核融合模式。

本节分为三部分：3.1 节介绍三层架构与核心设计原则；3.2 节介绍设备端 API 并通过实例演示其用法；3.3 节分析两个插件接口及其后端实现 GDAKI 与 Proxy，阐释其设计依据与性能特征。

3.1 核心原则与架构

NCCL GIN 的架构建立在单边通信语义之上，该语义支撑两个关键的性能目标：最大化通信---计算重叠 与 最小化端到端操作延迟。通过使 GPU 线程能够直接发起 RDMA 操作------无需接收方协调即可读写远程内存------GIN 消除了主机---设备同步开销与双边握手延迟，使异步数据传输能够与计算并发进行。
图 3（原文图 3）：GIN 架构，展示 NCCL Core、插件层（Plugin Layer）与设备端 API 之间的交互。

如图 3 中左侧绿色路径所示，GIN 架构由三个协作层组成，旨在平衡高性能与广泛的厂商支持：NCCL Core （主机端 API）、Device GIN API （GPU 可调用的原语）与 GIN 网络插件（可插拔的网络后端）。图 3 右侧灰色路径展示的是基于内置网络插件的既有双边集合通信 API。三个 GIN 层次详述如下：

i）NCCL Core：主机端 NCCL 功能，管理内存窗口注册、资源分配与通信器初始化，为 GIN 资源管理提供基础，并在 NCCL 既有基础设施上扩展设备发起通信能力；

ii）Device GIN API：设备端 API，向 GPU 内核暴露统一接口，使应用能够直接从 CUDA 内核调用单边通信操作。它根据底层网络后端，分发到 NCCL 提供的（Proxy）或插件提供的（GDAKI）实现；

iii）GIN 网络插件 ：插件层提供可扩展机制，定义远程数据移动操作并支持双语义------GDAKI 与 Proxy------以最大化网络覆盖范围。NCCL 的 InfiniBand 传输层对两种语义均提供实现，外部厂商也可提供自己的实现。在 Proxy 接口下，NCCL Core 拥有控制结构、设备侧排队逻辑与设备 API 实现，插件仅需提供基于 CPU 的 put、signal、test 与 regMr 操作，从而使不具备 GPU 直通能力的网络也能接入，降低了进入 GIN 世界的门槛。在 GDAKI 语义下，插件同时拥有控制通路与设备 API：它们通过 createContext 创建 GPU 上下文，并提供使用 DOCA GPUNetIO 等内核发起式 API 直接编程 NIC 的设备代码，NCCL Core 则作为协调者，在插件的主机组件与设备组件之间传递结构体。

这些组件通过若干关键设计要素实现设备发起的单边通信：用于单方面数据移动的单边语义 、用于零拷贝远程访问的对称内存窗口 ，以及具有灵活排序语义的异步完成跟踪。

单边通信语义。 GIN 暴露单边 RDMA 原语------用于远程写入的 put，以及带远程通知的写入 put + signal------使 GPU 线程无需接收方的任何协调即可访问远程内存。该单边模型消除了握手协议的开销与接收方参与的需要，允许发起方单方面发出传输，并独立控制何时验证完成。单边模型对 MoE 工作负载中的不规则通信模式尤为有效（动态 token 路由产生不可预测的流量模式），也同样适用于受益于并行、非阻塞对端通信的单趟集合算法实现。

基于窗口的（非）对称内存。 通信缓冲区必须在所有 rank 上集合式注册，建立在可寻址性上对称的内存窗口，遵循 MPI RMA 窗口模型 $28$ 。所有进程均可访问已注册的内存，类似于 NVSHMEM 的对称堆。GIN 窗口在设计上支持容量非对称：每个 rank 可以注册不同大小的缓冲区。这一灵活性对分离式（disaggregated）服务架构至关重要------其中 prefill rank 需要比 decode rank 更大的缓冲区。请注意，NCCL 2.28 的当前实现强制要求对称大小，但该约束将在未来版本中解除。此外，内存分配与注册并不耦合：NCCL-GIN 内存窗口允许用户基于已有分配创建窗口。每次注册都会生成封装远程访问元数据的窗口句柄。窗口句柄为后端提供了特定的优化机会：后端可利用 rank 相对偏移，直接根据窗口元数据与目标地址构造 RDMA 描述符。

用于网络并行性的 GIN 上下文（Context）。 GIN 上下文是表达网络并行性的主要抽象。每个上下文抽象一条 GPU 与 NIC 之间的通道，并封装网络资源与连接（队列对，QP）。每个通信器可拥有多个上下文，使应用能够利用跨多个 NIC、端口与 QP 的网络级并行性，支持相互独立的并发通信流。单个上下文可寻址与该通信器关联的每一个 rank，因此一个上下文可以向不同对端发出多个并发操作。

异步完成跟踪。 所有设备发起的操作均异步执行并立即返回，使其他工作（如计算，或通过 NVLink 进行的节点内通信）能够并行推进。应用通过使用按上下文分配的资源的两种不同机制来跟踪操作完成。Counter（计数器） 是本地对象，在发送方一侧跟踪完成，指示源缓冲区何时可以被安全复用。与跟踪上下文上所有已投递操作之完成的 flush 操作不同，Counter 是一个强大的概念，可按操作跟踪本地完成，使用户能够高效地描述流水化算法。每个数据移动操作都可以选择性地向用户提供的 counter（通过 counterID）报告本地完成。

另一方面，Signal（信号） 是对称对象，提供远程完成跟踪，确认数据已到达目的端并在目的端可见。与 OpenSHMEM 基于地址的同步不同，GIN 使用基于 ID 的寻址：每个 signal（和 counter）由整数 ID 而非内存地址标识。基于 ID 的设计简化了资源管理，并使完成通知的硬件实现更为高效。

排序语义。 为最大化网络效率与吞吐，GIN 操作默认是无序的。GIN 仅对同一上下文中发往同一对端 的 put 与 signal 操作之间提供排序保证。当一个 signal 操作（无论是独立的 signal，还是带有 ncclGin_SignalInc/ncclGin_SignalAdd 动作的 put）在目的端完成时，它保证同一上下文中此前所有发往该对端的 put 操作均已完成，且对远程 GPU 线程可见。这提供了无需显式 fence 操作的轻量级排序：应用可以将多个 put 攒批，并在最后一个操作上附带 signal，从而确保整个序列在远程有序可见。相比之下，flush 操作仅确保本地完成------所有挂起操作均已被消费、源缓冲区可安全复用------但不保证远程可见性。GIN 基于 signal 的排序以最大性能为目标，通过 signal 选择性地提供排序保证，而非全局排序。值得注意的是，GIN 不假定也不保证 GPU 线程之间的任何排序；用户使用 CUDA 同步原语同步线程是其自身的责任。

3.2 设备端 API 与编程模型

设备端 API 为 GPU 内核提供对网络操作的直接控制，暴露无需 CPU 干预即可从 CUDA 设备代码调用的方法。编程模型以 ncclGin 对象为中心，该对象封装网络资源（上下文、操作队列与对端连接状态），并提供数据移动、完成跟踪与同步方法。后端选择（DOCA GPUNetIO 或 Proxy）在通信器初始化时根据硬件能力与用户配置透明地进行；无论底层实现如何，呈现给设备的接口完全相同。

API 组织。 接口将操作组织为反映通信工作流的四个逻辑类别：数据移动 操作（put、putValue、signal）向远程对端发起单边传输或通知，投递异步执行的 RDMA 操作；完成跟踪 操作区分本地完成（flush、readCounter、waitCounter------表明源缓冲区可安全复用）与远程完成（readSignal、waitSignal------确认数据已到达目的端并对远程 GPU 线程可见）；屏障同步 （ncclGinBarrierSession）在通信阶段之前协调 team 内的所有 rank，通过全网络范围的同步确保全局一致性；状态管理 操作（resetCounter、resetSignal）重置完成状态，以便在多轮通信中复用。这种关注点分离实现了对通信---计算重叠的细粒度控制，并支持多样化的同步模式。

此外，GIN 设备 API 与 GPU 内存模型紧密交互，并接受用户提示以优化性能关键的内存排序与一致性任务。例如，put 接受来自用户的两个提示：所提供数据的可见性作用域（visibility scope），以及操作完成后预期的用户可见性。

使用工作流。 应用通过三阶段工作流与 GIN 交互（代码清单 1）。初始化阶段，应用在创建 NCCL Device 通信器时启用 GIN 支持（使用适当配置标志调用 ncclDevCommCreate），从而创建 GIN 上下文。随后应用使用 ncclCommWindowRegister 将内存缓冲区集合式注册为窗口，返回供设备代码使用的窗口句柄。内核执行阶段，设备线程实例化一个 ncclGin 对象并指定所需的上下文索引（通常根据目标对端或负载均衡需求选择），发出数据移动操作，并可选地附带完成动作，如远程 signal 递增或本地 counter 更新。最后，内核在复用缓冲区或进入后续计算阶段之前，通过等待 signal 或 counter 进行同步，确保通信与计算阶段的正确排序。代码清单 1 给出了 NCCL GIN 接口的简化视图，突出核心操作。实际 API 还包含面向高级用例的额外模板参数与选项（如协作线程组、内联数据传输），但核心抽象保持一致。

代码清单 1：简化的 NCCL GIN 设备 API

cpp 复制代码

class ncclGin {
  // 构造函数：以设备通信器和上下文 ID 初始化
  ncclGin(ncclDevComm comm, int contextIndex);

  // 数据移动操作
  void put(team, peer, dstWindow, dstOffset,
           srcWindow, srcOffset, bytes, ...);
  void putValue(team, peer, dstWindow, dstOffset, value, ...);
  void signal(team, peer, signalId);

  // 本地完成跟踪
  void flush(coop);                        // 阻塞直至操作完成
  uint64_t readCounter(counterId);         // 轮询 counter
  void waitCounter(coop, counterId, expectedValue);
  void resetCounter(counterId);            // 重置以便复用

  // 远程完成跟踪
  uint64_t readSignal(signalId);           // 轮询 signal
  void waitSignal(coop, signalId, expectedValue);
  void resetSignal(signalId);              // 重置以便复用
};

// 用于跨 rank 同步的网络屏障
class ncclGinBarrierSession {
  ncclGinBarrierSession(coop, gin, team, barrierHandle, index);
  void sync(coop);                         // 全局屏障同步
};

// 可选：为数据附加完成动作
put(..., ncclGin_SignalInc{signalId});     // 远程 signal
put(..., ncclGin_CounterInc{counterId});   // 本地 counter

使用示例。 代码清单 2 演示了使用 GIN 原语实现的单向环形交换（ring exchange）模式。在该内核中，每个 rank 将数据发送给环形拓扑中的后继（myRank + 1），数据沿环单向流动------这是流水化通信算法中的常见模式。put 操作（第 13--16 行）将数据从本地 sendWin 传输到对端 recvWin 的计算偏移处，并在完成时原子地递增远程 signal 0，从而提供数据到达的远程通知。随后，发送 rank 等待自己的 signal 0 被其前驱递增（第 19 行），确保接收到的数据已到达并对本地 GPU 线程可见，然后才继续计算。最后，signal 被重置以供后续通信轮次使用（第 21 行）。该模式展示了 GIN 的异步操作、灵活的完成语义与显式同步原语如何使设备代码实现高效的重叠式点对点通信。

代码清单 2：使用 NCCL GIN 的单向环形交换

cpp 复制代码

__global__ void ringExchange(
  ncclDevComm devComm,
  ncclWindow_t sendWin,
  ncclWindow_t recvWin,
  size_t dataSize, int myRank)
{
  // 初始化上下文 0
  ncclGin gin(devComm, 0);
  int peer = (myRank + 1) % devComm.nRanks;

  // 向对端发送数据，并通过递增对端的
  // signal 来通知完成
  gin.put(ncclTeamWorld(devComm), peer,
           recvWin, myRank * dataSize,
           sendWin, peer * dataSize, dataSize,
           ncclGin_SignalInc{0} );

  // 等待前驱
  gin.waitSignal(ncclCoopCta(), 0, 1);
  // 为下一轮重置
  gin.resetSignal(0);
}

3.3 后端（GDAKI 与 Proxy）实现

设备 API 抽象了两种不同的后端实现，分别实现前文所述的双插件语义。GDAKI 后端通过 DOCA GPUNetIO 实现 GPU---NIC 直接通信，从而实现 GDAKI 语义，插件同时提供设备 API 与控制通路。Proxy 后端通过 CPU 中介的传输实现 Proxy 语义，由 NCCL Core 提供设备 API，插件仅提供基于 CPU 的数据通路操作。两个后端暴露完全相同的设备侧接口，使运行时无需修改应用代码即可透明选择后端。

GDAKI 后端：GPU---NIC 直接通信。 GDAKI 后端以最纯粹的形式实现设备发起的网络：利用 DOCA GPUNetIO，使 GPU 线程无需 CPU 参与即可直接编程网卡。当内核调用 put 时，GPU 线程在设备内存中构造 RDMA 工作队列项（Work Queue Entry，WQE），填入源/目的地址与传输元数据，并直接写入 NIC 的 doorbell 寄存器以触发 DMA 传输。NIC 硬件自主管理操作推进（progress）：轮询 GPU 内存中的新 WQE，在 InfiniBand 或 RoCE 上执行 RDMA 事务，并在 GPU 可见内存中更新完成队列项（CQE）。这条 GPU---NIC 直达路径消除了到 CPU 的 PCIe 往返，实现了小消息的低延迟。但该方案要求较新的硬件与软件：ConnectX-6 Dx 或更新的、具备 GPU 可访问控制结构的网卡，以及所需的 CUDA 12.x 版本（详见 $20$ ）。此外，正确的系统配置------包括 GPUDirect RDMA 内核模块（nv_peer_mem 或 dmabuf）以及 GPU---NIC 共置的 PCIe 拓扑------对正确运行与最优性能至关重要。

Proxy 后端：CPU 辅助通信。 Proxy 后端以峰值性能换取硬件可移植性，将 CPU 作为 GPU 与 NIC 之间的中介引入通信路径。GPU 线程以"发后即忘"（fire-and-forget）的存储方式，将操作描述符------64 字节，包含源/目的窗口句柄、可能的源内联值、偏移、大小与完成动作------enqueue 到分配在 CPU 内存中的无锁队列。每个通信器配有一个专用 CPU 代理线程，绑定（pin）在靠近本 rank GPU 与 NIC 的 NUMA 节点上，持续轮询这些队列。检测到新描述符后，代理线程提取各字段，并通过网络插件的 iput/iput_signal 接口投递网络操作（映射到标准 InfiniBand verbs 或其他网络 API）。插件负责执行 signal，并确保所有先前 put 操作的可见性。完成通知沿反向路径传递：代理线程使用网络插件的 test 接口轮询完成事件，将已完成的操作匹配到其关联的 GIN counter，并更新 GPU 可见内存中的完成状态（根据 GDRCopy 可用性驻留在 GPU 或 CPU 内存）。尽管与 GDAKI 相比，CPU 的参与引入了额外延迟，但 Proxy 后端支持任意 CUDA 版本、任何支持 GPUDirect RDMA 的网卡（InfiniBand、RoCE、iWARP）以及 Volta 或更新的 GPU。此外，CPU 的参与通过主机侧插桩简化了调试，并在 GPU---NIC 直接通信不可用的系统上实现了优雅的性能降级。

后端选择与可移植性。 表 1 总结了 GDAKI 与 Proxy 后端的架构差异。配备现代 NVIDIA 端到端网络基础设施（ConnectX-6 Dx 或更新网卡、较新 CUDA 版本、正确配置的 GPUDirect RDMA）的高性能生产系统倾向选择 GDAKI，以获得最低延迟与零 CPU 开销。开发环境、 legacy 硬件部署、多厂商网络架构或 GPUDirect 支持配置不当的系统，则依赖 Proxy 保证功能正确性与运维灵活性。运行时在通信器初始化（ncclCommInitRank）期间自动检测可用后端：通过能力查询探测 DOCA GPUNetIO 支持，必要时回退到 Proxy。应用可通过环境变量（NCCL_GIN_BACKEND）覆盖该选择，用于调试或性能调优。该设计确保了跨多样化部署场景的可移植性，同时在硬件与软件基础设施允许之处保留 GPU---NIC 直接通信的性能优势。

表 1：NCCL GIN 后端实现的架构对比

特征	GDAKI	Proxy
通信路径	GPU↔NIC 直达	GPU→CPU↔NIC
CPU 参与	零（完全由设备驱动）	必需（每个通信器一个专用线程）
推进模型	NIC 硬件自主轮询 GPU 内存	CPU 线程轮询队列并向 NIC 投递
操作投递	GPU 直接敲响 NIC doorbell	GPU 写描述符；CPU 提取并投递
硬件要求	ConnectX-6 Dx+ 网卡；CUDA 12.2+	任意 RDMA 网卡；任意 CUDA GPU；任意 CUDA 版本
实现基础	DOCA GPUNetIO 设备 verbs	插件 `iput`/`test` API
调试支持	仅设备侧工具	主机侧检查与追踪
可移植性	要求 GPU---NIC 直接访问（参考实现：ConnectX）	通用（所有厂商）
适用场景	生产级 HPC/AI 集群	开发、legacy、多厂商环境

四、DeepEP 集成

本节介绍 NCCL GIN 与 DeepEP 的集成，以验证其对需要计算---通信融合与低延迟的工作负载的有效性。DeepEP 是一个专用的 MoE 通信库，使用 NVSHMEM 与 IBGDA 实现设备发起的稀疏全交换通信------即 dispatch（分发）与 combine（合并）原语。该库提供两种风格的 dispatch 与 combine 原语：高吞吐（High-Throughput，HT）内核与低延迟（Low-Latency，LL）内核，分别用于训练/推理 prefill 阶段和推理 decode 阶段。本次集成展示了如何使用 GIN API 实现 DeepEP 的设备发起通信模式，同时保持其性能特征，并与既有 NVSHMEM 通信后端共存。

4.1 集成要求

DeepEP 的通信模式提出了若干要求：i）高 QP 并行性 ------HT 内核需要 24 个 QP，LL 内核需要 8--16 个 QP（与本地专家数量匹配）；ii）异构拓扑支持 ------HT 使用对称的 rank 对 rank RDMA 加 NVLink 转发，LL 使用全互联 RDMA 网状（mesh）拓扑；iii）细粒度同步 ------对循环缓冲区流控的 head/tail 指针进行原子更新；iv）后端共存------NVSHMEM IBGDA 与 GIN 后端必须共存，以根据执行环境匹配用户偏好。

4.2 后端集成策略

集成为生命周期管理（初始化、内存分配、屏障）采用了一个最小抽象层，同时允许性能关键操作通过条件编译在内核中直接使用后端特定的设备 API。该设计兼容了根本性的语义差异：IBGDA 使用基于指针的寻址与内存原子操作，而 NCCL GIN 使用基于窗口的寻址与 signal 原子操作。

集成解决了四个关键的转换挑战。第一，多通信器映射：由于 NCCL GIN 每个通信器提供 4 个上下文，满足 DeepEP 的 QP 需求需要 ⌈QPs/4⌉ 个通信器，工作通过确定性选择进行分配（comm_id = id / 4，ctx_id = id % 4）。第二，内存管理：后端向所有通信器注册已分配的缓冲区，并将设备可访问的窗口句柄存储在 GPU 内存中，使内核能够将指针运算转换为（窗口，偏移）二元组。第三，同步：预分配的结构化 signal 布局将基于内存的原子操作映射到 signal 原语（HT：每个通道两个 signal，分别用于 head/tail；LL：每个专家一个 signal）。第四，语义保持：带原子 signal 的零字节 put 模拟 release-acquire 语义，确保先前传输在发出完成信号之前的可见性。

表 2：DeepEP 通信内核所用的 DeepEP 自定义 NVSHMEM/IBGDA API 与 NCCL GIN API 对照

注：本表并非 NVSHMEM/IBGDA 与 NCCL GIN API 的全面比较------仅聚焦 DeepEP 库中实际使用的对应 NVSHMEM 与 NCCL API。

方面	DeepEP 自定义 NVSHMEM/IBGDA 层	NCCL GIN
内存模型	PGAS：分区全局地址空间，对称堆；跨 PE 的基于指针的直接寻址	基于窗口：显式注册内存窗口；窗口内基于偏移的寻址
数据传输 API	`put_nbi(dst_ptr, src_ptr, count, pe)`------基于指针的非阻塞 `put`；warp 集合式执行；异步单边	`put(team, peer, dstWin, dstOff, srcWin, srcOff, bytes)`------（窗口，偏移）对；线程级；异步单边
同步原语	内存原子操作：直接对远程内存位置的原子操作（`atomic_add`、`atomic_fetch`）	Signal 原子操作：专用 signal 基础设施；`signal(peer, id)` 执行原子更新，`readSignal(id)` 用于轮询
完成模型	本地 flush ：每个 QP 的 `quiet()`；阻塞直至特定 QP 上发往某个唯一远程 PE 的所有操作完成	按上下文 flush ：每个上下文的 `flush()` 支持跨多个队列的并行完成检查
屏障操作	基于 team 的屏障（`barrier(team)`、`barrier_all()`），使用不透明 team 句柄；同步所有 team 成员	`ncclGinBarrierSession`，带 team 标签与会话 ID；支持无需全 team 协调的对称子集同步

4.3 操作语义映射

从 NVSHMEM 迁移到 NCCL GIN 需要在不同的编程模型之间进行转换，同时保持通信语义。NVSHMEM 提供 PGAS（分区全局地址空间）抽象，采用基于指针的寻址与基于内存的同步原语；NCCL GIN 则遵循基于窗口的单边模型，采用基于 signal 的完成跟踪（已在 3.2 节回顾）。表 2 将 DeepEP 的通信模式映射到对应的 NVSHMEM 与 GIN 原语，突出集成所需的关键语义转换。对于数据传输，内核即时计算窗口相对偏移，并根据通道或专家 ID 确定性地选择通信器，实现跨 QP 的负载均衡。对于同步，基于 signal 的设计将数据移动与完成通知解耦：批量传输使用不带即时 signal 的 put()，随后通过显式 signal() 操作，仅在此前的所有操作完成后才原子地更新远程计数器。该模式通过网络原语而非内存排序实现 release-acquire 语义，确保在 signal 到达时数据可见。

4.4 高吞吐（HT）内核集成

HT 内核针对大批量（4096 个 token）优化，使用分层通信：GPU 通过对称 RDMA 连接将数据发送到远程节点，再由远程节点经 NVLink 将 token 转发到目标 GPU。这在最大化节点内 NVLink 带宽的同时最小化了节点间流量。RDMA 缓冲区包含多个充当 QP 的通道，每个通道都有发送/接收缓冲区。head 与 tail 指针跟踪缓冲区占用情况，提供循环缓冲区流控。

dispatch 内核为各 SM 分配专门角色。奇数编号 SM 充当 Sender（向远程 rank 发送 token）和 NVLink Receiver（最终目的地），偶数编号 SM 充当 Forwarder（接收 RDMA token 并经 NVLink 转发）。这种专门化实现了并发的双向通信。为减少争用，数据/tail 更新与 head 指针更新使用不同的通道，将工作分布到不同的通信器上。

遵循操作映射（表 2），每个 SM 角色使用基于 signal 的原子操作管理指针，使用基于窗口的 put() 传输数据。远程 tail signal 通过 gin.signal(SignalAdd, 1) 递增，head 指针流控依赖通过 gin.readSignal(signal_id) 轮询本地 head signal。数据传输使用单线程的 NCCL GIN put()，随后执行 __syncwarp() 以保持 warp 集合语义。notify dispatch 内核使用一个协调者 SM 来 flush 所有写入（gin.flush()）、在对称 RDMA rank 之间执行屏障、重置 head/tail signal，并在主 dispatch 开始前交换元数据。

combine 内核镜像了 dispatch 内核的专门化设计，每个 SM 使用 25 个 warp。偶数编号 SM 充当 NVLink Sender（将输入 token 分发到本地缓冲区）、RDMA Receiver（将远程 token 与偏置项整合）以及监控接收进度的 Coordinator；奇数编号 SM 充当 NVLink 与 RDMA Forwarder（合并本地 token 并转发给远程 rank），并配有监控 Forwarder 的相应 Coordinator。其操作映射与 dispatch 平行：Forwarder warp 使用单线程 put() 加 __syncwarp() 传输数据，用 readSignal() 轮询 head 指针，用 signal() 更新 tail；Receiver warp 使用 readSignal() 监控 tail 指针；Coordinator warp 通过 signal() 更新 head 指针。

4.5 低延迟（LL）内核集成

LL 内核针对小批量（1--128 个 token）优化，使用全互联 RDMA 网状连接，实现 GPU 到 GPU 的直接通信。token 流内嵌路由元数据，无需单独的 notify 阶段，最小化了 dispatch-combine 周期时间。按专家分配的 signal 提供了集群中任意专家对之间的直接协调。

SM 分配按每个 SM 上 G = ⌈N/S⌉ 个 warp 组来分布专家，其中 N 为专家总数，S 为可用 SM 数。每个 SM 通过 expert_idx = sm_id * G + warp_group_id 分配专家。在每个 warp 组内，大多数 warp 处理 FP8 量化与 token 发送，另有一个计数 warp 管理所有已分配专家的专家计数与元数据。该组织方式实现了跨数百个专家的高效并行化（例如 288 个专家分布在 132 个 SM 上，每个 SM 3 个 warp 组）。

LL 内核利用 NVLink-RDMA 混合通信。对于每次 token 传输，内核通过自定义函数 nccl_get_p2p_ptr 检查 NVLink 可用性：若可用，则使用 warp 级内存操作直接拷贝 token；否则，使用 NCCL GIN 的 put() 执行 RDMA 传输（表 2）。token 首先从 PyTorch 张量拷贝到 RDMA 发送缓冲区，此阶段可选地应用 FP8 量化。完成发往某目的地的 token 传输后，计数 warp 使用带 SignalAdd 的零字节 put() 发送按专家统计的 token 计数，确保所有先前数据传输在计数送达之前已完成并可见------这实现了后端集成策略中所述的 release-acquire 语义。接收方使用 gin.readSignal(signal_id) 轮询，直到 token 到达。

combine 内核将专家输出路由回源 rank，并进行加权归约。它采用相同的 NVLink-RDMA 混合方法，可选地使用 LogFMT 压缩以减少数据量。传输专家输出后，flag signal 通过零字节 put() 结合 SignalAdd 通知目的地，确保在接收方开始累加之前传输已完成。接收方使用 TMA 加载 warp 将专家输出取入共享内存，然后由归约 warp 以 FP32 应用 top-k 权重，最后转换为 BF16 输出。

五、性能评估

本节通过两种互补的方式评估 NCCL GIN 与 NVSHMEM。首先从点对点微基准测试（5.1 节）入手，隔离协议级性能特征；随后评估与 DeepEP 1.2.1 版本（一个生产级 MoE 通信库）的集成。DeepEP 评估（注：尽管 NVSHMEM 同时支持 IBGDA 与 IBRC 传输，DeepEP 的实现与 IBGDA 紧耦合）涵盖用于训练与推理 prefill 的高吞吐（HT）内核（5.2 节），以及用于推理 decode 的低延迟（LL）内核（5.3 节），均在 RDMA+NVLink 混合与纯 RDMA 两种配置下进行。

所有实验在 NVIDIA 的 EOS 集群（配备 H100 GPU，见表 3）上运行，使用 NVSHMEM 3.4.5 与 NCCL 2.28。DeepEP 基准测试为每块 GPU 分配 24 个 SM，通信根据自动选择的通道配置在 NVLink 与 RDMA 之间分配。

表 3：EOS DGXH100 计算节点硬件规格

规格	DGXH100 节点
节点数量	576
GPU 型号	H100 80GB HBM3
每节点 GPU 数	8（合计 640 GB）
GPU 显存带宽	3.2 TB/s
NVLink 代际	第 4 代
NVLink 带宽	900 GB/s（双向）
每 GPU NVLink 数	18 条链路
CPU 型号	Intel Xeon Platinum 8480CL
CPU 插槽数	2
CPU 核心数	112（每插槽 56）
CPU 主频	2.0 GHz 基频，3.8 GHz 睿频
系统内存	2 TB
InfiniBand	8×400 Gbit/s（计算）；2×400 Gbit/s（存储）

5.1 点对点微基准测试

为确立基线性能，我们在两块 H100 GPU 之间使用 ping-pong 测试，测量了 4 字节到 4 MB 消息大小范围内带 signal 的 put 延迟。图 4（原文图 4）展示了 NCCL GIN 双后端（GDAKI 与 Proxy）与 NVSHMEM IBGDA、IBRC 传输的性能对比。

对于小消息（4--128 字节），NCCL GIN GDAKI 实现了 16.7 µs 的往返延迟，与 NVSHMEM IBRC 的 16.0 µs 相当，而 NVSHMEM IBGDA 为 24.3 µs。GDAKI 后端的 GPU---NIC 直达路径消除了 CPU 代理开销；Proxy 后端尽管需要穿越 GPU→CPU 队列，仍实现了 18.0 µs。在较大消息尺寸下，带宽限制占主导地位，所有实现趋于一致，验证了 NCCL GIN 面向应用集成的基本性能特征。

图 4（原文图 4）：点对点延迟：NVSHMEM IBGDA/IBRC 与 NCCL GIN GDAKI/Proxy 后端。
图 5（原文图 5）：NCCL GIN 与 NVSHMEM 的 HT 内核带宽。

5.2 高吞吐（HT）内核

HT 内核针对 MoE 训练与推理 prefill 的大批量 token（4096 个 token）优化，使用分层通信：专门化的 SM 角色（Sender、Forwarder、NVLink Receiver）在最小化节点间 RDMA 流量的同时最大化节点内 NVLink 带宽。图 5（原文图 5）展示了 2、4、8 节点下 FP8 与 BF16 精度的 dispatch 与 combine 带宽，分别报告 RDMA 与 NVLink 指标。

两种实现在所有配置下均提供了相当的性能。在 2 节点（16 块 GPU）、BF16 精度下，NCCL GIN 的 dispatch 操作达到 84.36 GB/s 的 RDMA 带宽，NVSHMEM 为 84.97 GB/s。在 8 节点（64 块 GPU）下，两种实现的 dispatch 操作均维持约 53--54 GB/s 的 RDMA 带宽。在不同规模、精度模式与操作类型下，结果差距均在 1--2% 以内，表明 NCCL GIN 在保持 HT 吞吐的同时，实现了向 NCCL 基础设施的标准化统一。

5.3 低延迟（LL）内核

LL 内核（见第四节）针对 MoE 推理 decode 的小批量 token（1--128 个 token）优化，采用全互联 RDMA 网状连接、按专家分配的 signal 以及 NVLink-RDMA 混合路径。在 BF16 精度、隐藏维度 7168 下，dispatch 操作传输 14,352 字节的消息（14,336 字节 token 数据加 16 字节用于 token 源索引的元数据），combine 操作传输 14,336 字节的消息。带 signal 的零字节 put 操作用于实现数据可见性的 release-acquire 语义。我们在 RDMA+NVLink 混合与纯 RDMA 两种配置下进行评估，以覆盖不同部署场景。

启用 NVLink 的 LL 内核（RDMA+NVLink）。 该配置代表具有节点内 NVLink 与节点间 RDMA 的典型部署。图 6、图 7（原文图 6、7）展示了带宽与延迟对比。在 1 节点（8 块 GPU）下，NCCL GIN 略优于 NVSHMEM：dispatch 达到 185.28 GB/s、40.62 µs，而 NVSHMEM 为 182.15 GB/s、41.43 µs；combine 操作几乎相同（211 GB/s、69 µs）。

在多节点规模下，两种实现表现出相当的性能，仅有微小差异。NCCL GIN 在各规模下始终保持更低的延迟（例如 2 节点时低 9%：142.51 µs 对比 157.00 µs）。combine 操作在所有规模下差距均在 1--3% 以内。

图 6（原文图 6）：启用 NVLink 时 NCCL GIN 与 NVSHMEM 的 LL 内核带宽。
图 7（原文图 7）：启用 NVLink 时 NCCL GIN 与 NVSHMEM 的 LL 内核延迟。

禁用 NVLink 的 LL 内核（纯 RDMA）。 禁用 NVLink 后，所有通信均经由 RDMA------测试跨交换机拓扑或无 NVLink 系统等场景。图 8、图 9（原文图 8、9）的测量结果显示，两种实现在各规模下保持相当的性能，多数指标差距在 1--2% 以内。在 1 节点（8 块 GPU）下，NCCL GIN 的 dispatch 操作达到 47.00 GB/s 带宽与 160.82 µs 延迟，NVSHMEM 为 46.79 GB/s 与 160.67 µs。在 8 节点（64 块 GPU）下，两种实现均维持约 34--35 GB/s 带宽与 219--225 µs 延迟。

图 8（原文图 8）：禁用 NVLink（纯 RDMA）时 NCCL GIN 与 NVSHMEM 的 LL 内核带宽。
图 9（原文图 9）：禁用 NVLink（纯 RDMA）时 NCCL GIN 与 NVSHMEM 的 LL 内核延迟。

5.4 讨论

评估结果表明，NCCL GIN 以与 NVSHMEM 相近的性能特征提供了设备发起的通信能力。在微基准测试与应用工作负载（HT 与 LL 内核）中，GIN 将设备发起的原语与 NCCL 的拓扑感知集合通信集成在单一运行时内，结合了设备侧 API 的灵活性与 NCCL 的生产级基础设施。GIN 的实现仍在积极开发中，计划中的优化包括 WQE 攒批以及在多个操作间摊销 doorbell 开销，以进一步提升性能。

六、相关工作

设备发起的通信库。 OpenSHMEM $29$ $12$ 为对称内存与单边操作确立了 PGAS 语义，但早期的 GPU 扩展仍由 CPU 中介 $14$ 。NVSHMEM $8$ $13$ 实现了可从 CUDA 内核调用的设备端操作，通过消除内核启动开销获得了 60--75% 的加速。然而，NVSHMEM 作为独立于既有集合通信框架的独立运行时运作。GPUrdma $19$ 与 GIO $17$ 等早期 GPU 发起式 RDMA 工作面临 GPU---NIC 内存一致性挑战，通过内核驱动扩展为不规则应用带来了 44% 的提升。DOCA GPUNetIO $36$ $20$ 为 InfiniBand 与 RoCE 提供生产级设备侧 RDMA API，构成了 GIN 之 GDAKI 后端的基础。

集合通信运行时。 NCCL $6$ $24$ 为分布式训练提供拓扑感知的集合算法与生产基础设施，传统上使用主机发起的通信。MPI RMA $30$ 操作仍是主机发起的；UCX $31$ 与 UCC $32$ 提供统一的通信框架，但无设备可调用原语。NCCL 2.28 通过 Device API 扩展了这一点，将设备发起的能力（LSA、Multimem、GIN）集成进 NCCL 的既有基础设施。

MoE 通信库。 MoE 架构需要消息大小不可预测的不规则全交换路由 $25$ 。DeepSpeed-MoE $33$ 采用分层并行；FasterMoE $34$ 与 Tutel $35$ 优化专家调度。DeepEP $26$ 与 pplx-kernels $27$ 提供低延迟的 GPU 发起原语，但独立于集合通信框架运作。

GIN 的定位。 GIN 通过双后端将设备发起的网络原语独特地集成进 NCCL 的生产基础设施：GDAKI 用于 GPU---NIC 直接通信，Proxy 用于在通用硬件上进行 CPU 辅助操作。该集成在保持 NCCL 生态系统兼容性的同时，为 MoE 推理与内核融合模式等新兴工作负载启用了设备驱动的通信。

七、结论与未来工作

现代 AI 工作负载------包括 MoE 推理与编译器生成的融合内核------要求 GPU 直接控制网络操作，这些能力超出了 NCCL 传统主机发起模型的范围。本文介绍了 GIN------NCCL 2.28 Device API $9$ 的组成部分------它使 GPU 线程能够直接从 CUDA 内核发出单边 RDMA 操作。GIN 提供统一的三层架构（主机 API、设备 API，以及具有双语义的可插拔网络后端），既支持经由 GDAKI 的 GPU---NIC 直接通信，也支持在标准 RDMA 硬件上的 CPU 辅助操作。我们的评估验证了 GIN 的实际可行性：GDAKI 后端对小消息实现了 16.7 µs 的往返延迟；DeepEP 集成以极少的代码改动，在 DeepEP 的高吞吐与低延迟内核上展示了有竞争力的性能。

重要的是，GIN 的价值超越了原始性能本身，在于生态系统的统一------通过与 NCCL 生产基础设施的集成提供可扩展性与可扩展性（extensibility）。 应用获得了一套统一的通信抽象------面向 NVLink/PCIe 的 Load/Store Accessible（LSA）、面向 NVLink SHARP 的 Multimem、面向网络 RDMA 的 GIN------从而能为每种模式选择合适的原语。至关重要的是，该集成保留了 NCCL 的生产级特性：支持多维并行（专家并行、张量并行、流水并行）的分层通信器，用于弹性大规模训练的容错与弹性机制，以及拓扑感知优化。这些能力消除了部署多个通信运行时的运维复杂性，同时为 MoE 推理与编译器生成的融合内核等新兴工作负载提供了所需的灵活性。

未来工作将聚焦 GIN 在生产应用中的更广泛采用，例如 PyTorch 分布式训练、TensorRT-LLM 推理服务、用于 LLM 推理的 vLLM 与 SGLang，以及 JAX/Triton 编译器生成的内核。我们还计划用更多单边原语扩展 GIN 的 API，以支持新兴的通信模式与分布式算法需求。

致谢

作者感谢 NCCL 与 NVSHMEM 团队的贡献。作者还感谢 Jeff Hammond 与 Matthew Nicely 对手稿的细致审阅与富有洞见的反馈。

作者声明使用 Cursor AI 协助了本文的写作与编辑。作者已审阅并批准所有内容的准确性与原创性。

参考文献

$1$ NVIDIA Corporation, "TensorRT-LLM: A Framework for Efficient Inference of Large Language Models," 2023. https://github.com/NVIDIA/TensorRT-LLM

$2$ W. Kwon, Z. Li, S. Zhuang, Y. Sheng, et al., "vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention," arXiv:2309.06180, 2023.

$3$ DeepSeek-AI, "DeepSeek-V3 Technical Report," arXiv:2412.19437, 2024.

$4$ P. Tillet, H. T. Kung, D. Cox, "Triton: An Intermediate Language and Compiler for Tiled Neural Network Computations," MAPL@PLDI, 2019.

$5$ J. Bradbury, R. Frostig, P. Hawkins, et al., "JAX: Composable Transformations of Python+NumPy Programs," 2018. http://github.com/google/jax

$6$ NVIDIA Corporation, "NCCL: Optimized Primitives for Collective Multi-GPU Communication," 2023. https://developer.nvidia.com/nccl

$7$ NVIDIA Corporation, "NVSHMEM: Scalable Communication Library for NVIDIA GPU Clusters," 2020. https://developer.nvidia.com/nvshmem

$8$ NVIDIA Corporation, "NVSHMEM 3.0 Programming Guide," 2023. https://docs.nvidia.com/nvshmem/

$9$ S. Jeaugey, J. Bachan, P. Markthub, et al., "Fusing Communication and Compute with New Device API and Copy Engine Collectives in NVIDIA NCCL 2.28," NVIDIA Technical Blog, 2025.

$10$ A. Paszke, S. Gross, F. Massa, A. Lerer, et al., "PyTorch: An Imperative Style, High-Performance Deep Learning Library," Advances in Neural Information Processing Systems (NeurIPS), 2019.

$11$ L. Zheng, L. Yin, Z. Xie, et al., "SGLang: Fast Serving Framework for Large Language Models and Vision Language Models," 2024.

$12$ OpenSHMEM Specification Committee, "OpenSHMEM Application Programming Interface, Version 1.0," 2012.

$13$ S. Potluri, A. Goswami, D. Rossetti, et al., "GPU-Centric Communication on NVIDIA GPU Clusters with InfiniBand: A Case Study with OpenSHMEM," 24th IEEE International Conference on High Performance Computing (HiPC), 2017.

$14$ M. G. Venkata, N. Imam, S. Pophale, et al., "Exploring OpenSHMEM Model to Program GPU-Based Extreme-Scale Systems," OpenSHMEM and Related Technologies, 2015.

$15$ NVIDIA Corporation, "GPUDirect RDMA," 2013. https://docs.nvidia.com/cuda/gpudirect-rdma

$16$ S. Potluri, K. Hamidouche, A. Venkatesh, et al., "Efficient Inter-Node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs," 42nd International Conference on Parallel Processing (ICPP), 2013.

$17$ K. Hamidouche, T. L. Falch, K. Beatty, et al., "GPU Initiated OpenSHMEM: Correct and Efficient Intra-Kernel Networking for dGPUs," IEEE International Parallel and Distributed Processing Symposium (IPDPS), 2020.

$18$ E. Agostini, D. Rossetti, S. Potluri, "GPUDirect Async: Exploring GPU Synchronous Communication Techniques for InfiniBand Clusters," Journal of Parallel and Distributed Computing, 2018.

$19$ A. Daoud, M. Suntinger, G. Kestor, et al., "GPUrdma: GPU-Side Library for High Performance Networking from GPU Kernels," ACM International Conference on Computing Frontiers, 2016.

$20$ NVIDIA Corporation, "DOCA GPUNetIO Programming Guide." https://docs.nvidia.com/doca/sdk/doca-gpunetio/

$21$ NVIDIA Corporation, "RDMA Technologies Comparison: InfiniBand, RoCE, iWARP," 2022. https://network.nvidia.com/

$22$ CloudSwitch, "InfiniBand vs RoCE: A Comprehensive Guide," 2025. https://www.cloudswitch.com/

$23$ NVIDIA Corporation, "GPUDirect RDMA Requirements and Recommendations," 2021. https://docs.nvidia.com/cuda/gpudirect-rdma

$24$ Z. Hu, S. Shen, T. Bonato, S. Jeaugey, et al., "Demystifying NCCL: An In-Depth Analysis of GPU Communication Protocols and Algorithms," IEEE Symposium on High-Performance Interconnects (HOTI), pp. 48--59, 2025.（译者注：原文以 hu2025demystifying 与 Zhiyi25 两个键分别引用此文）

$25$ D. Ren, C. Qin, K. Liu, et al., "DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models," arXiv:2401.06066, 2024.

$26$ DeepSeek-AI, "DeepEP: Efficient Mixture-of-Experts Communication Library," 2025. https://github.com/deepseek-ai/DeepEP

$27$ Perplexity AI, "pplx-kernels: Perplexity GPU Kernels for MoE Communication," 2024. https://github.com/perplexityai/pplx-kernels

$28$ T. Hoefler, J. Dinan, R. Thakur, et al., "Remote Memory Access Programming in MPI-3," ACM Transactions on Parallel Computing, 2015.

$29$ B. Chapman, T. Curtis, S. Pophale, et al., "Introducing OpenSHMEM: SHMEM for the PGAS Community," 4th Conference on Partitioned Global Address Space Programming Model (PGAS), 2010.

$30$ MPI Forum, "MPI: A Message-Passing Interface Standard, Version 4.0," 2021.

$31$ P. Shamis, M. G. Venkata, M. G. Lopez, et al., "UCX: An Open Source Framework for HPC Network APIs and Beyond," 23rd IEEE Annual Symposium on High-Performance Interconnects (HOTI), 2015.

$32$ OpenUCX Community, "Unified Collective Communication (UCC) Library." https://github.com/openucx/ucc

$33$ S. Rajbhandari, C. Li, Z. Yao, et al., "DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale," 39th International Conference on Machine Learning (ICML), 2022.

$34$ J. He, J. Zhai, T. Antunes, et al., "FasterMoE: Modeling and Optimizing Training of Large-Scale Dynamic Pre-Trained Models," 27th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP), 2022.

$35$ C. Hwang, W. Cui, Y. Xiong, et al., "Tutel: Adaptive Mixture-of-Experts at Scale," Proceedings of Machine Learning and Systems (MLSys), 2023.

$36$ NVIDIA Corporation, "DOCA: Data Center Infrastructure on a Chip Architecture," 2023. https://developer.nvidia.com/networking/doca