📚 课程目录第2章 Arista AI集群以太网架构总览

2. Arista AI集群以太网架构总览

在AI集群网络中，架构选择直接决定了GPU之间能否高效交换梯度、参数和激活值。Arista面向AI场景的以太网方案并非单一拓扑，而是围绕Spine-Leaf、Rail-Optimized和分布式解耦三种思路展开。理解它们的适用边界，比记住名词更重要。

Spine-Leaf：通用Clos架构的AI适配

Spine-Leaf本质是两级Clos网络。Leaf交换机下联GPU服务器，Spine交换机负责Leaf之间的全互联。以典型参数为例：若集群有128台GPU服务器，每台服务器配置8张400G网卡，Leaf层采用32端口400G交换机，则每台Leaf可下联16台服务器（每台服务器双上联），共需8台Leaf。Spine层若采用64端口400G交换机，8台Leaf各提供2个400G上联，则Spine只需1台即可满足无阻塞，但实际部署中通常采用2台Spine做冗余，形成1:1收敛比。

Spine-Leaf的优势在于任意节点间等距，适合AllReduce、AllGather等集合通信模式。但AI流量具有明显的突发性和长流特征，传统ECMP哈希在流数较少时容易产生哈希极化，导致部分链路拥塞而其他链路空闲。Arista的解决方案是在Leaf和Spine上启用动态负载均衡（DLB）或自适应路由（Adaptive Routing），根据链路实时利用率重新分配流量。配置示例如下：

interface Ethernet1/1
   description Uplink-to-Spine1
   mtu 9214
   no switchport
   ip address 10.0.1.1/31
!
interface Ethernet1/2
   description Uplink-to-Spine2
   mtu 9214
   no switchport
   ip address 10.0.1.3/31
!
router bgp 65001
   neighbor 10.0.1.0 remote-as 65000
   neighbor 10.0.1.2 remote-as 65000
   maximum-paths 64
   address-family ipv4
      neighbor 10.0.1.0 activate
      neighbor 10.0.1.2 activate

这里MTU设为9214是为了承载RoCEv2的无损流量，BGP用于交换路由，maximum-paths 64确保多路径负载均衡。判断Spine-Leaf是否健康，关键看PFC暂停帧计数和ECN标记比例：若某条上行链路PFC持续增长，说明该路径已拥塞，需要检查哈希策略或启用DLB。

Rail-Optimized：面向GPU Rail的定向优化

在NVIDIA GPU服务器中，每台服务器通常有8张GPU，每张GPU对应一张网卡，形成8个“Rail”。Rail-Optimized架构的核心思想是：同一Rail内的GPU网卡连接到同一组Leaf交换机，不同Rail之间通过Spine或专用互联层通信。这样，AllReduce中的Ring通信可以尽量在Rail内完成，减少跨Spine跳数。

以8 Rail为例，每台服务器有8张400G网卡，分别标记为rail0至rail7。Rail0的所有服务器网卡接入Leaf-R0组，Rail1接入Leaf-R1组，依此类推。每组Leaf再上联到Spine。这种结构下，同一Rail内的GPU通信只需经过Leaf，延迟最低；跨Rail通信才经过Spine。对于Tensor Parallelism（TP）通常在同一服务器内或同Rail内完成，而Data Parallelism（DP）的AllReduce则跨Rail，此时Spine层带宽成为关键。

Rail-Optimized的选型依据是GPU通信模式。若训练任务以TP为主，Rail内带宽需求高，应确保Leaf上行收敛比接近1:1；若以DP为主，Spine层需要更大带宽。Arista建议在Rail-Optimized中启用RoCEv2 with PFC+ECN，并在Leaf上配置WRED阈值，例如ECN标记阈值设为链路带宽的30%，最大标记概率10%。

分布式解耦架构：控制与转发分离

分布式解耦架构是Arista面向超大规模AI集群的进阶方案。其核心是将控制平面集中化（如使用EVPN/VXLAN或Segment Routing），而数据平面保持分布式转发。在AI集群中，这意味着Spine层可以只负责高速转发，Leaf层负责策略和隧道终结。解耦的好处是：当集群从千卡扩展到万卡时，Spine层可以独立扩展，而不影响Leaf的接入逻辑。

具体实现上，Arista支持EVPN Multihoming用于服务器双归接入，以及SRv6或MPLS用于流量工程。例如，在Spine上配置SRv6 locator，Leaf将AI流量封装为SRv6路径，指定经过特定Spine节点，从而绕过拥塞链路。这种架构的选型依据是集群规模和管理域：千卡以下Spine-Leaf足够；千卡到万卡可考虑Rail-Optimized；万卡以上且需要多租户隔离时，分布式解耦架构更合适。

选型依据与实操判断

三种架构并非互斥，实际部署中常混合使用。例如，在Rail-Optimized的Spine层引入EVPN解耦，既保留Rail内低延迟，又获得多租户隔离能力。选型时需回答三个问题：集群规模多大？千卡以下Spine-Leaf性价比最高；千卡到万卡优先Rail-Optimized；万卡以上考虑分布式解耦。主要通信模式是什么？TP为主则Rail内带宽要充足，DP为主则Spine层不能成为瓶颈。运维能力如何？Spine-Leaf配置简单，Rail-Optimized需要规划Rail映射，分布式解耦需要EVPN/SRv6运维经验。

实操建议：在Arista EOS上验证架构是否达标，可执行 show interfaces counters errors 查看PFC和ECN计数，执行 show ip route summary 确认多路径是否生效。若PFC暂停帧在5分钟内增长超过1000，说明拥塞严重，需调整DLB或WRED阈值。

最后需要强调：架构选型不是一次性决策。随着集群从训练初期扩展到后期，Rail映射可能变化，Spine层可能需要从2台扩展到4台。Arista的CloudVision可以统一管理多架构混合部署，通过配置漂移检测确保所有Leaf的MTU、PFC、ECN参数一致。判断架构是否健康，最终看集合通信完成时间和链路利用率方差：若AllReduce时间随节点数线性增长，说明架构存在瓶颈；若各上行链路利用率方差超过20%，说明负载均衡需要优化。