企业官网建设流程全解析

我做了快十年的AI基础设施评估，说句实话，每次看到厂商PPT上那颗“顶配AI芯片”的TOPS数字被当成真理宣传，我都替买家捏把汗。TOPS、FPS、Token/sec这三个词，是当下衡量AI芯片真实性能绕不开的标尺，但也是被误解最深、被营销话术加工最多的三个词。如果你正准备选型、做算力规划，或者只是想搞清楚自己手里那张加速卡到底值不值，这篇内容应该能帮你把这三笔账算明白。

先说清楚一个核心观点：没有任何单一指标能回答“这颗AI芯片真实性能怎么样”，真正的答案藏在“用哪类模型、跑哪种并发、坚持多久不降频”这些更具体的问题里。我这篇文章不打算给你讲一堆抽象的架构图，而是把TOPS、FPS、Token/sec三个指标掰开揉碎，讲清楚它们各自能说明什么、不能说明什么，再给你一套我实测下来比较靠谱的评估流程和方法。不管是新手还是已经踩过坑的工程老手，都能在里面找到可以直接搬走的东西。

1. 先搞清楚你手里的指标到底在说什么

1.1 三个指标各管哪一段

在做AI芯片选型之前，我习惯先让团队把需求拆成三个问题：

• 这颗芯片的算力上限是多少？
• 跑真实模型时，每秒能处理多少张图或多少帧数据？
• 跑大语言模型这类生成式任务时，每秒能吐出多少个字？

对应的就是TOPS、FPS、Token/sec三个指标。它们管的是AI芯片工作的不同层面，你可以理解为一条生产线上的三个仪表盘：TOPS是发动机最大功率，FPS是实际装配线速度，Token/sec则是针对特定“文字加工流水线”的产出速度。

拿汽车来打比方，TOPS像是铭牌上的最大马力，FPS像是你在市区实际能跑到的平均车速，Token/sec则是这辆车在特定物流场景里，一小时能送多少个包裹。马力再大，路况不好或者车身太重，实际车速也会很难看。AI芯片也一样，TOPS再高，遇到内存带宽不够、算子不兼容、散热压不住，实际跑模型的FPS照样拉胯。

搞清楚这一点，你就能理解为什么我会反复提醒身边的人：别只看一个数字就做决定，三个指标要放在一起看，而且要放在自己的真实场景里看。

1.2 为什么“峰值TOPS”这么有欺骗性

TOPS是Tera Operations Per Second的缩写，代表每秒万亿次操作。厂商宣传的“峰值TOPS”，通常是指芯片在某个特定数据精度、特定算子组合、最理想频率下能跑到的理论最大值。

问题出在这个“理论最大值”离真实使用有多远。比如一颗号称200 TOPS的芯片，可能是在INT8精度下测出来的，你如果跑的是FP16模型，数字直接打对折；如果跑的是INT4量化模型，有些芯片反而会跑得更高。更微妙的是，TOPS的计算方式和硬件架构强相关：有些芯片擅长矩阵乘加这类算子，因为计算单元全堆在这上面，跑卷积、跑Transformer都很快，但一旦遇到大量的非矩阵运算，比如动态Shape、复杂控制流、大量向量运算，峰值TOPS就撑不住了。

我在测试中就经常看到这样的现象：一颗算力数字非常好看的芯片，在跑某个关键视觉模型时，FPS反而输给了算力数字只有它一半的对手。原因就是对手的算子库对那个模型优化得更好，内存调度更合理。

所以，TOPS不是没用，它是衡量芯片理论容量的重要参考，尤其在做硬算力对比时很有价值。但不能把它当成真实性能，更不能拿它直接推算你的业务能跑多快。想要看清真实性能，就必须引入FPS和Token/sec。

2. TOPS：看起来最直观，其实最容易被忽悠

2.1 TOPS是怎么算出来的

TOPS的计算公式并不复杂：TOPS = 计算单元数量 × 每个单元每个时钟周期的操作数 × 核心频率 ÷ 10^12。

