国内显卡服务器的性能监控工具和方法?

干了这么多年算力运维，我越来越觉得一个道理很对：你不会管理的东西，你也无法真正拥有它。

这句话放在显卡服务器上尤其贴切。一张显卡跑得好不好，利用率高不高，什么时候该降频了，什么时候显存要爆了，这些事情如果心里没数，那所谓的“算力运营”就是一笔糊涂账。我见过太多团队花了大价钱采购了高性能的GPU服务器，结果跑起来要么温度过高降频，要么显存泄漏没发现，要么几张卡负载严重不均，算力白白浪费了一大半。

这些问题不是靠多买几张卡能解决的，而是要靠一套完善的监控体系来解决。这篇文章我想结合国内显卡服务器的实际运维经验，聊聊性能监控的工具和方法，希望能给正在管理GPU集群的朋友一些实实在在的参考。

为什么显卡服务器的监控比普通服务器更难

先说一个基本的判断。显卡服务器的监控和普通CPU服务器的监控，难度不在一个量级上。

普通的CPU服务器，你主要看CPU使用率、内存占用、磁盘IO、网络流量这几个指标，基本就够了。但显卡服务器不一样。一张现代GPU芯片内部有成千上万个计算核心，它的运行状态涉及到温度、功耗、显存带宽、PCIe吞吐、卡间通信延迟、时钟频率、ECC错误等等几十个维度。任何一个指标出现异常，都可能影响到整个计算任务的稳定性和效率。

更要命的是，显卡服务器的故障往往不是“宕机”这种显性的崩溃，而是“降效”这种隐性的恶化。你可能发现模型训练的时间突然变长了，但系统没报任何错误，服务器也在正常运行。这时候如果没有精细化的监控数据，你根本不知道问题出在哪。可能是某张卡温度过高开始降频了，可能是PCIe链路出了故障导致带宽下降了一半，也可能是显存碎片化严重导致分配效率降低。

这些都是显卡服务器监控必须面对的挑战。好在，国内在这方面已经有了成熟的工具和方法。

工具篇：从基础指令到企业级平台

聊方法之前，先说说工具有哪些。国内显卡服务器的监控工具，大致可以分为三个层次。

第一个层次是基础的命令行工具。最经典的就是nvidia-smi，这是NVIDIA官方提供的命令行工具，几乎所有的运维人员都离不开它。一条nvidia-smi命令，你就能看到每张卡的温度、功耗、显存占用、计算利用率、运行的进程等等基本信息。它的优点是轻量、直接、不需要额外安装，适合快速查看单台服务器的即时状态。

但nvidia-smi的局限也很明显。它只能看当下的数据，没法追溯历史，没法做趋势分析，也没法设置告警。你总不能半夜三点爬起来手动敲命令去看温度吧?所以它更适合做应急排查的“急诊工具”，而不是日常运维的“体检系统”。

第二个层次是开源监控方案。Prometheus加Grafana的组合，是目前国内GPU监控领域事实上的标准。Prometheus负责采集和存储指标数据，Grafana负责可视化和展示。中间需要一个桥梁把GPU的数据转换成Prometheus能认识的格式，这个桥梁就是dcgm-exporter。

dcgm-exporter是NVIDIA官方提供的工具，它基于DCGM，能够把GPU的各类指标暴露出来供Prometheus抓取。部署起来不算复杂，在每一台GPU节点上跑一个dcgm-exporter容器，然后在Prometheus里配置好抓取目标，再用Grafana连接Prometheus，你就能看到一个非常漂亮的GPU监控仪表盘了。

这套开源方案的好处是灵活、免费、社区活跃，你能想到的指标基本都能采集到。但缺点也很明显，需要自己搭建和维护，对于没有专门运维团队的团队来说，门槛不算低。

第三个层次是商业化的云监控平台。国内主流的云厂商都提供了GPU监控的解决方案。比如阿里云的云监控2.0推出了ECS洞察功能，可以对ECS实例中的GPU卡进行自动化的监控，包括功率、温度、显存使用率、计算利用率等指标，并且支持配置告警规则。华为云的CCE也基于DCGM提供了全面的GPU观测能力，与Prometheus和Grafana做了深度集成。

