从nvidia-smi到gpustat：GPU显存与进程监控的实用指南

1. 为什么我放弃裸用nvidia-smi，改用gpustat盯着GPU

做深度学习或高性能计算的同学都清楚，nvidia-smi几乎是装机标配。但我不清楚你们怎么想，至少我自己在排查显存占用、进程异常、多卡利用率不均这些问题时，每次对着nvidia-smi的满屏输出都觉得很费劲：信息确实全，但太密了，权限信息、温度、功耗、编码器利用率这些指标在大部分场景下我根本不关心，真正想看的其实是几件事——每张卡显存还有多少、占用率拉满没有、是哪个用户哪个进程在跑，以及有没有陷入大家都停下来等我释放显存的尴尬局面。

后来我接触了gpustat，第一反应是这工具太小巧了。它不是要取代nvidia-smi，而是把最核心的GPU运行状态按一种更接近人类阅读习惯的方式重新排版。简单说，同样是打开终端扫一眼，nvidia-smi让我需要花几秒钟在脑子里重新组织信息，gpustat则直接告诉我答案。下面这张表是我日常用得最多的功能对比，能很直观看出两者的差异：

这里要说明，gpustat的核心数据仍然通过NVIDIA官方工具链拿到的，它并不会凭空多出什么监测指标。它在做的，是重新定义展示层。它内部调用的是pynvml（NVIDIA管理库的Python绑定），然后对结果做过滤、排序、配色。所以如果你已经有nvidia-smi能用，gpustat基本可以安心装；如果你连nvidia-smi都跑不起来，那问题通常是显卡驱动或NVML库层面，而不是gpustat的问题。

这篇说明我打算从安装开始，把常用的命令组合、实时监控方案、多卡服务器场景和几个在真实环境中容易踩的坑一次讲透。不管你是装了双系统还没配好环境的入门用户，还是负责实验室多卡服务器运维的老手，这篇都能给你一个相对完整的参考。

2. 安装方式与依赖说明：pip是主路径，其他方式尽量靠后

2.1 最直接的pip安装方式

在Ubuntu环境里，安装gpustat最省心的方式是通过pip，官方推荐的命令如下：

bash复制pip install gpustat

如果你用的是Ubuntu 22.04或更新版本，系统自带的Python环境可能被PEP 668约束，直接pip install会遇到类似error: externally-managed-environment的报错。这种情况下有三个选择：

bash复制# 方案1：使用pipx，隔离环境，推荐日常使用
pipx install gpustat

# 方案2：给当前用户单独装
pip install --user gpustat

# 方案3：如果你坚持用系统pip（不推荐），需要加--break-system-packages
pip install gpustat --break-system-packages

我自己的习惯是，如果只是临时想在服务器上看两眼GPU状态，又不想污染系统Python环境，就用pipx；如果恰好已经在用conda管理环境，那就直接放到base环境里。下面这两种都是比较常见的路径：

bash复制conda install -c conda-forge gpustat

或者在你的conda环境内执行：

bash复制pip install gpustat

需要提醒一下，conda install的包版本通常比PyPI慢半拍。gpustat本身更新并不频繁，这个差异一般不会带来问题，但如果你遇到某些奇怪的显示bug，优先试试升级到PyPI最新版。

2.2 千万别用apt源硬装

在Ubuntu上，有人习惯所有工具一律apt install。gpustat其实也被部分Ubuntu发行版的软件源收录了，但你通过apt install gpustat能装到的版本通常比较老，而gpustat早期版本在不同NVML版本的兼容性上是有坑的。你要是装上以后发现输出格式跟网上教程对不上，或者某些参数不支持，十有八九是版本太旧。

从实用角度看，我强烈建议统一走pip或conda路线。不仅版本新，而且卸载也干净，不会跟系统包管理器产生纠缠。

2.3 依赖项到底装了些什么

执行pip install gpustat以后，Python会顺带安装几个核心依赖：

