AI时代的＂数据高速公路＂:一文彻底读懂RDMA技术

一、传统 TCP/IP 的困境：传 100GB 文件，为什么会把 CPU "累垮"？

想象你要把一份 100GB 的大文件从服务器 A 传到服务器 B。在我们熟悉的传统 TCP/IP 网络里，这份数据并不是 "直达" 目的地，而是要在服务器内部经历多轮中转，大量消耗 CPU 算力——这也是高速网络下，算力被网络拖慢的核心原因。

1.1 发送端：数据从应用到网线的 4 步旅程

第一步：用户态 → 内核态 【CPU 执行内存拷贝】

应用程序调用send() 发起传输后，CPU 会把纯应用数据（文件内容）从用户空间内存，拷贝到内核空间的 Socket 发送缓冲区。

🔍 常见误区澄清：不会按小包大小反复拷贝

很多人以为 100GB 的文件要拆成上千万个 1460 字节的 MSS 小包，就要拷贝上千万次，实际上完全不会。

数据拷贝的粒度和 TCP 单包大小（MSS）无关，只和 Socket 发送缓冲区的剩余空间有关：应用会分多次调用send()，每次把几 KB 到几 MB 的批量数据整段拷贝进内核，绝不会提前拆成 1460 字节的小包逐个复制。

简单说：拷贝次数只和系统调用次数有关，和报文拆分数量完全是两回事。

这是发送端唯一一次 CPU 亲自搬运全量数据的步骤。

第二步：内核协议栈封装处理 【CPU 执行逻辑，无额外全量数据拷贝】

TCP/IP 协议栈为数据 "打包"：依次添加 TCP 头、IP 头、以太网头，计算校验和，处理路由与分段逻辑。

这里有个核心优化：内核不会把应用数据再完整复制一遍，而是通过指针操作缓冲区预留的头部空间，只填充几十字节的协议字段，数据载荷本身全程共享同一块内存。

针对分段工作，分两种场景：

• 开启 TSO（绝大多数服务器默认开启）：TCP 分段卸载是现代网卡的标配功能。内核直接把大段数据交给网卡，"拆成 MSS 大小小包" 的工作完全由网卡硬件自主完成，CPU 只需要处理 1 次大报文的协议头。

• 未开启 TSO：Linux 内核会通过 GSO（通用分段卸载） 做软件层面的分段。全程也只会复制协议头，通过指针共享同一份应用数据内存，不会把全量数据再复制一遍——仅仅增加少量 CPU 逻辑开销，不会产生额外的全量数据拷贝。

第三步：内核内存 → 网卡硬件 【DMA 硬件自主搬运，CPU 不碰数据】

驱动向网卡提交发送任务后，网卡自带的 DMA（直接内存访问）引擎会主动 "上门取件"：直接从内核内存中读取封装好的完整报文，写入网卡自身的硬件发送缓冲区。

整个过程 CPU 全程不参与数据搬运，只需要在最开始写一个寄存器通知网卡 "有任务"，剩下的全由硬件自主完成。

第四步：网络传输

报文通过网卡转换成光/电信号，经过交换机、路由器转发，最终到达接收端服务器。

1.2 接收端：对称的反向流程

接收端的流程和发送端完全对应，同样只有 1 次 CPU 全量数据拷贝：

1. 网卡 DMA 引擎直接把收到的报文写入内核接收缓冲区（硬件搬运，无 CPU 参与）；

2. 内核协议栈逐层解析协议头，处理丢包重传、拥塞控制、报文聚合（GRO/LRO）等逻辑；

3. CPU 把纯应用数据从内核缓冲区，批量拷贝到用户空间的应用内存中（接收端唯一一次 CPU 全量数据拷贝）。

总结

发送端 1 次 CPU 拷贝，接收端 1 次 CPU 拷贝，端到端共 2 次 CPU 参与的内存拷贝。但别小看这 2 次——每次拷贝都伴随着内核态/用户态的上下文切换，加上协议栈封装解析、中断响应、校验和计算、拥塞控制、乱序重组等一系列 CPU 密集型操作，当网络带宽达到 100Gbps 甚至 400Gbps 时，CPU 已经被网络中断"淹没"，根本无暇处理真正的计算任务。