举个例子，假设一颗AI芯片有128个AI核心，每个核心每个周期能完成1024次乘加操作。这里的1024次乘加，在厂商口径里通常算作2048次操作，因为乘和加各算一次。如果核心频率是1.5GHz，也就是每秒15亿周期，那理论算力就是：

128 × 2048 × 1.5 × 10^9 = 393.216 × 10^12，约等于393 TOPS。

这个数字看起来很高，但注意几个藏在话术里的坑。

第一个坑是“操作数”的定义。有的厂商会把一次乘加算成一次操作，有的算成两次，导致同一颗芯片在宣传上有两个完全不同的TOPS数字。跨厂商对比时，如果不确认口径，就是拿苹果和橘子比。

第二个坑是频率。芯片标称频率是最高Boost频率，实际长时间满载运行时，因为功耗和散热限制，频率往往会往下掉。我之前测过一颗芯片，宣称频率1.8GHz，持续跑AI负载五分钟后掉到1.4GHz，算力直接缩水两成以上。

第三个坑是稀疏度。有些芯片支持稀疏计算，宣传的TOPS是基于激活值和权重有50%以上为零的假设。真实模型里，稀疏度根本达不到理想水平，所以实际收益远低于预期。厂商没有骗你，但也没把真实前提讲全。

2.2 实际能跑到几成，取决于数据精度

同样一颗芯片，在不同数据精度下的TOPS差异大到我经常建议客户先列一张精度对照表。通常同一块推理卡上，INT8的TOPS是FP16的两倍，而FP16又是FP32的两倍，甚至更多。

具体跑哪个精度，需要综合模型精度损失和硬件支持情况来权衡。很多边缘设备上的视觉模型，用INT8量化后精度损失很小，但推理速度能提升一到两倍，这就是划算的；但如果模型是训练好的大语言模型，直接压到INT8可能会导致输出质量明显下降，这时候就需要谨慎。

我见过一个典型案例：有团队为了追求高TOPS，把所有模型都强行量化到INT8，结果发现某个关键检测任务的精度爆降，最终返回去用FP16，FPS反而不如一开始就用INT8裁剪模型结构的方案。你看，TOPS是高了，但真实业务表现并没有提升。所以，正确的做法是：先确认你能接受的部署精度，再去看这个精度下的TOPS，而不是被“理论峰值TOPS”牵着走。

2.3 怎么用TOPS做横向对比

既然TOPS容易被误导，那怎么用它做横向对比才靠谱？我的经验是三步走。

第一步，统一口径。对比前先确认所有芯片是不是都在同样的精度(比如都是INT8)、同样的稀疏度假设(都按稠密计算)下得到的数据。如果厂商没标，直接发邮件问，问不到就默认按最保守的稠密计算来算。

第二步，除以功耗，看能效。同样的TOPS，A卡只有25W功耗，B卡要150W，在边缘场景里高下立判。能效比（TOPS/W）在电池供电、散热受限的设备里往往比绝对TOPS更重要。

第三步，结合FPS一起看。如果资金和人力允许，直接把你要用的模型在两个平台上跑一遍，拿实际FPS除以标称TOPS，算一算这个平台“每TOPS能换多少真实帧率”。这个比值越高，说明芯片的架构、编译器和算子库配合得越好。我自己的经验是，不同芯片的这个比值差距能有两三倍，很多标称TOPS不高的芯片恰恰在这个维度上胜出。

3. FPS：把“能不能跑”变成“跑多快”

3.1 FPS测试里的隐藏变量

FPS（Frames Per Second）原本是衡量视频或游戏画面的帧率，放在AI芯片评测里，指的是每秒能处理多少帧图像样本。听上去很简单，就是拿一个数据集、一个模型，跑出“每秒钟过多少张图”嘛。但实际测试里，变量多到能让人抓狂。

我总结下来，最大的四个变量是batch size、输入分辨率、精度、是否开延迟优化。

batch size的影响最容易被忽视。很多芯片在batch size从1调到4、8之后，吞吐量会大幅上升，但单帧延迟也在涨。如果你做的是实时视频分析，就只能用小batch甚至batch size=1；如果你做的是离线批量处理，用大batch才能榨干芯片性能。所以对比FPS时，必须写明batch size，否则数字毫无意义。

