如何评估一颗 AI 芯片的真实性能？TOPS、FPS 与 Token/sec 全解析

关键词：AI芯片性能评估、TOPS、FPS、Token/sec、推理吞吐、延迟测试、任务绑定、工程指标、计算效率

摘要：
AI 芯片在实际部署中，其理论峰值性能往往无法反映真实执行效率。如何科学评估一颗 AI 芯片的“真实性能”，已成为芯片选型与系统集成环节中的关键技术问题。本文从工程实战角度出发，深入拆解当前常用性能评估指标（TOPS、FPS、Token/sec）背后的定义逻辑与使用陷阱，并结合推理模型部署与执行路径，系统讲解 AI 芯片在不同场景下的性能验证方法。通过对芯片算力-功耗-调度三维关系的分析，读者将掌握评估一颗 AI 芯片是否“跑得动业务”的核心判断能力。

真实 vs 理论：AI芯片性能评估的常见误区与分歧
TOPS 指标详解：定义、计算方式与误导风险
FPS 测试方法：场景绑定与实际吞吐估算方式
Token/sec 的测量逻辑：从Transformer到语言模型的核心指标
评估中常见偏差来源：精度模式、数据流设计与调度方式
工程实战：典型芯片平台的性能测试方案构建
任务级调度评估：Tile映射、指令重排与资源复用影响
总结：建立“业务驱动”的AI芯片性能评估方法学

第1章：真实 vs 理论——AI芯片性能评估的常见误区与分歧

1.1 为什么“跑得快”≠“性能强”

AI芯片的宣传页面往往以一个鲜明的数字作为主打：XXX TOPS。但在实际工程部署中，开发者最关心的问题从来不是“芯片峰值能算多少”，而是：

真实业务下的推理速度是否达标？
系统资源是否足以支撑连续工作？
功耗是否控制在设备允许的热设计功耗（TDP）内？

这就形成了第一层 “理论性能”与“系统性能”之间的鸿沟。例如一颗声称 128 TOPS 的芯片，在一个 INT8 精度的分类任务中，实际推理速度只有 200FPS，资源利用率不到 30%。这并不一定代表芯片无效，而是说明：

芯片的结构设计、数据流路径、调度策略、模型架构之间存在不匹配。

1.2 典型的性能评估误区

常见误区	说明	实际表现
仅看TOPS	峰值理论性能	忽略数据搬运、调度等待
忽略任务调度模式	推理延迟依赖于Tile编排与DMA时序	任务切换导致帧延迟激增
混用精度指标	不同精度下TOPS/FPS不可直接横向比较	FP32与INT8无可比性
误用FPS评估小模型	小模型可能早已饱和带宽	芯片资源空转但吞吐看似很高
以Benchmark代替业务验证	公共模型无法代表业务复杂度	真实部署时性能反而下降

因此，对于企业部署、工程交付场景而言，必须转向 “场景绑定式性能评估”：即围绕实际任务模型、目标延迟与吞吐量、精度设定三大维度开展测试与优化。

1.3 建议的评估原则

业务驱动优先：以任务维度的 Token 延迟、任务完成时间为核心评价指标；
多指标组合：同时测量 TOPS 占比、FPS、功耗、资源利用率；
调度对齐验证：绑定真实模型调度路径，避免 synthetic benchmark 干扰判断；
精度透明化：明确每个指标对应的精度类型（如INT8、BF16等）；
片内瓶颈定位：区分计算瓶颈（PE不足）、数据瓶颈（带宽不足）、调度瓶颈（控制路径不匹配）。

第2章：TOPS 指标详解——定义、计算方式与误导风险

2.1 什么是 TOPS？

TOPS（Tera Operations Per Second）即“每秒万亿次操作数”，用于表征 AI 芯片在特定精度下的理论最大计算能力。

一般计算公式为：

TOPS = PE数量 × 每个PE的OPS × 主频 × 精度效率系数 / 10^12

其中：

PE数量：张量计算阵列中的乘加单元个数；
OPS：通常为 MAC（Multiply-Accumulate）次数；
精度效率系数：与数据宽度有关，如INT8 通常效率最高，FP32最低；
主频：影响理论操作次数，但易受到散热、电压影响。

