3. 数据中心网络拓扑设计与验收标准

在AI数据中心里，拓扑不是“把交换机和网卡连起来”这么简单。它直接决定了All-Reduce这类集合通信的带宽利用率、故障域大小，以及验收时该测什么、测到什么程度算合格。本节围绕Spine-Leaf、Rail-Optimized、NVLink与以太网融合三类架构，讲清拓扑规划、冗余设计、收敛比计算和验收指标定义。

一、Spine-Leaf：通用东西向流量的基础骨架

Spine-Leaf是两层CLOS结构：每台Leaf下挂服务器，每台Spine与所有Leaf全互联。任意两台服务器之间最多经过Leaf→Spine→Leaf三跳，跳数固定、时延可预测。规划时先确定三个参数：单端口速率（如400G）、Leaf下行端口数、Spine数量。

以一台64×400G Leaf为例，若下行接32台服务器（每台1个400G上行），则剩余32个端口上行到Spine。若部署32台Spine，则每台Leaf到每台Spine用1个400G链路，形成32条等价上行。此时下行总带宽32×400G=12.8T，上行总带宽32×400G=12.8T，收敛比（oversubscription）为1:1，属于无收敛设计，适合训练流量。

若下行接48台服务器、上行仅16条400G，则下行19.2T、上行6.4T，收敛比3:1。收敛比定义为“下行总带宽÷上行总带宽”，数值越大越容易在突发流量下拥塞。验收时应明确每个Leaf组的收敛比目标，并在流量测试中验证是否达标。

二、Rail-Optimized：让同一GPU编号走同一张网

在GPU集群中，每台服务器有8个GPU（GPU0~GPU7），每个GPU对应一张网卡。Rail-Optimized的核心思想是：所有服务器的GPU0接在同一组Leaf（Rail 0），GPU1接在Rail 1，依此类推。这样GPU0之间的通信只经过Rail 0的Leaf和Spine，不跨Rail，路径更短、拥塞域更小。

规划时，每个Rail通常配2台Leaf做MLAG或堆叠，服务器双上行分别接这两台Leaf。8个Rail共16台Leaf，再上联Spine。验收要点是：确认每台服务器的8张网卡确实按GPU编号接入对应Rail，且同一Rail内Leaf的端口分布均匀。若接错Rail，跨Rail流量会绕行，集合通信效率下降。

三、NVLink与以太网融合架构

NVLink负责机内GPU间高带宽互联（如H100的NVLink 4.0，单GPU 900GB/s），以太网负责机间互联。融合架构中，一台服务器内8个GPU通过NVLink全互联，对外则通过8张400G网卡接入Rail-Optimized以太网。数据流是：GPU→NVLink→本机网卡→Leaf→Spine→对端Leaf→对端网卡→NVLink→对端GPU。

验收时要区分两类带宽：机内NVLink带宽和机间以太网带宽。机内可用nvbandwidth或NCCL单机测试验证；机间则用NCCL多机All-Reduce测试，观察总线带宽（busbw）是否接近理论值。若机间带宽远低于网卡线速之和，需排查Rail接线、收敛比或PFC/ECN配置。

四、冗余设计与收敛比计算

冗余设计要回答两个问题：链路断了怎么办、设备挂了怎么办。链路级冗余靠MLAG或EVPN-MH，服务器双上行分别接两台Leaf，任一链路故障时流量切换到另一条。设备级冗余靠Spine多台部署，单台Spine故障时，Leaf到其余Spine的等价路径自动接管。验收时应做断链测试：拔掉一条上行，观察业务是否中断、切换时间是否在毫秒级。

收敛比计算需区分“设计收敛比”和“实际收敛比”。设计收敛比按端口数算，实际收敛比要考虑流量模型。例如Rail-Optimized中，同一Rail内GPU0之间通信走Rail 0，不占用其他Rail带宽，因此每个Rail的收敛比可独立计算。若每个Rail下行接32台服务器×1个400G，上行16条400G，则收敛比2:1。验收时用NCCL All-Reduce测试，观察busbw是否达到理论值的80%以上。

五、验收指标定义

拓扑验收不能只看“链路up”。建议定义以下可量化指标：

这些指标应在验收方案中逐条写明测试方法、工具和判定阈值。例如Rail接线正确率可用LLDP邻居信息比对，All-Reduce busbw用NCCL的all_reduce_perf测试，故障切换用持续ping或iPerf观察丢包和恢复时间。

总结来说，Spine-Leaf提供通用骨架，Rail-Optimized优化GPU集合通信，NVLink与以太网融合则把机内和机间带宽串起来。验收时围绕收敛比、Rail正确率、All-Reduce带宽和故障切换时间四个维度定义指标，才能保证拓扑既“连得通”又“跑得快”。