效率度量：MFU、MBU、goodput 与成本

前四章给了物理量（算力、带宽、延迟、容量）、分析框架（Roofline）、精度、通信代价。这一章把它们组织成可汇报、可比较、可用来做决策的指标。

问题很实际：硬件工程师说 TFLOPS，框架工程师说 samples/s，服务工程师说 QPS 和 P99，老板说每月账单。同一个系统问题，四套语言，谁也说服不了谁。

第一步：先判断受限类型

所有指标选择的前提，是回答第四章的那个问题——算力受限还是带宽受限？

I = \frac{\text{FLOPs}}{\text{字节}} \quad \text{vs} \quad I_{\text{balance}} = \frac{P_{\text{peak}}}{B_{\text{peak}}}

受限类型	主指标	优化方向
计算受限（ $I > I_{\text{balance}}$ ）	MFU	更好的矩阵单元、降精度、减少冗余计算
访存受限（ $I < I_{\text{balance}}$ ）	MBU	融合、分块、增大批量、降精度
通信受限	通信占比、有效链路带宽	重叠、换并行策略、分层算法
数据受限	加速器空闲占比	预取、并发、GPU 侧解码

这一步搞错，后面所有数字都会误导人。 对一个访存受限的负载报 MFU，就像用体温计量血压。

计算侧：MFU 与 HFU

\mathrm{MFU} = \frac{\text{模型必要 FLOPs}}{P_{\text{peak}} \times T} \qquad \mathrm{HFU} = \frac{\text{实际执行 FLOPs}}{P_{\text{peak}} \times T}

MFU（Model FLOPs Utilization）：分子只算"模型数学上必需的运算"。
HFU（Hardware FLOPs Utilization）：分子算"硬件实际执行的运算"。

两者的差别主要来自激活重计算——为省显存而重做的前向计算，硬件确实算了，但模型不需要它。所以总有 $\mathrm{HFU} \ge \mathrm{MFU}$ ，差值就是重计算的代价（典型 25–35%）。

怎么选：

目的	用哪个
比较两个实现谁更高效	MFU（口径统一，不奖励做无用功）
判断硬件有没有被喂饱	HFU
对外汇报	必须注明是哪个

很多论文和博客不说清楚用的是哪个，导致数字不可比。看到一个"55% 利用率"，先问是 MFU 还是 HFU。

经验区间

场景	MFU
单卡小模型，实现良好	50–70%
单机八卡	45–60%
千卡级训练，工程优秀	35–50%
万卡级，含故障与 straggler	25–40%
MoE（all-to-all 开销大）	20–35%
实现有问题	< 20%

低于 30% 通常意味着有明确的系统问题，按第二章的排查表逐层查。

访存侧：MBU

\mathrm{MBU} = \frac{\text{实际读写字节数} / T}{B_{\text{peak}}}

访存受限负载的对应指标。自回归解码的 MBU 能到 60–80% 就算不错，它直接决定单请求生成速度。

一个有用的心算：自回归生成时，每产出一个 token 需要把全部权重读一遍（第九章会解释为什么）。若 MBU 是 70%，单请求速度约为

0.7 \times \frac{\text{显存带宽}}{\text{模型字节数}}

代入 70B 模型（BF16，140 GB）与 3.35 TB/s：约 17 tokens/s。与实测对比，能立刻判断实现有没有问题。

吞吐

单位时间完成的工作量。训练用 samples/s 或 tokens/s，推理用 QPS 或 tokens/s。

比较吞吐时还要统一：序列长度、批量、精度、分词器。任何一项不同，数字就不可比。

延迟

永远看分布，不看平均。

分位	用途
P50	典型体验
P95	常规 SLO
P99	用户流失的临界点
P999	告警与容量规划

一个服务平均延迟 100 ms 听起来不错，但如果 P99 是 5 s，就有 1% 的请求几乎不可用。而在一个页面要调十个服务的场景下，几乎每个用户都会碰上至少一次 P99：

P(\text{至少一次慢}) = 1 - 0.99^{10} \approx 9.6\%

十个服务，近一成用户受影响。这就是为什么大规模系统关注尾延迟远超关注平均值。

推理的两个特化延迟指标：

TTFT（Time To First Token，首 token 延迟）：从收到请求到吐出第一个 token，影响"感觉响应快不快"。
TPOT（Time Per Output Token，每输出 token 延迟，也叫 ITL）：之后每产出一个 token 的平均耗时，影响"生成流畅不流畅"。

两者由生成过程的两个不同阶段决定，第九章会拆开讲。

两者是独立的 SLO，可以分别优化，也会互相干扰——第九章会讲这个张力。

Goodput：有效产出占比

\mathrm{Goodput} = \frac{\text{有效训练时间}}{\text{总时间}}

损失来自故障恢复、检查点保存、straggler、重启、预热。万卡训练中它可能只有 70–90%。