• nvidia-ml-py（或较老版本中的pynvml）：这是和NVIDIA驱动管理的NVML库通信的桥梁，gpustat读取显存、利用率、温度、进程列表全靠它。
• psutil：用来读取本机CPU利用率和进程归属用户信息。
• termcolor 或类似的排版库：负责终端彩色输出。
• six：部分版本需要，兼容Python 2/3差异用。

很多人在使用时遇到ModuleNotFoundError: No module named 'pynvml'这类报错，就是因为这些依赖在安装过程中被跳过，或者因为用了--no-deps参数强制不装依赖。正常安装时基本不会遇到，但如果你习惯在已有环境里手动管理包，这点需要特别留意。

2.4 安装完成后先做一次最小验证

装完后第一次运行，建议不要加任何参数，先跑一次最小命令验证底层链路是不是通的：

bash复制gpustat

正常情况下，你会看到类似下面这样的一段输出：

code复制ubuntu-2040        Sun Jul 21 15:30:01 2025
[0] NVIDIA GeForce RTX 3090 | 50'C,  95 % |  10239 / 24576 MB | user1 python: 10239 MB

如果终端支持彩色输出，利用率、温度、显存这些字段会配不同颜色：负载较低偏绿色，负载接近满载偏红色。这个排版信息密度比nvidia-smi高很多，一眼就能看出有没有人卡着显存不放手。

如果运行后报错，请先检查nvidia-smi是否能正常执行。如果在Ubuntu里nvidia-smi本身都无法显示，那问题不在gpustat，而是需要回头排查显卡驱动安装。这在前面的相关热词里也是我看到的高频问题，比如很多人装完Ubuntu后直接去装了个桌面环境，却漏了NVIDIA驱动，或者在UEFI安全启动打开的情况下驱动模块没被正确签名加载。

3. 命令参数深度拆解：从只显示一行到完整现场还原

gpustat的魅力在于参数一眼能看明白，没有复杂的分段子命令。你只需要掌握它的主命令和几个开关，就能应对大多数监控场景。

3.1 最常用的-c和-p：一眼看出有没有人在摸鱼

一次运行gpustat默认只输出进程名称和显存占用，但排查问题的时候，光看到python是不够的，你得知道这个python进程是谁的、哪台机器连过来的、在跑什么任务。这时候把-c和-p组合起来是最有价值的：

bash复制gpustat -cp

其中：

• -c：显示每个GPU上的命令行信息（command）。
• -p：显示进程ID（PID），也就是进程号。

输出会变成类似这样：

code复制[0] NVIDIA GeForce RTX 3090 | 50'C,  95 % |  10239 / 24576 MB | user1/10235 python train.py --batch_size=32

看到user1/10235 python train.py --batch_size=32，你就能当场判断是谁的脚本、大致在跑什么逻辑。不需要再额外执行ps -ef | grep python去反查。如果机器是多人共用的，这一步可以帮你少走很多冤枉路。

值得注意的是，-c在某些情况下可能会看到比较长的命令行，比如跑的是python -m torch.distributed.launch --nproc_per_node=4 train.py这类命令，gpustat在显示时如果截断不够友好，长命令会把单行输出撑得很宽。遇到这种场景我一般改用gpustat -cp -i 2实时轮询，或者在命令行本身不那么长的时候才加-c。

3.2 -u：按用户维度看显存占用

如果你想快速判断某个用户是否同时占用了多张卡的全部显存，用-u可以让每个进程前面带上当前用户的名称：

bash复制gpustat -u

这对多人共用服务器、每次分配卡位都要靠人工协调的场景特别有用。比如你看到alice在0号和1号卡上开了两个显存占满的进程，同时bob在2号卡上也有任务，你就能判断要不要去群里喊一声让某个人限速。

另外，-u和-p组合使用，配合Linux的id命令，还能快速反查某个PID对应的具体启动方式，边界情况排查时效率很高。

