规划预计 40 分钟

高性能网络规划：SU、Rail 与线缆账

按 GPU 数算出计算网的 leaf/spine 台数与线缆数，并核对无阻塞条件。

学完这节你能做到

按 rail-optimized 原则算出交换机与线缆数量
核对两层 Fat-Tree 的无阻塞条件是否成立
把结果与 DGX SuperPOD 参考架构的数字对上

建议先学跳过这几节会看不懂本节的部分推导

计算网和业务网是两套完全不同的账

上一节的以太网规划允许收敛，因为业务流量有峰谷。计算网不行：

AllReduce 是一种全员同时满速通信的模式。 所有 GPU 在同一时刻互相发数据，没有"平均利用率"这回事——要么全速，要么全都在等最慢的那一条链路。

所以计算网的规划口径变成三条硬约束：

必须无阻塞（1:1），不接受任何收敛
必须 rail-optimized，让同 rail 通信只走一跳
按整 SU 布线，宁可留空位也不留不对称的路径

Rail 是什么

一台 8 卡 GPU 服务器有 8 张计算网卡。把每台机器的第 N 张卡都接到第 N 组 leaf 上，这一组就叫一个 rail：

                rail 0        rail 1              rail 7
              ┌────────┐   ┌────────┐          ┌────────┐
              │ leaf-0 │   │ leaf-1 │   ...    │ leaf-7 │
              └───┬────┘   └───┬────┘          └───┬────┘
     node-0 ──NIC0┘       NIC1─┘              NIC7─┘
     node-1 ──NIC0┘       NIC1─┘              NIC7─┘
      ...
     node-30 ─NIC0┘       NIC1─┘              NIC7─┘

好处是：同一个 rail 内的任意两个节点之间只有一跳（都挂在同一台 leaf 上）。而 NCCL 的 Ring AllReduce 恰好可以安排成"每张卡只和其它节点的同号卡通信"，于是绝大部分流量都只走一跳，根本不上 spine。

跨 rail 通信才需要 leaf → spine → leaf 三跳。

×端口数算得对，但接错 rail

最隐蔽的布线错误：把一台机器的 8 张卡全接到同一台 leaf 上。

端口总数一样、交换机台数一样、线缆数一样，账面上完全对，验收单也过得去。但同 rail 的通信全部被迫上 spine，AllReduce 带宽直接腰斩，而且这个问题只能通过实测 busbw 才能发现。

这就是为什么高性能网络的验收必须跑 NCCL：布线图纸对不能代表现场接对。

无阻塞的算法

交换机端口对半分：一半下行接节点，一半上行接 spine。以 64 口交换机为例：

每台 leaf：32 口下行 + 32 口上行

每个 rail 的 leaf 数 = ⌈节点数 ÷ 32⌉
leaf 总台数          = rail 数 × 每 rail 的 leaf 数
上行口总数           = leaf 总台数 × 32
spine 台数           ≥ ⌈上行口总数 ÷ 64⌉

spine 台数还有一个额外约束：每台 leaf 的 32 个上行口要均分到各台 spine 上，所以 spine 台数必须能整除 32（即只能取 1、2、4、8、16、32）。按容量算出 12 台时，实际要取 16 台。

对着参考架构验算

DGX SuperPOD (H200) 的计算网就是这套算法的标准答案。它的组件表：

SU 数	节点	GPU	leaf	spine	计算+UFM 线缆	spine-leaf 线缆
1	31	248	8	4	252	256
2	63	504	16	8	508	512
3	95	760	24	16	764	768
4	127	1016	32	16	1020	1024

拿 1 个 SU 手算一遍：

节点 31，每节点 8 张 NDR 400G 卡，交换机 64 口

每 rail 的 leaf 数 = ⌈31 ÷ 32⌉ = 1
leaf 总数         = 8 rail × 1 = 8            ✓ 表格是 8
上行口总数        = 8 × 32 = 256              ✓ 表格 spine-leaf 线缆 256
spine 台数        = ⌈256 ÷ 64⌉ = 4            ✓ 表格是 4
计算线缆          = 31 × 8 = 248，+4 根 UFM = 252  ✓ 表格是 252

再看 3 个 SU 那行，验证"整除"约束：

leaf 总数  = 8 rail × ⌈95 ÷ 32⌉ = 8 × 3 = 24     ✓
上行口总数 = 24 × 32 = 768                        ✓
按容量算   = ⌈768 ÷ 64⌉ = 12 台
但 12 不能整除 32 → 取能整除 32 的下一个值 = 16    ✓ 表格是 16
此时每台 leaf 到每台 spine 之间是 32 ÷ 16 = 2 条并行链路

i为什么 32 台机位只装 31 台机器

参考架构里一个 SU 的设计是 32 节点，但实际只装 31 台——腾出的位置给 UFM （InfiniBand 的管理平面）接线用。这也是"计算+UFM 线缆"比 节点 × 8 多出 4 根的原因。

同样的思路还体现在另一条建议上：如果你只买了半个 SU 的机器， 仍然要把整个 SU 的 leaf 和 leaf-spine 链路都接完，空位留着。这样任意位置的转发路径长度都一致，性能不会因为"机器插在哪台 leaf 上"而变化。

