跳到正文
Meta Engineering·· 4 天前精选AI 评分75

深入 Meta Prometheus:吉瓦级超级集群的建设与可靠性工程

Inside Prometheus: Meta’s Journey to a Gigawatt-Scale Supercluster

AI 导读

Meta 详解吉瓦级超级集群 Prometheus 的硬件、网络与可靠性工程,其第一阶段已完成并用于训练 Muse 基础模型。集群目前拥有数十万 GPU,正向约 1 million GPUs 扩展;Muse Wonder 预训练和强化学习运行的有效训练时间占比分别超过 85% 和 90%。

推荐理由

通过备用 GPU、分层故障恢复与逐项归因的工程实践,解释超大规模训练如何减少中断并提高有效吞吐量。

正文 · AI 翻译
  • 随着 Muse 基础模型系列近期发布,我们希望带你深入了解让这一切成为可能的基础设施。
  • 我们的吉瓦级超级集群 Prometheus 的第一阶段已竣工,我们正努力将其规模扩大至  ~100 万个 GPU。
  • Prometheus 还采用了闭环液冷等技术,以帮助其高效运行。

目前,在俄亥俄州新奥尔巴尼,Meta 正在推进其迄今最雄心勃勃的 AI 基础设施项目。Prometheus,我们的吉瓦级超级集群,代表着我们基础设施的一次进步,正在训练下一代基础模型,为数十亿人带来全新的 AI 体验。

两年前,新奥尔巴尼还是一个处理网络流量的传统数据中心园区。随着硬件、网络和建筑设计的进步,我们改造了这个园区,使其能够承载前沿模型的训练任务。我们正在分阶段建设这一超级集群。第一阶段已竣工,并已用于训练我们的 Muse 基础模型,其中包括 Muse Wonder 模型。这些全新的前沿模型在个人和专业智能体任务中实现了业界领先的性能。

大型训练任务需要所有环节都以最佳状态运行,才能维持其性能;单台主机出现问题,就可能拖慢或中止整个任务,降低其“有效吞吐率”。通过着力提升系统的稳定性和可靠性,我们在 Muse Wonder 的预训练运行中实现了超过 85% 的有效吞吐率,在强化学习(RL)运行中实现了超过 90% 的有效吞吐率。在这些训练运行期间,按实际经过时间计算,我们实现的整体平均中断间隔时间(MTBI)为 ~47k GPU 小时。此后,我们在整个计算集群中进一步实施了多项变更,包括修复固件,将 MTBI 提高至超过 54K GPU 小时,而且我们仍在不断改进。

现在,我们正着眼于 Meta Superintelligence Labs 的下一代前沿模型,继续扩大 Prometheus 的规模。

Prometheus 超级集群位于 Meta 在俄亥俄州新奥尔巴尼的数据中心内。

超级集群:解锁全新 AI 能力

如今,Prometheus 由分布在多栋互联建筑中的数十万个 GPU 组成,这些建筑包括传统数据中心建筑、针对 AI 优化的数据中心建筑和快速部署设施,均通过绵延数英里的光纤紧密互联,像一台机器一样运行。 

这一容量让我们能够探索比以往实际可行的规模更大的模型和更长的上下文窗口。达到完整规模后,Prometheus 将包含约 100 万个分布式 GPU,全部同步运行。 

多代 AI 硬件

Prometheus 目前部署了两种 NVIDIA GPU 平台,第三种平台(基于 NVIDIA 的 Vera Rubin NVL72)也即将到来。每一种平台都借助我们的 NVL72 机架架构,实现了性能和效率的代际飞跃;在这一架构中,72 个 GPU 在同一网络互连结构内作为单个加速器运行。

Catalina:NVIDIA GB200

