AI芯片选型：从TOPS峰值到真实负载的评估方法

1. 算力数字的信任危机为什么TOPS开始不够用了如果你最近一年跟做AI芯片或推理部署的人聊过大概率会听到一个共同的抱怨标称算力越来越漂亮实际跑起来却越来越让人心里没底。一颗芯片写着几百TOPS的INT8算力纸面参数能把上一代产品甩开好几条街但真把业务模型搬上去吞吐量可能只比老产品高个百分之二三十延迟甚至偶尔还会倒退。这种落差不是个例而是整个行业正在经历的一次评判标准迁移。TOPS全称是每秒万亿次操作本质上是一个理论峰值指标。它的计算方式很朴素芯片里有多少个乘加单元每个单元每个时钟周期能做多少次乘加再乘以主频最后除以一万亿。这个公式本身没问题问题在于它描述的是一个理想状态——所有计算单元永远满载、数据永远及时到位、没有任何等待和空转。可真实的AI负载根本不是这样运转的。我拿一个具体的场景来说明。假设你部署的是一个目标检测模型输入分辨率是1080p模型里有大量的卷积层、少量的全连接层还有几个需要做非极大值抑制的后处理步骤。在纸面上卷积部分确实能吃满算力但卷积和卷积之间需要把特征图写回内存再读出来后处理阶段更是几乎用不到矩阵计算单元。这些环节里芯片的乘加阵列要么在等数据要么干脆闲着。标称的几百TOPS在这种负载下能发挥出三成就算不错了。更麻烦的是不同厂商对TOPS的统计口径并不统一。有的按稀疏化之后的等效算力标有的按INT8标但实际业务跑的是INT4或者FP16还有的把不同精度下的算力混在一起宣传。这就导致一个很尴尬的局面你拿着两张标称算力相近的卡去做选型实测下来差距可能大到让你怀疑是不是自己测错了。我见过一个团队选型时按TOPS排了个序结果实测发现排第一的那颗芯片在自家模型上跑不过排第三的原因就是排第一的那颗芯片内存带宽成了瓶颈算力根本喂不饱。所以现在业内越来越多人开始说一句话TOPS是给投资人看的真实负载才是给工程师看的。这句话虽然有点绝对但它点出了核心矛盾——算力峰值和实际有效算力之间隔着一整套系统级的工程问题。这些问题包括内存带宽够不够、片上缓存怎么调度、算子库对模型结构的适配程度、多卡互联的通信开销甚至包括驱动和编译器的成熟度。任何一个环节掉链子标称算力都只是墙上的奖状。那为什么这个标准迁移偏偏发生在现在因为前几年AI芯片还处在“有没有”的阶段大家先解决算力从无到有的问题标称指标粗糙一点也能忍。但现在行业进入了“好不好用”的阶段业务方开始算投入产出比开始关心每瓦性能、每美元吞吐、部署周期和运维成本。这时候再拿一个理想状态下的峰值数字去说服人已经不好使了。评判标准从峰值算力转向真实负载表现本质上是从实验室思维转向产品思维。2. 真实负载到底在考验芯片的哪些能力2.1 内存带宽与计算单元的比例关系真实负载第一个要过的关就是内存墙。你可以把计算单元想象成一个超级能吃的胃内存带宽就是食道。胃再大食道太细进食速度就上不去。AI负载里大量的操作是访存密集型的比如逐元素加法、归一化、激活函数这些操作的计算量很小但需要把数据从内存搬进搬出。如果芯片的算力/带宽比失衡这些操作就会成为整个流水线的堵点。一个粗略的经验法则是对于主流的视觉类模型每1TOPS算力大致需要配比4到8GB/s的内存带宽才能让计算单元保持较高利用率。对于Transformer类的大模型这个比例还要更高因为注意力机制里的键值缓存会带来大量随机访存。你在选型时如果只盯着TOPS看很容易忽略这个比例结果就是买回来一颗算力很强但带宽不足的芯片跑什么模型都差一口气。2.2 算子库对模型结构的覆盖度第二个考验是算子库。芯片厂商提供的算子库不可能覆盖所有模型里用到的所有算子总有一些冷门操作需要自己写或者等厂商更新。问题在于一个模型里哪怕只有一个算子没有被高效实现整个模型的性能就可能被拖垮。我遇到过最极端的情况是一个模型里有个自定义的池化操作厂商库里没有对应实现编译器只能回退到CPU上跑结果这一个算子占了整个推理时间的四成。所以现在有经验的团队在做芯片评估时会先把自己要部署的模型拆成算子列表然后逐个去查厂商的算子库支持情况重点看那些非标准算子、融合算子和动态形状算子。这个工作很琐碎但能帮你避开很多坑。有些厂商会提供算子覆盖度报告但你要注意看报告里的“支持”是什么含义——是原生高效支持还是通过组合算子拼出来的还是回退到通用计算单元。这三种情况的性能差距可能是数量级的。2.3 批处理与并发场景下的调度效率第三个考验是调度。真实业务很少一次只处理一条数据通常要做批处理来提高吞吐或者要同时处理多个请求来降低延迟。这时候芯片的调度能力就很重要了。有些芯片在单批单请求下表现很好但一批量上去性能不升反降因为片上缓存不够用批与批之间互相抢资源。还有些芯片在多模型并发时调度混乱导致延迟抖动很大这对在线服务来说是致命的。评估调度效率的一个实用方法是做阶梯式压测从batch size等于1开始逐步增加到2、4、8、16观察吞吐量和延迟的变化曲线。理想的曲线是吞吐量随batch size近似线性增长延迟增长平缓。如果吞吐量很快到顶甚至下降或者延迟急剧上升说明调度或缓存存在瓶颈。这个测试不需要很复杂的工具用厂商提供的推理框架加上一个简单的压测脚本就能做。2.4 精度与量化策略的实际表现第四个考验是精度。现在几乎所有的推理部署都会用量化来降低计算量和内存占用常见的是INT8量化更激进的会用到INT4。但量化不是免费的午餐它可能带来精度损失而且不同芯片对量化的支持程度差异很大。有的芯片对INT8的支持很成熟量化后的精度损失可以控制在可接受范围内有的芯片INT8算子实现粗糙量化后精度掉得厉害你不得不回退到FP16算力优势就没了。评估量化表现不能只看厂商给的精度报告因为那些报告通常是在标准数据集上测的跟你的业务数据分布可能差很远。正确的做法是拿你自己的校准数据集去做量化然后在你的验证集上看精度变化。同时要关注量化后的性能提升是否达到预期——有些芯片量化后算力翻倍但实际推理速度只快了百分之十几因为瓶颈在访存而不是计算。3. 从纸面参数到实测数据一套可复用的评估方法3.1 先明确业务场景的硬约束在开始任何测试之前先要把业务场景的硬约束列清楚。这些约束包括延迟上限是多少毫秒吞吐量最低要求是多少精度底线在哪里功耗和散热预算是多少部署环境是数据中心还是边缘设备。这些约束决定了你评估芯片时的侧重点。比如在线推荐场景对延迟极其敏感那你就不能只看吞吐量边缘设备对功耗敏感那每瓦性能就是核心指标。我习惯把这些约束写成一个表格每项指标标注是“硬性门槛”还是“优化目标”。硬性门槛是必须满足的不满足直接淘汰优化目标是在满足门槛的前提下尽量做好的。这样在后续测试中就不会被某个单项的漂亮数字带偏始终围绕业务需求做判断。3.2 构建贴近真实的测试负载测试负载的构建是评估中最关键也最容易被敷衍的环节。很多团队直接拿厂商提供的基准测试脚本跑一遍就完事了但那些脚本通常是为了展示芯片优势而设计的跟你的真实业务负载可能相差甚远。正确的做法是从你的业务里抽取一个有代表性的模型最好就是准备上线的那一个然后用真实的数据分布去做推理测试。如果业务里有多个模型那就选一个主力模型加一两个典型辅助模型组成一个测试集。测试数据不要用随机生成的要用真实业务数据或者至少是分布接近的模拟数据。输入形状也要覆盖实际可能出现的各种情况包括最小尺寸、最大尺寸和典型尺寸。这些准备工作看起来繁琐但能让你拿到的数据真正有参考价值。3.3 关键指标的测量与记录方式测量环节有几个细节容易出错。第一是预热芯片在冷启动和热稳定状态下的性能可能有明显差异测试前要让芯片跑一段时间达到热稳定。第二是多次测量取统计值不要只跑一次就下结论至少跑十次取中位数和百分位值。第三是记录完整的延迟分布不要只看平均延迟P99延迟往往更能反映用户体验。我通常会记录这样一组指标不同batch size下的吞吐量、平均延迟、P50延迟、P99延迟、功耗、芯片利用率、内存带宽利用率。这些指标要同步记录因为单独看任何一个都可能产生误判。比如吞吐量很高但P99延迟也很高说明调度不够稳定芯片利用率很低但吞吐量达标说明还有优化空间。3.4 横向对比时的公平性原则如果你要对比多颗芯片公平性是个大问题。首先软件栈要尽量对齐用各自厂商推荐的推理框架和最优配置不要一颗芯片用精心调优的配置另一颗用默认配置。其次测试环境要一致包括散热条件、电源质量、宿主机的其他负载。第三是测试脚本要相同输入数据要相同测量方法要相同。还有一点容易被忽略要给每颗芯片足够的调优时间。有些芯片上手快默认配置就能跑出不错的结果有些芯片需要仔细调优才能发挥实力。如果你给每颗芯片的时间不一样对比结果就不可信。我的做法是给每颗芯片设定一个固定的调优预算比如两天时间在这两天里尽量把它调到最好状态然后在这个状态下做对比。4. 那些标称参数不会告诉你的坑4.1 峰值算力的“含水量”从哪里来标称算力的含水量主要来自三个地方。第一个是稀疏化很多芯片会标一个稀疏算力通常是稠密算力的两倍但稀疏化需要模型本身有足够的稀疏性才能利用而大多数业务模型并没有那么稀疏。第二个是精度混标比如用INT4的算力去对标竞品INT8的算力数字上好看很多但INT4在实际业务中的可用性还有限。第三个是理想频率标称算力是按最高睿频算的但实际持续运行时芯片会降频真实算力可能只有标称的七八成。你在看厂商资料时要特别留意算力数字后面跟着的小字注释。如果写着“稀疏”“峰值”“理论”这些词就要在心里打个折扣。更靠谱的做法是直接问厂商要稠密算力、持续算力和实际业务场景下的实测数据。如果厂商支支吾吾拿不出来那这个数字的水分可能不小。4.2 编译器成熟度对开发效率的隐性影响编译器成熟度是个隐性但极其重要的因素。一个成熟的编译器能把你的模型高效地映射到芯片上自动做算子融合、内存复用、流水线调度。一个不成熟的编译器则可能生成一堆低效代码让你不得不手工优化开发周期成倍增加。我见过一个团队选了一颗纸面参数很漂亮的芯片结果编译器对动态形状支持很差模型里所有动态维度都得改成静态的改完精度还掉了最后项目延期了好几个月。评估编译器成熟度的一个方法是看它对主流框架的支持程度和更新频率。如果厂商能及时跟进主流框架的新版本说明编译器团队在持续投入。另一个方法是拿一个结构稍微复杂一点的模型去编译看编译时间、生成的代码质量和是否报错。如果编译一个标准模型都磕磕绊绊那后续的开发体验可想而知。4.3 多卡扩展时的通信开销陷阱多卡扩展是另一个容易踩坑的地方。单卡性能好不代表多卡扩展效率高卡间通信的开销可能吃掉大部分算力增益。有些芯片的互联带宽不足多卡跑起来后通信成了瓶颈加卡带来的吞吐提升远低于预期。还有些芯片的多卡编程模型不成熟需要开发者手动管理通信和同步开发难度大且容易出错。评估多卡扩展效率的方法是做扩展性测试从单卡开始逐步增加到2卡、4卡、8卡观察吞吐量的增长曲线。理想的曲线是接近线性的如果增长很快放缓甚至下降说明通信或调度存在瓶颈。这个测试要在真实的模型和batch size下做因为不同模型对通信的需求差异很大。4.4 长期运行下的稳定性与降频问题长期运行稳定性是业务部署的底线但恰恰是很多评估容易忽略的。实验室里跑几分钟的性能数据跟数据中心里跑几个月的表现可能完全不同。芯片在持续高负载下会不会降频驱动会不会偶发崩溃内存会不会泄漏这些都需要在评估阶段就纳入考察。我的做法是在评估后期安排一个长稳测试让芯片在典型负载下连续跑至少24小时期间记录性能曲线、功耗曲线和错误日志。如果性能随时间明显下降或者出现任何非预期错误都要搞清楚原因。这个测试能帮你提前发现很多在短时间测试中暴露不出来的问题。5. 评判标准迁移之后选型思路该怎么调整5.1 从“算力优先”转向“场景匹配优先”评判标准变了选型思路也要跟着变。以前大家习惯先按算力排序再从高到低挑。现在更合理的做法是先明确场景需求再去找最匹配的芯片。场景匹配包括算力够用、带宽匹配、算子覆盖、精度达标、功耗合适、软件栈成熟这几个维度。算力只是其中一个维度而且往往不是最关键的维度。举个例子如果你部署的是一个小模型但要求极低延迟那算力可能不是瓶颈瓶颈在启动开销和调度延迟你需要的是一颗调度轻快、小算力但低延迟的芯片。反过来如果你做的是离线批量推理对延迟不敏感但对吞吐量要求高那就要优先看带宽和批处理效率。场景不同最优解完全不同。5.2 把软件栈成熟度纳入核心权重软件栈成熟度应该被赋予更高的权重。一颗软件栈成熟的芯片可能纸面算力不是最高的但实际部署效率高、开发周期短、运维省心。一颗软件栈不成熟的芯片纸面算力再高也可能因为各种工程问题而无法发挥。在评估时可以把软件栈成熟度拆成几个子项框架支持度、算子覆盖度、编译器质量、文档完善度、社区活跃度、厂商支持响应速度。每个子项打分最后加权。我个人的经验是对于需要快速上线的项目软件栈成熟度的权重可以占到四成以上。对于研究性质的项目可以适当降低这个权重因为研究项目有更多时间做底层优化。但即便是研究项目软件栈太差也会严重影响迭代速度。5.3 小规模试点比大规模采购更划算在正式大规模采购之前先做小规模试点。试点规模不用大几颗芯片加上一台服务器就够。试点的目的是在真实业务环境下验证芯片的表现包括性能、精度、稳定性、开发效率。试点阶段要尽量模拟真实部署条件包括数据流、并发模式、运维流程。试点跑通了再考虑扩大规模。试点的成本看起来是额外的但它能帮你避免大规模采购后才发现不合适的巨大损失。我见过太多团队因为跳过试点直接大批量采购结果发现芯片跟业务不匹配要么硬着头皮用要么折价处理损失远超试点成本。试点还有一个好处是能帮你积累第一手的调优经验这些经验在大规模部署时非常宝贵。5.4 建立自己的内部基准测试集长远来看每个做AI部署的团队都应该建立自己的内部基准测试集。这个测试集包含你业务里最典型的几个模型、最真实的数据分布、最常用的batch size和并发模式。每次评估新芯片或者新版本软件栈都用这个测试集跑一遍记录结果。时间长了你就有了一套自己的数据选型时不再依赖厂商的宣传材料而是靠自己的实测数据做判断。这个测试集的维护需要一些投入包括定期更新模型和数据、维护测试脚本、管理测试环境。但它的回报是长期的能让你在芯片选型这件事上越来越有底气。而且这套测试集还能用于日常的性能监控和回归测试一举多得。6. 一个简化版的真实负载评估清单如果你正准备做芯片评估又不想搞得太复杂可以参考下面这个简化清单。它不能覆盖所有情况但能帮你抓住重点避免在明显不合适的芯片上浪费太多时间。评估维度具体检查项判断标准算力匹配稠密算力、持续算力、目标精度下的算力满足业务峰值需求的1.5倍以上余量内存带宽带宽数值、算力带宽比、实际带宽利用率算力带宽比在合理区间实测利用率高于60%算子覆盖主力模型算子列表、非标准算子支持情况核心算子原生支持非标准算子有可行方案量化支持INT8/INT4支持程度、量化工具链、精度损失量化后精度损失在可接受范围性能提升明显软件栈框架支持、编译器质量、文档、社区主流框架支持良好编译顺畅文档齐全多卡扩展互联带宽、扩展效率、编程模型扩展效率高于70%编程模型清晰稳定性长稳测试、降频情况、错误率24小时长稳无异常性能无显著下降功耗散热典型负载功耗、散热方案、每瓦性能功耗在预算内散热方案成熟这个清单里的每一项都需要实际测试来验证不能只看厂商资料。测试的顺序建议从算力匹配和内存带宽开始这两项如果不满足后面的就不用测了。算子覆盖和量化支持可以并行做软件栈和多卡扩展在初步筛选通过后再深入。稳定性和功耗散热放在最后作为最终决策的参考。7. 写在最后的一些个人体会做了这么多年的推理部署和芯片评估我最大的体会是没有最好的芯片只有最合适的芯片。同一颗芯片在A团队手里是神器在B团队手里可能是鸡肋差别往往不在芯片本身而在于团队对场景的理解和对软件栈的掌握程度。所以评估芯片这件事本质上是在评估芯片和团队、和业务的匹配度。另一个体会是评估这件事没有捷径。你可以看很多评测报告可以听很多厂商宣讲但最终做决策的依据应该是你自己跑出来的数据。别人的数据可以参考但不能替代你自己的测试。因为你的模型、你的数据、你的部署环境、你的团队能力都是独一无二的变量只有你自己的测试才能把这些变量都考虑进去。最后一个建议是把评估当成一个持续的过程而不是一次性的任务。芯片在迭代软件栈在更新你的业务也在变化。今天合适的芯片半年后可能就不合适了。保持对新技术和新方案的关注定期用你的基准测试集去跑一跑这样在需要做选型决策时你手里始终有最新的数据。这件事做起来不难难的是坚持。但坚持下来回报是实实在在的。