GPU服务器监控指标指南：显存、利用率、功耗、温度与故障|赋创fuchuang

先给结论：建立“资源、健康、链路、业务”四层监控

GPU利用率只表示某个采样窗口内GPU有工作，不能单独说明服务是否高效。显存已满但GPU利用率很低，可能是模型已加载但没有请求；GPU利用率较高但吞吐下降，可能与降频、CPU、网络、存储或请求分布有关。

指标组	建议观察	可能回答的问题
显存	已用/剩余显存、BAR1、显存接口活跃度、显存温度	是否存在OOM风险、KV Cache挤压或带宽瓶颈
计算	GPU/SM活跃度、Tensor/FP管线活跃度、时钟、P-State	工作负载是否真正使用计算单元
功耗	板卡瞬时功耗、能耗累计、功耗上限、功耗导致的时钟事件	是否触发功耗限制，机柜和电源是否有余量
温度	GPU温度、显存温度、距降频阈值的温度余量、风扇转速	散热是否逼近限制，是否已经发生热降频
健康	ECC、Xid、PCIe replay、行重映射、链路CRC/重传、脱离GPU	是否存在硬件、链路或驱动层异常
业务	队列长度、TTFT、TPOT、吞吐、错误率、拒绝请求	GPU指标变化是否真正影响用户体验

模型权重加载后会长时间占用显存，但不代表显存接口始终忙碌。在推理服务中，还要把权重、KV Cache、激活、CUDA图、通信缓冲和运行时工作区分开理解。

告警不宜只用一个统一显存百分比。应结合模型类型、最大上下文、并发和回收策略，通过PoC确定稳定区间和趋势告警。

单看温度绝对值不足以判断是否降频。DCGM提供GPU温度、显存温度、距最近降速阈值的温度余量，以及热、功耗和外部power brake导致的时钟事件。实际字段名称可能随DCGM版本变化，应在监控平台升级时同步复核。

单个指标很少能直接给出根因。显存占用高但显存读写活动低，可能只是权重和KV Cache常驻；GPU利用率高但功耗、时钟和吞吐没有同步变化，需要检查采样窗口、内核类型和排队；温度升高同时出现时钟受限事件，才更接近热或功耗边界。

DCGM字段覆盖GPU利用率、显存、温度、功耗、时钟、PCIe、错误与拓扑等类别。实际采集前要核对目标GPU支持的字段，并记录字段ID、单位、采样频率和聚合方式。

nvidia-smi可查询设备状态、功耗、温度、时钟、PCIe链路和进程信息，适合单机核查与故障取证。生产监控仍需把数据送入时序系统，并保留GPU、主机、容器、模型和任务之间的标签关系。

先在空闲、典型负载和压力负载下采集基线，再设置“阈值＋持续时间＋关联条件”。容量告警关注显存余量和队列；健康告警关注XID、不可纠正错误和设备失联；效率告警关注单位业务量对应的GPU时间、功耗和等待。不同GPU型号、散热环境与工作负载不应共用一个绝对阈值。

DCGM提供健康、诊断、策略和遥测能力，但诊断结果仍应与应用日志、作业状态和硬件事件交叉验证。告警系统要保存原始时间窗，避免只留下聚合后的红灯。

验收时模拟显存逼近上限、进程退出、负载突增和节点重启，检查指标是否连续、标签是否正确、告警是否去重、工单是否带上下文。无法从告警定位到主机、GPU、任务和模型版本的仪表板，不能视为完成交付。

采样频率也应分层：设备健康和错误事件要尽量保留原始时序，容量趋势可以使用较长窗口，业务看板则要与请求周期对齐。聚合前应明确最大值、平均值、分位数和缺失值处理，否则同一时间段可能得出相反判断。修改采样周期后，应保留变更点并重算告警基线。

赋创可协助完成GPU服务器与软件环境的监控指标梳理、DCGM等遥测组件部署、仪表板与告警接入、压测期基线记录和交付验收。业务SLA和最终告警阈值应由客户根据实际负载确认。

不代表。还要结合时钟、降频原因、显存接口活跃度、队列、TTFT、TPOT、吞吐和错误率。

不建议。不同GPU、散热方式和服务器设计的官方运行限制不同。应结合官方阈值、温度余量和PoC基线设置。

不能。DCGM主要提供GPU和相关硬件遥测。用户可见的延迟、吞吐、排队、错误率和质量指标仍需要在应用与推理框架层采集。

不是。过高频率会增加采集与存储开销，过低频率又可能漏掉短时故障。应按健康事件、容量趋势和业务周期分别设置，并验证缺失值与聚合逻辑。

每次告警至少关联主机、GPU UUID、驱动、容器、任务、模型版本、采样窗口和最近变更。赋创可协助DCGM或系统工具接入、指标标签设计、仪表板和故障注入验收；具体阈值需以客户机房与工作负载基线确认。

方案咨询

联系赋创获取算力、软件栈和交付路径建议。