AI 集群网络 —— InfiniBand、RoCE 与万卡训练

NVL72 内 72 GPU 全互联只是开始——大模型训练要几千甚至几万 GPU。这层网络叫 scale-out。本文专题讲。本章作为第六章网卡的”前传”。

一张全景

graph TB
  GPU[GPU SM]
  HBM[HBM 显存]
  NVL[NVLink/NVSwitch<br/>72-576 GPU 紧耦合]
  NIC[RDMA 网卡<br/>400G/800G InfiniBand 或 RoCE]
  SW[Spine/Leaf 交换机<br/>整集群]
  
  GPU --- HBM
  GPU --- NVL
  NVL -.- NIC
  NIC --- SW
  SW --- SW

每跨一层带宽掉 5-10×、延迟涨 5-10×——AI 集群网络设计就是想方设法让最重的通信留在低层。

为什么以太网 TCP 不够

传统数据中心的”以太网 + TCP”路径：

1
2
3

应用 → socket → kernel TCP → 网卡驱动 → 网卡 → 链路
延迟：5-50 μs（同机房）
CPU 占用：高（每包都过 kernel）

AI 训练每步要做 AllReduce——成千上万次集合通信，要求微秒级延迟和 CPU 零开销。TCP 完全不行。

RDMA（Remote Direct Memory Access） 就是为这个而生：

graph LR
  A[GPU A 显存] -.- B[GPU B 显存]
  
  A --> N1[网卡 A]
  N1 --> N2[网卡 B]
  N2 --> B
  
  CPU[CPU] -.-> X[不参与<br/>kernel bypass]

RDMA 让网卡直接读写远端显存——不过 CPU、不过 kernel、零拷贝。

RDMA 的两条物理路线

graph TB
  RDMA[RDMA]
  RDMA --> IB[InfiniBand<br/>专用网卡 + 专用交换机<br/>NVIDIA Mellanox 主导]
  RDMA --> ROCE[RoCE<br/>RDMA over Converged Ethernet<br/>跑在普通以太网上]
  RDMA --> IWARP[iWARP<br/>RDMA over TCP<br/>已边缘化]

InfiniBand（IB）

历史最悠久——2000 年开始用，原本是 HPC 专用：

特点：
  - 物理层就是 IB（专用线缆 + 专用交换机）
  - 端到端 credit-based 流控（无丢包）
  - 微秒级延迟（机内 1-2 μs，跨柜 3-5 μs）
  - 单口 200/400/800 Gbps
  
代次：
  EDR (100G) → HDR (200G) → NDR (400G) → XDR (800G)
  
NVIDIA 收购 Mellanox（2019）后，IB 几乎是 NVIDIA 独家

InfiniBand 是 NVIDIA AI 集群的”默认”网络。

RoCE v2

把 RDMA 协议跑在普通以太网上：

RoCE v1：链路层 RDMA，只能同 LAN
RoCE v2：UDP/IP 上 RDMA，可路由
        现在大家说 RoCE 默认 v2

特点：
  - 用普通 100G/400G 以太网交换机
  - 价格比 IB 低 30-40%
  - 互操作性好（多厂家可选）
  - 延迟略高于 IB（约 1.5-2 μs 差距）

挑战：
  - 以太网默认丢包，要靠 PFC + ECN 做"无损"
  - PFC 调优极其复杂
  - 大集群难于诊断

IB vs RoCE 实际选择

NVIDIA SuperPOD（NVIDIA 推荐）：     默认 IB
xAI Colossus（10 万 H100）：         IB
Meta 24K H100 集群：                 RoCE（自研以太网栈）
微软 Azure：                         混合（IB + RoCE）
腾讯 / 阿里 大模型集群：             IB 主流
字节 / 百度：                        RoCE 较多

选 IB 还是 RoCE 是 AI 集群的世纪之争：

IB 优势：    生态成熟，NCCL 调优默认好用
            交换机自带高级特性（adaptive routing）
            
