AI 存储的三层策略：数据集、checkpoint 与热数据

为什么 AI 存储是独立问题：三种负载三种脾气

AI 集群的存储负载与传统业务截然不同，三种负载三种脾气。负载一：训练数据集——海量顺序读（数千 worker 同时读万亿 token 的数据集——吞吐的量级是 TB/s 级的聚合需求）、随机性来自分片（数据分片后各 worker 读不同部分）。负载二：checkpoint——周期性的大文件写（每几十分钟写一次数百 GB 的模型状态——本库断点续训篇）+ 偶发的读（恢复时读回）。负载三：推理的热数据——模型权重的加载（启动时大文件顺序读）+ 运行时的小文件随机读（token 分词表等）。三种负载的「读写比例、大小、并发模式、延迟要求」完全不同——一个存储系统打天下必然有短板，分层架构是正解。

三层架构：并行文件系统、高速缓存与对象存储

层一：高性能并行文件系统（数据集与 checkpoint 的主存）。选型：Lustre/GPFS（IBM Spectrum Scale）/JuiceFS 类——并行文件系统的特征：多客户端的高聚合带宽（数千客户端并发读的扩展）、POSIX 语义（训练代码直接读）。数据集层的要点：读吞吐的聚合（训练的几千 worker 同时读——聚合吞吐要匹配 GPU 的消费速度：「存储跟不上，GPU 在等数据」是训练的最大浪费，本库 RDMA 篇的 GPUDirect Storage 的关联）、数据集的分片友好（按文件分片的天然并行）。checkpoint 层的要点：写突发的处理（几百个任务同时写 checkpoint 的风暴——错峰与带宽预留）、写的可靠性（checkpoint 是「保险」——保险存储本身不能不可靠：多副本与校验）。层二：节点本地缓存（热数据与加速层）。本地 NVMe 作为缓存层：数据集的热点分片缓存到节点本地盘（训练的第一次全量读走共享存储、之后走本地缓存）、权重与模型的本地化（本库模型分发篇的节点缓存）。缓存的管理：缓存的命中率监控、容量与淘汰策略、一致性（数据更新后的缓存失效）。层三：对象存储（海量数据的持久层）。原始数据集与归档的仓库：对象存储（S3/OSS）存原始语料、数据集从对象存储「装载」到并行文件系统（训练前的数据准备阶段）——对象存储的廉价与无限容量做「仓」，并行文件系统做「货架」。

文件系统的选型与「存储成为瓶颈」的排查

选型的决策变量：规模（数据集的 TB/PB 级）、并发客户端数（训练 worker 的数量）、吞吐需求（GPU 消费速度的反推）、预算（并行文件系统的成本不菲）。主流方案的画像：Lustre（HPC 的传统王者——超大规模验证过）、GPFS/Spectrum Scale（IBM 的企业级）、JuiceFS（云原生的分布式文件系统——对象存储为底座、元数据引擎独立——国内 AI 团队的主流选择之一）、以及云厂商的托管方案（FSx for Lustre/GCP Filestore）。「存储成为瓶颈」的排查。症状一：GPU 利用率低且波动（GPU 等数据——数据加载是瓶颈的信号：nvidia-smi 的利用率锯齿状）；排查：数据加载的吞吐测量（dataloader 的速度 vs GPU 消费速度——dataloader 的 worker 数与 prefetch 也要先排除）、存储端的压力观测（聚合带宽是否打满）。症状二：checkpoint 写入慢（写 checkpoint 的时间过长——写带宽的瓶颈或写风暴：错峰与分层写入）。症状三：数据准备的时间过长（训练前的数据准备阶段耗时——装载与预处理管线的效率）。排查的工具：fio（存储的基准测试）、iostat（存储设备的实时压力）、以及训练框架的数据加载指标（dataloader 的耗时统计）。

AI 存储的进阶：数据集管线的工程化

AI 存储（正文三层）的进阶：数据集管线的工程化——数据从采集到训练的全管线工程。管线的阶段。采集与清洗（本库数据管线篇——存储视角：原始数据的入库与暂存）、预处理与分片（tokenize、分块、分片——预处理产物的存储形态：分片文件的组织）、装载与缓存（训练时的数据供给——本库正文的三层架构）、版本与复用（数据集的版本管理——本库数据版本篇的存储面）。管线的工程要点。预处理的算力（tokenize 是 CPU 密集——预处理集群的算力规划：数据管线的算力也是算力）、分片的设计（分片的大小与 worker 的匹配——分片太大 worker 不均、太小元数据开销大）、装载的吞吐（本库正文的三层：对象存储 → 并行文件系统 → 节点缓存的三段装载）、以及数据集的版本与血缘（哪个训练用了哪个版本的数据集——数据集的血缘追踪：复现与合规的需求）。数据管线的收束：训练数据的存储不是「找个盘放数据」，是一条「采集-清洗-分片-装载-版本化」的工程管线——管线与 GPU 集群的对接效率，决定了「数据墙」（本库数据墙篇）是不是你的真实瓶颈。