上图清晰展示了传统模式与RDMA模式的本质区别：传统模式数据要"层层过关"，经历用户空间→内核→网卡的多级缓冲；RDMA模式则直接"抄近道"，从应用内存直达网卡。

更直观的数据对比：

注：传统TCP/IP在1500B大包场景下也能接近线速（~9 Gbps），但会消耗大量CPU；而在64B小包等极端场景下，受协议栈中断处理瓶颈影响，吞吐可能骤降至1–3 Gbps。RDMA则无论包大小，均能以极低CPU占用稳定跑满带宽。

在 AI 大模型的分布式训练场景下，每轮 AllReduce 梯度同步都需要上万张 GPU 严格对齐，训练效率符合典型的木桶效应 —— 任何一个节点的延迟抖动，都会拖慢整个集群的进度，因此网络不仅要低延迟，更要延迟高度稳定。

传统 TCP/IP 恰恰在稳定性上存在先天短板，长尾延迟是其核心痛点：标准内核默认 TCP 的最小重传超时（RTO）为 200ms，即便数据中心内通过 DC-TCP 等定制协议调优，软件协议栈的中断调度、内核锁竞争、重传状态机处理，依然会带来毫秒级的延迟波动，P99 延迟往往是平均值的数倍甚至数十倍。

而 RDMA 将完整的可靠传输逻辑全部卸载到网卡硬件中实现：接收端检测到丢包后，硬件立即回传 NAK 否定确认，发送端收到后立刻重传对应报文，全程无需 CPU 和内核介入，重传开销仅微秒级；仅在极端的 ACK 丢失场景下才会触发超时兜底，阈值也仅几十到几百微秒，远小于 TCP 量级。

最终体现在业务上，就是 RDMA 的 P99/P999 延迟几乎与平均延迟持平，几乎没有长尾抖动，能稳定支撑万卡级集群的高效同步，避免大量 GPU 算力陷入空等。

二、从DMA到RDMA：一场"绕过CPU"的技术革命

要理解RDMA，我们先从大家更熟悉的DMA（Direct Memory Access，直接内存访问）说起。

2.1 DMA：芯片内部的"直达通道"

在计算机内部，CPU是"大管家"，负责调度一切。但硬盘读写数据时，如果让CPU亲自把数据从硬盘搬到内存，CPU就没法干别的了。于是DMA技术诞生了：硬盘控制器可以直接读写内存，完全不需要CPU参与。CPU只需要发一个指令："把硬盘第1000块的数据搬到内存地址0x12345678"，然后就可以去忙别的了。

2.2 RDMA：把DMA的能力扩展到网络上

RDMA（Remote Direct Memory Access，远程直接内存访问）的核心理念：一台服务器的网卡，可以直接读写另一台服务器的内存，就像访问本地内存一样。

这套技术最早在InfiniBand中落地成熟，但 InfiniBand 需要专用 HCA 网卡和专用 IB 交换机，成本高昂，很难大规模普及。

为了让 RDMA 能在通用以太网场景落地，业界走出了两条技术路线：

• 2002-2007 年：IETF 制定了iWARP，基于传统 TCP/IP 实现 RDMA，主打对现有 IP 网络的最大兼容性。
• 2010 年：InfiniBand 的主导组织 IBTA 推出了RoCE，把成熟的 IB 传输协议封装到以太网帧中传输，主打硬件卸载的性能优势。

但起步更早的 iWARP 最终逐渐边缘化，核心问题恰恰出在它的 TCP 底座上：TCP 协议的状态机、拥塞控制、重传机制逻辑复杂，完整硬件卸载的芯片实现难度大、成本高，导致 iWARP 的性能上限和 CPU 卸载效果始终不及 RoCE；再加上生态厂商支持有限，没能成为主流。

而 RoCE 在后续演进中补齐了扩展性短板：2014 年推出的RoCE v2版本改用 UDP/IP 封装，既保留了 IB 原生协议轻量、易硬件卸载的优势，又支持三层 IP 路由，彻底适配大规模组网。搭配数据中心无损以太网技术（PFC 优先级流控 + ECN 显式拥塞通知），RoCE 既能复用标准以太网基础设施、成本远低于专用 IB 网络，性能又能接近 InfiniBand 水平，最终逆袭成为以太网 RDMA 的事实标准。