RoCE 优势：  便宜
            和已有以太网网络融合
            供应商多元（Broadcom、Cisco、Arista 等）
            
共识：       1000 卡以下：IB / RoCE 都行
            1万卡以上：差距开始显现，IB 更稳

“轨道”拓扑（Rail-Optimized）

AI 集群最大的特殊之处——Rail（轨道）拓扑。

普通 Fat-Tree

graph TB
  S1[Spine 1] --- L1[Leaf 1] & L2[Leaf 2] & L3[Leaf 3] & L4[Leaf 4]
  S2[Spine 2] --- L1 & L2 & L3 & L4
  S3[Spine 3] --- L1 & L2 & L3 & L4
  S4[Spine 4] --- L1 & L2 & L3 & L4
  
  L1 --- N1[节点 1<br/>8 GPU]
  L2 --- N2[节点 2<br/>8 GPU]

普通 Fat-Tree 每节点 1-2 张网卡——8 GPU 共享 1 张 400G 网卡。

Rail 拓扑：每 GPU 一张网卡

graph TB
  subgraph Rail0["Rail 0"]
    L0[Leaf-0 交换机] --- G00[节点 1 GPU 0] & G10[节点 2 GPU 0]
  end
  subgraph Rail1["Rail 1"]
    L1[Leaf-1 交换机] --- G01[节点 1 GPU 1] & G11[节点 2 GPU 1]
  end
  subgraph RailN["Rail 2-7"]
    LN[Leaf-2..7]
  end

8 GPU/节点 → 8 个 Rail，每 Rail 一张 IB 卡。同 Rank 的 GPU（GPU 0）跨节点直接走自己的 Rail——不和别的 GPU 抢带宽。

Rail 模型：
  GPU 0 永远经 Rail 0 网卡 + Leaf 0
  GPU 7 永远经 Rail 7 网卡 + Leaf 7
  
跨 Rail 通信：要走 Spine（少见）
同 Rail 通信：1 跳到达

为什么 Rail 适合 AI

AllReduce 时：每个 GPU 和 N 个对应 GPU 同步
  → 同 Rank 的 GPU 直接 Rail 0 内 AllReduce
  → 不和别的 GPU 抢带宽
  → 8 个 Rail 并行进行

Tensor Parallel：留在节点内 NVLink
Data Parallel：走 Rail（同 rank GPU 之间）
Pipeline Parallel：跨节点点对点

NVIDIA SuperPOD 设计指南就把 Rail-Optimized 作为默认。

几种典型集群拓扑

NVIDIA SuperPOD（256 H100）

4× DGX SuperPOD Scalable Unit：
  每 SU = 32 节点 × 8 GPU = 256 GPU
  Rail-optimized，每节点 8× 400G IB
  + 1-2× 200G IB 用于 storage 和 mgmt
  
Spine：     8× 400G QM9700（NDR 64-port）
Leaf：      32× 400G QM9700
集群：       1024 GPU

xAI Colossus（10 万 H100，2024）

xAI 在孟菲斯部署的全球最大 H100 集群之一：
  100,000× H100
  Rail-optimized + IB 400G
  100% 液冷
  10 万卡 AllReduce 大模型训练
  自研电力（专用变电站 150 MW）

Meta 24K H100 集群（2024）

Meta 公开宣布 24,576 H100 集群：
  RoCE v2 + 自研 Wedge400 交换机
  3 层 Fat-Tree，无收敛
  自研集群管理软件
  Llama 3 训练就在这里

Google Gemini 集群（TPU）

Google 用 TPU v5p / Trillium：
  3D Torus + OCS（光交换）
  非 Fat-Tree（特殊拓扑）
  对 NCCL/AllReduce 直接用 XLA 自管理

NCCL：集合通信的事实标准

graph TB
  PT[PyTorch / JAX / TF]
  PT --> NCCL[NCCL<br/>NVIDIA Collective<br/>Communications Library]
  NCCL --> NVLINK[NVLink<br/>节点内]
  NCCL --> IB[IB / RoCE<br/>跨节点]

