外行看 AI 芯片第一眼都会盯上宣传页那个最显眼的数字TOPS。厂商发布会一喊200 TOPS1000 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 单帧成本你的模型一次推理要算多少FPSFrames 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 一起算的总吞吐。比如一颗芯片用 batch1 跑一个模型得到 100 FPS但把 32 张图合成一个 batch 送进去单次推理耗时可能只增加到原来的 3 倍因此折合出来的等效吞吐可能高达 800 FPS 以上。厂商在实际宣传中经常选用 batch 模式下的吞吐数据因为数字更好看。评估芯片时一定要先明确你的使用场景。如果是视频结构化这类单流低延迟需求对应的就是 batch1 的 FPS如果是离线批量图片处理那看批量吞吐才合理。这两个场景下选型结论可能完全不同不提前对齐口径后面所有测试都白做。我们不妨用一个实际算例把几个概念串起来。假设我手上有一颗标称 20 TOPS 的芯片跑一个 30 GOPS 的检测模型理论帧率是 667 FPS。实测时发现算子库覆盖率一般有效利用率只有 35%那实际帧率约 233 FPS。这个数字更接近真实部署体验。所以在看厂商报告时永远要问一句这个 FPS 是在什么模型、什么精度、什么 batch 下测出来的影响变量对 FPS 的影响幅度备注模型复杂度每增加 1 倍 GOPS理论 FPS 减半模型越大算力需求越高数据精度INT8 通常比 FP16 快 1.5~2 倍取决于芯片对 INT8 的加速比Batch size增大 batch 通常提升总吞吐但会牺牲单流延迟算子覆盖非覆盖算子可能慢 5~10 倍最容易被忽略的变量输入分辨率分辨率影响特征图尺寸与 GOPS 几乎线性相关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的测试结果很可能是在 batch64、序列长度 2048 的条件下产生的把这个数字当作单用户体验来期待会导致严重误判。模型规模精度权重体积50GB/s 带宽的理论 decode 上限200GB/s 带宽的理论 decode 上限7BFP1614GB3.57 token/s14.29 token/s7BINT43.5GB14.29 token/s57.14 token/s13BFP1626GB1.92 token/s7.69 token/s70BINT435GB1.43 token/s5.71 token/s这个表格算的是单用户场景的硬上限。实测还要考虑算子效率、Attention 计算、缓存命中率等因素所以用户真正感知到的 token 数往往在这个数字的 60%~80% 左右。4. 怎么测才算数一套可落地的 AI 芯片评估流程4.1 测试前必须固定的一组变量做了这么多轮芯片评估我最深的体会是芯片本身的问题往往不大测试口径混乱才是选型翻车的最大原因。下面这几个变量是我在每次测试前都会强制自己先写进测试方案里的模型与版本同一个模型不同版本的算子实现差异很大测试前必须锁定 commit 版本不能用最新版这种模糊描述。输入尺寸视觉模型锁分辨率大模型锁 prompt 长度和生成长度这些都会直接影响结果。精度与量化方式是 FP16、INT8 还是 INT4量化后有没有做校准集这些必须记录在案。Batch 大小单流还是批量如果两个都测要分别报告。框架与推理后端PyTorch、TensorRT、厂商自研 runtime 的结果可以相差数倍。厂商自研 runtime 测出来的成绩通常最优但它也是你最终部署要用的所以测试必须和部署路径对齐不要拿 PyTorch 的刚编译结果去否定一个已经适配到位的芯片。4.2 三组核心测试模型、功耗、持续稳定性我会把测试拆成三个维度分别回答三个问题第一问这台芯片在我最核心的模型上能跑多快选 1~2 个和实际业务最接近的模型作为锚点模型分别测 batch1 的延迟和 batch 尽可能大的吞吐。记录下每一帧的耗时曲线别只看平均值要关注 P95 和 P99 延迟。在边缘端设备上延迟抖动直接决定系统是否可用。第二问达到这个速度需要付出多少功耗算力脱离功耗谈性能没有意义。很多高 TOPS 芯片飙性能时功耗会冲到几十瓦如果产品是电池供电根本撑不住。测试时要记录整板功耗计算性能功耗比FPS/W 或 token/s/W。我的经验是这个比值比绝对性能更能预测实际产品体验。一个 5W 功耗下跑 100 FPS 的芯片比一个 15W 功耗下跑 200 FPS 的芯片更适合绝大多数端侧产品。第三问持续运行会不会性能衰减把测试时间拉长到至少 30 分钟以上记录温度曲线和性能曲线。很多芯片在冷启动时能维持峰值频率运行几分钟后因为温度限制就降频性能可能掉 20%~40%。如果芯片用于长时间运行的视频分析或线上服务这个数字比冷启动峰值重要得多。4.3 看数据之前先对场景再看交叉验证测出来的数据怎么用第一步是对齐场景不是只看数字高低。如果你做的是安防领域的实时视频结构化核心指标就是 batch1 的 FPS 和功耗做自动驾驶多路摄像头并发处理能力比单路峰值更重要做端侧大模型助手要盯住 decode 阶段的单用户 token/s做云端批量推理才需要关注大 batch 下的总吞吐。第二步是交叉验证。如果条件允许用 MLPerf 等公开基准的结果和自测数据互相印证。公开基准至少能说明芯片在某类任务上的保底表现如果你自测的 Token/sec 或者 FPS 明显偏离公开结果优先怀疑自己的测试方法而不是直接怀疑芯片。我曾经因为没锁 CPU 频率导致自测结果比厂商数据低了 40%一度以为是工程样品有问题最后发现是测试机上跑了一个后台进程在抢占内存带宽。4.4 我也踩过的几个隐藏陷阱预热不足推理框架通常有初始化开销前几次推理会比稳定态慢不少。正式计时前先跑几十次热身才能拿到稳定数据。只测单帧单帧耗时看着是 5ms但连续推理时因为内存复用和调度限制实际吞吐可能只有理论值的一半。我习惯用连续跑 1000 帧中间不加等待的方式测真正稳态。忽略后处理AI 芯片通常只加速模型本身NMS、解码、前处理这些环节经常在 CPU 上执行。端到端 FPS 和模型 FPS 是两码事产品评估一定要以端到端为准。拿不同的量化标准对比有的芯片 INT8 是真正的 8bit 量化有的却是 INT8 权重配 FP16 激活实际效率差异不小。没有确认量化细节就横向比较结论没有参考价值。最后再说一点我自己的习惯。正式评估报告里我会固定用这样一张表来汇总数据避免被厂商或多或少的宣传话说晕场景锚点模型精度Batch实测指标整板功耗稳定态衰减结论端侧视觉YOLOv8s INT8INT81412 FPS6.8W5%推荐端侧大模型Qwen2-1.5B INT4INT4131 token/s5.2W3%待定云端批量自研检测模型 INT8INT8642300 FPS45W12%有条件推荐这套方法帮我在过去两年里筛掉过两台纸面数据漂亮、实际项目跑不动的开发板也帮我拦住过一次因为盲目相信高 TOPS 而差点选错芯片的方案。评估 AI 芯片说到底是拿你的真实模型、在真实场景下、跑真实数据并且用统一的尺子去量。TOPS 决定的是天花板的起点FPS 和 Token/sec 决定的才是你能不能交付产品。
外行看 AI 芯片第一眼都会盯上宣传页那个最显眼的数字TOPS。厂商发布会一喊200 TOPS1000 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 单帧成本你的模型一次推理要算多少FPSFrames 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 一起算的总吞吐。比如一颗芯片用 batch1 跑一个模型得到 100 FPS但把 32 张图合成一个 batch 送进去单次推理耗时可能只增加到原来的 3 倍因此折合出来的等效吞吐可能高达 800 FPS 以上。厂商在实际宣传中经常选用 batch 模式下的吞吐数据因为数字更好看。评估芯片时一定要先明确你的使用场景。如果是视频结构化这类单流低延迟需求对应的就是 batch1 的 FPS如果是离线批量图片处理那看批量吞吐才合理。这两个场景下选型结论可能完全不同不提前对齐口径后面所有测试都白做。我们不妨用一个实际算例把几个概念串起来。假设我手上有一颗标称 20 TOPS 的芯片跑一个 30 GOPS 的检测模型理论帧率是 667 FPS。实测时发现算子库覆盖率一般有效利用率只有 35%那实际帧率约 233 FPS。这个数字更接近真实部署体验。所以在看厂商报告时永远要问一句这个 FPS 是在什么模型、什么精度、什么 batch 下测出来的影响变量对 FPS 的影响幅度备注模型复杂度每增加 1 倍 GOPS理论 FPS 减半模型越大算力需求越高数据精度INT8 通常比 FP16 快 1.5~2 倍取决于芯片对 INT8 的加速比Batch size增大 batch 通常提升总吞吐但会牺牲单流延迟算子覆盖非覆盖算子可能慢 5~10 倍最容易被忽略的变量输入分辨率分辨率影响特征图尺寸与 GOPS 几乎线性相关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的测试结果很可能是在 batch64、序列长度 2048 的条件下产生的把这个数字当作单用户体验来期待会导致严重误判。模型规模精度权重体积50GB/s 带宽的理论 decode 上限200GB/s 带宽的理论 decode 上限7BFP1614GB3.57 token/s14.29 token/s7BINT43.5GB14.29 token/s57.14 token/s13BFP1626GB1.92 token/s7.69 token/s70BINT435GB1.43 token/s5.71 token/s这个表格算的是单用户场景的硬上限。实测还要考虑算子效率、Attention 计算、缓存命中率等因素所以用户真正感知到的 token 数往往在这个数字的 60%~80% 左右。4. 怎么测才算数一套可落地的 AI 芯片评估流程4.1 测试前必须固定的一组变量做了这么多轮芯片评估我最深的体会是芯片本身的问题往往不大测试口径混乱才是选型翻车的最大原因。下面这几个变量是我在每次测试前都会强制自己先写进测试方案里的模型与版本同一个模型不同版本的算子实现差异很大测试前必须锁定 commit 版本不能用最新版这种模糊描述。输入尺寸视觉模型锁分辨率大模型锁 prompt 长度和生成长度这些都会直接影响结果。精度与量化方式是 FP16、INT8 还是 INT4量化后有没有做校准集这些必须记录在案。Batch 大小单流还是批量如果两个都测要分别报告。框架与推理后端PyTorch、TensorRT、厂商自研 runtime 的结果可以相差数倍。厂商自研 runtime 测出来的成绩通常最优但它也是你最终部署要用的所以测试必须和部署路径对齐不要拿 PyTorch 的刚编译结果去否定一个已经适配到位的芯片。4.2 三组核心测试模型、功耗、持续稳定性我会把测试拆成三个维度分别回答三个问题第一问这台芯片在我最核心的模型上能跑多快选 1~2 个和实际业务最接近的模型作为锚点模型分别测 batch1 的延迟和 batch 尽可能大的吞吐。记录下每一帧的耗时曲线别只看平均值要关注 P95 和 P99 延迟。在边缘端设备上延迟抖动直接决定系统是否可用。第二问达到这个速度需要付出多少功耗算力脱离功耗谈性能没有意义。很多高 TOPS 芯片飙性能时功耗会冲到几十瓦如果产品是电池供电根本撑不住。测试时要记录整板功耗计算性能功耗比FPS/W 或 token/s/W。我的经验是这个比值比绝对性能更能预测实际产品体验。一个 5W 功耗下跑 100 FPS 的芯片比一个 15W 功耗下跑 200 FPS 的芯片更适合绝大多数端侧产品。第三问持续运行会不会性能衰减把测试时间拉长到至少 30 分钟以上记录温度曲线和性能曲线。很多芯片在冷启动时能维持峰值频率运行几分钟后因为温度限制就降频性能可能掉 20%~40%。如果芯片用于长时间运行的视频分析或线上服务这个数字比冷启动峰值重要得多。4.3 看数据之前先对场景再看交叉验证测出来的数据怎么用第一步是对齐场景不是只看数字高低。如果你做的是安防领域的实时视频结构化核心指标就是 batch1 的 FPS 和功耗做自动驾驶多路摄像头并发处理能力比单路峰值更重要做端侧大模型助手要盯住 decode 阶段的单用户 token/s做云端批量推理才需要关注大 batch 下的总吞吐。第二步是交叉验证。如果条件允许用 MLPerf 等公开基准的结果和自测数据互相印证。公开基准至少能说明芯片在某类任务上的保底表现如果你自测的 Token/sec 或者 FPS 明显偏离公开结果优先怀疑自己的测试方法而不是直接怀疑芯片。我曾经因为没锁 CPU 频率导致自测结果比厂商数据低了 40%一度以为是工程样品有问题最后发现是测试机上跑了一个后台进程在抢占内存带宽。4.4 我也踩过的几个隐藏陷阱预热不足推理框架通常有初始化开销前几次推理会比稳定态慢不少。正式计时前先跑几十次热身才能拿到稳定数据。只测单帧单帧耗时看着是 5ms但连续推理时因为内存复用和调度限制实际吞吐可能只有理论值的一半。我习惯用连续跑 1000 帧中间不加等待的方式测真正稳态。忽略后处理AI 芯片通常只加速模型本身NMS、解码、前处理这些环节经常在 CPU 上执行。端到端 FPS 和模型 FPS 是两码事产品评估一定要以端到端为准。拿不同的量化标准对比有的芯片 INT8 是真正的 8bit 量化有的却是 INT8 权重配 FP16 激活实际效率差异不小。没有确认量化细节就横向比较结论没有参考价值。最后再说一点我自己的习惯。正式评估报告里我会固定用这样一张表来汇总数据避免被厂商或多或少的宣传话说晕场景锚点模型精度Batch实测指标整板功耗稳定态衰减结论端侧视觉YOLOv8s INT8INT81412 FPS6.8W5%推荐端侧大模型Qwen2-1.5B INT4INT4131 token/s5.2W3%待定云端批量自研检测模型 INT8INT8642300 FPS45W12%有条件推荐这套方法帮我在过去两年里筛掉过两台纸面数据漂亮、实际项目跑不动的开发板也帮我拦住过一次因为盲目相信高 TOPS 而差点选错芯片的方案。评估 AI 芯片说到底是拿你的真实模型、在真实场景下、跑真实数据并且用统一的尺子去量。TOPS 决定的是天花板的起点FPS 和 Token/sec 决定的才是你能不能交付产品。
