Meta’s AI Storage Blueprint at Scale

Meta的AI存储蓝图（规模化）——Meta工程团队

POSTED ON

2026年7月1日

TO

数据中心工程

,

数据基础设施

生产工程

Meta的AI存储蓝图（规模化）

.entry-meta

.entry-header

By

Sidharth Bajaj

Venkatraghavan Srinivasan

过去几年中，模型能力和训练数据集规模经历了指数级增长。在过去的约一年里，新前沿模型的发布周期已从数月缩短至数周。可靠且快速的存储访问对于AI创新的速度和计算成本至关重要。如果AI是大脑，存储就是记忆：能力和速度高度依赖于内存容量和检索速度。

然而，尽管AI计算性能每两年大约提升三倍，存储和互连性能的增长却相对温和。因此，存储瓶颈仍然是AI工作负载中导致GPU停滞的主要原因之一，直接影响支出和上市时间。除了GPU利用率，存储架构还直接影响AI研究的迭代速度；随着GPU日益分布于全球各地且数据集规模持续扩大，研究人员需要花费大量时间在不同区域之间传输数据，从而影响研究效率。在本文中，我们将探讨Meta的BLOB存储架构如何演进以解决两个主要挑战：最大化GPU利用率和最大化研究速度。

存储架构概述

Meta运营着数百个EB级规模的存储集群，为Facebook、Instagram、Reality Labs、Meta AI、Ads、数据仓库和内部数据库等所有外部和内部产品提供服务。我们的存储服务提供对象存储、文件系统和块设备API，这些API抽象层构建在名为Tectonic的水平可扩展基础块层之上。Tectonic层是一个区域级多租户存储架构，通过纠删码技术实现高耐久性和可用性，支持跨介质类型（如HDD和闪存）的分层存储，并通过智能放置热数据、冷数据和温数据来优化租户间的I/O利用率。基于Tectonic的BLOB存储层提供了一个全球可无限扩展的存储架构，并提供让用户在耐久性和可用性之间进行权衡的策略。

在之前的一次@Scale演讲《从存储视角训练Llama》中，我们讨论了Meta如何通过在Tectonic块层之上暴露NFS-like文件系统接口直接训练Llama。虽然这种架构在Meta内部仍被广泛使用，但现代训练栈正逐渐迁移至BLOB存储接口，这在业界也是普遍趋势。这种转变源于对BLOB存储层中大规模数据湖统一存储访问的需求，以及对高性能的迫切需求。

最大化GPU利用率

现代AI工作负载具有“数据饥渴”特性，其工作负载特征与传统Web应用截然不同：突发且持续的高吞吐量、可预测且有限的pMax延迟，以及变化的I/O模式。近年来，BLOB存储的重点已大幅转向最大化GPU利用率。

为什么延迟至关重要

为了理解有限的延迟和低pMax延迟为何重要，让我们以模型训练为例。在训练过程中，成千上万的GPU会多次遍历存储中的海量数据（即跨多个训练周期），并以批次方式训练数据集。每隔一定步骤或批次后，GPU会同步彼此的状态。如果某个GPU速度较慢，这一步骤会拖慢所有GPU以及整个训练进程。

图1展示了两个GPU之间的数据加载流程。每个GPU主机中的数据加载器会预先加载下一个数据批次，同时GPU处理当前批次以实现计算与I/O的最大重叠。对于GPU1，存储获取延迟在合理范围内，因此GPU从未因等待I/O而停滞。对于GPU2，存储获取出现了两次高延迟，导致GPU停滞。这些停滞导致整体步骤完成时间延迟。

图1：两个GPU之间的数据加载。

传统BLOB存储架构并不适用于AI

多年来，BLOB存储以真正面向服务的方式不断演进，层层叠加了大量功能。其中许多层是状态化的，并维护着自己的元数据存储。虽然这些元数据访问延迟通常不是传统HDD场景下的瓶颈，但对于需要毫秒级访问闪存数据的AI工作负载来说却成为致命障碍。图2展示了典型getObject(“/bucket/path”) API的请求流程。请求到达API服务器后，服务器需要在名称层、卷层和容器层进行多次元数据查询，才能将路径解析为一组(blockId, offset, size)元组。部分查询可能跨区域进行，延迟累计可达数百毫秒；任何一次查询的延迟都可能造成整体延迟。查询完成后，API服务器会将Tectonic层的数据代理传输给客户端。

图2：getObject API的旧请求流程。

虽然这种架构能很好地支持传统工作负载，但决定设计取舍的基础假设已发生转变。其中一些变化包括：

