从一到无穷大 #108：Meta 的 AI 存储架构——BLOB 重构与跨地域数据加载

在 Meta 的旧 BLOB 服务里，数据已经放到闪存上，一次 getObject() 请求中的多层元数据查询仍可能耗费数百毫秒，部分请求还要跨地域。底层介质变快以后，上层存储服务的查找和转发开销开始直接影响 GPU 利用率。 $1$

另一种等待发生在训练之前。GPU 分散在不同地域，研究者要先找到有算力的地方，再把训练数据搬过去。一次小规模实验也可能先花几个小时导入数据，调整数据后再等一轮。

Meta 保留了底层 Tectonic，改造了它上面的 BLOB 访问路径。训练运行时，客户端直接读取数据块，缓存吸收成批 GPU 对热数据和元数据的重复请求。跨地域的小实验可以在首批样本就绪后启动，存储服务根据 DataLoader 的预取信号，在 GPU 计算时准备后续数据。 $1$

1 原有存储体系与 AI 负载的变化

1.1 Tectonic 底座与 BLOB 存储接口

按照 Meta 的披露，它运营着数百个 EB 级存储集群，服务于社交产品、AI、广告、数据仓库和内部数据库等业务。对外暴露的对象、文件系统和块设备 API，都建立在可水平扩展的 Tectonic 基础块存储层之上。

Tectonic 是地域内的多租户存储基础设施，通过纠删码提供较高的持久性和可用性，支持 HDD、闪存等不同介质，并根据数据冷热和租户 I/O 需求安排放置。Tectonic 上面的 BLOB 层提供全局存储访问，并通过策略让使用方选择持久性与可用性的取舍。

较早的 Llama 训练架构，在 Tectonic 块层上提供类似 NFS 的文件接口，训练直接使用这条路径。这套架构仍在 Meta 内部广泛使用；新的训练栈逐步迁移到 BLOB 接口，原因是需要统一访问 BLOB 层的大规模数据湖，同时满足性能要求。本次改造的重点就是这层 BLOB 服务及其客户端。 $1$

1.2 吞吐之外的尾延迟约束

模型能力和训练数据集的规模持续增长，供数能力也要随之提高。Meta 用一个量级对比说明问题：AI 计算性能大约每两年提升到三倍，存储和互连性能的增长却更缓慢。模型与数据集继续扩大，存储瓶颈便会表现为 GPU stall，影响算力支出和模型交付速度。

AI 负载同时需要突发和持续的高吞吐，还存在多种 I/O 模式。数据集读取、模型权重和 Checkpoint 加载，访问对象与并发形态都可能不同；大量 GPU 一起开始读取时，平均带宽之外还要约束最慢请求。

图 1：Meta 原文 Figure 1。DataLoader 将下一批数据的读取与当前 batch 的计算重叠；GPU2 的两次高延迟读取造成计算空闲，并推迟同步完成。 $1$

原文以数十万 GPU 参与、多轮遍历数据集的训练场景说明同步压力。训练以 batch 推进，并在若干 step 或 batch 后同步状态。每台 GPU 主机上的 DataLoader 一边为当前计算供给数据，一边预取下一批。只要读取在当前计算结束前完成，这段 I/O 延迟就能被隐藏；读取晚到，GPU 就会等待，而相关同步点又会把一个参与者的延迟传递给整个训练任务。

图中的 GPU1 没有因读取本身而停顿，但它更早完成工作后，仍要等待 GPU2 到达同步点。因此，存储需要提供可预测的尾延迟。原文将目标写到 pMax，强调连最慢路径也要关注；低平均延迟无法单独保证训练稳定推进。

1.3 旧 BLOB 架构的四项基础假设

旧 BLOB 服务面向以全球 HDD 为底座的业务。Meta 把当时的设计取舍归为四项。 $1$