3.3 完整现场参数-a：相当于给nvidia-smi做了一次瘦身

如果你需要看到更全面的显卡信息，可以直接用：

bash复制gpustat -a

该参数会额外展示温度和利用率以外的一些信息，比如功耗、风扇转速等。但坦白说，gpustat的强项不在这些细节指标。真正要看功耗曲线、温度变化趋势时，我仍然会回去用nvidia-smi dmon或nvtop。gpustat -a的价值更多像一个中间档：已经比默认显示信息全面，又不像nvidia-smi那样堆得密密麻麻。

3.4 --no-color与JSON输出带来的自动化可能

假如你准备把gpustat嵌入到自动化脚本里，比如定期巡检显存占用然后通知管理员，那么彩色输出反而是累赘。这时可以关闭颜色：

bash复制gpustat --no-color

如果你用的是支持JSON的新版本gpustat，还可以尝试：

bash复制gpustat --json

这个参数会输出结构化数据，方便你后续用jq或Python去处理。我看到有些团队把gpustat --json的数据采集到监控系统里，定时采集每张卡的显存余量和利用率，用于绘制历史趋势图。这一步其实比裸用nvidia-smi --query-gpu更方便，因为gpustat已经把格式整理得相对规整了。

3.5 --watch参数：实现简易版实时刷新

很多教程会推荐用watch -n 1 gpustat来做实时刷新，gpustat本身也提供了一个时延刷新内部包装：

bash复制gpustat --watch

这个指令等价于每1秒自动刷新一次。如果你希望调整刷新频率，可以用-i参数：

bash复制gpustat -i 2

这里的数字单位是秒。我个人实测下来，训练模型的过程中用-i 2看刷新就够了，-i 1会显得有点闪眼，而且徒增无谓的NVML调用。对于负载快速变化的推理服务压测场景，-i 0.5也可以尝试，但注意某些终端对高频刷新支持得并不好，可能出现光标跳动导致输出错乱。

4. 与watch命令结合的实时监控方案：精确到你能看清每次显存波动

4.1 为什么要把watch和gpustat放在一起说

虽然gpustat自带--watch，但是懂Linux的老手还是会选择用watch命令来包裹它。最大的原因在于：watch能稳定显示一个持续更新的终端界面，并且在顶部显示两条关键信息——刷新间隔和当前时间。这两条信息在你截图发群里、排查训练中断问题时非常有用。

bash复制watch -n 2 gpustat -cp

解释一下这条命令：

• watch：Linux自带工具，会定期执行后面的命令并全屏刷新。
• -n 2：每2秒刷新一次。
• gpustat -cp：显示进程命令行和PID。

执行后，整个终端会固定在一个界面里，CPU使用率、GPU负载、显存占用每两秒更新一次，不会像普通命令那样疯狂滚动刷屏。

4.2 利用watch的-d参数观察变化

相比普通刷新，我特别推荐watch的差异高亮功能：

bash复制watch -n 2 -d gpustat -cp

加上-d（difference）后，每次刷新，watch会高亮显示自上一次刷新以来发生变化的行。比如某个进程占用的显存从10000MB涨到了10080MB，这个变化数值会高亮显示。在观察模型训练时显存占用是否稳定、有没有内存泄漏的场景里，这个功能比单纯盯着数字逐秒看更高效。

4.3 利用-t隐藏标题，让终端更干净

watch默认在顶部展示刷新命令、当前时间、主机名。如果你在一个干净整洁的终端里同时开多个watch窗口，比如左边看GPU、右边看CPU，那顶部标题栏全挤在一起会很乱。这时可以试试：

bash复制watch -n 2 -t gpustat

-t会隐藏watch自带的标题栏，屏幕完全被gpustat输出占据，监控起来更清爽。

4.4 Ctrl+C退出与进程终止的注意事项

