做AI相关开发这两年我整理过一份内部使用的AI芯片选型调查文档。最初只是随手列出来市面上能买到的训练卡和推理卡拢共57种后来一边调研一边补充现在文档里已经挂了120多种芯片涵盖云端、边缘到终端跨度从传统GPU到各种专用加速器。很多朋友问我“列这么多有什么意义选设备到底该看什么”其实真正有价值的不是那一串产品名字而是你在整理过程中一点点建起来的判断坐标系。这篇东西我从57种写到120多种中途踩了不少坑也梳理出一套自己的选型逻辑今天把它拆开讲讲。1. 从57种到120多种一份清单为什么会越写越长1.1 市场比你想象的更拥挤一开始我理解里的“AI芯片”就是那种插在服务器里、跑训练的大板卡。按这个思路搜确实只找到五六十种。可深入之后就发现所谓AI芯片的范围远比想象中宽有专门为数据中心训练设计的通用GPU有针对推理做了裁剪的加速卡有贴在摄像头旁边的低功耗边缘模块有集成在手机SoC里的神经网络单元还有趴在自动驾驶域控制器里做多路视觉处理的专用芯片。这些全都属于AI芯片的范畴。同一家厂商也可能同时出好几条产品线。比如某做通用GPU的厂商既有训练卡又出过针对轻量级推理的型号还在同一代架构里派生出一个嵌入式计算模块。如果只按“AI芯片”这个关键词去收集很容易漏掉那些细分市场里的重要角色。我后来专门按照“架构类型目标场景”两个维度去重分类清单立刻从五十多种跳到了上百种。所以从57到120不是故意堆数量而是你真正理解了市场结构之后发现它本来就那么多。1.2 每多一个维度就多一批芯片记录芯片时如果只记型号和算力那它永远是一张无意义的数据表。我把每一颗芯片都尽量标注上几个关键维度应用场景云端训练、云端推理、边缘推理、终端AI、自动驾驶、工业视觉架构类型GPU、ASIC、FPGA、NPU、类脑、存算一体芯片形态独立板卡、模块、SoC、IP授权供货状态量产、开发板阶段、样品、概念软件生态成熟度框架支持完善、仅有基础SDK、全部需要自研这些维度一展开芯片数量自然暴增。比如FPGA这类可重构芯片虽然算力不突出但在低延迟、可自定义数据通路上有独特价值再看ASIC如果只写“某款推理芯片”你会漏掉它背后的多个版本同一系列还有低功耗、高性能、带视频编解码等衍生型号。每一颗芯片在它的细分位置上都值得记录否则后面做选型时缺少参照。1.3 筛选的意义不是罗列而是建立坐标系很多人会觉得整理一百多种芯片太重了根本用不过来。但我的体会是清单本身不是最终产物你需要的是一个能让你快速回答“推荐什么芯片”的坐标系。当有人拿着一个“跑视觉检测边缘端功耗低于5W成本控制严格”的需求来问我时我不可能去翻一百多种芯片而是直接在坐标系里圈出几个候选边缘端、低功耗、带NPU、有成熟SDK、量产出货。筛选几轮之后能用的其实就那七八种。所以从57写到120本质上是逼自己去理解每一类芯片适合解决什么问题。搞懂了这些你面对任何一个新需求都能很自然地在心里排出一个候选列表而不是靠记忆力硬背型号。2. 选设备前先问四个问题2.1 你的任务到底是训练还是推理很多第一次选型的人上来就问“哪颗芯片算力最大”这其实没有意义。训练和推理是完全不同的两条路线。训练通常要求高并行度、大显存、高通信带宽因为要反复前向反向迭代、同步梯度推理则更看重单次请求延迟、吞吐量、能耗比。同一颗训练旗舰卡拿去做线上24小时推理通常电费和资源利用率非常难看反过来一颗推理专用芯片去跑训练精度和可扩展性又跟不上。所以第一步先明确这件事我买这颗芯片是给开发环境做模型训练还是给最终产品做实时推理如果是两个场景都要覆盖就要考虑是一套硬件兼容还是分别采购。现实中很多团队为了省钱只买推理板卡结果发现模型根本训练不动最后还是补了一张训练卡。这类问题应该在选型之前先解决。2.2 工作在云端还是边缘云端和边缘的约束差异极大。云端服务器放在数据中心或者机房环境可控散热和供电相对充足主要追求单位时间内的吞吐能力功耗和体积可以放在后面考虑。边缘端完全相反摄像头、机器人、无人机、手持设备这些芯片的功耗、封装尺寸、工作温度往往是硬限制。我见过一个工业视觉项目选了一颗标称性能很高的边缘芯片结果实际部署环境夏天室外温度接近50摄氏度那芯片因为散热不足频频降频最终实际帧率只有标称的一半。边缘设备通常还需要考虑接口是否匹配能不能直接接摄像头MIPI/CIS有没有千兆网口有没有CAN总线支不支持POE供电。很多芯片给你一个PCIe接口但边缘主板根本没有PCIe插槽还要额外加转接极其别扭。这个维度必须在清单里标清楚。2.3 预算和货期芯片选型不是只看“芯片单价”你得算整体拥有成本。包括服务器整机、外围主板的成本散热、机箱、电源的成本还有软件开发和维护的人力成本。有些芯片单颗价格便宜但工具链太简陋工程师要多花两三个月写底层算子这笔费用远超芯片差价。货期同样关键我调研时发现某些新发布的芯片号称“已量产”实际供货要等半年以上如果项目进度紧急这种就没法选。建议做一张“可用性表格”记录每颗芯片的采购渠道、最小起订量、交货周期、样片还是量产、固件是否稳定。这些信息很难在一张芯片规格书里看到必须靠跟供应商或代理商一条一条问。调查到120多种之后光是对比货期就花了不少时间但这一步能帮你避免在项目冲刺阶段被芯片交付卡脖子。2.4 团队技术栈你的团队平时用什么框架如果常年只写一个主流深度学习框架那就优先选该框架原生支持好、算子覆盖度高的芯片。有些芯片性能纸面上很猛但你对框架的支持只停留在“兼容”阶段很多自定义操作符需要手写CUDA风格的内核没有前人踩坑资料遇到问题只能自己翻文档开发节奏会非常痛苦。团队的人数和水平也要考虑。一个熟悉底层和C的团队可以玩转裸金属SDK选择自由度大一些一个主要写Python、靠现成库解决问题的团队最好选那种能“开箱即用”的平台。说到底芯片本身不会直接干活帮你把模型跑起来的是工具链和团队的技能组合。3. 核心硬件指标逐个拆解数字背后的坑3.1 算力TOPS和TFLOPS不是同一个东西芯片规格书里最显眼的指标就是算力。但这里有很多陷阱。TFLOPS说的是浮点运算能力TOPS说的是整数运算能力。AI推理里很多模型经过量化后用INT8来做所以厂商喜欢标TOPS而训练通常需要FP16或者FP32就得看TFLOPS。这两个数字不能直接对比一颗芯片标称“200 TOPS”另一颗标着“多高TFLOPS”你要先确认彼此是在什么精度下测出来的。还有“峰值算力”和“实际持续算力”的区别。峰值通常是跑在最高频率、特定指令组合下测出来的极限值。实际情况中考虑功耗墙、散热、数据搬运、同步开销能跑到峰值的五到七成就不错了。有些芯片号称稀疏计算能翻倍但前提是你的模型权重满足稀疏性要求如果模型不稀疏那个数字就是摆设。所以看算力时心里先打个折。3.2 内存带宽比算力更容易成为瓶颈AI计算本质上是“计算与数据搬运”的比赛。芯片每做一次矩阵运算都要从内存里取一批权重或激活数据。如果内存带宽跟不上算力再高也只能空转。这就是为什么同一批模型在不同芯片上的实际性能往往不像峰值算力差距那么大。你有一个算力120 TOPS但带宽只有50GB/s的芯片和一个算力90 TOPS但带宽达到100GB/s的芯片跑大多数实际模型后者大概率赢。在评估时可以算一个粗略的“算力带宽比”。例如一颗芯片标注INT8算力为x TOPS带宽为y GB/s那x/y得到的就是一次运算需要喂多少字节。比值越大说明它越依赖高复用、高数据命中率的场景一旦模型访存密集真实性能很难看。选型时不要单独看算力或带宽两个指标要放在一起看。3.3 显存容量决定你能跑多大的模型显存也叫板载缓存或内存决定了你能装下多大的模型批次。训练大模型时权重、梯度、优化器状态、激活值全都要驻留在显存里一张有几十GB内存的卡和一张只有8GB内存的卡能跑的最大模型规模天差地别。即使可以梯度检查点、混合精度、模型并行这些技巧都要消耗额外的通信和计算资源复杂度直线上升。推理端也有类似问题尤其是大语言模型。模型本身权重就在那里推理时还要为每一条请求保留上下文缓存如果显存不够并发上不去延迟也不稳定。所以看芯片时除了算力一定要注意它配备的显存或缓存容量。有些边缘芯片标称NPU算力很高但只带2GB内存跑稍微复杂一点的模型就提示“内存不足”只能换小模型这种芯片就不适合你的场景。3.4 互连与通信多卡跑不跑得动如果你要搭建多卡并行训练或推理集群单卡性能只是前提卡与卡之间的互连带宽才是真正的天花板。很多训练模型用的是数据并行每轮迭代都需要卡间同步梯度通信量非常大。如果互连带宽低或者只能走普通的PCIe总线那么卡一多通信耗时比计算还长整体效率提升极其有限。我实测过一种相对低成本的组合计算卡算力不错但卡间通信走普通网桥四卡并行效率勉强只有单卡的2.6倍换成有高速互连的架构后四卡效率能到3.5倍以上。除了板内互连还要考虑是否支持横向扩展到多机训练。是否有RDMA、有没有高速交换网络的驱动支持这些都决定了芯片能不能进集群。很多边缘场景则反过来要看的是芯片对外提供了哪些接口例如PCIe通道数、USB、UART、SPI这些决定了你和其他设备的连接难易。不要觉得这些很琐碎实际连接不上的痛苦比算力不够更让人头疼。3.5 功耗与散热很多芯片不是性能不够是散热压不住芯片的TDP热设计功耗和实际运行功耗并不能直接划等号。有些厂商标注的TDP是指极限状态下的上限实际跑模型时可能有25%到40%的浮动还有些芯片在持续高负载下会触发功耗墙降频导致性能逐渐下滑。边缘设备尤其敏感电源功率和散热器尺寸都是有限的选一颗20W TDP的芯片却配一个只能压住10W的被动散热外壳最终只能降频、丢帧。云端倒是没这么极端但机柜的功率上限和电费账单同样直接影响运营成本。我的经验是把“持续跑典型模型时的稳定功耗”作为关键指标。所以你在做基准测试时不能只看跑一两次的结果要连续跑几小时记录温度和帧率曲线看清散热压不压得住再决定要不要用这颗芯片。4. 软件生态决定你是“高效开发”还是“在坑里挣扎”的关键4.1 框架兼容性和算子覆盖度硬件只是舞台真正决定你能不能把项目做完的是软件生态。首先要确认芯片是否支持你平时用的深度学习框架。大多数芯片厂商都会说“支持某主流框架”但你要具体到该框架的哪个版本、哪些算子做了加速、哪些算子回退到CPU上慢慢跑。我之前遇到过一颗芯片官方文档声称支持大量算子实际我用一个包含LSTM和注意力机制的模型去转换结果有一整段需要手写自定义算子的适配代码前后折腾了接近两周。在比较不同芯片时我建议整理一份“算子覆盖表”把你项目里用到的模型结构产生的算子类型列出来逐一查每个候选芯片的支持情况。小批量模型和超大模型的算子差异非常大一张表能帮你直观看到哪颗芯片可以减少你的开发量。4.2 工具链成熟度编译器、调试器和量化工具成熟芯片厂商会提供一整套从模型转换到部署的工具链模型格式转换器、编译器、运行时、调试工具、性能分析器还有量化和剪枝辅助工具。这些工具的完善程度直接决定开发效率。比如将浮点模型转换成INT8模型这个环节好的工具链能自动调节精度损失甚至提供一整套校准流程差的工具链只给你一个命令行量化之后模型精度可能从95%掉到60%还没有专门调试手段逼得你手动插一堆回调代码去定位。性能分析器也很重要。你不能只关心模型能不能跑还要知道它到底慢在哪里。一个能显示每层计算耗时、内存占用、访存带宽利用率的工具能帮你快速找到优化方向。如果芯片厂商只提供极为简陋的profiler那优化起来无异于盲人摸象。我评估一颗芯片是否值得投入时会先看它的工具链是否能覆盖“模型转换-量化-编译-分析”这条完整链。4.3 驱动稳定性与社区驱动是硬件和软件之间的桥梁。芯片规格再好看驱动不稳定也会让你每天面对随机崩溃和内核报错。就应该把驱动更新频率和bug修复速度作为考察项。可以去看该芯片/平台的开发者论坛、QA社区以及用户反馈有没有人吐槽某个版本有严重性能回归或者官方是否经常发补丁。一个冷门的芯片出了问题找不到同类用户只能自己啃源码那种感觉我在早期调研时体验过多次。社区生态还包括代码示例、模型仓库、文档质量。有些厂商的示例代码更新及时覆盖常见模型新手照着就能跑通另一些厂商文档多年没更新示例还是几年前的旧框架语法让人寸步难行。你在选型前花一天时间把两个候选芯片的“从零跑通一个模型”流程走一遍就能感受到差距。4.4 实际算一笔账生态差带来的隐性成本假设芯片A峰值算力比芯片B高出300%但芯片A的推理引擎不支持某个关键算子需要自己写底层实现额外花三周芯片B性能略弱但插上用现有转换工具几分钟就跑通了。算上人工成本芯片B带来的实际收益很可能高于芯片A。对于大多数公司来说开发周期和人力成本往往比硬件性价比更敏感。我认识一位工程师他所在团队为了追求更高算力选一颗冷门芯片结果半年过去了模型还在调精度和性能另一个人用成熟平台不到两周就上线了。这种教训比一百份对比表格更能说明问题。5. 常见问题与排查技巧实录5.1 只盯峰值算力忽略了持续频率很多人拿到芯片第一反应是跑一个网上流传的高分benchmark。分数高就以为一切搞定实际部署时才发现跑几分钟后发热降频性能掉了一大截。我在评估边缘芯片时习惯把重负载进程连续跑一整夜同时在每个小时记录帧率和核心温度。如果曲线下滑严重就说明散热或者功耗控制有问题。解决的思路是要么降压降频换取稳定的帧率要么换散热方案增大散热面积或加快风扇转速最差的情况就是换芯片。5.2 忽略内存带宽导致实际利用率报废我早期测试某款芯片时标称算力看起来很有优势但实测模型性能只有预期的70%。排查理由用官方性能分析器看每一层的访存带宽发现很多层都吃满了内存带宽而计算单元只用了不到一半。这说明内存带宽不足模型变成了“访存受限”。解决方案是改进数据排布、增加张量复用、减少频繁的小批量操作实在优化不动就得承认这颗芯片不适合你的模型。判断模型是“计算受限”还是“访存受限”有个直接方法把输入批大小翻倍如果时间增长不大而帧率提升明显说明算力有冗余带宽还够如果帧率几乎不涨同时内存带宽已经饱和那就是带宽瓶颈。用这种方式你能很快判断一颗芯片和你模型的适配度。5.3 显存爆掉的排查思路如果训练或推理过程中报“显存不足”不要急着把batch size调小。按这个顺序排查看日志确认是哪一步分配显存失败是权重初始化、前向还是反向。检查模型本身是不是有额外的激活缓存没释放或者使用了超大的中间张量。尝试混合精度训练用FP16/INT8替代FP32通常能省下接近一半显存。关闭梯度检查点或延迟卸载这个要具体分析。确认是否残差连接把整个batch的中间结果都留下来了可以改用分段计算。如果还是超限再考虑模型并行把这些只有在做完整推理或训练时浪费的中间量拆到多卡上。有些芯片显存是固定的没法换卡扩容这时候选型时就要估算你的模型最大需要多少内存留出至少20%的余量。不要等项目做到一半才来发现内存不够。5.4 生态不成熟时的临时替代方案如果你手上只有一颗生态不成熟的芯片项目又必须往前推我的建议是大部分模型先用ONNX作为中间表示再做转换尽量绕开对特定训练框架的依赖。找厂商要“参考实现代码”或“模型对应示例”优先跑通官方提供的几个模型再替换你自己的模型。用传统CV算子或自定义C实现来顶替不支持的层比如某些特殊激活函数可以被一组基础算子组合表达。如果某些层实在太特殊考虑把这些层剥离出来放到CPU上跑虽然慢但至少能先把流程跑通后续再优化。终极方案换个模型结构去掉那些需手写算子的部分。这很多工程优化实际会做的事比硬磨底层算子要快得多。5.5 搭建自己的评估矩阵我最终从120多种芯片里选出候选靠的不是感觉而是一张量化打分表。这张表包括峰值算力按你的典型精度、内存带宽、显存容量、功耗、持续稳定性能、工具链成熟度、框架兼容性、社区活跃度、单芯价格、整机成本、可采购性和货期。每一项根据应用场景打1到10分再乘以对应权重最后得到综合分。举个例子做一个室内安防边缘盒子你的权重可能是功耗0.25、价格0.25、工具链0.2、算力0.15、内存带宽0.1、其他0.05。这样一算很多标称算力很高的芯片因为功耗太高直接出局而某些中端低功耗芯片反而排前面。没有权重任何评分都是伪客观。6. 从120种到3种我的筛选流程实操6.1 第一轮排除“不能用”的第一轮不看性能只看可落地性。打开那120多种的清单把以下情况先分出去没有公开购买渠道、只接受自家定制还处于PPT概念阶段没有开发板或样片工具链基本为空白甚至没有官方SDK只对特定行业开放普通买不到供应周期太长等货超过半年这一轮通常能筛掉一半以上。别舍不得选型是从“能用”开始而不是从“最强”开始。很多看起来很美好的芯片只能在展会上看到工程上是没法依赖它们的。6.2 第二轮按使用场景切分第二轮根据你自己的真实应用把剩下的芯片分成几堆训练、云端推理、边缘推理。如果你只做边缘推理那就把训练和云端推理暂时放一边。在这个环节我还会进一步细分成“单路视频分析”“多路视频分析”“大模型推理”“低功耗传感器处理”等子场景。每一小堆可能就三四颗芯片这样可以大大缩小比较范围。6.3 第三轮用你自己的模型跑真实基准第二轮留下的大概十几颗这时候别只看规格书尽量拿到开发板或云服务器资源用你自己的模型和数据跑一轮真实基准。我会固定几个真实任务一个图像分类模型、一个目标检测模型、如果做大模型再跑一个文本生成的子任务。分别记录端到端延迟、吞吐、最大batch、峰值功耗、连续运行稳定度。注意环境要尽量一致使用同样的框架版本、同样的量化方式、同样的推理引擎配置不然对比出来的数据没有意义。这一轮结束通常能确定三到五颗真正满足功能和性能的候选。6.4 第四轮谈价格、确认服务与长期支持最后联系供应商或代理商确认单价、数量折扣、开发套件价格、软件开发支持承诺、产保规划、停产风险。这里一定要问清楚后续是否有固件更新以及如果芯片要换代上一代产品大概保供多少年。边缘产品做出来是要卖好几年的芯片停供损失巨大。我一般还会要一份正式的合作协议把支持和供货承诺落到合同条款里。最终留下两款常规主力型再加一款备选型。这个结果往往和最初大家凭直觉推荐的高性能大屏卡完全不一样。6.5 没有最好的芯片只有最合适的芯片整个过程走下来你自然会发现“选设备该看什么”这个问题不能用一句“看算力、看生态”来回答。它取决于你的应用场景、团队能力、成本预算、项目周期和可接受风险。120多种的清单最大的价值不是让你挑出唯一的“王者”而是让你在每一次遇到新需求时都能快速定位到合适的候选区间再用上面这套流程缩小取优。我个人现在每隔一个季度就会更新一次那份清单把新发布的芯片加进去把停产或不可用的标出来把友商的反馈填进去。这已经变成一种习惯比任何花钱买的报告都更贴合我们自己的项目。最后再分享一个特别实用的小技巧在做大规模采购之前能申请到的开发板都多申请几个哪怕要付一点押金。你用实际项目跑上三天比任何宣传片和规格书都更能说明问题。选AI设备说到底是在选一个能陪你长期协作的合作伙伴千万别只看那一张参数表。