性能与延迟。 原有业务能容忍逐层查找对象的延迟。同步训练要约束到最慢的一次读取（pMax），否则一台 GPU 等数据，同一轮训练的其他 GPU 也要在同步点等它。
可靠性与持久性。 为了在整个地域故障后仍能访问数据，旧栈默认在全球复制数据和元数据。训练同样要求高可用，但实验可能只在某个地域读一份数据集的一小部分。数据保留几份、哪些地域需要就近读取，变成了两个可以分别决定的问题。
成本效率。 HDD 时代按每字节成本优化。训练把热数据放上闪存以满足 IOPS 需求，存储侧多花一些计算来缩短 GPU 等待，在整项作业的成本里也算得过来。
功率效率。 GPU 集群使机房供电比机架空间更紧张。存储代理每多转发一遍数据，都要消耗本可用于 GPU 的功率预算。

腾讯公司内部，一套早期的共享文件存储给每个文件系统配一台接入机和一块云盘。线上超过 95% 的实例是空的，接入机却一直占着。大客户又受单盘 40 TB、150 MB/s 的限制。后来让多个实例共用接入机，摊薄了空实例的成本。要提高单个实例的带宽，还得让它用上多块盘。

2019 年，为图像训练推出的高性能版本把不同文件分散到多块盘上，单个文件系统的吞吐上限到了 20 GB/s。但每个存储单元都留了一份目录树，哪怕列一个空目录，也要向每个单元各发两次请求。训练程序要先列出样本再随机读图，盘越多，读第一张图之前要等的应答就越多。有的业务干脆自己维护样本清单。

2020 年上线的另一套方案采用开源Lustre，元数据节点与数据节点独立部署，训练客户端可以同时访问多个数据节点。后续自研的通用版本把目录项和文件内容分开管理。一个文件系统的目录项放在同一分区，再加数据盘，列目录也只需问这一个分区。

面向并行训练的版本要解决另一个问题。多台训练机同时读大文件，如果每个字节都经过文件服务器转发，就得为转发流量不断加机器。客户端改为向文件的归属分区申请一段文件的块映射和范围读锁，再按映射直接读云盘。锁有效期间，重读这段数据可以复用映射。追加写仍要分配新块、登记块地址、更新文件大小。文件按名字分区，客户端通常能直接定位一个普通文件，不同文件的更新也能在各自的分区并行提交。如果先写临时文件再改名发布，新旧名字可能落在两个分区，这时由事务协调者记录并推进两个分区的目录项变更。完整列目录也仍要收齐各分区的条目。

再往后的版本减少了小文件读写前的往返。例如把预处理后的样本逐个写成文件，客户端原先要先创建，再执行一次 open 才能拿到文件描述符。现在创建请求直接返回描述符，接着就能写。反复按路径查找已有文件时，客户端也能复用缓存的查找结果。服务端原先每次写元数据的预写日志要落盘两次。把长度一并写进日志末尾后，一次落盘就够了。

Meta 之前的 Tectonic 问题在于。训练程序手里有对象名，旧服务仍可能花几百毫秒逐层查出块地址，才开始一次毫秒级的闪存读。下一批数据晚到，其他 GPU 也得在同步点等。Meta 把多层映射合并，服务端返回块地址、偏移和长度，客户端据此直接读取数据。 $1$

2 胖客户端：缩短 BLOB 请求路径

2.1 旧路径中的多层元数据与数据代理

BLOB 服务经过多年演进，在原有能力上不断增加新的服务层，其中多层是有状态的，并维护各自的元数据。对 HDD 负载而言，这些元数据访问通常不是主要瓶颈；当数据读取已经进入毫秒级闪存路径时，上层开销就很显眼了。

图 2：Meta 原文 Figure 2。API Server 访问多层 BLOB 元数据，解析出存储地址后，再代理底层 Tectonic 的数据流。 $1$

