一文讲透 GPUDirect RDMA：它到底解决了什么问题？AWS 上哪些 GPU 实例能用？

这两年搞大模型训练、分布式推理、HPC 计算，绕不开几个词：GPU、NVLink、NCCL、EFA、RDMA、GPUDirect RDMA。

我之前刚接触这块的时候，说实话也挺懵。一个模型训练慢，大家开会的时候嘴里都是“通信瓶颈”“AllReduce 太慢”“跨节点带宽不够”“EFA 没跑起来”“NCCL 没走 GPUDirect”。听着都挺高级，但落到机器上，最后还是那几条命令：nvidia-smi topo -m、fi_info、nccl-tests、NCCL_DEBUG=INFO。

这篇我就按运维视角聊聊：GPUDirect RDMA 是什么，它有什么用，它到底解决了什么问题，目前相关技术路线有哪些，AWS 上哪些实例支持，怎么简单判断自己有没有跑起来。

先说一个很现实的问题：GPU 很快，但数据搬来搬去很慢

现在 GPU 算力已经很猛了，A100、H100、H200 这些卡，单卡算力放以前看都不敢看。但真正跑分布式训练的时候，经常会发现一个现象：

GPU 利用率不是一直 95%、98%，而是忽高忽低，有时候卡在 40%、50%，甚至一堆 GPU 在等网络。

这个事情在单机 8 卡里还好一点。比如一台机器里面有 8 张 A100，卡和卡之间可以走 NVLink/NVSwitch，速度很高，延迟也低。

但问题来了，模型越来越大，一台机器装不下，或者训练时间太长，就要多机多卡。

比如 16 台机器，每台 8 张 GPU，就是 128 卡。再往上 256 卡、512 卡、1024 卡，甚至更多。

这个时候训练过程里会有大量 GPU 之间的数据同步，典型的就是梯度同步，也就是大家经常说的 AllReduce。每一轮训练，GPU 算完一部分以后，要把结果跟别的 GPU 对齐一下。你算你的，我算我的，最后还得合账。

这时候网络就变成了关键。

如果跨节点通信慢，GPU 就会出现一种很尴尬的情况：算得飞快，但等数据等到怀疑人生。就像你请了 8 个厨师切菜，刀工飞起，但是传菜口只有一个小窗口，菜出不去，后厨再猛也没用。

GPUDirect RDMA 解决的就是这个“传菜口太慢、搬运路径太绕”的问题。

普通 GPU 跨机器通信，数据到底怎么走？

为了说清楚 GPUDirect RDMA，我先说下没有它的时候，数据大概怎么走。

假设有两台机器：

机器 A 上有 GPU A
机器 B 上有 GPU B
两台机器通过高速网卡连接

现在 GPU A 的显存里有一块数据，要发给 GPU B。

传统路径大概是这样：

GPU A 显存
   ↓
机器 A CPU 内存
   ↓
机器 A 网卡 NIC
   ↓
网络
   ↓
机器 B 网卡 NIC
   ↓
机器 B CPU 内存
   ↓
GPU B 显存

你看这里面有几个问题：

GPU 显存要拷贝到 CPU 内存
CPU 内存再交给网卡
对端网卡收到后先进 CPU 内存
CPU 内存再拷贝到 GPU 显存
CPU 要参与调度和搬运
内存总线、PCIe、CPU 都被牵扯进去

如果数据量小还好，大模型训练的时候，动不动就是 GB 级别通信，这个复制成本就很明显了。

很多时候，不是 GPU 不够强，是数据搬运太绕了。

GPUDirect RDMA 是什么？

一句话版本：

GPUDirect RDMA 允许网卡直接访问 GPU 显存，实现跨机器 GPU 到 GPU 的低延迟、高吞吐通信，尽量绕开 CPU 内存中转。

更接地气一点说，就是原来搬东西要经过中转仓库：

GPU → CPU 内存 → 网卡 → 网络 → 网卡 → CPU 内存 → GPU

有了 GPUDirect RDMA 后，路径可以更接近这样：

GPU 显存 → 网卡 → 网络 → 网卡 → GPU 显存

当然实际底层比这个复杂，不是说 CPU 完全消失了，CPU 还是要初始化、注册内存、提交任务、协调流程。但真正的大块数据传输，不再需要 CPU 内存反复做中转。

AWS 官方对 EFA 支持 GPUDirect RDMA 的描述也比较清楚：它通过网络接口卡直接访问 GPU 内存，避免额外的内存复制，从而让远程 GPU 到 GPU 通信更快，也减少 CPU 和用户应用程序的编排开销。[2]

