企业官网建设流程全解析

拿到一张AI芯片规格表，最显眼的永远是那一串算力数字：几百TOPS、几十TFLOPS。但真把这些指标当成判断芯片好坏的唯一标准，十有八九会在实际部署时翻车。我见过不止一个团队，拿着纸面参数对比了三个月，最后买回来的板卡跑目标模型时性能连竞品一半都不到，原因就是只看了最亮的那几个数字，忽略了配套指标。这篇就专门聊聊AI芯片指标怎么看：哪些数字能信、哪些要打折扣、怎么做自己的实测验证，以及我从多次选型和部署里踩过的一些坑。适合正在选型、准备做硬件评测、或者被老板要求“对比一下两款AI芯片”的工程师朋友，看完可以直接套用到你自己的评估流程里。

1. 拆开看：AI芯片指标到底有哪些门类

1.1 算力指标：最显眼也最容易误读

AI芯片规格表上最常见的算力指标是TOPS和TFLOPS两条线。TOPS通常是整数运算的单位，代表每秒万亿次整数操作，常用于INT8量化的推理场景；TFLOPS代表每秒万亿次浮点运算，规则上分FP16、FP32、BF16等不同精度。很多只看大数字的人会忽略一个前提：精度不同，数值不能直接横向比。

举个最典型的例子。某款芯片标称INT8算力80 TOPS，另一款标称FP16算力40 TFLOPS。这两个指标恰好常见等价——因为多数芯片设计方案里，INT8的峰值算力大约是FP16的两倍，也就是说80 TOPS的INT8吞吐约等于40 TFLOPS的FP16吞吐。但如果有人拿着“80 TOPS > 40 TFLOPS”直接得出结论说前者更快，那就完全错位了。

更隐蔽的是稀疏算力。有些规格表会同时写“稠密算力”和“稀疏算力”，稀疏算力往往比稠密高一倍甚至更多。这个数字只有在模型权重本身就是稀疏结构、并且软件栈能真正把稀疏性转化为跳过零值计算时才能兑现。现实里大部分Transformer模型跑推理时，稀疏优化并没有想象中那么高的通用收益。所以看到标称数字特别高的时候，第一个反应应该是问：这是哪个精度、稠密还是稀疏、怎么算出来的。

另外也要留意“理论峰值”和“可持续性能”的区别。规格表上写的是时钟拉到最高、所有计算单元全部满负荷运行时的极限值。真实跑一个模型，内存搬运、算子调度、同步开销都会吃掉大量算力。理论峰值只是天花板，不是平均值。

1.2 存储与能效指标：容易被忽略的硬约束

比起算力，存储和功耗指标在规格表里的位置通常不那么显眼，但实际影响往往更大。存储指标至少要看三个：带宽、容量、层级结构。

带宽决定了数据搬运速度。AI计算本质上是一个反复“取数据—算—写回”的过程，算得再快，数据送不过来也白搭。容量则决定了模型能不能塞进单卡。这里有一个非常现实的判断：跑大模型时，如果模型权重加中间激活超过可用显存，就要做拆分、卸载或者量化，性能会受到很大影响。层级结构，比如片上缓存有多大、显存分几级，会影响小算子反复访问时的实际效率，这个参数规格表不一定写清楚，但实测时感受非常明显。

能效指标通常写成功率或TDP（热设计功耗），以及由此推出的能效比TOPS/W。这个指标在端侧场景尤其关键。手机、边缘盒子、机器人上用的AI芯片，能效比往往比绝对算力更重要，因为功耗上限决定了设备能用多久、散不散得热。云端场景则看整体功耗，机柜供电和散热成本最终会折算成部署成本。

把这三类指标放在一起看的逻辑，可以用一个码头比喻来理解：算力是装卸工人数量，带宽是传送带运送速度，容量是堆场面积，功耗是给码头开的电费账单。只雇一百个工人但传送带一分钟只能送十件货，效率照样上不去。AI芯片选型也是一样的道理。

2. 从纸面到实跑：算力指标的换算与折扣

2.1 理论峰值不是实际算力，先学会算利用率

很多评测报告里会出现一个词叫MFU（Model FLOPs Utilization，模型浮点利用率），直白说就是跑某个模型时，实际算力占理论峰值的百分比。这个指标非常重要，因为它把纸面算力拉回到了真实场景里。

计算公式不复杂：先统计模型一次完整前向或训练迭代需要多少FLOPs（浮点运算次数），再除以实测耗时，得到实际算力，最后除以芯片标称峰值算力，就得到利用率。

