加速卡利用率低的排查与优化，第一步不是立刻增加卡数，而是确认计算任务是否持续拿得到数据、是否被 CPU 或同步操作卡住。利用率读数只是采样时刻的忙碌程度；短任务、间歇性工作负载也可能让平均值显得很低。应同时观察任务耗时、吞吐量和等待原因。
先确认低利用率是真问题
固定一段稳定运行的任务，记录每轮处理时间、每秒完成量、加速卡利用率及显存占用。Linux 环境可用 nvidia-smi dmon 查看 NVIDIA 设备的周期性状态；AMD 设备可查看 rocm-smi 提供的监控信息。采样间隔过长会漏掉短暂的计算峰值，因此要结合任务日志，而不要只看单个瞬时数字。
若任务很快完成、总体吞吐满足需求，低平均利用率未必需要优化。若处理时间长且设备频繁空闲，才继续查瓶颈。加速卡利用率低的排查与优化应以可重复的同一负载为基准，避免把输入规模变化误判成性能改善。
沿着数据进入设备的路径检查
数据加载与 CPU 等待
查看数据加载耗时是否占每轮总时间的大头。用系统监控工具观察 CPU 是否长期繁忙，再用 iostat 检查存储读写是否繁忙、等待是否明显。若读取或解码跟不上，设备会在计算间隙空闲；网络文件系统波动、许多小文件和复杂预处理都可能造成这种现象。
- 先把数据读取、解码、预处理和设备计算的耗时分开记录，确认等待发生在哪一段。
- 临时使用内存中的小批数据重复计算。若利用率明显上升，优先优化数据加载，而不是改模型计算。
- 逐步调整数据加载进程数，每次只改一个变量；同时观察 CPU 争用和每秒处理量。进程并非越多越好，过量会增加调度与内存开销。
- 数据格式允许时，可采用批量读取、缓存常用数据或减少重复解码。缓存要考虑内存容量，并确认不会让数据版本失效。
检查同步与计算粒度
若数据已准备好但设备仍有空档，检查程序是否频繁等待计算结果、逐条提交很小的任务，或在每轮之间执行不必要的同步。PyTorch Profiler 可帮助查看算子时间线和等待区段；Intel VTune Profiler 可用于分析 CPU 侧线程活动。不同框架和设备的指标名称不同，应重点看时间线上的空隙及调用关系。
优化时分清吞吐与延迟
适当增大批处理规模，可能减少提交开销、提升吞吐，但会增加内存需求，也可能让单次响应变慢。在线交互更看重延迟，离线批量处理通常更看重吞吐，不能只追求利用率数字。数据加载、CPU等待和设备计算应分别验证：每次只调整一项，保留原始结果作对照。
若设备利用率较高但任务仍慢，瓶颈可能已转向内存带宽、设备间通信或算法本身；继续堆数据加载进程通常无效。加速卡利用率低的排查与优化，最终目标是缩短实际任务时间或提高有效吞吐，而不是把监控读数推到某个固定比例。
常见问题
利用率多少才算偏低？
没有适用于所有任务的统一阈值。结合任务耗时、吞吐量和时间线判断；短任务的采样均值尤其容易失真。
先增加数据加载进程数可以吗？
先确认数据加载确实是瓶颈，再小步增加并观察 CPU、存储和吞吐变化。若 CPU 已经拥挤，增加进程可能更慢。
利用率低但结果按时完成，需要优化吗？
若成本、时限和资源占用都可接受，不一定需要。优先解决影响实际交付的延迟或吞吐问题。
排查后利用率仍低怎么办？
检查任务是否过小、同步是否过频，并用性能分析时间线定位空档；若计算本身很轻，低利用率可能是正常表现。