这个“避免额外内存复制”，就是重点。

RDMA 又是什么？和 GPUDirect RDMA 什么关系？

RDMA 全称是 Remote Direct Memory Access，远程直接内存访问。

简单讲，RDMA 允许一台机器的网卡直接读写另一台机器的内存，中间尽量绕开远端 CPU 的参与。

传统 TCP/IP 通信，数据要经过内核协议栈，用户态、内核态来回切，CPU 处理协议、拷贝数据、收包发包。不是不能用，而是在高性能计算、大规模训练这种场景下，开销太大。

RDMA 想干的事就是：

低延迟
高吞吐
少拷贝
少 CPU 参与
用户态直接提交通信操作

常见 RDMA 技术路线有几种：

InfiniBand
RoCE / RoCEv2
iWARP
AWS EFA

这里面 InfiniBand 在 HPC 场景很常见，性能强，生态成熟。RoCE 是在以太网上跑 RDMA，云厂商和很多数据中心也会用。AWS 上比较特别，它不是让你直接操作传统 IB 网络，而是提供 EFA，也就是 Elastic Fabric Adapter。

EFA 是 AWS 给 EC2 做的定制网络接口，用来跑需要高实例间通信性能的应用，比如 HPC、分布式机器学习这些。[2]

GPUDirect RDMA 则是在 RDMA 的基础上，把目标内存从普通 CPU 内存扩展到了 GPU 显存。网卡能直接跟 GPU 显存打交道，这就把 GPU 分布式通信的链路缩短了。

它到底有什么用？别只看概念，生产里主要看这几个地方

我自己理解，GPUDirect RDMA 主要解决三个问题。

1、减少拷贝，降低延迟

没有 GPUDirect RDMA 的时候，GPU 显存和网卡之间往往要经过 CPU 内存中转。中间多一次拷贝，就多一次延迟，多占一次带宽，多吃一点 CPU。

训练任务规模小的时候，感觉不明显。节点一多，AllReduce 频繁起来，这点开销会被放大。

尤其是大模型训练里，有些通信是密集又频繁的，不是偶尔传个文件。

2、释放 CPU，不让 CPU 当“搬运工”

CPU 本来应该做调度、数据预处理、运行框架逻辑，结果大量时间被通信拷贝拖住，挺浪费。

GPUDirect RDMA 可以减少 CPU 在数据搬运中的参与。AWS 官方也提到，EFA 对 GPUDirect RDMA 的支持可以减少 CPU 和用户应用程序的编排开销。[2]

这句话在生产里翻译一下就是：CPU 少干点脏活，GPU 通信更直接。

3、提升多机多卡训练扩展效率

单机 8 卡扩到 16 卡，可能效率还不错。但从 8 卡扩到 64 卡、128 卡、512 卡，训练速度不一定线性提升。

为什么？通信成本上来了。

GPUDirect RDMA 不是魔法，不会让所有训练任务都线性扩展，但它能明显改善跨节点 GPU 通信效率，特别是 NCCL 这种集合通信场景。

AWS P4d 官方介绍里也提到，EFA 可使用 NVIDIA NCCL 扩展到数千个 GPU，而 GPUDirect RDMA 能在 P4d 实例之间实现低延迟 GPU 到 GPU 通信。[1]

所以你看，它不是给单机小游戏准备的，是给分布式训练和 HPC 这种“大家一起干活还要频繁对账”的业务准备的。

它解决不了什么？这点也得说清楚

很多人看到 GPUDirect RDMA，就觉得上了它训练一定快。这个不一定。

它解决的是跨节点 GPU 通信路径和网络通信效率问题，但下面这些问题它不背锅：

数据集读取慢，比如 S3 拉数据没做好缓存
CPU 数据预处理太慢
单卡显存不够导致频繁重算或 offload
训练代码写得不合理
Batch size、并行策略没调好
NCCL 参数配置错误
EFA 没装好、插件没加载
安全组、防火墙、placement group 没配好
容器里没挂设备或没装对应驱动

我见过一种情况，大家一开始怀疑是 GPUDirect 没生效，结果查半天，发现数据加载线程只有 2 个，GPU 一半时间都在等数据。这个就比较尴尬，像高速公路修好了，结果仓库还没发货。

所以 GPUDirect RDMA 是关键基础设施，但不是性能问题万能药。

AWS 上的 EFA 和 GPUDirect RDMA 是什么关系？