输入分辨率是另一个容易被偷换的概念。一个模型在640x640下的FPS，和在1280x1280下是完全两回事，后者计算量是前者的四倍。有的厂商会拿小分辨率跑出一个亮眼的FPS数字，但真实场景根本不会用这么小的图。

精度前文已经说过，INT8的FPS经常能比FP16高一倍。开延迟优化则是个双刃剑：开了之后吞吐量确实好看，但每次推理的延迟可能不稳定，对实时交互业务有潜在风险。

3.2 一个跑通FPS测试的完整流程

我在这里给出一套我常用的测试流程，可复现性很高，你可以直接拿去用。

环境准备阶段，先把芯片驱动和深度学习框架装好，尽量用官方推荐的组合。硬件模式设为性能模式，关闭屏幕节能、CPU自动降频等干扰项。然后固定一个基准模型，比如先用ResNet50作为初始对照，再补一个和你业务密切相关的模型。

数据集选型，我一般先用公开的ImageNet验证集的一个子集，比如1000张图，量不大但比较接近真实分布。如果你要测试的业务模型和通用视觉模型差异大，那就一定要换成自己的数据集，哪怕只有几百张，也要包含自己业务里最差、最难的样本。

测试脚本的核心逻辑，是先做热身跑，让芯片进入稳定状态，再开始计时。我习惯跑三次，每次跑完记录平均延迟和FPS，计算方差。如果三次结果波动超过5%，说明系统不稳定，需要重新检查散热和频率设置。

有一个细节我吃了不少亏：千万不能只记录总时间然后除以总样本数。因为推理引擎内部有预处理、后处理和动态Shape调整，这些非计算时间也占用硬件。正确做法是只对模型推理部分计时，或者至少把预处理和后处理单独统计出来，否则你测出来的FPS是“整个pipeline的速度”，不是“芯片的速度”。如果目的就是为了评估整个系统，那没问题；但如果你想横向对比芯片本身，就必须把外围开销剥干净。

3.3 游戏圈FPS的类比，帮你理解AI FPS

说个能帮你快速理解的事。最近很多玩射击游戏的朋友都在研究怎么把CS2界面左上角的FPS、GPU、CPU参数调掉，专心练枪法，还有一些人在找“FPS练枪网页版”，想通过小球追踪、反应射击这些小游戏来提升瞄准手感。这些游戏里的FPS概念，其实就是“画面每秒刷新次数”，数值越高，操作越跟手，感受越丝滑。

但AI芯片的FPS和游戏FPS有个本质区别：游戏里FPS是给画面渲染用的，直接决定人眼看到的流畅度，低于60就能感觉到卡顿；AI芯片的FPS是给模型推理用的，决定的是“每秒能处理多少输入样本”。你在练枪网站上用手腕甩枪调整准星，来来回回找手感，本质上就是在不断逼近自己的“响应极限”；AI芯片测FPS时，其实也是在整个系统层面找那个“稳定输出极限”。

我拿这个类比出来说，是为了提醒一件事：FPS低，不一定是芯片不行。游戏里FPS上不去还能看看CPU/GPU占用率、散热降频、后台进程；AI芯片FPS上不去，也得从模型结构、框架算子、内存带宽、数据加载等一堆环节里找原因。只看数字就下结论，很容易误伤一颗好芯片。

4. Token/sec：大模型时代最该盯住的数字

4.1 Token/sec到底在测什么

随着大语言模型成为主流应用，Token/sec这个指标变得越来越关键。它表示模型每秒能生成多少个Token。所谓Token，你可以粗略理解为词或子词的片段，一个中文词语可能就是一个Token，一个英文单词可能是两个Token。

如果你是做聊天机器人、AI写作、代码助手这类应用的，Token/sec直接决定了用户体感：生成速度太慢，用户等得不耐烦；生成速度快，对话体验会自然很多。我测试过很多设备，低端芯片每秒只能吐几个Token，阅读体验极差；而桌面级AI芯片或高端服务器显卡能到几十甚至上百Token/sec，感觉就完全不一样了。