三、RDMA的"三大杀手锏"：零拷贝、内核旁路、CPU卸载

RDMA之所以被称为"高性能网络通信的王者"，靠的是三大核心技术特性：

3.1 零拷贝（Zero Copy）：数据不再"搬来搬去"

传统网络中，数据在内存里被"搬"了2次。RDMA通过内存注册（Memory Registration）机制，让网卡直接访问应用程序预先分配的内存区域。数据从发送方的应用缓冲区直接"飞"到接收方的应用缓冲区，不需要经过内核空间的任何复制。

这就像快递从发货人手里直接交到收货人手里，不再经过任何中转站。

3.2 内核旁路（Kernel Bypass）：不走"正门"，走"专用通道"

传统网络通信中，应用程序必须通过系统调用（如send()、recv()）陷入内核态，让操作系统帮忙处理网络协议。这个过程涉及上下文切换——CPU要从用户态切换到内核态，处理完再切回来，开销巨大。

RDMA采用"双通道"设计：

• 控制通路：需要内核参与（用户态应用 → 用户态驱动 → Linux内核 → 内核驱动 → RDMA网卡），用于创建和管理通信资源。这部分操作虽然耗时较长，但执行次数很少。

• 数据通路：完全不需要内核参与（用户态应用 → 用户态驱动 → RDMA网卡），用于传输业务数据。应用程序通过专门的 Verbs API 直接在用户态操作网卡，避免了系统调用和上下文切换。

3.3 CPU卸载（CPU Offload）：把网络传输的活儿全交给硬件，彻底释放算力

在传统 TCP/IP 网络中，从数据封装解析、校验和计算，到丢包重传、拥塞控制，整套传输协议的核心逻辑都要靠 CPU 通过内核软件栈处理。哪怕现在主流网卡已经支持部分基础特性卸载，核心的状态调度、连接管理依然要占用 CPU 算力 —— 带宽越高，CPU 被网络消耗的资源就越多。

而 RDMA 直接把完整的传输层协议逻辑全部卸载到了网卡硬件中，整套收发、校验、重传、流控都由硬件芯片自主完成，彻底把 CPU 从 “网络搬运工” 的角色里解放了出来。

很多人听过的“远端 CPU 完全感知不到数据传输”，其实有明确的前提：

• 建连准备阶段（控制面）：需要两端 CPU 配合，完成内存注册、QP 连接建立、远程密钥（R_Key）交换等工作，相当于提前 “打通专用通道、约定好访问权限”，这一步 CPU 必须参与。
• 正式传输阶段（数据面）：通道建好之后，尤其是 RDMA WRITE/READ 这类内存语义操作，远端 CPU 就全程 “撒手不管” 了。不会触发网络中断，不会带来内核态切换开销，也不会因为数据搬运污染 CPU 缓存，算力可以 100% 留给业务计算。如果应用需要知道 “数据已经送达”，再通过 SEND/RECV 通道或者轮询内存标记的方式轻量通知即可。

实测数据显示，在 40Gbps 满流量场景下，RDMA 的单核 CPU 占用率仅 5% 左右，而传统 TCP/IP 协议栈的 CPU 占用率接近 50%，算力释放效果差距显著。

这张图展示了RDMA IB的整体工作原理：绿色曲线代表RDMA的"直达通道"，数据从用户空间直接到网卡；而传统TCP/IP的紫色曲线则要经历层层缓冲、中断和上下文切换（上图展示了 RDMA IB 的工作原理及网络拓扑。图中 "Span" 为 "Spine"（脊层）的变体写法，即业界标准的 Leaf-Spine（叶脊）架构）。

3.4 RDMA 的代价：光鲜背后的工程挑战

RDMA 的性能优势毋庸置疑，但在实际生产环境中落地，工程师们需要面对一系列"甜蜜的烦恼"。

内存注册的开销

