上周深夜，隔壁组同事喊我过去看个问题：他们的AI训练任务在扩展到256卡时，吞吐直接掉了40%。
我连上交换机看了一眼流量矩阵，东西向流量全堵在几条核心链路上——典型的非均匀流量撞上了** oversubscription 瓶颈**。
他们用的正是个简单的三层CLOS，但配置没做流量均衡。
这让我想起，很多AI集群的网络问题，根源往往在拓扑选型和配置上。

---

为什么拓扑这么要命？

AI集群和传统数据中心不一样。
传统数据中心南北流量为主，训练集群里东西向流量能占到90%以上。
一次AllReduce通信，可能涉及成千上万个流同时爆发。
拓扑决定了这些流怎么走、会不会撞车、延迟是否均衡。
搞错拓扑，后面怎么调优都像在填坑。

---

Fat-Tree：老将依然能打

Fat-Tree（胖树）本质上是个多级CLOS。
它的核心思想就一条：任何时刻，任何节点对之间都有多条等成本路径。
这靠三层实现：边缘层（连接服务器）、汇聚层、核心层。

# 举个简单的配置示例：用ECMP做流哈希
switch.configure_ecmp(
    hash_fields=['src_ip', 'dst_ip', 'src_port', 'dst_port'],  # 尽量多字段，避免流极化
    algorithm='crc32'
)
# 这里踩过坑：早期只哈希src/dst IP，结果大流全挤一条链路上

胖树的优点是无阻塞、带宽一致、容错性好。
但代价是成本——交换机端口数随规模增长很快。
N个服务器，大概需要5N/4个交换机端口（假设3层）。
所以超大规模时，硬件成本会飙高。

调试胖树时，最常遇到的就是ECMP哈希不均匀。
有一次我们发现流量倾斜，查出来是哈希算法用的太简单，大量流的五元组特征相似。
后来改成包含Inner Ethernet头字段，才打散均匀。

---

Dragonfly+：玩的是全局连接

Dragonfly（蜻蜓）走的是另一条路：用高阶路由器减少跳数。
它把节点分成多个组，组内全连接，组间靠全局链路互联。
最大优势是低直径：任意两个节点最多两跳。

但蜻蜓有个致命问题：局部热点可能扩散到全局。
因为组间链路是共享的，一旦某个组流量爆炸，整个集群性能都会受影响。
这就是所谓吞吐受限于最忙的全局链路。

# 监控时要特别关注组间链路利用率
switch-monitor --links inter-group --threshold 70%
# 别等到跑满再查，到70%就该分析流量模式了

蜻蜓适合流量模式比较均匀的场景。
如果AI任务通信模式是高度规则（比如All-to-all），蜻蜓能发挥低延迟优势。
但如果流量突发性强，容易引发拥塞。

---

混合架构：现实的选择

现在很多实际部署用的是混合拓扑。
比如：Pod内用胖树，Pod间用蜻蜓。
这样既能在Pod内保证带宽，又能在Pod间减少跳数。

我们线上一个集群就是这么干的：

• 每个Pod 256卡，Pod内是3层胖树（无阻塞）。
• 8个Pod之间用蜻蜓式全局链路连接。
• 关键点：Pod间链路带宽要高于Pod内，否则跨Pod通信立刻成瓶颈。

# 跨Pod流量调度策略
if flow.is_cross_pod():
    schedule_with_adaptive_routing()  # 动态避让拥塞链路
else:
    schedule_with_ecmp()  # Pod内随便哈希，反正路径多

混合架构的配置复杂度高，得仔细设计路由策略。
有时候甚至要结合显式路由（比如SDN动态调路）和自适应路由。

---

选型到底看什么？

1. 规模：
   低于512卡，胖树简单可靠。
   超过3000卡，得认真考虑蜻蜓或混合，否则交换机成本吓人。

2. 流量模式：
   如果流量可预测、均匀，蜻蜓能降延迟。
   如果流量突发性强、模式复杂，胖树的均衡性更稳妥。

3. 容错需求：
   胖树路径多，单链路故障影响小。
   蜻蜓的全局链路故障可能割裂网络，需要额外保护。

4. 预算和运维能力：
   胖树交换机多，但配置相对标准。
   混合架构省硬件，但调试和运维更吃经验。

---

几条血泪经验

• 拓扑定了，性能天花板就定了。
  选型前一定用流量模型仿真，别凭感觉。

• 胖树别忘了调ECMP，蜻蜓别忘了监控全局链路。
  默认配置基本都是坑。

• 混合架构里，Pod大小是关键参数。
  太小了浪费全局链路，太大了Pod内成本高。
  我们试出来256~512卡/Pod是个甜点。

• 留足监控接口。
  拓扑越复杂，越需要细粒度流量可视。
  提前部署Telemetry，出问题时能救命。

• 别迷信论文里的峰值指标。
  实际部署总有各种非理想因素：线缆误差、散热导致的降频、固件bug……
  留20%余量，心里不慌。

---

最后说个真事：
曾经有个集群，拓扑设计完美，仿真结果漂亮，一上线性能却只有预期的60%。
查了三周，发现是交换芯片的Buffer配置没随拓扑改，浅Buffer遇上多路径，导致微突发丢包。
所以，拓扑不光是连线图，还涉及芯片级、固件级、配置级的全套匹配。
这东西，纸上得来终觉浅，调过才知道哪儿藏着雷。