算力指标全景：从 FLOPs 到 MFU，用近三代旗舰 GPU 把每个数字讲清

聊性能时最容易踩的坑，是把几个长得几乎一样的词当成同义词：FLOP、FLOPs、FLOPS、MAC、TOPS……它们差的不是一星半点。小写 s 结尾的 FLOPs 是「次数」（工作量），大写 S 结尾的 FLOPS 是「每秒次数」（算力） —— 一个描述任务有多大，一个描述机器有多快，中间隔着一个时间维度。把这两类搞混，就会得出「这卡有 2250 TFLOPS，我这模型 175 GFLOPs，所以 0.08 毫秒跑完」这种离谱结论（真实世界慢几个数量级）。

下面按五个类别来摆 —— 计算量、算力、访存、效率、部署 —— 每个指标都配多个算例，而且尽量用近三代数据中心旗舰（Ampere A100、Hopper H100、Blackwell B200，以及 2026 的 Rubin）做对照，这样数字之间能横着比，看着更清楚。先给一张全景表。

为了让后面所有算例有一把统一的尺子，先把这几代旗舰的关键规格列在一起（FP16/BF16 为稠密 Tensor Core 算力）：[1]

FLOP / FLOPs — 计算量 · 浮点运算次数

一次浮点加法、一次浮点乘法各算一个 FLOP。整个网络做一次前向传播要做的浮点运算总数，就是它的 FLOPs。注意它是绝对次数，没有时间含义，只跟模型和输入有关，跟用什么硬件无关。

案例：CNN 一次前向 —— 用公式直接数

对卷积层（输出特征图 $H\times W$，输入/输出通道 $C_{in}/C_{out}$，卷积核 $K$）：

ResNet-50 在 224×224 输入下约 4.1 GMACs ≈ 8.2 GFLOPs。但很多论文写「ResNet-50 ≈ 4 GFLOPs」—— 它们其实报的是 MACs，只是嘴上叫 FLOPs（下一节会专门拆这个混乱）。

案例：Transformer 训练 —— 经验公式 6ND

大模型训练的总计算量有个极好用的经验估计：$\text{FLOPs} \approx 6ND$，其中 $N$ 是参数量、$D$ 是训练 token 数（前向 2、反向 4，共 6 倍）。[2] GPT-3 175B 在 300B token 上训练：

Llama-3.1 405B 在约 15.6T token 上训练，$6ND \approx 3.8\times10^{25}$ FLOPs —— 比 GPT-3 大两个数量级。这个绝对数字本身没有时间，要除以算力才知道要跑多久，见后面 FLOPS 一节。

案例：一次推理的 prefill —— 2ND per token

推理时，前向一次的计算量约 $2N$ FLOPs/token（$N$ 为参数量）。一个 70B 模型处理一段 1000 token 的 prompt（prefill 阶段），计算量约 $2\times70\times10^9\times1000 \approx 1.4\times10^{14}$ FLOPs。这个数后面会和「访存量」一起，用来算 prefill 的算术强度。

MAC / MACs — 计算量 · 乘加运算

深度学习的核心操作是「乘一下再加一上」(a*b+c)，叫一次 MAC(Multiply-Accumulate)，硬件上常由一条 FMA 指令完成。

案例：1 MAC ≈ 2 FLOPs 的换算

一次 MAC 含一乘一加，所以 1 MAC ≈ 2 FLOPs。MobileNetV1 标称约 569 MMACs，换算成 FLOPs 就是 ~1.14 GFLOPs。如果拿 569M 这个数去和别家报的 GFLOPs 直接比，就会误以为它比实际小了一倍。

案例：论文里的「4G 与 8G」之谜

学界报模型开销时 MACs 和 FLOPs 经常被混用：ResNet-50 你会同时看到「4.1G」和「8.2G」两个版本，差的正是这个 2 倍 —— 前者是 MACs、后者是 FLOPs。有些论文还用 “Mult-Adds” 这个词，指的也是 MACs。读数前先确认口径，否则横向对比全错。

案例：Tensor Core 本质就是 MAC 阵列