RDMA 要求应用程序将要通信的内存预先注册为 MR（Memory Region），网卡需要建立虚拟地址到物理地址的映射表（MTT）。注册/解注册操作本身需要陷入内核，涉及页表遍历和 DMA 映射，延迟在微秒到毫秒级。频繁注册小内存块会成为性能瓶颈，因此生产实践中通常采用内存池化策略：预先注册一大块内存，应用从中分配使用。

QP 数量限制

每个 RDMA 连接需要一个 QP（Queue Pair），而 QP 的上下文信息（QPC）存储在网卡片上缓存中。当集群规模达到数千节点时，QP 总数可能耗尽网卡资源。为此，RDMA 引入了 XRC（Extended Reliable Connection） 和 DC（Dynamically Connected Transport） 等扩展机制，让一个 QP 能与多个远端通信，但这也增加了编程复杂度。

无损网络的运维复杂度

RoCE 依赖 PFC + ECN 构建无损网络，这在实际运维中常常"把人逼疯"：

• PFC 死锁：多级交换机之间 PFC 帧的级联暂停可能形成环路死锁，导致网络完全僵死

• ECN 阈值调优：阈值设得太敏感，网络频繁降速；设得太迟钝，拥塞已经爆发

• 参数耦合：PFC 水线、ECN 阈值、DCQCN 参数之间相互影响，调优缺乏统一方法论

这些问题的排查往往需要深入理解交换机芯片行为和流量模式，对运维团队要求极高。

编程模型的门槛

传统 Socket 编程（send() / recv()）简单直观，而 RDMA 的 Verbs API 要求开发者理解 QP、WQE、CQ、MR、R_Key 等底层概念，手动管理内存注册和完成事件。调试门槛远高于传统网络：RDMA 问题涉及网卡硬件、驱动、无损网络、业务代码多层链路，偶发异常往往没有明确的错误码提示，可能表现为连接无响应、性能骤降，根因定位难度大。

一句话总结：RDMA 不是"开箱即用"的银弹，它是用开发复杂度和运维复杂度换性能。在决定是否引入 RDMA 时，团队需要评估：业务对延迟的敏感程度，是否值得承担这些工程代价。

四、RDMA 的"工作语言"：三种操作类型

RDMA 定义了多种操作类型，业内通常分为双边操作（Two-sided）和单边操作（One-sided）两大类。理解它们的关键，是搞清楚"接收方要不要提前准备"。

4.1 双边操作：SEND / RECV —— "快递签收模式"

场景：你寄快递，朋友必须在家签收

SEND/RECV 是 RDMA 最基础的操作。为什么叫"双边"？因为接收方必须提前"告诉网卡放哪里"——向网卡提交 RECV WQE，指定接收缓冲区地址。如果快递到了没人签收（没有匹配的 RECV WQE），网卡会报错：RNR（Receiver Not Ready）。

完整流程：

1. 接收方 APP → 提交 RECV WQE（"告诉网卡：快递放门口第3个柜子"）2. 发送方 APP → 提交 SEND WQE（"告诉网卡：把这箱货发出去"）3. 发送方网卡 → 取货、打包、发走4. 接收方网卡 → 收到快递，按 RECV WQE 指定地址放入柜子5. 双方网卡 → 各自在 CQ 里放完成通知6. 双方 APP → 轮询 CQ 得知"搞定了"

核心特点：

• 接收方必须提前准备（提交 RECV WQE）

• 数据放哪里，由接收方指定

• 适合控制消息、通知、密钥交换——接收方明确知道自己要收什么

🔍 关键澄清：SEND/RECV 的"双边"不是指"远端 CPU 参与数据处理"。无论 SEND 还是 READ/WRITE，远端 CPU 在数据面上都不做任何动作，都是通过轮询 CQ 异步感知的。真正的区别只有一点——SEND/RECV 要求接收方预先提交 WQE，READ/WRITE 不需要。

4.2 单边操作：READ / WRITE —— "有钥匙直接进门"

场景：你有朋友家的钥匙，直接开门放进去/拿出来

READ/WRITE 是 RDMA 最"神奇"的操作。为什么叫"单边"？因为接收方什么都不用做——提前把钥匙（R_Key）给你之后，你随时可以直接读写他的内存，他完全无感知。

WRITE（写远端内存）：