NCCL 主要算法：

AllReduce（梯度同步）：     Ring / Tree / NVLS
AllGather：                每 GPU 拼接数据
ReduceScatter：            每 GPU 持有 partial 结果
Broadcast：                单点到多点
P2P Send/Recv：            点对点

NVLink 等价物：             RCCL（AMD）、HCCL（华为）

NCCL 调优要点

# 关键环境变量
export NCCL_DEBUG=INFO              # 看通信信息
export NCCL_IB_DISABLE=0            # 启用 IB（默认）
export NCCL_IB_HCA=mlx5_0,mlx5_1    # 指定 HCA
export NCCL_IB_GID_INDEX=3          # RoCE v2
export NCCL_TOPO_FILE=topo.xml      # 自定义拓扑文件
export NCCL_P2P_LEVEL=NVL           # 节点内 NVLink 优先

# 测试 AllReduce 带宽
all_reduce_perf -b 1G -e 16G -f 2 -g 8
# 看 algbw（算法带宽）和 busbw（总线带宽）

“无损以太网”的复杂

RoCE 跑在以太网上要”无损”——靠两个机制：

PFC（Priority Flow Control）

graph LR
  A[发送端] -->|流量| B[交换机]
  B -->|缓冲快满| A
  A[发送端] -.->|PAUSE| A

队列快满时交换机发 PAUSE 帧让发送方暂停——链路级背压。

PFC 调优坑：

1. PFC storm：环路 PAUSE 导致全网阻塞
2. PFC 不支持多优先级 → 拥塞蔓延
3. 调优 buffer 阈值复杂
4. 不同厂家交换机行为不一致

ECN（Explicit Congestion Notification）

1
2
3

发送方探测 ECN 标记
  → 主动降速
  → 端到端拥塞控制（DCQCN）

PFC + ECN 配合，让 RoCE 在以太网上达到”近 IB”性能——但调优极其复杂。这是为什么 AI 集群运维比一般数据中心难十倍。

Scale-Up vs Scale-Out：分层架构的深层逻辑

OCP 2026 EMEA 峰会的核心议题之一，就是把 AI 集群网络从”一层 IB”彻底拆成三层：

graph TB
  subgraph SU["Scale-Up（紧耦合）"]
    direction TB
    A1[8 - 1024 xPU<br/>12 kW - 1 MW<br/>延迟 ns 级<br/>共享内存语义]
  end
  subgraph SO["Scale-Out（松耦合）"]
    direction TB
    B1[单数据中心<br/>~10 万 xPU<br/>~180 MW<br/>延迟 us 级，消息通信]
  end
  subgraph SA["Scale-Across（跨站点）"]
    direction TB
    C1[多数据中心园区<br/>100 万+ xPU<br/>1+ GW<br/>延迟 ms 级]
  end
  SU -.- SO -.- SA

带宽量级差距（Broadcom 在 OCP 2026 EMEA SUE-T 演讲中给出的园区级估算）：

前提：1M xPU 园区，每 xPU HBM 带宽 ~100 Tb/s，1k xPU/节点

Scale-Up 带宽 / 园区：  14.4 Eb/s
Scale-Out 带宽 / 园区：   1.6 Eb/s
Scale-Across 带宽 / 园区：0.16 Eb/s

结论：Scale-Up 带宽 ≈ Scale-Out + Scale-Across 总和的 8 倍
→ Scale-Up 互联才是整个 AI 基础设施的带宽重心

这个数字解释了为什么 NVLink 5（1.8 TB/s / 卡）和 NVSwitch 要做那么宽——训练时最重的通信根本不出 NVLink 域。

Scale-Up 与 Scale-Out 特性对比

