Keras微调时触发OOM错误但初始训练正常的原因排查

• 模型加载时的显存冗余或残留
  部分深度学习框架在加载模型时，若未提前清理GPU缓存，可能残留之前训练的隐性显存占用；或者加载代码中重复定义了模型实例，导致两份模型权重同时占用显存。即使启动时显示GPU使用率为0%，框架内部可能仍有未释放的缓存块，叠加新模型的显存需求后触发OOM。解决思路：加载模型前调用框架的缓存清理接口（如PyTorch的torch.cuda.empty_cache()、TensorFlow的tf.keras.backend.clear_session()），并确保代码中只初始化一次模型实例。

• 优化器状态加载带来的额外显存开销
  若训练时保存了优化器的状态（如动量参数、Adam的一阶/二阶矩），加载时这些状态会占用与模型参数规模相当的显存。第一次训练时优化器状态是逐步累积的，而加载时是一次性将所有状态加载到GPU，相当于在模型参数的显存基础上额外增加了近一倍的开销，刚好超出显存阈值。解决思路：若不需要延续之前的优化器状态，仅加载模型的state_dict，重新初始化优化器；若必须加载优化器状态，可尝试缩小batch-size或启用梯度累积。

• 数据集预处理的隐性差异
  即使图像尺寸均为128×128，新数据集的预处理逻辑可能存在差异：比如原数据集是单通道灰度图，新数据集是三通道RGB图但未做通道转换，导致输入张量从[64,1,128,128]变为[64,3,128,128]，显存占用直接翻倍；或者新增了数据增强操作（如随机翻转、裁剪的中间张量未及时释放），额外消耗显存。解决思路：核对新数据集的预处理代码，确保输入张量的通道数、数据类型与原训练完全一致，清理不必要的中间张量。

• GPU内存碎片问题
  第一次训练结束后，GPU显存可能产生大量碎片，虽然整体使用率显示为0%，但实际连续可用的显存块无法容纳模型+批量数据的连续内存需求。第一次训练时显存是逐步分配的，连续块足够，但重启加载时，碎片导致无法分配大尺寸连续内存，触发OOM。解决思路：重启训练进程（彻底释放显存），或在加载前调用缓存清理接口尝试合并碎片。

• 框架优化策略的差异
  若两次训练使用了不同版本的框架，或加载时未启用原训练的显存优化策略（如自动混合精度AMP），会导致模型显存占用升高。比如原训练用FP16混合精度，加载时默认用FP32存储参数，显存占用直接翻倍。解决思路：核对框架版本，确保加载时启用与原训练一致的精度优化策略。

内容的提问来源于stack exchange，提问作者psj