4. 日志与监控体系：训练日志规范、监控指标（采集与分析）

大规模模型训练的失败往往不是瞬间发生的，而是通过一系列微小的异常信号逐步累积而成。若缺乏结构化的日志与监控体系，当训练任务在凌晨三点中断时，工程师面对的是数十GB的原始输出和数百个无关联的指标曲线，根因定位如同大海捞针。本章聚焦于构建一套“可观测、可追溯、可预警”的训练监控体系，涵盖日志规范、关键指标采集以及基于趋势的异常分析。

4.1 训练日志规范：从“print大法”到结构化事件流

在单卡调试阶段，使用 print 输出损失值尚可接受。但在分布式训练中，日志必须遵循 结构化、分级化、关联化 原则。推荐采用 JSON 格式输出每条日志，并包含统一字段：timestamp、rank、level、event、message、extra。

// 推荐的结构化日志示例 (JSON Lines)
{"timestamp": "2025-06-12T14:03:21.123Z", "rank": 0, "level": "INFO", "event": "TRAIN_STEP", "message": "step=1500 loss=2.345 lr=1.2e-4", "extra": {"gpu_util": 98.2, "mem_alloc": 40500}}
{"timestamp": "2025-06-12T14:03:21.456Z", "rank": 3, "level": "WARN", "event": "GRAD_NORM", "message": "grad_norm=45.6 exceeds threshold=10.0", "extra": {"param_group": "embedding"}}
{"timestamp": "2025-06-12T14:03:22.001Z", "rank": 1, "level": "ERROR", "event": "NCCL_TIMEOUT", "message": "rank=1 waiting on rank=2 for 1800s", "extra": {"collective": "allreduce", "tensor_size_mb": 512}}

日志分级应遵循：INFO（正常步进、检查点保存）、WARN（梯度范数突增、学习率预热结束、通信重试）、ERROR（CUDA OOM、NCCL超时、数据加载失败）。所有日志必须携带 rank 标识，否则无法区分是单卡故障还是集体故障。此外，禁止在训练热路径（每步）中记录冗长的堆栈信息，应使用异步日志句柄，避免 I/O 阻塞计算。

最佳实践：为每个 event 类型分配唯一 ID（如 EVT_1001），并在代码中通过常量引用。这便于日志分析工具进行聚合统计，而非依赖字符串匹配。

4.2 监控指标采集：三类核心指标与采集频率

监控指标分为 资源类、计算类 与 通信类。采集频率需权衡开销：资源类每 5 秒采样一次，计算类（如 loss）每步记录，通信类则需在每次集合通信操作后记录累计耗时。

类别 指标名称 采集方式 异常阈值参考
资源 GPU 利用率 / 显存占用 NVML 轮询 (5s) 利用率 < 60% 持续 5min
资源 PCIe/NVLink 带宽 DCGM 计数器 带宽 < 理论值 30%
计算 Loss / Grad Norm / 吞吐 (samples/s) 训练回调钩子 Loss 连续 100 步不下降
通信 AllReduce 耗时 / 等待耗时 NCCL 计时器 通信占比 > 40% 总步时

采集到的指标需写入时序数据库（如 Prometheus + Grafana），并保留原始标签（rank, model_layer）。对于 loss 曲线，建议同时记录 平滑值（EMA）与 原始值，避免因个别噪声点误判发散。

4.3 核心原理：从指标关联到根因假设

监控的核心并非展示曲线，而是建立 跨指标关联推理。下图展示了典型的异常传播路径：当某张卡的散热故障导致 GPU 利用率下降，进而引发该卡的 AllReduce 等待时间拉长，最终表现为全局吞吐下降，但 Loss 曲线可能仍保持下降趋势——此时若只看 Loss 会完全漏检。

GPU 1 散热故障 温度 92°C → 降频 GPU1 利用率 45% SM 时钟降至 1.2GHz AllReduce 等待 2.3s 其他 rank 阻塞在集合通信 全局吞吐 1200→800 samples/s 下降 33% Loss 曲线正常下降 掩盖了底层故障 因果链 因果链 因果链 易漏检 监控分析原则：沿“物理→资源→通信→训练”链路逐层下钻，而非仅盯 Loss 曲线

上图揭示了监控分析的核心方法：自底向上关联。当吞吐下降时，首先检查通信耗时占比；若通信等待异常，再检查各 rank 的 GPU 利用率与温度；最终定位到物理层故障。这种分层诊断模型能有效避免“头痛医头”的误判。

4.4 案例场景：一次由日志监控发现的“静默”数据倾斜

某团队训练 70B 参数模型，使用 64 张 A100。Loss 曲线正常下降，但训练总时长比预估慢了 40%。工程师通过监控面板发现：Rank 12 的 GPU 利用率仅为 55%，而其他 rank 均在 95% 以上。进一步查看日志，发现 Rank 12 的 DATA_LOAD_TIME 事件平均耗时 180ms，而其他 rank 仅为 20ms。

根因定位过程如下：

  1. 检查数据管道：Rank 12 对应的数据分片文件位于机械硬盘（HDD）而非 SSD，导致 I/O 瓶颈。
  2. 验证假设：通过监控中的 disk_read_bytes 指标确认，Rank 12 的磁盘读取速率仅为 40MB/s，远低于其他 rank 的 1.2GB/s。
  3. 修复动作：将数据文件迁移至 NVMe SSD，并启用 prefetch_factor=4 的 DataLoader 预取。

修复后，Rank 12 的利用率回升至 96%，整体训练速度提升 35%。该案例表明：Loss 正常不代表训练健康，必须结合资源与数据管道指标综合判断。

4.5 误区与复盘：监控体系建设的常见陷阱

误区一：指标采集频率过高导致训练抖动。 曾有团队将 GPU 利用率采集频率设为 200ms，导致 NVML 调用占用了 PCIe 带宽，反而使训练吞吐下降 5%。建议资源类指标采样间隔 ≥ 2s，且使用独立的监控进程（非训练进程内轮询）。

误区二：日志无分级，ERROR 刷屏掩盖关键 WARN。 若将梯度范数异常全部记录为 ERROR，则真正的 NCCL 超时错误会被淹没在数千条 ERROR 中。应严格定义：WARN 表示“可自愈的异常”（如临时通信重试），ERROR 表示“需要人工介入的故障”。

误区三：只关注 Loss 曲线，忽略“负梯度”现象。 在混合并行训练中，若某张卡的梯度计算延迟导致其梯度在 AllReduce 中迟到，优化器会使用陈旧梯度更新，表现为 Loss 在局部震荡。此时应监控 gradient_skew 指标（各 rank 梯度时间戳差异），而非仅看 Loss 均值。

复盘清单：

  • 是否所有日志均包含 rank 与 event 字段？能否通过一条命令过滤出某张卡的全部事件？
  • 监控面板是否包含“通信耗时 / 总步时”的占比图？该指标是发现慢节点的最敏感信号。
  • 是否设置了 多指标联合告警？例如“GPU 利用率低 + 磁盘读速低”组合触发，而非单指标阈值告警。
  • 日志保留策略是否支持 72 小时回溯？大规模训练故障往往在数小时后才暴露，需保留原始日志用于事后分析。

最后，监控体系的建设应遵循“先有日志，再谈监控”的顺序。若日志中无法回答“训练中断前最后 10 秒每张卡在做什么”，那么任何高级可视化工具都是空中楼阁。建议从本章的结构化日志规范起步，逐步叠加指标采集与关联分析，最终形成一套能够自动预警“静默故障”的闭环体系。

← 上一章 📖 返回目录 下一章 →