最近由于项目需要，我深入研究了阿里云最新一代万卡集群的网络架构HPN 7.0，其中有许多值得分享的细节。先给出几个关键结论：该架构以三层RoCE组网为核心，设计时采用了1:1的收敛比。从整体拓扑看，每个Pod被划分为8个Segment，层次结构非常清晰。

首先，我们来深入剖析每个Segment的具体构成：

每个Segment部署了16台Leaf交换机，合计提供2048个200Gbps下行端口，这些端口恰好对应128台GPU服务器（每台服务器配备16个200Gbps网口）。据此计算，一个Pod最多可容纳1024台GPU服务器，即8192张GPU卡，其规模令人瞩目。

再来看Leaf交换机本身的配置：每台设备具备64个400Gbps上行端口和128个200Gbps下行端口。其中的映射关系值得注意——每个200Gbps下行端口对应GPU服务器的一个200Gbps网口，而每台GPU服务器拥有16个网口，因此需要连接16台Leaf交换机的200Gbps端口，才能充分利用带宽。

GPU服务器的网卡设计同样精妙：每台服务器安装8块双口200Gbps网卡，共计16个端口，采用双上联冗余接入方式。这意味着每张GPU卡拥有两条独立的上行链路，且这两条链路必须分别连接到不同的交换机。具体而言，在一个Group的128台服务器中，所有1号NIC端口统一接入Leaf交换机的1号端口，而16号NIC端口则接入Leaf交换机的16号端口，层次清晰。

这种双上联设计带来的实际好处非常显著：每个Segment内的GPU数量和通信带宽直接翻倍。Segment内部的GPU之间通信只需经过一台Leaf交换机，最多可支持1024张GPU卡互联，总通信带宽轻松达到409.6Tbps。更重要的是，该设计能够有效应对多种故障场景。例如，当某个上行链路中断、交换机宕机，甚至光模块或光纤出现问题时，流量会自动切换到另一个端口继续传输，避免训练任务直接中断——尽管训练速度可能受到一定影响，但总比完全停摆要好。下图中展示了故障时的流量绕行路径。

以上描述的是Core交换机与Spine交换机按1:1收敛比的标准配置。然而，在近期接触的一个实际项目中，收敛比被调整为了1:15。这很可能并非随意设定，而是阿里基于自身海量流量数据经过长期观测和建模后得出的最优方案。下图仅展示了3个Unit，但从整体网络拓扑已能窥见其设计思路。

整个集群共划分为15个Unit，每个Unit通常部署128至136台GPU服务器。采用双平面设计（Plan A和Plan B），每台GPU服务器的16个200Gbps端口中，8个上联至Plan A，剩余8个上联至Plan B。整个集群最大支持2040台GPU服务器，约合1.6万张GPU卡，规模极其庞大。

每个Unit配备16台Leaf交换机（Plan A和Plan B各8台），15个Unit满配共240台。每台Leaf交换机的上行和下行端口数量分别为60个和68个400Gbps端口。值得注意的是，下行的68个400Gbps端口可拆分为2个200Gbps端口，因此每台Leaf交换机实际上能提供136个200Gbps下行端口。

在满配情况下，Plan A和Plan B各部署60台Spine交换机。每台Spine交换机提供8个上行端口和120个下行端口（均为400Gbps），下行端口中每个400Gbps端口对应一台Leaf交换机的上行400Gbps端口，规划十分精密。

整个集群的顶层架构由8台Core交换机组成，每台Core交换机的上行和下行端口分别为8个和120个400Gbps端口。下行端口中的每一个均对应一台Spine交换机，从而构成了完整的端到端链路。