最近在做 AI 训练集群网络规划时很多朋友都在讨论同一个热点Meta AI 研究团队提出的 MetaRoCE目标是在“AI 规模”的以太网上把 RDMA 这条路走得更稳、更快。不少人会问RoCE 不是早就有了吗为什么还要新做一套传输协议它和 InfiniBand、传统无损以太网有什么区别这些问题如果只停留在概念层面很容易绕晕所以这篇文章打算从 RDMA 的工作原理讲起结合 MetaRoCE 公开论文的技术方向做一次拆解再给出一套可以在 Linux 环境下直接操作验证的 RDMA 环境搭建、无损以太网配置、带宽与延迟测试流程。本文适合正在做 AI 集群网络规划、GPU 训练性能优化或者想从 TCP 网络转向 RDMA 的开发者阅读。读完你会理解 RDMA 的核心机制、RoCEv2 与无损网络的关系、MetaRoCE 解决什么问题以及如何在自己的两台服务器之间快速跑通 RDMA 通信。1. 为什么 AI 训练流量需要新的传输协议1.1 分布式训练的网络瓶颈大模型训练已经不是单机单卡能完成的任务。以万卡集群为例数据并行、张量并行、流水线并行会同时存在GPU 之间需要频繁执行 all-reduce、all-gather、reduce-scatter 这类集合通信操作。一次全集群 all-reduce 的完成时间直接影响 GPU 的空闲等待时间进而影响训练效率。业内衡量训练效率时经常会看 MFUModel FLOPs Utilization也就是硬件算力的实际利用率。而网络恰恰是拉低 MFU 的主要因素之一。假设一个 10000 GPU 集群每 10 秒执行一次集合通信如果网络延迟高 10 毫秒理论上就会有约 0.1% 的算力浪费如果出现拥塞丢包导致重传等待时间会从毫秒级恶化到秒级整卡训练进度直接卡住。更麻烦的是 AI 流量的特点。训练过程中的通信模式非常规律却又高度突发大量 GPU 在同一个时间点同时发数据形成典型的 incast 流量流量大小随模型并行策略变化短的只有几十 KB长的达到几百 MB。传统 TCP 在这种场景下表现得并不理想原因不是 TCP 不够成熟而是它的设计目标并不是微秒级低延迟和大规模同步通信。1.2 从 TCP 到 RDMA 的转变TCP 走的是内核协议栈应用数据先拷贝到内核 socket 缓冲区经过 TCP 分段、IP 路由、网卡发送对端接收后再经过内核处理、拷贝到用户态。这个路径可靠且通用但存在三个明显问题多次内存拷贝CPU 开销高带宽越高越吃力。拥塞控制依赖丢包或者显式拥塞通知窗口恢复速度慢。按序交付导致队头阻塞一个报文丢失后面所有数据都在等它。RDMARemote Direct Memory Access远程直接内存访问则完全改变了数据路径。它允许一台机器直接读写另一台机器的内存不需要对端 CPU 参与数据搬运。发送方网卡通过 DMA 直接从应用内存取数据接收方网卡通过 DMA 直接写入应用内存中间绕过了内核协议栈和多次拷贝延迟从几十微秒降到几微秒CPU 占用也大幅下降。这也是为什么 InfiniBand 能长期统治超算和 HPC 领域而现在越来越多 AI 集群也开始转向 RDMA 技术。问题在于InfiniBand 的传输层能力确实强但网络设备生态相对封闭规模大了以后成本很高。于是业内一直在探索能不能用开放、成熟、成本更低的以太网也把 RDMA 跑出接近 InfiniBand 的效果。2. RDMA 工作原理与 RoCE 协议基础2.1 RDMA 的核心机制先理解 RDMA 的几个基本概念Memory Registration内存注册应用告诉网卡“这块内存可以被远程访问”网卡记录内存地址和长度后续 DMA 操作直接基于注册信息进行。Queue PairQP通信双方各维护一个发送队列和一个接收队列应用把发送/接收请求放到队列里网卡硬件负责处理。Completion QueueCQDMA 操作完成后网卡向 CQ 写入完成事件应用轮询或等待通知即可。Work RequestWR一次读、写或发送操作的描述。一次典型 RDMA 写操作的流程是应用注册内存后将 WR 投递到 QP 的发送队列网卡硬件从源内存 DMA 数据并封装成报文发到对端对端网卡根据报文中的 QP 信息把数据 DMA 写入对应内存最后两端 CQ 都会收到完成通知。全程 CPU 只在最初和最后参与数据搬运完全由硬件完成。这种方式带来了三个关键优势Kernel Bypass应用绕过内核直接与网卡交互Zero Copy内存数据不用在用户态和内核态之间反复拷贝CPU Offload数据的封装、传输、确认、重传都有网卡硬件处理。2.2 RDMA 的三种主要实现方式RDMA 是一个技术思想落地时主要有三种协议InfiniBand从物理层到传输层完整定义的 RDMA 网络延迟最低、可靠性强但交换机、网卡生态相对封闭采购和维护成本较高。RoCERDMA over Converged Ethernet在以太网上承载 RDMA复用以太网物理层和链路层网卡和交换机成本更低。iWARPRDMA over TCP可以直接跑在普通以太网上但 TCP 协议栈开销仍然存在性能不如 RoCE。对于 AI 集群来说目前主流是 RoCE。它既能享受以太网的开放生态又能利用 RDMA 的硬件卸载能力因此成为 InfiniBand 之外最受关注的方向。2.3 RoCEv1 与 RoCEv2 的差异RoCE 分为两个主要版本。RoCEv1 在以太网二层直接封装 RDMA 报文使用专门的 EtherType0x8915只能在同一个二层网络内通信无法跨 VLAN 或跨子网路由扩展性受限。RoCEv2 则把 RDMA 报文封装在 UDP 和 IP 中使用 UDP 目的端口 4791 标识 RoCEv2 流量。这样报文可以像普通 IP 报文一样被三层路由在多机柜、多数据中心的场景下更容易扩展。目前绝大多数数据中心 AI 方案使用的是 RoCEv2。从以太网帧的角度看RoCEv2 报文仍然遵循标准以太网帧结构帧尾同样带有 FCS 校验因此链路误码、光纤质量问题最终都会体现在 FCS 错误计数上。这也是后续排查链路问题时要重点关注的指标。2.4 QP 的传输模式RC、UC、UDRDMA 通信基于 QP而 QP 可以配置为不同传输模式RCReliable Connection可靠连接每个 QP 对应一个远端 QP提供可靠有序传输支持 RDMA Write、RDMA Read 和原子操作。这是 AI 训练中最常用的模式。UCUnreliable Connection不可靠连接同样是点对点连接但不保证可靠性和顺序少了确认和重传开销适合对丢包不敏感的场景。UDUnreliable Datagram不可靠数据报支持多对多通信单个 QP 可以发给多个远端 QP但报文长度受限于 MTU且不支持 RDMA Read。RC 模式下的可靠性由网卡硬件保证发送方网卡会保存报文副本在收到 NAK 或确认超时后重传。但这里有个前提如果网络频繁丢包RC 的重传机制就会频繁触发性能会急剧下降。所以 RoCE 对底层网络提出了非常高的要求这就是无损网络概念的由来。2.5 无损网络PFC 与 ECN以太网是尽力而为的拥塞时交换机会直接丢包。对 TCP 来说丢包可以接受因为 TCP 本来就要靠丢包触发拥塞控制。但 RoCE 的 RC 模式依赖硬件重传丢包率一旦超过阈值重传风暴会吞噬大量带宽和 CPU 资源。因此 RoCE 需要把底层以太网改造成“无损”网络最常用的两个机制是 PFC 和 ECN。PFCPriority Flow Control优先级流控是 IEEE 802.1Qbb 定义的机制。交换机在某个队列的缓存超过阈值时向对端发送暂停帧让对端暂停发送该优先级的数据。这里注意PFC 是按优先级暂停不是整个端口暂停因此可以保护无损优先级上的 RoCE 流量同时允许其他优先级流量继续转发。ECNExplicit Congestion Notification显式拥塞通知则是对队列深度进行标记。交换机检测到队列拥塞时对报文打上 ECN 标记接收端把拥塞信息反馈给发送端发送端主动降速。DCQCN 就是结合 ECN 标记和发送端速率降低的经典拥塞控制算法。PFC 负责“不丢包”ECN 负责“防拥塞”两者配合构成了 RoCE 无损网络的基础。但 PFC 在使用中也有副作用暂停帧会向上游传播一旦某个队列持续被暂停可能引发队头阻塞极端情况下甚至形成死锁。这正是后来需要更先进传输协议的原因。3. MetaRoCE面向 AI 规模以太网的传输协议设计思路3.1 为什么还需要新协议既然 RoCE PFC ECN 已经跑了很多年为什么还要提出 MetaRoCE核心原因在于现有方案更适合传统数据中心流量而 AI 训练流量有自己的特殊模式。第一个问题是拥塞控制粒度不够。DCQCN 这类算法是为通用数据中心流量设计的面对 AI 训练中周期性的同步流量、大量 GPU 同时发数据的 incast 场景时收敛速度不够快尾延迟会明显升高。第二个问题是负载均衡不均匀。传统网络使用 ECMP 做多路径负载均衡基于五元组哈希把流量分配到不同路径。AI 训练的集合通信流量往往是大象流一个哈希选路可能就把几条大流分到同一条链路上其他链路空闲形成慢节点。分布式训练遵循木桶效应最慢的一路决定了整次通信的完成时间因此负载不均的影响会被放大。第三个问题是 PFC 风暴与运维复杂度。无损网络的 PFC 参数需要精细调优队列缓存、暂停阈值、恢复阈值都要和流量模型匹配。在万卡规模下任何一台交换机的参数异常都可能引发 PFC 风暴影响整个训练集群。3.2 MetaRoCE 的核心设计方向根据目前已公开的论文与技术分享MetaRoCE 并不是简单地把 RoCE 重新包装而是尝试从传输层解决 RoCE 在大规模以太网上遇见的系统性问题。综合公开信息来看它主要围绕以下几个方向主动式流控不再单纯依赖 PFC 被动暂停和 ECN 被动降速而是引入更主动的速率控制机制让发送端在拥塞发生前就调整发送速率。选择性重传相比完全依赖 PFC 保证“不丢包”MetaRoCE 在传输层引入更高效的选择性重传能力即使出现零星丢包也能快速恢复而不是触发整个连接的重传风暴。多路径与报文级负载均衡通过把报文分散到多条路径避免大象流被哈希到同一条链路从而降低尾延迟。端到端可观测性在协议层面加入更多探测和监控机制快速定位链路质量、队列时延和丢包点减小异常定位时间。与训练框架协同传输协议不是孤立存在的它需要与 NCCL 这类集合通信库配合让流量调度更贴合训练任务的节奏。这里需要特别提醒MetaRoCE 属于研究型成果具体算法细节还在持续迭代建议以论文原文和后续工程化文档为准。对普通开发者来说更重要的是理解它所解决问题的方法论传输协议要针对应用场景重新设计而不是拿来主义。3.3 一句话理解 MetaRoCE如果只用一句话概括MetaRoCE 想做的是让 RoCE 在高成本、高复杂度、但性能强大的 InfiniBand 和开放、低成本、但传输能力相对弱的普通以太网之间找到一个工程上可落地的平衡点。它不否定以太网的价值相反它试图通过改进传输层把以太网改造成真正适合 AI 训练的基础设施。理解这一点再看后面要介绍的具体配置与调优手段就不会觉得这些参数只是零散的“经验技巧”而是围绕同一目标展开的系统工程。4. 环境准备在 Linux 上搭建 RDMA 验证环境理论讲完接下来进入实战。想要真正理解 RoCE建议准备两台带 RDMA 网卡的服务器。没有的话也可以在虚拟化平台上模拟但性能和真实网卡差距较大最好的方式是实际物理机验证。4.1 硬件与系统要求RDMA 能力依赖网卡硬件。目前常见的支持 RDMA 的网卡包括NVIDIA Mellanox ConnectX-4/5/6/7 系列。Broadcom 部分支持 RoCE 的网卡。Intel E810 等支持 iWARP 或 RoCE 的网卡。驱动方面Mellanox 网卡使用 mlx5_core 驱动Intel 部分网卡使用 irdma 驱动。Linux 内核从 4.x 开始逐步内置了这些驱动的 inbox 版本但生产环境通常建议安装厂商提供的 OFED 驱动包功能和性能更完整。操作系统建议使用 Ubuntu 20.04/22.04、CentOS 7/8、Rocky Linux 等主流发行版。这里不写死具体版本号因为不同内核版本自带的 rdma-core 版本差别较大大家需要根据自己的环境和网卡型号调整。4.2 安装 rdma-core 与常用工具在 Ubuntu 上可以直接使用 apt 安装 RDMA 用户态工具sudo apt update sudo apt install -y rdma-core perftest ibutils2 ibverbs-utilsCentOS/Rocky Linux 上对应的包名可能略有不同可以通过 yum 搜索 rdma-core 和 perftest 确认。安装完成后加载内核模块sudo modprobe mlx5_core sudo modprobe ib_core sudo modprobe ib_umad sudo modprobe ib_uverbs如果使用源码编译自行安装 OFED需要参考厂商安装文档安装完成后一般会自动完成模块加载和持久化配置。4.3 确认 RDMA 设备可见使用下面的命令检查系统是否已经识别 RDMA 设备# 查看所有 RDMA 设备链路状态 rdma link show # 查看设备的详细能力 ibv_devinfo -v # 查看 InfiniBand 相关设备状态 ibstatus一个正常的输出效果类似这样$ rdma link show link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev enp1s0 link mlx5_1/1 state ACTIVE physical_state LINK_UP netdev enp1s0如果看到 state 为 DOWN 或者 netdev 为空说明设备没有初始化成功需要检查驱动、固件和链路状态。ibv_devinfo会输出设备支持的端口速率、MTU、传输模式等信息这是判断网卡是否支持 RoCEv2 的重要依据。5. 无损以太网的关键配置示例RoCE 能否跑满带宽取决于底层网络是否“无损”。无损网络配置包括端侧网卡、交换机队列、PFC、ECN 等部分。下面以常见环境为例演示配置思路。5.1 端侧配置端侧主要做三件事调整 MTU、映射优先级、设置 ECN。RoCEv2 建议使用大 MTU比如 4200这样可以减少报文数量、提高有效载荷比例。命令如下# 设置 RoCE 网卡的 MTU按实际网卡名修改 ip link set enp1s0 mtu 4200优先级映射的目的是让 RoCE 流量走指定的 Traffic Class从而匹配交换机上的 PFC 优先级别。以 NVIDIA Mellanox 网卡为例可以使用 mlnx_qos 工具查看和配置# 查看当前 QoS 配置 mlnx_qos -i enp1s0 # 修改优先级到 Traffic Class 的映射参数以实际版本为准 mlnx_qos -i enp1s0 --prio_tc0,0,0,0,0,0,0,0在 Linux 侧还需要确认 RoCE 报文的 DSCP 值能够正确映射从而让交换机识别并进入无损队列。不同厂商的命令差异较大建议先查看当前网卡能力再按厂商文档调整。5.2 交换机侧配置交换机侧的配置涉及 PFC 优先级、ECN 阈值、缓存池大小三个核心参数。这里给出一段 SONiC 风格的配置示意各家厂商的 NOS 细节不同本文重点演示参数含义{ BUFFER_PG: { Ethernet0|3: { profile: ingress_lossless_profile } }, BUFFER_PROFILE: { ingress_lossless_profile: { pool: ingress_lossless_pool, size: 1048576, xon_offset: 16384, xon: 36864, xoff: 65536 } }, ECN: { Ethernet0: { ecn_mode: threshold, ecn_threshold: 1048576 } } }这段配置里的几个概念值得记住BUFFER_PG把某个端口的某个优先级映射到无损缓存配置。xon/xoff缓存水线。当占用超过 xoff 时触发 PFC 暂停降到 xon 以下时恢复发送。ecn_threshold队列长度超过该阈值时开始对报文标记 ECN。这些参数没有万能值需要根据实际网络拓扑、端口速率、流量突发程度反复测试。建议先在测试环境验证再推广到生产集群。5.3 验证无损效果配置完成后先确认网卡和交换机是否真的发送了 PFC 暂停帧可以通过 ethtool 检查统计计数器# 查看网卡统计重点看 pause 相关计数 ethtool -S enp1s0 | grep -E tx_pause|rx_pause # 查看网卡丢包和 ECN 计数Mellanox 网卡的计数器名称可能不同 ethtool -S enp1s0 | grep -E ecn|dropped在网络空闲时tx_pause 和 rx_pause 计数应该很低。如果出现大量 pause 帧说明流量突发已经触发了 PFC 流控需要关注缓存配置是否合理。如果 ECN 标记计数很高说明队列长期处于拥塞状态需要检查拥塞控制参数和应用侧的通信模式。6. 实战用 RDMA 工具测通节点间通信6.1 测试拓扑准备两台服务器每台配置一张支持 RoCE 的网卡并配置 RoCEv2 所需的三层网络。最简单的拓扑是两张网卡直连或者通过一台无损交换机连接。给两张网卡配置同网段 IP# 节点 A ip addr add 192.168.1.1/24 dev enp1s0 ip link set enp1s0 up # 节点 B ip addr add 192.168.1.2/24 dev enp1s0 ip link set enp1s0 up6.2 用 perftest 测试带宽perftest 是 RDMA 最常用的压力测试工具。在节点 A 上启动服务端在节点 B 上启动客户端# 服务端节点 A ib_write_bw -d mlx5_0 -x 3 -F 192.168.1.1 # 客户端节点 B ib_write_bw -d mlx5_0 -x 3 -F 192.168.1.1参数说明-d指定使用哪个 RDMA 设备例如 mlx5_0。-x指定端口号。-F前台运行便于看到实时结果。后面跟服务端 IP。测试完成后客户端会输出带宽结果核心指标是 Throughput 和 Message Rate。在 100G 网络下单条 RC 连接的 ib_write_bw 一般能跑到 90 Gb/s 以上如果只有十几 Gb/s说明配置一定有问题。6.3 测试延迟延迟测试使用 ib_write_lat 或 ib_send_lat# 服务端 ib_write_lat -d mlx5_0 -F 192.168.1.1 # 客户端 ib_write_lat -d mlx5_0 -F 192.168.1.1输出中的 Average latency 通常在 1 到 3 微秒量级具体取决于网卡型号和驱动版本。如果延迟达到几百微秒大概率是报文进入了软件路径或者网络存在严重拥塞。6.4 配合 NCCL 验证训练通信perftest 只验证了单 QP 的 RDMA 能力真实训练还要配合 NCCL。NCCL 提供了环境变量来控制 RDMA 行为export NCCL_IB_DISABLE0 export NCCL_IB_HCAmlx5_0,mlx5_1 export NCCL_IB_TC106 export NCCL_IB_SL3 export NCCL_IB_TIMEOUT22 export NCCL_IB_RETRY_CNT7 export NCCL_IB_GID_INDEX3接着用 NVIDIA 提供的 nccl-tests 跑一次 allreduce./build/all_reduce_perf -b 128M -e 128M -f 2 -g 8-g 指定用多少张 GPU。如果输出中的 busbw 接近理论带宽说明 NCCL 的 RDMA 路径已经打通。实际训练时还可以结合训练日志里的通信耗时进一步判断是否需要调整 NCCL 参数。7. 常见问题与排查思路RDMA 环境搭建过程中最容易踩坑的往往不是代码而是网络配置和系统参数。下面整理一张高频问题表问题现象常见原因解决思路rdma link show 看不到设备驱动未加载或固件不匹配检查 modprobe 输出、安装对应 OFED 版本ibv_devinfo 端口 DOWN网线/光模块未插好或对端没启动检查 ethtool 链路状态、光模块告警创建 QP 报 Operation not permitted内存锁页限制过小执行 ulimit -l unlimited或调整系统配置带宽只有线速的 10%MTU 太小、QoS 映射错误、PFC 未生效统一端到端 MTU检查 PFC 优先级一致性ping 通但 RDMA 不通RoCEv2 UDP 端口 4791 被 ACL 过滤检查交换机 ACL、确保相关 IP/端口放行ECN 标记计数非常高拥塞控制参数不匹配调整 ECN 阈值确认 DCQCN 参数生效FCS 错误计数增长光纤或光模块质量问题更换跳线/模块检查接口误码NCCL 初始化超时NCCL_IB_TIMEOUT 太小或网络丢包增大超时参数排查链路丢包这里挑两个最典型的展开说明。第一个是“带宽上不去”。很多情况下服务器和交换机之间的 PFC 优先级不一致比如端侧把 RoCE 流量映射到 priority 3但交换机只对 priority 5 配置了无损队列。这时 RoCE 报文实际上走的是普通有损队列一旦拥塞就会丢包RC 模式开始反复重传带宽自然上不去。排查方法是检查两端优先级配置确保完全一致。第二个是“内存锁页不足”。RDMA 需要把应用内存锁在物理内存中不允许换页这要求进程有足够的 memlock 限制。常见做法是在 systemd service 里设置 LimitMEMLOCKinfinity或者直接在 shell 中执行 ulimit -l unlimited。8. 最佳实践与工程建议8.1 网络规划优先AI 集群的 RoCE 网络规划应该先定目标再上设备。明确训练任务需要多少 GPU、集合通信流量多大、是否要求多路径容错再决定拓扑和收敛比。推荐 spine-leaf 两层拓扑路径越多报文级负载均衡的发挥空间越大。不要在生产集群里直接调 PFC 参数。所有缓冲区阈值、ECN 阈值、QoS 映射都先在测试环境用 perftest 和 nccl-tests 压测记录不同参数下的带宽和尾延迟找到最稳的一组再上线。8.2 参数调优要建立基线网卡参数、NCCL 参数、交换机参数共同决定最终性能。建议把每次调整记录成基线记录网卡固件、驱动版本、rdma-core 版本。记录交换机 NOS 版本和 QoS 配置。记录 perftest 的带宽、延迟结果。记录 NCCL env 配置和 allreduce busbw 结果。这样在升级驱动、替换交换机、增加 GPU 节点后可以通过对比基线快速发现性能退化。8.3 监控与告警要覆盖 PFC 和 ECNRoCE 网络最大的风险是 PFC 风暴。建议在网卡和交换机侧都开启 pause 计数、ECN 标记计数、丢包率监控。一旦发现任意接口的 pause 帧速率持续飙升立即定位触发源。交换机侧还可以开启 sFlow 或者 gNMI 遥测采集队列深度和端口拥塞信息。训练过程中训练框架本身的通信耗时也是重要信号。如果 allreduce 耗时突然升高优先检查物理链路误码、光模块温度告警和交换机风扇/电源状态这些硬件问题也会表现为网络抖动。8.4 多租户隔离与安全边界RoCEv2 本质上是普通 UDP/IP 报文协议本身没有内置加密。在多租户环境下如果不同租户共享同一无损网络某个租户的异常流量可能引发 PFC 暂停影响其他租户的训练任务。建议通过 VLAN/VRF 做二层隔离并在交换机上限制无损优先级的入口速率。同时要注意PFC 不应该跨信任边界生效。不同租户之间如果接口对接口直连建议关闭跨租户的 PFC或者通过 ACL 限制 UDP 4791 端口只能从可信来源访问。8.5 跟随社区与标准演进RDMA 的发展离不开社区推动。Linux 内核侧有 linux-rdma 邮件列表和 rdma-core 项目负责用户态库和内核驱动演进OpenFabrics Alliance 负责 OFED 的维护和认证IBTA 负责 InfiniBand 与 RoCE 相关规范Ultra Ethernet Consortium 则聚焦以太网在 AI 大规模场景下的传输增强。MetaRoCE 这类研究也会反过来影响这些标准组织日常在 GitHub 上关注 rdma-core、perftest、nccl-tests 的更新对保持技术判断力很有帮助。9. 写在最后回到开头的那个问题RoCE 早就有了为什么还要关注 MetaRoCE因为 AI 规模正在把传输协议的设计边界推到新的极限。对于大多数团队来说短期内并不需要自己实现一个传输协议但一定需要理解 RoCE 的底层机制掌握无损网络配置、性能测试和异常排查方法。建议动手路线很清晰先准备两张支持 RDMA 的网卡直连跑通 ib_write_bw 和 ib_write_lat再接入无损交换机配置 PFC 和 ECN验证性能是否稳定最后在 GPU 节点上用 nccl-tests 测试真实集合通信性能。只有把这条链路每一步都跑通再回头看 MetaRoCE 论文里关于主动流控、选择性重传、多路径负载均衡的设计才会有更具体的体感。下一篇文章我打算进一步拆解 RoCE 拥塞控制在不同流量模型下的表现并对比 DCQCN、Timely 以及新方案之间的差异欢迎有类似问题的小伙伴一起讨论。