特性	Scale-Up	Scale-Out
主要目标	让多 GPU 像一颗大 GPU	连接数千个节点
内存模型	所有 GPU 共享内存	各节点独立，消息通信
延迟敏感度	极高（ns 级）	耐受（μs 级）
带宽要求	高对分带宽	可扩展带宽
规模	10 - 1000 个节点	100 - 10,000 个节点
拥塞管理	最小超额订阅，确定性	自适应路由，流量工程
训练用途	高带宽对 TP 至关重要	超大 LLM（100-10,000 GPU）可扩展
推理用途	超低延迟是关键	水平扩展支持高 QPS

ESUN：以太网进军 Scale-Up 网络

ESUN（Ethernet Scale-Up Network） 是 OCP 发起的开放以太网 Scale-Up 标准，由 Meta 和 Microsoft 联合主导，参与成员 166 人，ESUN 1.0 规范已于 2026 年正式批准。

为什么需要 ESUN

传统 RDMA NIC 体积太大，无法集成进 xPU 封装。而 Scale-Up 带宽通常是 Scale-Out 的 8-12 倍——这要求极轻量的端点实现。现有方案（UEC、RDMA、TCP）都解决的是更通用、代价更高的问题，不适合 Scale-Up 场景。

Scale-Up 私有小规模网络的特殊性：

1
2
3

有序交付：Scale-Up 域内可期待有序到达
近无损：单跳 + LLR + 流控 → 近乎无丢包
→ 可用更精简的报头 + 更简单的可靠性协议

ESUN 1.0 技术要点

graph LR
  E1[标准以太网<br/>IP 头 20-40B] --> E2[ESUN 扩展头<br/>仅 4B EH]
  E2 --> E3[小包效率大幅提升]

ESUN 4 字节扩展头（EH）字段：

字段	位宽	功能
EH-CoS	3 bit	服务质量（替代 DSCP/802.1p）
EH-ECN	2 bit	显式拥塞通知（持续拥塞的 Fabric 反馈）
Flow Label	16 bit	负载均衡（替代 ECMP）
TTL	4 bit	多跳拓扑支持
Rev/UD/RSVD	余下	版本/用户自定义/保留

ESUN 相较标准以太网的增强：

功能	标准以太网	ESUN
链路级拥塞管理	PFC	PFC + CBFC（基于信用的流控）
Fabric 拥塞反馈	IP based ECN	EH-ECN
流量分类	DSCP, 802.1p	EH-CoS
负载均衡	无 LLR / ECMP	LLR + EH-Flow Label
多跳支持	TTL, IP based ECN	EH-ECN + EH-TTL

咱评：ESUN 干的事不复杂——把以太网的头部做轻、把拥塞控制做对、把链路可靠性做进去。核心是兼容以太网生态（NOS/运维工具/物理层），又补齐 Scale-Up 场景的缺口。以太网的 NOS（SONiC 等）可以直接复用，不需要从零搭。

SUE-T：OCP 的 Scale-Up 传输规范

OCP 进一步在 ESUN 基础上成立 SUE-T（Scale-Up Ethernet Transport）工作组（Broadcom 主导），专门为 xPU 和 NIC 端点制定规范：

SUE-T 解决的问题：
  - 事务打包（Transaction Packing）：优化小事务的以太网包利用率
  - 内存访问方式：Push vs Pull 语义选择
  - 可靠性模型：传输层 vs 逐跳
  - 调度策略：工作保守式打包

设计目标：die 面积和功耗最优
→ 让 xPU 开发者可以把 Scale-Up 互联集成进芯片封装

PCIe Scale-Up 的上限与以太网 Scale-Up 的选择逻辑

随着 AI 集群规模突破 64 卡，Scale-Up 互联方案面临根本性选择：

PCIe Scale-Up 的上限

当前 PCIe Scale-Up 方案（如 PCIe Switch 构建的 Scale-Up 域）：

理论上限：约 64 个加速器（受 PCIe 树形拓扑限制）
实际瓶颈：
  - PCIe 5.0 ×16 双向：128 GB/s
  - 64 GPU 全互联时每 GPU 可用带宽：128 / (64-1) ≈ 2 GB/s（极度稀释）
  - PCIe Switch 延迟：~500 ns - 1 μs
  - PCIe 域内跳数：随规模增加，带宽效率急剧下降

