RDMA 深入 —— InfiniBand、RoCE 与 iWARP

第五章 5.8 已经讲了 AI 集群里 IB / RoCE 的”应用层”。本篇深入协议——RDMA 的 verbs、QP / WQE、IB / RoCE / iWARP 的协议差异，以及实际调优。

为什么 RDMA 这么重要

1
2
3
4
5
6
7
8
9
传统 socket TCP：
  应用 → write(fd) → kernel → TCP/IP 栈 → 网卡 → 链路
  延迟 5-50 μs（同机房）
  CPU 占用：每包都过 kernel

RDMA：
  应用 → ibv_post_send → 网卡（DMA 直接读应用内存）→ 链路
  延迟 1-5 μs
  CPU 0 占用（除了发起请求那一下）

RDMA 三大特性：

graph TB
  R1[Kernel Bypass<br/>不过 OS 内核]
  R2[Zero Copy<br/>不拷贝数据]
  R3[Direct Memory Access<br/>网卡读写应用内存]
  R1 --> P[低延迟 + 低 CPU]
  R2 --> P
  R3 --> P

三种 RDMA 实现

graph TB
  RDMA[RDMA]
  RDMA --> IB[InfiniBand<br/>专用物理 + 链路 + 网络]
  RDMA --> ROCE[RoCE<br/>跑在以太网上]
  RDMA --> IWARP[iWARP<br/>跑在 TCP/IP 上]
InfiniBand RoCE v2 iWARP
物理层 IB 专用 以太网 以太网
链路层 IB 以太网 + 无损 以太网
网络层 IB IBA UDP/IP TCP/IP
传输层 IBA IBA iSER over TCP
流控 Credit-based 无损 PFC + ECN TCP 重传
延迟 1-2 μs 2-5 μs 5-15 μs
跨子网 经路由器 UDP 路由可达 TCP 路由可达
厂家 NVIDIA Mellanox 主导 NV / BCM / Marvell Chelsio 主导
市场 AI / HPC 主流 AI / 云存储 增长 金融 / 存储 小众

InfiniBand 协议栈

graph TB
  APP[应用]
  APP --> VERBS[Verbs API<br/>libibverbs]
  VERBS --> CORE[IB Core<br/>kernel]
  CORE --> HW[网卡硬件<br/>HCA]
  HW --> LINK[IB 链路层<br/>credit 流控]
  LINK --> PHY[IB 物理层<br/>SerDes / NRZ / PAM4]

HCA（Host Channel Adapter）= IB 网卡。每个 HCA 有：

1
2
3
GUID（Globally Unique ID）：     全局唯一
LID（Local ID）：                 本地子网内 16-bit
GID（Global ID）：                跨子网 128-bit（类似 IPv6 地址）

IB 子网管理器

每个 IB 网络有一个 SM（Subnet Manager）——通常运行在 IB 交换机上：

1
2
3
4
5
SM 职责：
  - 自动发现拓扑
  - 分配 LID
  - 配置交换机路由表
  - 监控链路状态

这是 IB 和以太网最大的不同——IB 自带”自动配置”，以太网要靠 BGP / 自配置协议。

verbs API：编程模型

RDMA 应用通过 libibverbs 编程。核心概念：

graph TB
  PD[Protection Domain<br/>保护域]
  CQ[Completion Queue<br/>完成队列]
  QP[Queue Pair<br/>SQ + RQ]
  MR[Memory Region<br/>注册内存]
  WR[Work Request<br/>请求]
  
  PD --- QP
  PD --- MR
  QP --- CQ
  WR --> QP
概念 作用
PD（Protection Domain） 保护域，隔离不同应用的资源
MR（Memory Region） 注册的内存——网卡知道 va→pa 映射
QP（Queue Pair） 一对 Send Queue + Receive Queue
CQ（Completion Queue） 操作完成事件队列
WR（Work Request） send/recv/read/write 请求
WC（Work Completion） WR 完成事件

QP 类型