使用watch模式时，要退出实时监控，直接按Ctrl+C即可。但这里有一个小坑：如果你用watch -n 1 gpustat跑了几分钟后，按Ctrl+C退出，有些旧版watch的进程清理并不彻底，终端可能残留一些异常光标状态。这时候输入reset可以恢复终端正常显示。

另一个常被忽略的点是，如果你在监控过程中发现某个进程占用了大量显存需要清理，千万不要直接照着gpustat输出的PID用kill -9一股脑杀掉，尤其是那些训练到一半的进程。最好先确认进程归属，是别人正在跑的任务还是已经僵死的进程，再决定处理方案。

5. 多卡服务器实战：如何快速找出占卡凶手

5.1 不装任何额外工具，用gpustat解决“我的卡去哪了”

4卡、8卡GPU服务器是实验室和中小型公司的标配。每次有人喊“为什么我的程序申请不到显存”，通常不是真的没有显存，而是某张卡被占满、别的卡又有剩余，程序分布调度时不够均匀或者分配策略有问题。

在这种场景下，我拿到一台陌生服务器后的排查顺序是：

1. 先执行nvidia-smi确认显卡总数和驱动状态。
2. 再执行gpustat看简洁视图，确认每张卡的显存占用情况。
3. 如果发现有卡显存几乎占满但利用率很低，马上用gpustat -cp查看到底是什么进程在占用。
4. 如果进程归属于其他用户，我一般先看是不是对方忘了释放显存。多次刷新后如果进程仍然是僵尸状态，再联系管理员处理。

这一套流程，熟练之后10秒内就能得出结论。换成以前使用nvidia-smi时，要在那一大屏输出里定位到哪张卡被谁占满，眼睛得来回扫好几趟。

5.2 配合nvtop作为补充，但gpustat依然是快速判断的首选

有人会问：既然都上多卡服务器了，是不是直接上nvtop更全面？这里我根据经验说句公道话。nvtop安装起来会比gpustat复杂一点，需要添加额外的源或自己编译，界面也走的是类htop的图形化风格，适合长期挂在终端看。但如果只是想快速执行一个命令、把状态甩到群里，gpustat的纯文本输出无疑更方便。

要是你想长期盯着，也可以两个都用：

• 短时间判断：gpustat。
• 长时间观察温度、功耗曲线：nvtop或nvidia-smi dmon。
• 跑实验前确认所有卡状态正常：gpustat。
• 排查驱动或硬件故障：nvidia-smi -q -d TEMPERATURE这类命令更详细。

5.3 如何在Docker容器里使用gpustat

不少训练任务跑在Docker容器里，容器内能否使用gpustat取决于NVIDIA Container Toolkit是否配置好。如果你在宿主机上能正常执行nvidia-smi，但容器内执行gpustat时报找不到NVML库或无法访问设备，通常不是gpustat的问题，而是启动容器时没有挂载GPU或者缺失--gpus all参数。

正确的启动方式类似：

bash复制docker run --gpus all -it --rm nvcr.io/nvidia/pytorch:24.01-py3 bash

容器内再安装：

bash复制pip install gpustat
gpustat

这里我踩过一个大坑：即使加了--gpus all，容器内也可能缺少NVIDIA驱动用户态库的路径映射，尤其是一些精简基础镜像。正常的深度学习镜像通常已经包含了/usr/lib/x86_64-linux-gnu/libnvidia-ml.so，如果你缺这个库，就需要在启动容器时把宿主机的NVIDIA库目录挂载进去，或者直接换官方提供的NGC镜像，不建议在精简容器里跟NVML库纠缠。

5.4 远程连接时不方便实时交互的替代方案

有时你通过SSH登录服务器，网络不稳定，跑watch模式会断断续续。这种时候我用的方法是把gpustat输出重定向到文件：

bash复制gpustat -cp --no-color > gpu_status.txt

然后随时用cat gpu_status.txt查看。如果你想定时记录GPU状态供后续分析，可以配合cron或写一个简单的循环脚本：

bash复制while true; do date >> gpu_usage.log; gpustat --no-color >> gpu_usage.log; sleep 60; done

