阿里HPN-用于大型语言模型训练的数据中心网络

 

阿里巴巴HPN:用于大型语言模型训练的数据中心网络

   探索大规模语言模型训练新方法：阿里巴巴HPN数据中心网络论文。

   摘要

本文介绍了阿里云用于大型语言模型(LLM)训练的数据中心网络HPN。由于LLM和一般云计算之间的差异(例如，在流量模式和容错性方面)，传统的数据中心网络不太适合LLM训练。这就要求我们专门为LLM培训设计一种新的数据中心网络架构。

与一般云计算产生数百万个小流量(例如，低于10Gbps)不同，LLM训练在每个主机上产生少量周期性的、突发的流量(例如，400Gbps)。LLM训练的这一特性使得传统数据中心常用的负载均衡方案等成本多路径(Equal-Cost Multi-Path, ECMP)容易出现哈希极化，从而导致流量分布不均等问题。HPN引入了一种两层双平面架构，能够在一个Pod内互连15K gpu，通常由传统的3层Clos架构容纳。

这种新的架构设计不仅通过减少ECMP的出现来避免哈希极化，而且大大减少了路径选择的搜索空间，从而使我们能够精确地选择能够容纳大象流的网络路径。LLM训练中的另一个挑战是，它要求gpu同步完成迭代，这使得它对单点故障(通常发生在ToR上)更加敏感。HPN提出了一种新的双tor设计，通过解决第二层同步挑战来取代传统数据中心网络中的单tor。HPN已经在我们的生产中使用了8个多月。我们分享我们在激励、设计和构建HPN方面的经验，以及HPN在生产中的操作经验。

   1 介绍

大型语言模型(Large Language Model, LLM)是一种使用海量数据集进行训练的超大型深度学习模型。一个具有数千亿参数的LLM的训练依赖于一个大规模的分布式训练集群，通常配备了数千万个GPU。由于其独特的特点，对数据中心网络的设计提出了新的挑战。

问题1:流量模式。LLM训练的流量模式在(1)低熵和突发流量方面与一般云计算的流量模式不同。具体来说，通用云计算产生了数百万的流量，这赋予了网络高熵。每个流都是连续的、低利用率的(例如，通常低于NIC容量的20%)，如图1所示。相反，LLM训练产生的流量很少，但具有周期性的突发性，导致网络的熵低，利用率高。突发可以直接达到NIC容量，在我们的生产集群中是400gbps。

这种流量模式破坏了传统数据中心网络中广泛部署的等成本多路径(ECMP)负载均衡方案。由于ECMP采用哈希算法在所有等效路径上均匀分配流量，因此ECMP在高熵低利用率流量模式的网络(即传统的数据中心网络)中可以很好地工作，但在LLM训练的情况下则不适用。由于LLM训练的流量模式，我们的传统数据中心网络最近遇到了上述流量模式导致的多个性能问题。

问题2:对故障的敏感度更高，特别是单点故障。LLM训练是一个同步过程，所有GPU协同完成一系列迭代;因此，任何GPU中的异常都可能延迟或崩溃整个训练过程。这意味着LLM训练比传统的云计算对故障更加敏感。

我们发现，对LLM培训影响最大的是与机架顶(Top-of-Rack, ToR)相关的单点故障，这可能会影响各种GPU。此外，LLM培训中的故障是昂贵的。我们的生产统计数据显示，LLM培训中的错误会比在一般云计算中发生时给公司造成20倍多的成本。

我们的亮点：阿里巴巴高性能网络(HPN)。本文展示了我们独特的数据中心网络架构，专为LLM培训而设计。相较于传统架构，HPN在诸多方面展现出卓越性能，包括但不限于：

HPN引入了一种创新的ToR部署方案——非堆叠双ToR设计，旨在消除ToR单点故障风险。相较于堆叠双ToR解决方案，这种非堆叠设计消除了交换机间的直接同步，极大地提升了大规模部署的稳定性和可靠性。

通过采用最新的51.2Tbps交换芯片和优化铁路网络，我们成功地将1K GPU集成到一级网络中，为96.3%的培训工作提供了卓越的网络性能。HPN在2层双平面架构中容纳了15K GPU,这使得训练集群的规模得以保持在传统水平，而非采用3层Clos架构，从而显著降低了ecmp的发生概率。

这种设计特性不仅消除了聚合层中的哈希极化(通过双平面设计),还将选择承载不同流量的理想路径的搜索空间减少了1-2个数量级。

我们深入探讨了支持大规模推理和HPN设计、部署及运行的经验。HPN已成功部署并在生产环境中运行超过8个月，未出现任何ToR单节点故障。实践证明，采用HPN的LLM训练吞吐量比传统数据中心网络高达14.9%。

   2 背景与我们的目标

2.1 大型语言模型(LLM)训练

"LLM,一个庞大的模型，拥有超过100个B参数，由多个层次构成。它的训练需求惊人，数十到数千个GPU同步运作。为了有效协调，主流训练框架(如Megatron-LM和Deepspeed)采用混合并行策略，确保资源充分利用。"