2.2 为什么TOPS容易“虚高”？

误导一：以INT8为基准标注全部精度性能

许多芯片标注的 100+ TOPS 实际是 INT8 精度的峰值。然而：

在 FP16 下，其性能可能仅为 1/2；
在 BF16 下，受乘加结构重构影响，实际更低；
更别提 FP32，这通常被用于训练，推理芯片不支持或效率极差。

误导二：忽略资源调度和内存带宽

TOPS 不考虑数据是否能“及时喂给”算子执行：

数据通路不畅，PE 就会空转；
模型结构不规则导致 PE 活跃率低；
Tile 执行不均衡引发 pipeline 断裂。

误导三：实测场景不说明前提条件

很多“峰值TOPS”是在最理想模型结构（大卷积、规则矩阵乘）中测得，工程中常见的剪枝模型、小算子模型根本无法激活全部PE。

2.3 如何合理使用TOPS指标

仅用于芯片结构能力的上限估计；
结合PE活跃率计算“实际TOPS占比”，例如：

实际TOPS = 理论TOPS × PE活跃率 × 精度系数

结合能耗计算TOPS/W指标，判断芯片能效比（即性能/功耗比）；
不将TOPS作为唯一性能参考值，而应与调度结构、模型适配度共同评估。

第3章：FPS 测试方法——场景绑定与实际吞吐估算方式

3.1 什么是 FPS？为什么它不能泛用？

FPS（Frame Per Second）代表芯片每秒钟完成推理处理的图像帧数，是视觉任务中最直观的吞吐指标，常用于图像分类、检测、分割等场景的性能评估。

FPS 通常以如下方式计算：

FPS = 总处理帧数 / 总用时

但这个指标的可靠性，取决于几个关键前提：

任务模型必须固定：不同网络结构对芯片资源调度的要求差异巨大；
输入尺寸必须明确：不同分辨率会影响 Tile 切分数量与内存搬运；
执行精度必须标注：INT8/FP16 的性能差距可达 2~10 倍；
系统边缘开销必须剔除：如传感器延迟、I/O耗时、预处理等。

因此，在工程实践中，只有明确绑定业务场景，FPS 才有工程指导意义。

3.2 视觉类任务中的 FPS 评估方法

以下为推荐的场景化 FPS 测试流程：

步骤	内容
模型绑定	选定业务中真实部署的模型结构与参数
输入构造	固定输入图像尺寸（如640×480），使用真实数据或模拟静态数据集
精度标注	明确使用的是 INT8/BF16/FP16/FP32
延迟分离	使用 on-chip profiler 分离出 Preprocess / Inference / Postprocess 时延
多轮测试	使用 warm-up + steady-state 测试，排除冷启动影响
工程对比	对比调度器配置优化前后的FPS变化（如Tile调度优化、缓存预加载）

实际项目中，例如在智能摄像头中使用轻量检测模型（YOLOv5-Nano），AI芯片初始吞吐量为 65FPS。通过调度器粒度细化、DMA路径优化和PE阵列重新绑定后，优化到 91FPS，提升幅度超过 40%，但 TOPS 未发生改变，说明 FPS 更能反映系统端到端执行效率。

3.3 FPS 的工程误用陷阱

错误做法	问题
用相同模型评估不同芯片，不注明输入尺寸	无法公平比较（如320×320与640×640）
将“含预处理”的 FPS 与“纯推理”对比	误导真实芯片性能
不说明批大小（Batch Size）	芯片吞吐与Batch高度相关
忽视 Postprocess 时间	目标检测任务后处理占据大量时间

建议在报告中明确说明：

“INT8精度、输入640×480、单Batch下，模型X在纯推理阶段平均FPS为95，芯片资源使用率84%，峰值功耗2.9W。”

第4章：Token/sec 的测量逻辑——从 Transformer 到语言模型的核心指标

4.1 为什么视觉类 FPS 不适用于 Transformer？

与图像推理不同，Transformer 模型（如 BERT、GPT、ViT、SAM）推理过程中以Token为计算粒度，其执行路径由输入 Token 长度、头数、隐藏维度、序列深度共同决定。

此类模型往往包含：