适合场景：
  - 小规模推理集群（8-16 卡）
  - 存量服务器改造（不支持 NVLink 的非 NVIDIA 阵营）
  - 成本优先、延迟容忍的场景

PCIe Scale-Up 64 卡上限成因：

graph TB
  P1[PCIe Switch 层级] --> P2[每层翻倍设备，带宽减半]
  P2 --> P3[64 GPU = 6 层 PCIe Switch]
  P3 --> P4[单 GPU 可用带宽 < 5 GB/s]
  P4 --> P5[Tensor Parallel 效率崩溃]

以太网 Scale-Up（>64 卡）

当规模超过 64 卡，以太网成为首选（非 NVLink 阵营）：

以太网 Scale-Up 优势（>64 xPU）：
  - 高基数交换机（High-Radix）：单台 512 端口，一跳连 512 xPU
  - 多平面叠加：N 个平面 = N× 带宽
  - 物理层成熟：DAC/AOC/光模块成本低
  - NOS 生态：SONiC 直接复用
  - 规模无上限（理论）：通过增加交换机层数扩展

以太网 Scale-Up 挑战（相比 NVLink）：
  - 延迟较高：~500 ns - 2 μs（NVLink 约 700 ns - 1 μs）
  - 需要 LLR + CBFC 保证近无损（ESUN 解决）
  - 内存语义需要额外协议层（UALink / SUE-T 解决）
  - 软件栈仍在建设中

三种方案选择矩阵

场景                    推荐方案
─────────────────────────────────────────
≤ 8 GPU，NVIDIA 阵营    NVLink（NVL8/DGX）
≤ 72 GPU，NVIDIA 阵营   NVLink 5（NVL72）
≤ 144 GPU，NVIDIA 阵营  NVLink 6（NVL144，Rubin）
≤ 576 GPU，NVIDIA 阵营  NVLink 6（NVL576，Kyber）
> 64 GPU，非 NVIDIA      以太网 Scale-Up（ESUN / UALink）
任意规模，跨节点          InfiniBand / RoCE（Scale-Out）

咱要说明：这个矩阵的本质是互联带宽 vs 成本 vs 生态的三角权衡。NVIDIA NVLink 在带宽和延迟上领先，但绑定 NVIDIA；以太网方案成本低、生态开放，但标准仍在成熟中；PCIe 方案最通用，但超过 64 卡后效率急剧下滑。

集群网络的”故障” reality

万卡集群每天有 GPU 故障、网络抖动、链路 flap：

xAI Colossus 10 万卡：
  每天 GPU 故障：~50 个（百万分之几故障率 × 万 × 365天）
  每天 IB 链路 flap：~5-10 个
  每天 PSU/风扇/电源问题：~10 个
  
软件层面：
  PyTorch 必须支持 fault-tolerant training
  Checkpoint 频率要够高（每小时）
  自动 GPU 故障隔离 + 重启
  自动网络拓扑发现（拓扑变了 NCCL 重建路径）

网卡的代次

ConnectX-5（2017）：     100G EDR
ConnectX-6（2020）：     200G HDR
ConnectX-7（2022）：     400G NDR
ConnectX-8（2024）：     800G XDR
BlueField DPU：         网卡 + ARM CPU + 加速器（智能网卡）

NVIDIA 不只是卖 GPU——网卡的”墙内市场”也是它的：

graph TB
  NV[NVIDIA AI 集群]
  NV --> GPU[GPU: H100/B200]
  NV --> NIC[网卡: ConnectX-7/8 + BlueField]
  NV --> SW[交换机: Quantum-2 NDR / Spectrum]
  NV --> CABLE[线缆: 光模块 / DAC / AOC]
  NV --> SW2[NVSwitch + NVLink Switch]

整套 AI 集群基础设施都是 NVIDIA 一家供货——这是 NVIDIA 比 AMD 强的真正护城河。