1
2
3
4
5
RC（Reliable Connection）：可靠连接，类似 TCP
UC（Unreliable Connection）：不可靠连接（少用）
UD（Unreliable Datagram）：不可靠数据报，类似 UDP
XRC（eXtended RC）：     共享 QP 的扩展版（多对多）
DCT（Dynamic Connect）： 动态连接，万卡集群可扩展

RC 是最常用的——MPI / NCCL / Verbs 应用绝大多数用 RC。

四种核心操作

1
2
3
4
SEND / RECV：       双方都参与（双端模式）
RDMA WRITE：        发起方写到对方内存（单端，对方 CPU 不参与）
RDMA READ：         发起方读对方内存
ATOMIC：           远端原子操作（CAS / FAA）

RDMA WRITE/READ 是真正的”零开销”——对方 CPU 完全不知道。

1
2
3
4
5
6
7
8
9
// 简化的 RDMA WRITE 示例（伪代码）
struct ibv_send_wr wr = {
    .opcode = IBV_WR_RDMA_WRITE,
    .sg_list = &local_addr,
    .num_sge = 1,
    .wr.rdma.remote_addr = remote_addr,
    .wr.rdma.rkey = remote_key,
};
ibv_post_send(qp, &wr, &bad_wr);

RoCE 详解

RoCE = RDMA over Converged Ethernet

graph TB
  subgraph V1["RoCE v1"]
    L1V1[Ethernet]
    L2V1[IB 传输层]
    L1V1 --- L2V1
  end
  subgraph V2["RoCE v2"]
    L1V2[Ethernet]
    L2V2[IP]
    L3V2[UDP 4791 端口]
    L4V2[IB 传输层]
    L1V2 --- L2V2 --- L3V2 --- L4V2
  end

RoCE v1：链路层 RDMA，只能同 LAN 内（无 IP 头，不能路由）
RoCE v2：UDP 4791 端口承载 IB 传输层——可以跨子网路由

现在大家说 RoCE 默认是 v2。

RoCE 的”无损”挑战

IB 物理层就是无损的（credit 流控）；以太网默认会丢包，RoCE 必须靠无损以太网：

1
2
3
要素 1：PFC（Priority Flow Control，链路级背压）
要素 2：ECN（Explicit Congestion Notification，端到端拥塞）
要素 3：DCQCN（Data Center QCN，拥塞控制算法）

详细在 无损网络与拥塞控制 一篇展开。

iWARP 简介

iWARP（Internet Wide Area RDMA Protocol）：

1
2
3
4
5
6
7
8
9
10
11
RDMA 跑在 TCP 之上：
  IP / TCP / DDP / MPA / RDMAP / 应用

优点：
  - 利用 TCP 重传，不需要无损以太网
  - 跨数据中心可达
  
缺点：
  - 延迟大（10-15 μs）
  - 性能不如 RoCE
  - 厂家少（Chelsio / Intel）

iWARP 主要在金融、存储应用上有少量部署——AI 不用 iWARP。

GPUDirect RDMA

普通 RDMA 是 CPU 内存 ↔ CPU 内存。AI 训练要 GPU 内存 ↔ GPU 内存——这就是 GPUDirect RDMA：

graph LR
  G1[GPU A 显存] --> NIC1[HCA A]
  NIC1 --> NIC2[HCA B]
  NIC2 --> G2[GPU B 显存]
  
  CPU1[CPU A] -.- X[不参与]
  CPU2[CPU B] -.- X

工作原理：

1
2
3
4
1. GPU 显存 BAR 暴露给 PCIe 总线
2. 网卡 DMA 直接读写 GPU 显存（peer-to-peer over PCIe）
3. 不经过 CPU 内存
4. NCCL / MPI 等库自动启用

GPUDirect RDMA 让 GPU 跨节点通信延迟从 ~10 μs 降到 ~3 μs。这是 H100/B200 集群训练的标配。

配置要点

1
2
3
4
5
6
7
8
9
10
11
12
13
# 启用 GPUDirect（BlueField / ConnectX）
modprobe nvidia_peermem