1. 双方前期通过 SEND/RECV 交换 R_Key（"这是我家钥匙"）2. 本端 APP → 提交 WRITE WQE（"把这箱货放到他家客厅，地址是 0x1234，钥匙是 R_Key_X"）3. 本端网卡 → 取货、打包、发送4. 远端网卡 → 收到后，直接用 R_Key 验证权限，把数据写入指定内存地址5. 远端网卡 → 回复 ACK6. 本端网卡 → 在 CQ 放完成通知

READ（读远端内存）： 流程相反，本端主动从远端"拉"数据。

核心特点：

• 接收方什么都不用提前做（除了前期交换 R_Key）

• 数据放哪里，由发送方直接指定

• 远端 CPU 完全不参与、不感知

• 适合大规模数据搬运——性能最强

4.3 三种操作怎么配合？—— 分工不同，不是谁更好

一句话总结：SEND/RECV 是"信使"，负责前期沟通和轻量通知；READ/WRITE 是"搬运工"，负责大规模数据搬运。两者在数据面上远端 CPU 都不参与，区别只在于"谁指定接收地址"。

4.4 原子操作：分布式系统的"锁机制"

除了 SEND/RECV/READ/WRITE，RDMA 还支持原子操作，允许本节点直接对远程内存执行原子操作，无需远程 CPU 参与：

• Compare and Swap（CAS）：如果远程内存值等于给定值，则替换为新值。用于实现分布式锁。

• Fetch and Add：获取远程内存当前值并加上给定值。用于计数器、队列索引。

这些原子操作为构建高性能分布式系统提供了底层基础设施。

五、RDMA的"基础设施"：核心概念解析

要深入理解RDMA，必须了解它的几个核心"零件"：

5.1 QP（Queue Pair，队列对）

QP是RDMA通信的基本单元。每个QP由两部分组成：

• SQ（Send Queue，发送队列）：存放SEND、WRITE、READ等发送操作请求

• RQ（Receive Queue，接收队列）：存放RECV操作请求

每张网卡内的 QP 都有唯一的编号（QPN），用于标识通信端点。一个进程可以申请和使用多个 QP。

5.2 WQE（Work Queue Entry，工作队列项）

WQE是工作队列中的具体操作单元，描述了每一个RDMA操作的详细参数：

• 操作类型（WRITE、READ、SEND、RECV等）

• 本地内存地址和数据长度

• 远程内存地址和R_Key（对于READ/WRITE）

• 例如："把位于地址0x12345678、长度为12字节的数据，发送到远程节点B的QP2"

APP将WQE提交到工作队列后，RDMA网卡会异步地处理这些请求，并将完成结果写入CQ。

5.3 CQ（Completion Queue，完成队列）

CQ用于存放操作完成的通知（CQE）。APP通过轮询或事件通知的方式从CQ中获取操作完成状态。这种异步设计让APP可以在提交一批WQE后，继续执行其他计算任务，等网卡处理完再回来"收结果"。

5.4 MR（Memory Region，内存区域）与密钥

RDMA要求应用程序将要用于通信的内存注册为MR。注册后，系统会返回：

• L_Key（本地密钥）：用于本地网卡访问该内存

• R_Key（远程密钥）：用于远程节点访问该内存

只有持有正确R_Key的节点，才能对远程内存执行READ/WRITE操作。这是RDMA的安全机制。

5.5 连接类型：RC、UC、UD、XRC、DC

• RC（Reliable Connected）：可靠连接，一对一通信，有ACK确认和重传机制，最常用。

• UC（Unreliable Connected）：不可靠连接，无ACK，性能更高但可能丢包。

• UD（Unreliable Datagram）：不可靠数据报，一对多通信，无连接。

• XRC（Extended Reliable Connection）：扩展可靠连接，一个发送QP可与远程节点的所有进程通信，大幅减少大规模集群中的QP数量。

• DC（Dynamically Connected，动态连接传输）：按需建立、释放连接，通过连接复用大幅减少大规模集群下的 QP 资源占用，适合超大规模节点的通信场景。

六、三大技术路线：InfiniBand vs RoCE vs iWARP

RDMA是一种"概念"，目前有三种主流实现方案：

6.1 InfiniBand：性能之王