"DP,即数据并行。模型的完整拷贝被均匀分布在所有GPU上，训练数据同步更新，每次迭代，通过AllReduce技术在各GPU间梯度达成统一。"

管道并行性(PP)是一种将模型划分为多个阶段的方法，每个阶段由一系列连续的模型层组成，并由不同的GPU提供服务。这种方法使得每个GPU能够更有效地处理输入数据，从而提高整个模型的性能。

张量并行性(TP)是一种模型优化技术，它允许整个模型或其中的每一层在GPU上进行水平分割。这种方法使得每一层都在一组GPU上分布，从而提高了计算效率。在每次迭代过程中，同一TP组中的GPU通过AllReduce/AllGather协议同步计算输出和梯度，进一步加速了模型的训练过程。

"鉴于大规模训练需求及多种并行策略，LLM训练中的流量模式与传统DNN训练显著不同，呈现出独特的弹性云计算特征。"

2.2 LLM训练中的流量模式

传统的数据中心网络架构(如胖树)主要是为通用的、弹性的云计算设计的。我们观察到，LLM训练的流量模式与通用云计算的流量模式不同。网络利用率的周期性突发。在我们的生产中，通用云计算产生了数百万的流量，流量利用率一般保持在20%以下。整体的流量格局是相对连续和稳定的，以小时为单位缓慢变化(如图1所示)，相反，LLM训练产生的流量很少，但会周期性突发，如图2和图3所示。

更具体地说，图2显示了在我们的生产LLM培训中NIC (2×200Gbps)的吞吐量。NIC周期性传输大量数据，瞬间达到400Gbps的网络容量，传输时间从几秒到几十秒不等。这种流量模式源于对梯度同步的需求。典型的LLM训练涉及一系列迭代，并且在每次迭代期间，需要在不同的并行组(每个组有许多gpu)之间进行数据同步。

突发发生在每次训练迭代的后向阶段，此时所有数据并行组需要通过AllReduce集合通信操作同步梯度。

网络利用率的突然爆发意味着LLM训练需要极高的网络带宽。因此，我们需要确保用于LLM训练的网络能够为突发提供足够的物理带宽，以避免丢包。此外，流量的同步性表明LLM训练对长尾延迟特别敏感。任何长尾流都将成为整个集体通信操作完成的障碍，使所有并行组暂停。少量的流量。

如图1所示，一般的云计算实例通常会产生数十万的连接;相反，LLM训练中的每个节点产生的连接非常少。如图3所示，一个GPU只使用几十到几百个连接。结合前面提到的突发性高的网络利用率在训练过程中，每个流需要发送的实际数据量是可观的。传统的数据中心对于LLM训练的流量模式不太适合。

传统的数据中心网络采用ECMP作为负载均衡方案。ECMP假设，当网络中有大量流量时，哈希算法可以有效地将流量均匀分布在所有等效路径上。

这个假设在一般的云计算流量模式下成立，通常会产生数百万条流量(如图1所示)。然而，这样的假设在LLM训练的情况下不再有效，LLM训练涉及几个大流量(也被称为具有大象流分布)。在我们使用传统数据中心进行LLM训练的实践中，由于哈希极化，我们已经遇到了多个性能问题，严重影响了LLM的训练效率。

更糟糕的是，由于传统数据中心网络的3层架构性质，一个大象流的转发将经过3次哈希(即ToR、Aggregation和Core layer)。由于每个哈希的输入(即流的五元组)保持不变，这种“级联”哈希的效果可能会导致更严重的负载不平衡(即哈希极化)。我们已经在我们的生产中观察到许多由哈希极化引起的负载不平衡情况，特别是在跨pod通信场景中，流量需要通过所有三层交换机才能到达目的地。

2.3 LLM训练对故障很敏感

针对大规模机器学习(LLM)培训，故障带来的影响远超普通云计算。LLM训练具有高度敏感性，一次GPU或主机故障便可能导致迭代中断，甚至整个训练过程瘫痪。这是因为在LLM训练中，多个GPU需要协同完成数十天的迭代，任何环节的故障都可能对整体进度造成严重影响。

其次，LLM培训的失败可能会导致重大成本。当故障发生时，LLM训练通常利用检查点从故障中恢复;然而，由于在LLM训练中生成检查点需要大量存储(例如，每个GPU 30GB)和高开销(例如，100)，我们的客户选择每隔几个小时生成一个检查点。例如，在图4中，我们记录了四个代表性的生产llm中的检查点生成间隔，通常从2小时到4小时不等，(即使在这些高间隔，由检查点引入的开销仍然在5%左右)。

这意味着一旦发生故障，整个训练必须回滚到几个小时更早，并重新培训。考虑到使用3K个gpu的训练任务每小时的训练费用为2万美元，失败可能导致3万美元的经济损失。

