速查·4.X 训练推理踩坑补遗（一）

速查·4.X 训练推理踩坑补遗（一）

正文 4.3 的八条实录覆盖了显存、权重、OOM、网络等高频故障。本条补六个新现场：报错更曲折，但定位思路可以直接复用。

实录一：DataLoader worker 成批退出，报 "worker exited unexpectedly"

现场：训练起跑后 1~2 分钟必挂，日志里 DataLoader worker 的 traceback 一闪而过。
定位：容器默认 /dev/shm 只有 64MB，worker 用共享内存传 batch，第一个大 batch 一到就爆。df -h /dev/shm 一看便知。
处置：docker run --shm-size=8g，或降低 num_workers 并检查 pin_memory。这也是"本地好好的、进容器就挂"的最常见根因之一。

实录二：fp16 混合精度训练，loss 跑成 NaN

现场：amp 训练若干 step 后 loss 变 NaN，且再不恢复。
定位：fp16 数值范围窄，梯度上下溢。确认 GradScaler 用法是否正确、是否连续跳步；对比 NaN 出现的 step 与学习率调度的关系。
处置：① 严格按 scale → backward → unscale → step 的顺序用 GradScaler；② 有条件优先换 bf16（Ampere 及之后的卡支持，动态范围大，基本告别 NaN）；③ 仍不行就排查数据里的异常值（inf/超大数），别急着回 fp32 全量。

实录三：长上下文推理一上 32K 就 OOM

现场：8K 上下文正常，32K 直接 CUDA OOM，卡上没有别的任务。
定位：KV cache 显存随上下文长度线性增长，和模型权重是两本账。粗估公式：KV cache ≈ 2 × 层数 × KV头数 × head_dim × 上下文长度 × 精度字节数 × 并发数。
处置：推理引擎限制 max_model_len；压低并发 batch；用支持 PagedAttention 的引擎（如 vLLM）提高显存利用率。先算账再上长度，别靠试。

实录四：checkpoint 保存到一半进程被 OOM kill，文件是坏的

现场：宿主机 OOM killer 杀了容器，重启后加载 checkpoint 报文件损坏。
定位：保存期间权重序列化会瞬时占用接近翻倍的内存（进程内对象 + 写入缓冲），撞上宿主机内存上限；半截文件没有任何标记。
处置：① 原子写：先写 ckpt.pt.tmp，torch.save 成功后再 os.rename 覆盖——rename 在同一文件系统上是原子的；② 保存后立即 load 校验一次再继续训练；③ 保留最近 N 份 checkpoint，不覆盖唯一副本。坏 checkpoint 的损失以"几天训练"计，这个防御值得写进所有训练脚本。

实录五：GPU 利用率常年 100%，吞吐却上不去

现场：nvidia-smi 显示 100%，迭代速度却只有预估的五分之一。
定位：GPU 在"等数据"与"空转计算"之间高频切换，利用率高不等于效率高。用 profiler 看 dataloader 时间占比，或对比 SM 实际占用。
归因：九成是 CPU 侧瓶颈——数据预处理太重（解码/增强）、num_workers 不够、数据放在网络盘上。
处置：预处理搬进 GPU（DALI 等）、加 worker、数据先落本地盘或转成顺序读取更快的格式。结论记牢：优化 GPU 利用率，先查 CPU。

实录六：在运行中的容器里 pip install 了包，重启后消失

现场：调试时随手在容器里装了个包，一切正常；第二天重启容器，ImportError。
归因：容器是镜像的运行实例，写在可写层的内容随容器删除而消失——这是特性不是 bug。
处置：调试装包可以，但"要留下"的依赖必须回到 Dockerfile 重建镜像。别用 docker commit 固化容器——那是快照不是配方，三个月后没人说得清里面装了什么。正确路径：改 Dockerfile → 构建 → 镜像打版本 tag → 重建容器。

详细原理见正文第四章 4.1「训练任务沙箱化」与 4.2「推理服务沙箱化」。