先找到占显存的是谁
服务报显存不足、或者显存占用与业务量对不上账时，第一步不是重启，而是列出当前占用显存的进程。默认的进程表信息有限，容器场景下进程名会显示成宿主上的可执行文件路径，直接看容易一头雾水。改用结构化查询拿到进程号与占用数值，再回查进程归属与启动命令，才能判断能不能动它。
列出占用进程
列出占用进程
# 结构化输出：进程号、进程名与占用显存
nvidia-smi --query-compute-apps=pid,process_name,used_memory,gpu_uuid --format=csv
# 回查进程归属与启动命令，判断是哪个服务
ps -o user,pid,etime,cmd -p <PID>
# 用设备文件反查（Linux）：谁打开了这块卡
fuser -v /dev/nvidia* 2>/dev/null
# 容器场景：按容器过滤，确认是哪个容器里的进程
docker ps --format '{{.ID}} {{.Names}}'字段读法
| 字段 | 含义 | 用途 |
|---|---|---|
| pid | 宿主视角的进程号 | 回查属主、启动命令与启动时间 |
| process_name | 可执行文件名或路径 | 容器内进程会显示为宿主上的路径 |
| used_memory | 该进程占用的显存 | 判断谁是大头，决定先动谁 |
| gpu_uuid | 所属卡的唯一标识 | 多卡机器上按卡核对，避免看错设备 |
典型使用场景
- 排查显存不足：确认是业务进程吃满了显存，还是别的进程占了坑
- 服务启动失败：目标卡上仍有残留进程占用显存，启动时分配不到空间
- 多实例共卡：核对每个实例的实际占用，按数据调整各自的显存预算
- 训练与推理混部：确认训练任务是否还在跑，避免互相挤占
- 深夜排查：用结构化输出记录现场，再决定处理方式，避免凭印象动手
判断顺序
| 第一步 | 确认总量：卡上已用显存是多少 |
|---|---|
| 第二步 | 列出进程：都是谁在占，各占多少 |
| 第三步 | 核对归属：进程属于哪个容器、哪个服务、哪个人 |
| 第四步 | 决定动作：业务相关的走摘流重启，无关的先沟通再处理 |
容器里跑的进程在宿主机上同样可见：进程号是宿主命名空间下的编号，与容器内看到的编号往往不同，不要直接按容器里的进程号操作。
进程已退出但显存仍被占用，多为句柄未释放或驱动尚未回收：确认没有任务在跑之后再考虑重启相关进程或重置设备，重置属于高风险操作。