SIGCOMM ’24: ACM SIGCOMM 2024 Conference, August 4–8, 2024, Sydney, NSW, Australia

https://dl.acm.org/doi/10.1145/3651890.3672265

一、研究背景与动机：传统数据中心网络为何不适合 LLM 训练

大语言模型的训练对数据中心网络提出了全新的挑战，传统面向通用云计算设计的网络架构已不再适用。阿里巴巴在实际生产中观察到两个根本性的不匹配。

第一个不匹配体现在流量模式上。通用云计算产生数百万条连续、低利用率的小流（通常低于网卡容量的 20%），整体流量模式平稳且缓慢变化。而 LLM 训练截然不同——每台主机仅产生少量连接（几十到几百条），但这些流是周期性的、突发性的大象流，瞬间就能占满网卡全部 400Gbps 的容量。这种低熵、高突发的流量特征使得传统数据中心广泛采用的 ECMP 负载均衡方案失效。ECMP 依赖大量流的哈希值在多条等价路径上均匀分布，而当流的数量极少且每条流都是大象流时，哈希极化（hash polarization）导致某些链路严重拥塞而其他链路空闲。更严重的是，传统三层 Clos 架构中大象流需要经过三次级联哈希（ToR、汇聚层、核心层），加剧了负载不均衡。

第二个不匹配体现在故障敏感性上。LLM 训练是一个同步过程，所有 GPU 协同完成每个迭代，任何一块 GPU 或主机的异常都可能延迟甚至崩溃整个训练过程。生产数据显示，LLM 训练中的故障成本是通用云计算的 20 倍——一个使用 3000 块 GPU 的训练任务每小时成本约 2 万美元，一次故障回退到数小时前的检查点意味着约 3 万美元的直接损失。而 ToR 交换机的单点故障是最致命的，因为一台 ToR 故障会导致数十甚至上百台主机不可用。阿里巴巴的运营数据显示，每月约 0.057% 的 NIC-ToR 链路故障，约 0.051% 的 ToR 交换机发生严重错误，每天还有 5000-60000 次链路抖动事件。

二、HPN 整体架构：两层双平面取代三层 Clos

基于上述挑战，阿里巴巴设计并部署了 HPN（High Performance Network），一种专为 LLM 训练打造的数据中心网络架构。HPN 的目标有三个：扩展性（单 Pod 支持 15000 块 GPU）、高性能（最小化网络跳数和 ECMP 哈希次数）、以及 ToR 单点故障容错。

HPN 将网络分为前端网络和后端网络。后端网络承载训练过程中的通信流量，前端网络处理管理、推理和存储等其他流量，两者物理隔离以确保训练流量不受干扰。每台主机配备 8 块 GPU，通过 NVLink 高带宽互连（400-900GBps 双向），同时配备 9 块双端口 200Gbps 网卡，其中 8 块分别服务 8 块 GPU 接入后端网络（每块 GPU 独享 400Gbps RDMA 带宽），1 块接入前端网络。每块网卡的两个端口分别连接到不同的 ToR 交换机，形成双 ToR 设计。

HPN 的后端网络采用两层双平面架构而非传统的三层 Clos，通过四个关键机制逐步扩大网络规模：双 ToR 使规模翻倍，51.2Tbps 单芯片交换机充分利用端口容量，Rail-Optimized 拓扑使规模扩大 8 倍，双平面设计再次使规模翻倍。最终实现单层网络（Segment）容纳 1024 块 GPU，单 Pod 容纳 15000 块 GPU——这一规模在传统架构中需要三层 Clos 才能实现。生产数据显示 96.3% 的训练任务使用不超过 1000 块 GPU，因此绝大多数任务可以在单个 Segment 内完成，享受最优网络性能。

三、非堆叠双 ToR：从根源消除单点故障

传统数据中心普遍采用单 ToR 设计，即每块网卡的两个端口通过一根线缆连接到同一台 ToR 交换机。这种设计在 ToR 故障时会导致其下所有主机断连。业界已有的堆叠双 ToR 方案（如 vPC、M-LAG）将两台 ToR 通过直连链路同步状态，看似能解决问题，但阿里巴巴在三年生产实践中发现，堆叠双 ToR 引入的故障反而占到了传统数据中心全部严重故障的 40% 以上。典型问题包括：一台 ToR 数据面故障但控制面正常时，另一台 ToR 因无法同步而被迫关闭自身，导致整机架宕机；双 ToR 升级过程中新旧版本 RPC 不兼容，70% 的升级无法满足 ISSU 的版本差异假设。

HPN 提出了非堆叠双 ToR 方案，彻底去掉了两台 ToR 之间的直连链路，使两台 ToR 完全独立运行。实现这一方案的核心难题在于如何让两台独立的 ToR 在主机看来像是一台设备。HPN 通过与交换机厂商深度合作，定制了 LACP 模块：两台 ToR 使用 RFC 预留的虚拟路由器 MAC 地址作为统一的系统标识，并通过端口偏移算法生成不同的端口 ID。在故障处理方面，HPN 将所有 ARP 转换为 /32 主机路由注入 BGP，当某条 NIC-ToR 链路故障时，对应的主机路由被撤回，BGP 收敛自动将流量切换到另一台 ToR。同时关闭二层广播并实现 ARP 代理，确保 Segment 内部流量也能通过三层路由正确转发。

四、Tier1 设计：单 Segment 容纳 1024 块 GPU

HPN 在 Tier1 层采用 51.2Tbps 单芯片交换机。选择单芯片而非多芯片机框式交换机的原因是：阿里巴巴的长期运营经验表明，尽管单芯片交换机数量是多芯片交换机的 32.6 倍，但多芯片交换机的严重硬件故障总数反而高出 3.77 倍。根因在于多芯片交换机本质上是分布式交换系统，内部 Fabric、芯片间交互和芯片-CPU 通信都可能引发故障。

