Meta的AI网络演进
Meta
多年来，Meta的AI基础设施发生了翻天覆地的变革，从CPU主导的训练模式，逐步转向同一主机上GPU的加速训练，最终构建起了网络互联的分布式系统。如今，Meta的模型训练已经高度依赖基于RoCE的网络架构，采用CLOS拓扑结构，叶（leaf）交换机连接GPU主机，脊（spine）交换机则支持集群内GPU的规模扩展。
本次演讲将深入剖析Meta网络建设的渐进式演变，这些变化都是为了满足AI服务的高标准要求而量身打造。还将分享在规模化基础设施的发展过程中，如何克服路由、传输和硬件层面的重重挑战。同时，也将展望这一领域尚存的机遇，期待在未来几年取得更为显著的进步。
我接下来要分享在扩展用于AI应用的网络过程中遇到的种种挑战，或许大家对此已经有所耳闻。在我审阅PPT的过程中，我发现其中有很多展示我们实力的实例，无论是图片还是代码片段，都让人印象深刻。特别是那些编码示例，我觉得特别有意思。只要输入一个提示，代码就能自动生成，这不禁让我好奇这种技术未来会如何影响我们的工作和生活。
这种基于提示的代码生成技术，是否能成为未来网络配置的重要一环呢？这让我对未来的发展充满了期待和想象，尤其是对那些正在学习计算机科学的年轻人来说。他们将会如何利用这样的技术进步，创造出更加智能、高效的网络系统呢？
Meta的AI应用场景极为丰富，其中一些已经在实际生产中应用了数十年。起初，训练和推理主要依赖于CPU，但近年来，我们已大力转向GPU基础设施。我们的应用场景涵盖了排名和推荐算法，这对Instagram和Facebook等平台至关重要，同时也涉及神经网络的内容理解，现在已发展为更广泛的机器学习应用，如语音转文字功能和内容审核，以确保内容的安全与合规。此外，我们目前正在探索图像和文本的生成式AI以及大型语言模型。
这些应用场景对基础设施提出了严峻的挑战。它们的快速发展令我们这些从事基础设施工作的人深感震撼。我们的使命是构建能够适应这些不断变化需求的灵活系统。这些模型和应用场景之间的融合不足，使得问题更加复杂。因此，我们的主要挑战在于打造灵活且可扩展的基础设施，以满足这些动态需求。
举一个具体的例子来稍微深入一些。我会在后续详细介绍。大家可以从Meta的众多演讲和博客文章中找到我们已经讨论过的细节。在此，我只想强调几点。
大型语言模型训练是一个重要的应用场景。这些模型运行在包含数千甚至两千台GPU的集群上。所有这些数据都基于Nvidia A100 GPU。我们最近发布的大型语言模型所需的基础设施规模已经达到了zettaFLOPS级别。我必须确保我理解了zettaFLOPS的含义，它指的是10的21次方，这意味着什么呢？这一切将如何发展？这就是它的含义，这是我们非常重要的一个应用场景，但它也对基础设施提出了极高的要求。我们的一个目标是构建一个每秒能够进行20 exaFLOPs运算的集群，这样我们就能在一天或不到一天的时间内训练出与LLaMA同样规模、拥有650亿个参数的模型。相比之下，我们早期训练的一些模型，以及当时的集群，需要花费数天甚至数周的时间，但那是因为它们是我们要深入研究并发布的基础模型。现在，我们希望能够大幅缩短这一时间，实现几小时内就能运行并生成这些模型。
或许大家之前已经看过其中的一些内容。我会提供一些参考资料，但基本上，这些资料试图展示不同模型在多个维度上的需求，无论是计算、内存大小还是网络。当大家综合考虑所有模型及其需求时，会发现它们在图上呈现出一种非常有意思的分布。大型语言模型，尽管非常重要和关键，但与同样重要和关键的排名和推荐模型在需求上存在很大差异。
即使是推理本身，如果大家了解训练过程的话，也会知道推理本身也分为多个阶段，每个阶段都有其独特的挑战。
说到推理，很多人可能会认为，只要拿一个模型来应用就可以了。但实际上，推理的过程分为不同的阶段。就比如人们在思考如何回答问题时，其实就已经涉及到了推理的第一部分，也就是预填充。他在想：“我要怎么回答这个问题呢？”这实际上需要大量的计算。所以，当他在思考时，可能会有一些延迟。同样，在推理的解码部分，即他开口说话的时候，我们希望这个过程能够非常迅速。我们不希望他说每个词之间都有几秒钟的间隔。虽然整个推理过程可能需要几秒钟，但实际的交互应该非常流畅，听起来像是自然的语音输出。因此，推理本身是一个相当复杂的过程。预填充和解码这两个阶段对推理的要求也有很大的不同。
在过去的几年里，我们一直在思考模型的需求以及它们在基础设施的各个方面有何不同，包括网络。
那么，我们是如何尝试将这些需求整合成不同的解决方案的呢？基本上，我们采用了排名和推荐训练系统，并设计了一个扁平化的结构。这个结构非常大，能够同时处理多个任务。你可以把它想象成一个AI云，不同的排名和推荐任务不断被提交到这个云上。这些任务在我们的基础设施上运行，因为各种应用程序都需要排名功能。比如，Instagram或Facebook想要展示的广告，或者人们上传的视频，我们都需要对它们进行排名和评估。因此，许多任务都在这些排名集群上运行。
其中，主力是一个运行着Ethernet和RoCE的4000个GPU的集群。这是我们过去几年一直在部署的工作。
另一方面，大型语言模型的集群并不像AI云那样，每天都要训练数百或数千个基础模型。这里是我希望运行几个大型任务的地方，这些任务会占用整个集群，每天执行ZettaFLOPs次运算。
目前，我们正在设计和部署的是一个支持3.2万个GPU的InfiniBand和RoCE集群，专门用于大型语言模型的训练。这是InfiniBand集群的设计。
这是以太网RoCE集群的设计。
之前我们谈到过Meta分享的研究超级集群，那是在一两年前，也是一个InfiniBand集群，拥有1.6万个GPU。但现在我们正在迈向更高的目标，并建设更多的集群。
我一直都在引用我们之前分享的不同时间点的信息，无论是通过演讲还是出版物。我只是想强调这对我们所有人来说有多么重要。在Meta，我们非常重视分享我们在构建AI集群方面的经验。并不是说有很多现成的操作手册或参考设计书可以直接用来建立3.2万个GPU的集群。这对于我们作为运营商来说非常重要，同时我们也非常愿意与所有人合作，无论你是同样做这件事的运营商还是与我们合作的供应商。
我们在Open Compute上的分享就是有意义的，也是我们坚信的。一直以来，我们都对我们的系统、网络系统以及机架设计持开放态度。
而且，我们也在逐渐开放我们的模型和设计。因此，我在Meta AI博客上放了一些快速参考资料，包括我们如何改进基础设施、我们向社区发布的模型，以及许多深入探讨我们正在构建的基础设施不同部分的演讲和博客文章。如果你错过了，我们已经设立了人工智能特别讨论环节，其中一场讨论会是关于今天AI的应用案例，然后我们还有一场讨论会是关于我们集体通信中的流量模式。我知道关于AI的演讲有很多，但我们真的认为将这些信息传播出去非常重要。（https://engineering.fb.com/2023/11/15/networking-traffic/watch-metas-engineers-on-building-network-infrastructure-for-ai/）
这是我们所面临的一个主要挑战。我们致力于构建能够应对模型多样化应用场景并预见其发展的基础设施。尽管设计过程充满了困难，我们仍已完成了初步的设计。人们普遍认为这是极具挑战性的部分，我完全理解，设计出能够应对所有情况的方案确实不易。这确实令人兴奋，因为大家现在看到的那些蜘蛛图，都需要我们针对特定需求进行优化，比如推理计算等。设计出这样的方案真的很有挑战性，这是一个巨大的难题。
然而，更大的挑战还在后头，我们才刚刚起步。一旦我们有了这些设计方案，接下来的规划、建设、测试和部署工作将更为艰难。这将是未来几年我们要持续努力的工作，涉及到所有的集群。因为不同的工作领域和问题类型，可能涉及到不同产品的组件，它们将成为整个解决方案的一部分，而这只是我们整个技术体系中的一小部分。整个技术体系都是经过长期积累和实践的，这是无可置疑的。那些与我们合作过的人，比如我们几年前在OCP中引入的Wedge 40或Wedge 100，它们至今仍在我们的技术体系中发挥着作用。我们正在努力推动它们的升级，但其中一些仍在继续使用，实际情况就是如此。
因此，当我们管理一个像我们这样规模的技术体系时，会涉及到很多代的产品。在AI领域的挑战尤为突出。为了让大家有更直观的了解，如果回顾我之前展示的图，那些只是训练后端集群的一部分。再看看那些变种，你会发现有用于排名的RoCE，用于大型语言模型的RoCE，以及InfiniBand等。实际上，在过去的三四年里，我们已经经历了多个世代的更新。从最初的设计到最新的设计，我们一直在不断迭代和改进。
我提到了GPU，比如我们之前列出的A100，但现在我们也在使用Nvidia的H100。然而，这只是我列举的一部分变种，还有很多其它的交换机、线路卡、光学元件、NIC等组件我没有详细介绍。对于那些负责网络运营的人来说，将一个新产品从实验室或概念验证阶段推向生产阶段，面临着巨大的挑战，因为涉及到众多不同的组件。
关于设计迭代时间，我想补充一点。当我们构建布线系统或前端布线时，比如从100G过渡到200G，或从200G过渡到400G，这些过渡以及像Wedge 40、Wedge 100或Wedge 400这样的产品寿命较长，它们为我们提供服务的窗口也更长。但在AI领域，由于我们紧跟最快的GPU和模型的发展方向，迭代时间大大缩短。因此，我们不能满足公平研究组或生成式AI组提出的三年升级网络的需求。他们的需求非常迅速，对基础设施来说是一个巨大的挑战。有时候，我们甚至需要在不到一年的时间内完成一个集群的建设。所以，AI带来的迭代速度给我们带来了很大的挑战。
除了GPU，我还提到了Meta正在开发自己的ASIC系列，这将为我们的技术体系带来更多的变化。
以上只是关于后端的讨论。在这里，我要向前端团队致敬，因为没有前端就没有后端。前端承载着所有的计算和存储任务。当用户想要查看他们生成的个性化信息时，这些信息会经过前端进行处理。社交网络的信息也存储在前端。因此，前端和后端必须协同工作，确保从端到端的服务能够无缝运行，以便UI和AI应用场景能够顺畅地为用户提供服务。你可以训练一个模型，但如果前端网络的推理速度慢，用户在等待生成结果时会感到不满。
为了解决这种爆炸性的测试矩阵和不同方案的挑战，我们采用了多种方法。在这里，我只列举一些。
如何进行有效的测试和基准测试，是我们极为重视的领域，因为这可以帮助我们深入了解解决方案在不同层面的性能表现。不同层面的性能有多快？瓶颈在哪里？作为一个极客和科学家，我非常喜欢探索并尝试优化这些瓶颈。测试和基准测试正是解决这个问题的关键。系统能够运行起来并不难，但真正的挑战在于如何提升性能，无论是20%、10%还是5%。这需要我们深入各个层面进行细致的研究和优化。
从开放性的视角来看，我们这里确实有很多进展。事实上，请允许我稍微回顾一下。我们手头有许多工作正在进行，显然，PyTorch是开源的，我们一直在推动这一点，模型也是开源的。但我们的努力并不止于此，我们一直在开放各种软件工具，这些工具将协助我们进行联合基准测试和验证。我们已经开始与其它公司、运营商以及供应商展开合作。所以，这正是我们所需要的。
我们已经在学术或行业会议上进行了分享。我们有一个工作组正在全力推进，并且已经有很多视频资料可供参考，我们还将继续在这方面加大投入。我必须强调，测试和基准测试对我们所有人来说都是至关重要的，因为这是我唯一能够验证并证明“这将真正帮助我们的模型”的方式，我能够明确说明哪些因素对我们来说是真正重要的。
实际上，我们在内部也经常采用这种方法。这不仅仅限于供应商和合作伙伴。每当我们对交换机的配置进行调整或修改时，每当我们对SDN控制器进行改动以执行某些操作时，我们都希望确保这些改动是有效的，不会在我们看不到的地方引发问题。举个例子，我们曾进行了一系列调整，原本以为可以解决瓶颈问题的一部分，但结果却增加了内存使用量，给系统的其它部分带来了更大的内存压力，反而导致整体的训练作业时间变长。如果没有这些基准测试，我们可能会急于求成，采纳一个解决方案，无论是硬件组件的更换还是软件的修改，而没有意识到这对整体作业的影响。
我还想补充一点，为了加速我们的进度，我们会重新评估并调整我们已经拥有并在后端使用的硬件和软件。
顺便说一句，如果你一直关注OCP网络领域的话，今年正好是OCP网络成立的第十个年头。在过去的十年里，我们一直在深入研究这些白盒交换机，并通过OCP软件层将它们开放，无论是SAI还是我们特别在SAI上使用的FBOSS。这些都是作为我们AI集群的重要组成部分，进行了深度集成和部署。
在顶部机架交换机方面，我们采用的是OCP交换机，它们运行着FBOSS和SAI。而Wedge 400和Minipack2则是我们的前端设备，它们支持 A100和H100 GPU。再举一个例子，我们使用的操作系统软件，也不得不根据后端的需求进行调整。
当我们首次构建AI集群时，团队就明确表示：“我们必须确保后端的性能与前端一样出色，因为我们已经部署的前端设备已经稳定运行多年，表现非常优异。”而我们的第一个集群在初期其实是相当手动化的。我们不断优化，直到它的性能与前端相当。但随后我们意识到，实际上后端集群在某些方面的要求更为苛刻。
因为每当线路卡出现故障，我们需要将其排除，但长时间的停机显然会降低集群处理的petaFLOPS或exaFLOPS量级。因此，我们必须迅速更换故障硬件、及时检测并恢复正常运行。为此，我们在操作上进行了大量软件调整，以提高后端集群的SLA。
经过重新定位和基准测试后，我们认识到，一切成功的关键都在于人。这里我举几个例子，比如我们计划更新数据中心，但现有的数据中心并不是为高密度的AI应用场景设计的。我们不得不慎重考虑，如何合理布局大量的电力供应和光纤线路，并改进冷却系统。因此，我们请来了最初设计这些数据中心的工程师，并请他们为AI应用场景提供解决方案。
另外，为了管理训练集群，我们需要一个SDN控制器。多年来，我们在SDN领域积累了丰富经验，所以我们召集了一些虽然不一定有AI经验，但拥有路由、控制和控制理论背景的专业人士。现在，他们正在为我们的后端集群编写控制系统，从主干网络到AI集群的一些后端部分都有涉及。
这种操作调试是确保AI集群稳定运行的关键环节。想象一下，在成千上万个组件中，要找到导致1.6万个GPU的LLM性能下降的具体原因，可能是一个缓冲区的问题，可能是网卡的问题，也可能是其它什么细微的故障。这确实是一个巨大的挑战，但我们会竭尽全力去解决。
多年来，我们的工程师一直在调试大型分布式TCP应用程序，他们精通如何追踪问题，无论是网卡、PCI总线还是其它什么故障。他们总是迅速投入工作，我相信他们也非常享受在AI集群中遇到的挑战。
现在，我想向我们的合作伙伴提出一个问题，这更多是关于人的方面。与我们一起合作的人们，让我们携手进行常规的测试和基准测试，看看哪些地方可以复用我们之前开发的硬件和软件。总的来说，只要大家能帮助我们简化运营、调试、部署和测试流程，那么将产品集成到我们的系统中就会更加容易。
通常在POC和实验室中，系统可以正常工作，但真正投入使用又是另一回事。因此，让这个过程变得更简单真的非常有帮助。
最后，我来回顾一下刚才提到的几个要点：不断演进的模型需求、异构集群测试、软件基准测试、组件复用以及人才。这些都是我所描述的工作的重要组成部分。但近几年，这项工作确实迅速增加。我们需要继续这样努力，以推动未来集群的发展。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）