一次 getObject("/bucket/path") 先到 API Server。服务端依次查询 Name、Volume、Container 等层的元数据，将路径解析为一组 (blockId, offset, size)，才知道数据存在哪些块、从什么偏移读取、读取多长。部分查找可能跨地域，多次访问累计到数百毫秒并不罕见，任意一层的慢响应都会拖住请求。

完成查找后，API Server 继续从 Tectonic 读取数据，并把数据代理给客户端。这里同时存在定位和传输两类额外开销：前者经过多层服务，后者让字节流多经过一站。

2.2 统一元数据、客户端直读与区域部署

Meta 重新实现 BLOB 元数据子系统，将分散在多层的元数据合并为由 ZippyDB 支撑的统一、扁平 schema。ZippyDB 是分布式 KV 存储，新的 schema 用于更直接地完成对象路径到存储地址的映射。

数据传输职责则下移到胖客户端 SDK（fat client）。SDK 内嵌 Tectonic BlockClient，可以从存储服务器读取底层块；API Server 负责提供读取计划，字节流直接返回客户端。

图 3：Meta 原文 Figure 3。元数据请求继续经过 API Server，读取计划返回后，客户端直接访问 Tectonic。 $1$

新的调用过程是：

SDK 接到 getObject("/bucket/path")，向 API Server 发送 getReadPlan("/bucket/path")。
API Server 通过新的元数据存储定位数据，生成包含 (blockId, offset, size) 等信息的 ReadPlanResult。
SDK 使用内嵌的 BlockClient，按照读取计划从 Tectonic 流式获取数据。

原文给出的查找复杂度是每个 chunk 做 O(1) 元数据定位。对象包含多个 chunk 时，仍然需要处理对应的块和范围；这里优化的是定位过程的分层开销。

部署也随之改变。精简后的 BLOB 栈既可以全局部署，也可以区域部署；Meta 在每个 AI region 中放置与 GPU 共址的区域 BLOB 服务，让性能路径尽量留在地域内。统一元数据减少查找链路，客户端直读减少代理开销，区域部署减少跨地域访问对关键路径的影响。 $1$

2.3 客户端处理慢节点与流量尖峰

客户端直读后，少量慢存储节点仍会制造尾延迟。Meta 在客户端采用 hedged reads：一个读取迟迟未完成时，再向另一条可用读取路径发出备援请求，利用较早返回的结果缓解慢节点影响。原文没有展开触发阈值和具体副本选择策略。

另一类问题来自客户端出口。Checkpoint 事件可能造成陡峭的流量峰值，随后出现网络拥塞、超时和重试，最终让 GPU 停顿。SDK 因而增加动态并发控制，根据应用层的拥塞信号自动调整并行度。 $1$

3 数据热点与 ReadPlan 热点

3.1 集中读取造成的数据与元数据压力

请求路径缩短后，还要处理集中访问。数据集和 Checkpoint 加载会让数百个 GPU 并发读取；模型权重等内容本身就很热，GPU 重启又会制造尖峰。即使客户端可以直读 Tectonic，同一批内容被反复读取，仍会给底层存储带来集中的 I/O 压力。

定位信息也有对应的热点。大量客户端读取同一个 BLOB，就会反复请求它的 ReadPlan，让相同元数据分片承压。因此，需要分别缓存对象数据和对象路径到存储地址的映射。 $1$

3.2 复用 Owl peer，利用主机内存分发热数据

Meta 利用 GPU 主机上的空闲内存组成分布式数据缓存，将 Owl 子系统的 peer 组件集成到 BLOB SDK，使数据访问统一经过这层缓存。缓存中的热数据可以供其他主机读取，减少重复访问底层存储的 I/O。 $1$

Meta 在 2022 年介绍的 Owl 采用集中控制、分散传输的设计。peer 是嵌入使用方进程的库，负责下载、缓存数据块，并向其他 peer 提供缓存内容；tracker 维护数据块的缓存与下载位置、peer 的位置及缓存状态，决定读取来源、缓存和重试策略。数据在 peer 之间传输，tracker 负责调度，通常优先选择 peer 中已有的内容。 $2$

