AI 集群中的存储性能为什么会直接影响 GPU 利用率，训练数据加载过程详细解析

一块高端GPU每秒可以完成海量计算，但如果数据不能及时送到它面前，再强大的GPU也只能等。

这正是AI训练集群中一个很容易被忽视的问题。很多人看到一台服务器安装了多块高端GPU，就认为训练速度主要取决于GPU数量和算力。实际运行大型模型时，GPU利用率还受到数据读取、数据预处理、CPU、内存、网络、存储以及GPU之间通信等多个环节影响。其中，存储系统一旦成为瓶颈，就可能让昂贵的GPU处于“吃不饱”的状态。

理解这个问题，首先要弄清楚训练数据到底是怎样进入GPU的。

一批训练数据通常不会从SSD直接跳进GPU显存。典型的数据路径是：训练数据位于本地NVMe SSD或者共享存储系统中，操作系统和数据加载程序将数据读取到主机内存，随后经过解码、解析、随机裁剪、归一化、tokenization等预处理，再通过PCIe等高速互连传输到GPU显存。训练框架通常还会提前准备下一批数据，让数据传输与GPU计算尽可能重叠。

因此，GPU训练实际上是一条流水线。

GPU正在计算第N批数据的时候，CPU和数据加载线程可以准备第N+1批数据，存储系统则继续读取后续数据。理想状态下，当GPU完成当前计算时，下一批数据已经准备好，可以立即开始新的计算。

问题出在任何一个环节跟不上。

如果SSD读取速度不足，CPU拿不到足够的数据；如果CPU解码速度不足，数据虽然已经从SSD读取出来，却还没有完成预处理；如果主机内存带宽或者PCIe传输成为瓶颈，数据无法及时进入GPU；如果GPU之间需要大量通信，计算本身也可能被通信操作打断。

所以，“存储性能影响GPU利用率”是正确的，但不能简单理解成“SSD越快，GPU利用率就越高”。

存储首先影响的是数据供给能力。

假设一个训练任务需要持续读取大量图像、视频、文本或者其他训练样本。如果数据集放在机械硬盘上，随机访问能力通常比较弱。当多个CPU线程同时请求数据时，磁盘寻址和I/O等待可能迅速增加。换成NVMe SSD以后，延迟和并发I/O能力通常会大幅改善，尤其适合大量并行数据读取。

但现代AI训练面对的存储问题已经不仅仅是“HDD还是SSD”。

在单台服务器中，可以使用多块NVMe SSD组成高速本地数据盘。到了大型AI集群，训练数据往往存放在分布式存储系统中。数十、数百甚至更多计算节点同时读取数据时，真正的瓶颈可能从单块SSD转移到整个存储网络。

例如，一台服务器拥有8块GPU，如果每块GPU都需要持续读取数据，那么几十台服务器同时训练时，整个集群可能产生巨大的读取流量。此时即使每台服务器本地的NVMe性能很高，共享存储系统、网络交换机、存储服务器或者元数据服务也可能成为瓶颈。

这也是分布式AI存储与普通企业文件存储最大的区别之一。

普通办公文件系统主要面对的是文档、图片和业务文件访问，而AI训练更加关注大规模并发读取、带宽、延迟、I/O队列深度以及数据访问模式。训练任务可能同时让大量计算节点读取同一个大型数据集，因此存储系统需要能够承受高度并行的访问压力。

数据布局也会产生明显影响。

如果训练数据被切割成大量非常小的文件，读取这些文件时不仅需要传输数据，还会产生大量文件打开、关闭、元数据查询等操作。当数千个训练进程同时进行这种操作时，元数据系统可能先达到瓶颈。

因此，AI训练环境经常需要针对数据集进行重新组织。例如把大量小文件打包成较大的数据文件，并采用适合顺序读取和并行读取的数据格式，从而减少元数据操作和随机I/O。

不过，文件越大也并不意味着性能一定越好。关键在于数据布局是否适合训练任务的访问模式，以及能否让多个计算节点并行读取，而不是让大量请求集中到某一个存储节点。

另一个经常被忽视的问题是数据预处理。

训练图片通常不能直接拿来计算。图像可能需要解码、调整尺寸、裁剪和归一化；文本模型则可能需要读取文本、切分token并进行编码。视频训练的预处理更加复杂。

因此，即使NVMe SSD能够提供非常高的读取带宽，如果CPU处理不过来，GPU仍然可能等待。

