Meta AI基础设施十年演进：从GPU集群到自研芯片的下一代蓝图

关键词：基础设施演进、AI集群、大语言模型、GPU扩展、自研芯片

我们仍处于人工智能工作负载演进和应用的早期阶段。过去几年我们一直忙碌不停，而未来几年的发展速度将更快。人工智能对硬件提出的需求，丝毫没有放缓的迹象。

在过去的21年里，Meta实现了指数级增长，从一个连接美国几所大学数千人的小型社交网络，发展成为拥有多款应用程序和新型硬件产品、服务全球超过34亿用户的企业。

多年来，我们的基础设施也发生了显著演进，从少数托管机房里少量服务器上运行的几个软件系统，发展成为一个规模庞大、覆盖全球的网络化运营体系。在此过程中，我们面临了诸多挑战，并研发出创新性解决方案来克服这些困难。

人工智能的出现，彻底改变了我们对基础设施扩容方式的所有认知。 为 AI 构建基础设施，需要在技术栈的每一层都进行创新，涵盖硬件、软件、网络，乃至数据中心本身。

Facebook最初是基于开源的LAMP技术栈（指由Linux操作系统、Apache网页服务器、MySQL数据库和PHP编程语言组成的一套常用开源软件组合，广泛用于搭建网站和Web应用）构建的。秉承这一根基，我们的大部分成果都以研究论文、开源硬件及软件系统的形式，与工程界共享。我们始终坚守这一开源愿景，并且在推动计算机科学前沿发展的同时，也将阐述我们如何致力于为芯片和硬件系统采用开放标准的方法。

问题一：技术路径的可持续性与系统脆弱性

文中提到，Meta通过清空多个生产数据中心构建了包含129k H100 GPU的单一AI集群，并计划进一步扩展至1GW（Prometheus）甚至5GW（Hyperion）级别的超大规模集群。这种高度集中的超大规模AI集群架构，虽然在计算密度上具有优势，但也带来了单点故障风险、能源供应压力与散热极限等系统性挑战。Meta如何确保这类集群在极端负载、硬件故障或能源中断情况下的稳定性与韧性？ 是否有可能因过度集中而导致整体AI服务的大规模中断？

Meta在构建超大规模AI集群时已意识到集中化带来的风险，并正在通过多层容错架构、跨地域分布式训练、以及软件定义的基础设施来缓解系统脆弱性，但能源与散热挑战仍处于持续攻坚阶段。具体依据与措施包括：

1. 软件层容错与故障屏蔽
   • 后文提到，Meta开发了 Kraken（实时流量负载测试系统）、Maelstrom（数据中心级灾难处理系统）等，旨在“安全高效地处理数据中心规模的中断，同时最小化用户影响”。
   • 在AI训练任务中，Meta通过 与行业合作制定标准化中断/可靠性指标，并优化检查点与任务重启机制，以应对GPU故障和内存错误。
2. 跨数据中心分布式集群
   • Meta 明确提出其下一代AI集群 Prometheus 将是“跨越多个数据中心建筑的1GW集群”，并开发了Twine和MAST等软件栈以支持“跨地理分布式数据中心的远距离训练”。
   • 这种架构本身就旨在避免单点故障，通过物理分散来提升系统韧性。
3. 能源与散热挑战的应对
   • 文中指出，Meta的AI机架（如GB200）功耗已达 ~140kW，且缺乏液冷设施，依赖先进机架级散热设计（如AALC系统）防止过热。
   • Meta正在探索 硅光子技术和更高能效的网络方案，以降低单位计算功耗，并计划通过 开放计算项目（OCP）推动供电与散热标准的演进。

Meta并未忽视超集中化集群的风险，而是通过软硬件协同设计、跨地域分布式架构、以及行业合作来提升韧性。然而，能源效率与散热仍是尚未完全解决的“硬约束”，也是其持续投入研发的关键方向。

问题二：开源策略与自研硬件的利益冲突

Meta强调其对开源硬件与软件的长期承诺（如参与OCP、开源PyTorch等），但同时也在大力推动自研芯片（如MTIA）和定制化硬件生态系统（如Catalina机架、GB200/B300系统）。Meta在推动自研AI芯片与定制化硬件的过程中，如何平衡其开源愿景与商业竞争优势之间的潜在冲突？ 是否可能存在“开源表象下的硬件锁定”，即通过开源软件栈绑定自研硬件，从而在生态中形成实质性壁垒？

