2. Arista HPC网络架构总览
在HPC集群中，网络拓扑不是“把交换机连起来”这么简单，它直接决定了集合通信（AllReduce、AllGather）的跳数、对分带宽、故障域大小以及布线成本。Arista在HPC场景下主推的几种拓扑——Spine-Leaf、CLOS、Rail-Optimized、Dragonfly——本质上是在端口数、收敛比、跳数、线缆复杂度四个维度上做不同取舍。理解这些取舍，才能为GPU集群、存储网络或混合负载选对架构。
一、Spine-Leaf：通用东西向流量的基础骨架
Spine-Leaf是两层CLOS的工程化实现。Leaf交换机下联计算节点，上联所有Spine；Spine之间不互连，只做转发。任意两个Leaf之间恰好经过“Leaf→Spine→Leaf”三跳，跳数恒定，延迟可预测。以Arista 7060X系列（32×400G）为例，若Leaf用32端口，其中20个下联节点、12个上联Spine，则收敛比约为20:12≈1.67:1；若追求无收敛，则需Leaf上联端口数等于下联端口数，此时Spine数量由Leaf数量决定。
Spine-Leaf的适用场景是通用HPC与AI混合负载：节点间通信模式不固定，既有MPI的邻居交换，也有参数服务器的随机访问。它的优势是ECMP（等价多路径）天然负载均衡，任意链路故障后收敛快；缺点是当规模扩大到数千节点时，Spine层端口需求急剧上升，且所有跨Leaf流量都要经过Spine，对Spine的缓冲和转发能力要求高。
二、CLOS：从三层到多级，解决端口数瓶颈
当单层Spine端口不足以支撑Leaf数量时，CLOS扩展为三层：Leaf→Spine→Super-Spine。每一级都保持“下级所有节点上联到上级所有节点”的完全二分连接。三层CLOS的跳数变为五跳，但可支撑的节点数从O(p²)提升到O(p³)。Arista的典型做法是：Leaf用32×400G，Spine用64×400G，Super-Spine用128×400G，逐级放大端口密度。
选型依据很直接：节点规模超过单层Spine可容纳的Leaf数时，必须上三层CLOS。但要注意，每增加一级，延迟增加约1～2微秒，且布线复杂度呈指数上升。对于延迟敏感的紧耦合HPC，三层CLOS通常只在万卡以上集群中才值得引入。
三、Rail-Optimized：为GPU集合通信量身定制
Rail-Optimized的核心思想是按GPU编号分轨。假设每台服务器有8块GPU，编号0～7。所有服务器的GPU0接入同一台Rail交换机，GPU1接入另一台，以此类推。这样，不同服务器上相同编号的GPU之间只有一跳，而AllReduce的环形算法恰好是“同号GPU先做Reduce-Scatter，再跨轨做AllGather”。
以NCCL的Ring AllReduce为例，8卡服务器内通过NVLink完成本地Reduce，然后同轨GPU通过Rail交换机交换梯度，最后跨轨通过Spine完成AllGather。这种拓扑把最频繁的通信放在一跳路径上，显著降低延迟。Arista的Rail-Optimized方案通常配合400G/800G端口，每轨一台交换机，轨间通过Spine互联。适用场景是大规模GPU训练集群，尤其是NCCL通信占主导的负载。缺点是轨间带宽受Spine收敛比限制，且GPU编号必须与布线严格对应，运维复杂度高。
四、Dragonfly：低直径、高扩展的组间互联
Dragonfly把节点分成若干“组”，组内用全互连或高密度交换机连接，组间用全局链路连接。任意两组之间最多经过“组内→全局→组内”三跳，网络直径小。Arista在Dragonfly场景中通常用高基数交换机（如7800R系列）作为组内核心，组间用少量长距链路。它的优势是可扩展性极强，适合万卡以上集群；缺点是全局链路数量有限，组间通信容易成为瓶颈，且路由需要自适应算法避免拥塞。
选型时，Dragonfly适合通信局部性明显的负载：大部分通信发生在组内，组间通信占比低。如果AllReduce是全局同步的，Dragonfly的组间链路会成为瓶颈，此时Rail-Optimized或三层CLOS更合适。
五、选型决策：从规模、通信模式到收敛比
实际选型可以按以下顺序判断：
- 节点规模≤2000，通信模式混合：优先Spine-Leaf，收敛比控制在2:1以内，Spine用64×400G，Leaf用32×400G。
- GPU集群，NCCL为主，规模≤4000：Rail-Optimized，每轨一台交换机，轨间Spine收敛比1:1或2:1。
- 规模≥3000，且需要三层扩展：三层CLOS，Leaf→Spine→Super-Spine，逐级端口密度递增。
- 万卡以上，通信局部性强：Dragonfly，组内高基数交换机，组间全局链路按1:4～1:8收敛。
最后需要强调：拓扑选择不是孤立的，它必须与路由协议（BGP/OSPF）、ECMP哈希策略、QoS队列、拥塞控制（DCQCN）协同设计。例如Rail-Optimized中，同轨流量走直连，跨轨流量走Spine，若ECMP哈希不区分轨号，可能导致跨轨流量抢占同轨带宽。Arista EOS支持基于RoCEv2的流级负载均衡，可在Rail拓扑中按GPU编号做哈希，确保同轨流量优先走直连路径。选型时，建议先用小规模测试验证NCCL AllReduce的带宽和延迟，再按实测结果调整收敛比和轨间链路数量。