论文中的临时分发树展示了这条数据路径：tracker 按 chunk 维护临时分发树，同一 chunk 可以有多棵树，peer 可以边下载边向下游转发。 $3$

图 4：Owl 论文 Figure 1，论文第 5 页。原图保留四个阶段，箭头表示数据传输方向。 $3$

图 4(a)(b) 中，A 从外部存储读取，B 从 A 读取，随后 C、D 从仍在下载的 B 获取数据。A 失效后，tracker 让 B 接着从外部存储读取，C、D 继续从 B 接收；B、C 完成下载并缓存后，对应的下载边移除，D 仍可从 B 读取。这样，一批同时请求热数据的客户端可以共享正在流入的内容，减少各自回源。 $3$

3.3 Tracker 分片之间共享数据来源

图 5：Owl 论文 Figure 3，论文第 8 页。虚线框表示不同 tracker 管理的 peer，跨框虚线表示委托得到的数据来源关系。 $3$

图 5 中，tracker 1 通过 tracker 2 找到正在获取该 chunk 的 A，再让 E 从 A 读取；F、G 随后从 E 获取。tracker 交换来源信息，数据仍在 peer 之间流动，避免两个分片各自回源。 $3$

两张图解释的是 Owl 论文的通用机制。2026 年文章明确披露复用了 Owl peer，并未展开 AI 存储场景的 tracker 部署和具体策略。 $1$

3.4 缓存 ReadPlan，缓解元数据热分片

Owl tracker 记录 chunk 在哪些 peer 上以及下载状态；ReadPlan 保存的则是对象路径到底层块、偏移和长度的映射。Meta 将 ReadPlan 缓存放在类似 memcache 的分布式内存存储中。热点对象的定位请求先由缓存承接，避免持续访问相同元数据分片。原文将它作为独立机制介绍，没有说明它由 Owl 实现。 $1$ $3$

原文披露，分布式数据缓存的平均命中率约为 80%，ReadPlan 缓存提供 1---2 毫秒的元数据访问。前者描述数据缓存命中，后者描述定位信息访问，两者对应不同部分的开销。组合起来，缓存能够吸收流量尖峰、缓解元数据热分片，并通过内存访问改善 P50、P99 延迟。 $1$

4 减少跨地域数据准备

4.1 跨地域全量拷贝拖慢小规模实验

训练数据可能保存在一个地域，可用 GPU 却在另一个地域。为了让训练从本地存储稳定读取，原有流程要求先把本次训练所需的数据集复制到 GPU 所在地域，等数据准备完成再启动训练。换一个训练地域，或者调整数据集，研究者就可能重新经历一轮搬运与等待。

Meta 给出了一次典型训练提交的六个步骤：

从多个来源整理、增强数据，并保存到 BLOB 存储。
选择本次训练运行的地域。
提交数据摄取任务，在目标地域创建训练数据集快照，并将数据组织为适合 GPU 主机加载的文件格式。
等待摄取完成，数据量大时可能耗费数小时。
提交训练任务，监控运行。
分析输出、调整数据集，再从第 3 步开始下一轮迭代。

第 2---4 步可能占用数小时，其中第 3---4 步还会随数据调整而重复。对持续数周或数月的大任务，提前复制快照可以换取后续稳定的加载性能；小规模实验则经常只想尽快验证一次数据或模型改动，每轮都先等数小时拷贝，会直接拖慢迭代。Meta 指出，绝大多数任务规模较小，研究者愿意接受偶尔的性能下降，换取更快的实验反馈。

新的目标由此确定：数据摄取一次，随后可以在不同地域使用，研究者不必为每一轮实验手动完成整份数据搬运。Meta 在 2026 年 7 月的文章中提到，前沿模型发布间隔已经从数月缩短到数周。在这样的迭代节奏下，数据准备也需要从小时级压到分钟级。 $1$

