大模型训练日志分析：从日志定位 loss 异常与训练卡死

训练日志里出现 loss 突然变成 nan、连续多步不下降，或者进程还在但 GPU 利用率掉到 0，先别急着重启任务。
按下面的顺序把日志拆开看：先确认日志文件位置和格式，再提取 loss 与学习率序列，然后对照异常时间点查报错和资源，最后用监控和轮转把问题固定下来。
这套方法在单机多卡和多机训练里都适用，前提是你至少保留了 stdout 日志或框架输出的结构化日志。

先确认日志落在哪、长什么样

多数训练框架会把 stdout 和 stderr 重定向到文件，常见写法如下：

nohup torchrun --nproc_per_node=8 train.py > logs/train_$(date +%F_%H%M).log 2>&1 &

如果用的是容器，日志可能在 docker logs 里，先落盘再分析：

docker logs 训练容器名 > logs/train_container.log 2>&1

拿到文件后先看前 50 行和最后 100 行，确认打印格式。
一般每步会输出类似 step=1200 loss=2.31 lr=0.0001 grad_norm=1.8 的行。
如果日志里没有 loss，只有框架的进度条，需要回到训练脚本里把日志级别调到 INFO，并确保每个 rank 的日志分文件保存，否则多进程会互相覆盖。

提取 loss 序列，判断是发散还是抖动

用 grep 加 awk 把关键字段抽成两列，便于观察趋势：

grep -oE 'step=[0-9]+ loss=[0-9.eE+-]+' logs/train_2025-01-01_1200.log \
  | awk -F'[= ]' '{print $2, $4}' > loss.txt

然后看首尾和跳变点：

head -5 loss.txt
tail -5 loss.txt
awk 'NR>1 && ($2-prev>1 || prev-$2>1) {print NR, prev, $2} {prev=$2}' loss.txt

如果 loss 在前几百步快速下降后进入平台期，属于正常收敛；
如果某一步突然从 2.x 跳到几十甚至 nan，重点查该步前后的学习率、梯度裁剪和 batch 是否变化。不要只看平均值，大模型训练里单个 step 的异常往往被平滑掉，按 step 对齐才能定位到具体数据或参数更新。

卡死和 OOM 的日志特征

训练卡死常见表现是日志停在某一步不再输出，但进程还在。
先确认时间戳：

tail -n 20 logs/train_2025-01-01_1200.log
ps -ef | grep train.py
nvidia-smi

如果最后一条日志时间超过 10 分钟且 GPU 利用率接近 0，优先怀疑数据加载阻塞、NCCL 通信挂起或某个 rank 先挂。
多机训练时分别登录各节点看日志，找出第一个停止打印的 rank。
OOM 则通常伴随 CUDA out of memory 或 RuntimeError: NCCL error，用以下命令确认显存和进程状态：

nvidia-smi --query-gpu=index,memory.used,utilization.gpu --format=csv

避坑：不要直接 kill 主进程了事。 先保存当前日志和 nvidia-smi 输出，再按框架方式停止，否则可能留下僵尸进程占住显存。
重启前把 batch size、梯度累积步数和日志级别确认一遍，避免同样问题复现。

用轮转和监控把日志管起来

日志文件过大时 grep 会变慢，建议按大小轮转：

logrotate -f /etc/logrotate.d/train

配置片段示例：

/path/to/logs/train.log {
  daily
  rotate 7
  size 500M
  compress
  missingok
  notifempty
}

同时把 loss 和 grad_norm 定期打到独立文件，方便后续画图。
验证方式是轮转后确认新日志继续写入、旧文件被压缩，并且用 grep -c 'loss=' 对比轮转前后的行数没有明显丢失。

常见疑问

日志里 loss 是 nan，但训练没报错，需要立即停吗？ 建议先停。
nan 会污染后续参数，继续训练可能浪费算力。
停之前保存 checkpoint 和对应日志段，再检查学习率是否过大、数据里是否有空值或异常长序列。

多卡训练日志混在一起怎么分析？ 让每个 rank 输出到独立文件，例如在启动脚本里用 RANK 环境变量拼文件名。
分析时先看 rank 0 的汇总日志，再对照异常 rank 的详细日志。

只有进度条没有 loss 文本怎么办？ 在训练循环里加一行 if global_step % 10 == 0:
logger.info(...)，
把 step、
loss、
lr 和 grad_norm 打出来，
重新跑一小段验证格式后再全量训练。

日志分析的目标不是把每条输出都读完，而是用固定命令快速回答三个问题：loss 是否在正常区间、异常发生在哪一步、该步前后环境有没有变化。
先把这套流程跑通，再根据你的框架和日志格式微调字段即可。