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 服务器与存储节点：

Spine 层（脊交换机） Spine-1 Spine-2 Spine-3 Spine-4 Leaf 层（叶交换机） Leaf-1 Leaf-2 Leaf-3 Leaf-4 Leaf-5 Leaf-6 Leaf-7 Leaf-8 接入层（GPU 服务器 / 存储节点） GPU-Srv1 GPU-Srv2 存储节点 GPU-Srv3 GPU-Srv4 存储节点 GPU-Srv5 GPU-Srv6 GPU-Srv7 GPU-Srv8 GPU-Srv9 GPU-Srv10 GPU-Srv11 GPU-Srv12 GPU-Srv13 GPU-Srv14 任意 Leaf 到任意 Leaf 跳数 = 2（经 Spine），ECMP 提供多路径负载均衡

上图展示了一个典型的 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、万亿级 语料）时，存储流量会瞬间打满网络缓冲区，导致 NCCL 梯度同步出现微突发丢包，进而引发 AllReduce 性能断崖式下降。强烈建议至少将存储网与业务网物理隔离。

3.4 案例：一个 32 节点集群的拓扑规划

假设我们需要搭建一个用于 175B 参数模型预训练的集群，共 32 台 GPU 服务器（每台 8×A100 80GB），总计 256 张 GPU。以下是推荐的拓扑规划流程：

  1. 确定 Leaf 数量：每台 Leaf 交换机通常提供 32~64 个下行端口。若每台 Leaf 接入 8 台服务器（8×200G），则需要 32/8 = 4 台 Leaf 用于业务网。
  2. 确定 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。
  3. 规划存储网：单独部署 2 台 Leaf 用于存储，接入 4 台存储节点（每台双 100G 上行）。
  4. 规划管理网：使用 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 数量。
误区二：忽略 RoCEv2 的 PFC 死锁风险
在叶脊拓扑中启用 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 暂停帧计数是否持续增长）。
← 上一章 📖 返回目录 下一章 →