为什么硬件厂商堆的是「乘加」而不是通用浮点？因为矩阵乘法就是海量 MAC。Tensor Core 是专门做 $D = A\times B + C$ 的脉动阵列，一个时钟周期吞下一整块小矩阵的乘加。这就是为什么 H100 的 Tensor Core FP16 算力(990 TFLOPS)是其 CUDA Core FP32(67 TFLOPS)的近 15 倍 —— 它把通用算力的预算全压到了 MAC 上。[1]

Params — 计算量 · 参数量

模型里可学习权重的个数。它决定的是存储和显存占用，不是计算量，两者不能互相推断。

案例：Llama-3.1 405B 放不进单卡

FP16 下每个参数 2 字节，405B 参数光权重就要 $405\times10^9\times2 \approx 810\ \text{GB}$。对照上表：一张 80GB 的 A100/H100 差着十倍，即便 192GB 的 B200 也要 5 张、288GB 的 Rubin 也要 3 张才装得下权重 —— 这还没算 KV cache 和激活。Params 直接决定「至少要几张卡」，而跟它每秒能算多少毫无关系。

案例：DeepSeek-V3 —— 参数量 ≠ 每 token 计算量

MoE（混合专家）模型把 Params 和计算量彻底解耦。DeepSeek-V3 有 671B 总参数，但每个 token 只激活约 37B。所以它的显存占用按 671B 算（要全放下），而每 token 计算量（那个 $2N$）只按 37B 算。用总参数量去估它的推理算力，会高估近 20 倍。

案例：权重不是唯一吃容量的 —— KV cache

显存里除了 Params，还有 KV cache（每条请求、每个已生成 token 都要缓存）。长上下文、大 batch 时 KV cache 能膨胀到和权重同量级，直接压缩可用 batch。所以 Params 决定地板，KV cache 决定还能塞多少并发 —— 两者一起吃容量。

FLOPS — 算力 · 每秒浮点运算次数

把上面的「次数」除以时间，就进入算力的世界。核心区别：大写 S = per Second。 $\text{FLOPS} = \text{FLOPs} \div \text{时间}$。

案例：GPT-3 训练到底要多久

把任务 FLOPs 除以集群算力，得到理想耗时。GPT-3 的 $3.15\times10^{23}$ FLOPs，用 1024 张 A100（每张 312 TFLOPS）、且 100% 利用：

但真实 MFU 只有三四成（见后），所以实际是一个月量级。这就是 FLOPs（任务）和 FLOPS（算力）配合使用的标准姿势。

案例：同一任务，三代卡的理论时间

同样跑一个 $10^{22}$ FLOPs 的训练任务，单卡满载理论时间随峰值算力线性缩短：A100(312 TFLOPS)约 8.9 小时，H100(990)约 2.8 小时，B200(2250)约 1.2 小时。三代之间近 7 倍的差距，几乎全来自 Tensor Core 峰值的提升 —— 前提是负载真能吃满算力，而这恰恰是 Roofline 要回答的问题。

Peak FLOPS — 算力 · 理论峰值

厂商标称的算力上限。看这个数时务必盯紧两件事：哪种精度、是否含稀疏翻倍。

案例：精度阶梯 —— 同一块 H100 的五个峰值

同一块芯片，精度每降一档，峰值大致翻倍。H100 一张卡上：FP64 约 67 TFLOPS、TF32 约 495、FP16/BF16 990、FP8 约 1979 TFLOPS。所以「H100 算力多少」这个问题没有唯一答案，必须先问精度。低精度训练/推理之所以是主线，正因为它直接把可用峰值翻番。[3]

案例：稀疏翻倍陷阱 —— B200 的「9000」是怎么来的

市场材料常印 B200「FP4 算力 9000 TFLOPS」，但那是开了 2:4 结构化稀疏后的数字，稠密 FP4 只有约 4500 TFLOPS。只有满足稀疏模式的负载才拿得到稀疏峰值，稠密矩阵乘法实打实减半。拿稀疏峰值去比别人的稠密峰值，等于自带 2 倍水分。

案例：跨代峰值 —— 十年涨 2380×

