企业官网建设流程全解析

外行看 AI 芯片，第一眼都会盯上宣传页那个最显眼的数字：TOPS。厂商发布会一喊"200 TOPS""1000 TOPS"，好像性能天花板就已经写死了。真把芯片买回来跑自己的模型，结果往往和纸面数字差一大截。这不是厂商造假，而是 TOPS 本身就是一个"理论上限值"，它只描述了芯片"全力空转时能算多快"，完全没回答你真正关心的问题：跑你那个模型，到底每秒能出多少帧？大模型每秒能吐多少个 token？

我在评估端侧 NPU 和边缘算力板卡时踩过不少坑，今天把这几个指标从定义到实测，再到换算逻辑完整捋一遍。这篇文章会拆清楚 TOPS、FPS、Token/sec 三者分别衡量什么、怎么换算、怎么测，以及什么样的评估流程才能支撑一次靠谱的芯片选型。

1. 先拆掉"算力军备竞赛"的滤镜：TOPS 到底是什么

1.1 TOPS 的计算公式里藏着哪些变量

TOPS 的全称是 Tera Operations Per Second，翻译过来就是"每秒万亿次操作"。它描述的是芯片在理想状态下每秒钟能完成多少次基本运算操作。这里最关键的两个字是"理想状态"。

芯片的标称算力来自一个非常简单的公式：

算力 = MAC 阵列数量 × 时钟频率 × 每次运算的操作计数

以常见的 NPU 架构为例，一个 MAC（乘加单元）一次可以完成一次乘法加一次加法。行业惯例把一次乘加算作两次操作（2 Operations），所以一个由 512 个 MAC 组成的处理单元，跑在 1GHz，它的算力就是：

512 × 2 × 1GHz = 1024 GOPS ≈ 1 TOPS

这个公式本身没有任何问题，但变数在于"用哪几个参数往里填"。频率可以填睿频上限，MAC 数量可以填整个芯片的合计值，操作计数可以因为精度定义不同而翻倍。更麻烦的是，有的厂商会把稀疏计算也折算进来——如果芯片支持 2:4 结构化稀疏，理论上有一半的权重可以被跳过，于是标称算力直接乘 2。这一路算下来，标称值已经是"理想中的理想"。

1.2 标称精度差异：INT8、FP16、BF16 各说各话

精度是算力标称里最容易做文章的地方。同一个 MAC 阵列，在不同数据精度下的吞吐完全不同。现在各家宣传页上出现最多的组合是 "INT8 稀疏" 算力，因为这个数字最大、最好看。但等你真的把模型转成 INT8 加载，结果往往要用几个加密工具链跑通，中间还伴随着校准、量化误差、算子不支持的回退，绝无可能达到宣传值。

我在评估一颗面向边缘视觉的 NPU 时就遇到过这种情况。芯片手册标称 INT8 总算力 32 TOPS，但我用 INT8 跑 YOLOv8s，实测帧率反推出来的有效算力只有 8~9 TOPS。原因很简单：卷积层吃到了算力红利，但模型里的非卷积算子（如某些激活、上采样、后处理）要么跑在性能低很多的通用核上，要么干脆得靠 CPU 协助。这些"算力黑洞"在 TOPS 标称里完全不存在。

还有个容易被忽略的点：FP16 和 BF16 不能混为一谈。FP16 在部分架构上可以实现 INT8 一半的吞吐，但 BF16 因为指数位分配不同，在有些老架构上反而跑不出 FP16 的速度。看 spec sheet 时一定要确认它标的到底是哪个精度下的数字，不要让"XX 芯片算力 50 TOPS"这样没有精度上下文的信息误导判断。

1.3 专项加速单元：TOPS 会被"偏科"放大

现在很多 AI 芯片不是单一的同质算力池，而是由卷积加速单元、Transformer 加速单元、向量单元、标量单元组成异构架构。TOPS 标称值往往只算了其中某几个加速器的峰值，活性对比的就是卷积或 MatMul 这类最容易加速的算子。