这些商业化方案的优势在于开箱即用，不需要自己去折腾部署和配置，告警通道、可视化看板都是现成的。如果你用的是公有云的GPU实例，这可能是最省心的选择。

第四个层次是企业级AI运维平台。对于拥有大规模GPU集群的企业来说，单一的监控工具已经不够用了，他们需要的是平台级的解决方案。浪潮云海的InCloud AIOS就是一个典型的例子，它专门针对异构GPU集群的运维场景，提供了从物理卡到业务Pod的全链路可视、智能预警、根因定位等能力。用他们的话说，就是要做到“看得见指标、看得透本质，找得到根因、防得住风险”。

还有一个值得关注的开源项目是华佗，这是滴滴开源并依托CCF孵化的操作系统深度观测项目。最近华佗刚刚宣布支持了沐曦GPU，把观测能力拓展到了国产算力底层。这对于那些正在使用国产GPU的团队来说，无疑是个好消息。

方法篇：监控不是目的，解决问题才是

工具摆在那，怎么用才是关键。我结合自己在国内显卡服务器运维中的一些经验，说说几个比较实用的监控方法。

分级监控，层层递进

监控不能眉毛胡子一把抓。几十个指标全都堆在同一个看板上，别说一眼看出问题，光是看着就头晕。

一个比较合理的做法是分级监控。把监控指标分成三个层次：

基础层是硬件健康状态，包括温度、功耗、风扇转速、电源状态这些。这一层关注的是“显卡还能不能正常工作”。如果温度超过了85度，或者功耗异常波动，那就是硬件层出了问题，需要优先处理。

性能层是计算和显存的使用情况，包括GPU利用率、显存占用、PCIe带宽、卡间通信延迟这些。这一层关注的是“显卡跑得好不好”。如果利用率长期低于10%，说明计算任务可能卡住了或者数据加载有瓶颈。

业务层是和具体应用相关的指标，比如训练任务的loss值变化、每轮迭代的时间、推理服务的延迟等。这一层关注的是“业务有没有受到影响”。有时候显卡本身跑得很好，但业务指标却在恶化，这时候就需要结合硬件指标来排查根因。

把这三个层次的指标串起来，才能形成一个完整的监控闭环。

分层告警，避免疲劳轰炸

告警配置是门学问。配置得太敏感，半夜三点被叫醒发现是个小波动，时间长了人就疲了，真出大事的时候反而没人响应。配置得太迟钝，等告警发出来的时候，故障已经扩散了。

一个比较成熟的实践是分层告警策略。

P0级别的紧急告警，需要立刻响应。比如GPU温度超过90度持续了3分钟，或者显存占用超过95%持续了5分钟。这种告警往往意味着硬件故障或者严重的内存泄漏，必须马上处理。P0告警建议用电话加短信加企业微信多通道同时推送，确保有人能收到。

P1级别的重要告警，需要尽快处理但不需要半夜把人叫起来。比如单卡和平均利用率的差异超过了30%，说明多卡负载可能不均衡。或者PCIe带宽使用率超过80%，说明数据传输可能有瓶颈。这类告警可以设置在工作时间推送。

P2级别的提示告警，记录一下就好，不需要立即处理。比如显存碎片率偏高，或者温度的日变化超过了15度。这类告警可以作为日常巡检的参考，或者用来做一些预防性的优化。

另外还有一个很实用的技巧是设置告警静默期和聚合。同一个指标在5分钟内只发一次告警，避免短时间内被同一条消息轰炸几十遍。

多卡并行的效率监控

这是显卡服务器监控里最容易出问题的地方，也是最能体现监控价值的地方。

多卡并行训练的时候，理想的情况是所有卡的利用率都在一个比较高的水平，并且相互之间差距不大。但实际运行中，经常会出现某几张卡利用率低、其他卡利用率高的情况。这就是负载不均，整体的训练速度会被慢的那几张卡拖累。

通过监控数据来诊断这类问题，有一个简单的思路。先看各张卡的GPU利用率，如果某张卡的利用率明显低于平均值，再去看它的PCIe接收速率是不是也偏低。如果是的话，问题可能出在数据加载上——CPU喂数据的速度跟不上GPU计算的速度。这时候可以考虑增加数据加载的线程数，或者用前面提到的GPU直接预处理来缓解瓶颈。