我们的首个平台 Catalina 采用 NVIDIA GB200 NVL72。我们部署的是 Ariel 变体,这是一种双机架配置,每个机架中的 36 个 GPU 通过 NVLink 互连,形成一个统一的 72-GPU 域。与 Grand Teton H100 相比,Catalina 在原始计算能力和内存容量方面均有所提升。它采用了我们的 Open Rack V3 (ORv3) 高功率机架(HPR)结构,这是一项贡献给 Open Compute Project (OCP) 的开放硬件设计。 

GB200 NVL72 的 Ariel 变体为每个 NVIDIA Blackwell GPU 配备一个 NVIDIA Grace CPU 和 2 个 NVIDIA ConnectX-7 400G 网卡,CPU 与 GPU 的比例为 1:1,使我们能够先于业内其他企业,为每个 GPU 部署 800G 的 I/O。我们选择 Ariel,是因为相较于 NVIDIA H100,GB200 NVL72 几乎在所有其他维度上都实现了提升:FLOPS、HBM 带宽、纵向扩展带宽和纵向扩展域规模,而每个 GPU 的横向扩展带宽却仍会停留在 400G。我们预计这种不均衡会损害性能,因此选择了一种能为每个 GPU 提供 800G 横向扩展带宽的配置。随着该区域不断扩展,以及 800G 横向扩展能力逐渐可用,这也使我们的规格更加统一。


Catalina GB200 NVL72 的特性包括:

  • 72 个 NVIDIA Blackwell GPU,配备 13.4 TB HBM3e(每个 GPU 192 GB)。
  • 720 PFLOPS 的 FP8 峰值训练算力(FP4 下为 1,440 PFLOPS)。
  • 130 TB/s 的峰值 NVLink 带宽,用于域内互连。
  • 576 TB/s 的峰值聚合内存带宽。
  • 约 120 kW 的系统总功耗,涵盖两个配对机架。

Clemente:NVIDIA GB300 NVL72

我们的第二个平台 Clemente 转向采用 NVIDIA GB300 NVL72,在 GPU 和平台层面均较 Catalina 有所提升。GB300 将每个 GPU 的 HBM 容量提升至 1.5 倍,从 192 GB 增至 288 GB,稠密 FP4 吞吐量也以类似幅度提升,同时注意力(softmax)加速能力大约翻倍。在平台层面,横向扩展不再像在 GB200 NVL72 上那样构成制约:NVIDIA ConnectX-8 SuperNIC 原生即可为每个 GPU 提供 800G 带宽,因此我们在 Ariel 上提前部署的能力成为了基准配置。这一点加上 2:1 的 GPU 与 CPU 比例,使 Clemente 能够将完整的 72-GPU 域装入单个机架,简化了我们的物理部署。Clemente 可以搭配我们的模块化空气辅助液冷(AALC)部署,也可以在我们新设计的数据中心中使用设施液冷(FLC)。布线的减少也显著改善了可维护性。

Clemente GB300 NVL72 的特性包括:

  • 72 个 NVIDIA Blackwell Ultra GPU,配备 20.7 TB HBM3e(每个 GPU 288 GB,比 GB200 多 50%)。
  • 超过 1 exaFLOP 的 FP4 峰值算力。
  • 130 TB/s 的峰值 NVLink 带宽(每个 GPU 的双向带宽为 1.8 TB/s)。
  • 约 135 kW 的机架功耗。
  • 性能提升 5-10%,相较于 GB200 NVL72。

连接超级集群

在传统 Web 服务中,数据中心网络在服务之间传输请求和响应,而这些服务的实例通常不需要高带宽、高性能,也不需要跨多台服务器进行紧密的步调一致的协调。大规模 AI 训练需要具备所有这些条件,这意味着连接这些服务器的网络如今已成为 AI 工作负载的重要组成部分。为最好地满足这些需求,除了连接服务器的标准数据中心网络外,几年前我们还增加了一个 独立的专用数据网络,它基于以太网,称为后端(BE)网络,可实现数据中心楼宇内部及楼宇之间的 GPU 到 GPU 直接通信。