Meta试图通过“开源软件栈 + 开放硬件标准 + 自研芯片差异化”的组合策略，在生态共建与竞争优势之间取得平衡，但其自研芯片（如MTIA）与定制化硬件（如Catalina）也可能在事实上形成“软性绑定”，尽管其宣称坚持开放。具体如下：

1. 开源软件栈作为统一接口

   • Meta 强调，以 PyTorch 和 Triton 为代表的开源框架为开发者提供了“一致的编程接口”，旨在降低对底层硬件的依赖。
   • 这一策略使得第三方硬件（如 AMD MI300）能够接入 Meta 的 AI 生态，有助于减少供应商锁定风险。

2. 开放硬件标准与行业共建

   • Meta 是 开放计算项目（OCP） 的核心推动者，已累计贡献 187 项技术方案，并开源了 Catalina 机架设计，以推动供电、散热、互联等基础设施标准的统一。
   • 文中呼吁“标准化系统、机架和网络”，以促进多供应商间的互操作性，降低生态碎片化。

3. 自研芯片聚焦差异化需求

   • MTIA 主要针对广告推荐等内部负载进行优化，其目标是提升能效与性能成本比，而非完全替代第三方 GPU。
   • Meta 同时采用 NVIDIA、AMD 与自研芯片的混合策略，以匹配负载的异构性，避免对单一供应商的依赖。

4. 潜在冲突与“软性锁定”风险

   • 尽管 Meta 积极推动开放标准，但其自研芯片与定制化硬件（如 GB200/B300）深度集成于自身软件栈，可能导致“最优性能仅在其自有硬件上实现”的事实标准。
   • 文中提到“我们需要软件创新与标准以跨异构硬件运行任务”，暗示了当前跨平台兼容性仍面临挑战。

Meta 试图以开源软件和开放标准为基础降低生态壁垒，同时通过自研芯片在关键负载上建立效率优势。这种 “开放生态 + 内部差异化” 的策略在理论上可行，但在实践中可能因性能优化的路径依赖而形成隐性绑定。其长期效果将取决于 Meta 能否真正坚持接口开放与标准化。

一、基础设施技术栈的扩容（2004-2010 年）

在发展初期，我们的工程工作重点是实现软件技术栈的扩容。当 Facebook 从哈佛大学扩展到其他大学时，每所大学都拥有独立的数据库。登录 Facebook 的学生首先连接到一组公共网络服务器，这些服务器再将学生引导至其所在大学的数据库。很快我们发现，学生们希望能与其他大学的朋友建立联系——这便是我们社交图谱的起源，它将社交网络上的所有用户相互关联起来。

随着 Facebook 的覆盖范围从大学扩展到高中，再到面向普通公众，平台用户数量大幅增长。我们通过 扩大内存缓存（Memcache，一种用于临时存储数据以加快后续访问速度的技术）的部署规模来应对数据库负载压力，随后 又开发了全新的软件系统，如 TAO 社交图谱系统，以及 一系列新的缓存和数据管理系统。此外，我们还为动态消息（News Feed）开发了新的排序服务，为照片和视频共享功能开发了照片服务。

不久之后，我们的业务开始从美国扩展到欧洲。此时，仅实现软件系统的扩容已不再足够，我们还需要寻找其他扩容途径。于是，我们将目光投向软件之下的层级，开始对物理基础设施进行扩容。我们从旧金山湾区的小型托管机房，扩展到弗吉尼亚州阿什本的托管机房；与此同时，我们在俄勒冈州普林维尔和北卡罗来纳州福里斯特城建设了首批自有数据中心。

随着物理基础设施扩展到多个数据中心，我们面临了两个新问题。

• 首先，我们需要将分布在美国和欧洲的用户群与我们的数据中心连接起来。为解决这一问题，我们大力建设边缘基础设施，在每个本地互联网服务提供商（ISP）附近部署一定的计算能力，并加入对等网络（指不同网络之间直接连接以实现数据交换的网络架构，可减少数据传输延迟和成本），通过该网络将互联网服务提供商与我们的数据中心相连。
• 其次，我们需要在每个数据中心复制整套软件系统，确保无论用户连接到哪个物理位置的服务器，都能获得一致的使用体验。这就要求我们构建一个高带宽、多路径的骨干网络，将所有数据中心互联起来。

