GOPS 在模型与硬件文档中的含义辨析

GOPS 在模型与硬件文档中的含义辨析

执行摘要

在你指定的语境里，GOPS 并不是单义词 。综合学术论文、芯片规格、嵌入式/FPGA/ASIC 文档、深度学习框架与 MLPerf 基准资料，本文将其归纳为 三类主含义 ，外加一类常见但不独立成义的派生写法：

其一，吞吐型 GOPS ，即 giga operations per second ，表示设备在特定精度、特定计数规则下的运算速率；

其二，复杂度型 GOPS ，即"每个输入样本/每次推理需要的十亿级运算量"，很多论文和模型表会写成 GOPS 或 GOPS/input，但本质上它是运算量计数 而不是每秒速率 ；

其三，视频压缩语境中的 GoP/GOPs ，即 Group of Pictures ，表示视频编码中的图像组，与算力单位无关；

此外，GOPS/W、TOPS/W 是前述吞吐型指标的能效派生量，GOPS/s 则属于语义上重复的写法，因为 GOPS 本身已经含有"每秒"。 citeturn8view1turn10view2turn23view0turn31view2turn8view0turn42view3turn20view0turn27view0

最容易误导读者的地方有两类。第一类是计数口径不统一 ：NXP、NVIDIA 以及部分芯片/体系结构论文都明确采用 1 MAC = 2 ops 的换算，因此会把 MAC/cycle × 频率 × 2 换成 GOPS/TOPS；但 TensorFlow 和 PyTorch 官方 profiler 并没有把"GOPS"标准化为统一公共指标：TensorFlow 统计的是 float_ops，且依赖已注册的 flops 统计与 shape/RunMetadata；PyTorch 的 with_flops 只估算特定算子（目前主要是矩阵乘和 2D 卷积）。第二类是峰值与实测混淆：官方规格页常给出理论峰值，而真实部署文档、TensorRT、Vitis AI 和 MLPerf 更强调延迟、qps/samples/s 或 time-to-train，因为带宽、并行度、批大小、量化、稀疏性、数据搬运、操作符覆盖率都会显著改变"实际可达"的性能。 citeturn10view2turn32view0turn6view0turn36view0turn23view2turn35view0turn15view0turn39view0

因此，阅读"模型里写的 GOPS"时，不要先问"它等于多少 FLOPs"，而要先问"作者到底在说速率、单次运算量，还是视频里的 Group of Pictures" 。最实用的判别法是看邻近上下文：若旁边出现 MHz、MAC/cycle、peak、theoretical、INT8/FP16/BF16，通常是吞吐型；若旁边出现 Params、Top-1、fps 分列、/input、ImageNet，通常是复杂度型；若旁边出现 I/P/B frame、motion vector、codec、compressed stream，则几乎肯定是 Group of Pictures。 citeturn10view1turn23view0turn31view2turn8view0turn42view3

研究范围与未指定假设

未指定假设	本文采用的处理方式
目标读者	以能阅读论文、SDK 文档与规格书的工程师/研究者为主，但尽量避免不必要术语堆叠
研究语言	全文使用中文；引用中若官方资料为英文，则按原语义转述
资料优先级	优先官方/原始资料：芯片厂商规格页、官方 SDK/框架文档、MLCommons、Google Research、CVPR/OpenReview/arXiv 原文
口径范围	只讨论与你问题直接相关的 AI 模型、推理/训练、嵌入式/FPGA/ASIC、视频模型和行业算力指标语境，不扩展到无关行业缩写
时间视角	对可能变化的框架文档、MLPerf 页面、产品规格，以截至 2026-04-24 可访问资料为准
大小写处理	将 GOPS、GOP/s、G Ops/s、GOPS/input、GoP/GoPs 均纳入检索，但会在结论中区分它们是否同义
争议处理	对 MAC 究竟算 1 个 op 还是 2 个 ops 这类存在口径差异的问题，不强行统一，而是逐源说明并明确不确定性

