解析GPUDirect RDMA及类似技术

GPU Direct RDMA是2009年由Nvidia和Mellanox共同研发的软硬件协同创新技术。

当时GPU已经从图形渲染转向通用计算（GPGPU），成为HPC的核心加速器。GPU计算能力虽然在持续提升，但因为集群中不同节点之间的GPU间传输数据，仍需要CPU负责，通信存在瓶颈，所以GPU的计算能力的优势受其拖累不能完全发挥，从而导致集群整体效率不高。

NVIDIA当时清晰地认识到必须解决这个问题，所以开始与合作伙伴Mellanox一起探索GPU与网卡的直接通信的解决方案GPU Direct over InfiniBand。后续该技术方案逐渐成熟，并于2012年随Kepler架构GPU和CUDA 5.0一起发布，并被正式命名为GPUDirect RDMA。

一、技术简介

在没有GPUDirect技术之前，两台机器上的GPU进行通信，需要

1.GPU将数据从显存写入（GPU管理的）系统内存1

2.主机CPU将数据从系统内存1复制到（InfiniBand 网卡管理的）系统内存2

3.InfiniBand 网卡从系统内存2读取数据，并将数据传输到远程节点。

GPUDirect 1.0通过下面技术手段，通过共享缓冲区，消除了CPU参与的InfiniBand网卡与GPU之间的内存拷贝，减少了30%的GPU之间的通信时间。

1.Linux 内核修改

使得内存管理器允许NVIDIA 和 Mellanox 驱动程序共享主机内存，并让Mellanox驱动直接访问由CUDA库分配的缓冲区，从而实现零拷贝数据传输。

2.NVIDIA 驱动程序修改

使其具备标记共享内存页的能力，使得内核内存管理器将允许Mellanox 驱动程序访问这些内存页并将其用于数据传输，而无需进行拷贝或重新固定。

3.Mellanox 驱动程序修改

驱动程序能够查询内存，并通过使用新的内核内存管理器API与 NVIDIA驱动程序共享内存。

但在GPUDirect 1.0 方法中，存储在 GPU 内存中的数据仍会被复制到系统内存中，而GPUDirect RDMA针对此进行了进一步改进，使得RDMA网卡能够直接访问 GPU 显存，不需要借助主机系统内存，即可实现从 GPU显存到外部节点的直接DMA传输。

在GPUDirect改善了数据路径的传输性能之后，在2016年，CUDA8.0中还进一步发布了GPUDirect Async技术，通过该技术，可以优化GPU和网卡之间的控制路径，把CPU进一步解放出来。

二、关键技术

GPU Direct RDMA实现的关键在于建立地址可见性。地址可见性是实现GPU显存和RDMA网卡直接通信的核心前提。若地址不可见，RDMA网卡无法直接与 GPU 显存传输数据，只能依赖 CPU 中转。

为什么之前GPU显存地址不可见呢？因为GPU 拥有独立的内存子系统与内存管理单元，其显存地址是设备私有地址，与主机系统内存的物理地址空间完全隔离。

那么地址可见性问题是如何解决的呢？

首先，GPU需要通过PCI BAR向主机系统暴露显存物理地址的访问窗口，这是第三方设备访问 GPU 显存的硬件入口。

GPU向BIOS / OS申请一段物理地址空间（即BAR区域），并将该区域与部分显存空间绑定，这样RDMA网卡（注意GPU和RDMA网卡需要在同一个RC下，）只需访问该BAR 地址，即可间接访问对应的GPU显存物理地址。

第二，需NVIDIA 内核驱动提供地址翻译函数，将 GPU 虚拟地址转换为第三方设备可访问的物理地址。

这块的核心函数是nvidia_p2p_get_pages()，其核心作用是：

接收GPU 虚拟地址（如 cudaMalloc返回的指针）与长度，校验地址有效性（是否为 GPU 显存地址、是否未被释放），将 GPU 虚拟地址转换为与 BAR 绑定的物理地址，并存储在 nvidia_p2p_page_table 结构体中（该结构体的 physical_address 字段即为第三方设备可访问的物理地址），返回页表指针给RDMA驱动，供其配置DMA引擎。

第三，CUDA 的 UVA（Unified Virtual Addressing）机制为地址可见性提供底层内存布局支撑，确保 GPU地址在软件层面可被区分与管理