51.2Tbps 芯片带来了散热挑战——功耗比上一代 25.6Tbps 芯片增加了 45%，而最大结温保持不变。现有的热管和标准均温板方案都无法支撑芯片在全功率下持续运行。HPN 设计了优化的均温板散热器，通过改进芯片中心区域的毛细结构和增加烧结铜柱，使散热效率提升 15%，彻底解决了过温保护导致的停机风险。

结合 Rail-Optimized 拓扑，同一 Rail 的网卡连接到同一组双 ToR 交换机，不同 Rail 之间通过主机内部 NVLink 进行中转。每组双 ToR 服务 128 块 GPU，16 台 ToR 共同连接 1024 块 GPU 构成一个 Segment，大幅减少了需要跨汇聚层的流量。

五、Tier2 设计：双平面消除哈希极化

如果在 Tier2 层简单部署典型 Clos 拓扑，双 ToR 带来的流量汇聚仍然会导致哈希极化。HPN 的生产测量显示，在训练 GPT-3 175B 变体时，双 ToR 中两个下行端口的负载差异可达 3 倍。

HPN 的解决方案是双平面设计：将每组双 ToR 中的两台交换机分别归入两个独立的网络平面。一旦流量从源网卡的某个端口进入某个平面，其在 Pod 内的转发路径就完全确定，不再经过任何 ECMP 哈希。部署双平面后，两个端口的入向流量变得均衡，ToR 下行端口的队列长度下降了 91.8%，跨 Segment 流量性能提升了 71.6%。

双平面还大幅简化了路径选择的搜索空间。在 HPN 中，搜索不相交路径仅需检查每台 ToR 交换机的 60 条上行链路，复杂度为 O(60)。相比之下，NVIDIA SuperPod 的三层架构需要搜索 O(4096) 条路径，Google Jupiter 需要搜索 O(2048) 条路径。HPN 在集合通信库中实现了基于不相交路径的负载均衡方案：利用 RePaC 技术精确计算每条路径的哈希结果，建立多条不相交的 RDMA 连接，并通过跟踪每条连接上未完成的 WQE 字节数来选择最空闲的路径。在 512 块 GPU 上并发运行四个 AllReduce 任务的测试中，这一优化路径选择方案将集合通信性能提升了 34.7%。

六、实验评估：训练吞吐量提升 14.9%

HPN 已在阿里云生产环境中部署超过八个月，服务数十家客户的数千个模型训练任务。论文将 HPN 与上一代训练网络架构 DCN+（带双 ToR 的传统三层 Clos 全对分带宽网络）进行了对比。

在端到端训练性能方面，阿里云一个自有的大模型在 2300 多块 GPU 上训练，从 DCN+ 迁移到 HPN 后，端到端训练性能提升了 14.9%。汇聚层交换机的统计显示跨 Segment 流量平均减少了 37%，队列拥塞显著缓解。在代表性模型的训练中，LLaMa-7B、LLaMa-13B 和 GPT3-175B 分别获得了 7.9%、14.4% 和 6.3% 的性能提升。

在集合通信性能方面，HPN 在 448 块 GPU 上将 AllReduce 性能提升了最高 59.3%，Multi-AllReduce（用于 TP=8 的梯度同步）性能提升了最高 158.2%。

在可靠性方面，八个月的生产运营中未观察到任何 ToR 相关的单点故障。注入链路故障测试显示，单 ToR 设计下链路故障会导致训练立即停止且可能无法恢复，而双 ToR 设计下仅产生 6.25% 的性能下降，修复后立即恢复正常。链路抖动测试中，单 ToR 导致训练停顿超过 9 秒，而双 ToR 的性能影响几乎可以忽略。

七、设计取舍与经验教训

论文分享了多项有价值的设计决策和实战经验。关于为何不在 Tier2 采用 Rail-Only 拓扑来进一步扩大规模：虽然 Rail-Only 可以将单 Pod 扩展到 12 万块 GPU，但它要求所有流量都在同一 Rail 内，这在 MoE 模型训练（需要跨 Rail 的 All-to-All 通信）和多租户场景下是不可接受的限制。关于存储集群的位置：虽然后端网络带宽更高（3.2Tbps vs 400Gbps），但将存储放在后端网络会引入跨网络代理的复杂性、影响训练性能波动、并占用宝贵的 ToR 端口，因此最终选择放在前端网络。关于布线复杂性：HPN 的 Rail-Optimized 和双平面设计使布线更加复杂，初期施工人员频繁接错线缆，需要通过 INT 探测逐跳验证每条路径是否与蓝图一致。

一个值得关注的物理设计决策是将单个 Pod 完整容纳在一栋数据中心建筑内。阿里云每栋建筑的功率约束为 18MW，恰好可以容纳约 15000 块 GPU。这使得 Pod 内所有光纤长度控制在 100 米以内，可以使用成本低 70% 的多模光收发器替代单模光收发器。

八、总结与意义

HPN 是目前公开发表的最完整的 LLM 训练专用数据中心网络架构之一。它的核心洞察是：LLM 训练的流量模式与通用云计算存在根本性差异，网络架构必须针对低熵、高突发、少连接的大象流特征进行专门设计。通过非堆叠双 ToR、Rail-Optimized 拓扑和双平面架构的协同设计，HPN 在降低网络成本约 30% 的同时将训练吞吐量提升了 14.9%，并从根源上消除了 ToR 单点故障。对于构建下一代 AI 训练基础设施，HPN 在拓扑设计、故障容错和负载均衡三个维度提供了经过大规模生产验证的解决方案。