GPU 监控与故障排查实战(利用率/显存/掉卡)

GPU 监控与故障排查实战(利用率/显存/掉卡)

Written by

in

在跑训练或推理任务时,最怕的就是GPU利用率上不去、显存悄悄上涨、突然掉卡。这份指南面向算法工程师与平台运维,从指标解读、命令实操到故障排查,帮你建立一套完整的GPU监控与排障SOP。读完你就能自己动手查问题、定位根因,把GPU故障对训练任务的影响降到最低。

本文要点

  • 监控看这六项:利用率、显存、温度、功耗、时钟频率、错误计数(XID),前三项决定能不能正常跑,后三项决定硬件健康度。
  • 工具按场景选:nvidia-smi 适合快速查看,nvtop 适合单机实时观察,DCGM 适合集群监控,三者组合覆盖从排障到告警的全部需求。
  • 利用率100%但无进程:优先检查残留进程与监控刷新间隔,用 nvidia-smi 配合 ps -ef 交叉确认。
  • 显存泄漏:从训练循环和缓存释放入手,结合显存曲线定位泄漏点。
  • 掉卡XID错误:先查 dmesg 日志,再检查驱动版本与硬件状态,不要盲目重启。

GPU监控指标解析:利用率/显存/温度/功耗/时钟/错误计数

GPU 芯片特写

结论:先关注利用率和显存这两项,再结合温度与错误计数判断硬件健康状态。

利用率(GPU-Util)反映计算单元的活动比例,是判断任务是否真正在跑的关键指标;显存占用(Memory-Usage)代表模型和数据的存放规模,训练时一般不会主动释放;温度(Temp)和功耗(Power)决定硬件寿命,长时间超过85℃会加速老化;时钟频率(Clock)体现当前性能档位,波动大说明可能撞到功耗墙;错误计数(如XID)是异常信号,出现任何非零值都值得排查。

经验参考值(编辑经验,具体以厂商文档与自身基线为准):正常训练时利用率常见稳定在70%以上,显存占用率80%左右属于健康区间,温度常见宜控制在60-85℃之间。如果利用率长期低于30%,可能说明数据加载或模型并发存在瓶颈。

需要注意的是,这些参考值会因模型、硬件和任务类型而异,建议先记录自己环境的基线值,再对比异常波动。

nvidia-smi实战:常用命令与输出字段解读

结论:nvidia-smi是排查GPU问题的第一步,掌握几个常用参数就能覆盖大多数场景。

最基础的命令是直接运行 nvidia-smi,它会列出所有GPU的型号、显存、利用率、温度、功耗等信息。想要实时刷新,可以加 -l 参数,例如 nvidia-smi -l 5 表示每5秒刷新一次。监控场景下更推荐用query模式输出结构化数据:

nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw --format=csv -l 1

这条命令以CSV格式每秒输出一次GPU索引、名称、利用率、显存占用、温度与功耗,适合写入脚本或日志。

输出字段解读:GPU-Util 是利用率百分比,Memory-Usage 是显存使用情况,Temp 是核心温度,Pwr:Usage/Cap 是当前功耗与设计上限,Perf 是性能状态(P0-P12,P0最高),ECC 显示错误纠正状态。若要查看完整信息,可使用 nvidia-smi -q 导出详细硬件与驱动参数。

进阶工具对比与选择:nvtop/dcgm-exporter/Prometheus

GPU监控体系架构示意图,展示nvidia-smi、DCGM、Prometheus、Grafana的层级关系
GPU监控从单机nvidia-smi到DCGM+Prometheus+Grafana集群采集的典型数据链路

结论:单机调试用nvtop,集群监控用DCGM+Prometheus,两者不是替代关系。

nvtop 是一个类似 htop 的交互式工具,按进程显示GPU使用率、显存、温度、风扇等指标,能直观看到哪个进程在占用GPU。DCGM 是 NVIDIA 官方提供的数据中心GPU管理工具,支持细粒度指标采集与批量GPU管理,配合 dcgm-exporter 可把指标导出给 Prometheus,再结合 Grafana 实现长期监控与告警。

进阶工具对比与选择:nvtop/dcgm 对照表

表格对比来看:如果只是偶尔查一眼,nvidia-smi够了;需要调试单机性能时,nvtop的进程维度和交互体验更好;而集群环境建议优先用DCGM,因为NVIDIA官方博客专门介绍了在Kubernetes中利用DCGM实现GPU使用率的实时可见性。阿里云的ACK也提供了GPU资源监控的最佳实践,涵盖指标采集、告警配置与故障诊断场景,可作为集群方案的参考。

常见故障排查:显存泄漏、掉卡XID、利用率异常

掉卡XID故障排查流程步骤图,依次为查看日志、检查驱动、检查硬件、上报处理
从查看dmesg日志到硬件检查的标准化掉卡排查流程

结论:大多数GPU故障可以通过「现象-原因-排查步骤」对照表快速定位。

以下原创的「GPU故障排查速查表」按现象列出可能原因与排查步骤,覆盖利用率、显存、掉卡与温度四类高频问题:

