图解 RDMA：从内存搬运到 AI 集群网络

一台服务器要把数据交给另一台服务器，网线够快就行了吗？

在高速网络里，CPU 处理协议、数据在缓冲区之间复制、线程等待调度，也可能成为开销。AI 训练、分布式存储和高性能计算经常需要反复交换大量数据，因此既在意网络带宽，也在意“每搬一次数据要付出多少代价”。

RDMA（Remote Direct Memory Access，远程直接内存访问）让支持 RDMA 的网卡，在预先建立的权限和通信关系下，把数据直接放入对端指定的内存缓冲区，或从中读出数据，从而减少主机软件参与数据搬运的开销。这里的“直接”有严格边界：目标内存需要获得授权，网络传输与内存访问仍真实发生。定义与内存保护语义：IETF RFC 5040

1. 先看数据路径：RDMA 到底省了什么？

把服务器想成一座仓库，应用缓冲区是货架，CPU 是工作人员，网卡是装卸设备。

常见的 Socket 通信路径里，应用把数据交给内核，内核处理网络协议，再由网卡发出；接收端完成相应处理后，应用取得数据。这里可能发生用户态与内核态之间的缓冲区复制，以及协议处理、调度等开销。

RDMA 则更像是提前安排好货架位置和通行权限，让装卸设备按照任务单搬运。应用提交操作后，网卡承担更多传输与数据放置工作。

图 1：比较的是常见软件路径和已准备好资源的 RDMA 数据路径，不是对所有 TCP 实现的性能判断。普通网卡也会使用 DMA；RDMA 增加了远端操作、权限检查和直接数据放置等能力。

人们常用三个词描述 RDMA 的优势：

• 减少拷贝：数据可以直接进入注册缓冲区，减少中间缓冲区的 CPU 复制。
• 内核旁路：在常见用户态 RDMA 实现中，稳定运行的数据路径可以绕过传统内核网络协议栈。
• 硬件卸载：网卡处理较多传输协议工作，使主机 CPU 有机会把资源用于业务计算。

这些收益来自一整套软硬件协作。内存注册、资源管理和异常处理仍可能涉及内核；提交任务、轮询完成队列、序列化数据和运行应用仍然需要计算资源。零拷贝也不等于零数据移动，轮询还可能持续占用 CPU。TCP 同样存在零拷贝和卸载优化，比较时要明确具体实现。RDMA 数据路径背景：DCQCN 论文

2. “直接访问远程内存”为什么不会乱写？

RDMA 不会因为两台机器网络互通，就允许其中一台随意读写另一台的内存。

以常见 verbs 接口为例，接收方先把一段内存注册成MR（Memory Region，内存区域），声明范围和读写权限。通信双方还要建立相应的通信资源，并以受控方式交换操作所需的信息。

对远端 Read／Write，发起方通常需要知道远端地址和rkey（远端访问键）。网卡结合地址范围、访问键和权限检查操作能否执行。注册还会建立设备访问内存所需的映射；常见路径涉及固定内存页，也存在按需分页等机制。

可以把它理解为：“允许指定的通信对象，在规定的时间和范围里使用这些货架。”授权方可以回收或重新设置相关资源。

rkey 是访问检查的一部分，不是数据加密，也不能单独替代身份认证、租户隔离和安全的密钥交换。应用还必须管理缓冲区的有效期，防止一边重新使用内存，另一边仍在访问旧地址。内存注册与访问权限：rdma-coreibv_reg_mr

3. 一次 RDMA 操作是怎样完成的？

阅读 RDMA 文档时，先认清四个常见缩写：

下面用一次普通RDMA Write串起来：

图 2：省略了协议确认、连接状态转换等细节。普通 Write 不需要远端应用为每一笔写操作投递 Receive。

双方先准备资源，A 再把“从哪里取、写到哪里、写多少”的请求提交给网卡。随后由两端网卡完成数据传输和放置，A 根据完成信息管理后续工作。队列、工作请求与完成队列：NVIDIA RDMA 编程指南

有一个区别必须记住：本地操作完成，不等于远端业务已经处理完数据。普通 Write 本身通常不会让远端应用收到一个“请处理这笔业务”的接收完成事件。通知方式、可见性和并发同步，需要由应用或通信库另外设计；也不是每个成功的发送请求都必须产生独立完成事件。请求类型与完成语义：rdma-coreibv_post_send

4. Send、Write、Read，差别在哪里？

名字都像“传数据”，但两端应用的分工不同。

图 3：Read 的请求从 A 发向 B，读回的数据从 B 流向 A；图中的内存都已获得相应授权。