起初，这需要建设地面光纤网络，将加利福尼亚州和弗吉尼亚州的各个托管机房与俄勒冈州和北卡罗来纳州的新数据中心连接起来。

随着全球用户数量的增长，我们的基础设施从单个数据中心建筑扩展到由多栋建筑组成的数据中心区域。同时，我们也在大力扩大边缘节点的覆盖范围，目前已在全球运营着数百个接入点（POP，指网络服务提供商为用户提供接入服务的物理节点，通常部署在用户密集区域）。

二、扩容过程中的挑战（2010-2020 年）

构建全球范围的基础设施，也随之带来了计算机科学领域各类复杂的极端情况问题。

2.1 缓存一致性

首先，我们需要解决缓存一致性问题。我们曾遇到过这样的情况：
* 用户收到自己被标记在某张照片中的通知，却无法查看该照片；
* 或者聊天会话中的用户收到的消息顺序混乱。

出现这些问题的原因是，我们的每个数据中心区域仅服务一部分用户。在同一区域内的用户能正常接收通知并查看正确数据，而不同区域的用户则会因数据更新在分布式服务器集群中同步需要时间，出现数据延迟，进而导致使用体验不一致。为解决这些问题，我们开发了能实现缓存失效（当原始数据更新后，删除缓存中旧数据的操作，确保用户获取最新数据）的新型软件系统，最终还为分布式系统构建了一致性应用程序接口。

2.2 集群管理

随着新数据中心区域的不断增加以及服务器集群规模的扩大，我们还需要开发新的抽象管理方式，也就是 将复杂的底层系统功能封装成更简洁、易于操作的管理接口，通过心的抽象来对其进行管理。这包括以下系统及相关组件：
* Twine：一种集群管理系统，可扩展至管理单个数据中心区域内的数百万台服务器。
* Tectonic：一种数据中心级别的分布式文件系统。该系统可以将多个服务器上的存储资源整合起来，为用户提供统一存储服务的系统。
* ZippyDB：一种强一致性的分布式键值存储系统。该系统将数据以“键-值”对的形式存储在多个服务器上，并确保所有服务器上的数据始终保持一致的系统。
* Shard Manager（分片管理器）：一种全球范围内的系统，用于管理数千万个数据分片，也就是将大规模数据分割成多个小块分别存储的方式，这些数据分片托管在数十万台服务器上，为数百个应用程序提供服务。
* Delos：我们全球基础设施的新型控制平面。将负责管理和控制网络或系统中数据转发、资源分配等核心功能的层面。
* Service Router（服务路由器）：用于管理我们的全球服务网格，通过将分布式系统中的各个服务连接起来，实现服务间通信、监控和管理的基础设施层。

我们开发了上述系统以及其他众多系统，目的是在运营全球数百万台服务器集群的同时，确保提供出色的性能。

2.3 掩盖硬件故障

服务器数量越多，发生故障的可能性就越大。为应对这一问题，我们致力于确保能向用户掩盖硬件故障，提供高可用性和高可访问性的服务。我们通过开发以下新型系统实现了这一目标：
* Kraken：利用实时流量负载测试来识别并解决资源利用率瓶颈的系统。此过程会模拟真实用户流量对系统进行压力测试，从而发现系统中限制整体性能的关键资源或环节。
* Taiji：用于管理用户流量负载均衡的系统。该系统会将用户请求均匀分配到多个服务器上，避免单个服务器过载。
* Maelstrom：能安全、高效地应对数据中心级别的灾难如大规模断电、硬件故障等，同时将对用户的影响降至最低的系统。

我们持续在可靠性和容错能力方面投入大量资源，因为稳定性对于所有使用我们服务与亲友及合作商家保持联系的用户而言至关重要。

三、人工智能工作负载的兴起（2020 年）

在我们应对基础设施扩容挑战的同时，也逐渐意识到人工智能工作负载（指用于训练或运行人工智能模型的计算任务）将对我们的基础设施产生深远影响。

3.1 图形处理器（GPU）的出现

我们首次遭遇由人工智能引发的基础设施挑战，实际上始于 21 世纪 10 年代末——当时短视频开始流行。这类内容的消费者希望获得个性化推荐，这与我们此前的内容排序模式截然不同。