AWS 上不能简单套用“我有 RDMA 网卡，所以我就有 GPUDirect RDMA”这个逻辑。

AWS 的高性能网络主要看 EFA。EFA 是 EC2 的定制网络接口，适合大规模、低延迟、高吞吐的实例间通信。[2]

AWS 在 2020 年宣布 EFA 支持 NVIDIA GPUDirect RDMA，并且是在 P4d 实例上推出。[2]

P4d 是 A100 GPU 实例，支持 400Gbps 实例网络、EFA 和 GPUDirect RDMA，用于分布式 ML 训练和 HPC。[1]

官方资料里说得比较明确：P4d 支持 400Gbps EFA 和 GPUDirect RDMA 网络带宽，每台 p4d.24xlarge 有 96 vCPU、8 张 NVIDIA A100、1.1TB 内存、8TB NVMe 本地盘。[2]

这个信息很关键，因为 AWS GPU 实例很多，但不是所有 GPU 实例都适合多机训练，更不是所有都支持 GPUDirect RDMA。

AWS 目前哪些实例支持 GPUDirect RDMA？

这里我整理一个偏生产视角的表，注意 AWS 服务更新比较快，具体区域和可用区也会变化，最终还是以 AWS 官方实例文档和你实际创建时的能力为准。

明确适合 GPUDirect RDMA / EFA 分布式训练的 P 系列

实例类型	GPU	网络能力	GPUDirect RDMA 情况	典型场景
`p4d.24xlarge`	8 × NVIDIA A100 40GB	400Gbps EFA	官方明确支持	大模型训练、HPC
`p4de.24xlarge`	8 × NVIDIA A100 80GB	400Gbps EFA	通常用于同类分布式训练场景，支持 EFA/GPUDirect RDMA 生态	更大显存训练
`p5.48xlarge`	8 × NVIDIA H100 80GB	最高 3200Gbps EFA	面向大规模训练，支持 EFA/GPUDirect RDMA 生态	LLM 训练、生成式 AI
`p5e.48xlarge`	8 × NVIDIA H200	高速 EFA	面向更大显存和更高性能训练	LLM 训练、推理
`p5en.48xlarge`	8 × NVIDIA H200	更强网络规格，EFA	面向更高网络需求训练	超大规模训练

这里面，p4d.24xlarge 是资料最明确、最早支持 EFA + GPUDirect RDMA 的实例。AWS 官方文章明确写到 EFA 对 GPUDirect RDMA 的支持在 P4d 上推出，并说明 P4d 有 400Gbps EFA 和 GPUDirect RDMA 网络带宽。[2]

P4d 页面也强调，P4d UltraCluster 支持 400Gbps 实例联网、EFA 和 GPUDirect RDMA，有助于快速训练 ML 模型，并且 EFA 可配合 NCCL 扩展到数千个 GPU。[1]

P5 这一代是 H100，主要就是为大模型训练准备的，属于 P 系列里更高一档的训练实例。第三方资料也把 P 系列归为 ML、HPC、计算密集型场景，说明 P4/P5 这类实例支持 EFA 和 GPUDirect RDMA，用于低延迟分布式训练。[3]

G 系列要小心，不要看见 GPU 就以为支持

AWS 的 G 系列，比如 G4dn、G5、G6、G6e，更多是图形、推理、视频、轻量训练、虚拟桌面等场景。

它们当然也有 GPU，但定位和 P 系列不一样。

有资料把 P 系列和 G 系列做了区分：P 系列适合深度学习训练、科学模拟、大规模推理和高吞吐 AI 流水线，网络扩展侧重 UltraClusters、EFA 和 GPUDirect RDMA；G 系列更偏实时推理、媒体编码、游戏串流和虚拟桌面，不是为大规模分布式训练优化。[3]

我看到过有人拿 G6e 做 NCCL 测试，发现 GPUDirect RDMA 没启用，吞吐也上不去；GitHub 上也有人提到在 g6e 节点上使用 aws nccl plugin 时，GPUDirect RDMA not enabled。[4]

所以如果你的目标是多机多卡训练，别为了省钱直接拿 G 系列硬怼。它可能能跑，但跑得不一定舒服，最后省下来的机器钱可能被调优时间和训练时间吃回去了。

P3 / P3dn 呢？

P3 是 V100，P3dn 有更强网络，但它不是 AWS 最早明确支持 EFA + GPUDirect RDMA 的那一代。AWS 官方对比里也提到 P4d 相比 P3/P3dn，在性能、成本和网络能力上都有提升，并且 P4d 明确提供 EFA + GPUDirect RDMA。[2]