• 性能与延迟：如前所述，传统工作负载对延迟的要求较为宽松，而AI工作负载则需要从pMax级别到整个链路的可预测且有限的延迟。

• 可靠性与持久性：传统架构设计为即使在区域故障情况下也具有高度持久性和可用性；数据和元数据默认全局复制。虽然AI工作负载需要极高的可用性，但默认全局复制的设计已不再适用。

• 成本效率：传统架构基于HDD构建，并针对每字节成本进行了高度优化。AI工作负载的IOPS需求要求使用闪存，且存储的计算成本相对于GPU的计算成本已变得微不足道。

• 能效：随着GPU的普及，数据中心的电力限制正逐渐取代空间限制。每千瓦用于存储的电力都是无法用于GPU的电力。这是AI工作负载带来的新约束。

简而言之，取舍空间的变化已足够显著，迫使我们重新思考整个架构。

重建基础

在构建新基础时，我们做出了以下重大设计选择：

• 统一的元数据模式：我们重写了元数据子系统，将原本分散在不同层级的元数据整合为一个由 ZippyDB 支撑的统一扁平化模式。这使得通过 O(1) 查找将路径映射到存储地址成为可能，实现了阶跃式的性能提升。

• 无数据平面代理：我们移除了数据平面代理，构建了一个功能强大的客户端 SDK，能够直接从存储服务器向客户端流式传输字节。这有助于实现功耗效率目标，同时提升吞吐量并降低延迟。

• 区域部署：BLOB 存储堆栈现在更加精简，具备灵活部署为区域服务或全球服务的能力。我们现已在每个 AI 区域内，将区域化 BLOB 存储堆栈与 GPU 部署在同一位置。

图 3：getObject API 的新请求流程。

图 3 展示了 getObject(“/bucket/path”) 的新请求流程。当客户端 SDK 接收到该 API 调用时，现在会向 API 服务器发送 getReadPlan(“/bucket/path”) 请求。API 服务器通过新的元数据存储对每个数据块执行 O(1) 查找，将路径映射到 (blockId, offset, size) 元组。随后，API 服务器将 ReadPlanResult 返回给 SDK。SDK 内嵌了 Tectonic BlockClient，因此现在能够直接从 Tectonic 流式传输这些数据块。通过这些改进，我们重建了底层架构，实现了在 Tectonic 上零开销的目标。通过消除数据代理，我们还确保了功耗预算的控制。

应对峰值和热点

在数据和检查点加载期间，AI 工作负载已知会跨数百个 GPU 并发访问数据。数据子集（如模型权重）通常会成为“热点”，而 GPU 重启等事件会触发剧烈的流量峰值。在底层架构已修复的前提下，我们接下来需要解决的就是这些峰值和热点问题。幸运的是，BLOB 存储层多年来一直有处理热点的经验，因此我们在此处将现有解决方案适配到了 AI 工作负载。具体来说，我们采用了以下两种方法：

• 分布式数据缓存：我们利用 GPU 主机上的空闲内存作为分布式数据缓存，用于存储频繁且并发访问的数据。为实现这一点，我们复用了 Meta 的 Owl 子系统的组件：我们将 Owl 子系统的节点直接集成到 BLOB 存储客户端 SDK 中，使所有数据访问都经过这个数据缓存。

• Readplan 元数据缓存：Readplan 指的是路径到存储地址的映射。我们现在将频繁访问的 BLOB 的 readplan 缓存到一个类似 memcache 的分布式内存存储中。

在实践中，我们观察到分布式数据缓存的平均缓存命中率为 80%，而 readplan 缓存可提供 1-2 毫秒的元数据访问速度。本质上，这些简单的机制实现了以下三点：

• 吸收流量峰值，减少对存储的 I/O 需求。
• 解决元数据热点分片问题。
• 通过内存服务提升 p50 和 p99 延迟表现。

协议优化

到目前为止我们讨论的内容已实现了 80% 的目标。我们通过识别并修复堆栈中的瓶颈实现了剩余的 20%。以下是一些值得注意的问题（当然并非详尽列表）：

• 滞后节点：一个缓慢的存储节点导致尾部延迟。这是一个广为人知的问题，我们通过客户端的带保护读取（hedged reads）来缓解这一问题。

• 出站流量峰值：在检查点事件期间，客户端通常会产生尖锐的出站流量峰值。这反过来可能导致网络拥塞、超时和重试，最终导致GPU停滞。我们通过在客户端SDK上构建动态并发控制来解决这个问题，该控制能够根据应用层的拥塞信号自动调整并行度。