常见含义与快速判别

下表给出你在论文、模型卡、硬件手册里最常遇到的几类含义。为了避免把"缩写相同"误读成"单位相同"，表中把语境、计量对象、换算方式和示例来源并列展示。

含义	常见上下文线索	技术定义	常见换算与口径	典型真实示例
吞吐型 GOPS	MHz、MAC/cycle、peak、theoretical、INT8、NPU/DPU/TPU	每秒可执行的十亿级"operations"；常用于峰值算力或某一精度下的速率	常见厂商口径是 MAC/cycle × 频率 × 2；1 TOPS = 1000 GOPS；有时写成 GOP/s	Arm Ethos-U85 标 256 GOP/s，并说 1 GHz 下最高可达 4 TOP；NXP i.MX RT700 明确以 325 × 2 × 64 = 41.6 GOPS 计算；AMD PG338 直接写 "Peak Theoretical Performance (GOPS)"。 citeturn8view1turn10view2turn23view0
复杂度型 GOPS	Params、Top-1、ImageNet、/input、fps 单独列出、模型对比表	单个输入样本或一次前向/推理所需的十亿级运算量；本质是"总运算量"而不是"每秒速率"	常被写成 GOPS/input，也常被偷写成裸 GOPS；与 GMACs、GFLOPs 的数值关系取决于作者如何定义 1 MAC	早期 MLPerf Inference 论文表格写 ResNet-50 v1.5: 8.2 GOPS / input；AMD VCK5000 性能表把 GOPS 和 fps 并列；BNext 论文在 ImageNet 精度语境下写 0.82 GOPS。 citeturn31view2turn8view0turn18search0
视频编码型 GoP/GOPs	I-frame、P/B-frame、codec、motion vector、compressed video stream	Group of Pictures，视频编码中的图像组，不是算力单位	与 FLOPS/TOPS/MACs 无直接换算关系；大小写常写作 GoP 或 GOP	CVPR 2025 的 EMA 论文明确定义 GOPs (Group Of Pictures)，指出每个 GOP 含 1 个 I 帧和若干 P/B 帧，并在模型中使用 GOP encoder。 citeturn42view0turn42view3
派生写法而非新含义	GOPS/W、TOPS/W、GOPS/s	能效指标或重复写法	GOPS/W 表示功耗归一化吞吐；GOPS/s 语义上重复，因为 GOPS 已是 per second	Vega SoC 论文同时给出 32.2 GOPS 和 615 GOPS/W，并注明 2 OPs = 1 8-bit MAC；OFA 论文图中写 utilization (GOPS/s)。 citeturn27view0turn20view0

如果只保留最简结论，那么在你关心的"模型/硬件规格"范围内，可以把它记成一句话：GOPS 至少有三种主含义------硬件吞吐、模型复杂度、视频 GoP；而 GOPS/W 与 GOPS/s 只是围绕第一种含义衍生出来的写法。这也是为什么"同样写着 GOPS"的两个数字，可能一个表示 NPU 峰值速率，另一个却表示 ResNet50 单张图像所需的运算量。 citeturn23view0turn31view2turn42view3turn27view0

技术定义与计量关系

从计量学上说，OPS 是最宽泛的母集合，表示"operations per second"；FLOPS 是其中的浮点子集，强调 operation 的数据类型是 floating-point；GOPS 和 TOPS 只是 OPS 的数量级前缀，分别对应 (10^9) 和 (10^{12}) operations per second。Google TPU 论文用 92 TeraOps/second (TOPS) 描述 8-bit MAC 阵列的峰值吞吐，而 NVIDIA 在 GPU 性能指南中则用 TFLOPS 描述 TF32/FP16 的浮点峰值，说明同样是"每秒运算量"，其前缀与字母部分是否可直接比较，取决于数据类型与 operation 定义是否一致。 citeturn25view0turn32view0