如果现在新建大规模训练集群，我一般不建议优先考虑 P3。除非是历史任务、预算、区域库存、软件兼容性等原因。

怎么判断自己有没有用上？别光看实例名

很多时候大家以为“我开了 P4d，所以一定跑上 GPUDirect RDMA 了”。这个不一定。

实例支持是一回事，系统里驱动、EFA、NCCL 插件、容器权限、环境变量都要对。

我平时会这么查。

看 GPU

nvidia-smi

输出里至少要看到 GPU 正常识别，驱动版本正常，CUDA 版本别太离谱。

再看拓扑：

nvidia-smi topo -m

这个主要看单机内 GPU 和网卡、CPU 的拓扑关系。跨节点性能差，有时候也跟 GPU 和 NIC 的 NUMA 亲和性有关。

看 EFA 设备

fi_info -p efa

如果没有输出，或者提示找不到 provider，那 EFA/libfabric 环境大概率没装好。

也可以看内核模块：

lsmod | grep efa

还有设备：

ls -l /dev/infiniband/

EFA 通常也会暴露相关 verbs 设备。

看 nvidia-peermem

GPUDirect RDMA 很多环境需要 nvidia-peermem 模块。

lsmod | grep nvidia_peermem

如果没加载，可以尝试：

sudo modprobe nvidia-peermem

但注意，不同 AMI、驱动版本、AWS DLAMI 里处理方式可能不同。不要在生产训练节点上随便升级驱动，容易把 CUDA、NCCL、框架版本搞炸。

看 NCCL 日志

跑训练或 nccl-tests 时加：

export NCCL_DEBUG=INFO
export FI_PROVIDER=efa

有时候还会设置：

export NCCL_PROTO=simple
export NCCL_ALGO=Ring,Tree
export NCCL_SOCKET_IFNAME=ens

AWS 环境里常见还有：

export LD_LIBRARY_PATH=/opt/amazon/efa/lib64:$LD_LIBRARY_PATH

具体以你镜像里的路径为准。

然后跑 nccl-tests：

./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8

多节点一般用 MPI 或 torchrun 拉起来，比如 MPI：

mpirun -np 16 -N 8 \
  -x NCCL_DEBUG=INFO \
  -x FI_PROVIDER=efa \
  -x LD_LIBRARY_PATH \
  ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1

这里 -np 16 -N 8 表示两台机器，每台 8 个进程。实际按节点数和 GPU 数调整。

如果 NCCL 日志里完全没看到 EFA、OFI、NET/OFI 之类的信息，反而走 socket，那基本就没跑对。

有时候日志会出现类似：

NCCL INFO NET/OFI Selected Provider is efa
NCCL INFO Using network AWS Libfabric

看到这种才比较踏实。

AWS 上搭环境，我一般会注意这些坑

1、实例必须在支持 EFA 的规格和区域

不是所有区域都有 P5，也不是所有可用区库存都够。大规模集群最好提前申请容量，或者用 Capacity Reservation。

2、要启用 EFA 网卡

创建实例或集群的时候，要配置 EFA interface。用 AWS ParallelCluster 的话，这些配置可以写在集群配置文件里。

如果你只是普通方式开 EC2，没挂 EFA，那后面怎么装 NCCL 都白搭。

3、Placement Group 尽量用 Cluster

分布式训练节点之间要低延迟，尽量放到 Cluster Placement Group。

跨 AZ 就别想了，训练通信肯定难受。

4、安全组要放通节点间流量

EFA/MPI/NCCL 需要节点之间互通。安全组最好允许同安全组内全流量互通。

很多奇怪的 NCCL hang 住，最后都是安全组或者路由问题。

5、驱动、CUDA、NCCL、aws-ofi-nccl 版本要匹配

这块真别乱配。

建议优先用 AWS Deep Learning AMI 或者官方容器。P4d 官方也提到可以通过 AWS Deep Learning AMI 快速部署深度学习环境，里面包含框架库和工具。[1]

自己从零装当然也可以，但版本坑不少。比如：

NVIDIA Driver 太旧
CUDA 和 PyTorch wheel 不匹配
NCCL 版本不支持当前插件
aws-ofi-nccl 没编进去
libfabric 版本不对
容器里没挂 /dev/infiniband

6、容器里要能看到 GPU 和 EFA

Docker 里要有 GPU：

docker run --gpus all ...

