跳到正文
Meta Engineering Blog·· 3 小时前精选AI 评分77

Meta 详解 Prometheus 吉瓦级超级集群:一期已建成用于训练 Muse 模型

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

AI 导读

Meta 介绍其位于俄亥俄州 New Albany 的吉瓦级超级集群 Prometheus,一期已建成并用于训练 Muse 基础模型(含 Muse Wonder),最终将扩展到约 100 万张 GPU。

推荐理由

Meta 官方拆解 Prometheus 超级集群的组网、可靠性与功耗工程细节,读者可以了解吉瓦级训练集群如何维持 85% 以上 goodput。

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

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

两年前,新奥尔巴尼还是一个承载网络流量的传统数据中心站点。随着硬件、网络和建筑设计的进步,我们重新改造了这个站点,使其成为前沿模型训练项目的所在地。我们正在分阶段建设这个超级集群。第一阶段已经完成,并用于训练我们的 Muse 基础模型,包括 Muse Wonder 模型——这是我们新的前沿模型,在个人和专业智能体任务上实现了最先进的性能。

大规模训练任务要求一切以最优状态运行才能维持其性能;单台主机上的一个问题就可能拖慢或中断整个任务,降低其“有效算力产出”(goodput)。通过专注于提升系统的稳定性和可靠性,我们在 Muse Wonder 的预训练运行中实现了超过 85% 的有效算力产出,在强化学习(RL)运行中实现了超过 90% 的有效算力产出。在这些训练运行期间,我们实现了约 4.7 万 GPU 小时的整体挂钟平均无中断时间(MTBI)。此后,我们在整个集群上又进行了更多改进,包括固件修复,将 MTBI 提升至超过 5.4 万 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 NIC 配对,CPU 与 GPU 的比例为 1:1,使我们能够比业界其他公司更早地部署每 GPU 800G 的 I/O。我们选择 Ariel 是因为 GB200 NVL72 在几乎所有其他维度上相对于 NVIDIA H100 都实现了扩展:FLOPS、HBM 带宽、scale-up 带宽和 scale-up 域大小,而每 GPU 的 scale-out 带宽本会停留在 400G。我们预计这种不平衡会损害性能,因此选择了一种每 GPU 提供 800G scale-out 的配置。这也让我们随着区域扩展、800G scale-out 变得可用时,规格更加统一。


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)加速大约翻倍。在平台层面,scale-out 不再是 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 通过在网络结构中使用亚数据包级多路径路由和数据包重排序,并结合虚拟输出队列和基于信用的端到端流控制来实现这一点。 

随着以太网 NIC 技术的进步,能够在端点处进行数据包重排序,我们得以升级到非调度网络结构(NSF),使用浅缓冲 51.2T 以太网交换机,例如带有动态负载均衡的 Minipack3,以及基于 NVIDIA Spectrum-4 交换机 ASIC 的Minipack3N ,并在 ConnectX NIC 上使用 NVIDIA 的自适应路由。DSF 和 NSF 都基于 Meta 的FBOSS 网络栈,这使我们能够控制并快速迭代和优化 Prometheus 中的网络结构,并具备大规模运营这些集群的可见性。

汇聚

后端聚合(BAG)网络是一个多层 hub-and-spoke 网络,连接 Prometheus 集群中各建筑级 fabric,跨度从 2 公里到超过 100 公里。它采用 Arista 7800 系列机箱构建,搭载深度缓冲的 Broadcom Jericho3 芯片,每个区域对可提供数 Pbps 的带宽。

在此网络上运行预训练需要与 Meta Superintelligence Labs 进行专门的优化工作,以确保训练不被拖慢,尤其是考虑到这些距离下的光速限制。

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

每个层面的工程可靠性

在 Prometheus 的规模下,每个组件都需要进行可靠性监控。任何地方出现单一故障都可能中止整个训练任务并浪费宝贵的计算资源。 

维持这一级别的可靠性需要与 NVIDIA 建立共同工程模型,这超越了传统的供应商关系。团队深度嵌入我们的数据中心,共享实时遥测数据并开展联合故障排查会议,以按根本原因分解每一次系统停机。

这种归因驱动的问责模型确保双方都专注于有针对性的改进。Meta 优化调度和基础设施,NVIDIA 处理固件、信号诊断和内存管理。这种透明度消除了歧义,并推动两家组织更快修复问题。

72-GPU 故障域