这也是为什么很多AI训练系统使用多进程或多线程DataLoader，并配合预取机制、内存缓存以及pinned memory。它们的共同目的不是让GPU“读取SSD”，而是提前把未来需要的数据准备好，让GPU计算和数据准备同时进行。

在深度学习框架中，这种设计尤其重要。

以PyTorch为例，DataLoader可以使用多个worker并行读取和处理数据，还可以通过prefetch等机制提前准备后续批次。在合适的配置下，GPU计算当前batch的同时，CPU已经在准备下一个batch。

如果数据加载速度低于GPU消耗数据的速度，就会出现一种非常典型的现象：GPU计算一段时间，然后突然出现空闲，再继续计算，再空闲。

监控软件可能显示GPU利用率从90%以上掉到很低，然后再次升高。

这时候，直接购买更多GPU往往不是最有效的解决方案。因为问题不是GPU数量不够，而是数据供应不上。

AI集群中还有一种情况更加复杂：不同GPU可能出现不同程度的等待。

例如一台服务器拥有8块GPU，其中某些GPU已经拿到了下一批数据，而另外几个GPU还在等待。如果训练采用同步的数据并行方式，整个训练步骤可能需要等待所有参与计算的GPU完成相应工作。

于是，某一块GPU的I/O延迟甚至可能影响整个训练节点的同步节奏。

到了更大规模的集群，这种问题还可能通过网络进一步放大。数据并行训练不仅需要读取训练数据，还需要进行梯度同步；模型并行和流水线并行则会产生不同类型的GPU间通信。此时存储、CPU、网络和GPU通信之间存在复杂的相互影响。

这也是为什么不能把“GPU利用率低”直接等同于“存储太慢”。

GPU利用率低可能来自数据加载，也可能来自CPU预处理不足、GPU内核效率低、模型计算本身存在大量等待、GPU之间通信过多、内存访问效率低，甚至可能是训练参数配置不合理。

真正的工程优化，需要先找到GPU到底在等待什么。

因此，AI集群性能分析通常需要同时观察GPU利用率、GPU显存使用情况、CPU利用率、系统内存、PCIe吞吐量、网络流量以及存储I/O。只有把这些指标放在一起，才能判断瓶颈究竟发生在哪里。

存储测试也不能只看厂商宣传的“每秒多少GB”。

连续大文件读取、随机小文件读取、多线程并发读取和大量计算节点同时访问时，得到的结果可能完全不同。一个SSD在单线程顺序读取测试中表现非常优秀，并不意味着几十台训练服务器同时访问共享存储时仍然能够保持同样的性能。

因此，AI存储系统真正需要关注的是整个数据路径，而不是某一个硬件参数。

在本地存储环境中，可以通过增加NVMe设备、优化数据布局、合理使用缓存和并行读取来提高数据供应能力。在共享存储环境中，则需要进一步考虑存储节点数量、网络带宽、数据分布以及并发访问能力。

如果训练数据允许，还可以采用分层存储。常用数据放在高速本地NVMe，不常用的数据保留在容量更大的共享存储中。训练开始前，将即将使用的数据预热到本地缓存，也可以减少训练过程中的远程I/O等待。

另一种思路是减少“每次训练都从头读取原始数据”的开销。

经过预处理的数据可以提前转换成更加适合训练的数据格式，减少训练过程中重复执行昂贵的解码和预处理操作。对于经常重复使用的数据集，缓存策略尤其重要。

最终要解决的问题，其实不是“买更快的SSD”，而是让整个训练流水线保持平衡。

GPU需要计算数据，CPU负责准备数据，存储系统负责提供数据，网络负责传输数据，而软件框架负责把这些工作组织起来。如果其中任何一个环节明显落后于其他环节，整个系统就会出现等待。

这也是AI基础设施与普通服务器最大的区别之一。对于传统业务系统来说，一次磁盘访问慢几毫秒可能只是一个局部问题；对于拥有数百甚至数千块GPU的训练集群来说，如果每块GPU都在等待数据，那么浪费的可能是大量昂贵的计算资源。

所以，评价AI集群不能只看GPU数量，也不能只看GPU峰值算力。真正决定训练效率的，是从数据存储到GPU计算之间的整条链路能否稳定地把数据送到计算单元。

当GPU利用率长期偏低时，与其马上增加GPU，不如先问一个更基本的问题：GPU到底是在计算，还是在等数据。

这个问题看似简单，却往往决定了一套AI基础设施究竟是在高效运行，还是让昂贵的计算资源长期处于等待状态。