阿里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)给当今的AI和云服务带来了巨大的变革。一个具有数千亿参数的LLM的训练依赖于一个大规模的分布式训练集群，通常配备了数千万个gpu。LLM训练由于其独特的特点，对数据中心网络的设计提出了新的挑战。

问题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)。在本文中，我们分享了我们新的数据中心网络架构，HPN，这是专为LLM培训设计的与传统数据中心相比，HPN做出了以下贡献:

 •HPN提出了一种新的ToR部署设计(即非堆叠双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[30])采用并行策略的混合来有效地协调所有GPU。

数据并行(DP)。训练数据集均匀分布在所有GPU中，其中每个GPU都有整个模型的副本。在每次迭代中，所有GPU都使用AllReduce来同步计算的梯度。

管道并行性(PP)。一个模型被分成多个阶段，每个阶段包含一系列连续的模型层，并由不同的GPU提供服务。管道中的每个GPU接收来自前一阶段的输入，并将输出发送到管道中的下一阶段。

张量并行性(TP)。整个模型或PP中的每一层都可以进一步水平分割。因此，每一层分布在一组GPU上。在每次迭代中，同一TP组中的GPU使用AllReduce/AllGather来同步计算的输出和相应的梯度。

考虑到(1)庞大的训练规模和(2)各种并行策略，在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培训对故障更加敏感。在LLM训练中，多个gpu协同完成每次迭代，我们需要多次迭代(持续数十天)才能完成整个训练过程。因此，任何GPU或主机上的故障都可以直接减慢当前迭代，甚至使整个LLM训练过程崩溃。 

其次，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培训的独特特点，我们决定专门为LLM培训构建一个新的网络架构。我们应该达到以下目标。

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，这是我们专门为法学硕士培训设计的新数据中心网络。HPN满足§2.4中的目标。图7给出了HPN的概述。

HPN由前端网络和后端网络组成。后端网络主要支持训练过程中的流量，而前端网络承载其他流量(例如，用于管理、推理和存储的流量)。对于LLM培训，我们主要关注HPN的后端网络。在HPN的后端网络中，每台主机配备8个gpu，每个gpu通过专用的高带宽主机内网络(如NVLINK[49])连接。每个GPU可以通过这个400GBps-900GBps(双向)的主机内网络与其他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训练和推理的混合部署。

 

-对此，您有什么看法见解？-

-欢迎在评论区留言探讨和分享。-