最常见也最容易混乱的是 MAC 与 ops 的关系 。NXP 的 RT700 文档明确写出：64 MACs/cycle、325 MHz，所以峰值为 325 × 2 × 64 = 41.6 GOPS；NVIDIA 也明确说明 "Each multiply-add comprises two operations"，因此要从 multiply-add throughput 换算 FLOPS，要再乘 2；Vega SoC 论文同样在脚注中写出 2 OPs = 1 8-bit MAC。**这说明在很多硬件峰值文档里，默认口径是 1 MAC = 2 ops。**但这并不自动推出"所有论文/工具都必须这样算"，因为框架 profiler 和模型复杂度表往往根本不承诺统一的 MAC→FLOPs/GOPS 规则。 citeturn10view2turn32view0turn27view0

深度学习框架的官方口径恰好能说明这种不统一。TensorFlow 官方 tf.profiler 文档说明，float_ops 只有在算子注册了 RegisterStatistics('flops') 且 shape 可知时才能统计；没有 RunMetadata 时，位于 tf.while_loop 里的节点甚至只会被按"运行一次"计数。PyTorch 官方 torch.profiler 则把 with_flops 定义为"对特定算子（矩阵乘与 2D 卷积）用公式估算 FLOPS"。也就是说，官方框架更愿意把计量对象写清楚为 float_ops/FLOPs，而不是给出一个貌似统一、实际上非常依赖口径的 GOPS。 citeturn36view0turn36view1turn6view0

下面这个流程图把常见的计量关系与歧义点放在了一起。它不是某一家厂商的"官方标准图"，而是对上面原始资料的归纳整理。相关定义、换算与例外均来自前述官方/原始来源。 citeturn10view2turn32view0turn25view0turn36view0turn6view0
很多硬件规格采用 1 MAC = 2 ops
并非算力单位
口径依赖算子支持与运行元数据
MACs 或 MAC/cycle
OPS 或 FLOPS
GOPS = 10^9 ops/s
TOPS = 10^12 ops/s = 1000 GOPS
每输入运算量

GOPS/input 或 FLOPs/input
样本吞吐

samples/s 或 fps
实现吞吐近似值

OPS/s
GoP 或 GOPs

视频压缩语境
Group of Pictures
框架 profiler
TensorFlow float_ops / PyTorch FLOPs

若把它写成最常用的工程公式，可以近似记为：

• 硬件峰值口径 ：Peak_GOPS ≈ MACs_per_cycle × 频率(GHz) × 2 × 并行单元数
• 模型复杂度与实际吞吐的关系 ：实现 OPS/s ≈ 每输入运算量 × 每秒输入数

但这两个公式都只能在口径一致 时才可比较：前者默认支持的数据类型、稠密/稀疏状态与可映射算子集合相同；后者默认 每输入运算量 与 吞吐样本 的模型版本、输入尺寸、前后处理路径一致。 citeturn10view2turn32view0turn23view2turn35view0

真实来源中的用法差异

在芯片与加速器规格书 里，GOPS 几乎总是"吞吐型"。Arm Ethos-U85 的中文规格页直接写出"可扩展性能 - 256 GOP/s，1 GHz 频率时高达 4 TOP"；NXP 的 AN14700 不仅给出 41.6 GOPS，还把公式完整展开成 325 × 2 × 64；Renesas 在 RA8P1 发布资料中则把 Ethos-U55 的 256 MACs per cycle 与 256 GOPS at 500 MHz 对应起来。这里的共同点是：它们都把 GOPS 当作硬件在特定精度和特定计数规则下的速率能力，而不是某个模型的运算量。 citeturn8view1turn10view2turn10view1

