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

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)