AI服务器运维入门：GPU算力监控与显存异常处理

AI 服务器跑推理或训练任务时，最常见的故障不是 GPU 坏了，而是显存被占满或利用率长期为 0。
本文针对刚接手算力服务器的运维新手，讲清楚怎么用 nvidia-smi 判断 GPU 状态、怎么定位显存泄漏进程，以及怎么用容器限制和定时采集避免问题反复出现。
以下操作适用于安装了 NVIDIA 驱动和 Docker 的 Linux 服务器，命令在 Ubuntu 22.04 与较新驱动环境下通用，具体输出以你的驱动版本为准。

先看懂 nvidia-smi 的三个关键指标

登录服务器后执行：

nvidia-smi

重点看三块信息：

• 显存占用（Memory-Usage）：显示已用显存和总显存。推理任务通常占用稳定，如果已用显存持续上涨且不回落，基本可以判定为显存泄漏。
• GPU 利用率（GPU-Util）：任务运行时应有明显波动。长期为 0 而显存被占满，说明进程卡死或任务已退出但显存未释放。
• 进程列表（Processes）：记录 PID 和进程名。找不到对应进程却显示显存占用，通常是容器内进程或驱动残留。

如果服务器有多张卡，用 nvidia-smi -i 0 指定卡号查看，避免看错设备。

定时采集显存数据，别靠肉眼盯

临时排查可以手动执行，但定位泄漏需要连续数据。
写一个简单采集脚本：

mkdir -p /opt/gpu-monitor
cat > /opt/gpu-monitor/collect.sh <<'EOF'
#!/bin/bash
LOG=/opt/gpu-monitor/gpu.log
date '+%F %T' >> $LOG
nvidia-smi --query-gpu=index,memory.used,memory.total,utilization.gpu --format=csv,noheader >> $LOG
echo '---' >> $LOG
EOF
chmod +x /opt/gpu-monitor/collect.sh

加入计划任务，每 5 分钟记录一次：

(crontab -l 2>/dev/null; echo '*/5 * * * * /opt/gpu-monitor/collect.sh') | crontab -

运行一段时间后查看 /opt/gpu-monitor/gpu.log，对比不同时间点的 memory.used。
如果数值只增不减，结合进程列表定位具体 PID。

定位泄漏进程并安全释放显存

先找出占用显存的进程：

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

确认 PID 后，不要直接 kill -9。
先判断进程是否属于正在运行的任务：

ps -fp 

如果是已经退出的残留进程，可以正常终止：

kill 

终止后再次执行 nvidia-smi，确认显存回落。
如果显存仍未释放，且该卡上没有其他任务，可以重置 GPU（需 root 权限，且会影响该卡上所有任务）：

nvidia-smi --gpu-reset -i 0

注意：重置 GPU 会中断该卡上所有计算任务，生产环境务必先确认没有正在运行的推理服务，并做好任务迁移。

用 Docker 限制显存，防止单个容器拖垮整卡

如果 AI 任务跑在容器里，可以在启动时限制显存，避免一个容器占满整卡：

docker run -d \
  --gpus '"device=0"' \
  --memory 16g \
  --name ai-infer \
  -e NVIDIA_VISIBLE_DEVICES=0 \
  your-image:tag

显存层面的限制目前更多依赖框架参数（如 PyTorch 的 torch.cuda.set_per_process_memory_fraction），Docker 原生对显存配额支持有限。
更稳妥的做法是给容器设置内存上限和重启策略：

docker update --restart=unless-stopped ai-infer

这样容器异常退出后能自动拉起，避免显存被僵尸进程长期占用。

避坑与验证：确认问题真的解决了

排查完成后，至少做三项验证：

• 执行 nvidia-smi，确认显存占用回落到合理区间，GPU 利用率随任务正常波动。
• 查看 /opt/gpu-monitor/gpu.log，确认连续几个采集周期内 memory.used 不再持续上涨。
• 用 docker ps 确认容器状态为 Up，且重启次数没有异常增加。

常见坑有两个：一是只看总显存不看进程，误把正常缓存当成泄漏；
二是直接重启整台服务器，掩盖了真正的泄漏进程，过几天问题复现。
建议先保留采集日志，再处理进程，最后用数据验证效果。

如果你还在选型阶段，先确认服务器驱动版本和 CUDA 版本是否匹配任务框架要求，再谈监控；
版本不匹配时，nvidia-smi 能正常显示，但任务启动会直接报错。
日常运维中把采集脚本和容器重启策略配好，比事后救火省事得多。