The Landscape of GPU-Centric Communication

发表时间: 2024-09 · arXiv:2409.09874 (Survey)

作者/机构: DIDEM UNAT, Koç University, Turkey; ILYAS TURIMBETOV, Koç University, Turkey; MOHAMMED KEFAH TAHA ISSA, Koç University, Turkey; DOĞAN SAĞBILI, Koç University, Turkey; FLAVIO VELLA, University of Trento, Italy; DANIELE DE SENSI, Sapienza University of Rome, Italy; ISMAYIL ISMAYILOV, Koç University, Turkey

速读

一句话结论 本文对“以GPU为中心的通信”进行了系统性综述，梳理了从底层硬件互连、内存与网络机制到上层通信库的演进路线，为解决多GPU扩展时的通信瓶颈提供了完整技术图谱。

要解决什么问题 在高性能计算和机器学习中，多GPU集群是算力底座，但GPU间通信迅速成为可扩展性瓶颈。传统通信采用“以CPU为中心”的模型，将GPU仅视为算力协处理器，数据移动与同步高度依赖CPU。这带来三大卡点：一是数据路径冗余，GPU间传输需先拷贝到主机内存，再由CPU路由到目标GPU或网卡（NIC），导致高延迟和带宽浪费；二是控制路径阻塞，通信发起和同步必须由CPU介入，迫使GPU频繁中断计算等待调度，破坏了计算与通信的重叠；三是语义不匹配，细粒度通信模式极难扩展，因CPU无法高效处理GPU海量并发线程的微小数据交换。因此，将通信的数据与控制路径从CPU卸载到GPU，赋予其自主管理通信的能力，是突破扩展墙的关键。

怎么做的 本文通过建立统一的分类学，将以GPU为中心的通信机制按API调用位置和数据路径参与者进行解构。节点内通信被划分为主机原生、主机控制、设备原生及带回退的设备原生四类；节点间通信则按数据包构建和触发者的不同，划分为从完全依赖CPU到完全由GPU接管的五个阶段。核心思路是通过内存管理和直接访问技术逐步剥离CPU。内存管理方面：页锁定内存（Pinned Memory）跳过可分页内存的暂存拷贝；统一虚拟寻址（UVA）将CPU和所有GPU内存映射到同一地址空间；进程间通信（IPC）打破跨进程缓冲区访问限制；统一虚拟内存（UVM）实现按需隐式分页与显存超订。数据与控制路径直通化主要由GPUDirect系列实现：GPUDirect 1.0让GPU和NIC共享主机固定内存；GPUDirect P2P结合UVA，允许同节点GPU通过PCIe直接读写对方显存，引入直接加载与存储机制，使通信能内联到计算内核中；GPUDirect RDMA将GPU显存暴露给NIC的基地址寄存器，实现跨节点直接内存访问；GPUDirect Async允许GPU触发CPU预注册的网络消息。为实现完全自主，GPUNetIO允许GPU在内核执行期动态构建数据包并与NIC同步，彻底摆脱CPU。硬件互连上，NVLink和Infinity Fabric等提供极高物理带宽，并支持交换机层面的集合通信卸载。基于此，上层通信库完成范式转换：GPU-Aware MPI自动利用IPC和RDMA消除冗余拷贝；而以GPU为中心的集合通信库（如NCCL）摒弃了多次内核启动，将集合通信与局部归约计算融合在单一GPU内核中，大幅降低同步开销。

效果如何 本文作为系统性综述，未搭建传统对比实验，而是横向对比了各技术路线的硬件规格与固有代价。量化规格上，现代互连技术吞吐量惊人：NVIDIA Blackwell架构的第五代NVLink实现单GPU 1.8 TB/s双向带宽，可通过NVSwitch扩展至576卡全连接；AMD的xGMI在8卡系统提供896 GB/s总带宽。然而，这些方法在工程中面临明确的代价与失效场景。首先，固定内存过度分配会挤占物理内存拖垮系统。其次，GPUDirect P2P的直接读写虽能隐式重叠计算与通信，但通信线程会与计算争夺GPU资源；且该机制对内存访问模式极度敏感，非合并的随机读写会暴露远程内存延迟，导致执行停滞。在节点间通信中，GPUDirect RDMA在内核运行期无法保证GPU与NIC的内存一致性，必须依赖CPU拆除内核或调用特定API强制同步，导致持久化内核跨节点通信易出正确性问题。此外，GPUDirect Async受限于只能触发CPU预注册的消息，未彻底解耦控制路径。

A1 主要贡献

近年来，GPU因其大规模并行性和高内存带宽，已成为高性能计算（HPC）和机器学习（ML）应用的首选加速器。截至2025年11月，Top500超级计算机排名前10的系统中，有9个依赖GPU集群进行加速【79, TOP500 Supercomputer Sites, 2023, https://www.top500.org/】 。