这里要注意，Token/sec和FPS不同。FPS通常测的是“首帧延迟+后续吞吐”，而Token/sec在生成任务里更复杂，因为它有prefill（处理输入提示词）和decode（逐个生成Token）两个阶段。我在做评测时，会把prefill耗时和decode吞吐分开统计，因为首Token时间（TTFT）和生成速度是两种完全不同的体验指标：前者影响“点完发送要等多久才开始回复”，后者影响“开始回复之后字蹦得快不快”。

4.2 并发数上涨，Token/sec如何变化

做后端服务的人都有一个常识：单用户Token/sec跑得很快，不代表多用户并发时依然很快。我自己踩过这个坑。早期评估一块加速卡时，单用户测试结果非常漂亮，每秒能生成45个Token，我心里觉得稳了。结果接入线上环境，同时有8个用户在用，整卡总吞吐倒是上来了，但每个用户的Token/sec直接掉到不足原来的四分之一，体验完全崩了。

原因在于，大模型解码阶段是显存带宽密集型任务，多个请求并发时会争抢同一个带宽资源。芯片表面的算力再高，如果内存带宽不够，并发一上来就露馅。所以我在选型评估时，一定会做并发压力测试，至少要测1路、4路、8路、16路并发下的“用户平均Token/sec”和“整卡总Token/sec”，画一条曲线出来看拐点。

如果预算有限，没法测太多路并发的设备，我都建议直接按“每用户最低可接受Token/sec × 预估最大并发数”来反推需要的总吞吐量，然后找测评数据里在对应并发规模下还达标的芯片。

4.3 内存带宽才是隐藏瓶颈

聊Token/sec，绕不开一个指标：内存带宽。大模型的权重动辄几个GB到几十个GB，推理时每生成一个Token，都要把全部权重从头到尾扫一遍。所以生成Token的总量，几乎和内存带宽成正比。

我用过一个很直观的经验公式：理论上限 Token/sec ≈ 模型内存占用 × 2 ÷ 内存带宽。为什么乘以2，因为计算过程通常需要同时读取权重和激活值，实际读取量约等于权重的两倍。举个例子，一个7B模型在半精度下占地约14GB，如果你的芯片内存带宽是200GB/s，那理论上限大约就是200÷(14×2)≈7.14 Token/sec。

注意是“理论上限”，实际能跑到这个数字的六到七成就算优化得不错了。这也是为什么很多标称TOPS很高的芯片，跑大模型反而不如TOPS略低但内存带宽高出一截的芯片。看规格表时，除了算力，一定要盯紧DRAM带宽、L2 Cache容量这些参数，它们在Token/sec这个维度上的决定作用超乎想象。

5. 实操过程：把三张表拉到一起看

5.1 我需要一套可复现的测评流程

上面三个指标分开讲了原理，现在聊聊怎么把它们组合起来用。我自己的经验是，不要迷信任何一家评测机构给出的单一数字，最好能根据自己业务搭一套最小可复现的测评流程。这套流程不需要很复杂，但必须覆盖三个层面：硬件规格层面的TOPS、系统吞吐层面的FPS、应用体验层面的Token/sec。

我最近帮一个做边缘巡检设备的团队做选型，他们主要跑两个模型：一个是1280分辨率的工业缺陷检测模型，一个是7B参数的大语言模型用于自动生成缺陷描述。我只用了半天时间，就搭了一套同时覆盖三个指标的测试方案。

第一步，从规格表里把候选芯片的INT8理论TOPS、内存带宽、功耗整理成一张表。第二步，在每块卡上跑同一个检测模型，测FPS，记录稳定后的数值。第三步，在同一块卡上跑7B模型，测单用户和4路并发的Token/sec。三步走完，三张表放在一起，选型结论基本就很清晰了。

5.2 五分钟搭一个评估脚本

这里分享一个能用尽量少的代码跑通全流程的评估脚本套路，框架用PyTorch或ONNXRuntime都行，关键是把计时和多轮测试固化下来。

核心逻辑分四块：