# 验证
lsmod | grep nv_peer_mem
ibv_devinfo | grep -A5 active

# NCCL 测试（跨节点）
mpirun -np 16 -hostfile hosts ./all_reduce_perf -b 1G -e 16G -f 2 -g 8

# GDRCOPY（小消息加速）
git clone https://github.com/NVIDIA/gdrcopy
make install

性能数字直觉

操作 延迟 带宽
IB ConnectX-7 RC SEND（小消息） ~1 μs -
IB RDMA WRITE 4 KB ~2 μs -
IB RDMA READ 4 KB ~3 μs -
IB RC bulk write 1 MB - ~50 GB/s（400G）
RoCE v2 RC SEND ~2-3 μs -
iWARP TCP write 4 KB ~10 μs -
TCP socket 4 KB ~30-50 μs -
GPUDirect RDMA WRITE 4 KB ~3 μs（跨节点） -

实测带宽：

1
2
3
ConnectX-7 400G 单口理论：   400 Gbps = 50 GB/s
PCIe 5.0 ×16 单向：         64 GB/s
实测 ib_write_bw：          ~48 GB/s（达到光速 96%）

RDMA 的应用栈

graph TB
  APP[应用]
  APP --> CHOICE{选择}
  CHOICE --> VERBS[Verbs<br/>底层 API]
  CHOICE --> MPI[MPI<br/>HPC 标准]
  CHOICE --> NCCL[NCCL<br/>AI 集合通信]
  CHOICE --> UCX[UCX<br/>统一通信层]
  CHOICE --> NVMEoF[NVMe-oF<br/>存储]
  CHOICE --> GPFS[GPFS / Lustre<br/>文件系统]
  
  VERBS --> HW[HCA]
  MPI --> VERBS
  NCCL --> VERBS
  UCX --> VERBS
  NVMEoF --> VERBS
  GPFS --> VERBS

直接写 verbs 的应用很少——大部分通过 MPI / NCCL / UCX 这些上层库。

MPI（Message Passing Interface）

1
2
3
4
5
HPC 经典通信库：
  - 1990s 起标准化
  - OpenMPI / MPICH / Intel MPI
  - 集合操作：AllReduce / AllGather / Broadcast 等
  - 后端可对接 IB / RoCE / TCP

NCCL（NVIDIA Collective）

1
2
3
4
5
专为 GPU 集群优化：
  - 拓扑感知（NVLink / IB / PCIe）
  - GPU-to-GPU 直接通信
  - PyTorch / JAX 默认后端
  - 类似版本：RCCL（AMD）、HCCL（华为）

UCX（Unified Communication X）

1
2
3
4
HPC 跨厂家通信抽象层：
  - 自动选最佳传输路径（IB / RoCE / SHM / TCP）
  - MPI 后端常用
  - OpenMPI 默认 UCX

RDMA 的”老坑”

坑 1：MTU 不一致导致丢包

1
2
3
# IB 标准 MTU 4096，但端到端必须一致
ibportstate <port> mtu <2048|4096>
sysctl -w net.core.rmem_max=...

坑 2：QP 数量爆炸

1
2
3
4
5
6
n 节点全互联：n*(n-1)/2 个 RC QP
1000 节点：50 万 QP
每 QP HCA 需要资源 → 内存爆炸

→ 用 DCT（Dynamic Connect）或 XRC 减少 QP
→ NCCL 自动处理

坑 3：RoCE PFC storm

1
2
3
4
5
6
7
PFC 配置错 → 整个网络 PAUSE 蔓延
 → 全网吞吐崩
 
诊断：
  - 看交换机 PFC 计数器异常
  - 看 mlxlink / ibstat
  - 看 NCCL 日志

坑 4：内存注册慢

1
2
3
ibv_reg_mr 注册大内存：耗时
   → ODP（On-Demand Paging）让网卡懒注册
   → 或者预先注册大块内存重用

坑 5：MR 限制