凭借以上所有改进，新的BLOB存储堆栈现在能够处理AI工作负载而不会导致GPU停滞，并且在Tectonic层之上仅增加可忽略不计的开销。我们的下一个重点转向了研究。

最大化研究速度

GPU资源稀缺且日益呈现地理分布特性；同时，出于性能考虑，训练工作负载需要将数据与GPU共置。这为研究人员带来了有趣的挑战：他们现在需要负责跨区域摄入和移动数据集。

在Meta，典型的训练任务提交流程包括以下步骤：

• 研究人员从各种来源整理数据，丰富数据并将其持久化存储在BLOB存储中。
• 研究人员选择一个希望运行任务的区域。
• 研究人员提交一个数据摄入任务，该任务会将训练数据集的快照以优化GPU主机内数据加载的文件格式创建到目标区域。
• 研究人员随后需要等待摄入完成；根据数据集大小，这可能需要数小时。
• 研究人员提交训练任务并监控运行状态。
• 研究人员分析输出结果，调整数据集并再次迭代，从第3步重新开始。

步骤2到4可能需要数小时，直接影响研究人员的迭代速度。理想情况下，我们希望研究人员的时间用于模型调优，而不是等待存储。目前，研究人员在启动任务前会复制快照以实现数据与GPU的共置，这能带来最佳性能。虽然这种针对性能的优化对于持续数周或数月的大规模训练任务是合理的，但绝大多数任务规模要小得多；这些任务的负责人更愿意为了迭代速度而接受偶尔的性能下降。

因此，我们需要一个系统，使研究人员能够一次性摄入数据并在任何地方访问数据，而无需考虑区域边界。我们需要一个工作流程，让研究人员能够在分钟内迭代，而不是数小时。当我们重新审视设计时，这些数据集的“一次写入、多次读取”特性引起了我们的注意。如果我们把存储视为行星级计算机中的磁盘，并借鉴操作系统领域的思想会怎样？当一个运行在CPU核心上的Linux进程尝试从磁盘读取文件时，操作系统会通过内存页缓存和L2、L1 CPU缓存等不同层级的缓存透明地按需填充数据。这种直觉引导我们形成了图4所示的架构演进：

图4：数据加载架构演进。

核心思想是利用主机内和主机外的各种存储资源作为分层缓存，以硬盘作为最终真相来源的全局BLOB存储网络作为底层支持。具体来说，我们利用GPU主机上的内存和闪存作为L1和L2缓存。同时，我们利用由闪存支持的区域BLOB存储网络作为L3缓存。数据加载器继续通过熟悉的BLOB存储SDK访问存储。为了有效隐藏延迟并简化数据生命周期管理，我们依赖以下机制：

• 数据加载器预取：数据加载器在处理当前批次时，会将下一批次的数据集预取到内存中。这种预取操作会在BLOB存储SDK层面表现为一次读取操作。

• 深度预取：我们通过BLOB存储SDK公开了显式prefetch() API接口。数据加载器会通过在后台调用prefetch() API，显式预取未来几分钟内需要的数据。该API会触发从远程存储将数据加载到本地区域L3缓存，并预热元数据缓存。

• 自动数据生命周期管理：L3区域离散化闪存层级中的数据通常会保留配置的时长，以支持训练周期中不同轮次间的重复使用。我们支持自定义的驱逐策略，包括TTL和LRU策略。驱逐策略同时具备容量/配额感知能力。

新数据加载范式在生产环境部署后迅速被采用，目前我们仍在生产环境中同时支持这两种数据加载范式。为了用数字说明影响，图5展示了部署前后所有工作负载的摄入时间对比：

图5：部署前后的摄入时间对比。

在新前沿模型每周发布的时代，这种数据加载范式的转变是加速发展的迫切需求。

核心要点

现代AI工作负载对数据需求旺盛，存储在计算成本和创新速度中都扮演着关键角色。存储瓶颈直接影响GPU利用率和计算成本，在全球分布GPU的场景下，跨区域数据摄入所消耗的时间会直接影响研究迭代速度。Meta的BLOB存储架构最初是为服务Meta应用家族而构建的，为了满足AI工作负载需求，我们需要实现性能的阶跃式提升。这促使我们重新思考整个架构。通过重建元数据子系统，并采用分层缓存架构（结合预取/按需加载），我们能够有效满足当前工作负载的需求。

未来工作方向

我们持续在Meta改进存储系统以适应硬件演进和工作负载需求。该领域的未来工作包括：

• 将存储扩展到网络极限。

• 在更高规模下支持不阻塞GPU的检查点功能。

• 针对推理工作负载的新挑战，我们已开始着手解决。