大规模的 矩阵乘 + Softmax + LayerNorm 结构；
动态控制流（如自注意力路径）；
难以统一量化路径（Mixed Precision）；

因此，**Token/sec（每秒推理Token数量）**成为衡量这类模型吞吐能力的核心指标。

4.2 Token/sec 的定义与测量方法

Token/sec = 总处理Token数 / 总推理耗时

其中的“Token”通常指每轮推理中送入 Transformer 的 token 数量，而非输出token（生成任务另计）。

测量步骤建议：

步骤	说明
模型绑定	如部署 BERT-base，输入为 128 tokens
运行设置	精度设定为 BF16 / INT8 / FP16，Batch Size 固定（如8）
数据源	随机Token输入或文本样本
测试方式	连续运行N轮，排除初始化热身阶段
计算方式	汇总 Token 数，总耗时除以Token量

例如，在部署 LLaMA 模型的边缘推理场景中，测得芯片运行 2048 token，耗时 330ms，则：

Token/sec = 2048 / 0.33 ≈ 6206 Token/sec

4.3 Token/sec 指标背后的性能意义

场景	Token/sec 意义
文本理解模型	表征每秒能完成多少用户输入的处理
多轮对话任务	影响交互延迟与多用户吞吐
多头注意力优化	Token长度提升时，性能退化速度决定系统扩展性
Token Streaming	逐个输出Token时的延迟（Latency）成为主因

同时，Token/sec 也能反映芯片在“Tile级矩阵乘 + Softmax调度 + 数据缓存”的链条表现。性能瓶颈很可能不是计算本身，而是：

Token映射到 PE 阵列后不能并行展开；
LayerNorm 与 Softmax 调度与张量通路重叠；
缓存失配导致中间张量频繁写入L2。

4.4 精度与 Token/sec 的非线性关系

不同模型对精度的敏感性决定 Token/sec 的可优化空间：

BERT类模型：对 INT8 极为敏感，精度下降显著；
ViT类模型：部分中间层可 INT8 跑，混合精度适合；
大语言模型（LLM）：推理阶段可以在 BF16 跑得很稳。

在芯片编译阶段需控制：

精度转换点的位置；
子图分配方式；
动态Token长度的路径分支数量。

第5章：评估中常见偏差来源——精度模式、数据流设计与调度方式

5.1 精度模式对性能评估的影响

AI芯片执行效率受精度设置影响极大。即使是同一模型、同一架构，在不同精度模式下表现可能截然不同。

精度模式	描述	性能影响
FP32	高精度浮点，训练常用，推理性能最差	计算密集、功耗高、资源占用大
FP16/BF16	主流推理精度，能效比与精度平衡点	部分芯片仅支持其中之一
INT8	低比特定点量化，性能极高但精度敏感	需配合量化感知训练或校准
Mixed-Precision	不同层使用不同精度，需芯片支持调度切换	兼顾性能与精度的策略

错误评估案例：部分芯片标称 INT8 模式可达 120 TOPS，但实际部署模型以 FP16 为主，仅能触发 40% PE 活跃度，导致性能远低于预期。

在评估中应明确测试精度模式，并对比不同精度下的 Token/sec、FPS 与能耗数据。

5.2 数据流路径设计对性能的影响

AI芯片的计算效率不是孤立的，它严重依赖于数据能否及时送达计算阵列（TPA/PE），否则将导致算力空转。

关键影响因素：

SRAM结构：L0/L1/L2 不同缓存设计影响张量装载效率；
DMA调度策略：顺序搬运 vs 并发搬运对带宽利用率的拉动能力差异大；
广播与Tile重映射机制：数据是否能共享给多个PE，是评估中的核心；

工程中，若某模型内存在大量跨通道广播（如Transformer中Q/K/V共享输入），若芯片广播路径为“线性多播”，极易导致广播阻塞，影响整体吞吐。

高性能评估必须已关注 数据搬运效率 与 芯片的数据通道设计细节。

5.3 调度方式对真实性能的系统性干扰

调度器（Scheduler）是 AI 芯片运行时系统的“指挥官”，它决定了：

Tile 何时进入阵列
PE 如何调度张量执行
缓存如何分配与回收

常见调度相关偏差包括：