还要挂 EFA 相关设备，常见是：

--device=/dev/infiniband/uverbs0
--device=/dev/infiniband/rdma_cm

实际设备名看机器情况。

Kubernetes 里就要配 device plugin、EFA device plugin、NVIDIA device plugin，EKS 上还有一套自己的最佳实践。

一个简单例子：为什么 8 卡快，16 卡反而不明显？

我之前遇到过类似情况，单机 8 卡训练吞吐挺好，加到两台 16 卡，速度只提升了一点点。

一开始大家怀疑代码，后来查下来大概几个问题叠在一起：

两台机器没放在 cluster placement group
NCCL 没走 EFA，走了 TCP socket
容器里没有正确挂 EFA 设备
aws-ofi-nccl 插件没加载
安全组端口放得不完整，偶发 hang

最后修完以后，再跑 all_reduce_perf，跨节点带宽才上来。训练吞吐也正常不少。

这个事说明什么？GPUDirect RDMA 不是你买了实例就自动万事大吉，它是一条链路。链路上任何一环断了，最后都可能回退到普通网络路径。

GPUDirect RDMA 适合哪些业务？

我觉得这几类最明显：

大模型预训练

比如 LLM、多模态模型、推荐大模型。参数量大，GPU 数多，通信频繁。

多机多卡微调

微调规模比预训练小，但如果上几十张卡，通信也不能忽略。

HPC 科学计算

比如分子动力学、气象、地震、计算流体等。AWS 官方也提到 P4d 可用于自然语言处理、对象检测、地震数据分析、计算药物开发等场景。[2]

分布式推理

有些超大模型推理也需要跨 GPU、跨节点协作。虽然推理通信模式和训练不一样，但低延迟网络仍然重要。

不适合或者没必要的场景

不是所有 GPU 业务都要 GPUDirect RDMA。

如果你只是：

单机单卡推理
单机多卡小模型
视频转码
图形渲染
轻量 batch inference
偶尔跑个 notebook

那 GPUDirect RDMA 可能没啥明显收益，甚至没必要为了它上 P 系列。G5、G6 这类可能更划算。

选型别一上来就追最高配。云上 GPU 很贵，P5 这种烧起来账单很刺激，晚上睡觉都能梦见 Cost Explorer。

最后给一个选型建议

如果你现在在 AWS 上做 GPU 训练，我建议这样看：

小规模实验：

单机 G5 / G6 / P4d，看模型和预算

正式多机训练：

优先 P4d / P4de / P5 / P5e / P5en

需要 A100 生态成熟、成本相对可控：

p4d.24xlarge 或 p4de.24xlarge

追求 H100/H200，大模型训练：

p5.48xlarge / p5e.48xlarge / p5en.48xlarge

不要只看 GPU 型号，还要看：

跨节点网络
EFA
GPUDirect RDMA
NCCL 支持
区域库存
容量预留
训练框架兼容性

很多时候，多机训练不是“GPU 越多越快”，而是“GPU、网络、存储、框架、参数一起调对才快”。

总结一下

GPUDirect RDMA 其实没那么玄乎。

它解决的核心问题就是：跨机器 GPU 通信时，减少 CPU 内存中转，让网卡更直接地访问 GPU 显存，从而降低延迟、减少拷贝、提升多机多卡训练效率。

在 AWS 上，重点看 EFA。P4d 是官方明确提到支持 EFA + GPUDirect RDMA 的典型实例，P4d 支持 400Gbps 实例网络、EFA 和 GPUDirect RDMA，并可配合 NCCL 扩展到数千个 GPU。1

现在做大规模训练，P4d、P4de、P5、P5e、P5en 这类 P 系列才是主力选择。G 系列虽然也有 GPU，但定位更多是推理、图形、媒体等场景，不要默认它适合 GPUDirect RDMA 分布式训练。3

落地时别只看实例名，记得检查 EFA、libfabric、NCCL、aws-ofi-nccl、nvidia-peermem、容器设备、安全组、placement group。性能问题最后往往不是一个点，而是一串小坑串起来的。

如果这篇对你有点帮助，可以转给正在被 NCCL、EFA、GPU 利用率折磨的同事看看。说不定他少熬一个晚上，你多收获一杯奶茶。

欢迎关注 @运维躬行录，后面我会继续写一些云上 GPU 集群、EKS 训练集群、NCCL 调优、AWS ParallelCluster 这类偏实战的内容。

公众号：耕云躬行录
个人博客：躬行笔记