AI集群中的高速存储基础：数据集、检查点和KV Cache为什么会卡住GPU
一项预计要跑七天的训练，刚启动那会儿一切都很漂亮：多张GPU利用率高居不下，损失值稳稳地往下走。可几个小时后，监控曲线开始一波一波地往下坠——GPU冷不丁就闲下来，过一阵又缓过来，等到保存检查点的时候，更是直接停住老半天。
工程师先怀疑是训练代码的问题，翻了一遍没找到；又换上一批更快的GPU，现象却几乎原封不动。其实原因并不玄乎：GPU再快，也只能处理已经送到它眼前的数据。样本还没从磁盘读出来、CPU还没把预处理做完、模型权重还堵在加载的路上、检查点还没写完落盘——碰上任何一样，它都只能干等着。
存储在AI里干的活，说穿了就三件：源源不断地给计算供数、把模型和训练资产保存下来、以及在任务出故障之后还能让它接着跑。
这篇文章不打算讲某款存储产品具体怎么部署，而是想陪你顺着这项七天训练走一遍，让你知道"高速存储"这个栏目接下来要解决的，到底是哪几类问题。
数据进GPU之前，早就换了好几趟车
训练要用的原始文本、图片和视频，一开始通常都躺在对象存储、共享文件系统或者别的长期存储里。数据团队把它们清洗、切分、编码、转好格式之后，再整理成一份份适合并行读取的分片。模型权重也一样，要先从持久化存储里加载出来，经过CPU内存，最终才住进GPU显存。
任务一旦跑起来，数据加载进程就得不停地读这些分片，CPU在旁边负责解码、分词、数据增强和批次组装，把准备好的张量递给GPU。到了该保存的时刻，模型、优化器，还有继续训练所需的各种状态，又会被打包成检查点，沿着相反的方向写回存储。
顺着这条路看下来你就明白了：存储绝不是"计算开始前用一次就完事"的仓库。整个训练期间，它一边要不停地供数，一边还得周期性地接住成批的写入。存储读得慢，CPU就拿不到原料；CPU处理跟不上，GPU面前的队列照样是空的；主机到显存这段路要是堵了，磁盘再快也白搭。所以学AI存储，第一件事是建立起"完整数据通路"这个观念——真出了问题，别只盯着一块盘去测，而要顺着链条看清楚：数据到底是卡在了哪一站。
仓库装得下，不代表训练不会"断粮"
可以把训练集群想成一家中央厨房。仓库大到能囤下一整年的食材，那只说明容量够；可要是每天出库慢、每一小包还都得单独登记、又赶上好几个厨房同时来取货，厨师照样得排队等着。而厨房旁边那个取货飞快的小冷库呢，又装不下全部家当，也不适合用来存唯一的那份副本。
容量回答的是"能放多少"，可AI任务还会接着追问别的。连续读大分片、加载模型权重时，它更在乎吞吐量，也就是一秒到底能搬多少数据；样本要是由几百万个小文件拼成，系统就得频繁地开文件、查目录，这时候IOPS和元数据能力可能才是关键；而当某次操作必须尽快给出结果，延迟又会直接决定你要等多久。
这几个指标，对应的其实是不同的访问方式，并不是谁的数字最大谁就一定好。所以往后学的时候，不妨把容量、吞吐、IOPS、延迟和元数据，一个个放回具体任务里去掂量：模型加载、训练供数、小文件读取、检查点写入、在线缓存——它们给存储施加的压力，各不相同。
小文件和检查点，是两种最典型的AI存储难题
这项训练撞上的第一个瓶颈，来自小文件。"一个样本存一个文件"听起来清爽好管理，可规模一大，训练进程就得没完没了地查目录、开文件、读上一小段、再关掉。真正搬运的数据其实没多少，大把时间全耗在这些操作动作本身上了。常见的应对思路，是把零碎的小样本打包成较大的分片、再建好索引，同时把热点内容缓存到计算节点跟前。
第二个瓶颈，出在保存检查点的时候。平时数据是相对平稳地流向GPU的，可一到保存，许多rank可能会同时往外写模型权重、优化器状态和元数据，一下子堆出一个周期性的I/O洪峰。要是采用同步保存，训练进程还得眼巴巴等文件全部落盘才能继续，GPU也就跟着一起停摆。
所以检查点绝不能只看"多久存一次"。存得太勤，训练老被打断；间隔拉得太长，一旦故障，要重算的时间又太多。分片检查点、并行保存、异步保存、分层落盘，都是之后值得深入的方向。像PyTorch Distributed Checkpoint这类工具，解决的是"庞大的状态怎么分布式地读写"，可底层存储该扛的实际流量，一点也少不了。
这两个场景，恰好代表了AI存储的两种典型压力：小文件制造的是海量零散的操作，检查点制造的是短时间内的集中写入。把访问形态摸清楚，比单独背下一组硬件参数，要更贴近真实的问题。
本地NVMe、共享文件系统、对象存储，各管一段路
被读取和检查点这两个问题磨过一轮之后，团队就不再幻想找到一套"样样都最快"的存储了，而是改按数据的位置来分层。本地NVMe离计算节点最近，适合拿来缓存热点数据、临时文件和检查点缓冲；它快是快，可容量受单机限制，节点一旦挂掉，还没同步出去的内容也可能跟着一起没了。
共享或者并行文件系统，为多台训练节点提供一条统一的路径，适合放活跃数据和分布式检查点。它得直面多客户端并发、元数据热点、扩展和故障恢复这些挑战，是多节点训练里特别需要吃透的一层。
对象存储则擅长大容量、耐久保存和跨系统共享，很适合安置完整数据集、模型版本和历史检查点。只是它的访问接口跟传统文件系统不一样，大量小对象加上频繁的随机访问，未必适合直接闯进训练的热路径。
成熟的方案，往往让这三者搭着班干活：对象存储守着权威资产，共享高速层服务活跃训练，本地NVMe缓存眼下正用的数据。学存储分层的时候，记得一路追问下去：谁才是权威副本、缓存什么时候该失效、节点故障后允许丢掉哪些东西、检查点又该从哪里恢复。
GDS、KV Cache和3FS，是地图上再往下的几条岔路
等基础的数据路径摸清楚了，你会遇到一些更专门的概念。GPUDirect Storage，简称GDS，试图在条件兼容时，给存储和GPU显存之间搭一条更直接的DMA通道，省掉在CPU内存里中转那一道缓冲。它到底适合哪类数据、硬件拓扑支不支持、应用是不是非得先在CPU里处理一遍，都还得放到后面的专题里去判断。
等模型进了在线推理，KV Cache又把"存储层级"这件事，一路延伸到了GPU显存和主机内存。它存的是当前请求的中间状态，并不是什么长期文件——上下文越长、并发越高，它占的地方就越大；而当这份缓存被挪到CPU、别的GPU或者远端系统时，容量是撑大了，可网络和访问延迟也就一并挤进了请求路径。
DeepSeek开源的3FS，则代表了另一种思路：面向大规模AI负载的共享文件系统，用SSD配上RDMA网络把存储能力聚合起来，让计算和存储得以解耦。入门文章需要知道的，是它落在概念地图的哪一层，而不是就此得出"企业都该上3FS"的结论——规模、现有设施、兼容性和运维能力，最终才决定一套方案合不合适。
这三条岔路，分别把问题引向了直接数据路径、推理状态管理和大规模分布式文件系统。它们都该建立在你已经理解了数据生命周期、I/O形态和存储分层之后，再去碰才踏实。
这条高速存储学习路线，可以怎么走
后续学习，不妨顺着一份数据的生命周期，一层层往下走：
先把数据路径画清楚：搞明白数据集、模型权重、训练状态和推理缓存，分别从哪里来、又到哪里去。
再学I/O基本指标：把容量、吞吐、IOPS、延迟和元数据能力，一一放进具体的访问场景里。
接着理解数据组织与缓存：继续学小文件打包、分片、预取、本地缓存和数据预处理。
然后理解存储分层：认识本地NVMe、共享或并行文件系统、对象存储是怎么合力服务训练的。
再学检查点与恢复：进入分布式检查点、同步与异步保存、完整性校验和故障恢复。
最后进入专门方向：继续钻研GDS、KV Cache分层、RDMA文件系统和3FS这些AI存储专题。
把这条路线走完，等你再去比较存储方案时，关注点自然会从"容量有多大"，转向"数据能不能在对的时间，出现在对的层级上"。
接下来可以读什么
想先建立个全局认识，可以从算力资源总览和集群导读读起；真撞上跨节点读取和检查点拥堵，就接着学并行文件系统、对象存储和分布式检查点；如果你负责的是推理平台，那还得再往深里走一步，把KV Cache的容量估算、分层和跨节点传输弄明白。
站内关联阅读
参考资料
NVIDIA GPUDirect Storage Design Guide：https://docs.nvidia.com/gpudirect-storage/design-guide/index.html
PyTorch Distributed Checkpoint：https://docs.pytorch.org/docs/main/distributed.checkpoint.html
DeepSeek 3FS：https://github.com/deepseek-ai/3FS
NVIDIA, Tips on Scaling Storage for AI Training and Inferencing：https://developer.nvidia.com/blog/tips-on-scaling-storage-for-ai-training-and-inferencing/
Meta, Building Meta's GenAI Infrastructure：https://engineering.fb.com/2024/03/12/data-center-engineering/building-metas-genai-infrastructure/