1
2
3
HCA 单卡能注册的 MR 数和大小有限
   → 大模型训练时 MR 数过多 → 注册失败
   → 用 MR cache / 大段注册

verbs 编程的几个调试命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# HCA 列表
ibv_devices
ibv_devinfo
ibv_devinfo mlx5_0

# 端口状态
ibstat
ibstatus

# 性能测试
ib_send_bw -d mlx5_0 server_ip
ib_send_lat -d mlx5_0 server_ip
ib_write_bw -d mlx5_0 -F server_ip
ib_read_bw -d mlx5_0 -F server_ip

# 跑 RoCE（指定 GID）
ib_send_bw -d mlx5_0 -i 1 -x 3 server_ip   # GID index 3 通常是 RoCE v2

# 路径追踪
ibtracert <src_lid> <dst_lid>

# QP 状态
ibv_devinfo -v
mlnx_perf -i mlx5_0

调优清单

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 1. 中断绑定到 CPU NUMA 同侧
echo 0 > /proc/irq/<irq>/smp_affinity_list

# 2. NUMA 内分配内存
numactl --membind=0 ./app

# 3. 大页内存（减少 TLB miss）
echo 2048 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# 4. CPU 高性能模式
cpupower frequency-set -g performance

# 5. 关闭 C-State
cpupower idle-set -D 0

# 6. PCIe ACS 关闭（GPUDirect 必需）
setpci -s <BDF> ECAP_ACS+0x6.w=0:1f0

# 7. ConnectX 性能配置
mlxconfig -d <DEV> set PCI_WR_ORDERING=1
mlxconfig -d <DEV> set CQE_COMPRESSION=1

RoCEv2 与 InfiniBand 深度对比

表格看过便知其一，不知其二。咱今日将两者的骨子里讲透。

可靠性机制的根本差异

InfiniBand 的可靠性刻进了物理层：每条链路都有 credit-based 流控，发送方只在收到对端”空位”信号后才发包，从根本上杜绝链路级丢包。整个 IB 网络是一张天然无损的网。

RoCEv2 跑在以太网上，以太网没有 credit，靠三件套补救：

1
2
3
PFC（Priority Flow Control）：  链路级 PAUSE 帧，告诉上游"停一停"
ECN（Explicit Congestion Notification）：路由器标记 CE 位，端到端感知拥塞
DCQCN：算法，把 ECN 标记转化为发送速率调节

三者缺一不可——PFC 防止瞬时丢包，ECN 提供信号，DCQCN 做反应。光有 PFC 会引发”PFC storm”，光有 ECN 反应太慢——组合才是无损以太网的本质。

DCQCN 拥塞控制详解

DCQCN（Data Center Quantized Congestion Notification）是 Microsoft 与 Mellanox 联合设计、现已成为 RoCE 事实标准的拥塞控制算法。

graph LR
  TX[发送端 NIC] -->|数据流| SW[交换机]
  SW -->|ECN 标记 CE bit| RX[接收端 NIC]
  RX -->|CNP 包 反向路径| TX
  TX -->|降速 α 算法| TX2[降速后继续发送]

工作流程：

1
2
3
4
5
6
1. 交换机队列超过阈值 → 在数据包 IP 头打上 ECN CE 标记
2. 接收端 NIC 发现 CE 标记 → 每 N 个包发一个 CNP（Congestion Notification Packet）
3. 发送端收到 CNP → 触发速率降低
4. 速率调节公式：
   - 降速：rate = rate * (1 - α/2)，α 在 0~1 间随拥塞程度增加
   - 恢复：每过 T 时间没有 CNP，速率线性恢复 → 若再没有 CNP，指数恢复

调优关键参数：

1
2
3
4
5
6
7
8
9
10
# ECN 阈值（交换机侧，以 Broadcom SONiC 为例）
# 队列超过此阈值开始标记 CE
config qos wred Kmin=50000 Kmax=100000  # bytes