大型预训练作业将训练划分为采用数据并行的模型副本,从而形成网络使用的层次结构:对延迟和带宽敏感的操作集中在副本内部,而能够容忍较高延迟和较低带宽的流量则安排在副本之间。我们的网络设计与这一层次结构相匹配,在楼宇内部采用低延迟、高带宽的网络架构,并通过聚合网络连接各楼宇的网络架构。 

我们与 Meta Superintelligence Labs 密切合作,确保并行设计、流量模式、通信算法和软件均得到优化,尽可能减少网络通信耗时的显露。这使 GPU 尽可能保持忙碌,而不是等待网络。

过去几年,Meta 团队已在早期的楼宇级 24K GPU 集群和我们的区域级 100K+ GPU 集群中应用了这些网络理念,而在 Prometheus 中,我们将其规模和覆盖距离提升到了新的水平。

网络架构

在楼宇层面,每个基于以太网的网络架构通过高带宽、低延迟的多层拓扑互连最多 20,736 个 GPU。我们最初的设计采用解耦式调度网络架构(DSF),以缓解训练集合通信造成的网络拥塞。这类通信通常包含少量规模大、持续时间长的网络流,在传统负载均衡技术下会发生冲突;DSF 通过在网络架构中采用子数据包级多路径路由和数据包重排序,并结合虚拟输出队列和基于信用的端到端流量控制来缓解这一问题。 

随着以太网网卡技术的发展,端点能够进行数据包重排序,我们得以升级为非调度网络架构(NSF),采用浅缓冲 51.2T 以太网交换机,例如支持动态负载均衡的 Minipack3,以及基于 NVIDIA Spectrum-4 交换机 ASIC 的Minipack3N ,后者配合 ConnectX 网卡上的 NVIDIA 自适应路由使用。DSF 和 NSF 均基于 Meta 的FBOSS 网络协议栈,使我们能够自主控制 Prometheus 中网络架构的快速迭代和优化,并获得大规模运行这些集群所需的可观测性。

聚合

后端聚合(BAG)网络是一个多层级的中心辐射型网络,连接 Prometheus 集群中各建筑级网络,跨度从 2 km 到超过 100 km。它采用搭载深缓冲 Broadcom Jericho3 芯片的 Arista 7800 系列机框构建,为每对区域提供数 Pbps 的带宽。

在这一网络上运行预训练,需要与 Meta Superintelligence Labs 开展专项优化工作,以确保训练速度不受影响,尤其要考虑这些距离下的光速限制。

综合来看,Prometheus 网络的复杂性涉及数百万英里的光纤纤芯、数万台交换机和数百万个光模块——从建筑内部短距离、低成本的 2×400G FR4 LITE 可插拔模块,到用于超过 ~10 km 链路的 800G-ZR 相干光模块。

在每个层面构建可靠性

在 Prometheus 这样的规模下,每个组件的可靠性都需要受到监控。任何位置的单点故障都可能导致整个训练作业停摆,浪费宝贵的计算资源。 

要维持这一水平的可靠性,就需要与 NVIDIA 采用超越传统供应商关系的联合工程模式。双方团队深度驻扎在我们的数据中心,共享实时遥测数据,并开展联合故障排查会议,按根本原因剖析每一次系统停机。

这种以故障归因为导向的责任机制,确保双方都专注于有针对性的改进。Meta 优化调度和基础设施,NVIDIA 则处理固件、信号诊断和内存管理问题。这种透明度消除了模糊地带,推动双方组织更快地修复问题。

72-GPU 故障域

从 H100 一代的 NVL8 架构过渡到 NVL72,从根本上重新定义了我们保障基础设施韧性的方法。在 NVL8 时代,纵向扩展域——即通过 NVLink 紧密耦合、用于张量并行的一组 GPU——仅限于八个单元。采用 NVL72 后,这一域扩大到 72 个 GPU,使故障影响范围扩大至 9 倍。

