训练进度与里程碑表 | AI生成和翻译
训练是健康的。快速状态：
| 进程已运行 | 1:45 已用 |
| 参数 | 219.4M ✓ |
| 初始 val loss | 10.994 (随机 — 预期 ~ln(50304) = 10.83) |
| GPU | 100% util, 9.7 GB / 12 GB, 210 W |
| 首次日志记录 | iter 0: loss 11.0089, time 32.4 s (包括 startup eval，正常) |
为什么还没有看到 iter 1： log_interval=20，因此下一次打印将在 iter 20（约从开始后 7 分钟）。
进度预期
| 里程碑 | 迭代 | 自开始预计时间 |
|---|---|---|
| 第一条训练日志 | 20 | ~7 分钟 |
| 第一个真实 val loss | 250 | ~1.5 小时 |
| 完成 25% | 2,000 | ~12 小时 |
| 完成 50% | 4,000 | ~24 小时 |
| 完成 75% | 6,000 | ~36 小时 |
| 运行完成 | 8,000 | ~47 小时 (≈ 周六 5 月 16 日上午) |
何时结束训练
正常情况下不要提前结束。 余弦学习率调度从 4e-4 衰减到 4e-5，覆盖全部 8,000 次迭代；提前终止意味着训练的最后一部分从未获得锁定最终 loss 所需的低 LR 精调。
表明训练健康的信号——让其继续运行：
- val loss 在 iter 250 时 < ~7（从 10.99 下降）
- val loss 在 iter 1000 时处于 5–6 范围
- val loss 在每个检查点单调递减
需要调查（但不必恐慌性停止）的信号：
- val loss 远大于 train loss → 数据问题
- loss 突增或 NaN → 梯度爆炸（罕见；grad_clip=1.0 应能捕获）
- val loss 在连续 3 次以上评估（约 750 次迭代）中处于 > 3.5 的任意值上停滞 → 优化卡住
合理提前停止：
- 如果在 iter 6000 之前 val loss 达到约 2.95，你可以停止——无论如何已经接近模型容量上限。但训练的最后 25% 通常能额外降低约 0.05 loss，所以我还是会建议让它跑完。
需要我设置一个后台监视器，在 iter 250 触发（第一个真正信号）以及后续每个验证检查点时通知你吗？或者你主动问的时候定期检查？