日期：2026-07-05
主题：Meta 万亿参数 AI 训练的存储蓝图
原文：Meta 万亿参数 AI 训练的存储蓝图
来源：Engineering at Meta
领域：🏗️ 系统工程
过去几年，AI 模型的参数规模和训练数据集的增长速度远超大多数人的预期。GPT-4 到 GPT-5 用了不到两年，前沿模型的发布间隔从几个月缩到了几周。但有一个被很多人忽视的瓶颈正在浮现——存储。
Meta 的工程博客在 2026 年 7 月初发布了一篇深度技术文章，详细拆解了他们怎么从零重建面向 AI 训练的 BLOB 存储架构。这不是一篇"我们把缓存加大了一倍"的增量优化文章，而是一次彻底的架构范式转变：从为 HDD 和 Web 服务设计的存储栈，到为 GPU 集群和 AI 训练设计的原生存储栈。本期我们就来深入看看 Meta 到底做了什么、为什么这么做，以及它对整个 AI 基础设施的参考意义。
要理解 Meta 为什么大动干戈，先看清一个问题：AI 训练的存储瓶颈到底有多严重。
Meta 给出的数据很直观。一张 H100 GPU 在训练时，如果数据加载延迟超过阈值，GPU 就会进入等待状态——什么都不干，就在那里空转。在万卡甚至十万卡集群规模下，哪怕 1% 的空转率，对应的算力浪费都是天文数字。
但为什么存储会成为瓶颈？Meta 的分析指向一个根本原因：AI compute 性能大约每两年翻三倍，但存储和互联性能的增长要慢得多。这个剪刀差在传统 Web 服务时代并不致命——用户请求的 latency 容忍度是百毫秒级别，Web 页面的数据量也相对小。但 AI 训练的工作负载截然不同：
总结成一句话：为 Facebook 的图片和视频上传设计的存储架构，不等于能为 Llama 的训练数据加载提供良好服务。
Meta 的 BLOB 存储层（运行在 Tectonic 块存储之上）是经过了十多年有机演进的产物。功能上它非常强大——支持对象存储、文件系统和块设备 API，全球部署，跨区域复制，HDD/Flash 分层。但它的架构假设已经和 AI 需求脱节了。
问题一：多层元数据带来的长尾延迟。 在旧架构中，一次简单的 getObject("/bucket/path") 请求，在到达真正的存储节点之前，需要经过 namelayer、volumeslayer 和 containerlayer 三层元数据查询。每一层都维护自己的元数据存储，有些查询甚至需要跨区域。累加起来，延迟可以达到几百毫秒。对于 Web 服务的图片加载来说，几百毫秒可以接受；但对于 AI 训练中每次 GPU 的数据加载，几百毫秒的等待就意味着 GPU 空转。
问题二：数据平面代理的吞吐瓶颈。 旧架构中，API 服务器不仅做元数据查询，还扮演数据平面代理的角色——它负责把 Tectonic 块层的数据流 proxy 给客户端。这意味着所有数据都要经过 API 服务器中转，既增加了延迟，又消耗了额外的服务器资源，还让数据路径变得复杂。
问题三：默认全局复制的成本。 传统架构为了保证高可用，默认跨区域复制数据和元数据。这对 AI 工作负载来说是不必要的——训练通常在一个区域进行，数据不需要全局可见。
问题四：HDD 时代的成本优化假设。 旧架构高度优化了每字节的存储成本（适合 HDD 大量数据的场景），但 AI 需要的是高 IOPS（需要 Flash）。更关键的是，Meta 提出了一个新约束——功耗效率。在 GPU 集群中，数据中心的瓶颈从空间变成了电力。每千瓦用于存储，就是少了一千瓦用于 GPU。存储栈不能再"不计功耗"。
这几个问题的根源不是某个组件的 bug，而是整个架构的设计取舍需要重新审视。
Meta 的重建围绕三个核心决策展开。
统一元数据模式。 这是最根本的改动。他们把散布在不同层的元数据全部合并到一个统一的扁平化模式中，底层使用 ZippyDB（Meta 自研的分布式 KV 存储）来承载。改造后的效果是一个 O(1) 查询——给定一个路径，一次查询就能拿到存储地址的映射，不再需要逐层递归查找。这是一个步进式的改进，从"查三层"到"查一次"。
消除数据平面代理。 旧架构中，API 服务器既是控制平面也是数据平面。新架构把数据路径完全去掉——客户端集成一个"胖客户端 SDK"，其中嵌入了 Tectonic BlockClient。客户端从元数据服务拿到 ReadPlan（路径到存储地址的映射）之后，直接从 Tectonic 存储服务器流式读取数据。API 服务器只做控制平面的事情。这不仅大幅降低了延迟，还减少了功耗——因为省掉了大量 proxy 服务器。
区域级部署。 新的 BLOB 存储栈不再默认全球复制，而是设计为可灵活部署为区域级或全球级服务。在 AI 场景下，每个 AI 区域内部署一个与 GPU 机群同位置的区域存储栈。这既降低了跨区域数据传输的延迟，也减少了不必要的复制开销。
这三个改动叠加后的效果是：在 Tectonic 块层之上实现了"零开销"的 BLOB 存储层——新架构为 AI 工作负载引入的额外延迟接近于零。
基础架构重建完成之后，下一个棘手的问题是：AI 训练的数据访问模式天然会产生热点和尖峰。
典型场景：每轮训练 step 结束时，成百上千个 GPU 同时加载下一批数据；checkpoint 恢复时，所有 GPU 同时读取模型权重；某个热门数据集在训练开始时被大量并发访问。如果没有特殊的缓存机制，存储后端会直接被这些流量尖峰打穿。
Meta 用了两种手段解决。
第一，GPU 主机的分布式数据缓存。 他们把 GPU 主机上剩余的内存利用起来，构建了一个分布式数据缓存层，复用 Meta 已有的 Owl 内容分发子系统。所有数据访问都走这个缓存层。实际生产中，这个缓存的命中率平均达到 80%——也就是说，绝大多数数据根本不需要落到存储后端，直接在 GPU 集群内部就完成了交换。
第二，ReadPlan 元数据缓存。 路径到存储地址的映射（ReadPlan）也被缓存在一个分布式内存存储中（类似 memcache）。热点 BLOB 的元数据访问延迟降到了 1-2 毫秒。
这两个缓存机制的组合效果是：吸收了尖峰流量，解决了元数据热点分片问题，并且把 p50 和 p99 延迟降到了内存访问的级别。
架构改造加缓存机制解决了大概 80% 的问题。剩下 20% 靠的是在协议和客户端层面的精细优化。
Hedged reads（对冲读取）。在万卡集群中，总会有个别存储节点响应慢——硬盘老化、网络抖动、CPU 争抢。客户端对这种"慢节点"做 hedged read：先发一个请求，如果在指定时间内没有收到响应，立即向另一个副本发第二个请求，哪个先返回就用哪个。这是 Google 在 Google File System 时代就验证过的经典模式，Meta 在 AI 存储场景下也采用了同样的策略。
动态并发控制。Checkpoint 事件发生时，客户端会创建剧烈的 egress 尖峰——所有 GPU 同时写 checkpoint 到存储。这会导致拥塞、超时和重试，最终反过来 stall GPU。Meta 在客户端 SDK 中内置了一个动态并发控制器，根据应用层的拥塞信号自动调整并发度。流量低的时候放宽限制提高吞吐，流量高的时候收紧限制防止拥塞崩溃。
注意这两项优化都是在客户端 SDK 中实现的，不需要改动存储服务器——这是"胖客户端"架构的一个显著优势：很多智能策略可以集中部署在 SDK 里，快速迭代、统一控制。
以上所有改进的目标都是"最大化 GPU 利用率"。但 Meta 还面临另一个问题——研究迭代速度。
今天的 AI 研究流程是这样的：研究员从各个来源整理数据 → 选一个区域 → 提交数据摄入 job → 等数据拷贝完成（可能需要数小时） → 开始训练 → 分析结果 → 调数据集 → 再来一轮。第二步到第四步可以花掉几个小时，而这几个小时里研究员什么都没干，就是在等数据搬完。
Meta 从这个流程中看到了一个有趣的类比：操作系统怎么做数据加载的？
当一个 Linux 进程读一个文件时，操作系统透明地在各级缓存中逐层填充数据——CPU L1/L2 缓存、内存页缓存、磁盘缓存。用户进程不需要操心"数据现在在哪里"，操作系统自动处理。
Meta 把这个思路移植到了 AI 数据加载中。他们设计了一个三级缓存架构：
在这个分层下，数据加载的流程变成：
prefetch() API。Dataloader 可以提前几分钟触发预取，把即将用到的数据从远程存储"暖"到本地区域的 L3 缓存中，同时预热元数据缓存。这套架构上线后最直观的效果是：数据摄入时间从小时级压缩到了分钟级。论文中给出的数据说明了这一点——大多数工作负载的数据准备时间下降了超过一个数量级。
Meta 这篇文章的价值不仅在于它展示了"我们改了什么"，更在于它清晰地展示了一个思维转变：存储架构正在从"为 HDD 和 Web 服务设计"向"为 Flash 和 AI 训练设计"全面转型。
这里有几条值得所有做 AI 基础设施的人思考的结论：
第一，GPU 利用率不是你买了多少 H100 就决定了多少的。存储延迟上的任何低效都会直接放大为 GPU 空转的浪费。当你花几十万美元买一张 GPU 时，让它在等待 I/O 上浪费哪怕是 5% 的时间，对应每年数十万美元的隐形损失。
第二，胖客户端 SDK 是比 proxy 更优的架构选择。把智能逻辑放在客户端，让服务器变"傻"，是 Meta 整篇文章里反复出现的模式。元数据查询、对冲读取、动态并发控制、分布式缓存、深层预取——所有这些能力都集中在 SDK 层，存储服务器只做最纯粹的块读写。这让迭代速度和控制粒度都大大提升。
第三，操作系统的缓存思想在分布式系统中依然有效。三级缓存 + 预取 + 自动生命周期管理——这些基本概念在单机 OS 中已经验证了几十年。Meta 的贡献在于把它搬到了跨 GPU 主机、跨区域、跨存储介质的分布式环境中，并且证明了它在 AI 场景下同样有效。
文章结尾也提到了一些仍在进行中的工作：存储向网络极限扩展、更高规模下 checkpoint 不 stall GPU、推理场景的新挑战。这表明 Meta 的 AI 存储演进远未结束——当模型参数从万亿继续向十万亿迈进时，存储架构还会面临新的考验。
这篇文章对正在设计或运营 AI 训练基础设施的团队来说，是一份非常有价值的参考蓝图。