EarlyStopping必须监控val_loss而非train_loss，因为train_loss持续下降是过拟合典型信号，而val_loss上升才反映泛化能力退化；若未提供validation_data，val_loss无法计算，回调将静默失效。
EarlyStopping 为什么必须监控 val_loss 而不是 train_loss
因为 train_loss 持续下降是过拟合的典型信号，早停目标恰恰是防止它继续下降。只看 train_loss 会导致模型在验证集上性能已明显变差时仍强行训练，完全违背早停初衷。Keras 的 EarlyStopping 默认监控 val_loss，但如果你没开启验证集（比如没传 validation_data 或 validation_split），val_loss 根本不会被计算，此时回调会静默失效——连 warning 都不抛。
- 确保训练时显式提供验证数据：
model.fit(..., validation_data=(X_val, y_val))或validation_split=0.2 - 检查训练日志里是否真有
val_loss列；没有就说明验证流程没跑起来 - 不要依赖
monitor='loss'，它指训练损失，不是验证损失
EarlyStopping 关键参数怎么设才不误杀也不放水
patience 和 min_delta 是最容易配错的两个参数。太小（如 patience=1）会让模型刚抖一下就停；太大（如 patience=50）可能错过最佳点。实际中，patience=7 ~ 15 是较稳妥的起点，具体取决于验证集大小和任务难度——小数据集波动大，需要更大 patience。
-
min_delta=1e-4比默认0更合理：避免把浮点误差当改进 -
restore_best_weights=True必须开：否则返回的是最后一步权重，大概率比最佳点差 -
mode='min'对val_loss是默认值，但若监控val_accuracy，就得改成mode='max'
手动实现 EarlyStopping 有哪些坑要避开
自己写逻辑判断 val_loss 是否连续上升，看似自由，实则容易漏掉边界情况。最常见的是没正确处理第一次 epoch 的初始化，或在 on_epoch_end 里错误地把当前 loss 和“上一轮”比较，而“上一轮”其实还没发生。
- 别用
if current_loss > best_loss:直接比——首次运行时best_loss是未定义的 - 记录的是最小 loss 值，不是索引；恢复权重时得存下对应 epoch 的
model.get_weights()，不能只记个数字 - 如果用
tf.keras，注意model.save_weights()和load_weights()的路径权限与格式一致性
多卡训练或自定义训练循环里 EarlyStopping 怎么同步
在 tf.distribute.MirroredStrategy 下，val_loss 是各卡平均后的标量，EarlyStopping 回调本身能正常工作。但如果你手写分布式训练循环（比如用 @tf.function + strategy.run），val_loss 的聚合必须显式做——否则每张卡各自判断，可能 A 卡触发停止而 B 卡还在训。
立即学习“Python免费学习笔记（深入）”；
- 用
strategy.reduce(tf.distribute.ReduceOp.SUM, per_replica_loss, axis=None)再除以卡数 - 停止信号必须由 chief worker（通常
strategy.cluster_resolver.task_id == 0）统一广播，不能每卡独立决定 - PyTorch 的
torch.nn.parallel.DistributedDataParallel同理：val_loss要用torch.distributed.all_reduce汇总