Send／Receive 常被称为双边操作，Read／Write 常被称为单边操作。这里的“单边”描述的是操作发起和远端 CPU 参与方式，并不表示另一端没有做过准备。

还有原子操作，以及 Write with Immediate 等变体。后者带有额外通知语义，不能直接套用“普通 Write 无需接收请求”的说法。可用操作也取决于传输模式：常见 RC 支持 Read／Write，而 UD 不能简单按 RC 使用。操作与模式支持：NVIDIA RDMA 编程指南

例如，一个缓存服务可以通过 Send／Receive 收到“查询某个键”的请求，再由 CPU 查询；也可以设计成客户端通过 Read 读取事先公开的数据结构。后一种方式减少了某些服务端处理，但把地址管理、版本和一致性问题带给了系统设计者。

5. RDMA、InfiniBand、RoCE、iWARP 是什么关系？

RDMA 是一种通信能力和操作语义；下面可以使用不同的网络技术。理解这一层关系，才能避免把“支持 RDMA”误解成“必须使用某一种交换机”。

图 4：用于解释承载关系，省略部分报头、校验和物理层细节；iWARP 列展示常见的 TCP 承载。

RoCEv2 中的 UDP 主要提供封装与网络识别功能。使用可靠连接 RC 时，确认、顺序和重传等可靠性由 RDMA 传输机制提供，不能看到 UDP 就断定应用必须接受不可靠交付。RoCE 封装：NVIDIA 文档 · iWARP 的 TCP 承载：IETF RFC 5044

能够路由，也不代表跨任意广域网都能获得数据中心内相同的性能。往返时延、拥塞、丢包、设备能力和配置仍然影响结果。

6. 为什么 RoCE 总是与“无损网络”一起出现？

多台服务器同时向一台服务器发送数据，很容易出现“入口总速率超过出口速率”。包会先进入交换机缓冲区，缓冲区装满后就可能被丢弃。

许多经典 RoCE 实现对丢包很敏感，丢包后的恢复会明显影响吞吐与尾延迟。因此，传统部署常通过PFC（Priority-based Flow Control，基于优先级的流量控制），尽量避免某些流量因缓冲区溢出而丢包。

PFC 的动作是：下游向相邻上游发出暂停要求，让其暂时停止发送某个优先级的流量，给缓冲区留出空间。

需要区分三个概念：

• 可靠传输：传输层发现丢包后，通过确认与重传等机制恢复。
• 减少拥塞丢包：网络通过缓冲管理和流量控制，降低溢出丢包的机会。
• 绝对不丢包：现实中还会有链路误码、设备故障等原因，PFC 无法消除所有丢包。

所以，“可靠”不等于“不需要重传”，“无损配置”也不意味着所有故障都会消失。微软 2016 年的部署论文就记录了启用 PFC 后仍需处理的丢包与恢复问题。SIGCOMM 2016 论文

还应避免把历史经验写成永恒前提：RDMA 本身并不普遍要求 PFC。不同承载协议、网卡与传输设计，对网络的要求不同。IRN 等研究也专门探讨了如何通过改进丢包恢复等机制，让 RDMA 在不依赖 PFC 的情况下有效运行。Revisiting Network Support for RDMA，SIGCOMM 2018

7. ECN 与 PFC：为什么需要两套机制？

如果道路越来越拥挤，更合理的办法是让源头逐渐减少进入的车辆。PFC 则像某一段道路快装不下时，临时让相邻上游停一下。

ECN（Explicit Congestion Notification，显式拥塞通知）允许网络给数据包加上拥塞标记。在采用DCQCN的典型 RoCEv2 网络里，接收网卡看到标记后向发送端发出CNP（Congestion Notification Packet，拥塞通知包）；发送端再依据算法调整速率。

图 5：ECN 标记随数据包到达接收端，CNP 再反馈给发送端；PFC 帧作用于相邻链路。如果拥塞继续，反压可能逐跳向上游扩散，并非同一张 PFC 帧被全网路由。

二者可以配合：通过拥塞控制维持稳定发送，把 PFC 用作缓冲保护。PFC 本身不承担端到端公平分配带宽的全部职责。DCQCN 原始论文

工程上通常希望 ECN 在缓冲耗尽之前发挥作用，但不能只写一句“把 ECN 阈值设置得更小”。具体调优还与链路速度、往返时延、共享缓冲、端口余量和突发规模有关；不同计量位置的阈值也未必能直接比较。微软关于 ECN/PFC 阈值的技术说明

8. SIGCOMM 2016 那篇论文，给了我们什么提醒？

《RDMA over Commodity Ethernet at Scale》，重点是把 RoCEv2 带入大规模数据中心之后，如何让它长期稳定运行。

论文记录了几类容易被小规模带宽测试遗漏的问题：