这带来的结果是：一颗芯片标称 TOPS 很高，可能只在"卷积密集型的 CNN"上成立；换到大模型里大量存在的矩阵乘法和 Attention 计算，就完全不是一回事了。这有点像一辆跑车，标称极速 350km/h，但那个速度只能在赛道直道上实现，城市路段根本不在讨论范围内。评估芯片之前，先看清楚它的"赛道"是 CNN 还是 Transformer，这是第一步。

2. 从 TOPS 到 FPS：一道"利用率"的算术题

2.1 单帧成本：你的模型一次推理要算多少

FPS（Frames Per Second）描述的是 AI 芯片每秒能处理多少帧图像或多少张输入。这个指标和 TOPS 之间的换算关系其实是一个很直白的除法：

理论 FPS = 芯片有效算力（TOPS） / 单帧推理所需操作数（GOPS）

所以要把两者对应起来，必须先知道你的模型一次推理消耗多少操作。这里有个容易踩的坑：很多论文和开源仓库里报告的模型计算量单位是 FLOPs（浮点操作数），而 TOPS 里的 O 是 Operations。一个乘加（MAC）在 FLOPs 里往往被数成两次浮点运算，但在 Operations 里只算一次乘加操作。换算时如果不把单位对齐，算出来的理论帧率会直接翻倍。

以 YOLOv8s 为例，官方报告的模型计算量大约是 28 GFLOPs，也就是 14 GMACs。如果用 INT8 推理，一次推理的"操作数"大约就是 14 GOPS。一颗真实可用算力 10 TOPS 的芯片，理论上限是：

10,000 GOPS ÷ 14 GOPS ≈ 714 FPS

听起来非常美好，对不对？但这是上限，不是你实测能拿到的数字。

2.2 实际利用率：为什么理论 FPS 要打个三到五折

我在实测中遇到的情况是，一颗标称 32 TOPS 的 NPU，跑 YOLOv8s INT8，单帧大约 2.1ms，折合 476 FPS。用真实算力反推利用率，大致在 35%~45% 之间。如果模型里含有比较多的非标准算子，利用率甚至能掉到 15% 以下。

利用率上不去，瓶颈通常出在这么几个地方：

• 数据搬运：AI 芯片算得快，但如果权重和激活值在片上缓存与外部存储之间来回倒腾，DDR 带宽很快就会成为瓶颈。很多宣称高 TOPS 的芯片，片上 SRAM 只有几 MB，模型超过几 MB 就得频繁搬运权重，利用率被显著拖低。
• 算子覆盖度：厂商的推理库通常对常见算子做了深度优化，但自定义算子或组合算子往往只能走通用回退路径，速度可能相差 5~10 倍。
• 流水线气泡：NPU 执行矩阵运算时，中间的归一化、激活、池化等操作如果安排得不够密，计算单元就会等待，形成"气泡"，造成利用率损失。
• 多核调度：多核 NPU 协调不好时，核心之间的同步开销会吃掉不少算力，尤其在 batch size 较小的场景。

2.3 单流 FPS 和批处理吞吐必须分清

还有一个经常引起误导的点：FPS 到底是单路视频流的推理帧率，还是把多张图打包成 batch 一起算的总吞吐。比如一颗芯片用 batch=1 跑一个模型，得到 100 FPS；但把 32 张图合成一个 batch 送进去，单次推理耗时可能只增加到原来的 3 倍，因此折合出来的"等效吞吐"可能高达 800 FPS 以上。厂商在实际宣传中经常选用 batch 模式下的吞吐数据，因为数字更好看。

评估芯片时一定要先明确你的使用场景。如果是视频结构化这类单流低延迟需求，对应的就是 batch=1 的 FPS；如果是离线批量图片处理，那看批量吞吐才合理。这两个场景下选型结论可能完全不同，不提前对齐口径，后面所有测试都白做。

我们不妨用一个实际算例把几个概念串起来。假设我手上有一颗标称 20 TOPS 的芯片，跑一个 30 GOPS 的检测模型，理论帧率是 667 FPS。实测时发现算子库覆盖率一般，有效利用率只有 35%，那实际帧率约 233 FPS。这个数字更接近真实部署体验。所以在看厂商报告时，永远要问一句："这个 FPS 是在什么模型、什么精度、什么 batch 下测出来的？"

