一篇读懂 GPU 监控：DCGM、指标采集与告警

为什么 GPU 需要专门的监控

GPU 集群的故障管理流程——巡检、隔离、自愈——「GPU 集群故障工程」一篇已经讲过；本篇讲那套流程的眼睛：用什么指标、什么工具，把几千张卡的健康状态看清。GPU 的故障有很强的隐蔽性：显存 ECC 错误是悄悄累积的，卡的性能退化不伴随任何报错，风扇停转在空闲时毫无症状——等到任务失败或机器过热才晓得，代价已经是整个作业回滚。监控的目的就是把「悄悄变坏」变成「立刻知道」。

还有一个反向误区要先破：利用率高不等于健康。卡被死循环任务或恶意程序打满时，利用率曲线同样漂亮——健康的判断永远是多维的（温度、错误计数、限频状态一起看），单看任何一个数字都会被骗。监控数据还是自动化运维的触发源：设备插件据此判定 GPU 可不可调度、调度器据此摘卡、自愈流程据此重拉任务（联动「Kubernetes Device Plugin 与 GPU Operator」篇与「GPU 集群故障工程」篇），指标体系的质量直接决定这套自动化的上限。

先划清工具边界：nvidia-smi 是单机的、给人看的快照工具，敲一次看一眼；集群需要的是机器可读、持续采集、有历史、能告警的体系。这套体系的事实标准底座，是英伟达的 DCGM。

DCGM 是什么

DCGM（Data Center GPU Manager）是英伟达面向数据中心 GPU 的管理框架，打包了三块能力。指标采集：把利用率、显存、温度、功耗、ECC、NVLink、PCIe 等几十项指标以统一接口暴露出来，这是它被用得最多的能力。健康检查与诊断：提供从秒级快速体检到分钟级深度诊断的多档诊断命令（dcgmi diag 一族），覆盖显存、算力、互联的专项测试，新卡上架验收与故障复检都靠它。策略与告警：可以在节点本地注册条件触发（比如 ECC 错误超过阈值即标记 GPU 不健康），与上层调度联动把坏卡摘出调度池。

K8s 环境里 DCGM 通常不单独露面，而是被两层设施调用：GPU 设备插件用它的健康检查结果判定 GPU 是否可调度（这个联动在「Kubernetes Device Plugin 与 GPU Operator」一篇里讲过），dcgm-exporter 把它的指标翻译成 Prometheus 格式供全集群采集。也就是说，DCGM 在监控体系里的角色是贴近硬件的指标源头，上面所有的看板与告警，数据最终都从它来。

诊断功能要用对场合：秒级的快检适合新卡上架与例行巡检，分钟级的深度诊断会占卡跑压力测试——必须选在节点空闲时执行，在满载业务上跑深度诊断等于自己制造性能事故。例行巡检建议纳入平台日程：低峰期按月或按周对空闲节点轮跑诊断，主动挖出潜伏坏卡，而不是等任务失败倒逼排查。另外注意版本配套：DCGM 与驱动有版本对应关系，升级驱动要连带升级整条工具链，版本错配的典型症状是指标缺失或诊断失败。

核心指标与错误码

资源类指标：利用率、显存、温度、功耗

日常巡检看四类资源指标。利用率注意口径：DCGM 暴露的 SM 活动类指标反映的是「采样窗口内有计算在跑的时间占比」，不等于计算饱和度——内存带宽瓶颈型负载可能利用率常年高企而吞吐平平，容量分析别拿它直接当有效算力（这个口径坑在「算力度量衡」篇也提醒过）。显存看已用量与 ECC 保留量：部分显存因故障被保留标记，可用显存缩水是硬件老化的直接信号。温度要把 GPU 核心温度与显存温度分开看，高负载下显存温度超标引发的降频是隐蔽的性能杀手。功耗除了读数还要看限频状态：卡因温度、功耗墙或供电不足主动降频时，任务变慢的锅不在软件——限频原因字段能直接告诉你卡在自我保护。功耗封顶本身也是一条配置项：数据中心按机柜供电预算给卡设功率上限，监控要能区分「卡被策略限功率」与「卡出问题降频」，两者的处置完全不同。

