显存溢出本质是CUDA分配器拒绝分配，非nvidia-smi显示的物理占用；关键征兆包括：GPU-Util低但Memory-Usage高、nvidia-smi进程列表为空却显存未释放、torch.cuda.memory_allocated与memory_reserved差值超500MB。

nvidia-smi 本身不报“显存溢出”错误，它只反映当前状态；真正触发 OOM 的是 CUDA 运行时或框架（如 PyTorch）在 cudaMalloc 失败时抛出异常。排查关键不是等报错，而是提前识别“显存快撑爆”的征兆。

怎么看显存是不是真被占满了

别只盯着 nvidia-smi 输出顶部的 Memory-Usage 行——它显示的是“已分配但未必正在用”的显存总量。真正危险的信号是：

• GPU-Util 很低（比如 Memory-Usage 持续 >90%，说明显存被大张量占着不动，没释放
• 运行 nvidia-smi -q -d MEMORY，对比 Used GPU Memory 和进程列表里所有 Used GPU Memory 的总和：差值 >100MB 就大概率有泄漏
• 执行新任务时报 CUDA out of memory，但 nvidia-smi 显示“Processes”栏为空——这是典型残留句柄问题

为什么 kill 进程后显存还不释放

因为 nvidia-smi 只显示通过 CUDA API 正常注册的进程。以下情况会导致显存卡住不放：

• Python 进程被 kill -9 或 Ctrl+C 中断，子进程（如 DataLoader 的 worker）还在持有 /dev/nvidia0 句柄
• PyTorch 的 torch.cuda.empty_cache() 只清空缓存池，不释放已分配给 tensor 的显存；tensor 仍存活就无法回收
• Jupyter notebook 内核崩溃后未完全退出，后台 Python 进程仍在

这时必须用 fuser -v /dev/nvidia* 查真实句柄持有者，再 kill -9 对应 PID。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

PyTorch 场景下最该检查的三件事

深度学习训练中最容易误判为“显存溢出”的，其实是框架层资源管理问题：

• 确认是否启用了 pin_memory=True 且 num_workers > 0：worker 进程会在 GPU 上预分配显存缓冲区，即使模型没跑也会占几十 MB
• 检查 torch.utils.data.DataLoader 是否用了 drop_last=False + batch_size 不整除数据集：最后一个 batch 可能因 shape 不一致导致隐式重复加载
• 验证 model.to('cuda') 和 data.to('cuda') 是否成对出现：漏掉 data 移动，模型会把中间结果 fallback 到 CPU，后续操作可能触发意外的 GPU 张量创建

别忽略 nvidia-smi 的 Perf 和 Pwr 字段

当显存显示快满、但训练速度极慢时，Perf 字段常暴露真相：

• 如果 Perf 是 P8 或 P12（而非 P0），说明 GPU 被降频了——可能是温度过高（看 Temp）或功耗封顶（看 Pwr:Usage/Cap 接近 100%）
• 此时显存“看起来”不够，其实是计算单元跑不动，batch size 被迫调小，间接加剧显存压力
• 用 nvidia-smi -pl 临时提功耗上限（需 root），或加装散热/清理风扇，比盲目调小 batch 更治本

显存是否真的溢出，取决于你看到的是“物理显存耗尽”，还是“CUDA 分配器拒绝再分”——后者往往藏在 /dev/nvidia* 句柄、PyTorch 的 tensor 生命周期、以及 GPU 自身的功耗策略里。盯紧 fuser 和 nvidia-smi -q 的差值，比反复重启 Python 进程更有效。