NVIDIA GPU服务器如何查看显卡状态？驱动、显存与温度监控教程

一台 8 卡 GPU 服务器跑得好好的，某天训练速度突然掉了一半。登上去看，进程还在、显存也占着，就是慢。这种情况十有八九是某张卡因为过热降频了，或者掉到了 PCIe x4 链路，再或者 ECC 报错被降速。如果平时没有建立监控基线，遇到这类"软故障"就只能靠猜。

GPU 状态监控是所有 AI 运维的地基：驱动版本决定能不能跑，显存决定能不能装下模型，温度和功耗决定能不能持续跑满。本文整理一套从"一次性查看"到"长期监控"的完整命令集，全部可以直接复制执行，并给出各项指标的判断阈值。

一、先确认驱动和卡：基础信息查看

1.1 驱动与显卡总览

nvidia-smi（NVIDIA System Management Interface）是随驱动一起安装的核心工具，几乎所有状态查询都从它开始。

# 最常用：一次性输出驱动版本、CUDA 版本、每张卡的状态
nvidia-smi

# 只看驱动版本和最高支持的 CUDA 运行时版本
nvidia-smi --query-gpu=driver_version --format=csv
cat /proc/driver/nvidia/version

# 列出所有 GPU 的编号与型号（最简洁）
nvidia-smi -L

nvidia-smi 右上角显示的 CUDA Version: 12.4 指的是当前驱动所能支持的最高 CUDA 运行时版本，不等于机器上已经装了 CUDA 12.4 工具包。这点经常被混淆。要确认实际安装的 CUDA 工具包版本，得单独查：

# 确认 CUDA 工具包版本（软链方式）
ls -l /usr/local/cuda
/usr/local/cuda/bin/nvcc --version

# 若上面命令报找不到，先确认环境变量
echo $PATH
echo $LD_LIBRARY_PATH
which nvcc

# 查看驱动模块是否加载
lsmod | grep nvidia
modinfo nvidia | head -n 5

1.2 确认物理链路和拓扑

这一步排查"慢"的问题非常关键。很多性能问题的根因是 PCIe 链路降速或 GPU 挂在了错误的 NUMA 节点上。

# 从总线角度列出所有 NVIDIA 设备
lspci | grep -i nvidia

# 查看链路能力（LnkCap）与当前实际速率（LnkSta）
sudo lspci -vvv -s 0000:17:00.0 | grep -E "LnkCap|LnkSta"

# 输出 GPU 与 CPU 的 NUMA 拓扑矩阵
nvidia-smi topo -m

解读：LnkSta 里如果显示 Speed 16GT/s, Width x16 表示跑在 PCIe 4.0 x16 满速；如果显示 Speed 8GT/s 则是 Gen3，Width x8 表示只用了 8 条 lane。当 LnkSta 明显低于 LnkCap 时，就说明链路降速了，常见原因是 PCIe 插槽共享、riser 卡规格不够、BIOS 设置、或者金手指接触不良。

nvidia-smi topo -m 输出的矩阵中，NV# 表示 NVLink 互联，PXB 表示经由 PCIe 交换机，PIX 表示经由 PCIe 主机桥，SYS 表示跨 NUMA 节点（要过 QPI/UPI，延迟最高）。

二、显存状态：容量、占用与进程归属

2.1 查看显存占用

# 只看显存相关字段，适合脚本采集
nvidia-smi --query-gpu=index,name,memory.used,memory.total,memory.free --format=csv

# 带单位、易读格式
nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv,noheader,nounits

# 查看某张卡的完整显存详情
nvidia-smi -i 0 -q -d MEMORY

# 查看是哪个进程在占显存
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

判断要点：nvidia-smi 里看到的 used_memory 是进程向驱动申请的总量。像 PyTorch 这类框架的缓存分配器会保留已释放的块，所以它通常大于真实使用量。要区分"真的不够"和"只是缓存没释放"，需要结合框架自身的 torch.cuda.memory_allocated() 来看。

