年初有位朋友做边缘计算设备选型，一开始列了个 AI 芯片候选清单，拢共 57 款，觉得已经覆盖得很全面了。结果调研越做越深，发现同一个厂家在不同产品线、不同代际、甚至不同封装下都会分出好几款，最后这份清单硬生生整理到了 120 多种，光是去重和分类就花了两周。他跑来问我"你说选个设备，到底该看什么？"，我发现这个问题比想象中复杂得多——因为单纯看算力跑分根本没有意义，同一种架构在不同场景下的表现可能天差地别。
这篇内容就是基于那份从 57 种扩展到 120 多种的调查过程展开的。我会把这 120 多款芯片拆开揉碎，讲讲它们到底有什么区别、参数表上哪些数字能信、哪些数字纯属营销话术，以及真正落到你手头的项目里，该怎么建立一套自己的选型框架。适合正在做方案选型、预研评估，或者单纯想搞明白 AI 硬件市场为什么这么碎的工程师和技术决策者，看完你至少能比 90% 的人更清楚手里的器件该看什么、不该看什么。
1. 一份清单从 57 变 120：AI 芯片为什么会碎成这样
很多非硬件背景的工程师第一次接触 AI 芯片市场时，最大的困惑不是"芯片怎么选"，而是"为什么有这么多型号"。他们可能以为 AI 芯片就是 GPU、NPU 两大类，结果真正把市场翻一遍才发现，光是那几家头部厂商的历年在售型号、不同功耗档位、不同精度侧重、不同接口封装就能排列组合出好几十款。更别提近几年冒出来的大量 AI 加速卡、边缘 NPU、端侧 SoC 内置算力单元，以及国产替代背景下涌现的几十个品牌。当时我们统计的 57 款只是"有名有姓、资料齐全"的起步名单，后面越挖越多，逐步膨胀到 120 多种，这个数字本身就很能说明问题。
1.1 训练、推理、边缘、端侧：四个战场各有各的玩法
AI 芯片碎片化的第一个原因是应用场景的分裂。训练芯片和推理芯片不在一个维度上竞争，云端的推理加速卡和边缘盒子里的 NPU 也不在一个维度上竞争，手机 SoC 里挂的 AI 单元更是另一套逻辑。调查到第 80 款左右的时候，我们不得不按"场景归属"做了一次强制分类，才把混乱的清单理出脉络：
- 训练类芯片：追求极致算力和互联带宽，通常以集群形态出现，单位是卡，指标是 TFLOPS、显存带宽、互联拓扑能力。
- 云端推理芯片：针对已训练好的模型做在线服务，看重吞吐量、延迟、功耗比，对精度支持范围要求高。
- 边缘/工控级芯片：部署在摄像头、机器人、边缘服务器上，功耗、体积、接口、工作温度都是硬约束，算力反而不是第一位的。
- 端侧 SoC/NPU：集成在手机、平板、智能家居、可穿戴设备中，往往以"总算力 TOPS"作为营销卖点，但实际可用性受散热、内存带宽、软件生态的严重制约。
这四类芯片对"好"的定义完全不同。你拿一个训练卡去评估边缘场景，首先功耗和尺寸就不合格；拿一个端侧 NPU 去算大模型推理，内存带宽先卡死你。很多初学者选型出错，不是因为看不懂参数，而是把不同赛道的芯片混在一起对比，自然得不出有效结论。
1.2 国产芯片入场带来的"同质化竞争"放大效应
从 57 款增加到 120 多款的过程中，增量最明显的并不只是国外巨头，而是大量国产 AI 芯片厂商。这些厂商有些做云端训练加速，有些做边缘推理，有些直接内置进安防、工控、车载设备里，产品命名、参数表述、软件生态各自为政。更要命的是，很多国产芯片在算力标称上互相"对标"，你出 16 TOPS 我也出 16 TOPS，你标 INT8 我也标 INT8，但实际跑模型的效率差异非常大。这种同质化竞争让市场上出现了大量参数接近、实际表现两极分化的产品，进一步加剧了选型的困难。
我当时做的那份 120 多款清单里，至少有 30 款属于"参数看起来差不多，但软件成熟度和工具链差异巨大"的类型。如果不深入社区、不看实测，光靠厂商提供的白皮书做判断，很容易选到一款纸面数据完美、实际用起来想骂人的芯片。
1.3 碎片化的背后：没有一款芯片能覆盖所有场景
说到底，AI 芯片越来越碎的根本原因是：没有任何单一架构能够在成本、功耗、性能、生态四个维度上同时赢得所有场景。GPU 架构通用性强但功耗高，适合训练；ASIC 架构效率高但灵活性差，适合固定模型推理；NPU 架构在端侧很香但通用计算能力弱；FPGA 可以灵活重配但开发和量产成本相对尴尬。市场用脚投票的结果，就是每个垂类赛道都养出了一批专用芯片，于是清单越拉越长。从 57 写到 120 多，不是我们闲得慌，而是这个领域本来就已经细碎到这个程度了。
2. 参数表上那些数字，"暴力算力"为什么是最不值钱的信息
很多刚从软件转过来的人看芯片，第一个动作就是比 TOPS、TFLOPS、MAC 数量。我一开始也这样，但做着做着就发现：纯算力指标是最容易被厂商包装、也最容易误导决策的信息。你需要理解这些数字背后藏着多少水分和前提条件，才有可能不看走眼。
2.1 TOPS 的三重水分：精度口径、稀疏率、实际利用率
TOPS（Tera Operations Per Second）看着挺唬人，但它有一个巨大的隐藏前提——计算精度和稀疏性。以某款芯片为例，INT8 精度下标称 30 TOPS，但如果你跑 FP16 的模型，算力直接减半甚至更多；如果模型没有结构化稀疏，那它标称的"稀疏加速倍数"就完全用不上；再叠加实际运行中访存瓶颈、任务调度开销、散热降频等因素，真实可利用的算力往往只有标称值的 20% 到 50%。这不是哪家厂商独有的问题，而是整个行业的普遍现象。
所以选型时不要只看一个 TOPS 数字，要问三个问题：
- 这个标称是在什么精度下测的？INT8、FP16、BF16 算力差好几倍。
- 标称是否依赖稀疏加速？我的模型能不能吃到这份红利？
- 持续运行下的实际算力是多少？散热和功耗墙会不会直接让跑分"缩水"？
2.2 稠密算力 vs 稀疏算力："理论峰值"和"有效算力"不是一回事
稠密算力是指所有计算单元都在做有效乘加运算时的峰值，稀疏算力则是在跳过零值权重或激活值后能达到的加速效果。打个比方，稠密算力相当于高速公路上所有车道都跑满车时的通行量，稀疏算力则是某些车道可以飞过去时的夸张结果。厂商最喜欢把稀疏算力做得特别抢眼，因为很多宣传场景不需要交代模型的稀疏度需求——你拿一个全稠密的模型过去，稀疏加速单位完全是闲置的。
对于实际项目，我建议一律以稠密 INT8 或 FP16 算力作为对标基准，把稀疏算力当作加分项而不是核心参考项。这样能有效过滤掉一批"营销数字"。
2.3 Benchmark 的猫腻：跑分模型和你真实模型的差距
再往下挖一层，即便算力数字是诚实的，不同芯片对模型结构的适应性差异也很大。有的芯片对卷积优化做得极好，但对 Transformer 类的矩阵乘非常拉胯；有的芯片在小模型上能跑出接近峰值的利用率，换个稍大一点的模型就内存爆炸。所以厂商给出的 Benchmark 只能证明"它跑那个模型很强"，不能证明"它跑你的模型也强"。
我在实际调研时习惯做法是：找三到五个属于自己业务类型的代表模型（例如如果是做 CV 的，就选 ResNet 系列、YOLO 系列和一个 Transformer 检测头；如果是做 LLM 推理的，就选 7B 或 13B 参数的公开模型），去查这些模型在该芯片社区里的实测数据，或者直接申请开发板跑一遍。这个代价比硬件买错了重新来吧要低太多。
2.4 内存带宽和片上 SRAM：真正容易被忽略的算力天花板
很多人在参数表上只盯着 TOPS，却忽略了另一个决定性指标——内存带宽和片上缓存。AI 计算可以看成"数据的搬运和计算"，如果搬运速度跟不上计算速度，再高的算力也只能空转。举个实际例子：某款边缘芯片标称 20 TOPS，理论算力很可观，但它的内存带宽只有 25GB/s，跑一个稍微复杂一点的检测网络时，算子大部分时间在等数据，实测帧率低得可怜。
片上 SRAM 的大小决定了你能把多少权重和激活值留在最靠近计算单元的地方。SRAM 越大，对内存带宽的压力越小，实际利用率越高。这也是为什么现在主流 AI 芯片在迭代时都在拼命加大 SRAM 容量，而不是只堆算力。选型时建议把"算力/带宽"和"算力/SRAM 容量"两个比值拉出来对比，能避开很多光鲜亮丽的坑。
3. 比算力更关键的三张牌：生态、互联、功耗墙
算力只是入场券，真正拉开体验差距的是生态成熟度、互联能力和功耗约束。这三样东西在参数表上往往只是一行小字甚至不写，但它们往往决定了你的项目能做到什么程度。
3.1 软件生态：没有工具链的芯片等于废铁
做 AI 芯片选型时，我第一个看的从来不是算力而是交付物里包含哪些软件组件。一次完整的部署需要编译器、推理引擎、算子库、调试工具、性能分析工具，以及最重要的——社区和教程。有的芯片硬件做得很不错，但官方 SDK 文档几乎等于没有，算子支持要靠自己写，出了问题连个问的人都找不到。这种芯片就算白送给你，人力成本也足以拖垮整个项目。
反观那几家生态好的主流芯片，基本是"开箱即用"：模型转换工具能直接用，常见模型有现成优化样例，社区里有人踩过坑并给出了解决方案。我的个人经验是：生态成熟度应该占选型决策的 40% 以上权重，尤其是团队规模不大、没有专职芯片移植工程师的情况下。宁可硬件性能打个折，也要选一个软件链路通畅的。
衡量生态成熟度有几个很现实的维度：
- 从 PyTorch/TensorFlow 模型到芯片可执行文件，中间需要几步？有没有一键转换？
- 官方算子库能覆盖目标模型里多少比例的算子？缺失的算子自己实现的难度有多大？
- 有没有活跃的开发者社区、官方论坛或 QQ 群/微信群？
- 芯片厂商提供哪些调试和性能剖析工具？能不能找到性能瓶颈？
3.2 互联能力：单卡强不如多卡协同好
训练芯片高度重视互联带宽，因为集群算力取决于短板效应——一张卡再强，如果数据交换带宽跟不上，整个集群的扩展效率就会断崖式下降。而在推理和边缘场景，互联能力同样重要：多卡级联、外接 AI 加速模块、与主控芯片的 PCIe/UART/SPI 通信速率都会决定系统上限。
有一类很常见的"低价云端推理卡"，单卡性价比看起来极高，但互联协议是私有化的，只能单卡使用，不能做多卡横向扩展。如果你前期评估只看单卡，上线后突然要扩容，才发现根本组不了集群，这个教训我见过不止一次。选型前建议先想想项目未来两年会不会有多卡并联的需求，再决定互联值多少钱。
3.3 功耗墙与散热约束：性能释放的前提条件
芯片的典型功耗和最大功耗之间往往差着一大截。很多板卡标称 12W 典型功耗、30W 峰值功耗，实际持续跑算法负载时直奔 30W 去了——如果你的设备是密闭小型盒子，没有任何主动散热，那 30W 就是持续降频的节奏。我们曾经测过一款表面数据非常优秀的边缘盒子，标称 26 TOPS，实际装入无风环境后两分钟就热降频到 10 TOPS 左右，这个落差直接让部署方案的算力预算崩了。
所以在立项阶段就要弄清楚：设备的工作环境是什么？有没有风扇？结构热阻多少？目标功耗上限多少？这些约束条件要先于算力确立。你可以反过来用功耗预算去反推芯片需求——比如设备只有 10W 的功耗余量给 AI 模块，那么再强的高功耗芯片也没有意义，直接看 TDP 在 5W-8W 的档位，可以快速缩小选择范围。
3.4 供货稳定性与生命周期：长期项目的隐形风险
这一点完全来自我在整理 120 多种芯片时的新发现。很多芯片看起来不错，但细查它的供货状态和历史就会发现：有的型号已经处于 EOL 边缘，有的只对特定行业客户定向供货，有的在缺芯周期里优先供给大客户，小公司根本排不上队。有个选型导师告诉我一句话我非常认同："选芯片不只是选性能，是选一个愿意陪你走完产品生命周期的伙伴。"
因此在最终决策前，务必确认三件事：芯片是否处于大规模量产状态？是否有多家代理商渠道可以采购？厂商对该产品线的支持承诺年限是多少？如果这三条里有两条是模糊的，哪怕参数再诱人，也要慎重再慎重。
4. 分场景选型框架：训练、云端推理、边缘、端侧各自怎么挑
前面说的都是通用维度和原理，到了实际决策阶段，我们需要一套因地制宜的筛选框架。下面直接按四类场景给出我认为最合理的优先级排序和关键建议，你可以把它当成一份"抄作业"清单。
4.1 训练场景：互联第一，生态第二，单卡算力第三
训练芯片的选择逻辑和很多人想的相反，单卡峰值算力反而不是第一位指标。训练集群的核心瓶颈通常是互联带宽和显存容量：
- 互联带宽决定了大模型分布式训练的扩展效率。通信占比越高，卡间带宽越重要。
- 显存容量决定能装下多大的模型、多大的 batch size。显存不足就得做梯度累积或模型并行，训练效率会大打折扣。
- 生态决定你踩坑的深度。训练框架的适配程度、分布式通信库的成熟度，直接影响项目团队的产出效率。
选型建议：如果你的团队没有专职的底层性能优化工程师，优先选生态最成熟的那几家；如果预算有限、想尝试新兴训练芯片，一定要先做小规模集群测试，重点看 8 卡以上扩展效率是否接近线性。
4.2 云端推理场景：延迟、吞吐、功耗三要素动态平衡
云端推理芯片评估起来比训练复杂，因为线上业务对延迟的敏感度、请求的并发形态、模型动态批处理的能力都会影响最终选型。这里给出一个面向在线推理服务的决策清单：
- 延迟要求：SLA 是几个毫秒？需不需要用低延迟模式跑？延迟敏感型服务不能盲目追求吞吐，需要预留算力余量应对突发流量。
- 动态批处理能力：芯片能不能在运行时自动合并请求、提升 GPU/NPU 利用率？有些芯片推理引擎支持动态 batch，吞吐量能翻倍。
- 多模型共存：服务通常同时部署多个模型，芯片是否支持多上下文并行？切换模型的时间成本高不高？
- 功耗密度：机房单机柜功率预算有限，一个 PCIe 槽位能插的卡的总功耗不能超标。
我当时调研时特别重视一个指标——"每瓦每秒处理多少个请求"，这个指标综合了功耗和吞吐，比单纯看 TOPS 实在得多。拿这个指标去横向对比几款主流推理卡，你会发现有些标称很高的芯片在真实负载下排名骤降。
4.3 边缘/工控场景：接口兼容、温度范围、工具链一体化
边缘场景的选型往往不是"选最强"，而是"选最合适"。工程约束经常成为决定性因素：
- 工作温度范围：工业现场可能是 -40℃ 到 85℃，消费级芯片直接出局。
- 主控接口兼容性：边缘设备的 CPU 平台五花八门，有的是 ARM、有的是 x86，芯片支持的 PCIe 通道数、USB 版本、MIPI 接口能不能对上，比算力更重要。
- 实时性：很多工控场景对推理延迟的确定性有要求，普通 Linux 调度下抖动的 NPU 执行时间可能不合格。
这类项目的选型建议是：先定死接口和功耗，再算算力。很多边缘设备的主板框架已经定型，能塞进去的 AI 模块尺寸和接口类型是固定的，这时候你能选择的芯片范围其实就很小了，根本不需要在 120 多款里大海捞针。
4.4 端侧 SoC 内置 NPU：别被营销 TOPS 忽悠，看实测能跑什么
手机、平板、智能摄像头、带屏音箱这类端侧设备内置的 NPU，是营销水分最重的领域。厂商发布会上喊出的 "30 TOPS"、"50 TOPS" 看着吓人，但实际能跑到什么程度呢？我们实测过一些设备，重负载模型下 NPU 持续运行十几分钟就热降频，实际可用算力可能只剩 40%；加上内存带宽有限，大模型根本装不进片上缓存，主存读写的时间反而拖垮了整体延迟。
对于端侧 SoC 选型，我建议不要沉迷于 TOPS 数字，而是直接问三个可验证的问题：
- 这颗 NPU 能不能在我的目标模型精度下达到实时帧率？
- 官方 SDK 对这个模型的支持程度怎么样，有没有现成样例？
- 实际设备上持续运行一小时，性能和温度是否稳定？
这些问题的答案只能在真机实测中获得。做端侧项目的朋友，我强烈建议买一两台目标设备，先跑真实的业务模型，再做最终决策。
5. 从 57 到 120：一份调查用到的"选型过滤漏斗"
说完了原理和框架，我来复盘一下这份 120 多款芯片的调查方法本身。如果你也想建立自己的芯片知识库或选型库，下面这套"过滤漏斗"可以直接拿去改。
5.1 第一层：按场景赛道强制分类
第一轮从 57 款扩展到 120 多款后，最先要做的是按场景分类：训练类、云端推理类、边缘类、端侧类、以及其他特殊场景（自动驾驶、安防 ISP 融合等）。分类的目的不是给芯片贴标签，而是避免跨赛道对比。比如一个做机器人主控的工程师，只需要看边缘类的 30 多款，其余 90 款直接忽略即可。
分类之后再去重：同一颗芯片对应多个型号（不同封装、不同温度等级、不同供货形态）的，要归并成一条记录，并标注各型号的差异点，这样清单就不会虚胖。
5.2 第二层：用硬约束过滤
在每一类内部，先用硬性约束做第二层过滤：
- 功耗上限（超过某阈值的直接剔除）
- 温度范围（工业级 vs 商业级的分野）
- 接口形式（PCIe、MIPI、USB、以太网口等）
- 生命周期状态（已经是 EOL 或接近 EOL 的标记为高风险）
这个阶段的过滤速度非常快，我自己整理时，原本 35 款边缘芯片在这里就被砍掉了 12 款，剩下的才是需要深入评估的"种子选手"。
5.3 第三层：参数明细表横评
对通过硬约束的芯片，建立统一的参数明细表，横评以下字段：精度、算力、带宽、SRAM、内存容量、功耗、封装、软件栈、工具链成熟度、参考价格带、量产状态、典型应用案例。这个表不求一步到位，但字段必须先统一。整理这 120 多款时最耗时间的一步就是这个——不同厂商的资料口径差异很大，有的标峰值功耗，有的标典型功耗；有的用 TOPS，有的用 FLOPS，有的用 GOPS，单位不统一就得手动换算，非常容易出错。
5.4 第四层：社区信息交叉验证
参数表只能告诉你"纸面信息"，社区和开发者论坛上的真实反馈才是"落地信息"。我当时交叉验证时主要看三类内容：跑分实测（是否有人复现官方声称的性能）、踩坑记录（有没有人分享工具链 bug 和解决方案）、部署案例（有没有人把这款芯片用到了实际产品中）。一条芯片如果只有官方新闻稿、没有社区真实讨论，我会直接把它标为"低可信度候选"。
5.5 第五层：实际测试与 Demo 验证
过了前四层，剩下的芯片数量通常不超过 5 款。最后一步是搞到开发板或者样片，跑自己业务的代表性模型，记录真实帧率/延迟/功耗。这个阶段耗时最长，但也是唯一能一锤定音的环节。像我自己最后筛边缘芯片时，硬件测出来的真实性能和纸面参数的差距可以达到一倍以上，不实测根本没法放心。
6. 整理完这 120 款后，我总结出的五个选型铁律
第 1 条：没有万能芯片，只有适合当前场景的芯片。别把时间浪费在"哪款芯片全球第一"这种问题上，先把自己的应用场景、功耗预算、接口约束、软件能力通通搞清楚，答案自己会浮出来。
第 2 条：生态权重永远高于纸面性能。芯片的算力再猛，如果编译器连基本的算子都优化不好，你的模型跑起来就是比别人慢；反过来，生态成熟的芯片哪怕性能打个八折，成熟工具链和社区资源也能帮你把综合效率拉回来。
第 3 条：功耗墙决定真实算力。纸面 TOPS 是实验室里测出来的，你的设备里因为散热和功耗限制，实际能用的算力往往要按 50% 甚至更低去估算。建议在方案设计阶段就把散热余量算进去。
第 4 条：内存带宽和片上缓存是隐藏瓶颈。算力与带宽不匹配的芯片，跑真实模型时会出现典型的"计算等待数据"现象。参数表上不要只看算力，把每 TOPS 对应的带宽值算出来对比一下，能筛掉不少坑。
第 5 条：没有任何 Benchmark 比得上你自己的模型实测。厂商给的跑分数据再好，都不如你把自己最典型的几个模型跑一遍来得踏实。如果时间和预算有限，至少也要找到可信的社区实测数据，不能只凭参数表做决策。
最后再分享一条个人习惯：我每整理完一轮芯片清单，都会留一个"更新日期"字段，因为 AI 芯片市场变化太快了，三个月前的信息可能已经过时。这份从 57 款扩展到 120 多款的调查文档，现在已经变成了我持续维护的选型数据库，每次接到新项目，我只需要按照场景赛道的过滤漏斗重新跑一遍，就能在半天内锁定几个真正的候选芯片，而不是重新从零开始大海捞针。希望这套方法论对你也有用。
