集群里增加加速卡后，训练速度却没有明显变化，甚至单卡也时常空闲，先别急着采购。加速卡利用率低的排查与优化，应从数据能否稳定、连续地送达计算任务开始：看等待发生在哪里，再决定是否需要增加计算资源。
先分清“卡闲着”发生在哪一段
利用率指标需要结合任务阶段理解。模型初始化、验证、保存检查点或等待任务启动时，利用率短暂下降并不一定异常；如果训练主体期间反复出现空档，则应继续查输入流水线、存储吞吐和任务调度。不同厂商的监控工具名称不同，可先查看设备利用率、显存占用、功耗或活动状态，并与数据读取速率、训练步耗时对齐。
- 选一段有代表性的训练，记录约15至30分钟的指标；避开刚启动和保存检查点的阶段。
- 观察设备是否连续工作，还是每隔一段时间出现空闲；同时记录每步耗时是否周期性拉长。
- 对照数据读取量、数据准备耗时、存储延迟和任务排队情况。只看平均利用率，容易漏掉短时停顿。
这些观察不要求先设一个适用于所有集群的“合格百分比”。模型结构、批次大小、数据分辨率和监控采样间隔都会影响读数，重点是找出计算停顿是否与数据或调度事件同步。
沿着数据路径逐段排查
存储端：测实际读取，不只看标称速度
检查训练数据所在位置、并发读取方式及文件大小。共享文件系统或对象存储便于多节点访问，但高并发小文件读取可能产生元数据开销和延迟；节点本地 NVMe SSD 读取通常更直接，却要处理数据分发、容量和节点间一致性。可在不运行训练的情况下，用同一批样本测连续读取与随机读取，并比较单进程、多个读取进程下的吞吐和延迟。测试应尽量贴近训练时的文件大小、并发数及网络路径。
解码端：区分读得慢与处理得慢
图像解码、音频变换、数据增强、解压缩和格式转换都可能占用主机侧处理时间。记录取样、解码及增强各自耗时；若文件已读到但样本仍迟迟未就绪，单纯换更快的存储不一定有效。先减少重复解码，或把确定可复用的预处理结果按合适格式保存；若改用预处理数据，也要权衡磁盘空间、数据更新频率和精度要求。
队列端：确认生产者跟得上消费者
输入队列经常见底，说明数据生产速度低于训练消耗速度；队列长期积压，则瓶颈可能在计算或队列配置。逐步增加数据读取工作进程并观察吞吐，不要一次开到最大：进程过多会争抢内存、文件句柄和存储带宽，反而让延迟变差。多节点任务还要核对每个节点是否拿到正确的数据分片，避免重复读取或部分节点缺数。
做小步对照，再决定扩卡
- 固定模型、批次和数据顺序，建立当前吞吐与每步耗时基线。
- 每次只改一个环节，例如读取进程数、数据缓存位置或预处理方式，重复相同时间段测试。
- 记录训练吞吐、设备空闲间隙、数据读取延迟和节点间差异；确认改善不是缓存预热或任务阶段变化造成的。
- 在单节点数据供给稳定后，再逐步增加节点，观察总吞吐是否随卡数增长。若新增设备后每卡吞吐明显下降，应回头检查共享存储带宽、网络和分片策略。
加速卡利用率低的排查与优化，最终要回答的是“计算资源在等什么”。如果供数稳定、输入处理不再成为限制，而任务仍受计算量约束，扩卡才更可能带来收益；若共享存储已饱和，扩卡只会增加争用。
常见问题
设备利用率低，是否一定是数据读取问题？
不是。任务同步、节点间负载不均、检查点保存和计算本身的等待都可能造成空闲，应结合数据速率与各节点指标判断。
先缓存到本地盘还是增加读取进程？
若共享存储延迟高且数据集能容纳在本地盘，可测试缓存；若读取链路正常但数据准备较慢，可逐步增加进程。两者都要通过同一训练负载对照。
什么时候可以考虑扩卡？
当数据供给稳定、节点负载大致均衡，且增加节点的测试仍能提升总训练吞吐时，再评估扩容，同时核算网络、存储和调度能力。
