2、基础概念：吞吐量、延迟、利用率、MFU、HFU等核心指标的定义与计算方法

在诊断大模型训练瓶颈之前，必须先建立一套统一的“度量语言”。同一块 GPU、同一份代码，在不同口径下可能得出完全相反的结论：有人看到“利用率 95%”就认为已经压满，有人却指出 MFU 只有 38%，仍有大量优化空间。原因在于这些指标衡量的是不同层面的东西——硬件是否忙碌、算力是否真正用于有效计算、数据供给是否跟得上。本节把吞吐量、延迟、利用率、MFU、HFU 这几个核心指标的定义、计算方法和相互关系讲清楚，为后续的瓶颈定位提供判据。

一、吞吐量与延迟：一对相互制约的指标

吞吐量（Throughput）指单位时间内系统完成的有效工作量。在大模型训练中，最常用的口径是 tokens/s（每秒处理的 token 数）或 samples/s（每秒处理的样本数）。它衡量的是“整体产能”，直接决定一次训练要跑多久、要花多少钱。

延迟（Latency）指完成一个最小工作单元所花费的时间。训练场景下常见口径包括：单步迭代时间（step time，单位 ms/step）、单次前向时间、单次反向时间、以及端到端的首 token 时间。延迟衡量的是“响应速度”，它决定了流水线能否被填满、通信能否被掩盖。

两者的关系可以用一个直观公式表达：

吞吐量 ≈ 全局批大小 × 序列长度 / 单步迭代时间
tokens/s ≈ (global_batch_size × seq_len) / step_time(s)

这个公式揭示了一个关键事实：吞吐量不是独立变量，它由批大小和单步时间共同决定。增大批大小通常能提升吞吐量，但会占用更多显存、可能影响收敛；缩短单步时间则依赖计算、通信、数据加载的整体优化。因此，看到吞吐量低时，第一步不是盲目调参，而是拆解：是批大小受限，还是单步时间过长？

二、利用率：硬件到底有多忙

利用率（Utilization）通常指在采样窗口内，硬件单元处于活跃状态的时间占比。GPU 场景下常见的有 SM 利用率、显存带宽利用率、Tensor Core 活跃度等。它回答的问题是：“这块硬件有没有闲着？”

但利用率有一个致命陷阱：忙碌不等于高效。一个 SM 可能一直在执行访存指令、分支判断或小算子，利用率显示 90% 以上，但真正的矩阵乘算力却远未跑满。这就是为什么仅看 nvidia-smi 的 GPU-Util 容易误判——它反映的是“有没有 kernel 在跑”，而不是“算力有没有被有效利用”。

三、MFU 与 HFU：算力效率的黄金标尺

MFU（Model FLOPs Utilization，模型浮点运算利用率）定义为：模型实际需要的浮点运算量除以硬件理论峰值算力与时间的乘积。它衡量的是“有效模型计算占硬件理论峰值的比例”。

HFU（Hardware FLOPs Utilization，硬件浮点运算利用率）则把重计算（activation recomputation）等额外计算也算进去，衡量的是“硬件实际执行的全部浮点运算占理论峰值的比例”。

两者的计算公式如下：

MFU = (模型理论 FLOPs / 单步时间) / 硬件峰值 FLOPS
HFU = (硬件实际执行 FLOPs / 单步时间) / 硬件峰值 FLOPS

其中：
模型理论 FLOPs ≈ 6 × N × tokens   （N 为参数量，前向 2N + 反向 4N）
若开启重计算，实际 FLOPs 会高于理论值，此时 HFU > MFU

举例说明：一块 A100 的 BF16 峰值约为 312 TFLOPS。若某模型单步处理 100 万 token、参数量 70 亿，则理论 FLOPs ≈ 6 × 7e9 × 1e6 = 4.2e16 FLOPs。若单步耗时 2 秒，则实际算力 = 4.2e16 / 2 = 2.1e16 FLOPS = 21000 TFLOPS，MFU = 21000 / 312 ≈ 67%。这是一个相当健康的水平；而如果 MFU 只有 15%，说明大量算力被浪费在等待、通信或低效算子上。

MFU 与 HFU 的差值本身也是重要信号：差值越大，说明重计算带来的额外开销越高，通常意味着显存压力大、不得不牺牲算力换显存。此时优化方向可能是激活值分片、更高效的注意力实现，而不是继续堆硬件。

四、指标关系与典型参考区间

下面这张图展示了从“硬件理论峰值”到“有效模型吞吐”的逐层损耗关系，以及各指标所处的位置。

结合工程经验，不同规模训练的 MFU 参考区间如下表所示。注意这些数值会随模型结构、并行策略、序列长度和硬件代际变化，仅作为判断“是否异常”的粗略标尺。

五、案例与常见误区复盘

某团队在 8 卡 A100 上训练 13B 模型，观察到 GPU-Util 长期在 92% 以上，但吞吐量只有预期的一半。初步判断“硬件已压满”，准备扩容。进一步采集指标后发现：MFU 仅 18%，HFU 却达到 45%。这说明硬件确实在忙，但大量算力消耗在重计算上——由于显存不足，团队开启了全量激活重计算，前向被额外执行了一遍。真正的瓶颈是显存管理，而非算力不足。改用激活分片并调整并行策略后，MFU 提升到 41%，吞吐量翻倍，无需增加任何硬件。

这个案例集中体现了三个常见误区：

• 把利用率等同于效率：GPU-Util 高只说明有 kernel 在跑，不代表算力被有效利用。必须结合 MFU/HFU 一起看。
• 只看吞吐量不看延迟：吞吐量高但单步延迟波动大，往往意味着流水线气泡严重，长期看会拖累整体效率。
• 混淆 MFU 与 HFU：两者差值大时，优化方向应是减少无效计算（重计算、padding），而不是继续提升硬件峰值利用率。

掌握这些指标的定义与计算口径后，下一步就可以进入具体的瓶颈分类：当 MFU 偏低时，究竟是计算瓶颈、通信瓶颈、显存瓶颈还是数据瓶颈？这需要结合指标的时间序列特征和硬件计数器进一步定位。