温度指标还要看空间分布：进风口与出风口的温差、相邻槽位的温度梯度，能暴露散热体系的局部问题——风道短路、某槽位风扇停转，单点温度读数都可能是正常的。给每台机器维护一份温度画像（各位置的常态温度区间），偏离画像才是真正的信号，比死记一个全局阈值灵敏得多。

互联类指标也该列入日常：NVLink 的错误计数、PCIe 的吞吐与重试，是分布式训练的血管健康度。单卡指标全绿但互联退化时，表现是多机任务集体变慢且极难定位——因为每台机器看自己都是好的。这类问题要靠集群层的互联指标对比（哪些链路的错误计数在涨）来锁定。

错误类指标：ECC 与 XID

硬件健康的核心是两类错误。ECC 错误分两档：单比特错误可自动纠正，不影响正确性，但数量趋势反映显存颗粒老化——缓慢累积可以接受，加速累积要警惕；双比特错误不可纠正，意味着数据已经坏了，出现即视为该卡不合格，立刻摘除。XID 错误码是驱动层记录的 GPU 错误事件编号，出现在内核日志里，不同编号对应不同故障类别——显存非法访问、掉卡、总线错误各有对应编号（具体映射以英伟达官方 XID 文档为准，不在此编造）；运维上记住一条常识口径：任何 XID 都值得记录，反复出现的 XID 是卡要出事的前兆。

XID 的处置要做成矩阵而不是临时查文档：按编号归类——哪类重启即可恢复、哪类必须摘卡换硬件、哪类其实是任务自己的显存非法访问（锅在用户代码而非硬件）。矩阵写进 runbook，告警消息里直接带上编号与建议动作，值班的人不用每次现场查表。互联类指标（NVLink 错误计数、PCIe 吞吐异常）同样属于这一层：单卡健康但互联退化，会让全家桶式的大规模训练集体变慢，而且极难从任务侧定位。排查手段是对比法：同一条链路的错误计数按天环比，涨了的链路去查物理层——换线、换槽位、重插卡，逐级排除；大规模训练上线前先跑一遍全链路互联体检，把基线错误计数记下来，之后的环比才有参照，没有基线的环比全是噪声。

采集链路：从 exporter 到告警

标准采集链路四段：节点上 dcgm-exporter 以守护进程形态运行（K8s 里是 DaemonSet，每节点一个），周期性向 DCGM 拉取指标并翻译成 Prometheus 格式暴露在本地端口；Prometheus 按抓取配置周期性刮取所有节点的 exporter，指标带节点与卡序号标签入库；Grafana 接在 Prometheus 上出看板——全局热力图（全集群温度或利用率一眼扫过）、单节点详情页、单卡历史曲线三层最常用；Alertmanager 消费 Prometheus 的告警规则，做分组、静默、路由到值班渠道。

这条链路的工程账有两笔。一是指标基数：每卡几十项指标乘几千个节点，Prometheus 的存储与查询压力要靠合理的抓取间隔（常用十几秒到半分钟的口径）与指标裁剪来控制，用不到的指标别采。二是 exporter 自身的可用性要被监控——exporter 挂了等于这个节点失明，必须有「无数据」告警兜底，否则最常见的故障形态恰恰是「不是卡坏了，是看卡的眼睛闭上了」。

标签设计与看板组织决定这套体系好不好用：指标务必带上节点、卡序号、卡型号标签，看板按「全局热力图——单节点详情——单卡历史」三层组织，从上层任意一格能点进下钻页面。抓取间隔还有个容易踩的坑：单次抓取是瞬时采样，几秒的性能毛刺大概率落在两次抓取之间；判断异常要靠「持续多长时间超过阈值」的区间条件，而不是单点越线就告，否则告警会被无数无害毛刺淹死。单套 Prometheus 也有规模上限，多集群场景下按集群分片采集、上层做联邦聚合或接入远端存储（常识口径），别把几千节点硬塞进一个实例。

