训练时 GPU 利用率忽高忽低、每轮耗时偏长，不一定是算力不足，也可能是数据没有及时送到训练进程。排查深度学习训练数据读取瓶颈优化方案时，先别同时改存储、批大小和 worker 数量：逐环节测量，才能分清问题在磁盘、文件组织、解码还是传输。
一、先确认训练是否真的在等数据
观察训练日志中的每步耗时、数据加载耗时和 GPU 利用率变化。如果框架能分别记录取数与计算时间，先比较这两项；如果没有，可在短时间内观察 GPU 利用率和磁盘活动。GPU 利用率低并不能单独证明读取慢，模型计算量小、批次太小也会造成类似现象。
做对照时，固定模型、批大小和数据集，比较正常数据加载与重复使用内存中同一批数据的速度。若后者明显更快，瓶颈更可能在输入链路；若差距不明显，应转查计算、同步或训练配置。
二、按五个环节逐段定位
1. 存储设备与路径
确认数据位于本机 SSD、机械硬盘、网络文件系统还是对象存储挂载目录。连续大文件读取更容易体现吞吐能力；大量小文件则常受随机访问和元数据操作影响。Linux 上可用 iostat 等工具观察设备读速、等待时间和利用率，也要核对训练进程实际读取的挂载路径，避免数据意外落在较慢的盘上。
2. 文件组织与读取方式
数十万张图片逐个打开，可能产生大量文件系统请求。可以将样本整理成适合顺序读取的分片格式，例如 tar 分片，或使用数据框架支持的记录格式。分片过大不利于随机打散和并行读取，过小又会增加文件管理开销；应结合数据集大小、存储类型和训练时的打乱需求测试，而不是直接套用固定分片尺寸。
3. DataLoader 并行配置
以 PyTorch DataLoader 为例，逐步调整 num_workers，例如从 0、2、4 开始比较；这些只是试测起点，不是通用最优值。worker 太少可能无法并行取数，过多则会增加进程调度、内存占用和存储竞争。确认每个 worker 都能正常读取，再测试预取和常驻 worker 等设置；单机与网络存储的最佳配置可能不同。
4. 解码与预处理
检查图像解码、数据增强、文本分词等操作是否集中在训练主进程。可先测“只读取”与“读取加预处理”的耗时差异，再逐项启用裁剪、缩放或增强，找出最耗时步骤。固定尺寸数据可考虑离线完成部分确定性预处理；随机增强通常应保留在训练阶段，以免削弱样本变化。
5. 主机到加速设备的传输
若数据已经及时读入主机内存，但训练仍有等待，检查批次是否正确送往设备，以及数据拷贝是否与计算衔接。以 PyTorch 为例，可测试 pinned memory 与非阻塞传输等选项，并确认它们在当前硬件和数据管线上确实有效。小批次下，拷贝与调度开销可能更显眼；大批次则要同时留意主机内存和设备显存占用。
三、把测量结果变成优化动作
固定模型、批大小和样本顺序，记录每步耗时、磁盘读速及 GPU 活动，保留一组基线。
先绕过预处理，再尝试内存数据对照，判断时间主要花在存储还是计算。
若小文件或随机读取明显拖慢输入，测试分片读取；若单纯读取已很慢，优先检查存储介质、挂载路径和并发争用。
逐项调 worker 数量、预取及预处理设置，每次只改一个变量，并在相同训练条件下复测。
记录吞吐、单步耗时和内存占用，保留整体表现更稳的配置；不要只凭某一瞬间的 GPU 利用率作结论。
有效的深度学习训练数据读取瓶颈优化方案，核心是用对照实验找到最慢的一段，再针对性调整。存储读速低就检查介质与文件布局，CPU 解码占时就优化预处理并行，传输等待明显再处理设备拷贝；每次改动都复测，避免把一个瓶颈换成另一个瓶颈。
常见问题
增加 worker 一定能加快训练吗？
不一定。worker 增多会增加并行度，也会增加 CPU、内存和存储压力，应逐档测试并观察整体吞吐。
GPU 利用率低就说明数据读取慢吗？
不能。模型计算量、批大小及同步等待都可能导致利用率偏低，需要结合取数耗时和存储活动判断。
把数据复制到本地 SSD 是否有效？
当网络存储访问是主要瓶颈时可能有效；若瓶颈在解码或预处理，复制数据未必改善训练速度。