把视野拉长：P100(2016)到 Rubin R100(2026),AI 峰值算力涨了约 2380×，而同期通用 CUDA Core 的 FP32 算力只涨了约 10×。[1] 这两条曲线的剪刀差说明：这十年的算力暴涨几乎全发生在「专用矩阵乘 + 低精度」这一条线上，而不是通用浮点变快了。

TOPS — 算力 · 每秒万亿次操作

和 FLOPS 同构，但 “Operations” 通常指整数运算（尤其 INT8），多见于推理加速器和边缘芯片的规格表。浮点用 FLOPS，定点/整数用 TOPS，单位换了别直接比大小。

案例：数据中心 INT8 —— A100 到 B200

A100 标称 624 TOPS(INT8),H100 约 1979 TOPS（INT8 稠密），B200 更高。INT8 量化推理在分类、检索、推荐这类对精度不那么敏感的场景里非常划算 —— 用整数管线换近一倍吞吐。

案例：边缘芯片 —— Jetson Orin 与 Thor

边缘端规格表几乎只看 TOPS。Jetson AGX Orin 标称 275 TOPS(INT8),2025 年的 Jetson Thor 跃升到约 2070 TFLOPS(FP4) 量级 —— 把数据中心的低精度路线下放到了机器人/车端。注意 Orin 报 TOPS（整数）、Thor 报 FP4 TFLOPS（浮点），口径不同，不能直接相减。

显存带宽 — 访存 · Memory Bandwidth

显存和计算单元之间每秒能搬多少字节。LLM 自回归解码几乎总是被它卡死:每生成一个 token，都要把整个模型的权重从显存读一遍，这是纯搬运，算得再快也得等数据到位。

案例：70B 单条解码，三代带宽决定上限

生成一个 token 至少要读一遍权重。FP16 的 70B 模型权重 140GB，把它除以带宽就是每 token 的理论下限：

这一列数字完全由带宽决定，跟峰值算力(312 / 990 / 2250 TFLOPS)半点关系都没有 —— A100 到 B200 解码提速约 4 倍，靠的全是带宽涨了 4 倍。

案例：量化为什么能加速解码

既然解码瓶颈是「读权重的字节数」，那把权重变小就能直接提速。把上面的 70B 从 FP16 换成 FP8，权重从 140GB 砍到 70GB，每 token 要读的字节减半，解码吞吐近乎翻倍 —— 这跟算力无关，纯粹是少搬了一半数据。FP4 再砍一半。这就是低精度推理在带宽墙下的核心价值。

显存容量 — 访存 · Memory Capacity

能放下多大的模型加多大的 batch/KV cache,决定的是「可行 / 不可行」，不是快慢。

案例：每代能单卡放下的最大稠密模型

按 FP16（2 字节/参数）粗算，显存容量直接框定单卡能装的权重上限：A100/H100 的 80GB ≈ 40B 参数，B200 的 192GB ≈ 96B,Rubin 的 288GB ≈ 144B。再大就必须张量并行切到多卡 —— 容量不够时，再高的算力和带宽都无从谈起。

案例：长上下文把容量吃光

容量不只给权重。一个 70B 模型在 128K 上下文、batch 较大时，KV cache 可以轻松吃掉几十 GB，和权重抢同一块显存。这就是为什么 B200/Rubin 把单卡容量从 80GB 一路推到 192/288GB —— 长上下文 + 高并发的时代，容量本身就是产品力。

访存量 — 访存 · Bytes

某个算子完成任务实际要读写多少字节（输入 + 权重 + 输出）。它本身不直接当 KPI，而是和 FLOPs 搭配，算出下一节最关键的「算术强度」。

案例：解码 vs prefill 的访存量差异

同一个 70B 模型：解码一个 token 是矩阵-向量乘(GEMV)，要读 140GB 权重却只做约 $1.4\times10^{11}$ FLOPs;prefill 1000 个 token 是矩阵-矩阵乘(GEMM)，权重还是读那 140GB（被 1000 个 token 复用），却做了约 $1.4\times10^{14}$ FLOPs。访存量几乎一样，计算量差 1000 倍 —— 这正是两者一个 memory-bound、一个 compute-bound 的根因。