指标命名也要统一规划：导出器暴露的指标名、单位、标签在集群级保持一致；不同版本的导出器改指标名，会悄悄断掉下游看板与告警——升级导出器前先对指标清单做对比，改名指标在新旧名之间留一段双写期，让下游有缓冲地切换。这类「指标契约」的纪律，和 API 的版本管理是同一件事。

典型告警规则与行动闭环

一组可以直接抄走的规则

告警规则按严重度分级给一组常识口径的示例。立即处理级：双比特 ECC 错误出现即告——该卡已经产生数据损坏，联动摘除；XID 错误出现即告——按编号定级，涉及掉卡与显存类错误的直接隔离；掉卡告警——节点可见 GPU 数量变化，卡消失是驱动或硬件层面的硬故障。观察级：GPU 或显存温度超过阈值（八九十度区间按机型校准，模糊口径）持续数分钟——散热问题预警；ECC 单比特错误日增速超基线——颗粒老化趋势；限频状态频繁触发——性能劣化预警；显存水位持续高位——容量预警。兜底级：exporter 无数据——监控本身失明，比卡坏更危险。

告警要接行动，不止是叫人

告警规则之外，闭环设计决定监控的实际价值。每条告警绑定处置动作：观察级进工单，立即处理级直接触发流程——按「GPU 集群故障工程」篇的自愈机制自动隔离节点、迁移任务；值班渠道的升级策略（多久没人认领升级到下一级）写清楚。历史指标数据还有一层事后价值：故障复盘时回看前兆曲线——出事前几个小时温度是不是在爬、ECC 是不是在加速，这些规律反过来又变成新的告警规则。监控体系是长出来的，不是搭完就完的：每复盘一次故障，规则清单就厚一页。

告警的运营还有两件事别漏。一是静默管理：计划内维护（换卡、固件升级、机房检修）提前对相关节点设静默窗口，否则每次维护都触发一串已知告警，值班的人很快学会无视告警——告警疲劳比没有告警更危险。

告警文案的工程化也值得投入：消息里带上节点名、卡号、指标当前值、阈值、建议动作与处置手册链接——值班的人不打开看板就能判断要不要立刻行动，这条投入的回报极高。规则的阈值还要定期校准：机型更替、散热改造、负载结构变化都会移动合理阈值的位置，每半年把告警阈值过一遍，误报率与漏报率摊开来看——告警体系的调参和推理服务一样，是持续的运维对象。二是任务侧与硬件侧指标的配合：GPU 侧指标看硬件健康，任务侧的显存泄漏、驻留异常要看应用自身的指标，两边对照才能分清「卡坏」与「程序坏」——监控篇管前者，应用的锅别让硬件背。

最后一层是输出的沉淀：每月出一份 GPU 健康简报——告警统计、故障复盘结论、坏卡去向、更换周期趋势——把监控体系的产出变成管理层看得懂的资产台账。监控要长期拿到投入，就得让人看见它省了多少钱：一次提前发现的坏卡、一次避免的作业回滚，都是这本简报里的数字。

小结

GPU 监控的体系一句话概括：DCGM 做贴近硬件的指标源头，dcgm-exporter 做翻译，Prometheus 做采集存储，Grafana 做展示，Alertmanager 做告警路由；指标上资源类四件（利用率、显存、温度、功耗）看当下，错误类两件（ECC 分档、XID 编号）看健康，互联指标看分布式训练的集体命脉；告警按立即处理、观察、兜底三级分层，每条都绑定行动而不是叫一声就完。

两句话收束这门手艺。第一句：GPU 的坏是悄悄的坏，ECC 在累积、显存在缩水、温度在爬坡，等报错出现时代价已经翻倍——监控体系的价值就是把发现提前到前兆阶段。第二句：监控是运维的输入，不是运维本身，指标齐了、告警响了之后，隔离与自愈的流程承接不住，监控就只是昂贵的装饰品。把它和故障工程流程、容量规划（利用率历史正是容量规划的输入）连起来用，这套体系才算转满了。