3. Token/sec：大模型时代真正该盯的指标

3.1 prefill 和 decode 是两套完全不同的性能逻辑

大模型推理的 Token/sec 和传统视觉模型的 FPS 遵循完全不同的性能逻辑，因为生成式推理分两个截然不同的阶段：

prefill（预填充）阶段：用户输入的一段 prompt 一次性送入模型，并行计算所有 token 的注意力。这个阶段计算量大，但并行度高，属于计算密集（compute-bound）场景。引用高 TOPS 的芯片在这个阶段可以充分发挥优势。

decode（解码）阶段：模型逐 token 生成输出，每一步只能生成一个 token，而且每一步都要读取完整的模型权重参与计算。这个阶段的计算量相对小，但每次都必须把几十 GB 的权重从内存搬到计算单元，属于访存密集（memory-bound）场景，再高的算力也快不起来。

这两个阶段对芯片资源的需求完全相反。一个在 prefill 阶段飞快、decode 阶段拖沓的芯片，和另一个 prefill 一般、decode 极快的芯片，面对"短 prompt 长回复"和"长 prompt 短回复"两类应用时，用户感知差异会非常大。因此只看一个笼统的 Token/sec 数字毫无意义，必须区分阶段。

3.2 decode 速度的天花板：内存带宽说了算

decode 阶段为什么受带宽限制？可以用一个简单模型估算。比如一个 7B 参数的模型，如果以 FP16 存储，权重大约 14GB。每生成一个 token，理论上至少要把这 14GB 权重从存储中读一遍（实际还要加 KV cache 和激活值）。如果芯片的内存带宽是 50GB/s，那么单用户 decode 理论上限就是：

50GB/s ÷ 14GB ≈ 3.57 token/s

注意这是理论极限，还假设计算零耗时。算力再高，这个数字都不会变。这也是为什么很多端侧大模型只能跑出 3~5 token/s 的原因，并不是芯片不够强，而是 DDR 带宽已经封死了上限。

量化是打破这个瓶颈最直接的手段。同样 7B 模型，INT4 量化后权重从 14GB 降到约 3.5GB。在相同带宽下，理论 decode 上限提升 4 倍，达到 14 token/s。这也是为什么现在部署大模型几乎是"量化先行"。当然，量化会带来精度损失和额外的反量化开销，需要结合模型任务评估。

3.3 batch 与 KV cache：吞吐和延迟的博弈

大模型部署还有一个维度，是传统视觉评测里面没有的：并发用户数。随着 batch size 增加，内存读取的权重可以被多个请求共享，总吞吐（token/s 总和）会明显上升，但每个用户分到的响应速度会下降。这就是为什么服务端部署会用尽可能大的 batch 提升吞吐，而端侧交互应用必须接受单用户低并发下的延迟。

在长对话场景下，KV cache 会随序列长度增长不断占用带宽，从而持续压缩有效 token/s。所以你在厂商测试报告里看到的 Token/sec，一定要搞清楚它测的是多长的序列、KV cache 是否参与计算、batch 多大。一个"服务端 1000 token/s"的测试结果，很可能是在 batch=64、序列长度 2048 的条件下产生的，把这个数字当作单用户体验来期待会导致严重误判。

这个表格算的是单用户场景的硬上限。实测还要考虑算子效率、Attention 计算、缓存命中率等因素，所以用户真正感知到的 token 数往往在这个数字的 60%~80% 左右。

4. 怎么测才算数：一套可落地的 AI 芯片评估流程

4.1 测试前必须固定的一组变量

做了这么多轮芯片评估，我最深的体会是：芯片本身的问题往往不大，测试口径混乱才是选型翻车的最大原因。下面这几个变量是我在每次测试前都会强制自己先写进测试方案里的：

• 模型与版本：同一个模型不同版本的算子实现差异很大，测试前必须锁定 commit 版本，不能用"最新版"这种模糊描述。
• 输入尺寸：视觉模型锁分辨率，大模型锁 prompt 长度和生成长度，这些都会直接影响结果。
• 精度与量化方式：是 FP16、INT8 还是 INT4？量化后有没有做校准集？这些必须记录在案。
• Batch 大小：单流还是批量？如果两个都测，要分别报告。
• 框架与推理后端：PyTorch、TensorRT、厂商自研 runtime 的结果可以相差数倍。厂商自研 runtime 测出来的成绩通常最优，但它也是你最终部署要用的，所以测试必须和部署路径对齐，不要拿 PyTorch 的刚编译结果去否定一个已经适配到位的芯片。

