2026/7/23大约 6 分钟
针对大模型训练，SRE 必须构建一套“分层监控指标体系”。我为你梳理出了所有你在监控盘（Grafana）、日志和告警中需要死死盯住的硬核指标，分为三大核心监控纵深：
一、 GPU 硬件与算力监控（显卡到底在干嘛）
这是最底层的监控，直接反映了真金白银买来的算力有没有在轰鸣。
1. GPU Utilization (GPU 核心利用率)
- 监控什么： 显卡芯片（CUDA Core/Tensor Core）被占用的时间比例。
- SRE 避坑指南： 这个指标极具欺骗性！ 哪怕 GPU 只是在慢吞吞地从内存读数据，或者在等网络发小纸条，它的利用率也可能显示为 100%。所以它只能用来判断 GPU 有没有在运行，不能用来评估训练效率。
2. GPU Power Usage & Throttle (功耗与降频告警)
- 监控什么： 显卡当前的实际功耗（瓦数 W），以及是否触发了
Throttle（由于过热或供电不足导致的官方强制降频）。 - SRE 实战价值： * 判断真干活还是假干活： 真正的 BF16 矩阵大爆发计算时，GPU 功耗会瞬间拉满到最大（比如单卡 400W-700W，俗称“跑满了”）；如果卡住了或者在摸鱼，功耗会掉到几十瓦。
- 硬件故障排查： 如果某张卡的功耗长期比其他卡低 50W 以上，或者告警里出现了
Clocks Throttle Reason: Thermal，说明机房散热坏了或者该卡的硅脂干了，导致它因为太热而自己降频。由于分布式训练是“木桶效应”，这一张卡降频，会把整个集群的其他几百张卡全部拖慢！
3. NVLink / NVSwitch Bandwidth & Error Rate (机内高速总线监控)
- 监控什么： 机内卡与卡之间走 NVLink 的每秒吞吐量，以及 CRC 错误率。
- SRE 实战价值： 如果发现某个训练任务速度暴跌，查这个监控，要是看到 NVLink 带宽掉到了 0，或者 Error 计数在疯狂飙升，说明主板物理损坏、硬件松动，或者驱动掉线，导致通信降级成了奇慢无比的 PCIe。
二、 显存（VRAM）深度解剖监控（揪出显存刺客）
当算法同学频繁跑来找你报 CUDA Out of Memory 时，你必须打开这个监控盘，告诉他显存到底被谁吃掉了。
1. Dedicated VRAM Used (已分配物理显存)
- 监控什么： 显卡当前实打实被占了多少个 GB。通常在训练启动后会维持在一个极高的水平（比如 80GB 的卡被占了 78GB）。
2. PyTorch Reserved Memory / Cache (PyTorch 预留缓存)
- 监控什么： PyTorch 内部的显存垃圾回收池（Memory Caching Allocator）。
- SRE 深度原理解析： PyTorch 为了避免频繁向显卡申请/释放显存（这非常耗时），它会采用“占山为王”的策略——向显卡申请了一大块显存后，哪怕某个张量用完了，PyTorch 也不会把空间还给操作系统，而是把它放进自己的 Cache 池子里，留给下一个张量用。
- 监控看点： 真正的物理 OOM 往往是因为这个 Cache 池子里碎片太多。如果你看到
Reserved Memory很高，但Active Memory（正在干活的张量）很低，说明显存碎片化极其严重。这时候就需要让算法去调用torch.cuda.empty_cache()来强行打扫战场。
三、 网络与通信监控（SRE 的绝对雷区）
大模型多机训练，80% 的性能损耗和卡死都出在网络上。
1. RDMA / InfiniBand / RoCEv2 Net Traffic (万兆跨机网卡流量)
- 监控什么： 跨机网卡（比如你之前看到的 200G 网卡）的输入/输出（TX/RX）速率。
- SRE 实战价值： 在反向传播（Backward）阶段，由于全网都在疯狂做
AllReduce或者是 FSDP 的ReduceScatter，网卡流量会瞬间拉出几个高耸的波峰，直接打满 200G 带宽。如果波峰没有出现，或者非常微弱，说明计算和通信根本没有重叠（Overlap 失败），显卡在大把大把地浪费时间等网络。
2. Network Retransmission & Drop Rates (网络重传与丢包率)
- 监控什么： 交换机和网卡侧的
RoCEv2 / IB丢包计数、重传计数。 - SRE 的红色警报： 这是大模型集群最恐怖的隐形杀手！ 传统的 Web 网页丢个包，用户顶多觉得卡了 0.1 秒；但大模型的 NCCL 是一套绝对不容忍任何瑕疵的环形拓扑。一旦跨机网络发生哪怕 0.01% 的丢包，就会引发大面积的重传，导致整个 NCCL 通信环路彻底“死锁”。表现在监控上，就是网络流量瞬间归零，整个训练任务直接 Hang 死（假死）。
四、 存储与数据加载监控（防止“后勤跟不上”）
1. Data Loader / Disk Read IOPS & Bandwidth (磁盘读取读取瓶颈)
- 监控什么： 训练集（包含海量文本或图片的那些大包）从你本地的 NVMe 固态硬盘（或者 NAS 共享存储）读取到内存的速度。
- SRE 实战价值： 如果发现 GPU 功耗经常有规律地“每隔几秒就掉到 0 几秒，然后又飙上去”，去看这个指标。90% 是因为磁盘读数据太慢、或者 PyTorch 的
num_workers（数据加载线程数）配小了，导致显卡算完了一步，下一箱‘粮食’还没从硬盘里搬出来，显卡只能被迫停工。
🛠️ SRE 终极监控告警大盘配置模版
如果你去配置公司的 Grafana 看板，最完美的 LLM 训练监控布局应该长这样：
- 【红线告警区】：
GPU Drop（某张卡突然在系统里消失了）、NVLink Error > 0、Network Drop Rate > 0%$\rightarrow$ 这类告警一旦触发，必须立刻电话叫醒运维，因为这意味着整个训练集群已经瘫痪在烧钱了。 - 【性能调优区】：
MFU（算力利用率）$\rightarrow$ 长期低于 40% 提示优化；GPU Power$\rightarrow$ 出现周期性大幅下坠提示有存储或网络瓶颈。 - 【容量规划区】：
VRAM OOM Prediction$\rightarrow$ 监控显存增长曲线，如果在前向传播前几个 Batch 显存就踩到了 98% 的红线，提前预警算法准备迎接 OOM。
把这一套监控建起来，你不仅能对你们那台 8 卡服务器了如指掌，未来就算去管 1000 张卡的超级数据中心，底层也是完全一模一样的逻辑！
在我们今天梳理的这一整套监控里，哪一个指标（比如功耗降频、显存预留、网络丢包）最让你感到意外，或者很想知道它在物理硬件上到底是怎么发生的？