更大的纵向扩展域赋予了 NVL72 带宽优势,但也使 72-GPU 机架成为我们规划容量时所依据的分配单位。训练并行在组大小为 2 的幂时映射效率最高,因此,每个 NVL72 域运行一个 64-GPU 切片,并将剩余八个 GPU 保留为机架内备用。当 GPU 发生故障时,备用 GPU 会立即接替,使作业从上一个检查点重新启动,而不必等待硬件维修,机架也能继续参与作业。机架内冗余将有效机架故障率降至由可导致整个 pod 离线的故障所决定的下限;对于更罕见的整机架故障,我们额外保留约 2% 的机架作为备用。对于一次使用 32,768 个活跃 GPU 的训练运行,这意味着要配置 523 个 NVL72 机架,即 37,656 个 GPU,比活跃 GPU 规模高出约 13%。其中大部分余量(11%)源于 72 个 GPU 中使用 64 个的切片配置,而非纯粹的可靠性开销。

物理复杂性进一步提高了这些可靠性要求。单个 NVL72 域包含 5,184 条经过调优、以 200 Gbps 运行的差分对信号链路,每条链路都经过多个潜在故障点,包括 GPU SerDes、计算托盘 PCB、线缆盒和交换机托盘接口。在如此密集的互连结构中,以每通道 200 Gbps 的速率维持一致的信号完整性,构成了这一规模下前所未有的工程挑战。

故障恢复 

故障恢复关注的是如何应对故障,以尽量减小其对训练时间的影响。根据故障的影响范围,我们通过两种机制加以处理:

并行感知容错(PAFT):当故障能够被隔离到一个数据并行模型副本时,我们允许单个故障副本下线,而集群其余部分重新执行该步骤并继续有效训练,从而降低硬件故障的影响。受影响的分片只需在可用的备用主机上重启并重新同步,即可将可能导致整个系统停摆的故障转化为总体吞吐量轻微、暂时的下降。

检查点保存:当故障影响范围大于一个数据并行模型副本时,整个作业会从最近的检查点重新启动;频繁保存检查点可以减少此类事件造成的工作损失。我们的分布式检查点架构会将模型状态(包括梯度和优化器数据)异步保存到多层存储中。我们采用增量检查点和内存暂存,确保这些保存操作对训练吞吐量的影响降至最低。

这两种故障恢复机制与备用策略相结合,利用机架内预先分配的备用 GPU 托盘以及备用机架,尽量缩短替换硬件的启动时间,并减少硬件故障造成的工作损失

系统性减少中断

训练前沿模型时,基础设施可靠性需要超越单纯可用性的视角。根本挑战在于保持训练持续推进,避免系统频繁停摆。在 Prometheus 中,我们将中断定义为任何迫使作业暂停并启动恢复周期的故障,涵盖 GPU 芯片缺陷、网络互连异常、存储瓶颈或散热限制。

这些中断带来了巨大的运维开销,因为我们的工作负载高度相互依赖;72-GPU 域内的单个故障就可能影响整个集群的总体吞吐量。这种性能损失直接影响我们的工程迭代速度,导致有效算力减少,并延长向数十亿人交付先进 AI 体验的时间。

在 2025 年中期 Prometheus 的初始阶段,我们的中断率达到峰值,每 8K GPU 每天发生近 1,000 次中断。经过一年的严格跨职能工程工作,我们将中断次数减少了 99%,使集群能够持续并行运行多个规模达数万 GPU 的训练作业。

要实现这种稳定性,需要对每个中断来源进行细粒度拆解,然后针对每类故障部署有针对性的工程解决方案:

NVLink 信号完整性:最初是 GB200 部署的主要瓶颈。由于 NVLink 连接数量超过 600,000,即使轻微的信号劣化也会触发频繁的 NVLink 恢复周期。我们实施了持续遥测和自动标记,利用 L11 诊断烤机测试,在投入生产前定位薄弱链路。我们的分类工具能够区分瞬态故障与持续性信号完整性故障,从而指导有针对性的维修和组件更换,并在修复后的系统重新投入生产前进行验证。 

