过去几年，模型能力和训练数据规模都在快速膨胀。更明显的变化是，新一代前沿模型发布间隔从几个月压缩到几周。这个节奏背后不只是 GPU 数量的问题，存储也会直接决定训练吞吐、作业等待时间和算力浪费。对 AI 基础设施来说，存储已经从“放数据的地方”变成了训练流水线的一部分。
存储为什么会影响模型迭代速度
大模型训练不是一次性把数据读进内存就结束。训练集、检查点、日志、特征缓存、评估数据、恢复数据都在不断读写。任何一个环节抖动，都会放大成 GPU 空转、作业重启时间变长，或者数据准备跟不上训练。
在前沿模型发布周期缩短的环境里，存储系统要解决的不只是容量问题：
- 训练数据集指数级增长，要求存储能横向扩展。
- 训练作业对吞吐和尾延迟敏感，慢盘或热点会拖住整组计算节点。
- checkpoint 写入必须可靠，否则一次失败可能损失大量训练时间。
- 数据访问路径越长，计算成本越容易被隐藏的 I/O 等待吞掉。
所以，“可靠且快速访问存储”不是基础设施团队的局部优化，而是模型研发节奏的一项核心约束。
AI 存储蓝图里的关键判断
从摘要能看到，Meta 关注的是 scale 下的 AI storage blueprint。这里的关键词不是单一存储产品，而是“蓝图”：如何让存储服务模型训练、数据增长和更快的发布周期。
一个实用的 AI 存储架构通常需要同时处理三类负载：
- 大规模顺序读取：训练数据被大量 worker 并行读取，吞吐比单次请求延迟更重要。
- 高频 checkpoint 写入：训练过程中周期性落盘，写入失败或过慢都会影响恢复能力。
- 元数据和小文件压力：数据集如果由大量小对象组成，目录遍历、文件打开和元数据查询会变成瓶颈。
这也是很多 AI 平台最终会把“数据布局”和“训练调度”一起看待的原因。存储不是独立系统，它和数据预处理、缓存、集群网络、作业编排、故障恢复策略绑在一起。
可以这样实践：先量化训练节点看到的 I/O
如果你要评估自己的训练集群，不要只看存储厂商给出的峰值吞吐。更有用的是在训练节点上模拟真实读写模式：并发 worker 读数据、周期性写 checkpoint、观察吞吐和尾延迟。
下面示例使用 fio 做一个可改造的基准测试。运行前把 TEST_DIR 改成你的训练数据挂载目录，例如 /mnt/datasets、/data 或某个共享文件系统路径。
#!/usr/bin/env bash
set -euo pipefail
TEST_DIR="/mnt/ai-storage-test"
mkdir -p "$TEST_DIR"
fio --name=ai-training-read \
--directory="$TEST_DIR" \
--rw=read \
--bs=4M \
--size=8G \
--numjobs=8 \
--iodepth=16 \
--direct=1 \
--time_based \
--runtime=60 \
--group_reporting
fio --name=ai-checkpoint-write \
--directory="$TEST_DIR" \
--rw=write \
--bs=16M \
--size=16G \
--numjobs=4 \
--iodepth=8 \
--direct=1 \
--time_based \
--runtime=60 \
--group_reporting
你可以重点看三组指标：
READ/WRITE bw：训练 worker 能拿到的实际吞吐。lat percentiles：尾延迟是否突然升高。- 多节点同时执行时的吞吐下降：这比单节点成绩更接近训练现实。
如果你在 Kubernetes 上跑训练任务，也可以把这个测试包装成一个临时 Job。下面是一个最小示例，假设你已有名为 ai-dataset-pvc 的 PVC，并且集群镜像仓库能拉取包含 fio 的镜像。
apiVersion: batch/v1
kind: Job
metadata:
name: ai-storage-fio
spec:
template:
spec:
restartPolicy: Never
containers:
- name: fio
image: nixery.dev/shell/fio/coreutils
command: ["/bin/sh", "-c"]
args:
- |
set -e
mkdir -p /data/fio-test
fio --name=training-read \
--directory=/data/fio-test \
--rw=read \
--bs=4M \
--size=4G \
--numjobs=4 \
--iodepth=16 \
--direct=1 \
--time_based \
--runtime=45 \
--group_reporting
volumeMounts:
- name: dataset
mountPath: /data
volumes:
- name: dataset
persistentVolumeClaim:
claimName: ai-dataset-pvc
运行命令：
kubectl apply -f ai-storage-fio.yaml
kubectl logs -f job/ai-storage-fio
kubectl delete job ai-storage-fio
这个例子不能替代真实训练压测，但能帮助你快速发现：PVC 后端是否有明显吞吐上限、共享文件系统是否在并发下抖动、checkpoint 目录是否和训练数据读取互相干扰。
设计存储时别只盯着“更快”
AI 存储的目标不是把每一层都堆到最高规格，而是让数据流和训练节奏匹配。可以用下面几条检查自己的平台：
- 训练数据是否按大块文件或 shard 组织，避免海量小文件拖垮元数据路径。
- checkpoint 是否有独立路径、配额和生命周期策略。
- 热数据是否靠近计算节点，冷数据是否进入更便宜的层级。
- 训练失败后恢复时间是否被纳入 SLO，而不仅是训练时吞吐。
- 存储监控是否能按作业、数据集、租户拆分，而不是只有集群总量。
边界也很清楚：存储优化不能弥补混乱的数据管线。如果数据预处理重复运行、样本格式频繁变化、训练作业没有稳定的读写模式，再强的存储也只能被动承压。
落地建议
对大多数团队来说，不必一开始就复制超大规模公司的完整蓝图。更现实的路线是：先测量训练节点看到的真实 I/O，再把数据布局、checkpoint 策略和缓存层逐步固定下来。
当模型迭代从“月级”变成“周级”，存储系统的价值会从后台成本项变成研发速度的一部分。GPU 很贵，但让 GPU 等数据更贵。一个好的 AI 存储蓝图，核心不是某个神奇组件，而是让数据在正确的时间、以稳定的速度、可靠地到达训练任务。