从 H100 一代的 NVL8 架构过渡到 NVL72,从根本上重新定义了我们应对基础设施韧性的方式。在 NVL8 时代,scale-up 域——通过 NVLink 紧密耦合用于张量并行的 GPU 组——被限制为 8 个单元。借助 NVL72,该域扩展到 72 个 GPU,使故障影响范围增加了 9 倍。

更大的 scale-up 域正是 NVL72 带宽优势的来源,但它也使 72-GPU 机架成为我们围绕其规划容量的分配单元。训练并行性最高效地映射到 2 的幂组大小,因此每个 NVL72 域运行一个 64-GPU 切片,并将其余 8 个 GPU 保留为机架内备用。当某个 GPU 发生故障时,备用 GPU 立即取代其位置,因此任务从上一个检查点重新开始,而不是等待硬件维修,机架也继续留在任务中。机架内冗余将有效机架故障率降至由可能导致整个 pod 失效的故障所设定的下限;对于更罕见的整机架故障,我们保留大约 2% 的额外机架作为储备。对于 32,768 个活跃 GPU 的训练运行,这意味着需要配置 523 个 NVL72 机架,即 37,656 个 GPU,比活跃占用高出约 13%。其中大部分余量(11%)来自 64-of-72 切片几何结构,而不是绝对的可靠性成本。

物理复杂性进一步加剧了这些可靠性要求。单个 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 部署的主要瓶颈。由于拥有超过 60 万个 NVLink 连接,即使是轻微的信号衰减也会触发频繁的 NVLink 恢复周期。我们实现了持续遥测和自动标记,利用 L11 诊断烧机在生产前隔离弱链路。我们的分类工具能够区分瞬时故障与持续的信号完整性故障,指导针对性维修和组件更换,并在将修复后的系统重新投入生产前进行验证。 

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

NVLink 交换机和网络架构健康:单个交换机故障就可能危及整个 NVL72 域。我们以毫秒级分辨率监控网络架构健康状态,利用自动恢复路径隔离故障组件,并在不中断作业的情况下将流量重新平衡到剩余基础设施上。

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

持续改进由我们的运营基础设施驱动:位于 New Albany 站点的同地分诊团队、3 月份同步整个技术栈修复的全面稳定性冲刺,以及严格的归因驱动问责框架。每次维修都必须经过强制隔离,以在返回计算池之前验证系统完整性。

我们的可靠性北极星仍然是每 8K GPU 每天两次中断,即约 10 万 GPU 小时的 MTBI。从中断率峰值实现 99% 的降低表明,在 Prometheus 的规模下,稳定性是一个工程挑战,并且有可解决的工程成果。

在集群规模上使硬件成熟

部署数十万个第一代加速器会暴露出在较低规模下被隐藏的质量问题。GB200 的部署已将硬件成熟转变为我们团队和合作伙伴的首要工程学科。

工程领域包括:

  • 快速固件包部署:我们构建了可靠且快速的固件包自动化,能够在几小时内将固件和驱动程序修复部署到超过 10 万个 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,有助于节省空间。我们还通过与更广泛的行业分享系统设计来延续我们的可持续发展工作,例如通过 IcePack(我们的液冷网络机架)以及 OCP。

超越 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 峰值带宽。
  • 2.52 峰值 EFLOPS 的 FP4 训练算力 1.26 峰值 EFLOPS FP8 训练,每机架。
  • 216 TB/s 峰值 NVLink 带宽(每个 GPU 双向 3 TB/s)。
  • 约 1,500 TB/s 峰值聚合内存带宽。
  • 全液冷计算托盘,每机架功率超过 170 kW。
  • 每瓦性能提升 10-20%,相比 GB300 NVL72。

Prometheus 中的技术成就帮助建立了蓝图,将指导我们未来如何应对超级集群设计的复杂性。我们即将在路易斯安那州 Richland Parish 推出的超级集群 Hyperion,正在从头开始设计,并充分考虑了来自 Prometheus 的洞察。它将具备闭环液冷、与我们的公用事业合作伙伴 Entergy 的全面电网连接——Meta 为此支付全部成本——以及下一代网络设计。 

了解更多关于我们在 New Albany 的 社区工作。

文章 深入 Prometheus:Meta 迈向吉瓦级超级集群的历程 首次发表于 Engineering at Meta。

来源:Meta Engineering Blog · engineering.fb.com