内存可靠性(HBM 和 LPDDR):随着我们扩大采用更高内存容量的 GB300 的部署规模,内存相关故障成为中断的主要来源。通过与 NVIDIA 密切合作,我们利用集群遥测和详细的错误分析来识别反复出现的故障特征,并通过优化 HBM 固件设置、内存巡检、改进的 LPDDR 纠错算法,以及基于模式的预测性检测来缓解这些故障,在性能退化的设备影响作业吞吐量之前将其停用。我们正在整个集群中部署这些变更,并衡量其对中断率和硬件更换需求的影响。

NVLink 交换机与互连网络健康状况:单个交换机故障就可能影响整个 NVL72 域。我们以毫秒级分辨率监控互连网络的健康状况,利用自动恢复路径隔离故障组件,并在其余基础设施之间重新均衡流量,而不中断作业。

后端网络事件:在 BAG 超级脊层,链路事件通过基于硬件的故障检测机制进行透明处理。我们的平面拓扑可确保在单根光纤或单个端口发生故障时重新路由流量,而不会中断同步的 GPU 突发流量。

持续改进由我们的运维基础设施推动:驻扎在 New Albany 站点的故障分诊团队、March 开展的全面稳定性攻坚行动(同步了整个技术栈的修复工作),以及严格的、以归因为导向的问责框架。每次维修后都必须经过隔离验证,以确认系统完整性,然后才能重新加入计算资源池。

我们的可靠性核心目标仍然是每 8K 个 GPU 每天发生两次中断,即平均中断间隔时间(MTBI)约为 100k GPU 小时。将中断率从峰值降低 99% 表明,在 Prometheus 的规模下,稳定性是一项能够通过工程手段解决的工程挑战。

在集群规模下推动硬件成熟

部署数十万个第一代加速器,会暴露出在较小规模下隐藏的质量问题。GB200 的部署已使硬件成熟度提升成为我们团队和合作伙伴的一项主要工程工作。

工程工作领域包括:

  • 快速部署固件包:我们构建了可靠且快速的固件包自动化部署机制,能够在几小时内向超过 100k 个 GPU 部署固件和驱动程序修复。我们已将单个 pod 升级耗时的 P90 从硬件引入初期的超过七小时缩短至两小时。这使我们能够针对主要中断类别,向整个集群快速推送修复。
  • 集群健康状况:我们关联分析跨多个机架系统的遥测数据,并对每一次作业中断进行分类,以指导软件修复、硬件维修和更换决策。我们跟踪 MTBI、可用容量以及有效训练吞吐量,并建立了完善的反馈循环,将硬件和软件可靠性的提升转化为更高效的计算产出。 
  • 跨合作伙伴质量验证:与多家制造合作伙伴开展并行验证,通过来自生产集群的持续反馈确保质量一致。
  • 自动化信号筛查:在任何生产流量接入之前,使用诊断压力测试验证超过 600,000 条 NVLink 路径。在这样的规模下,即使缺陷率很低,也需要主动识别。
  • 供电压力测试:研究 PSU 模块与稳压器在单个 GPU 的 1,400W 负载下如何相互作用,以发现只有在大规模部署时才会出现的故障模式。
  • 精密液冷:对冷板和歧管组装实施严格的质量把关,以维持最佳结温,并防止整个集群发生泄漏。
  • 集群维护:主动准备、快速处置、确定修复维修的优先级,以及提前部署备件。 
  • 健康检查:通过先进的入库验收/老化测试和作业前健康检查,识别健康节点,将其纳入大型训练作业。

从 Blackwell 到 Vera Rubin,每一种新的平台架构都融入了这些实际运营经验,在每一步中收紧我们的筛查和设计规范。

优化功耗与管理瞬态波动

最大限度提高吞吐量、尽量减少闲置电力,并开展同步分布式训练,这些目标在给定功率范围内带来了供电挑战。当数万个 GPU 同步执行计算密集阶段和通信周期时,会引发大幅功率瞬态波动——集群内的负载会突然波动 30-40%。启动或暂停一项大型训练作业,就可能在短短数秒内引起数十兆瓦以上的负载变化。