这个脚本记录出的log配合awk、grep就能统计出某个时间段内的平均显存占用率，对分析训练任务的资源利用效率很有帮助。

6. 常见报错排查记录

6.1 执行gpustat时报NVML: Driver/library version mismatch

这应该是我见过最多的一个报错。出现这段提示，本质上是NVIDIA驱动内核模块加载的版本和用户态NVML库版本不一致。一般在Ubuntu系统升级内核、NVIDIA驱动升级不完整，或者重启后驱动没有正确加载时出现。

排查步骤：

bash复制# 检查内核模块版本
cat /proc/driver/nvidia/version

# 检查用户态驱动工具版本
nvidia-smi

如果nvidia-smi也报同样错误，那就确认是驱动层问题。此时最简单的方法是重启机器，让驱动模块重新加载。如果是远程服务器不方便重启，可以去查一下lsmod | grep nvidia，把残留的旧内核模块卸载后再重新加载，不过操作有风险，建议在了解Linux内核模块机制的前提下进行。

gpustat在这里只是个受害者，它调用NVML失败就会透出这个错误提示，千万别误以为gpustat坏了。

6.2 无GPU环境或未安装NVIDIA驱动时报No NVIDIA GPU detected

如果你的机器本身没有NVIDIA显卡，或者用的是AMD显卡，以及部分通过云平台创建的CPU实例，执行gpustat输出可能会是空的或者只显示一个空列表。

正常有GPU的机器上，第一行输出会包含类似[0] NVIDIA GeForce RTX 3090的设备列表。如果输出中完全没有设备信息，先运行nvidia-smi确认系统层面是否识别到GPU。若nvidia-smi能看到但gpustat看不到，大概率是权限或者NVML库路径的问题。

有个小场景值得说一下：在部分云服务器上，如果你用了NVIDIA vGPU或MIG功能，gpustat显示的逻辑设备数量和你物理卡数量不一定对得上。这种虚拟化场景下，最好以nvidia-smi输出的显存总量和计算实例编号为准。

6.3 权限不足导致看不到其他用户的进程

默认情况下，如果你不是root用户，而且系统的/proc权限做了严格限制，gpustat可能无法获取到其他用户进程的详细信息。此时你会看到类似：

code复制[0] NVIDIA GeForce RTX 3090 | 60'C,  80 % | 12000 / 24576 MB | user1/1234 python

有些信息可能会被隐藏，或者PID查询失败。这种情况可以通过sudo执行：

bash复制sudo gpustat -cp

但使用sudo要谨慎，因为这会让你能查看到服务器上所有用户的进程命令行，如果机器上有严格遵守隐私策略的约束，需要注意操作合规性。更多时候，普通用户模式下能看到显存占用、用户名称和PID已经足够判断问题，并没有必要强行获取其他人的完整命令行。

6.4 终端中文乱码或字符对齐问题

gpustat默认输出里有一些特殊字符用来区分GPU编号和状态，在部分SSH客户端或浅色背景下可能显示错位，甚至会因为字符宽度计算不对而出现对不齐的情况。遇到这种问题，最简单的方法是加上--no-color或者强制终端使用UTF-8编码。

bash复制gpustat --no-color

大多数情况下，这只影响观感，不影响实际数据读取。但如果你打算把输出拷贝到文档或聊天工具里，--no-color能保证不出现颜色转义序列干扰。

6.5 装了gpustat后执行命令却提示找不到

这种情况通常是因为pip安装路径不在当前用户的环境变量里。Ubuntu上如果用了--user安装，可执行文件会出现在~/.local/bin，你需要确认这个目录在PATH中：

bash复制export PATH=$PATH:~/.local/bin

如果要一劳永逸，可以把这行写入~/.bashrc或者~/.zshrc。也可以用which gpustat查看具体的可执行文件路径，排查是不是被某个conda环境遮蔽了。多环境混用的用户一定要留意：在conda环境内外切换时，gpustat可能指向不同Python环境下安装的版本，如果你看到的输出和预期不一样，先执行which gpustat。

