NanoChat训练日志字段

NanoChat训练日志字段 | AI生成和翻译

首页 2026.07

答案：

这是 base_train.py 中两条连续的 print0 输出行被终端换行拼接在一起的结果——开头的 h: 1 实际上是前一行中 epoch: 1 的尾部，被终端换行截断了。实际格式字符串直接来自 scripts/base_train.py：

epoch = f"{dataloader_state_dict['epoch']} pq: {dataloader_state_dict['pq_idx']} rg: {dataloader_state_dict['rg_idx']}"
print0(f"step {step:05d}/{num_iterations:05d} ({pct_done:.2f}%) "
       f"| loss: {debiased_smooth_loss:.6f} | lrm: {lrm:.2f} "
       f"| dt: {dt*1000:.2f}ms | tok/sec: {tok_per_sec:,} "
       f"| bf16_mfu: {mfu:.2f} | epoch: {epoch} "
       f"| total time: {total_training_time/60:.2f}m{eta_str}")

逐字段解释，以你的行为例：

step 00383/29000 (1.32%) —— 当前优化器步数 / 总计划步数。383/29000 = 1.32%，符合计算。
loss: 3.369286 —— debiased_smooth_loss，一个经过偏差校正（类似 Adam 的偏差校正，使早期步骤不会人为偏低）的 EMA 平滑交叉熵损失。不是原始的每步损失。
lrm: 1.00 —— 来自 WSD（warmup-stable-decay，预热-稳定-衰减）学习率调度器的学习率乘数，不是原始学习率。值为 1.00 说明你处于平坦的“稳定”阶段，衰减阶段尚未开始（训练后期才会触发）。
dt: 4052.93ms —— 该步的墙上时间。在 MI300X 上，这包括前向+反向+Muon/AdamW 更新。
tok/sec: 129,360 —— 吞吐量 = B*T*ddp_world_size/dt。反推：每步 token 数 ≈ 129360 * 4.05293 ≈ 524,350 个 token。如果你使用 depth=20（d=1280）和 T=2048，且单 GPU（ddp_world_size=1），则意味着 B ≈ 256。
bf16_mfu: 62.46 —— 模型算力利用率（Model FLOPs Utilization）：100 * flops_per_sec / (gpu_peak_flops * ddp_world_size)。建议检查 nanochat/common.py 中的 get_peak_flops() 函数——它硬编码了各 GPU（H100/A100 等）的峰值 FLOPs 表，我怀疑 MI300X 并未包含在该表中，这意味着你的 62.46% 可能是基于错误/默认的峰值 FLOPs 常数计算得出的。在信任这个数值进行真实 MFU 比较之前，请使用 grep 搜索 get_peak_flops 并确认其中包含 MI300X（CDNA3，~1.3 PFLOPs bf16 密集计算）的条目。
epoch: 1 pq: 0 rg: 279 —— 数据加载器的恢复状态，不仅仅是“epoch 编号”：
- epoch —— 完整遍历打乱后的分片集合的次数（epoch=1 表示第一次遍历）。
- pq_idx —— 当前 parquet 分片文件 的索引（每个文件约 100MB / 约 0.25M 字符，参见 FineWeb-EDU 重新打包的 dev/repackage_data_reference.py）。
- rg_idx —— 当前 parquet 文件内 行组（row group） 的索引（row_group_size = 1024 个文档/组）。这三个值正是 save_checkpoint 所保存的状态，以便在训练崩溃后恢复时能从中断的分片位置继续，而不是重新开始整个 epoch。
total time: 25.43m 和 eta: 1951.2m —— total_training_time 只有在第 10 步之后才开始累积（预热步骤不计入平均时间），而 eta = (num_iterations - step) * avg_time_per_step。两行之间的差异：25.43 - 25.36 = 0.07m ≈ 4.2s，这与中间单步的 dt=4052.93ms 吻合——因此循环行为一致，没有卡顿。

一个值得注意的数据管道信号：rg_idx 在一步内从 278 变为 279 —— 也就是说，在当前批次大小下，你每个优化器步骤消耗几乎正好一个行组（1024 个打包文档）。按 eta: 1951.2m（约 32.5 小时）完成全部 29000 步计算，你将循环大量行组——建议确认你的本地分片缓存（~/.cache/nanochat）已下载了足够多的分片，以免在 AMD Dev Cloud 机器上运行时因网络 I/O 获取 parquet 文件而卡住。

参考文献：

返回捐助