Python环境下如何正确解决PyTorch出现的显存溢出OOM？-Python教程-PHP中文网

显存溢出本质是PyTorch缓存分配器无法找到连续空闲块，而非总显存不足；torch.cuda.empty_cache()仅释放无引用的缓存块，需配合model.eval()、torch.no_grad()和gc.collect()在epoch末使用。

python环境下如何正确解决pytorch出现的显存溢出oom？

显存溢出不是“显存不够”，而是 PyTorch 的缓存分配器找不到一块连续的空闲块——哪怕 nvidia-smi 显示还有几 GB free。

为什么 `torch.cuda.empty_cache()` 有时没用？

它只释放那些“已无 Python 引用、但还躺在 PyTorch 缓存池里”的显存块。如果当前仍有张量活着（比如 model 还在 scope 里、loss 没 .item()、DataLoader worker 预加载了 batch），empty_cache() 就是按了个静音开关。

别在训练循环中间频繁调用——它不解决根本问题，反而干扰缓存复用
真正该用的地方是：一个 epoch 训练完 + validation 开始前，且确保 model.eval() 和 torch.no_grad() 已生效
配合 gc.collect() 一起用，尤其当你动态构建模型或反复 import 模块时

`memory_allocated()` 和 `memory_reserved()` 到底谁说了算？

看 OOM 日志里那行 Tried to allocate XX MiB (XX GiB reserved; XX GiB allocated)——关键在 reserved。它代表 PyTorch 当前从驱动手里“圈下来”的总显存，而 allocated 只是其中正在被张量使用的部分。碎片就藏在 reserved - allocated 里。

用 torch.cuda.memory_summary() 替代简单打印 memory_allocated()，它会明确列出 cached memory、active blocks、fragmentation %
如果 fragmentation > 30%，说明缓存池里全是小碎块，大张量进来必然失败
此时 empty_cache() 可能清出几百 MB，但无法拼出你需要的 2GB 连续块——得靠减少中间变量或改用梯度检查点

batch_size=1 还 OOM？重点查这三个地方

这基本排除了数据规模问题，矛头直指模型内部状态或框架行为。

Python 编程规范

Python 编程规范与最佳实践。强制 PEP 8 代码风格、语法校验、单元测试执行，适用于代码编写、审查和重构。触发词：Python、代码规范、py_compile、单元测试。

下载

nn.BatchNorm2d 在 model.train() 下会为每个 channel 分配临时统计缓冲区，和 batch size 无关；高分辨率输入（如 512×512）时单次 forward 就可能吃掉 1–2GB —— 推理务必调 model.eval()，训练小 batch 可冻结 BN：for m in model.modules(): if isinstance(m, nn.BatchNorm2d): m.eval()
误用了 torch.nn.DataParallel：即使单卡也复制模型，显存 ×2；改用 torch.nn.parallel.DistributedDataParallel 或直接删掉
loss.backward() 才报错？说明计算图撑爆了——检查是否在循环中累积了未释放的 torch.cat() 结果，或自定义 loss 返回了带梯度的大张量；加 torch.cuda.memory_snapshot() 定位爆炸层

验证阶段突然 OOM？别只盯着 model

训练能跑通，验证崩，大概率是 DataLoader 和上下文切换惹的祸。

num_workers > 0 + pin_memory=True 会让每个 worker 预加载 batch 到 pinned memory，再批量拷到 GPU；若验证集样本尺寸不均（如多尺度图像），某次拷贝可能瞬时申请远超平均值的显存
验证前漏掉 torch.cuda.empty_cache()，而训练末尾残留了大量缓存，导致验证一上来就撞墙
验证逻辑本身有坑：比如用 torchvision.utils.save_image() 保存整 batch 图像，或计算 PSNR 时把所有预测/真值堆成大 tensor 再做差——这些操作都在 GPU 上进行，极易触发峰值溢出

最常被忽略的点：OOM 往往不是某一行代码的问题，而是多个小开销叠加后，在某个临界点突然失守。与其死磕 batch size，不如先跑一遍 torch.cuda.memory_summary()，看清哪块内存成了“堰塞湖”。