在 20.1–20.4 节完成基础环境、容器化、调度系统和训练框架的部署之后，算力中心已经具备“跑任务”的能力。但真正进入生产状态后，集群会暴露出大量在搭建阶段不易察觉的问题：某张 GPU 的显存带宽悄悄下降、InfiniBand 端口出现 CRC 错误、训练 loss 突然发散……如果没有一套完善的监控运维平台，这些隐患最终会以 “任务静默失败三天，浪费数万元算力” 的形式被发现。
本节介绍监控体系的三个核心维度，以及如何将它们整合为一套可落地的告警与可视化方案。
一、GPU 状态监控：不只是看“利用率”
GPU 是算力中心最昂贵也最容易出故障的部件，监控必须覆盖健康度与效率两个层面。
（1）基础健康指标
- 温度：核心温度（GPU Temperature）与显存温度（Memory Temperature），超过 85℃ 需告警，超过 90℃ 显卡会自动降频甚至保护性关机。
- 功耗：当前功率与设计功耗（TDP）的比值，突然飙升或异常偏低都可能预示硬件损伤。
- 风扇转速：风冷方案下的基础指标，异常高转速意味散热通道堵塞。
- PCIe 链路状态：链路宽度（如 x16 降为 x8）、带宽降级、可纠正/不可纠正错误（CE/UE Error）数量。这常是 GPU 间歇性性能毛病的根源。
（2）显存与计算利用率
- 显存占用（Memory Used）：除跟踪绝对占用量（GB），还要关注显存碎片率。某些推理任务会因碎片化导致 OOM，但总占用却显示仍有空闲。
- SM 核心利用率：nvidia-smi 中的
GPU Utilization仅代表过去 1 秒内有计算任务的比例，不等于计算效率。更高的指标是 Tensor Core 利用率（需 nccl 或 DCGM 采集），以及 FP32/FP16 活跃度，可反映模型是否真正充分利用硬件。 - 显存带宽利用率：许多大模型训练是“带宽瓶颈”型，监控 HBM 带宽占用比（%）比单纯看算力利用率更能定位性能木桶。
（3）常见采集工具
- DCGM（Data Center GPU Manager）：NVIDIA 官方监控库，通过
dcgm-exporter输出 Prometheus 格式指标，覆盖 SM 占用、显存带宽、温度、功耗、ECC 错误等。 - nvidia-smi + 自研脚本：适合小规模集群快速验证，但不适合规模化自动告警。
- 国产 GPU（如昇腾）配套的 npu-smi、npu-exporter 等工具。
实用建议：不要等到训练任务报错再去查 GPU。生产环境必须对“GPU 温度 > 85℃”、“ECC 错误 > 0”、“链路降速”等指标设置 7×24 告警，且告警通道至少保证即时通知到运维工程师。
二、网络与存储监控：隐藏的算力杀手
大模型分布式训练的通信开销可占单轮迭代时间的 30%–50%。网络瓶颈往往伪装成“GPU 利用率低”，因此需要专门的监控维度。
（1）网络监控
- InfiniBand / RoCE 端口状态：端口速率、链路状态（Up/Down）、CRC 错误计数、符号错误计数。哪怕只是偶尔的 CRC 错误，都能因重传导致 allreduce 时间翻倍。
- RDMA 传输带宽与延迟：使用 perftest 工具逐节点打流并记录历史，监控是否存在性能退化。
- 光模块 / 光缆状态：接收光功率（Rx Power）、发送光功率（Tx Power）、温度、偏置电流。光模块老化会导致误码率上升。
- 拥塞与重传：从交换机侧监控 PFC（Priority Flow Control）帧计数、ECN 标记数等。网络拥塞会直接拖垮分布式训练。
（2）存储监控
- 并行文件系统（Lustre/GPFS/JuiceFS）：
- IOPS 与带宽：元数据服务器（MDS）的请求速率，对象存储服务器（OSS）的读写带宽。训练 Checkpoint 保存时的瞬间写入压力极大，需确保带宽余量。
- 慢盘与错误：磁盘 I/O 延迟（await）、坏块计数、文件系统错误数。
- 元数据负载：训练任务会高频读取大量小文件（如 parquet 数据片），元数据服务压力是容易被忽视的性能瓶颈。监控 MDS CPU 使用率、请求队列深度至关重要。
- 存储容量与增长趋势：Checkpoint 和训练日志会快速打满存储，需提前预警，并设置自动清理策略。
实用建议：对于百卡以上集群，优先部署 Infiniband Subnet Manager 的监控插件和罗森（RoCE）集群的 Grafana 面板，统一展示网络健康度。存储端至少配置两个告警：“任意 OSS 磁盘延迟超过 50ms” 和 “存储卷使用率超过 80%”。
三、训练任务全链路监控与告警
GPU、网络、存储的指标是“设备级”的，真正对开发者有价值的是“训练任务为什么慢了 / 为什么挂掉”。需要从任务视角打通所有层级。
（1）任务级性能指标
- 每轮迭代耗时（Iteration Time / Training Step Time）：如果突然增加 20% 以上，可能对应某节点网络掉速、存储卡顿或 GPU 卡住了。
- 吞吐量（Tokens per Second 或 Samples per Second）：整体效率直接对应算力成本。
- MFU（Model FLOPs Utilization）：理论峰值算力的实际利用率，是集群综合性能的“金标准”。当 MFU 从 50% 掉到 40%，一定隐藏着通信或 I/O 瓶颈。
- 梯度范数（Gradient Norm）：用于监控训练健康度。norm 突然爆炸意味着可能发散，需要自动触发梯度裁剪或暂停任务。
- Loss 曲线：包括 training loss 和 validation loss。除常规下降外，需自动检测“Loss 长时间不下降”（plateau）和“Loss 突然 NaN”等异常。
（2）分布式通信专用指标
- AllReduce 耗时：各节点间同步梯度的总时间，可通过 nccl 的调试输出或 PyTorch Profiler 获取。
- 通信量与带宽：NCCL 统计的总通信字节数和平均带宽，对比 InfiniBand 理论带宽，评估实际利用率。
- 流水线气泡（Pipeline Bubble）：如果使用流水线并行，可以通过 GPU 空闲等待时间来估算，反映切分策略是否合理。
（3）健康检查与日志告警
- 进程存活：所有训练节点上的主要训练进程（如 torchrun 启动的 worker）是否正常运行。
- OOM/Error 监控：自动抓取 CUDA OOM、NCCL timeout、文件读取失败等关键日志，并通过正则匹配触发告警。
- Checkpoint 保存状态：定期检查最新 checkpoint 的时间戳，防止因存储满或权限问题导致“训练跑了一个月，但最后一次保存是两周前”。
四、平台化方案：实际搭建建议
将上述所有指标落地为可用平台，建议分层设计：
| 层级 | 工具链参考 | 职责 |
|------|-----------|------|
| 采集层 | DCGM-exporter、Node Exporter、InfiniBand Exporter、Lustre Exporter、自定义日志采集器（Filebeat） | 从每台节点采集 GPU/CPU/网络/存储指标和日志 |
| 存储与聚合层 | Prometheus（时序指标）+ Loki / Elasticsearch（日志） | 统一存储，支持高效查询和告警规则 |
| 可视化层 | Grafana 仪表板，分角色设计：管理员看全集群状态，用户看自己任务详情 | 降低信息噪音，快速定位问题 |
| 告警层 | Alertmanager，根据严重等级分通道（企业微信、钉钉、邮件、短信），设置静默与升级策略 | 避免告警风暴，确保关键事件不遗漏 |
| 可观测平台 | 有条件的可引入 OpenTelemetry 做训练全链路 Trace（根因分析），或直接使用 NVIDIA 的 NVIDIA DGX Station / Base Command 等成熟方案 | 减少自研成本，提供更深层性能分析 |
实用最低配置：即使资源有限，至少部署 DCGM-exporter + Prometheus + Grafana 先管住 GPU，再用 简单脚本轮询训练日志中的 OOM/NaN 并发送告警。这能覆盖 80% 的致命故障。
五、告警设计的核心原则
- 区分告警重要性：GPU 温度高、存储即将满 必须实时通知；GPU 利用率短暂下降可标记为“注意”，不做紧急打扰。
- 收敛规则：对同一故障（如一个节点网络断开）可能引发的上百条关联告警进行压缩合并，只发一条摘要。
- 关联上下文：告警内容必须包含：时间、涉及的节点/任务名、具体指标值和阈值、建议排查步骤。避免让值班人员收到一条“GPU 97℃”后无从下手。
- 任务同步：将监控数据与调度系统（Slurm / Kubernetes） 的作业信息关联，自动识别“哪些任务受此告警影响”。
六、小结
监控运维平台是算力中心上线前的“最后检查项”，却是长久稳定运行的第一道防线。核心要记住：
- GPU 是心脏，网络是血管，存储是胃：任何一个器官出问题，整个训练任务都会“生病”；
- 从任务视角反推设备监控：不要为了监控而监控，每个指标都应该能回答“训练为什么受影响”；
- 告警是最后一道保险，自动恢复才是第一追求：在 21.5 节（算力利用率提升策略）中，将进一步讨论如何利用监控数据实现任务自动重新调度、坏卡自动隔离等自我修复能力。
这一层建设好了，你才能在深夜睡个安稳觉。