2、性能指标定义：吞吐量、算力利用率、通信效率、显存占用、端到端耗时

做性能回归分析，第一步就是得把指标定义清楚。我见过不少团队，大家嘴上说着“性能变差了”，结果一聊发现，A说的吞吐量是每秒样本数，B说的吞吐量是每秒token数，根本对不上。所以，咱们先把这五个核心指标掰扯明白。

吞吐量，说白了就是“单位时间能处理多少样本”。在GPU集群训练里，我们通常用 samples/sec 来衡量。这个指标最直观，也最容易理解。

我个人习惯把吞吐量拆成两步看：

举个例子，假设单卡每秒能跑 100 个样本，你用 64 张卡做分布式训练，理想情况下集群吞吐量应该是 6400 samples/sec。但实际往往达不到，因为通信有开销、负载不均衡。嗯，这里要注意，吞吐量不是线性增长的。

核心公式：

集群吞吐量 = 单卡吞吐量 × GPU数量 × 并行效率

MFU，全称 Model FLOPS Utilization，模型算力利用率。这个指标我刚开始接触时也觉得有点绕，其实它就是衡量“GPU的理论算力被用了多少”。

你想想看，一张A100的理论算力是 312 TFLOPS（FP16），但实际训练时，因为内存访问、通信、算子调度等原因，你不可能跑满这个数。MFU 就是实际算力除以理论算力。

我在项目中遇到过，有些团队只看吞吐量，觉得每秒样本数上去了就万事大吉。结果一算MFU，只有 30% 多。说白了，GPU在摸鱼。这时候就得去优化算子、减少通信开销。

我的经验： MFU 在 50% 以上算及格，70% 以上算优秀。如果低于 40%，建议先做一轮算子级 profiling。

分布式训练里，通信是最大的瓶颈之一。通信效率，衡量的是“通信时间占总训练时间的比例”。

我习惯用两个子指标来看：

我曾经踩过一个坑：用 256 张卡训练一个大模型，通信占比飙到了 60% 以上。后来发现是 all-reduce 的拓扑没配好，改成 ring all-reduce 后，通信占比降到了 25%。

注意： 通信效率跟模型大小、batch size、网络拓扑都有关。小 batch size 下，通信占比会更高，因为计算时间短，通信开销相对变大。

显存占用，这个指标看似简单，但坑不少。很多人只看“显存用了多少 GB”，其实不够。

我建议关注三个维度：

峰值显存：训练过程中显存使用的最大值。这决定了你能不能跑更大的 batch size。
显存碎片率：显存碎片多了，明明总量够，但分配失败。我遇到过一次，显存还剩 10 GB，但分配 2 GB 的 tensor 都报 OOM，就是碎片搞的鬼。
显存带宽利用率：HBM 带宽是否被充分利用。如果利用率低，说明数据搬运效率差。

避坑指南： 我曾经因为没监控显存碎片，导致训练跑到一半突然 OOM，白白浪费了 3 天。后来加了碎片监控，再也没出过类似问题。

端到端耗时，就是从“开始训练”到“训练完成”的总时间。这个指标最综合，也最容易被忽视。

我习惯把它拆成三部分：

你想想看，如果端到端耗时是 10 天，其中数据加载占了 3 天，那优化数据 pipeline 比优化模型本身更划算。这就是性能回归分析的价值——找到真正的瓶颈。

这五个指标不是孤立的。我画了一张图，帮你理清它们的关系：

从这张图你能看出来，五个指标环环相扣。显存不够，你就得降 batch size，MFU 跟着掉，吞吐量也掉，最后端到端耗时反而增加。所以做回归分析时，不能只看单一指标。

说了这么多理论，实际怎么监控？我分享一个我常用的模板：

指标	监控工具	采样频率	告警阈值
吞吐量	TensorBoard / WandB	每 100 step	低于基线 10%
MFU	Nsight Systems / PyTorch Profiler	每 500 step	低于 40%
通信效率	NCCL 日志 / 自定义 hook	每 1000 step	通信占比 > 50%
显存占用	nvidia-smi / pynvml	每 10 秒	峰值 > 90%
端到端耗时	训练脚本日志	每次训练	超出预期 20%

小技巧： 我习惯把监控数据都打到同一个 dashboard 上，这样一眼就能看出哪个指标异常。比如吞吐量掉了，先看 MFU 是不是也掉了，再看通信占比是不是变高了，定位问题快很多。

好了，这五个指标的定义和关系就讲到这里。记住，指标是死的，但分析是活的。下次做回归分析时，别只盯着一个数看，五个指标一起上，才能找到真正的性能瓶颈。