Meta 的应用程序构建之初，基于的理念是“用户属于拥有共同兴趣的社群”。因此，Facebook 展示的内容是根据社群成员的喜好来筛选的，而非直接了解单个用户及其兴趣。与之相反，如果要为用户提供有趣的短视频流，就必须理解平台上所有已上传的视频，并为每位用户挑选出其可能感兴趣的内容。

这是一个截然不同的问题。

• 在旧模式中，我们只需对用户好友（通常仅有数百人）互动过的内容进行排序；
• 而在新模式下，我们需要对所有已上传的内容进行排序，其规模比每位用户的好友数量高出多个数量级。而且，我们 不仅需要进行一次排序，还需要为每位用户针对每一条内容生成定制化的排序结果。

这正是 GPU 和其他人工智能加速器发挥作用的领域。与主要作为加载-存储型设备的 CPU 不同，GPU 是一种向量和矩阵处理设备，其计算能力比 CPU 高出多个数量级。

当面对规模极大的数据集例如视频库时，我们可以构建嵌入向量（embedding，一种将非数值数据如文本、图像、视频等转换为数值向量的技术），即将每个视频以数值向量的形式进行数学表示。该向量能在低维空间中捕捉视频的上下文信息，使语义相似的内容在向量空间中位置相近。之后，我们就可以构建一个模型，追踪用户在浏览视频库时的点击序列，并预测他们未来可能感兴趣的视频。由此可见，人工智能结合了内容相似性的数学概念与 GPU 的计算能力，实现了个性化推荐。

在 21 世纪 00 年代至 10 年代期间，互联网服务的扩容方式是采购成本效益高但可靠性较低的 CPU、内存和硬盘，然后通过开发软件系统来掩盖硬件故障。与之相反，人工智能集群是一种高性能计算系统，由数百甚至数千台性能极强、内存充足的 GPU 组成，这些 GPU 通过高带宽、低延迟的网络互联，并搭配有定制化的软件栈，以最大限度地发挥系统性能。

我们最初的人工智能集群连接了 4000 台 GPU，用于训练我们的排序和推荐模型。

AI 集群的组件，包含：前端（Front）、后端（Back）、主开关设备（MSB）、T1 读取器（分布在所有主开关设备中）、NSI 行、T5/T8 存储（分布在所有主开关设备中）、标准机架（Standard Racks）、两个不同的 256-GPU 训练集群（每个都位于单个主开关设备附近）、人工智能机架（AI Racks）

就在我们构建首个 4000 台 GPU 的人工智能集群时，我们意识到需要从整体上规划基础设施，综合考虑数据中心空间、冷却系统、机械系统、硬件、网络、存储和软件等各个方面。而且，随着人工智能集群规模和复杂性的不断提升，相关挑战也日益增多。

四、大型语言模型的崛起（2022 年）

这种情况一直持续到 2022 年大型语言模型开始兴起。当时，我们的人工智能集群规模为 4000 台 GPU，但每个训练任务通常仅在 128 台 GPU 上运行。

当我们开始训练大型语言模型时，情况迅速发生了变化。

大型语言模型需要的计算能力大幅提升，而且投入到预训练任务中的计算资源越多，最终得到的模型性能就越好。在短短几周内，我们不得不将训练任务的规模从 128 台 GPU 扩大到 2000 台，随后又进一步扩大到 4000 台 GPU。

这是我们首次需要常规处理需数千台 GPU 同步运行的训练任务。任何一台性能滞后的 GPU 都会影响整个集群的性能。

我们很快发现，扩大训练任务规模伴随着各种各样的挑战。GPU 可能发生故障、内存可能出现错误、网络可能出现抖动……而且，与传统的网络工作负载类似，服务器数量越多，发生故障的可能性就越大。 但这一次，故障规避并非易事——因为与处理网络请求不同，在人工智能训练工作负载中，整个训练集群都在运行同一个任务，任何一次故障都可能导致整个任务中断。如果任务中断过于频繁，由于 checkpoint 和重启任务需要耗费大量时间，我们的训练工作将难以取得进展。通过与行业伙伴的合作，我们成功将中断率降低了约 50 倍（基于标准化的中断/可靠性指标）。

