3. 集群架构:典型多节点训练集群的硬件组成与网络拓扑(如叶脊架构)
3.1 从单机到集群:为什么必须关注硬件组成
当模型规模突破单卡显存或单机算力上限时,训练任务必然走向多节点并行。一个典型的多节点训练集群,其硬件组成并非简单的“多台服务器堆叠”,而是围绕 计算、存储、网络 三大子系统精心设计的整体。理解硬件组成是理解网络拓扑的前提——因为拓扑的本质,就是为这些硬件之间提供高效、可靠、可扩展的互连路径。
从物理构成看,一个标准训练集群包含以下核心部分:
- 计算节点(GPU Server):通常为 8 卡 GPU 服务器(如 NVIDIA DGX A100/H100、浪潮 NF5688 等),节点内通过 NVLink/NVSwitch 实现高速卡间互联。
- 存储节点(Storage):分为并行文件存储(如 Lustre、BeeGFS)和对象存储(如 MinIO、Ceph RGW),用于存放训练数据集、Checkpoint 和日志。
- 管理节点(Login/Admin):提供用户登录、作业调度(Slurm)、集群监控入口,通常不参与计算。
- 网络设备(Switch):包括 Leaf(叶)交换机、Spine(脊)交换机、管理网交换机及存储网交换机。
关键认知:在多节点训练中,网络不再是“可选配件”,而是与 GPU 算力同等重要的“一等公民”。一个 1000 张 A100 卡的集群,若网络拓扑设计不当,实际有效算力可能仅剩 60%~70%。
3.2 叶脊(Spine-Leaf)拓扑:数据中心级无阻塞网络
传统三层树形拓扑(核心-汇聚-接入)在东西向流量(服务器到服务器)占比极高的 AI 训练场景下,会产生严重的带宽收敛和延迟抖动。现代 AI 训练集群几乎无一例外采用 叶脊(Spine-Leaf)架构,其核心思想是:任何 Leaf 节点到任何其他 Leaf 节点的跳数固定为 2(Leaf → Spine → Leaf),且通过等价多路径(ECMP)实现全带宽无阻塞转发。
以下是一个典型 2 层叶脊拓扑的结构示意,展示了 4 台 Spine 与 8 台 Leaf 之间的全连接关系,以及 Leaf 下挂的 GPU 服务器与存储节点:
上图展示了一个典型的 2 层叶脊拓扑。其核心特征可归纳为:
- 全连接(Full Mesh):每台 Leaf 的上行端口分别连接至所有 Spine,形成 N×M 的交叉矩阵。
- 无阻塞带宽:Leaf 下行带宽总和 ≤ 上行带宽总和,保证任意两台服务器之间的通信带宽不打折。
- 水平扩展:增加 Spine 数量可提升东西向总带宽;增加 Leaf 数量可接入更多服务器,两者互不干扰。
3.3 集群网络的分层设计:业务网、存储网、管理网
在实际部署中,训练集群不会只使用一张物理网络,而是按功能划分为三张独立的网络平面,各自承载不同流量特征的数据。这种物理隔离是避免相互干扰的关键手段。
| 网络平面 | 典型带宽 | 承载流量 | 关键设备 |
|---|---|---|---|
| 业务网(东西向) | 200Gbps/400Gbps | GPU 间梯度同步(NCCL/RCCL)、集合通信 | Spine-Leaf 交换机(RoCEv2/IB) |
| 存储网 | 100Gbps/200Gbps | 数据集读取、Checkpoint 写入、日志传输 | 独立 Leaf 交换机或复用业务 Leaf 的存储 VLAN |
| 管理网 | 1Gbps/10Gbps | SSH 登录、Slurm 调度、IPMI/BMC 带外管理 | 普通千兆/万兆交换机 |
常见误区:有些团队为了节省成本,将存储流量与业务流量混跑在同一张网络上。当多个节点同时读取大型数据集(如 ImageNet-21k、万亿级 Token 语料)时,存储流量会瞬间打满网络缓冲区,导致 NCCL 梯度同步出现微突发丢包,进而引发 AllReduce 性能断崖式下降。强烈建议至少将存储网与业务网物理隔离。
3.4 案例:一个 32 节点集群的拓扑规划
假设我们需要搭建一个用于 175B 参数模型预训练的集群,共 32 台 GPU 服务器(每台 8×A100 80GB),总计 256 张 GPU。以下是推荐的拓扑规划流程:
- 确定 Leaf 数量:每台 Leaf 交换机通常提供 32~64 个下行端口。若每台 Leaf 接入 8 台服务器(8×200G),则需要 32/8 = 4 台 Leaf 用于业务网。
- 确定 Spine 数量:为保证无阻塞,Spine 数量 × 单 Spine 端口速率 ≥ Leaf 上行总带宽。若 Leaf 上行采用 8×400G,则 4 台 Leaf 总上行带宽为 4×8×400G = 12.8Tbps。若 Spine 提供 32×400G 端口,则至少需要 12.8Tbps / (32×400G) = 1 台,但为冗余和 ECMP 负载均衡,通常部署 4~8 台 Spine。
- 规划存储网:单独部署 2 台 Leaf 用于存储,接入 4 台存储节点(每台双 100G 上行)。
- 规划管理网:使用 1 台千兆交换机,将所有服务器的 BMC 和业务网卡的管理口接入。
最终拓扑参数如下:
业务网:4 Leaf × 8 Spine(400G 上行),Leaf 下行 8×200G 接入 GPU 服务器
存储网:2 Leaf(100G 下行),连接 4 台并行存储节点
管理网:1 台千兆交换机,连接 32 台服务器 BMC + 管理口
IP 规划:业务网 10.0.0.0/22,存储网 10.10.0.0/24,管理网 192.168.1.0/24
3.5 误区与复盘:拓扑设计中的常见陷阱
误区一:盲目追求 Spine 数量
有些设计将 Spine 从 4 台增加到 8 台,但 Leaf 的上行端口数量并未同步增加。此时 Spine 增多只会增加 ECMP 路径数量,而不会提升总带宽——因为瓶颈在 Leaf 的上行端口。正确做法是:先计算 Leaf 上行总带宽,再反推 Spine 数量。
有些设计将 Spine 从 4 台增加到 8 台,但 Leaf 的上行端口数量并未同步增加。此时 Spine 增多只会增加 ECMP 路径数量,而不会提升总带宽——因为瓶颈在 Leaf 的上行端口。正确做法是:先计算 Leaf 上行总带宽,再反推 Spine 数量。
误区二:忽略 RoCEv2 的 PFC 死锁风险
在叶脊拓扑中启用 RoCEv2 时,必须启用 PFC(优先级流控)并合理规划无丢包队列。若 Leaf 与 Spine 之间的 PFC 配置不一致(例如某台 Spine 未开启 PFC),一旦出现拥塞,缓冲耗尽将导致丢包,而 RoCEv2 对丢包极其敏感,重传机制会严重拖慢 NCCL 通信。
在叶脊拓扑中启用 RoCEv2 时,必须启用 PFC(优先级流控)并合理规划无丢包队列。若 Leaf 与 Spine 之间的 PFC 配置不一致(例如某台 Spine 未开启 PFC),一旦出现拥塞,缓冲耗尽将导致丢包,而 RoCEv2 对丢包极其敏感,重传机制会严重拖慢 NCCL 通信。
复盘建议:在集群上线前,使用
ib_write_bw(IB 网络)或 perftest 工具,从 Leaf-1 下挂的服务器向 Leaf-4 下挂的服务器打流,验证跨 Leaf 通信带宽是否达到线速。若发现带宽不足,优先检查:
- Leaf 与 Spine 之间的链路是否全部协商为预期速率(如 400G);
- ECMP 哈希是否均匀(可通过
ethtool -S查看各上行口流量分布); - 是否存在 PFC 死锁(观察交换机上 PFC 暂停帧计数是否持续增长)。