InfiniBand从设计之初就考虑了RDMA，从硬件级别保证可靠传输，提供最高的带宽和最低的延迟。NVIDIA的DGX超级计算机、全球Top500超算大多采用InfiniBand。

但缺点是成本高昂，需要专用的IB网卡（HCA）和IB交换机，无法利用现有以太网基础设施。

6.2 RoCE：RDMA的"大众化"之路

RoCE（RDMA over Converged Ethernet） 是目前最主流的RDMA实现方式，让RDMA"飞入寻常百姓家"。

• RoCE v1（2010 年）：基于以太网链路层（Layer 2），不支持IP路由，交换机需要支持PFC等流控技术。

• RoCE v2（2014 年）：基于UDP/IP（Layer 3），支持IP路由，解决了扩展性问题，成为当前主流。

RoCE的优势在于：可以使用支持 DCB 特性的标准以太网交换机，仅需更换网卡，大大降低了部署成本。华为、阿里云、AWS、Google等主流云厂商的数据中心网络均采用RoCE v2方案。

什么是 DCB？

 DCB（Data Center Bridging，数据中心桥接）是以太网的一组增强特性，包括 PFC（优先级流控）、ETS（增强传输选择）等，用于构建无损网络环境。普通企业级/接入层交换机通常不支持 DCB，因此部署 RoCE 时需要选用明确支持 DCB 特性的交换机型号。

6.3 iWARP：被边缘化的"兼容派"

iWARP基于TCP/IP实现RDMA，利用TCP的可靠性来保证数据传输。它的优势是可以在现有IP网络上直接部署，无需配置无损网络。

但缺点是：

• TCP的复杂性导致硬件卸载效率低，性能上限不及RoCE

• 仅支持可靠连接，不支持多播

• 生态支持有限，目前仅有少数厂商（如Chelsio）支持，Intel已在新网卡中放弃iWARP

• 在25G/50G/100G+速率下几乎没有产品

因此，iWARP已逐渐被市场边缘化，RoCE成为以太网RDMA的事实标准。

七、为什么RDMA需要"无损网络"？

RDMA的高性能建立在网络不丢包的前提下。一旦网络出现丢包，RDMA需要重传，延迟会急剧上升，性能优势荡然无存。

但传统以太网是"尽力而为"（Best Effort）的，不保证不丢包。为了让RoCE在以太网上稳定运行，业界引入了一套无损网络技术体系：

7.1 PFC（Priority-based Flow Control，基于优先级的流控）

PFC是IEEE 802.1Qbb标准定义的"逐跳流控"机制。当交换机某个端口的接收缓冲区即将满时，它会向上游设备发送一个PAUSE帧，告诉对方"先别发了，等我处理完"。上游设备收到PAUSE帧后立即停止发送，等收到RESUME帧后再恢复。

PFC可以按优先级进行流控，确保RDMA流量（高优先级）不会被普通流量（低优先级）影响。

7.2 ECN（Explicit Congestion Notification，显式拥塞通知）

PFC是"被动防守"——等缓冲区快满了才喊停。ECN则是"主动预警"：

当交换机检测到拥塞趋势（队列长度超过阈值）时，会在经过的数据包中标记ECN位。接收端收到标记后，向发送端发送拥塞通知。发送端收到通知后主动降低发送速率，从源头避免拥塞。

7.3 拥塞控制算法

除了PFC和ECN，RoCE还需要部署专门的拥塞控制算法，如：

• DCQCN（Data Center Quantized Congestion Notification）：阿里云、微软等大规模部署的算法

• TIMELY：Google提出的基于延迟的拥塞控制

• HPCC：华为提出的高精度拥塞控制

这些技术共同构建了一个低时延、零丢包、高吞吐的网络承载环境，是RDMA稳定运行的"生命线"。

八、RDMA正在改变哪些行业？真实案例与数据

8.1 AI大模型训练：从"等数据"到"算不停"

GPT-4、Llama、DeepSeek等模型的训练需要数千张GPU之间频繁同步梯度数据。在传统的gRPC通信模式下，GPU大量时间都在"空等"数据。

阿里云PAISoar的实测数据（64 GPU卡）：

• 仅将底层通信替换为RDMA，模型性能提升：