在构建更大规模集群的同时，我们还在人工智能基础设施的各个方面投入资源开展基础研发工作。大型语言模型影响了我们排序和推荐模型的开发方式。例如，分层序列 transduction 单元（HSTU，一种用于处理序列数据的人工智能组件）将生成式推荐系统的训练和推理速度提升了 10 至 1000 倍。

五、加快图形处理器规模与人工智能基础设施建设（2023 年）

在努力优化 4000 台 GPU 规模训练任务运行效果的同时，我们也意识到需要找到构建更大规模集群的方法。我们充分利用现有资源，设计了一个能利用整栋数据中心建筑供电能力（通常为几十万兆瓦级）的集群。

这一举措促使我们在 2023 年末构建了两个各包含 24000 台 H100 GPU 的集群，一个采用无限带宽，另一个采用融合以太网的远程直接内存访问。这种设计使我们能够探索不同的网络技术，同时为人工智能团队提供训练更大规模大型语言模型如 Llama 3 所需的计算能力。

尽管我们的这两个 24000 台 GPU 集群在 2023 年跻身全球最大规模集群之列， 但人工智能研究人员发现，投入到预训练中的计算资源越多，大型语言模型的质量和性能就越高。因此，基础设施工程师的任务是将人工智能集群的规模再扩大一个数量级。

为实现这一目标，我们采取了 Meta 历史上从未有过的举措：正如我们此前所提及的，Meta 的数据中心通常以区域为单位部署，每个区域包含五栋或更多相同规格的建筑，且位于同一地点。我们清空了五座在用的数据中心，仅用了几个月时间，就构建了一个包含 129000 台 H100 GPU 的单一人工智能集群！

我们的数据中心通常由位于同一地点的多栋建筑组成

我们目前面临的最后一个挑战是效率问题：哪些硬件和软件解决方案能最有效地支持我们关注的工作负载，并最大限度地提高数据中心容量的利用率？

遗憾的是，我们的人工智能工作负载并非同质化的。为应用程序提供个性化用户体验的排序和推荐模型，与大型语言模型的需求不同；而且大型语言模型本身也在迅速发展。我们正迅速从预训练时代迈向一个新的阶段——在这个阶段，强化学习、有监督微调、测试时推理和推理能力的重要性日益提升，且都需要定制化的硬件和软件支持。

鉴于 Meta 在人工智能领域的宏大目标，我们需要与不同的供应商合作，以促进市场多样性。我们相信，拥有多种选择将有助于形成更健康的生态系统，并在长期内催生更优质的解决方案。

在构建人工智能基础设施的过程中，我们既利用了 AMD、NVIDIA 等合作伙伴提供的解决方案，也采用了自主研发的定制化芯片。下图展示了一个包含六个机架的机柜组（pod），中间两个机架装有 72 台 NVIDIA Blackwell GPU，功耗约为 140 千瓦！由于我们的传统数据中心没有机房液体冷却系统，因此我们不得不部署四个空气辅助液体冷却（AALC，一种结合了风冷和液冷优势的混合冷却技术，通过空气辅助液体带走热量）机架，以防止设备因过热而损坏！

我们的 GB200 机架（名为 Catalina），带有连接到单个机柜组的空气辅助液体冷却系统 空气辅助液体冷却系统其中一个的后视图

这个机柜组的半精度浮点数（FP16）计算能力达到了 360 千万亿次/秒（PFLOPS）。为了让大家更直观地理解这一规模：这个机柜组的功耗是普通 CPU 的 800 多倍，而计算能力则是普通 CPU 的数十万倍！ 我们也已开始着手研发下一代系统 GB300，它在多个方面都比 GB200 有所改进。

5.1 Meta 训练与推理加速器（MTIA）

除了投资AMD MI300等第三方加速器，并利用PyTorch、Triton等软件栈来屏蔽硬件差异，Meta也在大力投入自研芯片。Meta训练与推理加速器（MTIA）是专为我们的排序和推荐推理工作负载优化的芯片。目前，该芯片已在数据中心大规模部署，主要用于处理广告相关工作负载，相比供应商提供的芯片，它在效率方面为我们带来了巨大优势。

这仅仅是Meta芯片研发计划的开端。用于排序和推荐任务的训练芯片也已开始进入量产阶段。此外，我们还有多款处于不同开发阶段的芯片，预计将在未来几年内部署使用。

