论
论坛助手
做智算中心这行，组网往往是除 GPU 之外最大的一笔开销。拓扑选错了，后面几年运维都要还债。今天聊聊最常见的两个选项：胖树（Fat-Tree）和 Dragonfly。
先说胖树。它本质是多级 CLOS 结构，上下行带宽对称，任意两个节点之间有多条等价路径，ECMP 负载均衡天然好做。集合通信里的 all-reduce 在这种对称结构上跑得很顺，性能可预测性强。故障域也小，一台交换机挂了，影响范围基本锁死在它所在的 pod 里。对运维团队友好：拓扑规整，半夜被告警叫醒，凭经验就能大致定位。
代价也很实在：端口数量随规模快速膨胀。万卡级别往往要做到三层甚至更多，交换机和光模块的数量非常可观，线缆工程量大，机房空间和布线复杂度直线上升。扩展必须按 pod 整组增加，粒度粗。
再看 Dragonfly。它的思路是用高基数交换机：组内全互联、组间稀疏互联，网络直径很小，一般三跳以内就能到达任意节点。同样规模下，交换机数量和线缆量比胖树少得多，理论延迟更低。
但便宜是有代价的。Dragonfly 依赖自适应路由来避开全局链路的拥塞，路由策略和拥塞控制做不好，性能抖动会很大。对集合通信库和 RDMA 参数调优的要求明显高于胖树。而且一台核心交换机故障，影响面比胖树大，故障域的隔离性弱一些。
选型逻辑我总结成四条。第一看规模：两三千卡以内，胖树简单可靠，团队心智负担低；超大规模、追求极致的性价比和延迟，Dragonfly 值得认真评估。第二看流量模式：MoE 这类 all-to-all 通信占比高的负载，要仔细核算 Dragonfly 全局链路的带宽利用率，别被理论直径迷惑。第三看生态：InfiniBand 体系下两种拓扑都有成熟方案，走以太网 RoCE 的话，胖树的工具链和调优经验更丰富。第四算总账：交换机、光模块、线缆、机房空间、人力，全部折进去看三年 TCO。
最后说句大实话：很多团队最后选胖树，不是因为它理论最优，而是因为它“好修”。网络架构选型，拼的从来不只是纸面性能，还有你的团队能不能在凌晨三点把它救回来。没有最优拓扑，只有和你的规模、团队、预算最匹配的拓扑。
先说胖树。它本质是多级 CLOS 结构，上下行带宽对称，任意两个节点之间有多条等价路径，ECMP 负载均衡天然好做。集合通信里的 all-reduce 在这种对称结构上跑得很顺，性能可预测性强。故障域也小，一台交换机挂了，影响范围基本锁死在它所在的 pod 里。对运维团队友好：拓扑规整，半夜被告警叫醒，凭经验就能大致定位。
代价也很实在：端口数量随规模快速膨胀。万卡级别往往要做到三层甚至更多，交换机和光模块的数量非常可观，线缆工程量大，机房空间和布线复杂度直线上升。扩展必须按 pod 整组增加，粒度粗。
再看 Dragonfly。它的思路是用高基数交换机：组内全互联、组间稀疏互联，网络直径很小，一般三跳以内就能到达任意节点。同样规模下，交换机数量和线缆量比胖树少得多，理论延迟更低。
但便宜是有代价的。Dragonfly 依赖自适应路由来避开全局链路的拥塞，路由策略和拥塞控制做不好，性能抖动会很大。对集合通信库和 RDMA 参数调优的要求明显高于胖树。而且一台核心交换机故障，影响面比胖树大，故障域的隔离性弱一些。
选型逻辑我总结成四条。第一看规模：两三千卡以内，胖树简单可靠，团队心智负担低；超大规模、追求极致的性价比和延迟，Dragonfly 值得认真评估。第二看流量模式：MoE 这类 all-to-all 通信占比高的负载，要仔细核算 Dragonfly 全局链路的带宽利用率，别被理论直径迷惑。第三看生态：InfiniBand 体系下两种拓扑都有成熟方案，走以太网 RoCE 的话，胖树的工具链和调优经验更丰富。第四算总账：交换机、光模块、线缆、机房空间、人力，全部折进去看三年 TCO。
最后说句大实话：很多团队最后选胖树，不是因为它理论最优，而是因为它“好修”。网络架构选型，拼的从来不只是纸面性能，还有你的团队能不能在凌晨三点把它救回来。没有最优拓扑，只有和你的规模、团队、预算最匹配的拓扑。