4.2 三组核心测试：模型、功耗、持续稳定性

我会把测试拆成三个维度，分别回答三个问题：

第一问：这台芯片在我最核心的模型上能跑多快？

选 1~2 个和实际业务最接近的模型作为"锚点模型"，分别测 batch=1 的延迟和 batch 尽可能大的吞吐。记录下每一帧的耗时曲线，别只看平均值，要关注 P95 和 P99 延迟。在边缘端设备上，延迟抖动直接决定系统是否可用。

第二问：达到这个速度需要付出多少功耗？

算力脱离功耗谈性能没有意义。很多高 TOPS 芯片飙性能时功耗会冲到几十瓦，如果产品是电池供电，根本撑不住。测试时要记录整板功耗，计算性能功耗比（FPS/W 或 token/s/W）。我的经验是，这个比值比绝对性能更能预测实际产品体验。一个 5W 功耗下跑 100 FPS 的芯片，比一个 15W 功耗下跑 200 FPS 的芯片更适合绝大多数端侧产品。

第三问：持续运行会不会性能衰减？

把测试时间拉长到至少 30 分钟以上，记录温度曲线和性能曲线。很多芯片在冷启动时能维持峰值频率，运行几分钟后因为温度限制就降频，性能可能掉 20%~40%。如果芯片用于长时间运行的视频分析或线上服务，这个数字比冷启动峰值重要得多。

4.3 看数据之前先对场景，再看交叉验证

测出来的数据怎么用？第一步是对齐场景，不是只看数字高低。如果你做的是安防领域的实时视频结构化，核心指标就是 batch=1 的 FPS 和功耗；做自动驾驶，多路摄像头并发处理能力比单路峰值更重要；做端侧大模型助手，要盯住 decode 阶段的单用户 token/s；做云端批量推理，才需要关注大 batch 下的总吞吐。

第二步是交叉验证。如果条件允许，用 MLPerf 等公开基准的结果和自测数据互相印证。公开基准至少能说明芯片在某类任务上的"保底表现"，如果你自测的 Token/sec 或者 FPS 明显偏离公开结果，优先怀疑自己的测试方法，而不是直接怀疑芯片。我曾经因为没锁 CPU 频率，导致自测结果比厂商数据低了 40%，一度以为是工程样品有问题，最后发现是测试机上跑了一个后台进程在抢占内存带宽。

4.4 我也踩过的几个"隐藏陷阱"

• 预热不足：推理框架通常有初始化开销，前几次推理会比稳定态慢不少。正式计时前先跑几十次热身，才能拿到稳定数据。
• 只测单帧：单帧耗时看着是 5ms，但连续推理时因为内存复用和调度限制，实际吞吐可能只有理论值的一半。我习惯用"连续跑 1000 帧中间不加等待"的方式测真正稳态。
• 忽略后处理：AI 芯片通常只加速模型本身，NMS、解码、前处理这些环节经常在 CPU 上执行。端到端 FPS 和模型 FPS 是两码事，产品评估一定要以端到端为准。
• 拿不同的量化标准对比：有的芯片 INT8 是真正的 8bit 量化，有的却是 INT8 权重配 FP16 激活，实际效率差异不小。没有确认量化细节就横向比较，结论没有参考价值。

最后再说一点我自己的习惯。正式评估报告里，我会固定用这样一张表来汇总数据，避免被厂商或多或少的宣传话说晕：

这套方法帮我在过去两年里筛掉过两台"纸面数据漂亮、实际项目跑不动"的开发板，也帮我拦住过一次因为盲目相信高 TOPS 而差点选错芯片的方案。评估 AI 芯片，说到底是拿你的真实模型、在真实场景下、跑真实数据，并且用统一的尺子去量。TOPS 决定的是天花板的起点，FPS 和 Token/sec 决定的才是你能不能交付产品。