自己算一遍

默认值就是 1 个 SU 的配置，算出来会和参考架构对上（组件会显示一行绿色的核对提示）。建议试试这几个练习：

把节点数依次改成 63、95、127，看是否都和上面的表格一致
把每节点网卡数从 8 改成 4，看 leaf 台数怎么变
选 HDR 200G（40 口交换机）预设，看每 rail 能接的节点数怎么变
把节点数改到 600，看两层架构什么时候撑不住

计算器计算网 Rail-Optimized 布线账

网络与交换机预设

计算节点台数每节点 GPU 数

每节点计算网卡数等于 rail 数，通常与 GPU 数 1:1单口速率 Gbps

交换机端口数QM9700 为 64每 SU 节点数参考架构为 32

预留 UFM 管理链路（IB 场景）

无阻塞算法

64 口交换机对半分：32 口下行接节点、32 口上行接 spine。每个 rail 独立成组，所以 leaf 台数 = rail 数 × 每 rail 的 leaf 数。

GPU 总数

248

leaf

spine

rail 数: 8 个
每 rail 的 leaf 数: 1 台（每台接 32 节点）
leaf↔spine 并行链路: 8 条/对
计算网线缆: 252 根
spine-leaf 线缆: 256 根
SU 数量: 1 个
单节点计算网带宽: 3.20 Tbps
单节点理论 busbw 上限: 400 GB/s
全网对分带宽: 102.40 Tbps
通信跳数: 同 rail 1 跳／跨 rail 3 跳

✓ 与 SuperPOD 参考架构一致

1 个 SU / 31 节点 / 248 GPU 时，RA 给出 8 台 leaf + 4 台 spine、252 根计算线缆、256 根 spine-leaf 线缆。

·节点数不是 SU（32 台）的整数倍，当前算成 1 个 SU。参考架构的建议是按整 SU 布线、空位留着不插机器 —— 这样各处的转发路径长度一致，性能不会因为机器插在哪台 leaf 上而变化。
·已按 IB 场景预留 4 根 UFM 管理链路；这也是参考架构里一个 SU 明明是 32 台机位、却只装 31 台节点的原因。
·rail-optimized 的关键是「同一个 rail 的网卡接到同一组 leaf 上」。接错成「一台机器的 8 张卡全接一台 leaf」时端口数一样、账也算得通，但同 rail 的集合通信会全部挤到 spine 上，AllReduce 带宽直接腰斩。
·存储网、带内管理网、带外管理网都要另算。参考架构里它们分别是独立的 IB 网、SN4600 以太网和 SN2201 以太网。

还有三张网要算

计算网只是四套网络里的一套。参考架构里的完整清单：

网络	介质	用途	规格特点
计算网	InfiniBand NDR 400G	GPU 之间的集合通信	rail-optimized，无阻塞
存储网	InfiniBand	读写训练数据与检查点	存储侧 1:1，节点侧可接受约 4:3 轻度收敛
带内管理网	以太网（如 SN4600）	集群管理、家目录、外部仓库	成对部署提高并行度
带外管理网	以太网（如 SN2201）	BMC、交换机管理口、PDU	完全隔离，无用户访问场景

两个值得记住的细节：

存储网单独成网，因为单节点的 I/O 需求要超过 40 GB/s，塞进计算网会互相干扰
存储侧 1:1、节点侧约 4:3：存储设备那端不能有任何收敛，节点这端轻度收敛可以换来成本弹性

✓报价前的自检清单

计算网：leaf、spine、线缆、光模块，按整 SU 备
存储网：交换机与线缆，存储侧确认 1:1
带内管理网：交换机成对，端口数覆盖所有节点
带外管理网：独立交换机，覆盖 BMC + 交换机管理口 + PDU
UFM 节点与它占用的机位和线缆
光模块总量（每根线两端）+ 5% 备件
机柜功率与走线距离能否支撑上述布线

检查点

检查点单选

8 卡节点、每卡一张 400G 网卡、64 口交换机。一个 rail 的单台 leaf 最多能接多少个节点？

检查点单选

按容量算需要 12 台 spine，但参考架构给的是 16 台。为什么？

检查点单选

一套 GPU 集群端口数、交换机台数、线缆数全部符合设计，但实测 AllReduce 带宽只有预期一半。最值得先怀疑什么？

这节课的落点

计算网不接受收敛：AllReduce 是全员同时满速的通信模式
rail = 每节点的第 N 张卡接到第 N 组 leaf，同 rail 只有一跳、跨 rail 三跳
无阻塞算法：交换机端口对半分，每 rail 的 leaf 数 = ⌈节点数 ÷ (端口数/2)⌉
spine 台数要能整除每台 leaf 的上行口数，否则路径不对称
参考架构 1 SU = 31 节点（留一位给 UFM）+ 8 leaf + 4 spine + 256 根 spine-leaf 线
不满一个 SU 也要按整 SU 布线，空位留着，保证路径长度一致
计算网之外还有存储网、带内管理网、带外管理网三套要单独算
布线图纸对 ≠ 现场接对，验收必须实测 busbw

延伸资料

·DGX SuperPOD H200 参考架构 ↗

下一课：选型对比：IB、RoCE 与 Spectrum-X →