Leaf-Spine 和 Rail-Optimized 不是二选一。Leaf-Spine 描述交换网络如何分层连接并提供可预测的东西向路径；Rail-Optimized 则围绕多 GPU 节点的网卡和通信关系组织网络，以减少关键通信跨越不必要的交换层级。实际设计常常在 Leaf-Spine 基础上实现 Rail 划分。
先用 Leaf-Spine 建立容量模型
每台 Leaf 连接一定数量的计算节点，并通过上联连接 Spine。设计时要根据节点数、每节点网卡数、端口速率和目标收敛比计算 Leaf 下联与上联，而不是从交换机端口数倒推架构。还应明确链路冗余、等价多路径、故障影响和后续扩容端口。
Rail 设计从服务器内部拓扑开始
多 GPU 服务器通常有多条对外通信路径。Rail 设计需要明确每块 GPU、网卡、PCIe 交换和 CPU 的关系，并让相同通信角色的接口进入规划好的网络域。若服务器内部 NUMA 或 PCIe 路径没有对齐，外部交换网络再充足也可能出现绕行。
故障域和扩容必须一起计算
- 单条上联、单台 Leaf 或单个 Rail 故障影响多少 GPU。
- 某一 Rail 流量不均时是否会形成局部拥塞。
- 新增机柜是否有连续端口、光纤和 Spine 容量。
- 布线路径、配线架和机柜位置是否支持后续扩容。
- 路由、监控和自动化系统能否识别 Rail 与故障域。
验收要从物理链路走到业务
先验证所有链路的速率、FEC 和错误计数，再检查路由与多路径分布，然后完成单 Rail、跨 Rail、单节点和多节点的递增测试。NCCL 测试应保留拓扑文件、软件版本、消息大小和持续时间，避免只比较一次峰值。
参考架构可以帮助确定方法，但不能按端口表直接复制。节点型号、GPU 与网卡数量、机柜布局、介质距离和扩容目标变化后，Rail 划分和交换层容量都必须重新计算。
WeChat
Profile