GPU 组网拓扑

AI 集群的网络是分层构建的，每一层使用不同的互连方式——也使用不同的光模块。理解这些层次，就能明白一个集群为何有这么多光模块、一个坏模块又会在哪里伤害最大。

Scale-up 与 scale-out

可插拔光模块主要用在 scale-out 层——每台 GPU 服务器都有若干面向组网的 400G/800G 端口，此外还有独立的前端/存储网络。

Fat-tree 与无阻塞

scale-out 组网通常是 fat-tree（Clos） 结构：leaf 交换机连接服务器，spine 交换机连接各 leaf，leaf–spine 上行链路数量足够多，使任意服务器都能以全速与任意其他服务器通信（无阻塞）。集群中大多数光模块都用在这些 leaf–spine 和服务器–leaf 链路上——成千上万个完全相同的 DR4/DR8 模块。

Rail-optimised 设计

训练流量主要由跨服务器、相同 rank 的 GPU 之间的集合操作主导。 rail-optimised 拓扑正是利用了这一点：每台服务器的 GPU 0 都接到 leaf 交换机 0，GPU 1 接到 leaf 1，依此类推，使相同 rank 的 GPU 相隔一跳，集合操作永远不必穿过 spine。这对光模块的影响是：单条 rail 上的故障会影响每台服务器中的同一个 GPU 位置——这是一个值得识别的模式。

相互独立的网络

一个集群通常运行若干在物理上相互独立的组网：

• 计算网络——GPU 到 GPU（IB 或 RoCE），规模最大、光模块用量最多。
• 存储网络——连接并行文件系统和对象存储，常用以太网（存储组网）。
• 前端/管理网络——用户接入、编排调度、遥测。

每一个都有各自的光模块库存和各自的厂商验证规则。

为什么一条坏链路影响这么大

一次集合操作的完成速度取决于其中最慢的参与者。一个通道正在劣化的光模块—— FEC 纠错次数增多、偶尔重传——会拉长每一步的尾延迟，可能拖累整个集群吞吐量的一个可观比例。这就是为什么 AI 运营方要在整个机群范围内跟踪每通道 DDM 趋势，并主动更换光模块（AI 集群中的光模块）。

在 CodingBox 中

在光模块进入 rail 之前先在台架上完成验证：通过 CMIS 核对身份信息，在 DDM 界面记录每通道基线，并存入代码数据库，这样当某条 rail 开始出现错误时就能查到该模块的历史记录。

这些组网中 GPU 端的适配器——BlueField、ConnectX-8 SuperNIC、Pensando—— 及其双端口 OSFP 光模块：智能网卡与 DPU。