其中，PFC 针对的是优先级，并不会只暂停“真正导致问题的那一条业务流”。这也是故障可能扩大的原因之一。

论文还强调监控、管理和逐步上线。对今天的读者，更有用的是这些问题机制和排查思路；文中网卡、速率、规模与故障细节属于当时的环境，应和现网能力分开判断。论文原文

9. AI 集群为什么关心 RDMA？

多 GPU 训练除了计算，还要交换梯度、激活或其他张量。以 All-Reduce 为例，各参与者对输入执行求和等归约，并获得归约结果。这个过程由通信库组织，可能产生大量跨服务器通信。NCCL 集合通信说明

因此，可以从三个层次理解：

• RDMA提供数据传输与远端内存操作能力。
• GPUDirect RDMA在支持的硬件、驱动和拓扑下，让网卡直接访问 GPU 显存，减少主机内存中转。
• NCCL 等通信库组织 All-Reduce、All-Gather 等集合通信，并选择可用的数据路径。

图 6：GPUDirect RDMA 缩短 GPU 与网卡之间的数据路径；数据仍经过 PCIe、网卡和网络。主机侧的准备、控制和同步并不会因为画出了直连箭头就自动消失。

GPUDirect RDMA 的收益受 PCIe 拓扑、设备与驱动支持等条件影响。它也不会自动完成 GPU 内存同步，更不会把多台服务器的显存变成应用可任意访问、自动一致的共享内存。NVIDIA GPUDirect RDMA 文档

把链路换成 RDMA 后，如果 GPU 仍在等待慢节点、负载分配不均或拥塞，训练也可能继续停顿。网络吞吐测试的提升，最终要通过训练迭代时间或业务完成时间来确认。

10. 判断 RDMA 有没有价值，应看哪些指标？

先明确业务问题，再评价网络技术。下面是一组便于入门的观察方向，具体指标与测试方式需要结合系统设计。

还有一个很朴素的物理约束：RDMA 不能突破链路带宽上限。

假设要在一条 100 Gb/s 链路上单向传送 100 MB 数据，MB 按十进制计算，即使完全不考虑报头和其他开销，串行化时间也至少约为：

100 MB × 8 ÷ 100 Gb/s = 0.008 s = 8 ms

这是用于理解带宽下限的算例，不是 RDMA 性能测试结果。真实耗时还包括协议、排队、软件、PCIe、内存访问等因素；流水线和重叠执行又会改变它们的组合方式。

RDMA 的价值在于减少额外成本，让系统更有效地接近资源能力，并为应用提供不同的通信方式。

11. 常见疑问速查

换一块 RDMA 网卡，原来的应用就会自动变快吗？
不一定。应用、框架或存储协议需要实际使用 RDMA 路径；硬件支持只是条件之一。现有 Socket 应用不会仅因安装了新网卡，就自动获得单边 Read／Write 语义。

RDMA 是否完全不经过 CPU？
网卡可以承担大量数据搬运和协议工作，但 CPU 或其他处理器仍负责资源准备、操作控制、完成处理及业务计算，具体参与程度取决于实现。

普通 RDMA Write 完成，是否代表数据已经保存到磁盘？
不是。网络与内存操作完成不等于持久化，持久性需要存储协议和设备进一步保证。

有了 PFC，是否就没有拥塞了？
没有。暂停可以推迟缓冲区溢出，也可能把等待传播出去；过量流量仍需要拥塞控制、容量规划等措施处理。

RoCEv2 使用 UDP，为什么可以可靠传输？
UDP 是封装的一部分，常见 RC 模式的可靠性交给 RDMA 传输机制实现。其他模式不能一概按 RC 理解。

RDMA 能代替分布式算法和业务协议吗？
不能。数据放到了哪里、何时可以使用、是否读到同一版本、故障后如何恢复，仍需要系统设计。

延伸阅读

建议先理解图 1、图 3 和图 5，再读网络论文。

1. NVIDIA RDMA-aware Networks Programming Guide：查阅 QP、CQ、通信操作与传输模式。
2. rdma-core：ibv_reg_mr与ibv_post_send：了解实际接口中的内存权限与工作请求。
3. Congestion Control for Large-Scale RDMA Deployments，SIGCOMM 2015：理解 DCQCN、ECN 与 PFC 的关系。
4. RDMA over Commodity Ethernet at Scale，SIGCOMM 2016：了解规模化部署的故障机制与运维经验。
5. Revisiting Network Support for RDMA，SIGCOMM 2018：理解“RDMA 是否必须依赖 PFC”这一问题。
6. NVIDIA GPUDirect RDMA 与 NCCL 集合通信：连接 RDMA 与 GPU 通信场景。