为什么 800G 网络没让训练更快

每代 IB 带宽翻倍——但 AllReduce 时间没线性下降，因为：

1. 网卡 → GPU 间还要走 PCIe（5.0 ×16 = 64 GB/s = 512 Gbps）
   400G 网卡已经接近 PCIe 5.0 ×16 上限
   800G 实际"打不满"
2. NCCL 算法的复杂度（环 vs 树）
3. 集合通信的同步等待时间
4. 大模型梯度量级和带宽不成比例

PCIe 6.0 / NVLink 5 是配套必须升级的——B200 就是这么设计。

国产 AI 集群网络

鹊信（Galaxlink，华为）

华为 Atlas 集群的 RDMA 网络：

基于以太网（融合标准）
端到端微秒级延迟
配套 HCCL（NCCL 替代）
万卡级集群已上线

国产 RDMA 网卡

1
2
3

中际旭创：800G 光模块出货
新华三 / 锐捷：以太网交换机
国产 IB / RoCE 网卡：仍较弱，主要 ConnectX 替代

待补充：国产 AI 集群网络（万卡级）部署案例和性能数据。

一些诊断命令

# IB 网卡状态
ibstat
ibstatus
ibv_devinfo
mlxlink                       # MLX 网卡链路诊断

# RDMA 测试
ib_send_bw -d mlx5_0 -i 1 server_ip
ib_read_bw -d mlx5_0 -i 1 server_ip
ib_send_lat                   # 延迟测试

# IB 拓扑
ibnetdiscover                 # 全网拓扑发现
ibtracert <src_lid> <dst_lid> # 路径追踪

# RoCE 调优
ethtool -i eth0              # 网卡驱动
mlxconfig -d /dev/mst/mt4123_pciconf0 q
mlnx_qos -i eth0             # PFC/ECN 配置

# NCCL 性能
nccl-tests/all_reduce_perf -b 1G -e 16G -f 2 -g 8

# 监控
perfquery                    # IB 计数器
sar -n DEV 1                 # 网卡流量

一张总结：AI 集群网络栈

graph TB
  L1[GPU SM<br/>shared mem TB/s]
  L2[GPU 内 HBM<br/>3-8 TB/s]
  L3[NVLink 节点内<br/>1.8 TB/s, 700 ns]
  L4[NVL72 机柜<br/>72 GPU, 1 us]
  L5[InfiniBand/RoCE<br/>400-800 G, 3-5 us]
  L6[跨数据中心<br/>WAN, 10-100 ms]
  L1 --> L2 --> L3 --> L4 --> L5 --> L6

AI 训练集群”软件栈”必须理解每一层带宽和延迟——只有把通信安排在合适的层，才能跑出好的 MFU。

经验数字

H100 节点内 NVLink AllReduce：     ~1500 GB/s busbw
H100 跨节点 IB AllReduce（rail）：  ~360 GB/s busbw（400G × 8）
H100 跨节点 RoCE（同 IB）：         ~340 GB/s（PFC OK 时）
万卡集群 AllReduce 延迟：          1-3 ms（梯度大小依赖）

PCIe 5.0 ×16 端到端：             50-60 GB/s（理论 64）
ConnectX-7 单口 400G：           ~50 GB/s

小结

AI 集群分两层：scale-up（NVLink，紧耦合）+ scale-out（IB/RoCE，松耦合）
IB 默认稳定，RoCE 价格优但调优难
Rail-Optimized 是 AI 集群标准拓扑
NCCL 是事实标准的集合通信库
万卡集群每天有数十个故障——容错训练是必须能力
NVIDIA 的网卡 + 交换机 + GPU “全栈”是真正护城河

下一篇是第五章收口——GPU 选型和小结。

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

05-GPU与AI

#InfiniBand #RoCE #RDMA #集群网络

GPU 选型实战与第五章小结上一篇

AI 训练 vs 推理 —— 硬件视角的根本差异下一篇