# CNP 发送间隔（接收端 NIC）
mlxconfig -d <dev> set CNP_DSCP_P0=48
mlxconfig -d <dev> set RATE_REDUCE_MONITOR_PERIOD=4  # 微秒

# 降速因子（发送端）
mlxconfig -d <dev> set INITIAL_ALPHA_VALUE=1023  # 最大值=1023

DCQCN vs TCP CUBIC/BBR：

1
2
3
4
5
相同点：都基于拥塞信号降速 + 无拥塞时恢复
不同点：
  - DCQCN 运行在 NIC 硬件，μs 级反应
  - TCP 拥塞控制在内核软件，ms 级反应
  - DCQCN 靠 ECN 信号（无丢包），TCP 传统靠丢包

这就是为何 RDMA 能做到 2-5 μs 端到端延迟——连拥塞响应都是硬件完成的。

PFC 风暴的根源与防治

PFC 是把双刃剑：配得好是护身符，配错了是整网熔断器。

graph TB
  A[Node A 拥塞] -->|发 PAUSE 帧| B[上游交换机]
  B -->|传播 PAUSE| C[更上游交换机]
  C -->|蔓延| D[整网停摆]

防治：

1
2
3
4
5
6
1. 只对 RDMA 流量（QoS 3 或 4）开启 PFC，其余 traffic 走普通以太网
2. 设置 PFC watchdog：检测到 PAUSE 持续超时，自动切断，避免死锁
3. 合理设置 buffer 阈值：
   - 太小 → PFC 频繁触发，影响吞吐
   - 太大 → 拥塞传播慢，延迟升高
4. 用 Jericho3-AI / Spectrum-X 等带 adaptive routing 的芯片减少热点

AI 推理场景：prefill/decode 解耦的流量不对称

训练集群的流量模式是”对称的全员合唱”——AllReduce/AllGather，人人都有份，带宽均匀。推理集群不同，尤其是近年流行的 prefill/decode disaggregation（预填充与解码分离）架构，流量模式要复杂得多。咱今日细说。

推理的两阶段

graph LR
  P[Prefill 节点群<br/>计算密集型<br/>处理 prompt] -->|KV Cache 迁移<br/>P2P 单向大流| D[Decode 节点群<br/>内存带宽密集型<br/>自回归生成]
  D -->|token 输出| OUT[用户]
维度 Prefill 阶段 Decode 阶段
计算特征 计算密集，矩阵乘法 内存带宽密集，逐 token 生成
流量模式 类 All-to-All（batch 内） P2P 单向传输（KV Cache 迁移）
流量特征 较均匀，批次式 突发性强，不对称
延迟要求 吞吐优先 低延迟优先（TTFT/TPOT）
通信对象 Prefill 节点互相通信 Prefill → Decode 单向

KV Cache 迁移为何是难题

1
2
3
4
5
6
7
8
9
10
一次推理的 KV Cache 大小（以 LLaMA-3 70B 为例）：
  - 单层 KV：2 × (seq_len × head_dim × heads) × 2 bytes
  - 32 层，seq_len=4096，head_dim=128，heads=8
  → 约 2 GB 每次请求

问题：
  - Prefill 完成后需立即将 KV Cache 推送到 Decode 节点
  - 如果网络延迟高 → 用户感受到的 TTFT（First Token Time）高
  - Decode 节点要等 KV Cache 到位才能开始生成
  - 多个 Prefill 并发向同一批 Decode 节点发送 → 突发拥塞

与训练流量的对比

1
2
3
4
5
6
7
8
9
10
训练 AllReduce（对称）：
  节点 0 <--> 节点 1 <--> 节点 2 <--> ... <--> 节点 N
  双向带宽均等，持续且周期性
  网络设计：高吞吐 + 无损

推理 P2P（不对称）：
  Prefill 节点 --> --> --> Decode 节点（单向大流）
  Decode 节点 --> Prefill 节点（极少量 token 反馈）
  流量比例可达 100:1（Prefill 向 Decode 方向）
  网络设计：低延迟 + 应对突发

Jericho3-AI 在推理流量优化上的方向