存储的选型案例：不同规模集群的存储方案

AI 存储（正文选型）的案例：不同规模集群的存储方案——从小到大的三个实例。实例一：单节点/小团队（8 卡以内）。需求：数据集几百 GB、单机训练、无并发。方案：本地 NVMe 直存（数据集放本地盘——最简单最快）、备份到对象存储——本地盘就是最优解（没有共享的复杂度）。实例二：单集群多节点（数十卡）。需求：多节点训练、数据集 TB 级、多个并发任务。方案：JuiceFS/NFS + 对象存储（并行读的共享层 + 对象存储的仓）、节点本地缓存加速（本库正文的缓存层）、JuiceFS 的元数据引擎选型（Redis/Postgres——元数据的性能是 JuiceFS 的关键）。实例三：大规模集群（数百卡+）。需求：PB 级数据集、数千 worker 并发、checkpoint 风暴。方案：Lustre/GPFS 的并行文件系统（HPC 级的聚合吞吐）+ 对象存储的原始仓 + 分层与生命周期管理（数据的冷热分层——本库正文的三层架构的完整形态）。三个实例的共性原则：数据的「热温冷」分层、吞吐与 GPU 消费速度的匹配、checkpoint 的可靠性优先——三个原则在任何规模都成立，变的只是实现的规模。选型案例的收束：存储的选型没有最好只有匹配——按规模选实现、按负载配参数、按版本管数据——存储是训练的「物流系统」，物流通了，GPU 才吃得饱。

AI 存储的进阶案例：checkpoint 写入风暴的治理

AI 存储（正文 checkpoint）的进阶案例：checkpoint 写入风暴的治理——数百任务同时写 checkpoint 的工程。场景：200 个训练任务同时运行，每小时整点同时写 checkpoint——200 个 × 500GB = 100TB 的写风暴——存储带宽被打满。风暴的影响：存储带宽饱和 → 写入时间从 2 分钟拉长到 15 分钟 → 训练任务的等待时间翻倍 → 全集群的训练吞吐下降。治理的四招。招一：错峰——任务的 checkpoint 时间错开（每个任务的 checkpoint 时间偏移——按任务 ID 哈希分配偏移量——200 个任务的写入从「同一时刻」变成「分散在 1 小时内」）。招二：分级——不同任务不同的 checkpoint 频率（重要任务高频、普通任务低频——频率按重要性分配）。招三：分层写入——先写本地 NVMe、异步同步到共享存储（本地写入快、异步同步慢但不阻塞训练——本库正文的本地缓存层）。招四：带宽的预留——checkpoint 的带宽预留（存储的 QoS 为 checkpoint 流量保留带宽——带宽的预留要从训练数据的读带宽中扣除）。风暴治理的收束：checkpoint 风暴是「好习惯（频繁保存）引发的新问题」——它证明了「每解决一个问题就创造一个新问题」的工程定律；治理的方案不复杂，难的是「提前想到」——存储的容量规划要包含 checkpoint 风暴的峰值带宽。**

AI 存储的选型案例：JuiceFS 的部署与调优

AI 存储（正文选型）的案例：JuiceFS 的部署与调优——国内 AI 团队的主流存储方案。JuiceFS 的架构：元数据引擎（Redis/Postgres）+ 对象存储（S3/OSS）的分层——元数据管文件结构、数据存对象存储——「POSIX 文件系统的体验 + 对象存储的成本」的组合。部署的要点。元数据引擎的选择（Redis 性能最好但内存有限、Postgres 可靠性最好——元数据的量级决定引擎的选择：千万文件的元数据需要数据库引擎）、数据存储的选择（S3/OSS/MinIO——对象存储的选择按成本与性能）。调优的要点。缓存的大小（客户端缓存的大小——缓存越大读性能越好：本地 NVMe 作为缓存层）、块大小（数据块的大小影响读写效率——顺序读用大块、随机读用小块）、并发度（多客户端并发读的聚合带宽——千级客户端的聚合是训练数据供给的量级）。JuiceFS 的收束：JuiceFS 用「对象存储的容量 + 并行文件系统的性能」的组合，成为国内 AI 存储的性价比之王——它的部署简单（Docker 起元数据引擎 + 对象存储即用）与运维友好（无专用硬件），是中小团队的最佳选择。)

小结

AI 存储的三层策略：并行文件系统（Lustre/GPFS/JuiceFS）承载训练数据集与 checkpoint 的主存、节点本地 NVMe 缓存热数据与权重、对象存储做海量原始数据的持久仓。三层各司其职的前提是认识三种负载的不同脾气（顺序吞吐、突发写、随机读）。存储成为训练瓶颈的信号是 GPU 利用率的锯齿状波动——存储跟不上，GPU 在等数据，是集群里最贵的一种浪费。