7.2 训练调试案例集：十大经典翻车与处置

本章定位：卷0/卷1/卷2 各章的失败模式在此汇成一本”案例字典”——先收录行业经典 10 例，后续用你的真实踩坑按同款模板追加（格式：现象/第一嫌疑/修复/预防）。学完标准：遇到异常能按”现象→嫌疑排序”30 分钟内定位，而不是改一行跑两小时地瞎试。

0. 通用排查流程（先背这个再翻案例）

症状分类 → ① 不收敛类（loss 不降/NaN/震荡）
         → ② 过拟合类（train↓ val↑）
         → ③ 评估异常类（训练正常但评测诡异）
         → ④ 资源类（OOM/速度骤降）
按类进案例 → 30 分钟无果 → 回到 0.4 单 batch 过拟合定律重新起手

案例 1：loss 第一步就 NaN

• 第一嫌疑：学习率过大；次嫌疑：fp16 溢出、脏数据（某样本 loss=inf）、loss 里对 0 取 log。
• 修复：lr 降 10 倍试；换 bf16；数据逐 batch 前向找出毒样本（二分法）。
• 预防：新 loss 写完先数值对拍（0.3 的习惯）；AMP 一律 bf16。

案例 2：loss 卡在 ln(V) 不动

• 现象：语言模型 loss 恒等于 log(词表大小)——模型在”均匀猜”。
• 第一嫌疑：标签错位（忘 shift 一位、ignore_index 没设、pad token 参与了 loss）——教科书级 bug，人人踩过。
• 修复：手写一个 3 token 的小样本，纸上推 labels 对齐；检查 -100 掩码覆盖。
• 预防：2.5 的 loss mask 单测；改数据管线必跑”3 样本人肉验证”。

案例 3：单 batch 过拟合降不到 0

• 诊断顺序（0.4 §7）：标签对齐 → loss 实现（数值对拍）→ 数据预处理（归一化/resize 是否破坏）→ 梯度链（某层意外 detach/requires_grad=False；LoRA 时 print_trainable_parameters() 是否为 0）→ 模型容量（太小）。
• 预防：0.4 四件套里的 debug_overfit.py 常备。

案例 4：训练正常，验证精度诡异波动

• 第一嫌疑：评估循环忘切 model.eval()（dropout/BN 作祟）；次嫌疑：评估预处理与训练不一致（resize 插值、归一化均值）、评估 batch 里的 pad 处理。
• 预防：训练与评估用同一个预处理函数对象；评估脚本单独过一遍单样本人肉检查。

案例 5：SFT 后模型复读机

• 现象：回答模板化、重复句式。
• 第一嫌疑：epoch 过多 × 数据过少（背下来了）；次嫌疑：数据本身模板腔（蒸馏没清洗）、温度采样过低。
• 修复：减 epoch、数据多样性体检（5.2 的指标 2）、推理调 temperature/top-p。
• 预防：2.5 的失败模式三连实验（故意制造过）。

案例 6：微调后通用能力崩了（灾难性遗忘）

• 现象：领域任务变好，闲聊/常识变差。
• 修复：混入 1:1 通用数据、降 epoch、LoRA 降 rank、lr 降一档。
• 认知：这是 2.5 §5 的常态而非事故——评测必须含通用能力对照组。

案例 7：VLM 回答与图像无关（失明）

• 第一嫌疑：视觉特征没替换进正确位置（inputs_embeds 的占位 mask bug、img_mask 与占位 token 数不匹配）；次嫌疑：projector 输出 dtype/scale 异常（对齐失败）。
• 修复：打印替换前后的 hidden states 逐位检查；阶段一 loss 曲线回看是否真的降过。
• 预防：3.2 复现时”训练前/阶段一/阶段二”三段对比图——失明在阶段一就会暴露。

案例 8：训练几小时后突然 OOM

• 第一嫌疑：训练中途的验证循环没包 inference_mode()；次嫌疑：日志收集了 tensor、长尾样本（最长序列/最大图终于出现）、显存碎片累积。
• 修复：7.1 决策树第 0 步先看 max_memory_allocated 与 nvidia-smi 进程。
• 预防：开工前统计 seq len / 图像分辨率分布，cutoff + 分桶。

案例 9：DDP 多卡训练 loss 行为异常

• 现象：多卡比单卡还慢/loss 抖动异常/每卡数据重复。
• 第一嫌疑：DataLoader 没用 DistributedSampler（每卡吃全量数据）；次嫌疑：只在 rank0 做的操作（日志/保存）没包条件、梯度没同步（某些参数只在部分卡参与）。
• 预防：7.3 §3 的 DDP 检查单。

案例 10：训练时好好的，推理质量不对

• 第一嫌疑：chat template 错位（训练/推理不一致——2.5 头号 bug）；次嫌疑：dtype 不一致（训练 bf16 推理 fp32 的量化误差、4bit 底座配置漂移）、权重没 merge 就加载了 base。
• 预防：训练脚本顺手导出推理配置（template/采样参数）随权重发布。

自测题

1. 案例流程图的四类症状分别先查什么？（不收敛→lr/数据/精度；过拟合→数据量正则；评估异常→eval 模式与预处理一致；资源→7.1 决策树）
2. 案例 2 为什么”人人踩过”？（next-token 的 shift 错位是最容易漏的 off-by-one——防线是 3 样本人肉验证）
3. 案例群 5/6 共同的根因？（小数据 + 大改动 → 背诵或遗忘，都是”改动量与数据量不匹配”）
4. 为什么案例 10 的 template bug 不报错？（它只是改变了文本分布——模型照样运行，只是输入格式陌生）

动手作业

1. 建 debug-cases.md：把本章 10 例抄成检索卡（症状关键词索引）；
2. 从 0.4/2.5/3.2 作业里故意复现 3 个案例，各写一篇”现场记录”（用了多久定位）；
3. 长期：以后每次翻车按模板追加一例——这本案例集一年后就是你最值钱的私产。

延伸资源

• Karpathy《A Recipe for Training Neural Networks》——流程层的总纲（0.4 已列，此处当字典用）
• PyTorch 官方 FAQ（显存/确定性）——底层疑难杂症