在 19.1 节中我们完成了 GPU 服务器的硬件选型，但一台服务器内部再怎么强大，也只是孤岛。算力中心真正的工程难点在于：如何用网络把几十台、几百台甚至几千台 GPU 服务器连成一台“虚拟超算”，让千卡集群在训练时表现得像单卡一样高效协同。
这就是网络架构设计要解决的问题。一个朴素的判断标准是：如果你花了 1000 万买 GPU，但网络架构设计失误导致算力利用率只有 30%，那实际等于只用了 300 万的卡——剩下的 700 万都花在了 GPU 等网络传输上。
一、网络在 AI 集群中到底传输什么？
在讨论具体方案之前，先明确网络承载的三类流量：
| 流量类型 | 具体内容 | 特点 | 误判后果 |
|---------|---------|------|---------|
| 计算网络流量 | 分布式训练中 GPU 之间的梯度同步（AllReduce）、张量并行通信 | 极高频次（每步迭代都发生）、极低延迟要求、数据量巨大 | 训练效率断崖式下跌 |
| 存储网络流量 | 从存储集群读取训练数据、写入 Checkpoint | 带宽密集型、允许一定延迟、IO 模式以顺序大块读写为主 | 数据加载成为瓶颈，GPU 空转等数据 |
| 管理网络流量 | SSH 连接、监控数据采集、任务调度指令、日志回传 | 带宽需求低、对可靠性要求高 | 集群“失联”，无法执行操作 |
这三种流量的需求差异极大，必须分别设计网络平面。
二、三网分离：算力中心网络的第一个设计原则
绝不要把上述三种流量混在一张网上。原因很简单：当千卡集群执行一次 AllReduce 梯度同步时，计算网络带宽会被瞬间打满。如果管理流量也走这张网，运维人员可能在训练高峰期根本无法 SSH 登录节点——整个集群处于“能跑但不能控”的失控状态。
标准三网分离方案：
| 网络平面 | 推荐技术 | 典型带宽（单端口） | 连接方式 |
|---------|---------|-------------------|---------|
| 计算网络 | InfiniBand（首选）或 RoCE v2（次选） | 100Gbps / 200Gbps / 400Gbps | 每 GPU 至少一个专属端口，直连叶脊交换机 |
| 存储网络 | 独立 InfiniBand 或 25G/100G 以太网 | 25Gbps–100Gbps | 每节点 1–2 个端口连存储交换机 |
| 管理网络 | 千兆/万兆以太网 + IPMI/BMC 带外管理 | 1Gbps–10Gbps | 每节点 1 个管理口连管理交换机，BMC 独立在线 |
实用经验：
- 小规模集群（< 50 节点）：可以用高性能以太网（100G RoCE）同时承载计算和存储，用 VLAN 做逻辑隔离。这能省一套交换机硬件成本，但需要团队对 RoCE 调优有经验，否则丢包问题会频繁重传。
- 中大规模集群（50+ 节点）：强烈建议计算网络独立走 InfiniBand。IB 的端到端流控和无损特性，能让 AllReduce 效率从 RoCE 的 70%–80% 提升到 90% 以上。对千卡级训练任务而言，10 个百分点的效率差可能等于多省出几十张 GPU 的算力。
三、计算网络的核心选型：InfiniBand vs. RoCE
这是算力中心网络设计中最具争议、也最需讲清的话题。两者都能跑 100G/200G/400G，但底层实现逻辑完全不同。
方案 A：InfiniBand（IB）
核心优势：
- 端到端无损网络：IB 协议栈内置基于信用的流控（Credit-based Flow Control），从根本上杜绝了交换机缓冲区溢出导致的丢包。这对 AllReduce 这种“所有节点必须等齐数据才能继续算”的同步操作至关重要。
- 极低延迟：端到端延迟通常低于 1 微秒（以太网约 5–10 微秒），NCCL 通信库对 IB 有深度优化。
- 运行免调优：网络几乎不用做额外配置即可高性能运行，对运维团队压力小。
核心劣势：
- 价格贵：同速率下 IB 交换机和网卡单价通常是 RoCE 方案的 1.5–2 倍；
- 生态封闭：只有 NVIDIA/Mellanox 一家主要供应商，存在锁定风险；
- 拓扑依赖强：需要配套 Mellanox 驱动程序与子网管理器（Subnet Manager）。
方案 B：RoCE v2（RDMA over Converged Ethernet）
核心优势：
- 标准化开放：基于传统以太网交换机，华为、思科、Arista 均有成熟产品，多供应商竞价压低成本；
- 兼容性强：管理网、存储网若已是以太网，可复用运维工具链和运维知识。
核心劣势：
- 需要有损容忍配置：RoCE 依赖 PFC（优先级流控）和 ECN（显式拥塞通知）来模拟无损传输，但这两种机制配置复杂，参数调错会引入 PFC 风暴（一次拥塞导致全网死锁）；
- 大规模部署挑战大：100+ 节点的 RoCE 网络需要精密的 QoS 策略和持续的性能调优，团队必须有懂 AI 网络的专用工程师。
选型决策框架：
| 判断维度 | 选 IB | 选 RoCE |
|---------|------|---------|
| 集群规模 | > 100 GPU，对性能极致要求 | < 100 GPU，成本更敏感 |
| 团队能力 | AI 网络经验尚浅，追求“开箱即用” | 具备 RoCE 调优能力，有自建运维团队 |
| 预算 | 硬件预算充足，优先性能 | 希望控制建设成本 |
| 供应商策略 | 可与 NVIDIA 长期绑定 | 倾向多供应商、国产化替代 |
一个真实的折中方案：部分算力中心采用“IB 做计算，以太网做存储”的混合架构。这比全以太网方案成本略高，但比全 IB 方案便宜，且兼顾了训练效率和运维通用性。
四、叶脊（Spine-Leaf）网络拓扑：为什么 GPU 集群不堆叠交换机？
传统数据中心网络常用三层架构（接入→汇聚→核心），但在 AI 集群中，这种设计会导致跨交换机流量经过多层跳转，引入额外延迟。更致命的是，上联带宽往往存在收敛比（Oversubscription），例如 10 个 100G 下联口共享 1 个 100G 上联口——这在 AI 集群中意味着一半的 GPU 在等另一半 GPU 的数据，训练性能直接腰斩。
叶脊（Spine-Leaf）拓扑是 AI 集群的标准答案：
[Spine 交换机 1] [Spine 交换机 2] [Spine 交换机 N]
| | | | | |
—————————————————————————————————————————————————
| | | | | |
[Leaf 交换机 1] [Leaf 交换机 2] [Leaf 交换机 M]
| | | | | |
GPU Node × K GPU Node × K GPU Node × K设计规则：
- 每个 Leaf 交换机的上行端口数 = 对应 Spine 总数：例如 4 台 Spine，每个 Leaf 就要用 4 个上行端口直连这 4 台 Spine；
- 非阻塞设计：Leaf 下联端口的总带宽 = 上联端口的总带宽，即收敛比 = 1:1。这保证了任何两个 Leaf 下的 GPU 通信时，带宽不会被交换机瓶颈卡住；
- 扩展方式：要增加更多 GPU 节点，只需增加 Leaf 交换机的下联端口（或加更多 Leaf），并相应扩展 Spine 数量以匹配上行带宽需求。
计算一个实际例子：
假设你计划搭建一个 128 张 H100 GPU（每节点 8 卡，共 16 节点）的集群，每 GPU 配 1 个 400Gbps IB 端口。
- 每节点需 8 个下联端口 × 400G = 3.2Tbps 下行带宽；
- 若采用 32 口 400G 的 Leaf 交换机，每台 Leaf 可下挂
(32 − 上行端口数)个 GPU 节点； - 若用 4 台 Spine 交换机做冗余与负载均衡，每个 Leaf 需 4 个上行端口连 Spine，剩余 28 个下联端口可挂 28 台 GPU 节点（或更多节点做轻微收敛）。
关键注意事项：
- 跨 Leaf 流量：训练过程中，AllReduce 会跨所有 GPU 节点。如果一台 Leaf 下挂的 GPU 太少、Leaf 数量过多，跨 Leaf 通信比例过高，会引入额外延迟。理想情况下，每 Leaf 至少挂 4–8 节点，能让同一 Leaf 内的局部通信分担压力。
- Spine 数量不足的灾难：Spine 数量少意味着 Leaf 上行带宽有限，收敛比不再是 1:1，训练时会出现 GPU 间歇性等待，表现为“GPU 利用率很高但吞吐量很低”。
- RDMA 与 PFC 在叶脊中的配合：若使用 RoCE，需要确保整条叶脊路径上的交换机都支持 PFC 和 ECN。一台不支持或配置错乱的交换机会成为整个集群的性能黑洞。
五、实用总结：网络设计的四个核心原则
- 三网必分离：计算、存储、管理走独立的物理链路或至少严格 VLAN 隔离，尤其在大规模集群中计算网络绝对不能与管理/存储共用。
- 计算网络非阻塞：Leaf 下联总带宽必须 ≥ Leaf 上联总带宽，保证任意 GPU 对之间通信不被交换机内部瓶颈压制。
- 延迟比带宽更重要：分布式训练中，GPU 在等数据同步时的每一微秒空闲都是损失。优先选低延迟方案（IB 优先，RoCE 需深度调优）。
- 拓扑决定上限：叶脊拓扑是当前标配，但 Leaf 与 Spine 的数量配比、每个 Leaf 下分配的节点数，必须根据训练任务并行策略（数据并行、张量并行、流水线并行）反向推算。
在 19.3 节中，我们将继续向下穿透到存储系统设计——当计算网络保证 GPU 之间的梯度能光速同步之后，存储网络如何保证训练数据能以同等速度喂饱这一群饥饿的 GPU，将决定整个集群能否真正跑到 MFU 的理论上限。