4.2 异步加载所需的带宽量级

能否边训练边搬数据，首先取决于训练消费数据的速度。数据集的总容量决定整份复制要等多久，训练期间需要的持续带宽则由单位时间实际读取的数据量决定。

TorchTitan 在 256 张 H100 上测了 Llama 3.1 70B 的预训练吞吐。每个张量并行组用 8 张卡，共 32 组。在相同的混合精度与批量设置下，基线吞吐为 897 token/s/GPU，启用异步张量并行（AsyncTP）后提高到 1,010 token/s/GPU。 $4$

图 6　TorchTitan 论文第 8 页表 3。Throughput 列按每张 GPU 折算，数值取自第 90 次训练迭代。 $4$

要算整项作业每秒消费多少个 token，把表中每卡平均吞吐 r r r 乘以总卡数。代入 AsyncTP 这一行的读数可得

R = 256 r = 256 × 1,010 = 258,560 t o k e n / s . R=256\,r=256\times1{,}010=258{,}560\;\mathrm{token/s}. R=256r=256×1,010=258,560token/s.

若训练数据已分词，每个 token ID 按 int32 保存，占 b = 4 b=4 b=4 字节，训练端消费这些 token 对应的有效输入带宽为

B t o k e n = R b = 258,560 × 4 = 1,034,240 b y t e / s ≈ 1.03 M B / s . B_{\mathrm{token}}=R\,b=258{,}560\times4=1{,}034{,}240\;\mathrm{byte/s}\approx1.03\;\mathrm{MB/s}. Btoken=Rb=258,560×4=1,034,240byte/s≈1.03MB/s.

基线配置同理， 256 × 897 = 229,632 256\times897=229{,}632 256×897=229,632 token/s，对应约 0.92 MB/s。MB 按十进制计。这两个带宽值由论文的训练吞吐换算得到，统计的是喂给模型的 token ID。

也可以用算力做个独立估算。按稠密模型前向与反向合计每 token 约 6 N 6N 6N FLOP，以 N ≈ 7 × 10 10 N\approx7\times10^{10} N≈7×1010 粗略代表非 embedding 参数量，忽略随上下文长度变化的部分计算。 $5$ 256 张标准 H100 SXM 采用 BF16 时，单卡稠密峰值取 989 TFLOP/s。 $6$ 若模型算力利用率（MFU）为 40%，则 int32 输入对应的带宽约为

B B F 16 ≈ 256 × 989 × 10 12 × 0.40 6 × 7 × 10 10 × 4 ≈ 0.965 M B / s . B_{\mathrm{BF16}}\approx\frac{256\times989\times10^{12}\times0.40}{6\times7\times10^{10}}\times4\approx0.965\;\mathrm{MB/s}. BBF16≈6×7×1010256×989×1012×0.40×4≈0.965MB/s.

分子对应整组卡约 101.3 PFLOP/s 的有效模型算力，除以每个 token 的计算量，得到约 24.1 万 token/s。40% 是此处的假设，TorchTitan 实验使用的是功耗上限较低的 H100，部分计算采用 Float8。 $4$

另一个量级参照是 Dell 在 2024 年公开的 Llama 2 训练测试。测试使用 Pile 的两个 shard，分词后约 40 GB，只运行 40 steps。7B 配置使用 1 台服务器、8 张 H100，70B 配置使用 6 台服务器、48 张 H100，报告的 Peak Read TP 分别为 827 KB/s 和 3.8 MB/s。 $7$

图 7：Dell 白皮书 Table 4，第 12 页原表。关注 Peak Read TP（峰值读取吞吐）列；右侧 Peak Write TP 包含 Checkpoint 写入，属于另一类 I/O。 $7$

