显存溢出时memory_allocated()跳变是因CUDA缓存机制,它只统计实际张量占用,不计缓存碎片;OOM常由缓存无法拼合大块内存触发,需用memory_summary()查看缓存与碎片,配合empty_cache()、eval()模式、BN处理、梯度检查点及Dataloader调优综合解决。

显存溢出时torch.cuda.memory_allocated()返回值突然跳变
这不是显存真的“突然爆掉”,而是PyTorch的CUDA缓存机制在作祟。GPU显存分配器会预占显存块,memory_allocated()只统计当前张量实际占用,不包含缓存碎片。一旦新张量需要连续大块内存而缓存无法拼合,就会触发OOM。
- 用
torch.cuda.memory_summary()代替单纯看memory_allocated(),它能显示缓存(cached memory)和碎片情况 - 训练中每轮开头加
torch.cuda.empty_cache()——但别滥用,它只是释放未被引用的缓存,不能解决根本的batch过大问题 - 确认是否在
eval()模式下忘了关torch.no_grad(),模型前向传播时仍保留梯度计算图,显存翻倍
batch_size设为1仍OOM,大概率是model.train()里残留了nn.BatchNorm2d
BatchNorm层在训练模式下会保存running_mean和running_var,且对每个batch都做统计更新。即使batch_size=1,它仍按原始channel数分配临时缓冲区,尤其在高分辨率输入(如512×512图像)时显存开销陡增。
- 推理阶段务必调用
model.eval(),这会停用BN的统计更新,大幅降低显存峰值 - 若必须训练小batch,考虑替换为
nn.InstanceNorm2d或冻结BN参数:for m in model.modules(): if isinstance(m, nn.BatchNorm2d): m.eval() - 检查是否误将
torch.nn.DataParallel套在单卡模型上——它会复制模型到多个device,显存直接×N
RuntimeError: CUDA out of memory发生在loss.backward()而非model.forward()
说明前向没问题,反向传播时显存爆炸。这是典型的计算图保留过多中间变量导致的,尤其常见于自定义loss、循环结构(如RNN展开)、或用了torch.cat()/torch.stack()拼接大量张量。
- 在
loss.backward()前插入torch.cuda.memory_snapshot()(PyTorch 1.10+),导出内存快照用torch.cuda._memory_viz.trace_plot()定位哪层张量撑爆显存 - 避免在循环中累积
loss:不要total_loss += loss,改用total_loss = total_loss + loss并适时.item()提取标量 - 对长序列任务,启用梯度检查点:
torch.utils.checkpoint.checkpoint(model, x),用时间换空间,显存可降30%–50%
Dataloader的num_workers > 0反而加剧显存压力
多进程加载本身不占GPU显存,但每个worker会预加载batch并常驻内存;若主进程GPU显存已近极限,worker进程的内存映射(尤其是pin_memory=True时)可能触发系统级OOM,间接导致CUDA初始化失败或显存分配异常。
- 先设
num_workers=0验证是否真由worker引起——这是最快速的排查手段 - 若必须多进程,关闭
pin_memory=True,或降低prefetch_factor(默认2,可试1) - 检查worker内是否意外调用了
torch.cuda.device或创建了GPU张量——worker应在CPU上处理数据,仅在collate_fn末尾转GPU
PyTorch显存问题从来不是单一原因,empty_cache()治标不治本,真正要盯住的是计算图生命周期、BN行为、以及Dataloader与GPU内存的耦合边界。最容易被忽略的是:同一段代码在不同PyTorch版本中显存表现可能差异极大——1.12之后的缓存策略和1.9完全不同,升级前务必跑一遍memory_summary()对比。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