2.2 显存相关的健康状态

# 查看 ECC 错误计数（数据中心卡重点监控项）
nvidia-smi --query-gpu=ecc.errors.uncorrected.volatile.total,ecc.errors.corrected.volatile.total --format=csv

# 查看 ECC 是否开启及详细模式
nvidia-smi -q -d ECC

# 查看已退役（Retired）的显存页，出现非 0 需要注意
nvidia-smi -q -d PAGE_RETIREMENT

# 查看 MIG 模式状态（A100/H100 支持切分）
nvidia-smi --query-gpu=mig.mode.current --format=csv

ECC 不可纠正错误（uncorrected）一旦出现非零值，就应该安排停机检修——它意味着显存中出现了无法被纠正的数据损坏，继续跑下去训练结果可能不可信。可纠正错误（corrected）少量出现可以观察，但持续增长同样是硬件老化的信号。

三、温度与功耗：最影响持续性能的两项

3.1 温度监控

# 查看所有卡的温度与风扇转速
nvidia-smi --query-gpu=index,temperature.gpu,temperature.memory,fan.speed --format=csv

# 查看温度明细与降频阈值
nvidia-smi -q -d TEMPERATURE

# 查看当前降频原因（关键！）
nvidia-smi --query-gpu=clocks_throttle_reasons.active --format=csv

# 每秒刷新一次整体状态
watch -n 1 nvidia-smi

clocks_throttle_reasons.active 是诊断"为什么变慢"最有价值的字段。常见取值含义：

3.2 温度判断标准

不同卡型的温度上限不同，但工程上可以用一套保守阈值来运维：

• 核心温度持续低于 75℃：健康。
• 75～85℃：需要关注，检查机房进风温度和风道。
• 超过 85℃ 并出现 Thermal 降频：需要处理。常见原因是机柜热风回流、防尘网堵塞、相邻设备排风直吹。
• 显存温度（temperature.memory）：GDDR6X 类显存的显存结温可到 100℃ 以上才开始降频，但长期高温会加速老化，建议控制在 90℃ 以内。
• 突然的异常高温：单卡比同机箱其他卡高 10℃ 以上，通常是该卡散热器安装不良或导热硅脂失效。

3.3 功耗与时钟

# 查看实时功耗、功耗上限、当前与最大时钟
nvidia-smi --query-gpu=index,power.draw,power.limit,clocks.sm,clocks.max.sm --format=csv

# 查看持久化模式（建议数据中心卡开启）
nvidia-smi --query-gpu=persistence_mode --format=csv
sudo nvidia-smi -pm 1

# 调整功耗上限（示例：设为 300W，上限范围受卡型限制）
sudo nvidia-smi -i 0 -pl 300

# 锁定/解锁时钟（训练集群常用）
sudo nvidia-smi -q -d SUPPORTED_CLOCKS
sudo nvidia-smi -i 0 -lgc 1410,1410

持久化模式（Persistence Mode）建议长期开启。关闭时，每次没有计算任务后驱动会卸载，下次启动任务要重新初始化，会增加明显的首调用延迟，也会让监控采集出现断档。

四、查询字段速查表

--query-gpu 支持非常多的字段，下面是最常用的速查：

五、长期监控：从手工查看走向自动化

5.1 用 dmon 做持续采样

nvidia-smi dmon 是内置的守护式采样工具，适合临时抓一段时间的性能曲线，也是写监控脚本时最方便的数据源。

# 每 5 秒采样一次，输出功耗(p)利用率(u)显存(m)ECC(e)温度(t)
nvidia-smi dmon -s pucvmet -d 5

# 只采显存和利用率，采 720 次（约 1 小时，按 5 秒间隔）
nvidia-smi dmon -s um -d 5 -c 720