Dell 记录的是文件存储上的峰值读取吞吐，上面的算例算的是训练端持续消费的 token 字节数。缓存命中、一次读入整个分片，以及多个读取请求集中到达，都会使这两个数字不同。 $7$

按表 3 较快的一行，256 张卡在 60 秒内会消费约 258,560 × 4 × 60 ≈ 62.1 M B 258{,}560\times4\times60\approx62.1\;\mathrm{MB} 258,560×4×60≈62.1MB 的 token ID。预取提前一分钟，就要在本地为这批输入留出相应空间。跨地域链路要实际搬多少，还取决于多少样本已在本地、一次缺失会读回多大的分片，以及多个作业是否同时回源。Checkpoint、模型权重和多模态样本应另外核算。小规模文本实验可以直接取训练日志里的整作业 token/s，乘以实际文件格式的字节/token，再按预取提前量算出要准备的数据量。

4.3 全局数据源与三级缓存

训练数据集写入后往往会被反复读取，适合将持久数据源与计算附近的缓存分开。Meta 借鉴操作系统的按需加载思路：进程访问磁盘文件时，数据会经过不同缓存层次被逐步装入；跨地域训练也可以使用相似的组织方式。

图 8：Meta 原文 Figure 4。GPU 主机内外的内存和闪存组成性能层，全局 HDD BLOB 数据湖保留最终数据源。 $1$

具体层次是：

层次	存储介质	放置位置
L1	内存	GPU 主机
L2	NVMe 闪存	GPU 主机
L3	Flash BLOB	GPU 所在地域
全局数据湖	HDD BLOB	全局存储层

L1 内存缓存还在不同 GPU 主机之间分布式共享，L2 使用本机 NVMe，L3 使用区域内分离部署的闪存 BLOB 存储。训练端继续调用熟悉的 BLOB SDK，数据由缓存层承接，未在本地域的数据再从远端装入。ReadPlan 元数据缓存则继续为数据定位服务。

这个结构保留全局数据湖的共享能力，又把实际消费的数据放到靠近计算的位置。地域间传输仍然存在，但它可以随访问按需发生，并提前与训练计算重叠。

4.4 训练框架暴露访问计划，存储提前预热

普通 DataLoader 预取负责下一批数据。GPU 计算当前 batch 时，DataLoader 将下一 batch 读入内存；在 BLOB SDK 看来，这表现为一次读取操作。它提供了较短的计算与 I/O 重叠窗口。

跨地域传输需要更长的提前量。Meta 在 SDK 中提供显式 prefetch() API，由 DataLoader 在后台通知存储接下来几分钟需要哪些数据。存储收到信号后，将远端数据装入 GPU 所在地域的 L3 闪存缓存，同时预热元数据缓存。等到 DataLoader 真正读取下一批时，再由普通预取将数据读入主机内存。 $1$

沿着这个接口思路，小规模实验的训练框架也可以暴露更远的访问计划：如果已经知道下一轮或后续几个 epoch 会消费哪些数据，就提前提交相应对象或数据范围，让存储异步预热到靠近 GPU 的缓存节点。这是可延伸的协作方式；Meta 原文明确描述的预取窗口是未来几分钟，目标层是区域 L3，并未规定提前加载几个 epoch。

预取窗口要覆盖远端传输时间，缓存容量也要容纳提前加载的工作集。目标是让 GPU 计算当前数据时，后续数据已经在准备，并在消费前就绪；如果带宽不足或访问计划变化，缓存未命中仍可能带来等待。同一份数据跨 epoch 复用时，保留已有缓存也可以减少再次搬运。

4.5 小规模实验按需加载，全量交付保留预拷贝

按需加载与预拷贝可以对应不同的任务目标。Meta 表示新模式上线后获得快速采用，同时在生产中继续支持两种范式。 $1$ 对这里讨论的小规模实验与最终全量交付，可以据此采用不同策略。

