显存没释放不是显卡坏了：先分清「真占用」和「残进程虚占」
nvidia-smi 显示显存被占了好几 G，但进程列表里看不到程序 —— 这是上个任务异常退出（崩溃或被强杀）后 CUDA context 没归还留下的「虚占」。它和「真显存不足」的处置完全相反：真不足要降负载，虚占要杀残进程或重启服务。判据只有一条：nvidia-smi 的进程列表里那部分占用到底有没有 PID。
显存排错多卡GPU性能测试这条适用于
- 多卡机器（本机为 4×DGX Spark 共享集群）
- 任务曾被中断 / 进程刚退出
版本指纹
本机 4×DGX Spark；驱动对 context 释放行为随版本不同
具体做法
# ① 看真相：显存占用到底有没有 PID
$ nvidia-smi
# 正常占用：进程列表里有 PID + 进程名 + 占用 MiB
# 虚占：显存 Used 不为 0，但 Processes 列表为空 / 写 No running processes found# ② 多卡机器：确认自己用的是哪张卡
$ nvidia-smi -L # 列出所有卡
$ echo $CUDA_VISIBLE_DEVICES # 看当前暴露了哪张（空 = 全部可见）# ③ Linux：按 GPU 找占用进程并杀掉
$ fuser -v /dev/nvidia* # 列出占用 /dev/nvidia* 的进程
$ nvidia-smi | grep <pid> # 确认是哪个进程
$ kill -9 <pid> # 确认后再杀（别盲杀不认识的服务进程）# ④ 只暴露某一张卡跑任务（推荐做法，别裸跑）
$ CUDA_VISIBLE_DEVICES=1 python infer.py
$ CUDA_VISIBLE_DEVICES=1 vllm serve <model> --port 8001失效边界
适用边界：本例来自本机 4×DGX Spark 共享集群，任务被中断后显存残留。不同驱动版本对 context 释放的行为不一致，有的驱动在进程退出后 1~2 分钟内会自动回收，表现为「等一会儿就好了」——所以看到占用先别急着重启。多卡机器另有一个高发误判：程序默认只吃第 0 张卡，你以为在跑第 2 张，实际全挤在第 0 张，看起来像「其它卡被占」实则是自己占错了卡。以上均为本机实测口径，换环境请以 nvidia-smi 的真实输出为准。
适用边界：本例来自本机 4×DGX Spark 共享集群，任务被中断后显存残留。不同驱动版本对 context 释放的行为不一致，有的驱动在进程退出后 1~2 分钟内会自动回收，表现为「等一会儿就好了」——所以看到占用先别急着重启。多卡机器另有一个高发误判：程序默认只吃第 0 张卡，你以为在跑第 2 张，实际全挤在第 0 张，看起来像「其它卡被占」实则是自己占错了卡。以上均为本机实测口径，换环境请以 nvidia-smi 的真实输出为准。