亚马逊的工程团队最近抛出了一份关于超大规模数据中心扁平化网络架构的深度技术分享，主笔人正是AWS的"首席架构师"James Hamilton。文章不长，但信息密度极高——它讲的不是"我们应该怎么做网络"，而是"当你的集群规模大到几十万张加速卡同时跑梯度同步时，哪些传统设计假设必须被推翻"。核心结论很反直觉：在大规模AI训练负载下，把网络"做厚"反而不如"做扁"。
传统三层Clos架构在中小规模数据中心里是黄金标准——接入、汇聚、骨干各司其职，路由策略清晰，运维也成熟。但当单集群规模膨胀到支撑万卡甚至十万卡级别的AI训练时，每一跳额外的交换机层级都意味着带宽收缩、延迟叠加和更复杂的等价多路径（ECMP）哈希冲突。亚马逊的工程实践指向一个方向：尽可能压缩拓扑深度，用更扁的物理和逻辑结构换取更确定的通信性能。配套的路由策略也被同步简化——收敛更快、故障域更小、对训练Job的尾部延迟影响更可控。
这套思路对正在自建AI基础设施的团队来说是个值得对照的参考系。如果你正面临"集群一大就掉速、训练Job尾部慢节点拖垮整体"的痛点，问题的根源未必在加速卡互联本身，上层的网络拓扑和路由收敛策略往往才是真正的瓶颈。亚马逊给出的解法不是堆更贵的交换机，而是反过来——用更简洁的架构，把复杂性从运行时转移到规划期。这是一种工程哲学的转变，也是一份给所有大规模AI基础设施从业者的清醒提醒。