单点故障是指系统中的某个组件或部件出现故障，导致整个系统无法正常运行。虽然tier2和tier3层具有丰富的冗余链路，但每个NIC通过单个链路连接到ToR,造成单点故障风险。当访问链路(即连接NIC和ToR的链路)断开时，会导致相应的主机断开连接。更糟糕的是，ToR的故障可能导致数十甚至数百台主机不可用，从而导致严重的服务质量下降。LLM训练需要数千个gpu协同训练，涉及数十个tor和数千个光模块和链路。

在如此庞大的规模下，确保网络设备不出现故障实属不易。尽管监控和故障排除系统能帮助我们迅速定位问题根源，但它们无法防范培训过程中的意外崩溃。如图5所示，在我们运行的集群中，每月约有0.057%的NIC-ToR链路出现故障，而约0.051%的ToR交换机则遭遇严重错误和崩溃。在如此高的故障率下，单个LLM培训过程每个月可能会遇到1-2次崩溃。此外，每天还会出现5K-60K的链路抖动现象，导致暂时性性能下降。

2.4 基于实际考虑的目标

基于LLM培训的特色，打造全新网络架构，助力实现以下目标：1. 提高学员体验；2. 优化资源配置；3. 加速知识传播。

G1:可扩展性。如图6所示，单个生产培训任务所需的GPU数量低于3K。为应对未来需求变化，我们设定了包含15K GPU的主要容量目标，这与主流LLM培训提供商(如Google、AWS、Azure和NVIDIA)的训练集群配置相符，即每个集群提供10K-30K GPU。根据我们的经验，未来几年模型参数的数量可能会以一个数量级的速度增长(从1万亿到10万亿参数)。因此，我们数据中心的额外容量目标是支持100K GPU的规模。

"G2:卓越性能是我们的追求。优化的关键在于最小化网络跳数，这不仅有助于降低延迟，还能减少ECMP哈希次数，从而实现更精确的路径选择。更重要的是，我们应尽可能地促进GPU与GPU之间的直接通信，而非通过网络来传输信息，以此提升效率。"

G3网络采用单tor容错技术，针对§2.3中的观察，我们发现LLM训练可靠性的最大隐患在于单tor故障。因此，新架构应从根本上消除拓扑级别上的单tor失败风险。

   3 HPN架构概述

HPN,由前端网络与后端网络构成，为整个训练过程提供支持。其中，后端网络负责处理大部分的流量，而前端网络则承担起管理、推理和存储等其他任务。在我们的LLM培训中，我们主要聚焦于HPN的后端部分。

每台主机都配备了8个GPU,这些GPU之间通过高速的内部网络(如NVLINK[49])进行连接。这种网络的速度可达400GBps至900GBps(双向),使得每台GPU都能与其他GPU直接通信，提升了训练效率。

为了提供最大的网络容量，我们为每台主机配备了9个网卡，每个网卡都有2×200Gbps。这9个网卡中的一个(即图7中的NIC0)连接前端网络，其余8个网卡连接后端网络，在LLM培训期间承载流量。这8个网卡中的每一个都服务于一个专用的GPU(命名为rail)，因此每个GPU都有一个专用的400Gbps的RDMA网络吞吐量，导致总带宽为3.2Tbps。这样的设计旨在最大限度地利用GPU的PCIe功能(PCIe Gen5×16)，从而将网络发送/接收容量推向极限。每个网卡的两个端口分别连接到不同的tor上，构成双tor设计。

这种双tor设计旨在避免单ToR故障问题， 在tier1中，考虑到主机内网络(如NVLINK)比主机间以太网具有更高的容量，我们采用了rail-optimized design，其中属于不同rail的网卡连接到不同的tor集合。结合上述双tor设计，一台主机连接到后端网络中的16个tor。

通过充分利用51.2Tbps交换芯片的能力，HPN使1024个gpu通过称为段(§5)的单层网络互连。图6量化了我们的收益:大约96.3%的生产LLM培训工作需要不到1K的gpu;因此，在HPN中，这些作业可以放在一个网段中，从而实现最大的网络性能。

Tier2连接多个网段。我们结合双tor特性，在这一层设计了双平面转发(如图7所示)。源网卡0端口发出的流量可以通过网络转发，最终仅由目的网卡0端口接收，与源网卡1端口的流量物理隔离。这种双平面设计避免了聚合层hash极化的问题，同时不影响1:1的网络二分带宽。此外，双平面设计使Pod覆盖的gpu数量增加了一倍，支持15K gpu的互连。 

对于未来单个作业可能需要的更大规模，我们还设计了不同pod之间的核心层互连。由于单个Pod规模已经达到15K gpu，因此需要通过核心层进行协调的作业很少。在我们的设计中，我们选择了聚合核心层的超额认购比例为15:1。基于LLM训练的流量特征，我们跨pod分配PP通信，确保跨pod传输对端到端训练性能的影响最小。 

前端作为承载流量管理、推理与存储的关键角色，实现了与后端网络的物理解耦，确保了主要流程不受影响。同时，前端网络设计了1:1的超额认购，可拓展至LLM训练与推理等多样化场景。