如果利用率低但PCIe带宽正常，那可能是卡间通信的瓶颈。大模型训练中张量并行模式对卡间互联带宽要求很高，当通信吞吐触及上限时，数据传输时延会急剧增加，造成计算核心空转浪费。这时候需要考虑优化并行策略，或者调整卡的拓扑结构。

国产GPU的监控适配

最近一两年，国内很多智算中心和企业的GPU集群开始引入了国产算力。国产GPU的监控是一个绕不开的话题。

好消息是，国产GPU的监控生态正在快速成熟。浪潮云海的InCloud AIOS已经适配了多款主流的国产GPU，建立了统一抽象模型来标准化不同厂商的监控指标。华佗开源项目也刚刚完成了对沐曦GPU的深度观测支持，可以通过调用MetaX的底层接口获取GPU的功耗、温度、利用率、时钟频率等关键数据。

不过，在具体操作中还是有一些需要注意的地方。不同厂商的GPU暴露指标的方式不同，有的用类似nvml的接口，有的用自定义的工具。如果你需要同时管理英伟达和国产GPU的混合集群，最好选择一个能够统一纳管多种异构硬件的监控平台，避免在多套系统之间来回切换。

数据采集的实用配置

监控数据的采集频率不是越高越好。采集太频繁会增加系统开销，采集太稀疏又会漏掉关键的变化。根据实际场景来调整是一个比较务实的做法。

对于训练任务，GPU的负载相对稳定但需要实时反馈，可以设置1到2秒的采集间隔。对于推理服务，负载变化相对平缓，可以放宽到5秒。对于温度这类变化相对缓慢的指标，甚至10秒采集一次也够用了。

另外，采集数据的存储也是一个需要提前规划的问题。如果只是做短期排查，保留几天到一周的数据就够用了。但如果需要做趋势分析和容量规划，就需要把这些数据导入到时序数据库中长期保存。用InfluxDB或者Prometheus自带的TSDB都可以，关键是要有一个明确的数据留存策略。

案例：一个真实的性能故障排查

说一个我自己遇到过的真实案例。有一次我们跑一个大模型的训练任务，发现每个epoch的时间从原来的50分钟慢慢增加到了70分钟，但系统日志里没有任何报错。

我们首先打开了Grafana看板，检查各张GPU卡的指标。发现有一个节点的两张卡温度明显比其他节点高，一直在87度左右徘徊。再往下看功耗曲线，这两张卡的功耗相比刚启动时下降了大约15%。这就是典型的温度过高导致降频——显卡为了保护自己，主动降低了工作频率，性能自然就下来了。

排查到物理层面，发现那个节点的机柜散热风扇有一个坏了，导致局部积热。换掉风扇之后，温度降到了72度，训练时长恢复到了正常水平。

如果没有精细化的监控数据，这个问题可能会被忽略很久。你可能一直在怀疑代码有问题，或者数据加载有瓶颈，但实际上问题出在机房的风扇上。这就是监控的价值——让问题浮出水面，而不是让团队在错误的方向上瞎折腾。

总结

国内显卡服务器的性能监控，说到底是一个体系化的事情，而不是装一个工具就能解决的问题。

从工具层面看，我们有nvidia-smi这样的基础指令，有Prometheus加Grafana这样的开源方案，有云厂商提供的商业化监控服务，也有面向大规模集群的企业级AI运维平台。不同类型的团队可以根据自己的规模和预算来选择合适的工具组合。

从方法层面看，分级监控、分层告警、多卡并行效率分析、国产GPU适配，这些都是国内显卡服务器运维中绕不开的实践要点。监控不是目的，通过监控发现问题、定位根因、解决问题，才是最终的目标。

从趋势层面看，随着国产算力的快速崛起，异构GPU集群的监控正在成为一个新的挑战和机遇。华佗支持沐曦、浪潮适配多款国产芯片，这些信号都表明，一套能够统一纳管多种异构硬件的监控体系正在形成。

最后想说的是，显卡服务器的监控不是一劳永逸的事情。业务在变，模型在变，集群规模在变，监控的策略和工具也需要跟着调整。但有一点是不变的，那就是“没有数据就没有管理”。把监控体系搭好，把数据跑起来，你的显卡服务器才能真正发挥出它应有的价值。