直播回放 | 高性能智算集群设计思考与实践
内容介绍
1. AGI对基础设施的挑战
2. 高性能智算集群的设计实践
3. 思考与展望
今天将与大家分享阿里云灵骏智算集群产品的实践与思考。正如主持人刚才简要介绍的,灵骏智算集群是公共云的一个产品,已经面世近三年了。
其实,做公共云和做线下集群有着极大的差异。因为公共云需要满足多租户的需求,为众多客户提供一致的品质服务。无论客户需要的是一张卡还是一万张卡,他们都能迅速在公共云上开通并使用,而且性能要保持一致。因此,这里面的挑战可能比构建一个标准的线下集群,即货架产品更为复杂。
我的分享将分为三个部分:首先是AGI对基础设施带来的挑战;其次是高性能智算集群的设计实践,即我们在过去两三年中所做的一些工作;最后是一些思考与展望。在这个快速发展的领域,正如前面几位教授专家所提到的,我们面临着诸多挑战,也有一些深入的思考,今天我将与大家共同分享。
01. AGI对基础设施的挑战
我想从这里开始说起,在2024年,AGI领域中最有趣的一件事就是它与诺贝尔奖产生了关联,而且还不止一个奖项。我主要想谈谈与诺贝尔物理学奖相关的这一部分。其实,这两位教授,我认为他们极具创造力。
在40年前,他们运用物理学的工具为今天的机器学习,特别是人工神经网络,奠定了基础性的方法。这一点大家或许都有所了解,但我特别关注到其中一位名为 hopfield 的教授。他当时使用了一个包含30个节点的网络,在这个网络中,他最终需要计算涉及500个参数的运算。然而,当他试图将这个网络扩展到100个节点时,由于80年代计算机能力的限制,这个100个节点的网络变得过于复杂,因此他的尝试失败了。但今天,我们仍在谈论万亿参数规模的模型,这都要归功于他当时的贡献。当然,将这两个时代的参数规模直接对比可能不太恰当,但你可以看到,从当时的500个参数到今天的万亿参数,这差不多是20亿倍的扩展,这充分展示了技术进步的速度和规模。
所以,时至今日,我们讨论的一个话题是:在大模型领域,Scaling Law是否仍然具有重要意义。这个概念其实相对较新,最早可能是在2017年左右由百度的专家们提出的。它主张,如果模型结构、数据量和计算量都在持续增长,那么机器学习的效果也会呈现正相关增长。这就是Scaling Law的核心思想。回顾过去十年,我们可以看到,以Transformer模型训练所需的资源为例,其增长速度大约每两年达到750倍,这完全契合了Scaling Law的发展趋势。
但是,未来是否还会延续这样的趋势呢?我们预测,在未来三年内,更先进的模型,如MOE等,随着其尺寸的增长,仍会有性能上的提升。届时,参数规模可能会达到T级别,因此我们认为Scaling Law仍有增长的空间。尤其是当前,大家更加关注视频对真实世界的仿真或理解,这显然需要更大的参数量。回顾上一页提到的那两位获得诺奖的专家,他们在40年前的工作,从30年后的2010年代开始,以他们奠定的神经网络基础为起点,推动了这一波AI技术的演进,直至今天,确实发展飞速。这样的飞速发展给计算体系带来了非常巨大的冲击。
阿里云原本主要以通用计算为主,原先的集群大多以CPU机器进行通信为主。然而,如今我们发现,为了支持大模型的训练和推理,它在传统IO、内存通信等各个方面都遇到了新的瓶颈。那么,面对这些问题,我们应该如何应对呢?
02. 高性能智算集群的设计实践
接下来,我将从两个维度重点展开:一个是并行计算的性能扩展性,另一个是稳定性。
主要从这两个维度来谈谈我们在现有集群上的一些实践。具体来说,就是从不同的层级出发,从单芯片,包括单CPU和单GPU,到rec level,即一个机柜,再到机房级别、集群级别,甚至是跨集群、跨机房、跨可用区的级别。这种模型训练的需求一直在明显增长。正如前面有位教授提到的,海外可能已经有人在构建10万张卡的集群。这样的规模显然不可能完全放置在一个数据中心内,关于这一点,我稍后会详细展开。
另外,关于稳定性方面,前面所有的专家都提到了超大模型训练时的稳定性问题。而底层的基础设施,如功耗、散热和能源管理等,虽然看似简单粗犷,但实际上非常重要。后面我们会在这些领域为大家一一展开说明。
首先,我们认为原有的计算架构和集群设计已经无法满足以AI工作负载为核心的需求。因此,我们需要重新设计,采用AI Native的方式来构建计算集群。大家可以看到,这边展示的是原有的通用CPU或者计算模式,它基本上是基于通量计算的模型,是一种流程化的处理方式,即大数据被分散计算后再合并结果,是一种自上而下的流程式操作。然而,今天的AI计算模型则完全不同,它是以模型迭代化的训练循环为核心,这种高频次的迭代与原有的模式形成了鲜明对比。因此,这种计算模式已经从以CPU为中心转变为以GPU为核心。大家可以看到,蓝色部分代表CPU,而绿色部分则代表各种异构芯片或GPU。在以往的方式中,CPU之间通过MPI或内部PCIE总线进行通信。然而,在谈论AI集群时,我们现在更关心的是GPU之间的通信。因此,整个范式已经转变为以GPU为核心,讨论如何更高效地在GPU之间进行通信和协作,而CPU则可能退居次要地位。
然后你就会发现,我们可能需要一个类似于“X-Link”的daming概念来解决GPU之间的互通问题。而他们之间的互通可能不一定是以太网,但现在有好多种不同的技术方案,我们把它称为X-Link概念。这也是我们在后续思考中的一个方向。因此,有了前面的需求和挑战。
从2022年开始,林骏智算集群作为阿里云的公共云产品正式推出。本质上,它就像购买普通的虚拟机一样便捷,用户可以随时开启,从单卡到一万卡不等,只要有资源且用户愿意支付费用,可能是小时级或分钟级的时间,就能获得所需规模的集群。所有人获得的集群在性能上保持一致,不会因为规模大小而产生差异,同时,集群的稳定性也是相同的。
虽然用户的使用体验看似一致,但其背后的实现机制却相当复杂。我将从三个层面来阐述这个问题。首先是高性能基础设施的搭建,其次是性能优化与管理的实施,最后是支持上层应用的服务。刚才提到的性能兑现,即性能优化,最终会落实到监控与管理层面。我们需要支持阿里云自身的服务,包括容器服务或Pass层的一些服务,再往上就是客户的应用层面,但这部分可能不是今天的重点。因此,我会重点介绍高性能基础设施部分,特别是林骏集群。林骏集群的定位是一个专门的训练集群,当然也可以用于推理,但其主要功能是训练。在训练过程中,对存储的性能要求极高,同时存储的数据量也非常大。因此,我们需要解决如何提升训练过程中参数面的通信效率,如何充分释放GPU的能力,同时确保数据能够高效地提供给训练集群。
因此,在底层架构上,我需要考虑采用更高效的网络技术,如RDMA或TCP网络,以实现存储与计算集群之间的无缝连接,或者说我需要确保我的两种产品能够顺畅地互通。同时,存储系统本身也涉及到冷热数据的流动管理,该如何帮助客户降低成本呢?例如,虽然我可以提供高性能的CPFS,即高并发的文件存储系统来满足高并发需求,但其成本却相对较高。
那么是否需要将客户的所有数据都存放在高性能存储上呢?答案是不一定。只有在训练过程中打checking、存checking的时候才需要存放在CPFS上。而对于那些离线的数据、累积的checkpoint点或是暂时不需要的数据集,则可以存放在OSS或其他存储介质中。例如,可以利用CPU集群进行数据的预处理等工作。这样做既能降低客户的成本,又能提高数据流动的效率。
在我本身的训练集群中,实现了对不同异构芯片的兼容,并且构建了一个无收敛问题的RDMA计算网络。目前,我的线上集群已经能够扩展到10万张显卡的规模,同时在千卡级别的测试中,能够实现96%的线性加速比。此外,对于大规模的checkpoint存档,比如百亿级甚至7000亿级的数据点,可能需要几十个TB的存储空间,但我的系统能够确保这些数据在秒级时间内完成落盘。这样一来,客户可以节省大量时间,将更多精力投入到实际的训练过程中,同时也提高了客户的可靠性,或者说真正从客户角度出发,增加了有效的训练时长。
在显卡级别,我们已经实现了99%的性能优化。那么,我们是如何做到的呢?首先,从节点设计谈起。阿里巴巴有一套自研的盘酒服务器,其设计独具特色。与常见的商用机或标准机不同,它采用了分离式设计,即CPU和GPU分别位于不同的机箱中。这种设计的好处在于,我们可以更快速地迭代技术,以适应不同芯片的需求。具体来说,CPU位于一个box内,通常称之为“机头”,而GPU则位于另一个box内,称之为“机尾”。这样的组合方式符合模块化原理,为支持多种异构芯片提供了可能。
而这些服务器也都是我们自研的。在性能提升方面,采用这样的设计模式,例如右边的这个盒子,基本上可以支持16颗CPU和1.5PB的共享存储。对于单个节点,参数面网络带宽可以达到3.2TB/s,而在数据面和存储面,机头还提供了400G的网络能力。因此,整台机器具备3.6T外部网络的通信能力。
关于可靠性。在云计算领域,一个极具挑战性的问题就是如何在成千上万台,乃至十万台服务器的规模下,确保每台服务器都能提供一致的性能,并提升整体效率。为此,我们采用AI来服务AI,开发了基于AI的故障预测算法。这也是我们为什么要自主研发服务器的原因之一,即我们需要能够监测服务器的故障。当故障发生时,不需要人工介入,即不需要派遣工程师去现场排查问题,而是让服务器自动按照预设的自愈流程进行处理,从而有效提升我们的运维效率。
网络是另一个至关重要的基础设施。在这里即将介绍的是HPN7.0。然而,在大约两年的时间里,我们的网络技术已经迅速演进了四代,这在阿里云的历史上是前所未有的。在以往的通用计算场景中,网络技术通常在上线后服务2到3年才会迎来下一代。但在这个领域,技术的发展速度实在太快了。因此,今天我们有了HPN7.0,它能够支持的最大规模可以连接10万个GPU,让整个数据中心内的10万个GPU实现高效互联。想象一下,如果将这些GPU放置在一个IDC里,可能需要占据几栋楼,至少是五六栋楼的空间。而且,这样的规模还会消耗掉两个110千伏的变电站的全部容量。所以后面的限制因素并不一定在于网络或服务器技术,而可能是IDC的容量或者电力供应。
那么,回到我们的网络设计上,这是一种新型的设计。之前崔总介绍过使用IB网络三层架构可以实现万卡互联。确实,IB网络可以达到这样的规模。但阿里巴巴的这套网络,从交换机到协议,全部都是我们自研的。在这样的前提下,我们能够支持这种新型的网络拓扑设计。具体来说,我们可以实现单层设计,即仅通过TOR1层就可以接入支持128到136台发卡服务器的网络。如果采用两层交换机设计,我们的网络可以支持超过万卡的规模。而今天,我们正在推进的三层设计,则可以支持10万卡的互联。
因此扩展性通过这样的方式得到了极大的提升。更为关键的是,之所以选择使用更少的层次,原因很容易理解。例如,现在英伟达推出的H200及其后续产品,支持了诸如Multi-GPU等多种先进能力。为了充分释放GPU的性能,我需要适配这些能力。所以,在单层TOR架构下,可能会有16台服务器,每台服务器都连接到16个这样的交换机。这样的设计,当你走进机房时,会发现从设计、施工到后期的故障管理,都是一项非常复杂的工作。这样做带来的好处是,我能够为客户提供极低的时延。同时,由于网络层次减少、故障点降低,我的故障率也得到了有效控制,故障链得以缩短。此外,网络设计也实现了前后端分离,如绿色部分所示,这是我们的存算网络、存管网络,用于访问VPC、CPFS以及OSS等网络,它连接着VPC世界,可以通向集群外部。而橙色的网络,被称之为backin网络,主要用于参数面的通信。
而刚才提到的3.2T带宽正是在这个网络内部实现的,它理论上并不需要与外部网络互通,只需确保机尾的GPU能够高速互联即可。这个网络的核心任务就是追求极快的速度、高并发以及无拥塞状态。为了实现这些目标,我们需要依靠一系列自研协议的端到端优化,来大幅提升通信性能。具体来说,我们采用了自研发的Solar IDV技术,它支持多路径通信,还有HPCC这样的流控机制,这些都是紧密结合在一起的。而且,高网技术本身就是一种端网融合的技术。因此,大家可以看到,我在讲述网络时,其实还有一个非常重要的部分就是网卡。而我们也有自研的网卡,这样我们可以端到端地实现这些能力。当然,使用货架产品也是可以的,没有问题。但阿里云有其自身的特殊需求,比如要保证供应链安全等,还有很多其他的考虑因素。
接下来要讲的是最重要也是最具有挑战性的部分了。硬件方面相对来说还好一些,但稳定性一定是软硬件相结合才能实现的。特别是在集群规模日益扩大的情况下,这个挑战变得尤为明显。
刚才崔总已经介绍过Lama的训练日志情况,那些具体数字我就不再重复了。我们根据他的数据大致估算了一下,如果按照54天的故障率来计算,集群几乎每三分钟就会出现一次故障。如果真是这样,哪个客户能接受呢?即使这是世界上可能属于一线水平的集群,也难免存在这样的问题。那么,我们能做些什么呢?我们需要尽量减少图中红颜色和橙颜色部分所代表的部分,这些基本上是系统中不可用或者出现故障后需要定位的部分。而绿色的部分则代表真正有效的训练时间,这也是我的客户们最希望延长的部分。
如何缩短红色的部分呢?这其实是非常具有挑战性的。只要大家亲自管理过集群,就会发现我们之前提到的都是infra层面的问题。然而,实际上,任何一个故障都可能与基础软件、上层的AI框架,甚至用户的代码密切相关。任何一个环节出现问题,都可能导致整个集群停止训练。在这种情况下去定位问题并恢复运行,需要花费非常大的effort。那么,我们自己是如何实现这一点的呢?下面我先向大家汇报一下我们的成果。
在2023年的时候,我们认为我们在稳定性方面已经做得相当不错了,那时的集群可以连续三周以上不中断地进行训练。这反映了我们在基础设施这一层稳定性方面所做的工作。然而,到了2024年,随着集群规模达到3000卡,我们进一步实现了在一个月内稳定训练时长占比达到99%的成就。
为什么会选择这两个不同的维度或指标呢?这是因为它不仅代表了稳定性,还体现了容错能力。正如之前专家们提到的,我们采用了断点续训和自愈等机制。在公共云上,我们在资源池,即未售卖给客户的资源,以及客户使用中的资源,还有整个生命周期的监测上都做了大量的工作。例如,在资源未售卖给客户之前,我们会重点进行压力测试,检查卡的状态,特别是其集合通信的状态,因为很多故障可能是通过通信方式才能暴露出来的。当资源售卖给客户后,我们不仅仅局限于作为一个S层产品的提供者,而是要积极向上看,与PaaS层产品或者客户的系统进行深度整合。我们需要实现自愈功能,进行双向故障信息的同步,这样才能让整个复杂的AI训练技术栈实现完全的自动化和高效能,同时具备自愈能力。
因此,除了在集群内核的底层标准动作之外,我们还致力于解决更复杂、对客户最有价值的问题。这包括与PaaS层及客户层的系统进行深度交互,了解它们的运行状况。我们需要判断这些故障是否由底层基础设施引起,或者当底层发现问题时,主动通知上层系统,以便其尽快隔离有问题的节点。这些都是我们正在做的事情。同时,我们还具备全生命周期的可观测能力,这也是端到端的,特别是从业务视角出发,而不仅仅是关注基础设施的传统指标,还会关注迭代的时间、数据吞吐的效率以及IO性能,以此来反映训练是否正常进行。
03. 思考和展望
接下来是我们的一些思考。由于之前提到的铺垫,基础设施为了满足模型训练的扩展需求,也需要不断进行扩展,这主要包括水平扩展和垂直扩展,或者说是scale-out和scale-up。而我们根据这两个维度绘制了这张图,横轴代表范围,越往右范围越大;纵轴则代表互联性能。大家可以看到,当互联性能非常好时,比如显存带宽可以达到几个TB时,这通常意味着是芯片级别的互联。在这个层面上,我可能无法做太多从产品角度出发的改进,因为这些可能受到半导体产业发展以及地缘政治等因素的影响。
如果是位于图中最右下角的部分,也就是刚才讨论的万卡级甚至十万卡级的集群扩展问题,我们已经有了自己的观点。我们认为,IB在超过10万卡规模时,可能就不再适合了,因为它的网络层次太深。就像崔总之前介绍的,IB可能需要三层网络来实现万卡互联,而如果我们采用两层网络设计,理论上就能支持到十万卡的规模。这是一方面。另一方面,我们面临的主要限制其实是电力供应。刚才已经提到了,我们是否有足够的电力资源,以及IDC的设计标准能否满足10万卡集群的需求,这些都是我们需要考虑的问题。
但是今天我想重点与大家分享的是位于中间部分的思考,即在一个机柜内,我们应该如何设计x-Link的domain,以及这样的设计对我们的下一步扩展会产生怎样的影响。大家可能比较熟悉的是NVIDIA的NVLink和NVSwitch等技术。这些技术是我们后续会重点优化的领域。
简单来说,我们需要提供一个高性能的互联环境。以NVIDIA的设计为例,他们也有36卡、72卡等单柜设计。当单柜达到72卡时,风冷已经无法满足需求,必须采用液冷,且功耗会超过40千瓦。这对我们有很大的影响,而我们也持有同样的观点。在设计这部分时,我们需要考虑服务器的设计、交换机的设计,同时还需要考虑公共云产品的场景。可能有人认为这个尺度很小,对训练没有太大帮助,但实际上并非如此。通过实际发现,它对推理有更大的好处。虽然今天不是重点讨论基础设施,但值得一提的是,当这个互联的带宽变大后,许多当前困扰我们的问题,比如跨境推理等场景,都能得到较好的解决。
在集群维度上,也就是比机柜维度更大的层面上,我们会做些什么呢?大家请看这张图上橙色的部分,它代表了在机柜内xLink的影响,这主要关乎我们在设计训练并行策略时的TP Tensor、EP或MOE等场景。再往上一层,当我们面对千卡规模的集群时,一层交换机,即图中浅蓝色部分的设计可能就影响了PP的实现。再进一步,当我们需要管理跨万卡甚至十万卡规模的集群时,如何进行有效的调度成为关键,这时可能适合采用的运营策略就是DP。只有采用这样的策略,我们才能持续优化整个集群的架构,并解决一些极端场景下通信占比过高的问题。
还有就是刚才提到的x-Link domain,关于它在一个机柜内能支持多少张显卡或异构部件才是最佳的问题,我们自己做了一些仿真和测试。在我们的场景中,针对拥有150到200GB显存的显卡,我们得出的结论是:最佳的x-Link domain范围不应超过128张卡。这两条曲线分别代表使用MOE 1.8模式的一个模型和3T到5T大小的一个模型。大家可以看到,基本上当达到128张卡后,其性能收益就趋于平稳了。这是我们基于内部仿真得出的基本假设和结果。
最后,我想从调度的角度与大家分享一些思考。传统应用的特点是什么呢?它们主要基于CPU运行,且数据处理量很大,比如我们日常观看的视频等。这些应用的时延主要发生在网络上,特别是互联网上。对于这类应用场景,时延的容忍度非常低。比如,当你点击视频时,如果有一秒钟的加载时间,你可能会直接放弃观看。或者,当你在进行交易购买时,如果确认过程需要停留几秒钟,你也可能会选择放弃。
但是,AI应用的特点又是什么呢?它们的数据传输主要聚焦于token或训练所需的图像等,且时延主要发生在计算过程中,而非网络传输。实际上,大量的实验都集中在推理阶段,从用户视角来看,这是非常关键的。此外,AI应用场景对时延的容忍度相对较高。比如,当你向GPT提出一个问题时,等待一两秒是可以接受的,这与传统的CPU应用有显著不同。因此,我们认为ACS将更面向AI应用,更加友好。而传统的VM可能更适合CPU应用。从调度的角度来看,原来的调度范围通常是可用区AZ级别,但未来,我们可能会实现全球维度的调度,能够在不同的数据中心,甚至在国内的“东数西算”等项目中,都有很多值得考虑的点。因此,容器化和调度能力的升级也是我们后续关注的重点。