Broadcom Jericho3-AI 是专为 AI 后端网络设计的深缓冲路由芯片。在推理流量场景下，其主要优化方向包括：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1. 深缓冲（Deep Buffer）：
   - Jericho 系列标志性特征
   - 对突发性 KV Cache P2P 传输有天然吸收能力
   - 避免 ECN 过早触发、避免 PFC 风暴

2. Adaptive Routing：
   - 实时感知链路负载，动态选路
   - 对不均匀的 Prefill→Decode 流量分布更友好
   - 避免静态 ECMP 的"大象流"拥塞

3. QoS 精细化：
   - 为 KV Cache 迁移（延迟敏感）分配高优先级队列
   - 允许其他后台训练流量降级

4. 流量隔离：
   - Scale-Up 层（节点内 GPU 互联）和 Scale-Out 层（跨节点）物理/逻辑隔离
   - 防止推理 P2P 流量干扰训练 AllReduce 流量

注：Jericho3-AI 针对 prefill/decode disaggregation 的具体专项优化机制，博通在 2026-06 的技术访谈中未提供详细披露，上述为基于已知架构特性的推断。

实践建议

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
推理集群网络设计要点：

1. 将 Prefill 节点和 Decode 节点规划在同一 Spine 平面下
   → 减少 KV Cache 迁移跳数

2. KV Cache 迁移流量走独立 QoS 优先级
   → 保证 TTFT 延迟稳定

3. 选用支持 Adaptive Routing 的交换机（Jericho3-AI / Spectrum-X）
   → 应对突发不均匀流量

4. 集群规模参考：
   - <300 卡推理：RoCEv2 + 100/200G 已绰绰有余
   - 300-1000 卡推理：考虑 RoCEv2 + Jericho3-AI 深缓冲
   - 1000 卡 + 训推混部：InfiniBand 依然是最省心的选择

选 IB 还是 RoCE？

场景 推荐 原因
万卡 AI 训练 InfiniBand 默认稳定 + SHARP
千卡 AI 训练 IB / RoCE 都行 两者差距不大
中小集群 RoCE 便宜 + 以太网兼容
云存储后端 RoCE 与现有以太网融合
HPC 计算 InfiniBand 默认
跨厂家集群 RoCE IB 厂家锁定

一些实战经验

1
2
3
4
5
6
7
8
9
10
11
12
13
1. 万卡级训练：     IB + ConnectX-7/8 + Quantum-2
2. 千卡级训练：     IB 或 RoCE 都行
3. 300+ 卡推理：    RoCE 100/200G 充分
4. 单租户私有集群： IB 部署便利
5. 云租户：         RoCE 与以太网共存

调优时间预算：
  IB：      1-2 周配置 + 1 周调优
  RoCE：   1-2 月配置 + 持续调优 PFC/ECN
  
故障排查：
  IB：      工具齐全（ibtools 套件）
  RoCE：   要拼以太网工具 + IB 工具

小结

  • RDMA 三大特性：kernel bypass、zero copy、direct memory access
  • IB / RoCE / iWARP 三种实现，AI 集群只用前两个
  • verbs API 暴露 QP / MR / CQ / WR 等概念
  • GPUDirect RDMA 让 GPU 跨节点直接通信
  • IB 自带子网管理 + credit 流控，RoCE 要靠 PFC/ECN
  • DCQCN 是 RoCE 无损以太网的核心算法：ECN 标记 → CNP → 速率调节，全硬件实现
  • prefill/decode disaggregation 带来流量不对称，Jericho3-AI 的深缓冲 + adaptive routing 是应对之道
  • NCCL / MPI / UCX 是上层最常用的 RDMA 应用接口
  • 调优要从 NUMA、大页、中断绑定全面着手

下一篇讲数据中心拓扑——Spine-Leaf、Fat-Tree、Dragonfly。

内容深度由贤狼赫萝于 2026-06-15 增补，引用来源：OCP 2025/2026 幻灯片、Broadcom 技术访谈。