CS 知识库

简体中文

English

简体中文

English

主题

集群网络和通信 ​

1.5.1 为什么网络如此重要？ ​

在分布式训练中，网络是连接各个 GPU 的“高速公路”。如果高速公路太窄，即使 GPU 再快，也会被数据传输拖慢。

网络带宽对训练的影响 ​

训练一个 GPT-3 级别模型的总时间可以拆解为：

latex
总时间 = 计算时间 + 通信时间 + 空闲等待

不同网络条件下，计算和通信的占比可能完全不同：

场景计算时间通信时间说明
理想情况（无限带宽）100%0%GPU 几乎一直在计算
实际情况（有限带宽）60%40%通信已经显著影响训练效率
糟糕情况（带宽瓶颈）25%75%GPU 大量时间都在等待数据

网络越慢，GPU 越容易空转；在大规模训练中，网络往往决定集群上限。

1.5.2 GPU 互联技术对比 ​

单机内部互联 ​

技术带宽延迟用途特点
PCIe 4.0 x1632 GB/s~1 μsCPU-GPU、GPU-存储
PCIe 5.0 x1664 GB/s~1 μs新一代服务器带宽翻倍
NVLink 3.050 GB/s / 链路~0.5 μsGPU-GPU专用高速互联
NVLink 4.050 GB/s / 链路~0.5 μsH100 GPU 互联支持最多 18 条链路
NVSwitch900 GB/s（全互联）~0.5 μs多 GPU 全互联无阻塞交换

NVSwitch 架构 ​

NVSwitch 用于实现多 GPU 之间的高带宽全互联。

latex
              ┌─────────────┐
              │  NVSwitch   │
              │  交换芯片   │
              └──────┬──────┘
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
      GPU 0 ←────→  GPU 1 ←────→  GPU 2
        ▲             ▲             ▲
        │             │             │
      GPU 3 ←────→  GPU 4 ←────→  GPU 5
        ▲             ▲             ▲
        │             │             │
      GPU 6 ←────→  GPU 7 ←────→  GPU 8

特点：

  • 任意两个 GPU 之间都可以高速互联；
  • 带宽更均衡，减少通信竞争（无竞争）；
  • DGX A100：6 个NVSwitch 连接 8 个 GPU，总带宽可达 600 GB/s；
  • DGX H100：4 个NVSwitch 连接 8 个 GPU， 总带宽可达 900 GB/s。

1.5.3 跨节点网络技术 ​

InfiniBand（IB） ​

InfiniBand 是高性能计算（HPC）领域常用的高速网络，也是 AI 训练集群的首选网络之一。

典型配置包括：

  • 每个节点配备 1–2 张 ConnectX-7 IB 网卡；
  • 单卡带宽可达 400 Gbps；
  • 网络拓扑通常采用 或 ；
  • 端到端延迟通常在 1–2 μs 级别。

InfiniBand 演进 ​

版本单链路带宽常见配置总带宽发布时间
IB FDR14 Gbps4x56 Gbps2011
IB EDR25 Gbps4x100 Gbps2014
IB HDR50 Gbps4x200 Gbps2018
IB NDR100 Gbps4x400 Gbps2022
IB XDR200 Gbps4x800 Gbps2024

RDMA（Remote Direct Memory Access） ​

RDMA 是 InfiniBand 的核心技术，允许一台机器直接访问另一台机器的内存，无需 CPU 介入。

传统 TCP/IP 通信路径：

latex
应用层 → 内核层 → 网卡驱动 → 网卡 → 网络链路
        ↑ CPU 拷贝 / CPU 处理 ↑

RDMA 通信路径：

latex
应用层 ───────────────→ 应用层
   │                      ↑
   └────→ 网卡硬件处理 ───┘
        零拷贝，低延迟

RDMA 的优势：

  • 零拷贝：数据直接从应用内存到网卡；
  • 内核旁路：应用可以直接操作网卡，减少系统调用；
  • CPU 卸载：通信由网卡处理，CPU 专注于计算。

RoCE（RDMA over Converged Ethernet） ​

