这颗芯片到底行不行这是我在选型时被问得最多的问题也是工程师之间最容易吵起来的问题。业内有个很普遍的现象厂商发布会喜欢报TOPS做方案的人喜欢问FPS做大模型落地的人一上来就问Token/sec。这三个指标其实都在描述同一件事——AI芯片有多快但口径完全不同硬拿去横向对比轻则性能偏差一倍重则整个项目返工。这篇文章我想把这三个指标一次性掰开揉碎。它们各自怎么算出来的、衡量的是什么场景、有哪些隐藏的水分、怎么组合起来用我会结合我做过的选型测试和实际踩坑经历来讲。目标是让你拿到任何一颗AI芯片的参数表都能快速判断它适不适合你的业务而不是被一个漂亮的数字牵着走。1. TOPS这个数字是怎么被“吹大”的1.1 一次乘法加法算1次还是2次操作TOPS的全称是Tera Operations Per Second也就是每秒钟能执行的万亿次操作数。听起来很直接但问题恰恰出在“操作”这两个字上。AI计算里最基础的运算是乘加操作英文缩写叫MAC它做的事情是先做一次乘法再加一次加法两步合在一起。比如一个矩阵乘法本质上就是大量MAC的堆叠。那么问题来了一次MAC到底算一次操作还是两次不同的厂商有不同的算法。有的厂商按MAC来统计有的厂商按Multiplication和Addition分开统计于是同一个硬件用两套口径算出来TOPS数字直接翻倍。我见过一份芯片白皮书正文里写了一行小字TOPS基于总操作数计算含乘加分离统计。翻译过来就是它报的数值已经是按两次操作叠加后的结果了。如果你拿MAC数去换算实际性能要除以2。所以第一件事看到TOPS先问一句这是MAC口径还是OPs口径两者差一倍。1.2 精度不同算力差出个数量级2023年之后AI芯片的算力表越来越热闹动辄几十TOPS上百TOPS但如果不看精度这个数字基本没有参考价值。因为同样的硬件电路跑FP32、FP16、INT8、INT4算力是完全不同的。以主流NPU为例如果它FP16算力是XINT8通常是2倍INT4可以到4倍左右。有些专用芯片干脆只支持INT8和INT4那它的INT8算力自然显得很猛。但你的模型如果跑的是FP16实际能用的算力就只剩一半甚至四分之一了。拿一个典型的端侧推理场景来说一颗标称30 TOPS INT8的芯片实际跑FP16模型时只能释放15 TOPS左右再算上实际利用率打个三五折真实有效算力可能也就是5到8 TOPS的水平。这不是厂商造假而是你拿错了比较维度。1.3 稀疏化带来的“理论翻倍”现在很多AI芯片支持稀疏计算也就是把模型里大量的零权重跳过不计算理论上可以带来接近2倍的加速。芯片规格书上标的是支持2倍稀疏意思就是如果模型权重稀疏度达到50%算力可以翻倍。但问题在于你的模型不一定剪得出来这么高的稀疏度。我实际测试过一些公开的稀疏模型权重稀疏度做到30%到40%都不容易更别提50%了。有些厂商干脆把稀疏模式下的峰值算力直接印在宣传页上看着比竞品高一截实际部署时根本跑不出来。提示读TOPS时记住这个公式——真实可用算力约等于标称TOPS乘以精度折扣FP16约0.5INT8约1.0再乘实际利用率通常0.3到0.6。忽略任何一个系数决策就可能出问题。2. FPS算力变成“能感知的体验”2.1 为什么端侧AI都得看FPSFPS全称Frames Per Second意思是每秒处理多少帧。听起来像是游戏玩家关心的数字实际上在端侧AI里反而是最接地气的指标。原因很简单摄像头拍出来是一帧一帧的图很多AI应用就是逐帧去处理这些图。你能一秒处理30帧就能做到实时一秒只能处理5帧那就只能抽帧处理或者干脆没法上线。很多人对FPS的直观感受来自游戏左上角那个帧率显示cs2或者fps射击游戏里大家习惯看左上角的fps gpu cpu参数来判断电脑性能。这个直觉放在AI芯片上其实也能类比游戏里帧率代表画面渲染速度AI芯片的FPS代表算法推理速度。但有个关键差异游戏里FPS掉到30就会觉得卡AI场景里你要的是在指定时延内把这一帧处理完超过预算帧就是丢了下一帧再出现时目标可能已经变了。在我做过的一个智慧安防项目里边缘盒子要同时接8路摄像头做实时检测。当时拿到的芯片标称能力很漂亮但实测跑目标检测模型在1080p输入下只有12 FPS。单路实时要求25 FPS以上这芯片单路都满足不了更别说多路并发整个方案只能推翻重来。这个教训让我后来看任何芯片第一个问题永远是跑我的模型在目标分辨率下能达到多少FPS2.2 同样一颗芯片FPS能差出好几倍FPS这个数字比TOPS实在很多但它也不是一个固定值。同样一颗芯片跑不同模型、不同分辨率、不同软件栈FPS差距能拉到4到5倍。我用一颗典型的端侧NPU做过一组对比跑YOLOv5s和YOLOv8s两个检测模型同为640x640输入INT8量化FPS分别是31和19。换成EfficientDet-Lite则掉到12。分辨率的影响也很夸张从640x640降到320x320FPS不是简单的4倍提升——因为特征图、锚框等计算开销并不是线性缩放实测能提升5到6倍。软件层面的差异同样不能忽略。用厂商自带的推理引擎跑和用开源runtime跑同一模型性能可以相差30%以上。有些厂商对某个特定模型做了深度算子优化跑那个模型分数特别高跑你的模型就原形毕露。这也是为什么我说厂商benchmark里那个甜蜜点模型看看就好。2.3 测FPS时最容易忽略的隐藏变量除了模型和分辨率还有几个变量在影响FPS测试结果稍不注意对比就失去意义。Batch size批量大小。端侧推理通常batch1也就是一次处理一张图但厂商测试往往用batch4甚至batch8来拉高吞吐。batch4的FPS可能是batch1的2倍但你的业务场景未必能用上大batch。量化与校准INT8量化用什么校准集决定精度损失和实测速度有些芯片用W8A8和W4A16混搭精度速度差异也很大。后处理是否计入NMS、解码这些后处理有没有算进FPS里能差出5到10个毫秒对应帧率差3到5帧。我建议做横向对比时固定一套测试模板同一模型文件、同一输入分辨率、同一batch、同一推理框架、包含完整的预处理和后处理所有芯片都按这个模板跑数字才有参考价值。3. Token/sec生成式AI时代的新尺子3.1 LLM推理为什么让TOPS失灵大语言模型爆发之后芯片评测又多了个新指标Token/sec也就是每秒生成多少个token。这个指标背后是LLM推理的特殊机制自回归生成。模型生成一个词要看之前所有词的结果然后逐token地往下推。整个流程分成两个阶段。第一个阶段叫prefill处理一整段输入prompt把中间状态计算出来这个阶段是计算密集型的TOPS指标还能起点作用。第二个阶段叫decode每生成一个新token只需要处理一次增量计算这个阶段变成了访存密集型内存带宽反而成了瓶颈。为什么因为模型参数是固定的比如一个7B参数模型FP16精度下权重就有14GB即使在decode阶段只计算很少的矩阵乘法也需要把全部权重从内存里读一遍。你算力再高内存带宽跟不上芯片就是在等数据搬运算力闲置。这就是为什么有些算力很高的云端芯片跑LLM推理时速度反而不如一些带宽设计更激进的芯片。3.2 报Token/sec时必须看清这三个口径Token/sec听起来是一个简单数字但实际测试时至少有三种口径混着报最常见。第一种是prefill阶段的token吞吐。也就是处理prompt的速度通常用tokens/s表示数字一般很大因为一次性并行处理大量token。第二种是decode阶段的token生成速度也就是逐token生成时的速率芯片在这个阶段往往吞吐较低这个数字才是用户实际感受到的“打字速度”。第三种是端到端平均速度把prefill和decode全算进去用总token数除以总耗时这个数字落在前两者之间。厂商宣传时如果他用的是prefill数值看起来会很漂亮但用户实际体验决定于decode阶段。另外还要注意并发口径。单用户独占跑出来的Token/sec和32个用户并发时每个用户分到的Token/sec是完全不同的两个概念。有些云端服务商宣传整卡吞吐很高但拆到单个用户头上可能只有个位数体验非常差。我做测试时会同时记录两个数并发总吞吐和单用户速率前者看硬件上限后者看体验下限。3.3 我常用的Token/sec体验分界线对Token/sec到底多少才算够用不同场景标准完全不同。根据我自己的使用感受和跟不少做AI应用的同行交流我大致画了几条线。实时语音对话要求首token延迟低也就是prefill要快生成速度最好在30 Token/sec以上否则对话有明显停顿感。智能问答助手10 Token/sec是一个门槛低于这个速度人会觉得卡顿20到30 Token/sec算舒服。离线批量处理比如批量改写、摘要生成不需要实时交互5 Token/sec也能接受因为不涉及用户体验。顺带说一个估算方法decode阶段每生成一个token理论上要把整个模型权重读一遍。以一个7B模型INT4量化为例权重大约是4GB如果你想要30 Token/sec意味着内存带宽至少需要4GB乘以30等于120GB/s。如果芯片的带宽只有50GB/s那无论算力多强Token/sec都不可能到30。买芯片前先做这个算术题能帮你快速排除一批不靠谱的选项。4. 我的评估流程三步走选型不踩坑4.1 第一步把业务场景翻译成性能指标芯片选型第一步不是看参数表而是先明确自己的场景到底需要什么。同样是AI芯片智能门锁、自动驾驶、大模型一体机对性能的要求完全是不同的。我习惯把需求拆成四个维度跑的什么模型、什么精度、实时性要求是多少毫秒、同时跑几路。比如一个智能门锁的人脸识别方案可能只需要一个50M参数的小模型但要求从图像采集到完成识别300毫秒以内而一个ADAS前视方案要跑多个模型至少30 FPS实时处理而且必须做多路冗余。四个维度确认之后再来对照芯片指标。如果场景是“单帧时延敏感型”那就优先看重FPS如果是“高并发生成型”Token/sec才是核心如果只是把简单分类模型部署到海量设备上TOPS结合成本就够了。没有万能芯片只有场景匹配。下面是我常用的一张选型速查表典型场景首要指标次要指标备注智能摄像头/门锁FPS时延功耗单帧处理时延达标即可ADAS/机器人FPS实时性多路并发能力需要确认多模型调度能力语音助手/实时对话Token/secdecodeprefill首token时延交互感取决于生成速度离线批量生成Token/sec吞吐能效比并发吞吐越大越好工业质检FPS吞吐精度保障要考虑误检漏检率4.2 第二步搭一套统一的测试基线确认场景需求后不要直接拿厂商的评测数据做决策建议自建一套统一测试基线。我个人的习惯是固定五件事。模型固定用自己业务里真实要跑的模型不要用厂商benchmark里面的常用模型。 输入固定同一张验证图片、同一个分辨率如果是文本模型用同一段prompt和相同的生成长度。 精度固定明确是FP16、INT8还是混合精度并确认模型量化方式一致。 框架固定尽量用同一套推理框架或者芯片原厂SDK但要记录清楚用了什么版本。 并发固定记录是单路还是多路并发batch是多少。测试时我会记录四个维度的数据单次时延毫秒数、换算出来的FPS、整卡吞吐量、整机功耗。功耗这步容易被忽略但对端侧设备来说至关重要一颗性能很强的芯片如果功耗压不住在电池供电的产品里根本无法发挥。功耗测试至少要连续跑30分钟以上看稳态功耗而不是瞬时峰值。4.3 第三步用真实负载压测别信峰值基线测试跑通了说明芯片理论能力没问题。但真正的考验是真实负载压测这一步能暴露大量问题。我在一个项目里遇到过这样的情况芯片跑公开的YOLOv5s模型表现相当好但切到我们自研的检测模型后帧率直接掉了60%。排查半天发现我们的模型里有一些自定义算子芯片对应的推理引擎没有高效实现只能回退到CPU计算速度自然一落千丈。压测时还要注意输入数据的多样性。模型对不同图片的处理速度不是完全一致的一张全黑图片和一张满是物体的图片计算量差距可能很大。我一般会准备连续1000帧接近真实业务的视频流作为测试样本看平均帧率、最低帧率、最高时延这三个数值。最低帧率比平均帧率更重要因为用户感知到的卡顿恰恰来自那些最慢的帧。最后就是长时间稳定性测试。芯片在持续负载下会因为温度上升而降频性能越来越差。我做7x24小时连续运行测试时见过标称45 TOPS的芯片在运行40分钟后实际吞吐降到峰值的六成。这种隐性缩水不跑长时间测试根本发现不了。5. 常见问题与避坑实录5.1 为什么TOPS很高实际跑起来却很“肉”这是选型最让人困惑的地方。标称算力和实际体验之间隔着三层东西软件栈成熟度、算子覆盖率、内存带宽是否匹配。软件栈是最大变量。同一颗芯片厂商官方SDK经过深度优化的算子可能性能极好但遇到算子库里没有的op要么回退到CPU要么用通用实现硬扛性能断崖式下跌。我实测过某颗标称15 TOPS的芯片跑一个含特殊上采样算子的模型时帧率从预期的30 FPS掉到6 FPS原因就是算子不支持。算子覆盖率可以在芯片选型阶段就让厂商提供把你们业务模型的算子列表发过去让对方逐个确认哪些是硬件加速的哪些是CPU回退的。这个表格比任何TOPS数字都更有参考价值。5.2 厂商报的Token/sec为什么我复现不出来Token/sec的复现难度比TOPS高得多因为影响它的变量太多了。模型版本差一个commit结果就不同prompt长度不同prefill和decode占比就不同量化方式不同速度差异也很明显。我踩过一个具体的坑芯片厂商给的评测模型是经过层融合优化的而我们自己按照标准方式导出的模型没有做同样的优化跑出来只有对方数据的七成。后来对比发现厂商在模型导出阶段做了算子融合和内存复用优化这些优化在我们的部署流程里默认是关闭的。另一类问题是测试条件不一致。厂商说“默认30 tokens/s”但没有说明是1个用户独占还是16个用户并发下的平均值。这两种场景的数字差别非常大。所以我都会要求对方提供完整的测试配置说明包括模型版本、量化方式、batch、并发数、输入输出长度缺一个参数这个数字只能参考不能采信。5.3 热降频参数表上看不见的性能杀手很多芯片的峰值性能只能维持很短时间芯片温度一上来主频就会往下掉性能同步缩水。这个现象在参数表里看不到只有在实际压测中才能暴露。我在测试一款无风扇设计边缘设备时发现刚上电时跑YOLOv5s能有28 FPS连续运行15分钟后降到21 FPS之后保持稳定。如果只看前几分钟的数据会误以为性能足够实际上它只能维持峰值性能很短的时间。所以无论测FPS还是Token/sec一律要跑“预热持续”两段式测试。先跑10分钟让芯片达到热平衡再记录正式数据。这时候的数值才是设备长期稳定运行时的真实水平。5.4 选型时一定要看的隐藏清单除了性能和功耗选型还有几个容易被忽略的项目我在一次项目里吃过亏之后每次都会把这几项列进需求文档工具链的完善程度是否支持PTQ/QAT量化、算子库的覆盖范围、多模型部署的能力、内存带宽和容量是否够用、以及最实际的——开发板和技术支持的响应速度。工具链不友好的芯片性能再强也难落地。有些芯片需要专用的模型转换工具如果支持列表里没有你的模型结构就意味着大量适配工作。有些芯片工具的报错信息非常模糊一个量化失败可能要排查两三天。多模型部署能力也要重点测。端侧AI场景很少只跑一个模型比如手机上是人脸检测加美颜加超分模型之间需要动态切换或者并发执行这会直接考验芯片的内存管理和调度能力。单模型跑得快的芯片多模型并发时可能直接内存溢出。写在最后的一点体会做了这么多年AI芯片选型和评测我的感受是纸面上的指标只是第一道筛选器真正决定项目成败的还是实测。现在我看任何芯片第一件事是问清楚三个口径——峰值TOPS用的是什么精度、FPS是在什么模型和分辨率下测的、Token/sec是几个并发下的数据然后自己拿业务模型跑一遍跑通了再谈其他。光看发布会和规格书就拍板选型的项目我见过太多后面需要付出成倍的代价去返工。如果你正在做类似的选择不妨也按这个流程过一遍至少能帮你避开大部分坑。