• Inception v3: +24.94%

• ResNet-50: +44.83%

• ResNet-152: +38.80%

• VGG16: +23.38%

• 采用Ring AllReduce + RDMA vs 传统gRPC：

• Inception v3: +84.77%

• ResNet-50: +125.43%

• ResNet-152: +56.40%

• VGG16: +40.04%

在RoCE网络中，单向延迟可降至2-3μs，而传统TCP为10-15μs。这意味着GPU的等待时间减少了5-7倍，训练效率大幅提升。

8.2 GPUDirect RDMA：让数据"直达"GPU显存

普通RDMA解决了"服务器内存之间"的直接通信，但AI训练中数据最终要到达GPU显存。如果数据先到系统内存，再由CPU搬到GPU显存，仍然多了一道中转。

GPUDirect RDMA技术让RDMA网卡直接读写GPU显存，彻底绕开主机内存和CPU。数据从一台服务器的网卡直接"飞"到另一台服务器的GPU显存中，实现了真正的"端到端零拷贝"。

配合 GPUDirect RDMA 技术，跨节点 GPU 之间的通信无需再经过「网卡→主机内存→CPU 搬运→GPU 显存」的中转路径，端到端通信时延从传统方案的十几微秒降至 2~3μs，大吞吐量 I/O 场景下性能提升可达 3~4 倍。

8.3 分布式存储：JuiceFS、Ceph的"加速器"

分布式文件系统引入RDMA后，客户端与缓存节点之间的带宽上限大幅提升：

• JuiceFS：引入RDMA后，CPU占用从近50%降至约1/3，在160Gbps网卡测试中带宽可达20 GiB/s。

• Ceph：通过NVMe-oF（NVMe over Fabrics）结合RDMA，存储访问延迟从毫秒级降至微秒级。

本质上，NVMe-oF若非使用FC网络，就是NVMe over RDMA——包括NVMe over InfiniBand、NVMe over RoCE等。

8.4 数据库与金融交易

在高频交易、实时数据库等场景，微秒级的延迟差异可能意味着巨额利润或损失。RDMA让数据库节点之间可以直接交换内存页，避免了传统网络协议栈的层层开销。

8.5 高性能计算（HPC）

科学计算、基因测序、气象模拟、流体力学仿真等场景对网络延迟极度敏感。InfiniBand RDMA已成为全球Top500超算的标配，支撑着人类最前沿的科学探索。

GPU服务器内部架构：RDMA网卡（IB）通过PCIe Switch与GPU直连，配合GPUDirect技术实现数据"零中转"。

九、国内厂商的RDMA实践

9.1 阿里云：自研RoCE网络

阿里云数据中心网络采用RoCE v2方案，自研了基于DCQCN的拥塞控制算法，支撑了PAI平台的深度学习训练。在内部测试中，RoCE单向延迟稳定在2-3μs，为大规模AI训练提供了坚实的网络底座。

9.2 华为：超融合数据中心网络

华为推出了基于RoCE的超融合数据中心网络解决方案，通过智能无损算法（iLossless）实现网络的零丢包。其智算网络架构支持计算、存储、高性能计算三大区域的统一网络承载，降低了数据中心的网络复杂度。

9.3 腾讯云与百度

腾讯云、百度智能云等也在其智算集群中大规模部署RoCE网络，支撑混元大模型、文心一言等AI应用的训练与推理。

十、总结：一张图看懂RDMA

十一、写在最后：RDMA的未来

从DMA到RDMA，从芯片内到机房间，"直接访问"的哲学正在重塑整个计算架构。未来，随着400Gbps、800Gbps网络的普及，RDMA将成为每一台服务器的"标准配置"。

同时，RDMA技术本身也在演进：

• RDMA over QUIC：将 RDMA 与 QUIC 协议结合，探索 RDMA 在广域网、公网场景下的适用性，目前尚处于研究探索阶段。

• 可编程拥塞控制：更智能的网络自适应算法

• 与CXL（Compute Express Link）融合：未来可能实现跨机架的内存池化

下一次当你惊叹于AI的惊人能力时，别忘了——在幕后，RDMA正默默承载着这场算力革命的数据洪流。