在嵌入式/FPGA/ASIC 部署文档 里，情况开始分化。AMD 的 PG338 明确写 "Peak Theoretical Performance (GOPS)"，这仍然是吞吐型；但同一 AMD 生态中的 VCK5000 性能表又把 GOPS 与 fps 分成两列，表头先说吞吐量以 fps 为单位，再列出模型如 MLPerf_resnet50_v1.5_tf 的 8.19 GOPS 与 1476.8 fps。这种写法实际上说明：这里的 GOPS 更像是"单次推理运算量"列，而真正的吞吐指标是 fps。从该表数值还可以推导出一个"实际工作点"：8.19 GOPS/输入 × 1476.8 fps ≈ 12095 GOPS/s，这才接近设备在该模型上的实现吞吐；但表头中的 GOPS 本身并不表示"每秒"。这个推导是基于表中数值的计算性结论，而不是原文直接给出的定义，因此应视作推断而非原文措辞。 citeturn23view0turn8view0turn37calculator0

在基准与模型复杂度表 里，复杂度型 GOPS 很常见。早期 MLPerf Inference 论文在任务表里写得非常直白：ResNet-50 v1.5 8.2 GOPS / input、MobileNet-v1 224 1.138 GOPS / input、SSD-ResNet-34 433 GOPS / input。这说明至少在该历史版本里，MLPerf 把 GOPS 作为每输入复杂度 来展示，而非平台速率。值得注意的是，MLPerf 当前文档又改成了 FLOPs 字段，例如当前页面写 ResNet50-v1.5 FLOPs: 3.8 billion，而 MLPerf Inference 的正式结果页强调的核心仍是场景约束下的 latency/throughput ；MLPerf Training 更进一步，直接以"训练到目标质量所需的 wall-clock time"为主指标。同一个 benchmark 体系在不同时期和不同页面里，都未把 GOPS 当成唯一主指标。 citeturn31view2turn38view1turn15view0turn39view0

在学术论文 里，作者是否把 GOPS 当"速率"还是"模型预算"，要看伴随出现的量纲。OFA 论文把 MACs (Billion)、Arithmetic Intensity (OPS/Byte) 和 utilization (GOPS/s) 明确分开，属于非常规范的写法：MACs 是模型规模，OPS/Byte 是 roofline 分析中的算术强度，GOPS/s 则是实测利用率/吞吐。与之相对，BNext 论文在 ImageNet 精度语境下写出"80.57% Top-1 ... with 0.82 GOPS"，其缩写虽然没有在片段中展开，但从"精度---容量/预算"语境看，它更像是复杂度型运算预算而非"每秒速率"；这一点属于基于上下文的高概率判断，应当注明存在作者未在片段里显式定义缩写的有限不确定性。 citeturn20view0turn19view0turn18search0

在视频模型与压缩域论文 里，还会遇到完全不同的含义。CVPR 2025 的 EMA 论文开篇就在摘要与方法中把 GOPs 明确展开为 Group Of Pictures；它进一步定义每个 GOP 含一个 I-frame 和若干 P/B-frames，并据此构建 GOP encoder，把压缩流中的 I 帧和 motion vectors 编码为固定长度的 GOP feature。这里的 GOPs 与算力、FLOPs、TOPS 完全不是一个符号系统；如果读者不看上下文，只凭字母表面，就极易把视频压缩单元误读成算力指标。 citeturn42view0turn42view3

潜在误导与阅读风险

最危险的误导 是把"裸写的 GOPS"直接当成"设备速度"。很多文献和模型卡没有把 /input、/s 或 per sample 写全，尤其是在参数、精度、Top-1、fps 同时出现的表格中。早期 MLPerf 论文还算诚实，明确写 GOPS / input；但实际工程文档和论文中，经常只剩一个 GOPS。如果此时旁边还另列了 fps 或 latency，那么这个 GOPS 极大概率是复杂度 而不是吞吐 。AMD VCK5000 性能表就是最典型的例子：GOPS 与 fps 并列时，真正指"每秒"的是后者。 citeturn31view2turn8view0