# 输出为 CSV 便于后续分析
nvidia-smi --query-gpu=timestamp,index,utilization.gpu,memory.used,temperature.gpu,power.draw \
  --format=csv -l 10 -f /var/log/gpu_metrics.csv

-s 后面的字母含义：p=功耗/温度、u=利用率、c=CPU/内存、v=其他、m=显存、e=ECC、t=温度。用 -f 参数可以直接落盘成日志文件。

5.2 数据中心级监控：DCGM

对于 8 卡以上的集群，建议部署 DCGM（Data Center GPU Manager）。它比 nvidia-smi 更轻量，支持把指标导出到 Prometheus。

# 查看 DCGM 服务状态与发现的 GPU
systemctl status nvidia-dcgm
dcgmi discovery -l

# 配置健康监控，启用全部默认检查项
dcgmi health -s a
dcgmi health -g 0 -c

# 查看当前健康状态
dcgmi health -g 0 -g 1 -g 2 -g 3 -g 4 -g 5 -g 6 -g 7 -c

# 导出指标（配合 dcgm-exporter 接入 Prometheus + Grafana）
curl localhost:9400/metrics | grep dcgm_gpu_temp

DCGM 的健康检查覆盖了 PCIe 链路降级、显存错误、NVLink 错误、温度超限、功耗异常等场景，配合告警规则可以把"事后救火"变成"事前发现"。典型告警阈值建议：GPU 温度 > 85℃ 持续 5 分钟、不可纠正 ECC 错误 > 0、PCIe 链路宽度低于 x8、NVLink 错误计数增长。

六、日常巡检步骤清单

1. 确认驱动正常加载：nvidia-smi 能否正常输出，lsmod | grep nvidia 是否有模块。
2. 核对卡数与型号：nvidia-smi -L 的数量与资产清单一致，型号与采购合同一致。
3. 检查 PCIe 链路：lspci -vvv 中 LnkSta 是否等于 LnkCap。
4. 检查 NVLink 状态：nvidia-smi nvlink -s 各链路是否正常 up，错误计数是否为 0。
5. 查看 ECC 与页退役：不可纠正错误必须为 0，退役页持续增长需报修。
6. 检查温度与降频原因：温度是否逼近阈值，clocks_throttle_reasons.active 是否出现 Thermal 或 Power。
7. 确认持久化模式：nvidia-smi -pm 1 是否已开启。
8. 检查残留进程：nvidia-smi --query-compute-apps 里有无不属于当前业务的进程。
9. 对比历史基线：功耗、温度、利用率与正常时期的记录做对比，偏离 20% 以上要排查。
10. 验证告警链路：制造一次模拟告警，确认能推送到值班人。

# 一张图看清八卡的健康状态（精简巡检脚本）
nvidia-smi --query-gpu=index,name,driver_version,memory.used,memory.total,\
utilization.gpu,temperature.gpu,power.draw,power.limit,pstate,\
clocks_throttle_reasons.active,ecc.errors.uncorrected.volatile.total \
--format=csv

七、常见故障与对应现象

小结

GPU 状态监控的核心工具就是 nvidia-smi，但真正有用的是把它用成体系：用 --query-gpu 精确取字段做定时采集，用 dmon 抓性能曲线，用 clocks_throttle_reasons 定位降频，用 DCGM 做集群级告警和 Prometheus 集成。

三条实践建议：第一，建立基线——新机器上线时记录空载和满载下的温度、功耗、时钟，没有基线就没有"异常"这个概念；第二，把降频原因纳入必看项，它比单纯的利用率更能解释性能问题；第三，ECC 和 PCIe 链路要定期查，这两类问题平时无感，一旦爆发就是训练结果出错或性能腰斩。监控做得好，GPU 服务器的大多数故障都能在业务受影响之前被发现。

本文命令基于 NVIDIA 数据中心驱动（Tesla/Data Center 系列）环境，消费级显卡部分字段（如 ECC、MIG、页退役）可能不可用或显示为 N/A。