对于 toy 模型训练等短周期实验，先准备初始工作集即可启动，其余数据通过按需加载和后台预取陆续补齐。实验接受缓存未命中时偶发的性能回退，换取更快可用，避免每次修改都先等待整份数据集复制完成。

对于百 TB 级的最终全量数据交付，若后续训练持续时间长、集群停顿代价高，则可以沿用预拷贝加同步的策略：先把选定的数据快照完整交付到目标地域，确认同步完成、版本一致，再启动训练，以减少运行期间对跨地域传输的依赖。这里的同步指启动前的数据准备完成；百 TB 是本节讨论的场景量级，并非 Meta 划定的策略阈值。

按需加载还需要自动管理缓存。Meta 的 L3 区域闪存支持配置保留时间，以便在同一训练周期内跨 epoch 复用，并提供 TTL、LRU 等淘汰策略，同时感知容量和配额。 $1$ TTL 控制过期时间，LRU 按最近使用情况决定淘汰顺序；淘汰的是区域缓存，全局数据湖仍保留数据源。这样，实验之间的数据加载、复用与清理可以由缓存服务承担，研究者少做反复搬运和手动清理。

4.6 数据摄取时间与 GPU 运行路径

图 9：Meta 原文 Figure 5。对比的是 ingestion time，原文将其表述为全部工作负载的大致前后对照，百分比照录原图。 $1$

平均数据摄取时间从 150 分钟降到 10 分钟；P90 从 179 分钟降到 30 分钟，P99 从 61 小时降到 77 分钟，最大值从 89 小时降到 182 分钟。收益首先体现在训练前的数据准备，特别是原先需要等待数十小时的长尾。

按需加载让作业能够减少启动前必须完成的搬运，后续数据仍会在读取或预取时进入目标地域。因此，这组数字对应研究流程的等待时间，不能换算成训练总时长缩短了相同比例。

GPU 运行路径的结果则来自前述 BLOB 重构、热点缓存和客户端协议优化的共同作用。Meta 的结论是，新 BLOB 栈服务其 AI 工作负载时不再造成 GPU stall，在 Tectonic 之上只增加可忽略开销；去除数据代理也使功率开销保持在预算内。原文未给出改造前后的 GPU 利用率百分比、完整读延迟分布、训练吞吐或功耗对照，图 9 也未展开样本量和数据规模分布。 $1$

5 结束语

Meta 将后续工作列为三个方向：

将存储扩展到网络能力的极限。
在更大规模下支持不让 GPU 停顿的 Checkpoint。
处理推理工作负载带来的新挑战。 $1$

这也限定了本文讨论的范围：当前改造覆盖了 BLOB 访问路径、热点与拥塞，以及跨地域数据准备；更大规模的 Checkpoint 和推理仍在继续演进。

原文还没有展开缓存更新、失效与一致性协议，也未具体说明 BLOB 集群弹性和训推负载变化时的 I/O 复用。这些仍是方案落地时需要补充的设计内容。

6 参考资料

$1$ Meta's AI Storage Blueprint at Scale，Engineering at Meta，2026-07-01。

$2$ Owl: Distributing content at Meta scale，Engineering at Meta，2022-07-14。

$3$ Owl: Scale and Flexibility in Distribution of Hot Content，Jason Flinn 等，OSDI 2022。

$4$ TorchTitan: One-stop PyTorch native solution for production ready LLM pretraining，Wanchao Liang 等，ICLR 2025，§3.1---3.2、Table 3。

$5$ Scaling Laws for Neural Language Models，Jared Kaplan 等，2020，§2.1 与 Table 1。

$6$ NVIDIA H100 Tensor Core GPU Architecture，NVIDIA，v1.04，Table 1，第 20 页。

$7$ Scale AI Training and Fine-Tuning with Dell PowerScale and PowerEdge Servers，Darren Miller，Dell Technologies，2024-05，H20044，Table 4。