，成本通常低于 InfiniBand。
特性InfiniBandRoCEv2
网络类型专用网络标准以太网
是否需要特殊交换机是否，但需支持 PFC / ECN
性能最优接近 IB
成本高中等
兼容性专用生态与以太网兼容

RoCEv2（RDMA over Converged Ethernet version 2） 就是把 InfiniBand 的 RDMA 语义（零拷贝、内核旁路、直接内存访问）打包进 UDP/IP 数据包里，让它能在标准以太网上路由传输，从而以远低于 InfiniBand 的成本获得接近 RDMA 的性能。

为什么需要 RoCEv2？ ​

传统 TCP/IP 收发数据的路径是这样的：

plain
App → Socket Buffer → Kernel TCP Stack → NIC → 线路 → NIC → Kernel TCP Stack → Socket Buffer → App

每一步都有 CPU 参与 + 多次内存拷贝，延迟在几十微秒级，CPU 占用也不低。

RDMA 的做法是：数据从发送方内存 直接 DMA 搬运 到接收方内存，绕过内核、绕过 CPU 数据路径，延迟压到微秒级。

但 RDMA 最初是为 InfiniBand 设计的——需要专用网卡、专用交换机，成本高、生态封闭。

RoCEv2 的答案：保留 RDMA 的传输语义，但把载体从 IB 链路层换成大家熟悉的 UDP/IP over Ethernet，让它能跑在普通数据中心以太网上。

协议栈长什么样？ ​

plain
┌─────────────────────────────┐
│   RDMA Transport (IB Verbs) │  ← 读写语义、QP、完成队列……
├─────────────────────────────┤
│         UDP                 │  ← 目的端口 4791（RoCEv2 保留）
├─────────────────────────────┤
│         IP                  │  ← 可路由！跨子网没问题
├─────────────────────────────┤
│   Ethernet (L2)             │  ← 标准帧格式，Ethertype 0x8915
└─────────────────────────────┘

关键区别：

版本层级能否跨路由
RoCE v1L2（以太网帧）❌ 同一广播域内
RoCE v2L3（UDP/IP）✅ 可被标准 IP 路由器转发

所以现代部署里 几乎只用 v2。

核心挑战：以太网是"有损"的，RDMA 怕丢包 ​

这是 RoCEv2 最微妙也最关键的一点。

InfiniBand 天生是基于信用（credit-based）的无损链路——缓冲区满了就直接反压源头，永远不会丢包。

以太网默认是尽力而为（best-effort）——缓冲区满了就 drop，而 RDMA 遇到丢包的恢复代价极其惨烈（超时重传 → 延迟飙升）。

所以要让 RoCEv2 跑得好，必须在以太网上人为构建一个无损环境，靠两大机制配合：

① PFC（Priority Flow Control，IEEE 802.1Qbb）——链路层防丢包

plain
发送方 → [交换机 buffer 快满] → 交换机发 PAUSE 帧 → 发送方停发（仅该优先级队列）
  • 按优先级（8个优先级队列）分别暂停，不影响其他流量
  • 但 PFC 有个隐患：反压会向上游传播，配置不当可能引发 PFC storm / 队头阻塞

② ECN（Explicit Congestion Notification）+ DCQCN —— 网络层提前减速

plain
交换机发现队列超过阈值 → 打上 ECN 标记 → 接收方 NIC 发 CNP → 发送方 NIC 降速
  • DCQCN（Data Center Quantized Congestion Notification）是 RoCEv2 事实上的拥塞控制算法：乘性降速 + 加性回升，在缓冲区满到丢包之前就把发送速率压下来

实践中：ECN/DCQCN 做主力调速，PFC 做兜底防丢包。AI 集群通常把 RDMA 流量映射到独立优先级（如 Prio 5），与其他 TCP 流量隔离。

性能到底怎样？ ​

指标InfiniBandRoCEv2（调优良好）备注
端到端延迟~1-2 μs~2-5 μs（典型）/ ~7-10 μs（未精细调优）IB 天然更低更稳
带宽800 Gbps/port800 Gbps/port硬件代际同步
尾延迟确定性极好（集成流控）依赖调优质量调不好会有 spikes
硬件成本高（~1x 基准）低（约 1/3）以太网生态的规模经济
生态NVIDIA 主导（封闭）多厂商开放Broadcom / Intel / NVIDIA RNIC 都支持