我经常用下面这段Python脚本做快速估算：

# 模型单次前向传播的理论FLOPs，通常由框架或论文提供 model_flops = 1.2e13 # 例如 12 TFLOPs batch_time_s = 0.4 # 实测单次推理耗时（秒） # 芯片标称FP16峰值算力 spec_peak = 250e12 # 例如 250 TFLOPS # 实测有效算力 measured_flops = model_flops / batch_time_s measured_tflops = measured_flops / 1e12 # 利用率 mfu = (measured_flops / spec_peak) * 100 print(f"实测有效算力: {measured_tflops:.1f} TFLOPS") print(f"利用率(MFU): {mfu:.1f}%")

这段代码的场景是一个标称250 TFLOPS FP16的芯片，跑一个单次前向理论计算量12 TFLOPs的模型，实测耗时0.4秒，算出来有效算力只有30 TFLOPS，利用率12%。这个结果很多人第一次看到会吓一跳：这么低？其实很正常。大模型推理的利用率普遍在10%~30%之间，能跑到40%以上已经说明软硬件适配做得相当好了。

利用率低不代表芯片差，它更多反映的是模型结构、框架实现和芯片特性之间的匹配程度。选型时不要只看峰值，要拿着自己真实要跑的模型去测利用率。别人芯片利用率高，很可能是别人模型刚好跟那块芯片“长”得比较配。

2.2 精度和算子差异，会让同颗芯片判若两“芯”

算力数字还会随精度变化。一颗芯片跑FP16和跑INT8，标称算力可以差一倍甚至更多。不同业务场景对精度的需求不同：训练阶段通常需要FP16、BF16甚至FP32，推理阶段很多模型可以用INT8量化，但量化的前提是精度损失在可接受范围内。

这里就涉及一个容易被忽视的问题：指标不只包括吞吐和延迟，也包括任务质量指标。比如图像超分、视频增强这类视觉任务，部署到AI芯片上做量化后，不能光看帧率，还要看输出图的质量。行业内常用PSNR和MS-SSIM这类客观指标来评价图像重建质量。MS-SSIM的正常范围通常在0到1之间，越接近1越好；一般来说0.95以上肉眼很难分辨差异，掉到0.90以下就会开始看到明显的细节模糊或纹理失真。跑在芯片上的量化版本如果比全精度版本掉了零点零几个MS-SSIM，属于可以接受的范围；如果掉得过多，那就算吞吐再高也不能上线。

另外，同代同规格的芯片，跑同一个算子，不同软件实现可能差出好几倍性能。规格表只告诉你芯片计算单元的理论能力，不会告诉你厂商的算子库对某个特定shape的矩阵乘优化到什么程度。这就是为什么业内常说“AI芯片买的是硬件+软件栈”，编译器、算子库、推理框架适配度，往往比硬件峰值更能决定真实体验。

2.3 实测算力的三个关键测量细节

测试算力不是插上卡跑个命令那么简单，有几个细节经常导致数据失真。

第一个是热机问题。芯片刚上电时频率和温度都不稳定，尤其是散热系统还没进入稳态的时候，跑出来的数据偏高或偏低都有可能。正确的做法是先跑几分钟负载让温度和功耗稳定，再开始计时测试。我见过有人拿着开机第一分钟的跑分数据直接写报告，结果就是同一颗芯片不同时间测出两套完全不同的“真实峰值”。

第二个是输入shape的影响。同一个模型，输入token长度从128变成2048，算力利用率可能差出三倍。因为推理时序列变长，访存和计算的比例会急剧变化。所以对比两颗芯片时，必须固定完全相同的模型版本、精度、输入尺寸和batch大小，否则对比没有意义。

第三个是功耗模式。很多加速卡有不同功耗档位或频率策略，跑分时默认跑最高档，实际部署时为了压功耗和温度可能跑低档。测的时候一定要记录当时的功耗和温度数据，否则一个数字没法解释为什么两个实验室跑出天差地别的结果。

3. 内存带宽与访存模型：大模型场景必须补的一课

3.1 用算术强度判断瓶颈在算力还是在搬数据

算力和带宽之间有一个经典工具叫Roofline模型，也就是屋顶模型。这个模型的思路很简单：把芯片能达到的实际性能画成一条随“算术强度”变化的曲线，算术强度低的时候性能受带宽限制，呈一条斜线；算术强度高到一定程度，性能受算力限制，变成平台。

