AI服务器GPU显存监控：nvidia-smi与DCGM实操

AI 服务器上 GPU 显存被占满，往往不是模型太大，而是残留进程没退干净。
显存监控要解决两个问题：当下谁占了多少显存，以及长时间运行中显存是否在缓慢泄漏。
前者用 nvidia-smi 就能看清，后者需要把显存指标持续采集起来。

先确认驱动和显存读数正常

登录服务器后执行：

nvidia-smi

输出里重点看三列：Memory-Usage 是显存已用/总量，GPU-Util 是计算利用率，底部 Processes 表列出占用显存的进程 PID 和进程名。
如果命令报 NVIDIA-SMI has failed，先检查驱动是否加载：

lsmod | grep nvidia

没有输出说明驱动没装好或内核模块未加载，需要先处理驱动问题，再谈显存监控。

用 nvidia-smi 定位显存占用

日常排查显存，最常用的是按进程查：

nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

这条命令只列出计算进程及其显存占用，比完整输出更适合脚本处理。
如果只想看每张卡的显存汇总：

nvidia-smi --query-gpu=index,name,memory.used,memory.total --format=csv

发现某个 PID 占着显存但业务已经停止，先确认它是不是僵尸进程：

ps -p  -o pid,stat,cmd

状态为 Z 表示进程已退出但父进程未回收，需要处理父进程；
状态正常但业务不需要，可以用 kill 结束，结束前确认该进程不属于其他同事的任务。

部署 DCGM Exporter 持续采集显存指标

nvidia-smi 只能看当下，显存缓慢增长需要趋势数据。
NVIDIA 提供的 DCGM Exporter 可以把显存、温度、利用率等指标暴露成 Prometheus 格式。

前提是服务器已安装 NVIDIA 驱动，并且能运行 Docker。
用容器方式启动最省事：

docker run -d --gpus all --rm \
  -p 9400:9400 \
  --name dcgm-exporter \
  nvcr.io/nvidia/k8s/dcgm-exporter:latest

启动后验证指标是否可访问：

curl -s localhost:9400/metrics | grep DCGM_FI_DEV_FB

显存相关指标主要是 DCGM_FI_DEV_FB_USED（已用显存，单位 MiB）和 DCGM_FI_DEV_FB_FREE（空闲显存）。
能查到这两项，说明采集链路通了。

把显存指标接入 Prometheus 并设告警

在 Prometheus 的 prometheus.yml 中增加抓取任务：

scrape_configs:
  - job_name: 'dcgm'
    static_configs:
      - targets: ['127.0.0.1:9400']

重载配置后，在 Prometheus 界面查询 DCGM_FI_DEV_FB_USED 应能看到数据。
告警规则可以按显存使用率设置，例如单卡已用显存超过总量的 90% 持续 5 分钟：

- alert: GPUMemoryHigh
  expr: DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE) > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "GPU 显存使用率超过 90%"

阈值不要照搬，推理服务和训练任务的合理水位不同，先观察一周正常波动再定。

常见坑和验证方式

坑一：只看总量不看进程。 多卡机器上某张卡显存占满，先确认是哪个进程、是否属于预期任务，不要直接重启整机。

坑二：容器内看不到宿主机进程。 在容器里执行 nvidia-smi 可能只显示容器内进程，排查显存时回到宿主机执行。

坑三：显存碎片导致申请失败。 显存显示还有空闲但分配报 OOM，通常是碎片问题，重启对应进程往往比调参数更快。

验证监控是否生效，可以人为启动一个占显存的进程，观察 Prometheus 中 DCGM_FI_DEV_FB_USED 是否上升，告警是否按阈值触发。
确认后再把告警接入实际通知渠道。

GPU 显存监控的落点很明确：nvidia-smi 负责即时定位，DCGM Exporter 负责长期趋势和告警。
先把这两层跑通，再根据业务水位调整阈值，比一上来堆复杂面板更实用。