实际大厂案例：Meta 的 AI Research Supercluster、Microsoft Azure NDv4/NDv5 都跑 RoCEv2，规模上千张 GPU。

1.5.4 NCCL 集合通信库 ​

（NVIDIA Collective Communications Library）是 NVIDIA 提供的多 GPU 通信库，是分布式训练的基石。

NCCL 核心操作 ​

操作作用常见场景
AllReduce多个 GPU 的数据求和 / 平均，并所有 GPU数据并行梯度同步
AllGather收集所有 GPU 的数据，并让张量并行、参数聚合
ReduceScatter先 Reduce，再将结果切分给不同 GPUZeRO、张量并行
Broadcast从一个 GPU 向所有 GPU 广播数据参数初始化
Reduce多个 GPU 汇总到一个 root GPU指标统计、聚合计算

NCCL AllReduce 算法：

Ring AllReduce ​

Ring AllReduce（环形算法） 分为两个阶段：

  1. Scatter-Reduce：每个 GPU 获得部分规约结果；
latex
GPU 0 → GPU 1 → GPU 2 → GPU 3 → GPU 0
  1. AllGather：将完整结果广播给所有 GPU。

时间复杂度：

latex
2 × (N - 1) / N × 数据量 / 带宽

其中 N 是 GPU 数量。

Tree AllReduce ​

Tree AllReduce 先从叶子节点向根节点聚合，再从根节点向叶子节点广播。

算法优点缺点适用场景
Ring AllReduce带宽利用率高延迟相对高大数据量通信
Tree AllReduce延迟低带宽利用率不如 Ring小规模数据、低延迟场景

NCCL 性能调优示例 ​

python
import os

# 1. 选择 AllReduce 算法
# TREE: 树形算法，延迟低
# RING: 环形算法，带宽利用率高
# COLLNET: 使用 SHARP 交换机卸载
os.environ['NCCL_ALGO'] = 'RING'

# 2. 设置缓冲区大小
os.environ['NCCL_BUFFSIZE'] = '2097152'  # 2MB

# 3. 启用网络插件配置
os.environ['NCCL_NET_PLUGIN'] = 'none'

# 4. 调试模式
os.environ['NCCL_DEBUG'] = 'INFO'
os.environ['NCCL_DEBUG_SUBSYS'] = 'ALL'

# 5. 指定 IB 网卡
os.environ['NCCL_IB_HCA'] = 'mlx5_0,mlx5_1'

# 6. 启用 P2P 和 IB
os.environ['NCCL_P2P_DISABLE'] = '0'
os.environ['NCCL_IB_DISABLE'] = '0'

1.5.5 网络拓扑设计 ​

Fat-Tree（胖树）拓扑 ​

Fat-Tree 是常见的数据中心和 AI 集群网络拓扑。

特点：

  • 上下行带宽可以做到 1:1；
  • 可实现无阻塞网络；
  • 缺点是核心层交换机数量多，成本较高。

3D Torus（3D 环面）拓扑 ​

3D Torus 中，每个节点在 x、y、z 三个方向都与邻居相连，形成环形结构。

维度说明
连接方式每个节点连接 6 个邻居：+x、-x、+y、-y、+z、-z
优点交换机数量少、成本低、可扩展性好、适合 AllReduce 等集合通信
缺点非最短路径可能拥塞，需要精心设计通信模式
代表系统Google TPU Pod、NVIDIA DGX SuperPOD

小结 ​

本节介绍了 AI 集群中的网络和通信技术：

  • 单机内部依赖 PCIe、NVLink、NVSwitch；
  • 跨节点通信常用 InfiniBand、RoCE 和 RDMA；
  • NCCL 是多 GPU 集合通信的核心库；
  • 网络拓扑会显著影响训练效率和可扩展性。

在大规模 AI 训练中，网络不是配角，而是决定 GPU 集群是否能真正跑满的关键基础设施。

用心记录，持续成长

Copyright © 2026 hswsp