算术强度的定义是：计算量除以访存量，单位是FLOPs/Byte。如果一个任务的平均算术强度很低，说明做计算之前要搬运大量数据，再强的算力也只能等着数据进场，这就是“访存受限”；反过来，如果算术强度很高，计算单元才是瓶颈，带宽闲着也没用。

Transformer模型在大模型推理时就是典型的访存受限场景。以解码阶段为例，生成每个token都要把整个模型的权重从内存里读一遍。按每个参数大约2次浮点计算来粗算，一个7B模型生成一个token所需的算术强度大概只有几十到几百FLOPs/Byte，远远低于现代AI芯片的平衡点。也就是说，在大模型生成任务上，大部分芯片不是被算力憋死的，而是被带宽堵死的。

这也能解释为什么大模型推理时，模型变小不如带宽变大立竿见影。很多厂商优化大模型推理时优先压缩KV Cache、做算子融合（把多次内存访问合并成一次），本质上都是在降低访存量，让算术强度往右移。

3.2 带宽不够时，算力再高也只能干等

规格表里的带宽数字，比如800GB/s或者1TB/s，看起来都挺大，但和算力需求放一起看才知道够不够。一个实用的粗算方法：用标称算力除以标称带宽，得到一个“平衡算术强度”。如果目标模型在这颗芯片上的算术强度低于这个平衡点，那就注定跑不满算力。

举个例子，某芯片INT8算力200 TOPS，内存带宽600GB/s，那么平衡点大约在333 FLOPs/Byte。很多CNN模型的卷积层算术强度轻松超过这个数，所以这类芯片跑CNN可以接近满算力；但跑大模型解码时算术强度只有几十，远低于平衡点，于是带宽成了天花板。

我做过一个实际对比：芯片A算力比芯片B高了30%，但带宽比B低了15%；跑同一个大模型生成任务时，A的吞吐反而比B低了20%。只看算力指标的话这是个反常识结果，但用带宽一算就完全解释得通。所以选型时一定要带着自己的模型去算一遍算术强度，别只看算力有多大。

3.3 实测怎么验证访存瓶颈

不用依赖复杂工具，有几种简单的现象可以直接判断是访存受限还是计算受限。

第一种是固定batch size逐步加大输入尺寸，观察吞吐变化。如果算力受限，输入变大时总吞吐通常会明显增长；如果是访存受限，总吞吐增长会缓慢甚至停滞，因为带宽已经被数据搬运占满了。

第二种是单独跑一个矩阵乘法测试，分别扫描不同的矩阵尺寸，把实测TFLOPS画出来。如果你发现不同尺寸下性能波动非常大，说明芯片对某些shape的内存访问模式不友好。

第三种更直接，用性能分析工具看显存或内存控制器利用率。这个需要设备软件栈支持，不一定所有芯片都开放。但只要有条件，看硬件计数器永远比猜来得准。大模型推理场景里，如果带宽利用率已经跑到90%以上而计算单元利用率只有20%，那瓶颈就非常清晰了。

4. 功耗、能效与场景化验收

4.1 功耗墙如何决定真实性能

规格表上的功耗数字最容易被忽略，但它才是长期运行的“命门”。AI芯片标称的频率和算力，通常是在一个理想散热环境下才能长期维持的。实际部署到服务器机箱、边缘盒子或者笔记本里，散热条件一差，芯片就会被功耗墙或温度墙压住，频率自动往下掉，跑分直线下滑。

我遇到过最典型的情况：两款芯片在开放平台上裸板测试时性能接近，但装进同一款整机后，一款能稳定满频跑满，另一款跑了五分钟就开始降频，性能掉了三成。原因就是后者峰值功耗高、散热没跟上。评测芯片时如果只测裸板，不考虑整机散热能力，实际部署的表现可以差出很远。

能效比是另一个容易被纸面掩盖的数字。同样跑一个模型，A芯片功耗180W，B芯片功耗120W，性能相近的情况下，B的能效优势在长时间部署中非常明显。尤其是边缘设备或者多卡集群，功耗直接影响电费和散热设计。建议把功耗列入必测项，测试时用功率计记录整机功耗，不要只看规格表上的TDP，因为TDP只是设计值，实际功耗和负载特征强相关。

4.2 按业务场景定制验收指标

AI芯片没有绝对好坏，只有适配不适配。判断一款芯片是否满足需求，需要从具体业务场景出发定义自己的验收指标。不同场景看重的指标差别很大。

