在寻找更强大的 GPU 之前，先说明清楚预期。

用结果和时间窗口描述问题

把「GPU 没有在工作」换成可验证的观察：首个结果来得晚、各阶段出现停顿，或可接受的输出数量减少。请给出输入数据集、应用版本、各项设置以及观察时段。首次启动可能包含与已准备好的运行不同的阶段；若未加以说明，不要将它们混为一谈。

把整个流程拆分为文件打开、CPU 预处理、传输、GPU 计算、写入和校验。这些阶段可能相互重叠：所画的图只是一种假设，需要与追踪记录相互印证。请用同一时区和足够的精度记录各阶段的边界。在停顿之后采集的硬件图表无法解释该停顿，即使其数值看起来异常。

正确理解百分比和内存指标

在 NVIDIA SMI 中，GPU 利用率表示在采样区间内至少有一个内核在执行的时间占比。它并不是对全部组件性能的评分。内存利用率描述的是其读写活动，不应与占用的内存容量相混淆。文档还指出，某些字段可能因环境不同而不可用。

因此，请保留指标的准确名称及其单位。较高的内存用量可能对应着等待处理而保留的数据；在正常的预处理阶段也可能出现较低的活动。反过来，高活动量也不能证明程序在做有用的工作。必须把输出和应用进度与硬件指标放在一起看。

采集相关且足够简短的报告

选择一段具有代表性的序列，并将采集限定在该序列内。记录时间、GPU 标识符、活动、已占用显存以及应用的各个阶段。同时，使用系统上可用的工具观察 CPU 进程、其等待情况及其读写操作。所有核心的平均值可能掩盖单个饱和线程；还要查看相关进程。

下面这条读取命令适用于已获得授权且已安装 NVIDIA SMI 的 NVIDIA 目标设备。本指南未实际执行该命令。它会在 CSV 中保留单位，并每秒显示一次观测结果，直到被中断。请确认您的版本支持哪些字段，并在场景结束时停止采集。N/A 字段仍表示未知：不要把它当作零。

最低要求的日志应关联作业标识符、带时区的时间、当前阶段、可识别的输入或批次、进度以及可能的错误。日志中不得包含密钥，也不得包含对诊断无用的业务内容。如果缺少遥测数据，应先检查其采集机制和应用进度：一条空曲线并不能证明进程已停止。应标注无观测的时间段，而不是凭记忆重建它。

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

区分线索与结论

如果 GPU 活动在应用等待输入时下降，请检查文件路径。如果它在长时间的 CPU 准备阶段下降，请检查该阶段及其实际的并行度。如果各设备在等待分布式作业的其他参与者，请检查负载均衡与通信情况。多种症状可能同时出现；它们的相关性尚不能证明因果关系。

写下一个简短的假设以及一项可用于区分该假设的改动。例如，在结果保持一致的前提下，将已准备好的相同输入与通常的输入准备过程进行比较，可以隔离出某个步骤。不要同时更改批次大小、精度、进程数量和文件位置：否则一旦有所改善，将很难归因。

虚构示例：分析一个一百秒的循环

虚构团队“设计稿评审”描述了一个无重叠的循环：六十秒 CPU 准备、二十秒 GPU 计算，然后二十秒导出。总计为 100 秒，分配给 GPU 计算的时间占比为 20/100，即 20%。这一教学计算并不预测任何采样工具的百分比，也不对应目录中任何 GPU 的实测数据。

假设准备时间可以缩短到三十秒，而计算和输出保持不变。那么循环将变为 30 + 20 + 20 = 70 秒：少了三十秒，GPU 占比为 20/70，即约 28.6%。反之，假设仅将 GPU 计算减半，则得到 60 + 10 + 20 = 90 秒。该场景说明了为什么处理最长的等待可能比更换显卡更有影响。

使用性能分析工具深入分析某一阶段

如果常规观察能定位到一个缓慢区域却无法解释原因，就在一个短时间窗口内使用适合该应用的性能分析器。PyTorch Profiler 可以采集 CPU 和 CUDA 事件，并组织收集窗口。文档指出，启用形状或堆栈记录时会带来额外开销。因此，详细追踪是一种诊断工具；不应毫无保留地将其总耗时当作程序的正常耗时。

让阶段名称足够明确，以便把某项技术操作与你的工作对应起来：文件组准备、传输、应用步骤或输出发布。从假设所需的详细程度开始。修改之后，再做一次可比的观察，然后进行一次不启用重量级插桩的运行。这第二次检查可以验证在通常条件下收益同样存在。

避免采取掩盖问题的修正措施

提高并发度可以让 GPU 满载，同时却会让磁盘、主机内存或输出过载。增大批次大小可能改变延迟和所需内存。降低精度可能改变结果。这些决定并非禁止，但必须围绕同一业务目标、连同其副作用一起评估，而不能仅因显示的百分比上升就予以采纳。

不要为了诊断活动量的轻微下降而重置设备或更改其硬件参数。先从读取入手，然后由获得授权的人员检查明确的错误。也不要发布包含私人路径、机密参数或输入数据的原始日志。请准备对诊断有用的摘录，并将完整证据保留在团队获授权的范围内。

以对决策有用的证据结束诊断

最终报告应写明症状、所采纳的假设、尝试的改动、其条件以及观察到的结果。至少保留一次在同一组输入、同一质量和同一定义下的前后对比。如果结果不明确，就写明已排除的内容以及下一步需要进行的观察。记录被否决的线索，可以避免他人重新盲目尝试。

正常范围内的低活动并不总是需要修正。如果任务符合其期限、质量和预算要求，降低一项复杂度可能比脆弱的优化更可取。如果考虑新的配置，请把已证实的约束写入验收档案。没有任何单独一份读数会对产品目录进行排名，本示例中的任何数值都不构成承诺的性能。