核心问题: 尽管大量使用GPU能显著加速计算，但GPU之间的通信很快成为可扩展性的瓶颈【136, Peta-Scale Phase-Field Simulation for Dendritic Solidification on the TSUBAME 2.0 Supercomputer, 2011, SC ’11】【149, The Persistent Challenge of Data locality in Post-Exascale Era, 2025, Computing in Science and Engineering】。传统上，多GPU通信（无论是节点内还是节点间）一直由CPU负责，这种以CPU为中心的执行模型将GPU视为仅提供大量计算的设备，而在通信等辅助任务上依赖CPU。

研究目标: 过去十年中，一系列被称为“以GPU为中心的通信”的进步旨在挑战CPU在多GPU执行中的主导地位。这些进步从高层次上减少了CPU在关键执行路径上的参与，赋予GPU在发起和同步通信方面更多的自主权，并试图解决多GPU通信与计算之间的语义不匹配问题。

本文贡献: 本文对以GPU为中心的通信进行了全面的综述，重点关注供应商提供的机制和用户级库的支持。本文旨在：
1. 澄清复杂性：帮助研究人员、程序员、工程师以及库设计者理解该领域中各种可用选项的复杂性和多样性。以GPU为中心的通信涵盖了从专有硬件（如GPU间互连）到软件机制的广泛方法，这些方法各有优缺点，使得选择变得困难。
2. 定义术语和分类：定义“以GPU为中心的通信”，并对现有节点内和节点间的通信方法进行分类和抽象，以消除文献和供应商之间术语不一致造成的混淆。
3. 综述技术和库：介绍和讨论供应商为实现多GPU通信、网络和内存管理所提供的机制，这些机制是更高级别软件库的构建块。同时，回顾主要的通信库，讨论它们的优势、挑战和性能特点。
4. 展望未来：探讨以GPU为中心的通信背后的主要研究范式、未来前景和开放的研究问题。

本文通过广泛描述跨越软硬件堆栈的以GPU为中心的通信技术，为研究人员和开发者提供了如何最佳利用多GPU系统的见解。

A3 背景知识、关键观察与设计原则

我们可以将以GPU为中心的通信宽泛地定义为减少CPU在多GPU执行关键路径中参与的机制。这是一个非常宽泛的定义，涵盖了从赋予GPU通信自主权的供应商级改进到利用这些改进的用户级实现。为了明确区分，我们在不同章节中讨论它们。第3节关注NVIDIA CUDA和AMD ROCm运行时原生提供的通信机制和原语。第4节讨论这些机制如何催生更高级别的、以GPU为中心的通信库，并介绍AMD、Intel和NVIDIA提供的软件支持以及其他工业界和学术界的解决方案。

我们还指出了节点内通信（intra-node）和节点间通信（inter-node）的区别。单个GPU加速节点包含一个共享内存主机和多个GPU卡。在节点内通信时，任何给定的GPU可以由单个线程或进程控制，具有共享内存和地址空间。多节点系统则有多个这样的节点，其中每个GPU由不同进程控制，并且不同节点上运行的进程之间不共享内存。通信的格局根据所用设置而变化，因为节点间通信需要处理GPU-NIC交互和跨进程通信。

2.1 节点内通信

尽管将通信方法分为GPU侧和CPU侧的分类很常用，且对最终用户来说可能足够，但它并不总是具有解释性和准确性。为了避免定义的模糊性，我们将通信方法分为几种类型。这些类型基于通信期间执行的每个操作的执行者。我们定义了在节点内场景中通信所需的两个主要操作，以及在节点间场景中的四个操作。在节点内情况下，通信调用的两个组成部分是：

表1和图1展示了节点内通信机制的分类示例及其数据路径。


Table 1. 节点内通信方法的类型

1中被称为主机原生（host native）的通信方法在主机侧进行，并且不涉及设备之间的直接P2P（点对点）访问。这包括所有可以在禁用P2P访问的主机侧启动的方法。否则，如2（主机控制，host-controlled）所示，通信不涉及额外复制到主机内存，而是直接通过PCIe、NVLink或Infinity Fabric互连。GPUCCL（即NCCL、RCCL、oneCCL等）、GPU-aware MPI和*memcpy操作具有主机侧API，因此它们可能属于1和2。通过启用对对等设备内存的直接访问，设备侧API消除了CPU在节点内通信中数据和控制路径的参与，如图1中的3（设备原生，device native）所示。NVSHMEM、ROCSHMEM、Intel SHMEM也提供主机侧API，但需要P2P访问，因此它们的主机侧API属于2，设备侧API属于3。内核内P2P直接加载和存储提供类似功能并属于类型3，但即使在P2P访问禁用的情况下也能工作，即类型4，此时数据路径回退到主机。