• 固定随机种子，加载统一模型和数据集；
• 热身阶段跑10次推理，不记录结果，让芯片频率和缓存进入稳定状态；
• 正式测试跑3轮，每轮100次，记录每轮平均FPS；
• 输出结果到CSV，附上batch size、精度、输入分辨率等环境参数。

跑大模型Token/sec时，我会再加一段生成逻辑，固定输入提示词长度，比如256个Token，然后让模型连续生成一段固定长度，比如512个Token的输出，记录总耗时，减去首Token时间，再算后续的decode速度。

一个很重要的思路：脚本越简单越好，重点是每次跑测试时只改一个变量。如果你同时改了batch size和分辨率，测出来FPS变了，你根本说不清楚是哪个因素造成的。

5.3 一张图看懂结果怎么解读

跑完三个指标后，我的习惯是把结果画成一张“需求-指标”对应图。横轴是业务场景，纵轴是优先级权重。

给你举个例子：

制表完之后，再回到原始测评数据里，看看每颗芯片在对应场景下的实际表现是否满足业务底线。如果满足，才进入下一步的小批量采购验证。这套方法帮我在过去一年里避开了至少三次“看起来很强、买回来吃灰”的选型失误。

6. 常见问题与排查技巧实录

6.1 为什么跑出来比宣传低一半

这个问题我一年要被问八百遍。后来我总结出三个排查方向，基本能解决九成以上的困惑。

第一查降频。用监控工具盯着芯片频率，看是不是满载几分钟后频率往下掉。如果掉，优先解决散热和功耗墙设置。很多开发者拿开发板裸跑，没有主动散热，频率一降再降，性能自然腰斩。

第二查精度匹配。确认模型实际跑的精度，和厂商宣传TOPS时用的精度是不是一回事。经常有同学用FP32模型去测试，而芯片宣传的是INT8 TOPS，差距自然巨大。

第三查算子是否走加速单元。如果模型里某些算子不支持芯片的加速库，推理引擎会自动回退到CPU或通用GPU内核去算，性能立马崩。这时候要用profiler工具把每一层的耗时列出来，找出那几个耗时异常高的算子，要么换算子实现，要么改模型结构绕过去。

6.2 同一颗芯片，不同框架结果差很远

这一点说出来可能有些人不信，但真实测试里非常常见。同一颗芯片，用TensorRT、ONNXRuntime、PyTorch各自部署同一个模型，跑出来的FPS差距能到两倍以上。原因很简单，各家框架对模型算子的融合程度、内存复用优化、图优化策略都不一样。

所以，我的建议是：不要用自己最熟的框架，而是要选择对该芯片优化最好的框架。通常芯片厂商会给出官方推荐的推理框架，甚至配套专门的加速库。哪怕那个框架用起来别扭一些，性能收益也值得你去适应。

另外一点，框架版本也极其关键。同一个框架，升一个版本，算子兼容性可能大幅改善，FPS也跟着提升。测性能前，先把框架和加速库升级到稳定发布的最新版，再开始对比。

6.3 排查资源利用率的三板斧

如果一切设置看起来都对，但实测FPS或Token/sec还是上不去，我习惯用三板斧来定位问题。

第一板斧，看利用率。用芯片厂商自带的监控工具查看AI核心利用率是多少。如果利用率只有30%，说明模型并发度不够，batch size太小，或者算子并行度不足。

第二板斧，看带宽。大模型任务尤其要看内存带宽利用率。如果已经跑到八成以上，说明瓶颈在带宽不在算力，这时候堆TOPS没用，要么换带宽更高的芯片，要么把模型量化、剪枝，降低每次读取的权重体积。

第三板斧，看流水线。数据处理和推理是否重叠？很多慢的问题，都出在CPU端数据加载管得慢，芯片在等数据，而不是在算数。用异步数据加载，把预处理放到另一条线程上去做，通常能改善不少。

总得来说，这三个指标没有一个能单独回答“芯片真实性能如何”的问题。我做评估工作这么久，最大的心得就是：把TOPS、FPS、Token/sec放在一起看，结合自己的真实模型和真实并发场景去测，才能摸到一颗芯片的底。别再被PPT上单独挑出来的漂亮数字带跑了，数据不会骗人，前提是你会测、会看、会拆。