Summary

  • Adel Iazzag 的 NANOG 98 原讲稿指出，MoE 的 AllToAll 在每个专家层进行两次，流量目的地不均匀，多个发送方会挤向一个端口，而拥塞端口会变化。
  • 他要求在真实网络上测试 AllToAll、让调度器知道网络拓扑，并按多对一流量验证拥塞控制；一张平均利用率图表不能替代这些决定。

今天最忙的端口，下一层可能就失业。Adel Iazzag 在 NANOG 98 演讲里讲的是专家混合模型的网络账：token 被送往选中的专家 GPU，返回时再穿过网络。多个发送方可能压向同一个目的地；下一轮专家选择又让热点换端口。只按固定“最热链路”扩容，追的是上一场堵车。

32 页原讲稿把训练流量拆开看。数据并行用 AllReduce 汇总梯度，许多上行链路一起亮起、一起安静。流水线并行在相邻阶段交换激活值和梯度，利用率很低时，后段仍可能等前段交货。张量并行在同一小组 GPU 之间每层频繁交换；Iazzag 主张把这组通信留在 scale-up 域内。MoE 则发起 AllToAll，流量目的地不均匀，形成移动的多对一入流。

这些模式不会向交换机提出同一份需求。讲稿用 256 张 GPU 举例：环形 AllReduce 的通信步骤为 510，树形为 16。这是算法步骤示意，不是实测运行秒数。选择集合通信算法、消息大小和 GPU 的位置，都会改写链路上发生的事。先买更粗的管子，无法决定工作究竟从哪儿流过。

Iazzag 的网络设计要求很具体：同一编号的 NIC 对齐到相同的 leaf；每张 GPU 同时满速发送时预留一比一带宽；多对一到达场景要实际测试拥塞控制；普通 ECMP 不够时考虑分组或 flowlet 分散。调度器还必须获得拓扑。它安排流水线相邻阶段、决定张量组是否被拆到机架外，也决定下一批专家 GPU 的入流会聚在哪里。网络团队接到的是调度器已经写好的流量剧本。

讲稿没有给出某个生产集群的故障记录或闲置 GPU 费用。它给出可执行的验证：在自己的 fabric 上运行 AllToAll，记录热点在端口间怎样移动，再把结果与 GPU 放置和拥塞控制对照。AI 训练的成本不只写在 GPU 采购单上；任务等网络的时间，也由这些路径决定。

来源：NANOG 98 会议页 · Iazzag 原讲稿。