梯度累积本身不降低单步显存峰值，需配合减小batch_size才能缓解OOM；正确做法是保持等效batch不变而降低每步batch_size并增加累积步数。
为什么梯度累积能缓解OOM，但不能直接减小显存峰值
梯度累积（gradient accumulation）本身不降低单步前向/反向的显存占用，它只是把“一次大batch更新”拆成多次小batch计算+累加梯度，最后统一优化器步进。真正起作用的是你同时调低了batch_size，从而压低了激活值（activations）这一最大动态内存来源。
常见错误是只改了累积步数却没调小batch_size，结果显存反而更高——因为每步仍按原batch_size跑，还多存了梯度累加变量。
- 正确做法：设目标等效batch为
256，GPU显存只够batch_size=32，那就用accumulation_steps = 8 - 关键代码位置必须在
loss.backward()之后、optimizer.step()之前判断是否触发更新 - 记得同步调用
optimizer.zero_grad(set_to_none=True)，比默认set_to_none=False更彻底释放梯度引用
torch.cuda.amp.autocast + GradScaler怎么配才不报错
混合精度训练（AMP）不是开个autocast就完事。PyTorch的GradScaler必须和autocast严格配对使用，否则会因FP16梯度下溢（underflow）或NaN导致训练中断。
典型错误包括：scaler.scale(loss).backward()漏掉scaler，或在scaler.step(optimizer)后忘记scaler.update()，导致后续step卡死。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
autocast只包裹前向传播和loss计算，loss.backward()必须在外层（即不被autocast包裹） -
scaler.step(optimizer)内部会自动检测梯度是否有效，若全为NaN则跳过更新，但必须跟scaler.update()配套 - 遇到
RuntimeError: Found dtype Double but expected Float，大概率是某处手动写了.double()或dtype=torch.float64，破坏了AMP上下文
梯度累积 + AMP组合时最容易漏掉的三件事
两者叠加能同时压缩batch压力与数值精度开销，但协同逻辑变复杂。很多人在调试时反复失败，往往栽在这些细节上：
- 每次
scaler.scale(loss).backward()前，要确保loss是标量且未detach；若用了loss.mean()但输入是空tensor，会产出NaN - 累积期间不能调用
scaler.step()，否则scaler状态错乱；只在第accumulation_steps次才执行 - 验证阶段（
with torch.no_grad():）必须关闭autocast，否则部分算子（如torch.max）在FP16下可能出错，应显式写with torch.no_grad(), torch.autocast(device_type="cuda", enabled=False):
显存没降反升？先查这行日志
当你改完梯度累积和AMP，nvidia-smi显示显存占用反而更高，别急着回滚。先运行这行代码：
print(torch.cuda.memory_summary())
重点看两行：allocated bytes（真实已分配）和reserved bytes（PyTorch缓存分配器预留）。如果reserved远大于allocated，说明是缓存碎片问题，不是模型真吃不下——这时torch.cuda.empty_cache()可能有奇效，但只应在epoch末尾调用，别塞在step循环里。
另一个高发原因是数据加载器（DataLoader）开启了pin_memory=True但没配num_workers>0，导致CPU预加载张量堆积在GPU显存中。检查data_loader初始化参数，确认pin_memory仅在num_workers > 0时启用。
