使用torch.load与resume_from_checkpoint恢复训练时损失值不匹配

• 批次数据随机性差异
  即使数据路径完全一致，若未固定随机种子，训练时DataLoader的随机采样/shuffle逻辑会导致恢复后首次计算损失的批次和之前最后一步的批次数据分布不同，直接引发损失波动。
  验证：固定全局随机种子（torch、numpy、python random）后重新恢复训练，或手动取出训练最后一步的对应批次输入模型计算损失，看是否接近2.3。
  解决：在脚本开头添加seed_everything(固定数值)，确保数据加载的随机性和训练时完全一致。

• 优化器/调度器状态未正确恢复
  Trainer加载checkpoint时若缺失optimizer.pt或scheduler.pt文件，会重新初始化优化器和调度器，导致学习率等参数回到初始值，模型更新逻辑断裂，表现为损失异常。
  验证：加载后打印trainer.optimizer.param_groups[0]['lr']，对比trainer_state.json中记录的最后一步学习率；或直接加载optimizer.pt查看参数。
  解决：确认checkpoint目录下存在optimizer.pt和scheduler.pt，若自定义训练逻辑，需手动加载优化器状态。

• 模型权重加载不完整
  若恢复时模型结构与训练时存在细微差异（比如混合精度开关不一致、动态修改过模型层），torch.load可能会跳过不匹配的参数，用随机值替代，影响损失计算。
  验证：用strict=True加载模型权重model.load_state_dict(torch.load(checkpoint_path)['model'], strict=True)，查看是否有参数不匹配报错；对比模型某层参数平均值与checkpoint中对应值的差异。
  解决：确保恢复时模型结构、混合精度配置与训练时完全一致；若使用自定义模型，需保证结构无变动。

• 损失计算逻辑或依赖版本差异
  即使启动脚本一致，若缓存的代码文件未更新（比如损失函数模块被修改），或torch等依赖库版本与训练时不同，会导致损失计算结果偏差。
  验证：用相同输入数据在训练环境和当前环境下分别计算损失，对比结果；检查损失函数代码是否完全一致。
  解决：同步所有依赖库版本至训练时的状态；清理脚本缓存后重新运行。

• 日志损失为滑动平均值
  trainer_state.json中记录的损失可能是logging_steps范围内的滑动平均损失，而恢复后显示的初始损失是单批次即时损失，两者本身就存在差异。比如最后一步的滑动平均是2.3，但单批次损失可能原本就接近4。
  验证：查看训练原始日志中第100000步的单批次损失值，与恢复后的初始损失对比。
  解决：若为此情况，属于正常现象，继续训练观察损失是否快速回落至之前水平即可。

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