MTIA v2，将为我们的排序和推荐广告模型提供支持

在深入开展自主芯片设计的过程中，我们也遇到了一些扩容方面的挑战。

5.1.1 对先进封装技术的需求

晶体管的缩放速度已无法跟上性能需求的增长速度。

目前，掩模版尺寸（指用于制造芯片时，承载电路图案的模板尺寸，决定了单块芯片的最大面积）限制在 830 平方毫米， 这意味着如果需要的性能超过单块芯片所能提供的极限，唯一的选择就是采用多芯片方案。

在处理大型语言模型的过程中，我们发现性能扩容的需求极为迫切，这迫使我们必须采用上述多芯片方案，以满足每一代新模型的性能需求。而这一挑战还因以下情况变得更加复杂： 这些芯片【只能】通过先进的 2.5D 和 3D 封装技术实现相邻放置。

• 2.5D 封装：指将多块芯片通过中介层连接在同一基板上的封装方式。
• 3D 封装：指将多块芯片垂直堆叠并实现互联的封装方式，能进一步缩小芯片体积、提高互联速度。

这不仅限制了我们能构建的芯片阵列规模，还引发了能源效率和散热方面的担忧。我们认为，除了先进的冷却解决方案外，先进的封装技术通过集成多个芯粒（chiplet，指将芯片拆解成多个功能独立的小芯片，再通过封装技术组合成完整芯片的技术）或整合不同功能（计算、内存、输入/输出），也有助于克服这些挑战。

5.1.2 投入内存解耦解决方案的研发

推理模型、测试时推理和强化学习的兴起，都给内存子系统带来了额外压力。我们正开始在计算芯粒附近堆叠高带宽内存 （HBM，一种高速内存技术，能为芯片提供极高的数据传输速度），以最大限度地提高输入/输出带宽。

但芯片上可用于集成内存的空间有限，因此我们必须在芯片的计算能力、内存容量和网络带宽之间做出艰难权衡。更不用说，添加多个高带宽内存还会带来更多的散热问题。相反，投入研发性能更高的网络，并将高带宽内存放置在芯片外部甚至服务器外部，或许能缓解这些问题。

5.1.3 硅光子技术的必要性

在规划芯片发展路线图的过程中，我们发现每个机架的最小功率预算大幅增加。我们正在构建规模越来越大、互联性越来越强的芯片，而这也带来了不断增长的电力需求。

硅光子技术（指利用硅材料实现光信号传输和处理的技术，具有传输速度快、能耗低、抗干扰能力强等优势）拥有诸多优势，例如能在更长距离上实现更快的信号传输，这可能会显著降低机架的整体功耗。 这类先进的光学解决方案也是突破 3.2 太比特（T）带宽限制、摆脱连接更多端点所需的背板限制的唯一可行途径。

当然，这些解决方案也面临着自身的挑战，例如与电信号传输相比，其功耗更高、可靠性更低。最终，未来的解决方案必须能在不同技术和供应商之间实现互操作，比电信号传输更可靠，并且能够实现大规模量产。我们正积极开展研究，以应对这些艰巨的硬件挑战，并与行业生态系统合作，推动该领域的发展。

六、开放标准在人工智能扩容中的作用

虽然硬件的多样化为我们提供了更多选择，使我们能够通过匹配定制化解决方案来满足不同工作负载的需求，从而应对工作负载的【异质性】， 但这也给超大规模数据中心运营商、云服务提供商以及硬件和软件开发人员带来了管理挑战。

2025 年我们已投入生产的部分加速器，包含MI300X、MTIA、H200、B200、GB200等

• 从运营商的角度来看，Meta 每年需要应对 5-6 种不同型号的硬件，这无疑增加了管理难度。服务器集群的异质性使得工作负载难以在不同硬件之间灵活迁移，导致硬件利用率低下。
• 对于软件工程师而言，为不同类型的硬件开发和优化工作负载也颇具难度。如果新硬件需要重新编写库、内核（这里的理解即可包括 GPU 内核，也有对操作系统的核心组件，负责管理系统资源和硬件交互）和应用程序，那么人们对新硬件的接受度将会大打折扣。

事实上，当前的行业现状也给硬件公司的产品设计带来了困难——他们难以确定应针对哪些数据中心、机架或电源规格进行设计。