调度偏差类型	描述	性能影响
Tile调度粒度过粗	整个子图一次性调度	阵列利用率低，阻塞严重
任务切换点未绑定上下文	Runtime 不清楚上轮状态	数据丢失或重算，影响延迟
调度优先级无负载感知	没有按PE资源动态排队	高负载子图拖慢整体吞吐
调度器与模型图解耦	Scheduler 不感知IR图结构	常导致重复搬运、Tile冲突

因此，性能评估前需验证调度器版本、策略是否启用了“静态预调度表”、“子图动态绑定”、“Tile流水优化”等关键特性。

第6章：工程实战——典型芯片平台的性能测试方案构建

6.1 工程测试目标的定义方式

不同业务有不同目标，性能测试要为业务服务：

视觉场景（目标检测/分割）：以 FPS 与系统延迟为主
语言模型（Transformer）：以 Token/sec 与 Token Latency 为主
控制/工业场景：任务切换时间、上下文恢复能力、温控稳定性

应避免“测得多，不如测得准”的误区。

6.2 推荐测试流程

一个标准的芯片性能测试过程应包括以下阶段：

阶段	内容	工具建议
模型绑定	固定模型结构、输入维度与精度模式	PyTorch/ONNX/IR 流
部署验证	确保模型转换正确，输出精度与预期一致	Golden output比对、误差容忍设定
Profiler接入	芯片端导出资源使用、调度日志、功耗曲线	芯片自带Profiler或片外协处理模块
多轮测试	连续运行>1000轮，收敛稳定值	排除冷热启动影响
异常检测	检测是否有资源饱和、Tile丢失、指令阻塞	Runtime日志+硬件状态监控

6.3 芯片平台评估报告建议结构

输出结构化性能报告建议包含：

模型信息：

网络结构、参数量、Batch Size
输入维度与类型（图片/Text/语音）

芯片配置：

PE阵列规模、DMA路径、SRAM配置
精度支持能力、频率、电压配置

测试指标：

FPS / Token/sec
推理延迟（cold & warm）
PE活跃率 / DMA带宽 / SRAM命中率
功耗（Watt）、温度（°C）

调度策略摘要：

是否启用静态Tile划分
数据调度方式（同步/异步/广播）
子图调度机制（深度优先/任务依赖树）

优化建议：

调度器策略修改点
模型结构适配建议
软件编译优化路径（量化、融合等）

第7章：任务级调度评估——Tile映射、指令重排与资源复用影响

7.1 Tile 映射策略对任务调度效率的影响

在真实部署中，模型往往无法整体加载进AI芯片阵列，必须进行张量的空间、通道或时间维度切分（Tile）。Tile映射的方式决定了：

PE阵列的活跃程度
缓存重用效率
数据搬运延迟

典型映射策略：

映射类型	适用情况	资源占用	优缺点
空间切块	图像任务（卷积）	低-中	PE利用率高，数据复用差
通道切块	深层网络（多通道）	高	通道并行性强，Tile大小难控
时间切片	RNN/Transformer	中	延迟敏感，调度链复杂

实际工程中，混合Tile策略+任务感知动态绑定是主流方案。

例如，在一个Transformer部署场景中，Token维度切块为主，但Q/K/V模块之间共享通道维度结构，需单独调度重映射。

7.2 指令重排对阵列流水效率的提升作用

调度器在生成执行计划时，常通过 指令重排 来优化阵列执行顺序，从而减小空闲时隙，提高流水密度。

常见重排策略：

Layer内指令融合：将多个算子（如Conv+ReLU+BN）合并成一个PE宏指令；
访存-计算交织：安排数据搬运与执行重叠，避免等待；
计算顺序回退：由于数据未就绪，临时回调可执行路径，提升资源利用；

例如，在图像分割任务中，采用指令重排策略后，单帧推理延迟从 23.8ms 优化至 16.1ms，性能提升超 30%。

芯片调度器是否具备“调度图感知+资源依赖解耦”的能力，是评估高端芯片性能的重要维度。

7.3 资源复用策略对吞吐能力的系统拉动

AI芯片的真实性能还高度依赖对关键资源的复用策略，包括：

