上一篇聊完“1P算力”到底是什么，初次接触这个概念，可能还会常被问到一句话：
“那这1P，跑起来是不是真的能打满？”
答案可能有点扎心：大概率打不满，而且差得不少。 一个标称1P（FP16）的顶级AI卡，真正拿去训练大模型时，能稳定发挥出0.3P到0.5P，就已经算是业内的好成绩了。
更让人困惑的是：打开 nvidia-smi 看，GPU利用率不低，风扇在转，功耗上去了，账单更是一秒没停。但模型每秒吃进去的token，就是比按峰值算出来的少一大截。这中间差掉的0.5P到0.7P，去哪儿了？
一、先认识这个词：MFU
MFU，全称 Model FLOPs Utilization，模型算力利用率。这个词是Google在2022年的PaLM论文里正式提出并普及开的，计算公式如下：
MFU = 模型每秒真正完成的理论计算量 ÷ 硬件每秒的理论峰值计算量
它问的不是“GPU忙不忙”，而是一件更直接与成本相关的问题：你花钱买来的理论峰值算力里，有多少真的变成了模型前向和反向传播里的有效数学计算。
这里有个容易搞混的地方：MFU算的是“训练模型真正需要的那部分计算”跑了多快，不包括为了省显存而做的“重计算”（rematerialization，也叫activation checkpointing）。那部分计算确实发生了，但只是拿计算换显存，并不产出“新的模型进展”。业内还有个更宽松的指标叫硬件算力利用率（HFU），会把这部分也算进去，数字自然更好看一些。
PaLM论文里正好给了一组可以直接对比的数字：PaLM 540B的MFU是46.2%，HFU是57.8%，两者相差11.6个百分点。这11.6个百分点，就是重计算占用掉、但没有直接产出“新模型进展”的那部分算力——PaLM团队为了拿到更高的可行batch size，主动选择了用重计算换显存，这笔账在HFU里被算成“有效利用”，但在MFU里被刨除了。同一次训练，换一个统计口径，利用率数字能差出十几个百分点。这也是为什么看到“算力利用率”这个词时，第一件事该问的是：这个数字算的是MFU还是HFU？ 两者不是一回事，混着比较容易被数字表面的高低误导。也就是说，MFU算的是一笔“最不掺水”的账。
GPU利用率 ≠ MFU
第一次接触这个话题时会犯一个错：把 nvidia-smi 里的 GPU utilization 当成了MFU。
NVIDIA官方文档对 utilization.gpu 的定义是：在采样周期内，有一个或多个kernel正在GPU上执行的时间占比。也就是说，只要有kernel在跑，它就可能显示“很忙”，但这不代表Tensor Core被充分喂满，更不代表这些计算都在实实在在地推进模型训练。
这有点像餐厅后厨：灯一直亮着，不代表每口锅都在高效出菜。有人在切菜，有人在等外卖单，有人在找调料，后厨确实没闲着，但出菜速度还是上不去。MFU看的是出菜速度，GPU utilization只是看后厨灯亮没亮。
二、真实世界的数字长什么样
通过几个业内公开的训练案例，感受一下差距：
| 模型/系统 | 硬件 | MFU |
|---|---|---|
| GPT-3 | V100 | 约21.3% |
| Gopher | TPU | 约32.5% |
| Megatron-Turing NLG 530B | A100 | 约30.2% |
| PaLM 540B | TPU v4（6144卡） | 约46.2%（HFU约57.8%） |
| Llama 3 405B | 最高16K张H100 | 约38%–43%（BF16） |
| NVIDIA Megatron-Core 弱扩展基准 | H100集群 | 约42%–50%（模型变大MFU会升高） |
| MegaScale（字节，175B模型，12288卡） | GPU | 约55.2% |
| DeepSeek-V3（671B MoE，FP8） | H800 | 约21%–23%（不同估算口径） |
PaLM之所以被反复拿出来当标杆，是因为它把MFU这个概念系统化了，46.2%在当时是相当亮眼的跃升，代表着“标称1P的卡，实际发挥出了0.46P”。
从这些公开案例看，训练大模型能稳定做到35%–45%已经不差，50%以上基本可以算很强的系统工程成绩。
NVIDIA自己公布的Megatron-Core基准也印证了这一点：不同规模GPT模型的弱扩展测试里，MFU大多落在42%到50%之间。但一旦强扩展到更多GPU、通信开销暴露出来，MFU会从47%掉到42%。卡越多，越难打满。
DeepSeek-V3也很值得看。它是第一个大规模用FP8混合精度训练的模型，官方披露了671B总参数、37B激活参数、14.8T训练token和2.788M H800 GPU小时，但没有直接披露MFU。表里的21%–23%，是第三方基于公开数据和不同峰值口径做的估算。这个数字不是在说DeepSeek团队工程能力差，恰恰相反，他们把跨节点MoE通信几乎做到了“计算通信完全重叠”，是公开资料里工程最激进的方案之一。它更适合说明另一件事：精度越低、峰值算力翻得越高，MFU这个分母变大后，数字反而更难看。
三、怎么估算：一个粗略但好用的公式
如果是dense Transformer训练，业内常用的近似是：每个token大约需要 6 × 参数量 的FLOPs（前向约2倍参数量，反向约4倍参数量）。用这个数乘上每秒处理的token数，就能估出模型每秒完成了多少理论计算量，再除以“GPU数量 × 单卡峰值FLOPs”，就是MFU。这个公式主要适合dense Transformer的粗估；MoE、超长上下文和特殊attention结构，要按具体架构再修正。
比如一张标称1P的卡，如果训练时实际只贡献了300 TFLOPS的有效模型计算，那MFU就是30%；如果是400 TFLOPS，就是40%。这比单看GPU utilization更接近训练成本的真相。
四、那0.5P到底去哪了？
1. 模型或batch喂不满卡
模型太小、batch太小、序列太短，矩阵乘法（GEMM）规模不够大，kernel启动和内存访问的固定开销就会显得突出。反直觉的是：大模型有时反而更容易把算力吃满，因为GEMM更大、算术强度更高，这也是Megatron-Core基准里“模型变大MFU会升高”的原因。
2. 内存墙：算得快，喂不饱
GPU的计算核心和显存之间搬数据的速度（显存带宽）跟不上计算速度，是最常见的瓶颈。attention、LayerNorm、embedding、optimizer这些操作很多时候更像在“搬数据”而不是在“做数学”，算力核心经常处于空转等待的状态。
3. 通信开销：卡越多，越“聊得慢”
大模型训练要动用成千上万张卡协同工作，需要频繁做all-reduce、all-gather、reduce-scatter同步梯度，尤其是MoE架构还要处理跨节点专家路由。这些通信时间会实打实地挤占计算时间。DeepSeek-V3的技术报告里提到，他们专门拿出132个流处理器（SM）里的20个常驻处理通信，才接近做到计算通信完全重叠。如果粗略按SM数量线性折算，20/132约等于15%。这部分资源常驻通信后，留给模型计算的账面空间会先少一截。
4. 流水线气泡与硬件不稳定
千卡、万卡级别的同步训练有个“木桶效应”：只要有一张卡慢了（掉队者，straggler），或者流水线并行里某个环节没排满（气泡，pipeline bubble），整个集群都得等它。
更现实的是硬件故障率。Meta的Llama 3 405B论文提到，用最高16384张H100训练，54天预训练快照里一共发生了466次job interruption，其中419次是非预期中断，约78%和已确认或疑似的硬件问题有关。训练到这个规模，MFU不只是kernel优化问题，也是网络、调度、故障恢复和运维问题。大规模训练里，失败不是偶发事件，而是系统的一部分。
5. 标称口径本身有差异
有些卡的宣传数字用了FP8，有些用了稀疏性，有些用的是Tensor Core理想峰值。如果实际训练跑的是BF16，或者kernel没有吃到对应的精度和稀疏条件，就不能直接拿最高宣传数字当分母。用错峰值，算出来的心理落差会更大。
五、MFU 的真实用法：把规格书拉回训练现场
买卡时看峰值FLOPs，只能知道天花板有多高。训练时看MFU，才知道你现在站在几楼。
举个例子：一家公司说自己有10,000P算力，但真实训练MFU只有30%，那有效模型算力大概就是3,000P。另一家公司标称只有7,000P，但MFU做到45%，有效模型算力反而接近3,150P。硬件数量不是全部，软件栈、并行策略、网络拓扑和运维能力会直接改变这笔账的含金量。 这也是为什么大模型公司越来越像基础设施公司：把1P变成0.45P还是只能变成0.25P，到了万卡规模，几个百分点的MFU提升，可能就是几百万美元级别的差别。
对大多数团队来说，MFU也有一个很实际的用法：别一上来就迷信更贵的卡。 如果当前训练MFU只有15%到25%，可以先看batch大小、序列长度、数据加载管线、混合精度设置、FlashAttention、编译优化、通信overlap和并行切分策略。很多时候，先把系统调顺，比直接再买一批卡更划算。
但也别把MFU当成唯一目标。为了追高MFU把batch调到不利于收敛，或者为了减少checkpoint牺牲可靠性，最后可能只是让数字好看。一个比较稳的判断框架是：nvidia-smi 告诉你GPU有没有在忙，tokens/s告诉你模型吐得快不快，MFU告诉你买来的峰值算力有多少变成了有效训练。训练是否稳定收敛、故障恢复得快不快，也要放在一起看。一个MFU 70%但训练发散的任务，价值远不如一个MFU 35%但稳定收敛的任务。
写在最后
回到开头的问题：标称1P的卡，实际训练时大概率只有0.3P到0.5P在真正干活，中间被内存带宽、通信开销、硬件故障、生态成熟度和标称口径这几层现实“税收”啃掉了一半左右。
这不是哪家厂商在忽悠，而是大规模分布式训练这件事本身的物理与工程现实。从GPT-3的21%到PaLM的46%，再到MegaScale公开案例里的55%，过去几年大家一直在朝这道“打满”的题努力。每提升几个百分点，背后都是实打实的系统工程突破。
真正贵的不是那0.7P没有瞬间跑满，真正贵的是你不知道它丢在了哪里。
下次再看到“XX P级智算中心”这种宣传，别急着按峰值算训练能力，先问一句：它的MFU是多少？
数据来源：
PaLM: Scaling Language Modeling with Pathways（Chowdhery et al.， 2022）——PaLM 540B MFU 46.2%、GPT-3 21.3%、Gopher 32.5%、Megatron-Turing NLG 530B 30.2% 数据出处 https://ar5iv.labs.arxiv.org/html/2204.02311
The Llama 3 Herd of Models（Meta, 2024）——Llama 3 405B MFU 38%-43%、54天466次job interruption数据 https://ar5iv.labs.arxiv.org/html/2407.21783
NVIDIA Megatron-Core 性能基准页面——弱/强扩展测试下42%-50%的MFU区间 https://developer.nvidia.com/megatron-core
Google MaxText 文档——MFU 定义与计算公式 https://maxtext.readthedocs.io/en/latest/reference/performance_metrics.html
NVIDIA H100 官方规格——BF16/FP16 Tensor Core峰值在带稀疏性时为1979 TFLOPS，FP8 Tensor Core峰值在带稀疏性时为3958 TFLOPS，非稀疏口径通常约为一半 https://www.nvidia.com/en-us/data-center/h100/
NVIDIA nvidia-smi 文档——GPU utilization 指标定义 https://docs.nvidia.com/deploy/nvidia-smi/index.html
DeepSeek-V3 Technical Report / Hugging Face 模型页——671B MoE架构、37B激活参数、H800 GPU小时数、FP8训练细节 https://huggingface.co/deepseek-ai/DeepSeek-V3
What is the MFU for DeepSeek-V3 training？（Medium，第三方复现估算，MFU约21.4%） https://medium.com/@dlrover/what-is-the-mfu-for-deepseek-v3-training-0d9ea4d42eb4
What went into training DeepSeek-R1？（Epoch AI，独立估算MFU约23%） https://epoch.ai/gradient-updates/what-went-into-training-deepseek-r1
DeepSeek V3 & R1 Demystified（Kai Xiang，20/132 SM 用于通信的算力折算） https://kaimit.github.io/deepseek-demystified/
Decoding GPU Efficiency: Part 1 The FLOPs Fallacy（Clockwork，MegaScale 55.2%、行业MFU共识数字） https://clockwork.io/blog/decoding-gpu-efficiency-part-1-the-flops-fallacy/