我们通过 Dynamo Dimmer 应对这一问题。这是我们覆盖整个集群的电源管理框架,支持智能功率限制。Dimmer 不会强行停止工作负载,而是在集群接近供电上限时逐步调整 GPU 功率限制,确保训练不中断。该系统还配有用于应对瞬时尖峰的机架级备用电池(BBU)模块、用于平滑峰值的电容器托盘(CBU)、设施级电池储能系统(BESS),并通过与电力供应商深入协调,管理这些 AI 特有的用电特征。 

管理异构集群的冷却

虽然分布式方法让我们得以快速构建 Prometheus,但这也意味着需要应对不同地点各自特定的供电和冷却限制。 

我们的物理基础设施融合了多代冷却技术,为这些高功率机架提供所需的液冷。Prometheus 采用模块化风辅助液冷(AALC)的混合部署,涵盖我们的自然风冷数据中心建筑和快速部署结构。我们专为 AI 优化而建的建筑现已采用设施液冷(FLC),以实现最高功率密度。 

除了自有建筑外,我们还整合了向战略合作伙伴租赁的容量,从而加快部署进度并提高可部署的总容量。与此同时,我们的工业级快速部署结构重新定义了建设模式,能够以更短的工期交付可投入生产的算力。

高效运营 

在 New Albany,我们长期以来一直与当地公用事业公司合作,确保我们全额承担园区的能源成本,不给当地电网增加任何不必要的负担。我们还与能源开发商合作,新增清洁能源和可再生能源,以匹配我们的能源使用量。 

Meta 最新的 AI 优化数据中心采用闭环液冷,因为这是冷却 GPU 服务器最高效的方式,同时也有助于高效用水。直接面向芯片的闭环液冷让我们能够在单个服务器机架上容纳更多 GPU,从而节省空间。我们还通过 OCP 向更广泛的行业分享液冷网络机架 IcePack 等系统的设计,以拓展我们的可持续发展工作。

Prometheus 之外

我们将继续与 NVIDIA 密切合作,通过混合部署 NVIDIA GB300 NVL72 和 NVIDIA Vera Rubin NVL72 来扩展 Prometheus 的容量。

NVIDIA 的下一代 Vera Rubin NVL72 平台将在单 GPU 性能上实现代际飞跃,并直接集成到 Prometheus 现有的网络架构中。随着集群日趋成熟,我们将通过即将推出的 San Miguel 平台引入 Vera Rubin,扩充其主要由互联 GB300 构成的容量,从而进一步提高每瓦算力。


San Miguel Vera Rubin NVL72 将具备以下特性:

  • 72 个 NVIDIA Vera Rubin GPU,每个 GPU 配备 288 GB HBM4,峰值带宽为 19.2 TB/s。
  • FP4 训练算力峰值为 2.52 EFLOPS FP8 训练算力峰值为 1.26 EFLOPS,均为每机架指标。
  • NVLink 峰值带宽为 216 TB/s(每个 GPU 的双向带宽为 3 TB/s)。
  • 总内存带宽峰值约为 1,500 TB/s。
  • 全液冷计算托盘,每机架功率超过 170 kW。
  • 每瓦性能提升 10-20%,相较于 GB300 NVL72。

Prometheus 的技术成果帮助确立了蓝图,为我们今后应对超级集群设计的复杂性提供指导。我们即将在 Louisiana 州 Richland Parish 建设的超级集群 Hyperion,正从设计之初就融入 Prometheus 带来的经验。它将采用闭环液冷、与我们的公用事业合作伙伴 Entergy 实现全面电网连接(相关成本由 Meta 全额承担),以及下一代网络设计。 

进一步了解我们在 New Albany 的社区工作。

文章《走进 Prometheus:Meta 打造吉瓦级超级集群的历程》最先发表于 Meta 工程博客。

来源:Meta Engineering · engineering.fb.com