缓存（L0/L1/L2）：张量不重复装载、跨层共享；
PE阵列：分批调度、任务绑定清晰；
DMA通路：顺序执行转并行搬运、跨通道隔离优化；

工程实践中，若模型中间层张量未能在 L1 保持，导致 DMA 重复搬运，实际 Token/sec 下降 15%~40% 不等。

解决方法包括：

图调度器启用重用优先路径
编译器在 IR 生成阶段进行缓冲路径优化
Runtime 建立动态张量映射表

第8章：总结——建立“业务驱动”的 AI 芯片性能评估方法学

8.1 从“通用算力”走向“任务性能”的评估转型

长期以来，行业评估 AI 芯片过于依赖通用TOPS、“理想吞吐”，而忽略业务场景的运行边界。AI芯片的真实价值，取决于其在任务调度、资源压缩、功耗控制和部署便利性中的综合表现。

建议构建“业务驱动的芯片评估体系”，核心维度包括：

维度	评估点	说明
任务适配性	是否支持核心模型结构	Transformer / CNN / GNN 等主流结构支持情况
性能一致性	Token/sec / FPS 在长时间任务中的稳定性	是否出现退化、资源饱和等瓶颈
资源调度能力	Scheduler 是否支持任务绑定、PE复用、动态Tile切换	决定运行时执行效率
精度与能效比	支持哪几种精度、是否提供软硬协同精度控制机制	与精度切换带来的性能波动挂钩
系统集成能力	Runtime API 设计、部署方式、异常可追踪性	决定开发成本和故障恢复能力

8.2 工程落地视角下的性能测试建议

步骤	建议做法
模型绑定	用实际业务中部署的结构测试，不用“通用模型”
精度测量	同时测量 INT8、BF16、FP16 模式的性能，给出精度-效率对比图
调度剖析	打开调度日志，查看每步张量是否被重复装载、PE是否空转
异常测试	构造极端输入、打乱 Batch、模拟中断，观察系统回退机制是否生效
可复现报告	固定模型版本、芯片频率、Batch Size，确保多轮评估一致性

8.3 面向未来的芯片性能评估趋势

模型驱动评估（Model-centric Benchmark） 将取代通用TOPS排名；
图调度分析工具 将成为部署调优的核心辅助工具；
多任务、多模型并发测试 将成为新一代 SoC 芯片必须提供的评估能力；
开源芯片调度标准（如MLIR、TVM调度模块）将促进厂商之间评估对齐。

只有把性能评估建立在“真实业务约束”之下，才能真正筛选出能落地、能长期支撑系统演化的AI芯片平台。

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注人工智能领域。
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
具身智能：具身智能
国产 NPU × Android 推理优化：本专栏系统解析 Android 平台国产 AI 芯片实战路径，涵盖 NPU×NNAPI 接入、异构调度、模型缓存、推理精度、动态加载与多模型并发等关键技术，聚焦工程可落地的推理优化策略，适用于边缘 AI 开发者与系统架构师。
DeepSeek国内各行业私有化部署系列：国产大模型私有化部署解决方案
智能终端Ai探索与创新实践：深入探索智能终端系统的硬件生态和前沿 AI 能力的深度融合！本专栏聚焦 Transformer、大模型、多模态等最新 AI 技术在智能终端的应用，结合丰富的实战案例和性能优化策略，助力智能终端开发者掌握国产旗舰 AI 引擎的核心技术，解锁创新应用场景。
企业级 SaaS 架构与工程实战全流程：系统性掌握从零构建、架构演进、业务模型、部署运维、安全治理到产品商业化的全流程实战能力
GitHub开源项目实战：分享GitHub上优秀开源项目，探讨实战应用与优化策略。
大模型高阶优化技术专题
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理的完整全流程
Agentic AI架构实战全流程：一站式掌握 Agentic AI 架构构建核心路径：从协议到调度，从推理到执行，完整复刻企业级多智能体系统落地方案！
云原生应用托管与大模型融合实战指南
智能数据挖掘工程实践
Kubernetes × AI工程实战
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路：本专栏聚焦开发 / 测试人员的实际转型路径，基于 OpenAI、DeepSeek、抖音等真实资料，拆解从入门到专业落地的关键主题，涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话，只做实战经验沉淀，让你一步步成为真正的模型运营专家。