GPU 健康与压测

状态：入门理解 · 更新于 2026-09-14

GPU 验收不能只看“程序有没有跑完”。健康检查关注硬件是否稳定，性能压测关注系统是否达到预期，两者需要分别记录、共同判断。

先定义验收对象

同一型号 GPU 的结果还会受到功耗上限、散热、驱动、固件、CPU、NUMA、PCIe 拓扑和测试规模影响。因此，开始前至少固定以下信息：

• GPU 型号、数量、序列号或 PCI Bus ID；
• 驱动、CUDA、固件和测试工具版本；
• Power Limit、Persistence Mode、MIG 等运行配置；
• CPU/NUMA 与 GPU、NIC 的拓扑；
• 环境温度、持续时长、数据规模和通过标准。

不要用一个通用的温度或吞吐数字覆盖所有机器。最可靠的标准是同型号、同配置的健康基线与厂商规范。

测试矩阵

维度	要验证什么	重点观察
静态检查	设备是否被正确识别	型号、显存、链路宽度、驱动状态
显存	写入、读取和校验是否稳定	Uncorrectable ECC、页下线、测试报错
计算	长时间计算是否正确	结果校验、时钟、功耗、吞吐抖动
温度与供电	满载下能否稳定运行	温度、Power/ Thermal Throttle、掉卡
PCIe / NVLink	点到点链路是否正常	拓扑、链路降级、带宽、错误计数
多卡通信	集合通信是否稳定	NCCL 错误、带宽离群、超时

单一 GEMM 烤机不能覆盖显存全地址、链路和多卡通信；一次 DCGM 诊断也不能代替业务形态的长稳压测。

推荐流程

1. 压测前快照

保存设备清单、拓扑和错误计数，确认系统日志里没有已有的 Xid 或 PCIe 异常。常用入口包括：

nvidia-smi -q
nvidia-smi topo -m
nvidia-smi nvlink --status

2. 分层施压

先跑快速诊断，再分别覆盖显存、计算和链路，最后跑接近真实业务的多卡负载。这样发生故障时更容易定位，而不是把所有变量混在一个长任务里。

DCGM 环境可使用诊断能力做标准化检查；具体命令和权限以部署版本为准。多卡通信应补充 NCCL Tests，并与同机型基线对比。

3. 运行中采样

持续记录温度、功耗、核心/显存时钟、利用率、显存占用、ECC、PCIe Replay 和 NVLink 错误。只看测试结束时的一个快照会漏掉短暂降频和设备重置。

4. 压测后复核

再次采集与压测前相同的快照并比较增量，同时检查内核日志。新增的 Uncorrectable ECC、Xid、掉卡或链路降级都需要单独处理，不能只因平均吞吐正常就判定通过。

通过标准怎么写

一份可复查的标准应包含：

• 正确性：所有校验通过，无计算或显存数据错误；
• 稳定性：目标时长内无进程崩溃、设备丢失、Xid 或不可恢复错误；
• 热稳定：进入稳态后无异常持续降频，温度与功耗符合该机型规范；
• 性能：单卡与多卡结果处于同配置基线允许的偏差内；
• 一致性：同机 GPU 间没有无法解释的明显离群；
• 可追溯：保留机器信息、工具版本、参数、原始日志和结论。

故障定位顺序

1. 用 Bus ID 确定具体 GPU，避免设备编号在重启后变化。
2. 判断是单卡、固定插槽、固定链路，还是整机共同出现。
3. 对比温度、功耗、时钟与错误发生时间。
4. 检查 PCIe/NVLink 拓扑、NUMA 绑定和链路状态。
5. 在可控条件下交换卡、槽位或线缆，缩小硬件边界。
6. 保留故障前后日志，再决定重测、隔离或送修。

压测会让设备长时间处于高功耗状态，执行前应确认散热、供电和机房策略允许，并避免在承载生产任务的节点上直接运行破坏性测试。

信息来源

• NVIDIA System Management Interface
• NVIDIA DCGM Documentation
• NCCL Tests

更新日志

• 2026-09-14：补充验收对象、测试矩阵和故障定位流程。