RoCE（RDMA over Converged Ethernet）
RoCE 在标准以太网上实现 RDMA 功能，通过无损以太网机制（PFC + ECN）弥补以太网天然有损的缺陷，从而提供接近 InfiniBand 的低延迟和高带宽，同时复用现有以太网基础设施，大幅降低部署成本。Meta（24K GPU 集群）、阿里云、国内主要 AI 云厂商均大规模采用 RoCEv2。
RoCE v1 vs RoCE v2
| 特性 | RoCE v1 | RoCE v2 |
|---|---|---|
| 封装层 | 以太网帧（L2，EtherType 0x8915） | UDP/IP（L3，UDP dst port 4791） |
| 路由 | 不可路由，仅限同一广播域 | 可路由，支持跨子网 |
| 多路径 | 不支持 | ECMP（等价多路径）支持 |
| 拥塞控制 | PFC 逐跳背压 | PFC + ECN（DCQCN/TIMELY） |
| 主流程度 | 已被淘汰，仅存量部署 | 当前主流，行业标准 |
| 引入时间 | 2010 | 2014 |
RoCEv2 将 IB 传输层（BTH，Base Transport Header）封装在 UDP payload 中，使 IP 路由设备无需感知 RDMA 语义，网络基础设施与 IB 完全兼容。5 元组（源/目的 IP、源/目的端口、协议）可用于 ECMP 哈希，实现流量负载均衡。
协议栈结构
应用层（MPI、NCCL、存储客户端）
|
Verb API（ibv_post_send / ibv_poll_cq）
|
RDMA Provider（libibverbs + rdma-core）
|
RoCEv2 传输层（IB BTH + RETH/AETH）
|
UDP / IP（L3 路由）
|
以太网 MAC（L2）
|
25/100/200/400 GbE 物理层
与 InfiniBand Verb 兼容：RoCEv2 在应用层与 IB 使用相同的 Verb API（ibv_* 系列函数），应用代码无需修改即可在 IB 和 RoCE 网卡之间迁移。NCCL、OpenMPI、UCX 均通过同一接口同时支持 IB 和 RoCE。
RoCEv2 同样支持 RC/UD QP、RDMA Write/Read、Atomic 操作，语义与 IB 一致。主要差异在于底层封装和拥塞控制机制。
无损以太网要求
无损以太网是 RoCE 正常工作的前提。标准以太网在拥塞时直接丢包，RDMA 的 RC QP 遇到丢包后需要重传，重传路径涉及软件介入，延迟急剧增加（从 us 级变为 ms 级）。因此必须通过以下机制保证零丢包：
PFC（Priority Flow Control，802.1Qbb）
PFC 是逐跳（hop-by-hop）的背压机制，工作在链路层：
工作原理：
- 接收端（交换机端口或 NIC）监控各优先级队列的占用水位。
- 当某优先级的缓冲区占用超过 Xon 门限（暂停门限）时，向上游发送 PAUSE 帧，携带需要暂停的优先级和暂停时间。
- 上游收到 PAUSE 帧后，停止发送该优先级的数据，直到暂停时间到期或收到 PFCWD 恢复帧（Xoff 门限以下时主动恢复）。
- RDMA 流量映射到独立优先级（通常 Priority 3 或 Priority 5），与普通 TCP 流量隔离。
PFC 的已知问题：
- Head-of-Line Blocking（HOLB）：同一优先级内，一条流的拥塞 PAUSE 会阻塞同优先级的所有流，即使其他流没有问题。
- PFC Deadlock（PFC 死锁）：多个交换机之间形成循环等待，所有方向均被 PAUSE，网络永久停顿。需要 Watchdog（PFCWD）定时检测并强制恢复。
- PAUSE 帧传播放大：背压沿链路向上游传播，可能影响无辜的流量。
缓解措施：细粒度优先级隔离、PFCWD（PFC Watchdog，自动断链恢复）、显式路由规避循环。
ECN（Explicit Congestion Notification）
ECN 是端到端的拥塞感知机制，工作在 IP 层（RoCEv2 特有，RoCEv1 不支持）：
工作原理：
- 发送端在 IP 头 ECN 字段标记 ECT（ECN-Capable Transport，01 或 10）。
- 交换机检测到队列深度超过 K_min 门限 时，将数据包 IP 头的 ECN 字段改写为 CE（Congestion Experienced，11）。
- 接收端（RoCEv2 NIC）收到 CE 标记后，向发送端回送 CNP（Congestion Notification Packet），这是一个特殊的 RoCEv2 控制包。
- 发送端收到 CNP 后执行速率降低（见 DCQCN 小节）。
ECN 标记使用 RED（Random Early Detection）变种：
队列深度 < K_min：不标记 CE
K_min <= 队列深度 < K_max：以概率 p = (depth - K_min) / (K_max - K_min) × P_max 标记
队列深度 >= K_max：以概率 P_max 标记（通常 P_max = 0.1-1.0）
DCQCN 拥塞控制
DCQCN（Data Center Quantized Congestion Notification）是 RoCEv2 最主流的拥塞控制算法，由微软研究院提出，结合 ECN（端到端信号）和 Rate-Based 控制（发送端执行）。
速率控制状态机
降速（Rate Decrease）：
收到 CNP -> 记录当前速率 RC
-> 将当前速率乘性减：RT = RC × (1 - α/2)
-> α 更新：α = α × (1 - g)，其中 g 为平滑因子（~0.00390625）
-> 进入 Fast Recovery 阶段
默认乘性减因子：首次收到 CNP 后，速率降低约 50%（α 初始值为 1）。连续收到 CNP 时降幅逐渐减小（α 递减），避免过度降速。
速率恢复（Rate Increase）：分两个阶段：
阶段 1 — Fast Recovery（快速恢复）：
每隔 B 字节或 T 时间，将速率设置为当前速率与目标速率的中间值
RT = (RT + RC) / 2
重复 F 次（典型 F = 5）
阶段 2 — Additive Increase（加性增）：
每隔 B 字节或 T 时间，速率线性增加一个固定步长 RAI
RT = RT + RAI
直到达到最大速率 Rmax 或收到新的 CNP
关键参数
| 参数 | 典型值 | 含义 |
|---|---|---|
| Rmin | 线速的 5-10% | 最低发送速率下限 |
| Rmax | 线速的 95-100% | 最高发送速率上限 |
| K_min / K_max | 100KB / 200KB | ECN 标记队列深度门限 |
| P_max | 0.5 | ECN 标记最大概率 |
| T | 55 us | 速率恢复计时器间隔 |
| B | 150 KB | 速率恢复字节计数间隔 |
| F | 5 | Fast Recovery 步数 |
| RAI | 40 Mbps | 加性增步长 |
实际部署中这些参数需根据集群规模和流量模式调优，配置不当会导致吞吐量震荡或收敛缓慢。
TIMELY 算法（替代方案）
Google 提出的基于 RTT 的拥塞控制，不依赖 ECN，通过测量 RTT 变化判断拥塞：
- RTT 增加 -> 降速，RTT 稳定 -> 恢复
- 优点：不需要交换机配置 ECN，部署简单
- 缺点：RTT 测量精度依赖高精度时钟，对时间戳抖动敏感
- 主要用于 Google 内部；RoCEv2 开源社区主要使用 DCQCN
与 InfiniBand 的性能对比
| 指标 | InfiniBand NDR | InfiniBand HDR | RoCEv2（200GbE） | RoCEv2（400GbE） |
|---|---|---|---|---|
| 单端口线速 | 400 Gbps | 200 Gbps | 200 Gbps | 400 Gbps |
| 单向峰值带宽 | ~48 GB/s | ~24 GB/s | ~23 GB/s | ~46 GB/s |
| 小消息延迟 | ~600 ns | ~700 ns | ~1-2 us | ~1-2 us |
| 无损保证机制 | 硬件信用流控，天然无损 | 硬件信用流控，天然无损 | PFC + ECN（软件配置） | PFC + ECN（软件配置） |
| 大规模拥塞控制 | ECN + FECN/BECN + SHARP | ECN + FECN/BECN | DCQCN / TIMELY | DCQCN / TIMELY |
| 网内计算 | SHARP（AllReduce 卸载） | SHARP（v2） | 无 | 无 |
| 硬件成本（相对） | 高 | 中 | 低 | 中 |
| 配置复杂度 | 中（SM 统一管理） | 中 | 高（PFC 参数调优） | 高 |
| 大规模稳定性 | 成熟 | 成熟 | PFC 死锁风险需管理 | PFC 死锁风险需管理 |
延迟差距分析：
RoCEv2 比 IB 延迟高约 2-3 倍的根本原因：
- UDP/IP 封装比 IB LRH/GRH 更长，序列化时间略增。
- ECN 拥塞控制的反馈回路比 IB 信用流控慢（需要 CNP 往返）。
- PFC 暂停期间，被暂停的流等待时间不确定。
- 以太网交换机 store-and-forward 延迟通常高于 IB 直通（cut-through）交换机。
对于 AI 训练中的大消息 AllReduce，带宽是主要瓶颈而非延迟，RoCEv2 与 IB 的性能差距在大消息下缩小至 5-10%。
在 AI 集群中的应用
适用场景
RoCEv2 在以下场景具有成本优势：
- 规模适中（<1000 GPU）：交换机数量少，PFC 死锁风险低，配置复杂度可管理。
- 成本敏感场景：以太网交换机价格约为同等端口数 IB 交换机的 1/3 到 1/2。
- 混合流量：同一以太网网络同时承载 RDMA 和普通 TCP 流量（不同优先级隔离）。
- 存储网络：NVMe-oF over RoCEv2 在 AI 存储系统中广泛使用。
主要厂商
- NVIDIA（原 Mellanox）ConnectX 系列：同一 NIC 支持 IB 和 RoCEv2 两种模式，ConnectX-7 同时支持 NDR IB 和 400GbE RoCEv2。
- Marvell FastLinQ：以太网 RDMA NIC，主要面向存储和超融合场景。
- 博通（Broadcom）：以太网交换机主力供应商，Tomahawk 和 Trident 系列广泛用于 RoCEv2 网络的 Spine/Leaf 层。
国内云厂商实践
阿里云：自研 RDMA 以太网方案，大规模部署 RoCEv2，通过自研交换机和拥塞控制算法（结合 DCQCN 改进版）支持 10万+ GPU 规模集群。主要经验：
- 精细化 PFC 优先级分离，RDMA 流量独占优先级 3
- 自适应 ECN 门限（动态根据队列深度调整 K_min/K_max）
- 引入 PFCWD + 链路级别 PFC 死锁检测，将死锁恢复时间控制在秒级以内
华为：iRDMA（基于 RoCEv2 改进），在昇腾集群内部使用，结合 iLossless 无损以太网方案（HPCC 拥塞控制算法，基于 INT 精确 RTT 测量）。
字节跳动 / 腾讯 / 百度：均大规模部署 400GbE RoCEv2，替代 IB 用于 GPU 集群节点间通信。
与 NVLink 的分工
与 InfiniBand 类似，RoCEv2 主要承担节点间通信：
节点内（NVLink / HCCS / ICI）：
TP AllReduce — 带宽最优，延迟最敏感
节点间（RoCEv2 400GbE）：
PP P2P — 激活值传递，消息适中
DP AllReduce — 梯度同步，消息大，带宽主导
EP AllToAll — MoE 专家路由，消息分散，延迟敏感
典型集群规格（400GbE RoCEv2）
| 层级 | 设备 | 端口规格 | 备注 |
|---|---|---|---|
| 节点 NIC | ConnectX-7 / CX7 | 2×200GbE 或 1×400GbE | 每 GPU 节点 1-2 张 NIC |
| Leaf 交换机 | Tomahawk4/5 | 64×400GbE | 下行连服务器，上行连 Spine |
| Spine 交换机 | Tomahawk5 / Jericho3 | 64-128×400GbE | 核心转发层 |
| 典型集群规模 | — | — | 512-4096 GPU（2 层 fat-tree） |
配置与运维要点
必须启用的网络功能
部署 RoCEv2 的以太网交换机必须配置：
- PFC：为 RDMA 流量优先级（如 Priority 3）启用 PFC，关闭其他优先级 PFC 以避免 HOLB。
- ECN：在所有交换机端口和 NIC 上启用 ECN，配置合适的 K_min/K_max。
- DCQCN 参数：在 NIC 驱动（OFED/MLNX_OFED）中配置 DCQCN 参数，并与交换机 ECN 门限匹配。
- PFCWD：启用 PFC Watchdog，设置超时时间（典型 200ms），检测并恢复 PFC 死锁。
- QoS 映射：确保 RDMA 流量的 DSCP 值正确映射到 PFC 优先级。
常见问题
| 问题 | 根因 | 解决方案 |
|---|---|---|
| 吞吐量低于线速 50% | DCQCN 参数配置过于激进，速率过度降速 | 调大 K_min/K_max，减小 P_max |
| 延迟抖动严重 | PFC 暂停时间不稳定，交换机缓冲区设置不当 | 增大交换机缓冲区，精调 PFC 水位 |
| PFC 死锁 | 网络拓扑存在环路，PFC 反馈形成循环等待 | 启用 PFCWD，检查路由无环 |
| RoCE 连接超时 | ECN 未正确传播，CNP 丢失 | 检查 QoS 配置，确保 CNP 走高优先级 |
详见 InfiniBand 专题文档 了解与 IB 的技术对比与选型建议。