1. 从一个被问烂了的问题说起
如果你在AI Infra、高性能计算或者芯片行业待过一阵子，大概率会遇到这样一个场景：有人在群里发了一张GPU规格表，上面写着“FP16算力 312 TFLOPS”，然后另一个人问“那这个模型训练一次要多少FLOPs”，接着就有人开始算，算着算着两边吵起来了——因为一个人把FLOPS当成了FLOPs，另一个人把FLOPs当成了FLOPS。
这不是段子，这是几乎每个月都会在技术社区里重演的真实画面。我见过工作三四年的工程师在技术评审会上把这两个词混着用，也见过面试候选人在白板上推导模型计算量时，单位写错了导致整个估算差了三个数量级。更麻烦的是，很多技术文档自己也没写清楚，一会儿FLOPS一会儿FLOPs，读者根本分不清作者到底在说算力还是在说计算量。
所以这篇内容就是要把这件事彻底讲透。FLOPS和FLOPs，一个字母大小写的差别，背后是两套完全不同的概念体系：一个是衡量硬件“跑得多快”的算力指标，一个是衡量模型或算法“要跑多少步”的计算量指标。搞混它们，轻则算错训练成本，重则选错硬件方案、定错优化方向。
这篇文章适合谁看？如果你是刚入行的算法工程师、正在做模型部署的工程同学、需要评估训练成本的团队负责人，或者只是单纯被这两个词搞晕过的技术从业者，那接下来的内容应该能帮你把这块知识补扎实。我会从概念定义、单位体系、计算逻辑、实际估算方法、常见踩坑场景几个维度展开，尽量用从业者之间聊天的口吻，把这件事说清楚。
2. 概念拆解：两个词到底在说什么
2.1 FLOPS：硬件的“极限速度表”
FLOPS的全称是Floating-point Operations Per Second，注意最后的“Per Second”，它描述的是单位时间内能完成多少次浮点运算。这是一个速度指标，衡量的是硬件的能力上限。
你可以把它理解成汽车的“最高时速”。一辆车标称最高时速240公里，意思是它在理想条件下每小时最多能跑240公里。至于你实际开的时候是不是一直踩到底、路上有没有堵车，那是另一回事。FLOPS也一样，它标的是理论峰值，实际能跑到多少，取决于你的代码、内存带宽、并行度等一系列因素。
FLOPS的常见量级单位是这样的：
| 单位 | 含义 | 典型场景 |
|---|---|---|
| MFLOPS | 每秒百万次浮点运算 | 早期CPU、嵌入式芯片 |
| GFLOPS | 每秒十亿次浮点运算 | 现代CPU、入门级GPU |
| TFLOPS | 每秒万亿次浮点运算 | 主流数据中心GPU |
| PFLOPS | 每秒千万亿次浮点运算 | 高端加速卡、超算节点 |
| EFLOPS | 每秒百亿亿次浮点运算 | 顶级超算系统 |
这里有个细节值得注意：FLOPS前面通常会带精度标识，比如FP64 FLOPS、FP32 FLOPS、FP16 FLOPS、TF32 FLOPS。同一块芯片在不同精度下的FLOPS可以差几十倍。比如某款数据中心GPU，FP64可能只有几十TFLOPS，但FP16 Tensor Core能到上千TFLOPS。所以看到“这块卡有XXX TFLOPS”的时候，第一反应应该是问一句：什么精度下的？
2.2 FLOPs：模型的“工作量清单”
FLOPs的全称是Floating-point Operations，注意这里没有“Per Second”，它描述的是完成一次特定任务需要多少次浮点运算。这是一个总量指标，衡量的是工作量。
继续用汽车类比：如果FLOPS是最高时速，那FLOPs就是从北京开到上海总共需要跑多少公里。这个数字跟车没关系，跟路线有关系。换一辆更快的车，总里程不会变，但跑完需要的时间会缩短。
FLOPs通常出现在这些场景里：
- 论文里说“我们的模型只有4.5 GFLOPs”，意思是推理一次需要45亿次浮点运算
- 训练框架日志里写“Total FLOPs: 3.2e18”，意思是整个训练过程累计做了3.2×10¹⁸次浮点运算
- 部署工程师说“这个模型FLOPs太高了，端侧跑不动”，意思是单次推理的计算量超出了目标设备的处理能力
FLOPs的量级单位跟FLOPS长得一样，也是M/G/T/P，但含义完全不同。1 GFLOPs是十亿次浮点运算，是一个“次数”，不是一个“速率”。
2.3 为什么这两个词这么容易混
混用的根源有三个。
第一，拼写太像了。就差一个字母的大小写，在快速阅读或者打字的时候极容易搞错。而且很多字体里大写I和小写l看起来也差不多，视觉上更难区分。
第二，中文翻译都差不多。很多资料把FLOPS翻译成“浮点运算能力”或“浮点算力”，把FLOPs翻译成“浮点运算量”或“浮点计算量”。但在口语里，大家经常都说“算力”，于是“这个模型算力多大”和“这块卡算力多大”就混在一起了。
第三，量级单位重叠。两者都用M/G/T/P做前缀，如果不看上下文，看到“1.2 TFLOPs”根本不知道是在说速度还是在说总量。
我自己的经验是：看单位后面有没有“/s”或者“Per Second”。有就是FLOPS（速度），没有就是FLOPs（总量）。这个判断规则简单但极其有效，建议你从现在开始就养成这个习惯。
3. 单位体系与换算：别在数量级上栽跟头
3.1 两套单位体系的对照
虽然FLOPS和FLOPs的前缀一样，但它们描述的东西不同，所以在实际使用中，你需要建立两套独立的直觉。
对于FLOPS（速度），你需要知道：
- 一块主流数据中心GPU的FP16 Tensor Core算力大概在几百到上千TFLOPS
- 一块高端消费级显卡的FP32算力大概在几十TFLOPS
- 一颗服务器CPU的FP64算力大概在几百GFLOPS到几TFLOPS
- 手机SoC的NPU算力通常在几TOPS到几十TOPS（注意这里是TOPS，整数运算，后面会讲）
对于FLOPs（总量），你需要知道：
- 一个ResNet-50推理一次大约4 GFLOPs
- 一个BERT-Base推理一次大约22 GFLOPs
- 一个GPT-3规模模型推理一次大约350 GFLOPs（取决于序列长度）
- 训练一个GPT-3规模模型，总计算量在3×10²³ FLOPs量级
把这两组数字放在一起，你就能做一些有意义的估算了。比如：用一块312 TFLOPS的卡去推理BERT-Base，理论最短时间是多少？
计算过程是这样的：22 GFLOPs ÷ 312 TFLOPS = 22×10⁹ ÷ 312×10¹² ≈ 7×10⁻⁵秒，也就是大约0.07毫秒。当然这是理论峰值，实际因为内存带宽、kernel启动开销、batch size等因素，真实延迟会高不少，但至少你有了一个数量级上的参考。
3.2 精度对FLOPS的影响
前面提到，同一块芯片在不同精度下的FLOPS差异巨大。这里展开说一下为什么。
浮点运算的精度决定了每次运算需要多少位宽。FP64用64位表示一个数，FP32用32位，FP16用16位，INT8用8位。位宽越窄，同样面积的电路能塞下的计算单元就越多，或者同样的计算单元能在更短时间内完成一次运算。
以某代数据中心GPU为例，粗略的算力比例大概是：
- FP64：1×
- FP32：2×
- TF32：8×
- FP16/BF16：16×
- INT8：32×
这个比例不是固定的，不同架构差异很大，但趋势是一致的：精度越低，标称FLOPS越高。这也是为什么AI训练和推理越来越倾向于用低精度——不是因为它更准，而是因为它更快。
但这里有个坑：低精度FLOPS高，不代表实际任务就能等比例加速。因为很多操作的瓶颈不在计算，而在内存带宽。比如LayerNorm、Softmax这类操作，计算量不大但需要频繁读写内存，这时候FP16的高FLOPS根本发挥不出来。所以看到“FP16算力是FP32的16倍”时，不要天真地以为所有任务都能快16倍。
3.3 FLOPs的计算口径问题
FLOPs的统计口径比FLOPS更乱，因为“一次浮点运算”的定义本身就有歧义。
最常见的分歧是：乘加运算算一次还是两次？
一个矩阵乘法里的核心操作是a×b+c，这包含一次乘法和一次加法。有的统计工具把它算作2次浮点运算（1次乘法+1次加法），有的算作1次（因为硬件通常有FMA指令，一个周期完成乘加）。这两种口径算出来的FLOPs能差一倍。
主流的约定是：
- 学术论文和大多数分析工具（如fvcore、thop）默认乘加算2次
- 硬件规格书里的FLOPS通常按FMA算1次运算来标称
这就导致一个尴尬的局面：你用工具算出来模型有10 GFLOPs，除以硬件标称的100 TFLOPS，得到0.1毫秒，但实际可能跑出来0.2毫秒甚至更多。不一定全是口径问题，但口径至少是原因之一。
我的建议是：在做任何严肃估算之前，先确认两边的口径是否一致。如果不一致，要么统一口径，要么在结果上留出足够的余量。
4. 实际估算：从模型到硬件的完整计算链
4.1 怎么估算一个模型的FLOPs
对于常见的神经网络层，FLOPs有比较成熟的经验公式。
全连接层：输入维度D_in，输出维度D_out，则FLOPs ≈ 2 × D_in × D_out（乘加各算一次）。如果带batch size B，再乘B。
卷积层：输出特征图尺寸H_out × W_out，卷积核尺寸K × K，输入通道C_in，输出通道C_out，则FLOPs ≈ 2 × H_out × W_out × K × K × C_in × C_out。
注意力层：这是Transformer的核心。对于序列长度L、隐藏维度D、注意力头数H，粗略估算FLOPs ≈ 2 × L² × D × 2 + 2 × L × D² × 4。第一项是注意力矩阵的计算，第二项是QKV投影和输出投影。当L很大时，第一项会主导。
这些公式看起来简单，但实际用的时候有几个注意点：
- 激活函数、归一化层的FLOPs通常可以忽略不计，因为它们只占总量很小一部分
- 残差连接不产生额外的浮点运算，只是加法
- Embedding层本身不算FLOPs，但后续的投影要算
如果你不想手算，可以用工具。PyTorch生态里有fvcore和thop两个库，用法很简单：
import torch from thop import profile model = MyModel() input_tensor = torch.randn(1, 3, 224, 224) flops, params = profile(model, inputs=(input_tensor,)) print(f"FLOPs: {flops / 1e9:.2f} GFLOPs") print(f"Params: {params / 1e6:.2f} M")但要注意，这些工具对某些自定义算子可能统计不准，尤其是动态控制流、条件分支、循环结构。所以工具结果只能作为参考，关键场景还是得结合理论分析。
4.2 从FLOPs和FLOPS推算时间
有了模型的FLOPs和硬件的FLOPS，理论上就能算时间：
理论最短时间 = FLOPs ÷ FLOPS
但这个公式的实际可用性取决于一个关键概念：MFU（Model FLOPs Utilization，模型计算利用率）。
MFU = 实际达到的FLOPS ÷ 理论峰值FLOPS
在真实训练场景中，MFU通常在30%到60%之间。做得好的框架和模型能到50%以上，做得差的可能只有20%出头。推理场景的MFU通常更低，因为batch size小、kernel启动开销占比高。
所以更实际的估算公式是：
实际时间 ≈ FLOPs ÷ (FLOPS × MFU)
举个例子：训练一个总计算量3×10²³ FLOPs的模型，用1000块标称312 TFLOPS的卡，假设MFU是40%，那么：
总可用FLOPS = 1000 × 312×10¹² × 0.4 = 1.248×10¹⁷ FLOPS 训练时间 = 3×10²³ ÷ 1.248×10¹⁷ ≈ 2.4×10⁶秒 ≈ 28天
这个估算跟业界公开的一些训练时长数据是能对上的，说明方法本身是靠谱的。
4.3 一个完整的估算实例
假设你要训练一个类似LLaMA-7B的模型，想估算需要多少卡、跑多久。
第一步：估算单次前向传播的FLOPs
对于Transformer类模型，前向FLOPs ≈ 2 × N × L × D，其中N是参数量，L是序列长度，D是隐藏维度。但更准确的公式要考虑注意力部分的二次项。
LLaMA-7B大约有6.7B参数，隐藏维度4096，序列长度2048。粗略估算：
前向FLOPs ≈ 2 × 6.7×10⁹ × 2048 ≈ 2.7×10¹³ FLOPs = 27 TFLOPs
第二步：估算训练总FLOPs
训练时，前向+反向大约需要3倍前向的计算量（反向传播的FLOPs约为前向的2倍）。再乘以训练token总数。
假设训练1T token： 总FLOPs ≈ 3 × 2.7×10¹³ × 1×10¹² ≈ 8.1×10²⁵ FLOPs
第三步：估算训练时间
用1024块卡，每块标称312 TFLOPS，MFU取40%：
可用FLOPS = 1024 × 312×10¹² × 0.4 ≈ 1.28×10¹⁷ FLOPS 训练时间 = 8.1×10²⁵ ÷ 1.28×10¹⁷ ≈ 6.3×10⁸秒 ≈ 7300天
这个数字明显不对，说明我的估算哪里出了问题。检查一下：1T token的训练量对于7B模型来说，总FLOPs应该是6 × N × token数 = 6 × 6.7×10⁹ × 1×10¹² = 4×10²² FLOPs，而不是8.1×10²⁵。我前面多乘了三个数量级。
修正后： 训练时间 = 4×10²² ÷ 1.28×10¹⁷ ≈ 3.1×10⁵秒 ≈ 3.6天
这个结果就合理多了。业界训练7B模型在1T token上，用千卡级别跑几天，是符合实际的。
这个例子说明一个很重要的事：FLOPs估算里最容易出错的就是数量级。一个不小心多乘或少乘10³，结果就完全失去参考价值。所以每次算完，都要用直觉检查一下——这个时间/成本合理吗？
5. 常见混淆场景与避坑指南
5.1 硬件规格书里的文字游戏
很多硬件规格书在写FLOPS的时候，会标注“峰值”或者“理论最大值”。这个数字是在最理想条件下测出来的：所有计算单元满载、数据全部在寄存器里、没有内存访问延迟、没有指令调度开销。
实际能跑到多少？在训练场景，MFU 40%-50%算不错；在推理场景，尤其是小batch，MFU可能只有10%-20%。所以看到规格书上的FLOPS，先打个对折甚至打两折，再用来做估算。
另一个坑是稀疏算力。有些规格书会标“稀疏FLOPS是稠密的2倍”，但这个2倍只有在模型本身有50%结构化稀疏且硬件支持稀疏加速时才能拿到。大多数模型没有这种稀疏性，所以那个数字看看就好。
5.2 论文里的FLOPs口径不一致
读论文的时候，经常看到“我们的模型只有XX GFLOPs”，然后跟另一个论文的模型对比。但两篇论文的FLOPs统计口径可能不一样：一个算乘加为2次，一个算1次；一个算输入分辨率224，一个算320；一个包含后处理，一个不包含。
所以跨论文比较FLOPs时要格外小心。如果论文没有明确说明统计口径，最好自己用统一工具重新算一遍，或者至少确认输入尺寸、是否包含特定层等关键条件。
5.3 训练和推理的FLOPs不是一回事
训练时的FLOPs通常是推理的3倍左右（前向+反向），但这只是计算量。训练还涉及优化器状态更新、梯度同步、数据加载等额外开销，这些不直接体现在FLOPs里，但会显著影响实际耗时。
推理场景则更复杂：batch size=1时，FLOPs利用率极低，因为很多计算单元在等数据；batch size增大后利用率提升，但延迟也会增加。所以推理优化往往是在FLOPs、延迟、吞吐量之间做权衡，不是单纯看FLOPs数字。
5.4 整数运算的TOPS是另一套体系
在端侧和边缘计算场景，你更常看到的是TOPS（Tera Operations Per Second），而不是FLOPS。TOPS统计的是整数运算，通常用于量化后的模型。
TOPS和FLOPS之间没有简单的换算关系，因为整数运算和浮点运算的硬件实现不同。一个标称10 TOPS的NPU，跑浮点模型可能只有1-2 TFLOPS的有效算力。所以端侧选型时，不要拿TOPS直接跟FLOPS比，要看实际模型在目标硬件上的benchmark。
6. 实操中的经验与技巧
6.1 快速判断该用哪个词
我自己的判断流程是这样的：
- 如果描述的对象是硬件（GPU、CPU、NPU、加速卡），用FLOPS
- 如果描述的对象是模型、算法、任务，用FLOPs
- 如果是在说“跑得多快”，用FLOPS
- 如果是在说“要跑多少”，用FLOPs
- 如果拿不准，看单位后面有没有“/s”或“Per Second”
这个规则覆盖了90%以上的场景。
6.2 估算时留足余量
不管是估算训练时间还是推理延迟，我都会在理论值基础上留2-3倍的余量。原因很简单：理论值假设了完美的并行、零开销的通信、100%的MFU，这些在现实中都不存在。
具体来说：
- 训练场景：理论时间 × 2.5 作为保守估计
- 推理场景：理论延迟 × 3 作为保守估计
- 成本估算：在时间估算基础上再上浮20%作为buffer
这样算出来的数字虽然不够“精确”，但至少不会让你在项目排期时过于乐观。
6.3 工具推荐与使用注意
除了前面提到的thop和fvcore，还有一些工具可以用：
- PyTorch Profiler：不仅能看FLOPs，还能看实际kernel耗时、内存占用
- Nsight Systems / Nsight Compute：NVIDIA生态下的性能分析工具，能看到实际FLOPS利用率
- rocProfiler：AMD生态的对应工具
使用这些工具时要注意：它们统计的FLOPs通常是“理论计算量”，不是“实际执行的指令数”。有些框架会做算子融合，把多个小算子合并成一个大kernel，这时候工具统计的FLOPs可能跟实际执行的浮点运算次数有出入。
6.4 一个容易被忽略的细节：Batch Size的影响
FLOPs本身不随batch size变化（因为它是单样本的计算量），但实际FLOPS利用率跟batch size关系极大。
小batch时，GPU的并行度利用不充分，很多计算单元闲置，实际FLOPS远低于峰值。大batch时利用率提升，但可能遇到内存瓶颈或者梯度同步开销。
所以在做推理优化时，一个常见的策略是：在延迟允许的范围内尽量增大batch size，把FLOPS利用率拉上去。这也是为什么很多推理服务会做动态batching——把多个请求攒在一起跑，提高硬件利用率。
7. 回到最初的问题
现在再回头看“FLOPS和FLOPs的区别”，其实一句话就能说清楚：FLOPS是速度，FLOPs是总量。但这一句话背后，涉及的是从硬件规格到模型设计、从训练成本到推理优化的完整知识链。
我在实际工作中见过太多因为混淆这两个词而导致的错误决策：有人拿模型的FLOPs去跟硬件的FLOPS直接比，得出“这个模型跑不了”的结论，其实只是单位搞错了；有人在选卡时只看FLOPS数字，忽略了精度和实际利用率，结果买回来的卡跑自己模型还不如另一款便宜的。
这些坑我都踩过，所以现在每次做估算，我都会先把单位写清楚，把口径对齐，把余量留足。这三个习惯看起来简单，但能避免绝大多数低级错误。
如果你只记住一件事，那就记住这个：看到FLOPS想“多快”，看到FLOPs想“多少”。剩下的，就是在实际项目中不断积累对数量级的直觉——这个没有捷径，只能靠多算、多验证、多跟实际benchmark对照。算得多了，你看到一组数字，大概就能感觉到它靠不靠谱。这种直觉，比任何公式都值钱。