算术强度 — 效率 · Arithmetic Intensity

定义极简但极有用：

物理意义是「每从显存搬一个字节，能摊到多少次计算」。强度高 → 搬一次数据能算很久 → 受算力限制；强度低 → 大部分时间在等数据 → 受带宽限制。

案例：GEMM 与 GEMV 的两极

大矩阵乘法(GEMM)中每个元素被复用 $O(N)$ 次，算术强度高达几百甚至上千 FLOP/Byte；而 LLM 解码是 GEMV，每个权重只用一次，batch=1 时算术强度低到 ~1-2 FLOP/Byte。同一块卡，一个吃满算力、一个被带宽锁死，差别只在这一个比值。

案例：batch 是提升算术强度的旋钮

解码 batch=1 时每个权重服务一条请求（强度 ~1）；batch=256 时同一份权重读进来服务 256 条请求，算术强度涨到 ~256 FLOP/Byte —— 直接把负载从「带宽墙左侧」推过脊点、推向算力侧。这就是推理服务拼命攒 batch 的根本原因：不是为了省算力，是为了让本来闲着的算力有活干。

Roofline — 效率 · 屋顶线模型

把算术强度（横轴）和可达算力（纵轴）画在一张 log-log 图上，就得到一条「屋顶」曲线：

左半段是斜率为 1 的带宽屋顶，右半段是水平的算力屋顶。两段交汇处叫脊点(ridge point)，横坐标 = 峰值算力 ÷ 带宽。负载落在脊点左边就是 memory-bound，右边就是 compute-bound。

案例：三代脊点为什么稳定在 150–300

脊点 = 峰值算力 ÷ 带宽。A100:312 ÷ 2.0 ≈ 153;H100:990 ÷ 3.35 ≈ 295;B200:2250 ÷ 8.0 ≈ 281。三代算力涨了 7 倍、带宽涨了 4 倍，相除后脊点几乎没动 —— 因为厂商是算力和带宽一起加的。这意味着一个朴素但残酷的结论：只要你的负载算术强度低于约 300，换再新的卡，它依然是 memory-bound，提速幅度只跟带宽走，不跟峰值算力走。

案例：LLM 解码永远在屋顶线左端

解码算术强度 ~1，远低于任何一代的脊点(150–295)，所以它落在三条斜屋顶的最左侧，天花板永远是带宽。这从根上解释了为什么解码优化全在围着「少读权重 / 多复用权重」转：量化（少读）、MoE（只激活一部分）、投机解码（一次前向多出几个 token）、把 batch 做大（复用）—— 没有一个是在堆算力。

GPU 利用率 — 效率 · Utilization

就是 nvidia-smi 里那个百分比，含义只是「这段时间内有没有 kernel 在 GPU 上跑」。

案例：99% 利用率的幻觉

跑 LLM 解码时 nvidia-smi 常年 99%，看着像榨干了卡。但哪怕一个 kernel 只用了 5% 的计算单元、其余时间都在等显存，只要它在跑，利用率就显示 100%。解码 memory-bound,GPU 大部分时间在等 HBM，有效算力可能只有峰值的百分之几 —— 这个 99% 是个出了名会骗人的数字。判断「算力到底用了几成」，要看下面的 MFU。

MFU / HFU — 效率 · 模型 / 硬件 FLOPs 利用率

训练 LLM 时真正可靠的效率指标：

案例：50% 就算优秀 —— PaLM 与 Megatron

MFU 能到 50% 已经相当好。Google 的 PaLM 540B 训练报到约 46% MFU;[4] 业界用 Megatron 在 A100/H100 集群上的大模型训练普遍落在 40%–55%。剩下那一半哪去了？通信、流水线气泡、访存等待、非矩阵乘算子……全是 Roofline 和利用率讲过的那些损耗。看到谁报「90% 利用率」，先问清是 nvidia-smi 的利用率还是 MFU —— 差着一个数量级。

案例：MFU 与 HFU 的区别 —— 重计算