图1. 节点内通信方法的数据路径和API调用。该图在CC-BY [150] 许可下可用。
图1. 节点内通信方法的数据路径和API调用。该图在CC-BY [150] 许可下可用。

2.2 节点间通信

节点间场景更加多样化，因为需要与NIC（网络接口卡）进行交互。每种方法的实现细节可能涉及复杂的数据路径和决策。为了简化分类，我们区分了节点间通信的四个主要组成部分。除了节点内场景中使用的API和数据路径（到NIC），还有两个涉及与NIC交互的额外组件：

我们在分类节点间通信时确定了五个主要类别。如表2和图2所示，从1到5，通信调用的更多组件被移至GPU侧，而数据传输路径到达NIC所需的数据复制次数减少。多年来，通信方法和相应技术描绘了数据传输和通信控制的优化，我们将在第3节中讨论。首先，1中完全在CPU侧的通信方法可用，然后在2中通过在GPU和NIC之间使用共享固定内存，消除了CPU-GPU和CPU-NIC缓冲区之间的额外复制，从而得到改进。这降低了GPU-NIC传输的延迟。之后，GPU RDMA（远程直接内存访问）3促进了NIC通过PCIe直接访问GPU内存，最小化了它们之间的数据路径。4代表了GPU触发的通信技术，如GPUDirect Async和GPU-TN【73, GPU Triggered Networking for Intra-Kernel Communications, 2017, SC ’17】，其中GPU变得能够发起通信，前提是CPU预先在NIC上准备好数据包。5将数据包准备和与NIC的交互也完全移至GPU，使设备原生通信成为可能。

表2和图2中给出的类型并未反映所有可能的组合，因为一些库根据配置和可用硬件可能会导致不同的数据路径和控制组合。例如，如果没有RDMA技术，即使使用GPU侧通信控制，数据路径也会涉及主机内存。


Table 2. 节点间通信方法的类型。粗体单元格表示发生变化或优化的位置。D/H表示设备侧和主机侧API调用都可能属于此类型。

图2. 节点间通信的数据和控制路径。该图在CC-BY [150] 许可下可用。
图2. 节点间通信的数据和控制路径。该图在CC-BY [150] 许可下可用。

例如，Intel SHMEM即使通信调用是在GPU上运行的设备内核内发出的，也会在主机上使用一个代理线程通过标准的OpenSHMEM库来执行实际的RDMA。

A2 方法细节

3 供应商机制

本节我们讨论供应商为实现多GPU执行中的通信、网络和设备间内存管理所提供的机制。这些机制由GPU编程模型运行时或作为扩展API的一部分提供。这些技术分为四类：内存管理器、GPUDirect技术、硬件和库。图3总结了NVIDIA提供的技术，详细说明了它们的时间线和可用性。

接下来，我们介绍内存管理机制和GPUDirect技术，然后是作为这些通信方法先驱并最终使其可行的硬件支持。这些技术构成了更高级别的以GPU为中心的库的骨干，我们将在第4节中讨论这些库。

图3. 启用以GPU为中心的通信和网络的NVIDIA技术时间线。该图在CC-BY [150] 许可下可用。
图3. 启用以GPU为中心的通信和网络的NVIDIA技术时间线。该图在CC-BY [150] 许可下可用。

3.1 内存管理机制

3.2 GPUDirect技术

3.3 GPUNetIO

3.4 现代以GPU为中心的互连技术

3.5 供应商机制讨论

为了将这些供应商机制置于更广泛的通信生态系统中，图4总结了从应用程序和通信库到中间件、驱动程序和网络结构的软件堆栈。这个分层视图有助于将本节讨论的低级机制与接下来要审查的用户级通信库联系起来。

图4. 面向RDMA的以GPU为中心的通信软件堆栈，显示了从应用程序和领域框架到通信库、传输中间件、提供商库、内核驱动程序、网络结构和供应商软件堆栈的各个层次。该图在CC-BY [150] 许可下可用。
图4. 面向RDMA的以GPU为中心的通信软件堆栈，显示了从应用程序和领域框架到通信库、传输中间件、提供商库、内核驱动程序、网络结构和供应商软件堆栈的各个层次。该图在CC-BY [150] 许可下可用。

4 以GPU为中心的通信库

我们现在讨论近年来为简化多GPU编程而涌现的主要以GPU为中心的通信库，即GPU-aware MPI、GPU-centric Collectives和GPU-centric OpenSHMEM。

4.1 GPU-Aware MPI

4.2 以GPU为中心的集合通信 (GPUCCL)