早停应基于验证Loss连续若干轮未下降，需在每个epoch后用model.eval()和torch.no_grad()单独计算val_loss，避免误用训练loss或遗漏torch.no_grad()导致OOM。
早停判断逻辑：用 torch.nn.functional 计算验证 Loss 后怎么比大小
早停核心是「验证 Loss 连续若干轮没下降」，不是看训练 Loss。必须在每个 epoch 结束后单独跑一次验证循环，用 model.eval() + torch.no_grad() 获得干净的 val_loss。常见错误是把训练时的 loss 直接拿去判断，或漏掉 torch.no_grad() 导致显存暴涨甚至 OOM。
比较时建议用 val_loss （<code>min_delta=1e-4 防止浮点抖动），而不是严格小于。一旦触发更新，就重置计数器；否则 patience_counter += 1。
-
best_val_loss初始设为float('inf')，别用 0 或其他魔数 - 验证 loss 必须是标量（.item() 后的 float），不能是带 grad 的 tensor
- 如果验证集极小（比如
模型状态保存：只存 state_dict，别存整个 model 或 optimizer
保存完整 model 对象会导致序列化依赖当前代码结构，后续改类名、加参数就会 RuntimeError: Unexpected key(s) in state_dict。正确做法永远只存 model.state_dict() 和 optimizer.state_dict()。
文件名建议包含 epoch、val_loss、时间戳，例如：checkpoint_epoch_42_valloss_0.1234.pth。不要覆盖旧文件——早停可能回退到第 38 轮，但你刚覆盖了第 37 轮的 checkpoint。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 用
torch.save({'model_state_dict': model.state_dict(), 'optimizer_state_dict': optimizer.state_dict(), 'val_loss': val_loss}, path) - 加载时先
model.load_state_dict(checkpoint['model_state_dict'])，再optimizer.load_state_dict(...) - 记得调用
model.train()再继续训练，否则 BN 层和 dropout 会异常
早停触发后如何安全退出：别直接 break 就完事
break 只跳出当前 for 循环，但如果你的训练脚本里有后续日志、测试、绘图等逻辑，它们仍会执行——而此时模型权重还是上一轮的，容易误判效果。更稳妥的是用标志位 + 外层条件控制。
典型写法：定义 early_stop_triggered = False，触发时设为 True，并在主循环末尾加 if early_stop_triggered: break。这样能确保所有 cleanup（如关闭 tqdm 进度条、释放 dataloader）正常执行。
- 触发早停前，务必再调用一次
save_checkpoint()，保存最终最佳模型 - 打印信息要明确：「Early stopping at epoch 42, best val_loss: 0.1234」，别只写「Stopped」
- 如果用了学习率调度器（如
ReduceLROnPlateau），注意它和早停的配合顺序——通常早停应在 scheduler.step() 之后判断
多卡 DDP 训练下早停的坑：验证 loss 怎么聚合
DDP 模式下，每个 GPU 算出的 val_loss 是局部 batch 的平均值，不等于全局验证集 loss。直接取 rank 0 的 loss 做判断会偏差很大，尤其当验证集无法被 world_size 整除时。
必须用 torch.distributed.all_reduce() 把各卡的 loss sum 和 count 收集起来，再算全局平均。PyTorch Lightning 自动处理了这点，但手写 DDP 时极易遗漏。
- 验证循环中累积
total_loss += loss.item() * len(labels)和total_samples += len(labels) - 用
all_reduce对两个 tensor 求和，再除得全局 mean loss - 只有 rank 0 执行早停判断和保存 checkpoint，其他 rank 等待同步信号
早停本身不复杂，难的是验证 loss 的统计口径、状态保存的粒度、以及分布式场景下的数据一致性——这些地方错一点，恢复训练就可能完全跑偏。