MFU 只数模型前反向必需的有用浮点运算（分子用 $6ND$）；HFU 还把 activation recomputation（为省显存而重算一遍前向）这类额外运算也算进去。所以 HFU ≥ MFU:同一次训练，HFU 可能 57%、MFU 只有 48%，差值就是重计算「白干」的那部分。[5] 比较不同工作时，务必确认报的是哪一个。

延迟 / 吞吐 — 部署 · Latency / Throughput

延迟是单次请求的响应时间，吞吐是单位时间处理量。两者通过 batch size 互相拉扯。

案例：batch=1 与 batch=32 的此消彼长

接前面 H100 解码 70B 的例子：batch=1 时每秒约 24 token、延迟 42 ms/token；把 batch 提到 32，权重只读一遍就服务 32 条请求，总吞吐能涨到几百 token/s，但单条请求要等凑齐一批、排队更久，延迟上去了。把 batch 做大是用延迟换吞吐 —— 反之亦然。

案例：TTFT 与 TPOT —— 一个请求的两段延迟

LLM 服务把延迟拆成两段：TTFT（首 token 时间，由 prefill 决定，compute-bound）和 TPOT（每后续 token 时间，由解码决定，memory-bound）。这两段瓶颈不同、优化手段不同 —— prefill 拼算力和并行，decode 拼带宽和 batch。把它们混成一个「延迟」去优化，往往使错劲。

能效 / 性价比 — 部署 · Perf/Watt, Perf/$

每瓦能换多少算力、每美元能换多少算力。大规模部署时，这两个比峰值算力本身重要得多 —— 数据中心的瓶颈往往是供电和散热，不是买不起卡。

案例：三代能效 —— TFLOPS/W

用上表的峰值和 TDP 粗算每瓦算力（BF16 稠密）：A100 312 TFLOPS ÷ 400W ≈ 0.78 TFLOPS/W;H100 990 ÷ 700 ≈ 1.41;B200 2250 ÷ 1000 ≈ 2.25。三代能效翻了近 3 倍 —— 这才是数据中心真正算的账：同样的供电预算，B200 能多产出多少有效算力。

案例：为什么超大集群只看 perf/$ 和 perf/W

当你要部署上万张卡，1.4 还是 2.25 TFLOPS/W 的差距，直接换算成每年数百万的电费，以及能不能塞进现有机房的供电与散热预算。这时候没人再盯着峰值那个最大数字看 —— 总拥有成本(TCO)里，电费和机柜密度往往比卡的单价更致命。

一句话串起来 — 一条因果链

这些指标其实是一条因果链：任务有多大(FLOPs / MACs / Params)→ 机器多快多大（FLOPS / 带宽 / 容量）→ 两者一比，瓶颈在哪（算术强度 / Roofline）→ 实际用了几成（MFU，而不是 nvidia-smi 利用率）→ 上线后体感与成本（延迟 / 吞吐 / 能效）。

记住三条最容易翻车的：小写 FLOPs 是次数、大写 FLOPS 是速度；1 MAC ≈ 2 FLOPs；以及 —— 绝大多数 LLM 负载卡的是带宽不是算力，所以先看算术强度落在 Roofline 的哪一侧，再决定优化往哪使劲。

参考资料

• NVIDIA. NVIDIA H100 Tensor Core GPU Architecture / Blackwell Architecture Technical Brief. White Papers, 2022–2024. 规格数据另见本站《GPU 架构十年演化》一文整理。
• Kaplan, Jared, et al. Scaling Laws for Neural Language Models. arXiv:2001.08361, 2020.
• Micikevicius, Paulius, et al. Mixed Precision Training. ICLR, 2018.
• Chowdhery, Aakanksha, et al. PaLM: Scaling Language Modeling with Pathways. arXiv:2204.02311, 2022.
• Korthikanti, Vijay, et al. Reducing Activation Recomputation in Large Transformer Models. MLSys, 2023.
• Williams, Samuel, Andrew Waterman, and David Patterson. Roofline: An Insightful Visual Performance Model for Multicore Architectures. Communications of the ACM, 2009.