显存溢出时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初始化失败或显存分配异常。
立即学习“Python免费学习笔记（深入）”；
- 先设
num_workers=0验证是否真由worker引起——这是最快速的排查手段 - 若必须多进程，关闭
pin_memory=True，或降低prefetch_factor（默认2，可试1） - 检查worker内是否意外调用了
torch.cuda.device或创建了GPU张量——worker应在CPU上处理数据，仅在collate_fn末尾转GPU
empty_cache()治标不治本，真正要盯住的是计算图生命周期、BN行为、以及Dataloader与GPU内存的耦合边界。最容易被忽略的是：同一段代码在不同PyTorch版本中显存表现可能差异极大——1.12之后的缓存策略和1.9完全不同，升级前务必跑一遍memory_summary()对比。 