UVA 将应用程序的 VA 空间分为CUDA 管理区与OS管理区，其中CUDA管理区又细分为GPU 地址、CPU 地址、FREE 预留地址三类；

RDMA网卡等驱动可通过 UVA 布局，可快速判断某个地址是否为GPU 显存地址，避免对 CPU 地址进行无效的GPU地址映射；

配合cuPointerSetAttribute和cuPointerGetAttribute这些API可以进行地址的区分和管理。比如cuPointerSetAttribute(&flag, CU_POINTER_ATTRIBUTE_SYNC_MEMOPS, ptr)可确保该地址的内存操作与 RDMA 传输同步，避免地址失效等。

三、类似技术方案

1.开源方案DMA-BUF + RDMA

GPUDirect RDMA构建了一个以NVIDIA硬件为中心的护城河，其他厂商（如AMD、Intel）的GPU难以加入。

而开源方案DMA-BUF+IB CORE 则是利用了Linux内核提供的标准框架和接口的通用方案，硬件厂商只需要遵循这些公开接口开发驱动，即可相互协作。这对AMD、Intel、以及摩尔线程、壁仞等GPU厂商、以及NPU厂商是很利好的，也降低了RDMA网卡厂商的入场门槛。

DMA-BUF是和GPUDirect差不多时间的一个技术，它2012年就被收入Linux 3.3 主线内核（和GPUDIrect RDMA同一年）。

DMA-BUF是一个标准化的、基于文件描述符的缓冲区共享机制。

它允许一个设备驱动（exporter）将其内存区域安全地导出成一个dma-buf object，供另一个设备驱动（importer）直接访问。

exporter还需要实现一套 dma_buf_ops 回调函数，供importer调用来操作缓冲区。

整个过程由Linux内核统一仲裁和管理，实现了跨设备的零拷贝数据传输。

Intel利用了这个标准方案，实现了GPU内存的RDMA传输通用方案，并于2021年合入了Linux5.12主线内核：

GPU 厂商承担 DMA-BUF的Exporter 角色，让 GPU 显存可被 RDMA 设备通过标准接口访问；

RDMA 网卡厂商需承担 DMA-BUF的Importer 角色，通过标准接口访问 GPU 显存，实现 RDMA 直传。

2.AMD ROCnRDMA

AMD ROCm RDMA（ROCm Remote Direct Memory Access）是 AMD 为打破 NVIDIA GPUDirect RDMA 生态垄断、适配自家GPU与数据中心场景需求而打造的 设备直连通信技术，2018年被开始被引入到ROCm3.0，也叫ROCnRDMA，原理和NIVIDIA的相同。

并同步推出RCCL（ROCm 集合通信库），将 ROCm RDMA 能力整合进分布式训练场景，支持多节点 AMD GPU 的梯度同步与参数交换，为HPC与AI 训练提供通信支撑。

资料较少，有需要了解的同学，可以看源码：

https://github.com/ROCm/amdgpu/blob/master/drivers/gpu/drm/amd/amdkfd/kfd_peerdirect.c

从AMD2023年的资料来看，长期来看dmabuf将会取代ROCnRDMA的内核组件。

从这个角度来看，AMD ROCm RDMA定位是开源DMA-BUF + IB CORE + GPU + RDMA网卡的一个专用于AMD的方案。

四、总结

尽管GPUDirect RDMA 仍在纯 NVIDIA 生态中保持性能优势，但DMA-BUF RDMA方案，应该更得AMD、壁仞、摩尔线程、华为等异构算力厂商的支持。

我认为，DMA-BUF+RDMA 将成为异构算力集群（多厂商 GPU/NPU + 混合 RDMA 网卡）的默认选择，支撑对兼容可控有需求的场景；而GPUDirect RDMA则聚焦超算、大规模 AI 训练等对极致性能有绝对需求的纯VIDIA场景。

这些技术的迭代，最终指向的是算力无界协同的目标：让不同品牌、不同类型的加速设备，能以更低成本、更高效率实现数据直连，释放HPC 与 AI 大模型场景的算力潜力，这也是异构计算时代下，硬件生态从锁定走向开放的必然方向。

我收集了一些技术相关的资料，可供延伸阅读。有兴趣的同学可以从下面的链接获取:

https://pan.baidu.com/s/1ZrGUXdMn9fk0jDffV5DvRw?pwd=xlx1 提取码: xlx1