torch.cuda.empty_cache()不能解决根本问题，仅释放未被引用的缓存显存，对模型参数、激活值等活跃内存无效；需配合del变量、no_grad()及内存监控使用。
PyTorch报OutOfMemoryError: CUDA out of memory时，torch.cuda.empty_cache()真能解决问题？
不能直接解决根本问题，它只是“清空缓存中未被引用的显存块”，类似手动触发Python的垃圾回收，但对正在使用的显存（如模型参数、当前batch的梯度、中间激活值）完全无效。很多用户调用后仍报错，是因为误以为它能释放“活跃显存”。
实操建议：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 只在确认无活跃张量引用后调用，例如模型验证完、切换数据集前，或
del loss, outputs, logits之后再调用 - 配合
torch.cuda.memory_allocated()和torch.cuda.memory_reserved()打印前后对比，验证是否真有释放 - Windows下可能效果更弱（CUDA驱动行为差异），Linux + 合理的
cudaMallocAsync配置更稳定
梯度累加（gradient accumulation）怎么写才不爆显存又不改错训练逻辑？
核心是把一个“逻辑batch”拆成多个forward + backward小步，只在最后一步更新参数。关键不是多调几次loss.backward()，而是控制optimizer.step()和optimizer.zero_grad()的时机。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 设累积步数
accumulation_steps = 4，每个for batch in dataloader:里都做loss.backward()，但每4次才optimizer.step()+optimizer.zero_grad() -
loss必须除以accumulation_steps（否则梯度被放大，等效于学习率变大） - 记得在
step()前检查global_step % accumulation_steps == 0，避免最后一次不足步数时漏更新 - 使用
torch.cuda.amp.GradScaler时，scaler.scale(loss).backward()和scaler.step(optimizer)需配套，且scaler.update()每次都要调
为什么开了gradient accumulation还OOM？常见陷阱有哪些？
梯度累加只缓解batch_size导致的显存压力，但不管模型结构本身或中间激活值的开销。很多OOM其实来自激活值爆炸（尤其Transformer类模型），而非梯度。
容易踩的坑：
- 没关
torch.backends.cudnn.benchmark = False：动态图优化可能缓存多版本kernel，增加预留显存 - 用了
nn.DataParallel而不是nn.DistributedDataParallel：前者会复制整个模型到每个GPU，显存翻倍 - 验证阶段忘记
torch.no_grad()，或者用了model.train()——即使不更新参数，BN层仍会统计running_mean/var，且梯度图照常构建 - 自定义
forward里有.clone()、.detach().requires_grad_(True)等隐式保留计算图的操作，导致中间变量无法释放
比empty_cache和梯度累加更治本的三个显存压缩手段
这些方法直接减少单步所需显存，不是“腾地方”，而是“缩小占地”：
- 启用
torch.compile(model, mode="reduce-overhead")（PyTorch 2.0+）：可降低激活值驻留时间，部分场景显存降15%~30% - 对
nn.TransformerEncoderLayer等模块设batch_first=True并确保输入dtype=torch.float16，避免隐式类型转换产生临时float32张量 - 用
torch.utils.checkpoint.checkpoint包装子模块（如Transformer block）：用时间换空间，重算激活值而非存储，注意仅适用于无副作用的纯函数式子模块
真正卡在显存上时，先看torch.cuda.memory_summary()输出里的activated和reserved比例——如果reserved远大于allocated，说明是缓存碎片问题；如果两者接近，那一定是模型或数据本身太重，该砍结构、降精度或换checkpoint了。