第二个误导 是把不同计数规则下的数字直接横向比较。NXP、NVIDIA、Vega 都有明确证据表明，硬件峰值口径常按 1 MAC = 2 ops 计算；但当前 MLPerf 页面使用的是 FLOPs 字段，而官方框架 profiler 还会受到算子注册、动态 shape 和 RunMetadata 的影响。于是你会看到一种常见现象：同一模型在不同资料里，可能同时出现 GMACs、GFLOPs、GOPS，甚至相差接近 2 倍。**这不一定是谁算错了，往往只是 counting convention 不同。**严格说，若作者没有写清 MAC 是否折算为 2 ops，那么把这些值互相换算本身就是有争议的。 citeturn10view2turn32view0turn36view0turn6view0turn38view1

第三个误导 是把理论峰值当成实测有效吞吐。NXP 在应用说明里明确提醒，GOPS "is a measure of the maximum theoretical performance and may not represent the real-world performance"；NVIDIA 的 GPU 性能指南则从数学带宽、内存带宽、延迟、算术强度和并行度解释为什么应用实测吞吐常低于峰值；Vitis AI 的性能分析又把 AI acceleration、CPU processing、input reorder/copy、output reorder/unquantize 等时间拆开，并特别说明 AI acceleration 时间包含外部内存传输。因此，任何不说明测量路径的 GOPS/TOPS 数字，都不应自动理解为端到端推理能力。 citeturn10view2turn32view3turn23view2

第四个误导 是忽略 precision、sparsity 与批大小。Google TPU 的 92 TOPS 明确对应 8-bit MAC 阵列；Arm、NXP、Renesas 的 GOPS 也都与特定整数/神经网络 datapath 绑定；NVIDIA TensorRT 的官方 benchmark 示例显示，量化后的 ResNet-50 ONNX 模型在 batch size 4 下，Throughput 可从 507.399 qps 提高到 811.74 qps；NVIDIA 还在 Ampere 资料中说明，结构化稀疏可使 Tensor Core 计算吞吐相对稠密情形翻倍。也就是说，写着同样数量级的 GOPS/TOPS，如果一个是稠密 FP16，一个是稀疏 INT8，它们对同一个模型的可用意义完全不同。 citeturn25view0turn8view1turn10view2turn10view1turn35view0turn33search13

第五个误导 是把 TOPS/GOPS 当成生成式 AI 的充分指标。NVIDIA 在官方博客里非常直接地说，TOPS 只是"baseline"，而真实生成式 AI 体验还要看 tokens/s、images/s、批大小和内存容量。这个提醒对于理解"为什么一个 40 TOPS 的 NPU 不一定能在本地很好地跑大模型"尤其重要。反过来说，如果一份宣传材料只给 TOPS/GOPS，不给 latency、tokens/s、context、batch 或模型名，那么它更像"马力数字"，而不是可直接映射到用户体验的性能结论。 citeturn24view0

实务建议与推荐写法

如果你的目标是在阅读时快速判断作者意图，最稳妥的方法不是背定义，而是走一个简短的判别流程。下图把本文的实务判断规则压缩成一个工程化决策树。其规则来自前文列出的官方规格、MLPerf、框架 profiler 与视频模型论文。 citeturn23view0turn31view2turn42view3turn36view0turn6view0
是
否
是
否
是
否
看到 GOPS / GOP / GoP
附近是否有 MHz、MAC/cycle、peak、theoretical、INT8/FP16?
解释为硬件吞吐型 GOPS
附近是否有 /input、Params、Top-1、ImageNet，且 fps/latency 单独列出?
解释为模型复杂度型 GOP 或 GOPS/input
附近是否有 I/P/B 帧、motion vector、codec、compressed stream?
解释为 Group of Pictures
去看脚注、附录、工具文档或公式

如果你的目标是在报告中准确表述 GOPS ，建议遵守下面四条写法原则。

第一，永远把对象说全 ：是 峰值 INT8 吞吐、单样本前向运算量，还是 视频 GoP 结构。