7. 扩展玩法：让gpustat真正融入你的日常操作

7.1 写在shell配置里的别名

我见过不少用户整天敲gpustat -cp，其实一行别名就能帮你省下每次重复输入的麻烦。个人比较推荐在自己的shell配置文件中加入以下内容：

bash复制alias gpu='gpustat -cp'
alias gpuw='watch -n 2 gpustat -cp'

把它追加到~/.bashrc或~/.zshrc末尾后，执行：

bash复制source ~/.bashrc

之后输入gpu即可快速查看GPU进程，输入gpuw即可进入实时监控模式。如果这些别名不够通用，你可以按照自己的习惯来，比如只在某个特定项目目录下启用别名，或者定义成带参数的shell函数。

7.2 用gpustat辅助编写任务调度脚本

在自动化训练脚本里，有时候需要判断当前是否有空闲GPU，然后自动分配任务到空闲卡。虽然gpustat本身不做调度，但它的输出经过清洗后可以作为判断依据：

bash复制gpustat --no-color | awk '{print $NF}' | grep -o '[0-9]*' 

这个管道命令能抽取显存使用数值，不过直接解析文本总是不太优雅。更专业一点的做法是使用gpustat --json输出后用Python解析，根据可用显存大小给任务指派GPU。这类脚本我在实际工作中确实也写过，你会发现：一旦喂给程序的数据是标准JSON，后面能做的东西就多了——自动分配、自动告警、自动续跑都可以串起来。

7.3 监控多台远程节点的GPU

我们实验室偶尔有需要查看多台机器上GPU状态的情况。长期用SSH逐台登录太累了，简单方案是写一个循环脚本，通过SSH在每台机器上执行gpustat并逐台打印：

bash复制for host in node1 node2 node3; do
    echo "==== $host ===="
    ssh $host "gpustat --no-color"
done

更复杂的做法是使用gpustat-web这类工具把多台机器汇总到浏览器页面。不过这类工具需要额外配置一个小服务，如果只是临时排查，我更推荐前面这个循环脚本，简单可靠，没有额外端口暴露的风险。

7.4 结合cron做定时巡检告警

GPU卡死、显存泄漏在长周期训练里很常见。你可以把下面这样一段脚本放到crontab中，每天定时巡检并写日志：

bash复制#!/bin/bash
GPUSTAT_OUTPUT=$(gpustat --no-color)
echo "$(date) $GPUSTAT_OUTPUT" >> /var/log/gpu_usage.log

如果机器配了邮件发送服务，还可以在显存占用率超过阈值时用mail或curl通知自己。这类周期巡检逻辑不值钱，但真的能帮你省下不少半夜爬起来看训练状态的时间。

8. Ubuntu下查看显卡驱动状态与gpustat之间的重叠

8.1 先解决驱动再谈监控

从相关热搜词里也能看到，“ubuntu查看显卡驱动”是很多用户搜索的高频问题。如果你是因为驱动没装好，才想通过gpustat确认GPU状态，我建议先回到驱动本身。

查看Ubuntu下NVIDIA驱动是否正常，最标准的命令是：

bash复制nvidia-smi

如果提示没有该命令，说明驱动没装或未正确安装。还可以通过dkms状态查看驱动模块：

bash复制dkms status

gpustat作为一个NVML上层应用，能够正常运行的前提就是驱动层已经通过nvidia-smi验证。很多用户装好驱动后习惯直接执行gpustat，一旦报错就以为是gpustat没装好，其实还是驱动或权限问题。

8.2 如何才能确保gpustat看到的和nvidia-smi一致

