Meta 披露 AI 存储蓝图：百 EB 级 Tectonic 之上重建 BLOB 存储

在最新一篇 @Scale 技术博客中，Meta 工程团队详细介绍了其面向 AI 训练负载的存储架构演进。博客指出，尽管过去几年 AI 模型能力与训练数据集规模呈指数级增长，前沿模型发布间隔已从数月压缩至数周，但存储与互联性能的提升却相对滞后，存储瓶颈仍是 GPU 资源闲置的主要原因，直接影响 AI 研发成本与上市节奏。

Meta 存储体系总览

Meta 运营着数百个 EB 级存储集群，支撑 Facebook、Instagram、Reality Labs、Meta AI、广告、数据仓库及内部数据库等内外部产品。其存储服务对外提供对象存储、文件系统与块设备三类 API，这些 API 共同构建在名为 Tectonic 的横向可扩展基础块层之上。

Tectonic 是一个区域级多租户存储底座，通过纠删码保障高持久性与可用性，并支持 HDD 与闪存等不同介质之间的分层，以及冷热温数据的智能放置。在 Tectonic 之上的 BLOB 存储层则暴露全局、理论上无限可扩展的存储抽象，并允许用户在持久性与可用性之间做策略权衡。

Llama 训练栈的迁移路径

在早前一场 @Scale 演讲「Training Llama: A Storage Perspective」中，Meta 曾介绍如何通过在 Tectonic 块层之上暴露类 NFS 文件系统接口来直接训练 Llama。博客称，这一架构在 Meta 内部仍被广泛使用，但现代训练栈正逐步迁移到 BLOB 存储接口之上，这一方向也与业界趋势一致。迁移动机在于：BLOB 存储层可对超大规模数据湖提供统一访问，同时具备更高性能。

AI 负载对存储的新要求

Meta 团队强调，现代 AI 负载在 I/O 特征上与传统 Web 应用差异显著：突发且持续的高吞吐、可预测且有界的尾延迟（pMax），以及多变的 I/O 模式。BLOB 存储近年的优化重心因此从通用能力转向「最大化 GPU 利用率」。

以模型训练为例：

• 数十万块 GPU 在多个 epoch 内反复遍历海量数据，并以 batch 形式迭代。
• 每隔若干步，各 GPU 需同步状态。
• 只要其中一块 GPU 因存储拉取延迟而阻塞，整体训练步完成时间就会被拉长。

博客以两张 GPU 的数据加载流水线为例说明：若 dataloader 对下一 batch 的预取延迟低于 GPU 计算耗时，GPU 持续处于计算与 I/O 重叠状态；一旦预取延迟超标，GPU 便会陷入 I/O 等待，整步完成时间被显著延后。

传统 BLOB 架构的瓶颈

Meta 团队坦承，旧的 BLOB 存储架构是多年「有机演化」、逐层叠加而成，部分层无状态，但另一些层维护各自的元数据服务。在以 HDD 为主的传统场景下，这些元数据访问延迟并不构成瓶颈；然而面对 AI 工作负载所需的毫秒级闪存访问，这类叠加已成为「致命问题」。

以一个典型的 getObject("/bucket/path") 请求为例，请求进入 API 服务器后，需在 namelayer、volumeslayer、containerlayer 等多个组件间反复查询元数据，才能将路径解析为 (blockId, offset, size) 元组：

• 部分查询会跨区域，单次往返延迟可观。
• 多次查询叠加，总延迟可达数百毫秒。
• 任何一个慢响应都会拖慢整个请求。

解析完成后，API 服务器再从 Tectonic 层代理数据至客户端。在 AI 负载的新约束下，旧架构的几大设计前提被逐一打破：

• 性能与延迟：传统负载的延迟需求相对温和，AI 工作负载却要求端到端可预测、且对尾延迟 pMax 有明确上界。
• 可靠与持久：旧架构默认全局复制数据与元数据以应对区域级故障，AI 负载在可用性上的要求更高，「全局默认复制」的前提已不再适用。
• 成本效率：旧栈基于 HDD 优化、追求单字节成本最低，AI 负载对 IOPS 的要求显著改变了这套取舍。

（原文在描述新一代架构针对上述问题进行重新设计的具体细节处被截断，Meta 表示将在后续内容中展开。）