故障现象 可能原因 排查步骤
利用率100%但无进程 残留进程、核函数空转、监控刷新频率低 用 nvidia-smi -l 1 观察是否持续100%;ps -ef 查找残留进程并kill;检查容器内是否有僵尸进程
显存持续增长不释放 张量未del、缓存未清空、DataLoader泄漏 用 nvidia-smi 记录显存基线,跑一轮训练后对比增量;在代码中加入 torch.cuda.empty_cache();检查DataLoader的num_workers设置
掉卡(XID错误) 驱动不兼容、硬件过热、PCIe链路异常 `dmesg -T
温度异常偏高 风道堵塞、风扇故障、机房温度高 nvidia-smi -q -d TEMPERATURE 查看详细温度;检查风扇转速;清理散热器与机柜通风

显存泄漏的排查建议从代码层入手,训练循环中及时释放不再需要的张量,并定期调用 torch.cuda.empty_cache()。如果显存持续上升且无法回收,可能要检查 DataLoader 的 num_workers 是否过大导致缓存堆积。

掉卡(XID)是严重故障信号。常见的XID错误码包括 XID 79(GPU fallen off the bus)、XID 13/31(显存错误)等。出现XID后先不要重启,先用 dmesg -T 抓取日志,再检查驱动版本与硬件链路。驱动版本是掉卡的常见诱因,需要与CUDA版本严格匹配——京东云提供了自定义GPU驱动的操作指引,可用于驱动版本管理与兼容性验证。

GPU健康检查Checklist:日常巡检与预防

结论:建立例行巡检机制,大多数GPU故障都能在影响任务前被发现。

建议按日、周、月三个频率执行检查:

每日:运行 nvidia-smi 检查利用率、显存、温度是否正常。可以运行 nvidia-smi -q -d XID 查看XID错误计数。若显存占用率持续超过90%,应排查模型是否过大或存在泄漏。

每周:检查驱动与CUDA版本,确认与当前框架版本兼容。更新驱动前先备份现有环境,再在测试机上验证。

每月:复查硬件健康,包括PCIe链路状态、风扇转速、功耗曲线。可结合 nvidia-smi -q 导出的详细日志,对比历史基线,及时发现性能衰减。

常见问题FAQ

Q: GPU利用率100%但进程列表为空是什么原因?
A: 通常有三种可能:残留的GPU进程还在占用但被隐藏、监控工具刷新间隔与任务周期错位、计算核函数空转未实际提交任务。建议先用 nvidia-smi -l 1 确认持续占用,再用 ps aux | grep python 或 fuser -v /dev/nvidia* 找到残留进程并清理。

Q: 如何排查显存泄漏问题?
A: 先记录显存基线,再跑一轮训练对比增长曲线;在代码中检查张量释放,及时 del 不再使用的变量并调用 torch.cuda.empty_cache();同时检查 DataLoader 的 num_workers 是否过大。若显存仍在增长,用 nvidia-smi 配合PyTorch的 torch.cuda.memory_summary() 定位具体算子。

Q: 掉卡(XID错误)如何诊断和处理?
A: 先执行 dmesg -T | grep XID 提取错误码,再检查驱动与CUDA版本是否匹配,接着用 nvidia-smi -q 查看硬件状态(温度、风扇、PCIe)。如果错误反复出现,考虑更换GPU或上升至硬件层面排查。

Q: 如何监控GPU温度、功耗等指标?
A: 单机可用 nvidia-smi -l 5 实时观察,或 nvidia-smi -q -d TEMPERATURE,POWER 查看详细数据;集群环境建议用DCGM-exporter采集指标后接入Prometheus和Grafana,配置温度、功耗告警规则。

Q: nvtop与nvidia-smi有何区别?
A: nvidia-smi是NVIDIA官方提供的命令行工具,适合快速查看全局GPU状态;nvtop是第三方开源交互工具,按进程维度展示GPU使用率、显存和温度,类似CPU的htop。开发调试时nvtop更直观,脚本与监控场景则优先用nvidia-smi。

小结与下一步

结论:先建立监控基线,再配合排障SOP,GPU故障响应速度能提升一半以上。

回顾全文:监控指标重点看利用率、显存、温度和错误计数;常用工具推荐 nvidia-smi + nvtop + DCGM 三层组合;故障排查优先对照「现象-原因-步骤」速查表;日常巡检按日、周、月频率执行。建立自己环境的基线值,在出现波动时对比定位,才能把故障对训练的影响降到最小。

下一步行动:

  1. 立即记录当前环境 nvidia-smi 基线输出,保存为参考文档。
  2. 安装nvtop,下次训练时用进程视图观察GPU使用情况。
  3. 若管理多台GPU,部署DCGM-exporter + Prometheus + Grafana,为温度与XID设置告警。
  4. 在驱动升级前用测试机验证兼容性,避免因版本不匹配引发掉卡。

相关阅读

Comments

13 responses to “GPU 监控与故障排查实战(利用率/显存/掉卡)”

  1. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  2. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  3. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  4. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  5. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  6. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  7. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  8. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  9. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  10. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  11. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  12. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]

  13. […] GPU 监控与故障排查实战(利用率/显存/掉卡) […]