Goodput × MFU 才是作业的真实资源效率。 对比两个集群：

	MFU	Goodput	有效效率
集群 A（快但不稳）	45%	70%	31.5%
集群 B（慢但稳）	38%	95%	36.1%

B 更好。这个对比解释了为什么大规模训练团队会把大量精力投在可靠性而非峰值性能上——在万卡规模，"不挂"比"快"稀缺得多（回到第一章的三类工作）。

集群层：三层乘积

单个作业的效率之上，还有集群层的浪费：

\text{真实效率} = \underbrace{\text{分配率}}_{\text{卡有没有被领走}} \times \underbrace{\text{分配后使用率}}_{\text{领走后有没有在算}} \times \underbrace{\mathrm{MFU} \times \mathrm{Goodput}}_{\text{算得好不好}}

举个真实感的例子：分配率 85%、分配后使用率 60%、MFU 40%、goodput 90%，则

0.85 \times 0.60 \times 0.40 \times 0.90 \approx 18\%

买了一百张卡，实际只有十八张在做有效计算。 而多数团队只盯着 MFU 那一项优化。

第二项（分配后使用率）通常是最大的黑洞：交互式开发环境占着卡不跑任务、作业失败后资源未释放、排队碎片。让浪费可见，通常比任何调度算法都有效。

成本与能耗

所有优化的最终裁判：

\text{单位成本} = \frac{\text{硬件折旧} + \text{电力} + \text{网络存储} + \text{运维}}{\text{有效产出}}

分母按负载而定：训练是"完成的训练任务"，推理是"百万 token"或"百万请求"。

能耗侧看 PUE（机房总能耗 ÷ IT 设备能耗）——先进液冷可到 1.1 以下，传统风冷机房常在 1.4–1.6。同样的电费，PUE 1.1 比 1.5 多出近三成给计算。

一个反直觉的事实：加速器在峰值功耗的 70–80% 时能效往往最高。无脑拉满功耗上限，性能提升有限而功耗显著上升，每焦耳的产出反而下降。

负载特化指标

负载	主指标	辅助指标
大模型训练	tokens/s/GPU、MFU	goodput、通信占比、step 时间 P95
大模型推理	TTFT、TPOT、tokens/s	MBU、并发数、$/1M token
推荐训练	samples/s、带宽利用率	embedding 命中率
推荐推理	QPS、P99	缓存命中率、$/万次请求
视觉训练	samples/s	加速器空闲占比、数据管道吞吐
科学计算	强扩展效率	通信占比、双精度利用率

第八章会解释这些负载为什么需要不同的指标。

决策表：症状 → 看什么

症状	先看	再看
训练比预期慢	加速器空闲占比、MFU	通信占比、数据管道吞吐
训练时快时慢	step 时间分布、各 rank 差异	straggler、网络抖动、降频
扩容后没变快	强扩展效率	集合通信代价、拓扑映射
推理吞吐上不去	是首 token 阶段还是逐 token 阶段受限	对应看 MFU 或 MBU
推理延迟不达标	P99 分解（排队 / 首 token / 逐 token）	批处理策略、并发上限
显存 OOM	状态 vs 激活占比	分片度、重计算、精度
成本太高	三层乘积的每一项	量化、批处理、实例类型
集群利用率低	分配率与分配后使用率	排队碎片、占坑、失败率

四个常见误用

用 nvidia-smi 的 GPU-Util 判断效率。 那个数字只表示"有内核在跑"——一个只占 1% 计算单元的内核也会显示 100%。要看计算单元活跃度、矩阵单元利用率、显存带宽，这些要用专门的采集工具。

跨口径比较。 A 报单卡，B 报全集群，C 用不同分词器——三个数字不可比。比较前统一：每卡、每秒、同分词器、同精度、同序列长度。

只报最好的一次。 分布式训练的 step 时间有长尾，报最快的 step 会系统性高估。报中位数与 P95。

把 MFU 当作 KPI。 MFU 可以通过增大批量、减少通信、关掉重计算来刷高，但这些可能损害收敛或稳定性。最终 KPI 是"单位成本的有效产出"，MFU 只是它的一个分量。 优化 MFU 到 50% 但 goodput 掉到 60%，是净亏损。

本章要点

先用 Roofline 判断受限类型，再选指标；选错指标后面全错。
MFU 只对计算受限负载有意义；访存受限看 MBU。HFU − MFU 是重计算的代价（典型 25–35%）。
吞吐必须注明单卡还是集群；延迟必须报分位数，P99 比平均值重要得多。
Goodput × MFU 才是作业真实效率；集群层还要再乘分配率与分配后使用率，四项连乘常常只剩不到两成。
加速器在峰值功耗 70–80% 时能效往往最高。
四个误用：nvidia-smi 不是效率指标、跨口径比较、只报最好一次、把 MFU 当 KPI。