查看服务器GPU使用情况，最直接的办法是登录终端运行 nvidia-smi，先看每张卡的利用率、显存、温度和进程；要长期看趋势，再上 gpustat、DCGM Exporter 或云监控。 这条命令不需要额外部署，多数情况下能帮你快速判断是GPU在忙、显存快满，还是进程已经卡住，下面按“先排障、再监控、后定位”的顺序，把具体命令和常见坑讲清楚。
先判断需求：瞬时排障还是长期监控
登录服务器排查训练任务卡顿,和运维团队盯着几十张卡看趋势，是两件事，前者追求快，敲一条命令就能看到结果；后者追求可追溯，需要采样、存储、告警和看板。
- 临时看一眼：直接运行
nvidia-smi，关注GPU-Util、Memory-Usage、Temp、Power和底部进程列表。 - 持续刷新：用
watch -n 1 nvidia-smi，或者nvidia-smi -l 1，按秒刷新。 - 只取关键字段：用
nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw --format=csv -l 5，适合复制到表格或接入脚本。 - 按进程看：用
nvidia-smi pmon -c 1，能快速看到哪个PID在占卡。
| 指标 | 含义 | 常见异常信号 |
|---|---|---|
| GPU-Util | 计算单元利用率 | 长期为0但显存高，可能是进程空闲或显存未释放 |
| Memory-Usage | 显存已用/总量 | 接近上限时，新任务容易OOM |
| Temp / Power | 温度和功耗 | 温度持续偏高、功耗异常波动，要查散热和负载 |
| Processes | 占用GPU的进程 | 找不到业务进程却占卡，需排查残留或容器 |
NVIDIA官方文档对 nvidia-smi 字段有明确说明，先看懂这几个字段，比一上来装一堆监控工具更有效。
Linux服务器GPU占用率怎么查看：从一条命令到可复用脚本
nvidia-smi 的三种常用看法
第一种是直接运行,适合SSH登录后快速判断，第二种是循环刷新，适合盯训练任务启动阶段，第三种是结构化输出，适合写脚本或做巡检。
nvidia-smi watch -n 1 nvidia-smi nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total --format=csv -l 5
如果你只关心进程,可以加一条：
nvidia-smi pmon -c 1
多卡机器不要只看第一张卡。nvidia-smi 顶部会按GPU编号列出每张卡，训练任务可能只用了其中几张，显存快满时，GPU-Util 仍可能忽高忽低，这时要结合进程和业务日志判断。
容器、多卡和远程登录怎么处理
远程登录本身不影响查看,关键是命令要在有NVIDIA驱动的环境里执行，容器内查看时，先确认容器能访问GPU：
docker exec -it 容器名 nvidia-smi
如果容器里没有这条命令,通常是镜像没装驱动工具，或者启动时没加 --gpus 相关参数，Kubernetes环境可以先用 kubectl describe node 节点名 | grep nvidia.com/gpu 看GPU资源分配，再看Pod是否真正拿到卡，多卡任务还可以用 CUDA_VISIBLE_DEVICES 限制可见卡号，避免程序把整机卡都扫一遍。
MIG场景下,nvidia-smi -L 可以列出MIG设备，此时看到的是切片后的实例，不要拿整卡指标直接套用。
nvidia-smi和gpustat哪个好用：对比维度与选择建议
gpustat 是对 nvidia-smi 的可读性封装，安装方式通常是 pip install gpustat，运行 gpustat -i 1 可以按秒刷新，它把用户、进程和显存信息排得更紧凑，适合多人共用一台GPU服务器时快速看“谁在占卡”。
| 对比项 | nvidia-smi | gpustat |
|---|---|---|
| 安装 | 驱动自带，通常无需额外安装 | 需要Python环境，pip安装 |
| 字段完整度 | 全，支持查询、拓扑、ECC等 | 常用字段集中展示，够日常看 |
| 可读性 | 信息密，需要熟悉字段 | 进程和用户更直观 |
| 适合场景 | 排障、脚本、深度查询 | 多人共享、快速巡检 |
结论很直接：排障和写脚本优先用 nvidia-smi，日常多人看卡用 gpustat 更顺手。 两者不是替代关系，可以同时装。
云服务器GPU使用情况怎么监控：宿主机与容器两条线
云服务器GPU使用情况怎么监控：控制台、Agent与Prometheus
云服务器上,控制台通常能看GPU利用率、显存和温度趋势，但采集粒度、字段和延迟因厂商而异，想看得细，还是要在实例里装Agent或部署DCGM Exporter。
- 控制台：适合看整体趋势和基础告警，排查时仍要进机器跑
nvidia-smi。 - DCGM Exporter：暴露GPU指标，常配合Prometheus抓取，默认端口常见为
9400。 - Grafana看板：把
DCGM_FI_DEV_GPU_UTIL、DCGM_FI_DEV_FB_USED、DCGM_FI_DEV_GPU_TEMP等指标画成趋势图。 - 告警：显存接近上限、温度持续偏高、Xid错误出现时触发通知。
行业共识认为,多机多卡场景更适合用Prometheus这类时序监控做长期趋势，而不是靠人工反复敲命令，容器环境还要确认Exporter能访问到GPU设备，否则看板会是空的。
北京服务器GPU监控工具收费吗：自建与商业方案的成本边界
北京机房和云上区域的收费逻辑差别不大,商业监控工具通常按GPU卡数、节点数或年费计费，具体以厂商报价为准，开源方案没有License费用，但需要投入部署和运维人力。
| 方案 | 成本构成 | 适合场景 |
|---|---|---|
只用 nvidia-smi |
零工具成本 | 单机、临时排障 |
| 自建Prometheus + DCGM Exporter | 服务器资源、人力、维护 | 多机多卡、长期趋势 |
| 商业监控平台 | 按节点/GPU/年收费 | 希望少运维、要现成告警 |
如果只是偶尔查看,没必要为“北京服务器GPU监控工具收费吗”这个问题纠结，直接用系统命令成本最低，跨地域采集时要注意网络延迟和带宽，监控数据不必传回办公网再存，放在靠近机房的对象存储或时序库里更稳。
把GPU使用情况看明白：指标、进程和日志怎么串起来
指标不要只看利用率
GPU-Util 高不代表一定在有效计算，显存泄漏也不一定立刻把利用率拉满，业内专家指出，GPU监控不能只看利用率一个数字，显存、温度、进程和Xid错误要一起看。
- 显存趋势：连续观察
memory.used，比单次快照更容易发现泄漏。 - 温度与功耗：异常升高时先查散热、风道和机箱环境。
- ECC与Xid：用
nvidia-smi -q | grep -i ecc和dmesg | grep -i nvidia查硬件和驱动层报错。 - 拓扑：多卡训练可用
nvidia-smi topo -m看卡间互联，避免把跨NUMA通信问题误判成GPU瓶颈。
进程和日志怎么查
看到显存被占但找不到业务进程,可以按下面顺序查：
nvidia-smi pmon -c 1看GPU上的PID。ps -ef | grep 进程名确认进程状态。fuser -v /dev/nvidia查哪些进程打开了GPU设备。dmesg | grep -i nvidia查驱动加载和Xid报错。lspci | grep -i nvidia确认系统是否识别到卡。
非NVIDIA环境也有对应工具：AMD用 rocm-smi，Intel集显或独显可用 intel_gpu_top，工具不同，思路一样：先确认设备识别，再看利用率和进程。
把命令用对,比装一堆工具更重要。日常排障靠 nvidia-smi 和进程日志，长期监控靠DCGM Exporter加时序库，两条线配合才不容易误判。
怎么查看服务器GPU使用情况：常见问题解答
没有nvidia-smi命令怎么办
先确认是不是NVIDIA GPU，用 lspci | grep -i nvidia 看系统是否识别到设备，再用 lsmod | grep nvidia 看驱动是否加载，命令存在但报错，多半是驱动版本和内核不匹配，容器内没有该命令，通常是镜像未包含驱动工具，或启动时未正确映射GPU设备。
GPU-Util为0但显存占用高，正常吗
可能正常,模型加载后处于空闲等待、框架缓存未释放、进程挂起，都会出现利用率低但显存高，先看 nvidia-smi pmon 里的进程是否还在，再结合业务日志判断，不要直接重置GPU，先确认没有训练任务在跑。
云服务器控制台和卡端数据不一致，看哪个
以卡端 nvidia-smi 或DCGM采集结果为准，控制台受Agent状态、采集间隔和聚合逻辑影响，适合看趋势，不适合做秒级排障，两边差异持续存在时，优先检查实例内监控Agent是否正常上报。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793825.html