第二，永远把口径说全 ：是否按 1 MAC = 2 ops；是 dense 还是 sparse；是理论峰值还是实测；是否含 host preprocess、PCIe/DDR 传输与后处理。

第三，永远把条件说全 ：精度、时钟、批大小、输入尺寸、模型版本、框架版本、是否量化、是否有 RunMetadata/算子支持限制。

第四，尽量避免裸写 GOPS ；在复杂度语境里更推荐写成 GOP/输入、GMAC/输入 或 FLOPs/输入，在峰值语境里更推荐写成 INT8 GOPS 或 FP16 TFLOPS。这些建议直接对应了 NXP、TensorRT、Vitis AI、TensorFlow 和 PyTorch 文档里对测量条件的强调。 citeturn10view2turn35view0turn23view2turn36view0turn6view0

在实际写报告时，我推荐采用下面三种句式模板，而不是单独写一个"GOPS 数字"：

"峰值稠密 INT8 吞吐为 41.6 GOPS，按 64 MAC/cycle × 325 MHz × 2 计算。" 这类写法适合硬件规格。 citeturn10view2

"该模型单输入复杂度约为 8.2 GOP/input；若采用 1 MAC = 2 ops 口径，也可写作约 4.1 GMAC/input。" 这类写法适合模型预算或 benchmark workload 描述；但若原始文档没有给出 MAC 口径，后半句应标为换算说明而非原文数值。 citeturn31view2

"本文中的 GoP 表示 Group of Pictures；每个 GOP 含 1 个 I-frame 和若干 P/B-frames，是视频压缩结构，不是算力单位。" 这类写法适合视频模型论文或压缩域方法说明。 citeturn42view3

最后给一个最务实的判断法则：**如果一个作者给了你 GOPS，但没有同时告诉你"每秒还是每输入、什么精度、什么计数规则、什么测量边界"，那这个 GOPS 还不够可比较。**这不是吹毛求疵，而是因为官方资料本身已经证明，不同生态对相同字母组合的定义和使用范围并不一致。 citeturn10view2turn35view0turn36view0turn39view0

主要参考来源链接

• Arm Ethos-U85 中文规格页。 citeturn8view1
• NXP AN14700《i.MX RT700 eIQ Neutron NPU Enablement and Performance》。 citeturn10view2turn11view0
• Renesas RA8P1 发布资料与产品页。 citeturn10view1turn22search3
• AMD PG338《DPU Performance on Different Devices》。 citeturn23view0
• AMD VCK5000 模型性能表。 citeturn8view0
• NVIDIA《GPU Performance Background User's Guide》。 citeturn8view2turn32view3
• NVIDIA TensorRT《Performance Benchmarking using trtexec》。 citeturn35view0
• TensorFlow 官方 profiler API 与 TensorFlow GitHub 的 float_ops caveats。 citeturn6view1turn36view0turn36view1
• PyTorch 官方 torch.profiler 文档。 citeturn6view0
• MLCommons 当前 MLPerf Inference Benchmarks 页面。 citeturn38view0turn38view1
• MLCommons MLPerf Inference Datacenter / Mobile 结果页与场景指标说明。 citeturn15view0turn15view1
• MLCommons MLPerf Training 页面。 citeturn39view0
• MLPerf Inference Benchmark 早期论文（含 GOPS / input 表述）。 citeturn31view2
• Google Research《In-Datacenter Performance Analysis of a Tensor Processing Unit》。 citeturn25view0
• ICLR 2020《Once-for-All》论文。 citeturn19view0turn20view0
• OpenReview《Towards Optimization-Friendly Binary Neural Network》。 citeturn18search0
• CVPR 2025《Efficient Motion-Aware Video MLLM》。 citeturn42view0turn42view3
• NVIDIA 官方博客《TOPS of the Class: Decoding AI Performance on RTX AI PCs and Workstations》。 citeturn24view0
• NVIDIA Ampere 稀疏性资料。 citeturn33search13turn33search1