有些人会发现，在对同一张卡执行gpustat和nvidia-smi后，显存占用数值居然差了几十MB。这不是bug，而是两者取样的时刻不同。显存数据每时每刻都在波动，尤其存在多个进程并行申请释放显存的情况下，先后两次查询结果有差异是非常正常的。真正判断是否一致的维度应该是：显卡型号、显存总量、GPU利用率这几个相对稳定的指标。

有人在多进程场景下，还会发现gpustat显示的进程“似乎少了”，这是因为gpustat默认只显示当前用户有权限读取的进程，而nvidia-smi则能展示GPU上所有进程。此时可以尝试用sudo gpustat重新查看，应该就和nvidia-smi的进程列表对得上了。

8.3 从热词里看到的Ubuntu环境配置杂谈

结合Ubuntu相关的热门搜索，比如“ubuntu安装nvidia显卡驱动”、“ubuntu双系统安装”、“ubuntu换源”这些关键词，我能感觉到使用gpustat的群体里有相当一部分是和深度学习、机器学习相关的开发者。这群人通常在Ubuntu上配置驱动花费的时间比实际写代码更多。

在这个背景下，我推荐装好系统后尽早做两件事：一是配置好合适的软件源，避免后续安装包下载无比缓慢；二是确认显卡驱动的安装方式，建议用官方提供的runfile或者通过ubuntu-drivers工具安装，不要为了省事随便用一个PPA源，否则后续升级系统包时驱动损坏的概率会增加。驱动一旦稳定，gnome桌面、输入法等细节问题就按下不表了，跑起训练再来执行这行命令：

bash复制gpustat

你看到输出的瞬间，会感觉前面折腾Ubuntu环境都值了。

9. 几个必须反复强调的实战习惯

看到这里，gpustat的基本使用和常见坑位已经覆盖得差不多了。最后这部分内容不是命令，而是我在真实环境里使用多年后沉淀下来的几个直觉性习惯。

第一，不要把gpustat当成完整的性能分析工具。它适合快速判断显存和利用率状态，但如果你要诊断CUDA OOM的具体原因、查看GPU的SM占用率、显存带宽、PCIe吞吐量，这些都已经超出gpustat的能力边界。遇到这类深层次问题，老老实实去用nvidia-smi的查询模式或专业的性能分析工具，不要硬用一个简单工具解决所有复杂问题。

第二，在多人共用的GPU服务器上，尽量用gpustat -cp而不是裸gpustat。只有看到进程的PID和命令行，你才能明确知道某个进程是否还活着，以及它到底属于什么任务。如果某张卡显存占满但利用率一直为0，多半是进程已经变成无法正常退出的状态，用ps -ef | grep <PID>查一下后按实际情况处理。

第三，脚本里解析gpustat输出时，能用--json就别用文本正则。文本解析看着简单，但gpustat的后续版本一旦调整了显示格式，你的解析代码可能马上就废了。用JSON格式，至少字段是稳定且有语义的。

第四，如果要监控长期趋势，就一定要给输出打时间戳。单次执行gpustat看到的是一个瞬时快照，时间戳能帮你判断这个状态是什么时候留下的，尤其在分析夜间训练失败原因时，时间点几乎是最重要的第一线索。

我在实际使用中还有个体会，就是学会看gpustat输出的“负载率+显存余量”这两个指标的组合，基本能猜出训练是否健康。比如GPU利用率为99%但显存始终充裕，说明模型的计算密集程度高于显存需求，训练进度通常稳定；如果显存缓慢增长而利用率越来越低，就要开始怀疑是否存在内存泄漏或者是数据加载管线卡住了。这套判断思路配合gpustat的极低使用成本，几乎不会给你的工作流带来额外负担，却能帮你省下大量定位问题的时间。

工具只是入口，真正的价值在于用它建立对GPU服务器运行状态的敏感度。很多时候，我看到群里发来一句“我的训练挂了”，第一反应不是到处翻日志，而是请求对方先跑一下gpustat -cp，确认此刻的显存和进程全局情况。这种快速定位问题的习惯，值得每个人在使用gpustat的过程中慢慢养成。