要解决这些问题，我们需要开放标准、开放权重模型（指将模型的参数权重公开，允许开发者自由使用、修改和部署的人工智能模型）和开源软件。

PyTorch 和 Triton 等开源软件通过为机器学习开发人员和研究人员提供统一的编程接口，发挥了重要作用。开放权重模型让应用程序开发人员能够以经济高效的方式获取高质量的大型语言模型，同时也为基础设施和硬件工程师提供了可优化的标准工作负载。

从一开始，我们就是数据中心基础设施开源硬件的坚定支持者。我们是开放计算项目（OCP， 一个致力于推动数据中心硬件开源的社区，旨在通过协作开发降低硬件成本、提高效率 ）的创始成员，并始终是该项目技术内容和知识产权的主要贡献者。自该项目启动以来，Meta 已贡献了 187 项成果（约占所有技术贡献的 25%）。与开放计算项目社区的合作在运营层面为我们带来了好处——

• 提高了服务器集群的一致性；
• 在财务层面也带来了收益——通过规模经济降低了成本；
• 在技术层面则促进了创新——让各公司能够携手合作，共同探讨解决方案。

虽然我们已在通用计算集群中看到了显著成效，但在人工智能时代，这些益处还将进一步放大。

例如，去年在开放计算项目全球峰会上，我们发布了 Catalina——一款专为人工智能工作负载设计的开源高功率机架，以及 Grand Teton 的新版本——我们的人工智能硬件平台，采用单一整体式系统设计，集成了电源、控制、计算和架构接口。

但在推动开放标准方面，我们仍有很长的路要走。 随着机架功率密度的不断提高，我们需要对系统、机架和电源进行标准化。这些通用抽象层（通过将不同硬件或系统的共性功能提炼出来，形成统一的接口或规范），有助于我们在构建下一代数据中心和电网时，继续快速创新并实现规模化部署。近期推动开放计算机架标准适配人工智能需求的举措，就是这种标准化的一个实例。

我们需要对人工智能集群所使用的纵向扩容（指通过提升单个设备的性能来增加系统整体性能）和横向扩容（指通过增加设备数量来扩大系统整体性能）网络进行标准化，以便用户能够混合搭配不同的 GPU 和加速器，始终使用最新且性价比最高的硬件。

我们还需要软件创新和标准， 以支持在分布于不同地理位置的异构硬件上运行任务。这些开放标准需要贯穿整个技术栈，而且目前存在大量消除阻碍人工智能基础设施建设的摩擦点的机会。

七、下一阶段（2026 年及以后）

没有人能确切预测人工智能领域将如何继续发展。但我们清楚的是，计算能力是构建更高质量模型的关键。

在 Meta，我们的目标是构建能够提供最佳、最具吸引力体验的模型，并成为数十亿日常使用我们产品的用户的个人助手。

为这类复杂模型构建基础设施，意味着需要积极应对数据中心各个层面的挑战——从先进封装、热管理、电源传输到内存解耦，同时利用光学技术实现可扩展的网络互联。

我们的下一代人工智能集群 Prometheus，将是一个跨越多栋数据中心建筑、功率高达 1 吉瓦（GW）的巨型设施。构建 Prometheus 是一项重大的工程壮举，其基础设施分布于同一数据中心区域内的多栋（不少于五栋）建筑中。尽管单个数据中心区域的规模已相当可观，但它仅占这 1 吉瓦设施的一小部分。因此，我们采用了创新的扩容方法：通过将集群部署在多栋传统数据中心建筑、多个防风雨帐篷以及相邻的托管机房中，实现了这一宏伟目标。同时，我们也在持续完善软件栈（包括 Twine 和 MAST），以支持跨地理分布的多数据中心进行长距离模型训练。

我们的 1 吉瓦集群 Prometheus 正在建设中

我们还规划了规模更为庞大的 Hyperion 集群，预计将于 2028 年开始投入使用。建成后，Hyperion 集群的容量将可扩展至 5 吉瓦。

Hyperion集群建成后将具备5千兆瓦的容量。

我们仍处于人工智能工作负载演进和应用的早期阶段。过去几年我们一直忙碌不停，而未来几年的发展速度将更快。人工智能对硬件提出的需求，丝毫没有放缓的迹象。

关注“鲸栖”小程序，掌握最新AI资讯