LLM推理服务：重点关注首token延迟、Token生成吞吐（每秒输出Token数）、单卡可承载的最大并发数。这几个指标决定了线上服务的手感和成本。CV图像任务：重点关注端到端帧率、模型量化前后的质量分差，比如前面说的MS-SSIM和PSNR，不能只盯着FPS看。训练场景：重点关注矩阵乘法和通信的扩展效率，多卡互联带宽、同步开销远大于单卡算力本身。

我做验收评估时习惯准备一张表，把每个场景对应的指标写清楚：

这张表可以根据自己的业务替换，但原则不变：所有指标都要能拿真实数据和业务目标对上，而不是拿规格表上的营销数字直接写报告。

4.3 一套可复用的最小验收清单

根据多次评测经验，我给自己定了一套最小验收流程，任何芯片拿过来都先跑这五步：

第一步，确认环境。固定驱动版本、推理框架版本、算子库版本。换版本跑出来的数据没有对比意义，这个必须锁死。

第二步，跑标准基准测试。选一个有代表性的模型和输入尺寸，跑出吞吐和延迟基线。模型选自己业务最常用的那个，不要拿别人家现成的演示Demo，因为演示Demo往往经过针对性优化，和你的负载不是一回事。

第三步，扫带宽和算力两个极端负载。用一个访存密集任务测带宽有效性，用一个计算密集任务测算力有效性，这样能把芯片能力边界摸出来。

第四步，做场景模拟。按照你的真实业务负载，用相同的并发、批大小、序列长度跑一段时间，记录P99延迟、功耗、温度，观察稳定性。

第五步，记录并归档。把功耗读数、温度曲线、温度墙触发情况、测试时间和环境都写进报告。数据是给别人做决策用的，信息越完整越好。

这五步做完，基本能判断一块芯片在你业务里到底行不行。再高级的指标分析，最后也要落在这些实测数据上。

5. 避坑实录：我见过的指标误读现场

5.1 纸面数据翻车案例复盘

以前有一个选型项目，两款芯片纸面数据对比非常有趣：芯片X带宽是Y的两倍，算力只高了10%。团队很快得出结论，说X肯定更适合跑大模型，因为大模型访存受限。结果实测下来X只比Y快了15%左右，远低于带宽翻倍带来的预期提升。

排查后发现，问题出在软件栈上。X虽然带宽高，但某个推理框架在它上面没有启用合适的内存布局，很多数据搬运走了低效路径，带宽利用率只有五成；Y反而因为软件适配成熟，带宽利用率跑到了八成以上。这个案例给我留下的教训很深：硬件指标只是理论边界，软件适配决定能兑现多少。选型时必须把“软件栈成熟度”当成一个重要指标来评估，包括算子覆盖情况、框架集成难度、工具链完善程度、社区资料丰富度。

还有一次在端侧设备上，一款芯片标称能效比很漂亮，理论功耗很低。但实际上板后发现，跑起高清视频流AI增强任务时，因为CPU和NPU要频繁协同搬数据，整机功耗比芯片单独功耗高出不少，设备发热严重。这就是只看芯片TDP、忽略整机系统功耗导致的误判。

5.2 排查速查表

把常见问题和排查思路整理成了一张速查表，遇到性能不符合预期的情况可以直接对照：

另外一个经常被忽略的坑是多卡互联。很多评测只测单卡性能，但实际训练或多卡推理部署中，卡间通信效率影响巨大。卡间互联带宽、通信库是否适配，都必须纳入选型考量。单卡强不等于八卡强，这一点执行大规模训练时体会特别深。

5.3 选型时值得记住的一句话经验

说到底，AI芯片指标是决策的辅助工具，不是结论本身。每颗芯片都是算力、带宽、功耗、容量和软件生态之间的一次权衡取舍，根本没有“绝对最强”这回事。同样一颗芯片，跑在长序列大模型推理场景和短输入图像分类场景里，表现可以完全不同；拿着别人的评测报告不做实测，等于盲人摸象。

我自己的习惯是：任何新芯片上手，第一周只干一件事，把规格书上的关键数字和我自己业务模型的实际数字对照一遍，建立一张“纸面-实测”映射表。这张表做完，对芯片的脾性基本就有数了，后面再做算子适配和性能优化才有方向。

如果你现在正被一堆指标搞得头晕，那就记住一句话：指标是拿来缩小候选范围的，不是拿来拍板定论的。先圈两三个纸面参数最匹配的候选，再用自己的真实模型跑实测，用数据说话。这样选出来的芯片，大概率不会让你在实际部署的时候后悔。