96 lines
6.5 KiB
Markdown
96 lines
6.5 KiB
Markdown
# Why GPU Clusters Eat Networks: Starting from AllReduce
|
||
|
||
> 作者: wxj | 背景: 2年交换机L3控制面开发 + DPDK数据面
|
||
> 项目: [GitHub Link —— 待填]
|
||
|
||
这是 AI 网络冲刺的第一篇,概念级。目标就一个:把一个网络工程师的已有知识,平移到一个新问题上——**为什么 GPU 集群把网络吃干抹净**。
|
||
|
||
## 为什么做这个
|
||
|
||
我做交换机 L3 控制面两年,日常打交道的是 ECMP、路由表、ARP 老化。数据面用 DPDK 写过,用户态 TCP 栈也在做。在这些体系里,网络的定位是"尽力而为":丢包了,协议栈重传;拥塞了,窗口退避。
|
||
|
||
但 AI 训练集群把这条假设整个推翻了。
|
||
|
||
千卡集群训练时,AllReduce 聚合通信阶段占用训练时间的 **30~50%**(来源:ROADMAP Week 0)。训练不是算完就结束——每个 step,所有 GPU 都要把梯度加起来再广播出去,然后才能进入下一轮计算。**网络慢一毫秒,几千块 GPU 就一起空转一毫秒。** 这就是"GPU 集群吃网络"的含义:网络不再是被容忍的开销,而是训练吞吐的直接瓶颈。
|
||
|
||
对网络工程师来说,这不是新领域,而是一次"改名练习"(re-naming exercise)。下面每一层,我都会标出它对应我已经会的东西。
|
||
|
||
## 架构设计
|
||
|
||
Week 0 的 Gate 产物——GPU 集群通信栈,自上而下四层:
|
||
|
||
|
||
|
||
### L1 应用层:训练与集合通信
|
||
|
||
训练任务通过 NCCL 发起 AllReduce。AllReduce 的语义很简单:每个 GPU 持有一部分梯度,把所有人的梯度**加和**之后,让**每个人都拿到完整结果**。Ring / Tree 是它的两种经典算法形态。
|
||
|
||
关键洞察:**GPU 的时间就是钱**。AllReduce 期间 GPU 不计算,只等待。所以网络的每次抖动都会直接折算成 GPU 利用率损失。
|
||
|
||
### L2 传输层:RDMA over RoCEv2
|
||
|
||
传统 TCP 收包要经过内核协议栈:中断 → 拷贝到内核缓冲 → 拷贝到用户态。这条路径的延迟和 CPU 开销在 AI 场景不可接受。
|
||
|
||
RDMA 的答案是**零拷贝**:QP / Verbs 语义下,网卡(RNIC)直接把数据搬进应用事先注册的内存,CPU 完全不参与搬运。RoCEv2 把 RDMA 跑在以太网 + UDP 上,让无损以太网也能承载 RDMA 语义——这就是它和 InfiniBand 的根本区别:不用专用网络硬件。
|
||
|
||
这层对应我已会的东西:**TCP FSM → RoCEv2 QP/verbs**。都是"连接的建立、状态、可靠传输",只是状态机跑到了网卡硬件上。
|
||
|
||
### L3 网络层:无损以太网
|
||
|
||
RDMA 对丢包零容忍:一次丢包触发一次重传,性能立刻崩塌。所以承载 RDMA 的网络必须做到两件事:
|
||
|
||
1. **不丢包**:PFC(优先级流控)在链路层反压——下游缓冲快满时,直接让上游暂停发送
|
||
2. **提前疏导**:ECN 在丢包发生**之前**标记拥塞,DCQCN 在网卡侧做拥塞控制闭环
|
||
|
||
这里对应我已有的知识:**TCP 拥塞控制 → DCQCN**。TCP 把"丢包"当作拥塞信号;无损网络里"丢包 = 灾难",所以信号必须来自 ECN 标记而不是丢包。AIMD 曲线是一样的,信号源换了。
|
||
|
||
拓扑上,从 Spine-Leaf 到 Fat-Tree,再到 Rail-Optimized——这就是我日常的 **ECMP / 多路径问题**:东西向流量爆炸,要求网络提供全双工线速的多路径带宽(下文展开)。
|
||
|
||
### L4 硬件层:GPU 服务器与交换机
|
||
|
||
- **GPU ↔ NIC 直连**:PCIe / NVLink,数据搬进 GPU 内存的物理通道
|
||
- **800G 交换机**:单端口 800G,线速转发
|
||
- **DPU / SmartNIC**:把通信、拥塞处理从 CPU 卸载到网卡——这就是 DPDK 数据面思维("让 CPU 别碰数据路径")的硬件化版本
|
||
|
||
## 核心挑战
|
||
|
||
### 挑战一:东西向流量是压倒性的
|
||
|
||
GPU 集群的流量不是南北向(用户 ↔ 服务器),而是 GPU ↔ GPU 的东西向。每块 GPU 每个 step 都要和所有其他 GPU 通信。带宽需求 = GPU 数量 × 每块 GPU 的通信带宽,这比传统数据中心大一到两个数量级。
|
||
|
||
### 挑战二:丢包从"慢一点"变成"崩掉"
|
||
|
||
TCP 丢一个包,重传,吞吐降一点。RDMA 丢一个包,重传,整个集群的 step 时间被拖长——而且 PFC 自身还会引入新问题(风暴、死锁),这是 Week 1 的主菜。
|
||
|
||
### 挑战三:拓扑决定 NCCL 的心情
|
||
|
||
NCCL 是拓扑感知的:它根据 GPU 和交换机的位置决定 Ring / Tree 的排布。**乱序的拓扑会让 NCCL 的环形通信绕远路**,跨 spine 的流量比例直接决定瓶颈位置。这就是为什么大厂要 Rail-Optimized:让同一编号的 GPU(rail)尽量一跳可达,把流量钉在局部。
|
||
|
||
## 性能演进
|
||
|
||
| 演进项 | 数据 | 解决的问题 |
|
||
|------|-----|------|
|
||
| 拓扑:Spine-Leaf → Fat-Tree → Rail-Optimized | 训练流量约 60~80% 走 rail 内(一跳),20~40% 跨 rail;spine 交换机上到 128×800G | 东西向流量爆炸后的多路径与一跳化 |
|
||
| 机内互联:NVLink NVL5 | 单 B200 GPU 18 条 NVL5 链路,机内全互联 **1.8 TB/s** | GPU 间梯度交换不出机箱 |
|
||
| 跨机:InfiniBand NDR → 800G 以太网 | 计算网络 NDR 400Gbps;Spectrum-4 800G 以太网进入存储/管理面 | 跨 rack 的 AllReduce 流量 |
|
||
| 卸载:DPU / SmartNIC | BlueField-3 等 DPU 承担管理/存储面 200Gbps | CPU 从数据路径退场 |
|
||
|
||
(表格数据来源:NVIDIA DGX SuperPOD GB200 Reference Architecture;60~80% rail 内流量比例见参考 [3])
|
||
|
||
## 给读者的建议
|
||
|
||
如果你和我一样是传统网络工程师,进入 AI 网络最快的路径是:
|
||
|
||
1. **先吃透 AllReduce**:Ring AllReduce 每步传 (N−1)/N × data,推导一遍就知道网络为什么是瓶颈(Week 2 主菜)
|
||
2. **把每个新概念挂到旧概念上**:DCQCN = TCP 拥塞控制的表弟;Fat-Tree = 你的 ECMP 日常;PFC/ECN = 芯片流水线里的反压机制
|
||
3. **读代码而不是读百科**:verbs.h、ib_write_bw.c、rxe 内核模块,三层剥皮法每个 repo 一篇文章
|
||
4. **画图**:每个概念一张手绘图——我这张通信栈图讲给外行听过,才算真懂
|
||
|
||
## 参考
|
||
|
||
1. NVIDIA DGX SuperPOD: Next Generation Scalable Infrastructure Reference Architecture (DGX GB200) — https://docs.nvidia.com/dgx-superpod/reference-architecture-scalable-infrastructure-gb200/latest/
|
||
2. NVIDIA DGX SuperPOD Network Fabrics — https://docs.nvidia.com/dgx-superpod/reference-architecture-scalable-infrastructure-gb200/latest/network-fabrics.html
|
||
3. Rail-Optimized(DGX SuperPOD)的流量矩阵与 Spine 瓶颈分析 — https://blog.csdn.net/weixin_49199313/article/details/162331843
|
||
4. ROADMAP.md — AI-Networking Interview Sprint, Week 0 定义与 AllReduce 30~50% 数据
|
||
5. DCQCN (SIGCOMM'15) · Revisiting Network Support for RDMA (SIGCOMM'18) · Deadlocks in Datacenter Networks (HotNets'16) —— Week 1 精读预告
|