AI芯片选型指南：从120种方案中筛选最优解

1. 从57种到120多种，这份调查到底在说什么

第一次看到这个标题的时候，我正蹲在一个硬件选型的项目群里，有人甩过来一句“AI芯片现在都120多种了，选设备到底看什么”，群里瞬间安静了三秒。说实话，57种到120多种这个数字变化本身并不吓人，真正吓人的是它背后折射出来的一个现实：AI芯片这个赛道已经从“几家独大”变成了“百花齐放”，而且这个“百花”里有一大半你可能连名字都没听过。

我自己做硬件选型和方案评估有几年了，从最早接触GPU加速卡，到后来各种NPU、ASIC、FPGA方案满天飞，踩过的坑不算少。这份调查从57种写到120多种，本质上是在做一件事：把市面上能叫得上名字的AI加速硬件全部拉出来，按类别、按场景、按算力档位做一次系统性的梳理。它解决的不是“哪个芯片最好”这种伪命题，而是“在我的预算、功耗、生态约束下，哪个芯片最不坏”这个真问题。

适合看这份内容的人其实很明确：一是正在做AI硬件选型的工程师，二是需要给项目做技术路线决策的技术负责人，三是对AI芯片行业格局感兴趣、想搞清楚各流派差异的从业者。如果你只是跑跑开源模型、用用云端API，那这份调查对你的直接价值有限，但了解一下底层硬件的分化趋势，对理解模型部署的成本结构还是有帮助的。

我接下来会从这份调查的分类逻辑讲起，然后拆解选设备时真正该看的几个维度，再结合我自己在实际项目中的操作经验，把“怎么看、看什么、看完怎么决策”这条链路完整走一遍。中间会穿插一些我踩过的坑和总结出来的速查方法，希望能帮你少走点弯路。

2. 120多种AI芯片的分类逻辑与核心差异

2.1 为什么数量会从57种膨胀到120多种

这个数字翻倍的过程，其实对应的是AI芯片行业从“通用加速”向“场景专用”分化的过程。早期大家做AI加速，思路很统一：搞一颗能跑矩阵乘法的芯片，把算力堆上去就行。那时候能叫得上名字的方案确实不多，GPU几家、FPGA几家、ASIC几家，凑一起五六十种顶天了。

但后来情况变了。大模型训练和推理的需求开始分叉，训练要的是高精度、大显存、高互联带宽，推理要的是低延迟、低功耗、高吞吐。再往后，边缘侧和端侧的需求又不一样，有的要极致省电，有的要实时响应，有的要支持多模态输入。需求一分化，芯片设计就开始走不同的路：有的堆MAC阵列，有的优化内存层次，有的搞稀疏计算加速，有的专攻Transformer结构。

我自己的观察是，这120多种里，真正在市场上活跃的可能也就三四十种，剩下的要么是PPT阶段，要么是特定客户定制不对外卖，要么是已经停止迭代但还在某些老项目里服役。所以看到“120多种”这个数字，第一反应不应该是“这么多怎么选”，而应该是“先按场景筛掉一大半”。

2.2 按部署场景分类：云端、边缘、端侧

选设备的第一步，永远是先搞清楚你的模型跑在哪里。这个“哪里”不是物理位置，而是部署场景的约束条件。

云端训练和推理的场景，核心约束是算力和显存。你要跑千亿参数级别的模型，单卡显存至少得80GB起步，互联带宽得跟得上，否则多卡并行的时候通信开销能把加速比吃掉一大半。这个场景下，能选的方案其实不多，翻来覆去就是那几个系列的高端型号。

边缘侧的场景就复杂多了。边缘服务器、工控机、车载计算平台，这些地方的共同特点是功耗有上限、散热条件有限、但又要保证一定的吞吐量。我做过一个边缘视频分析的项目，当时在几款方案之间纠结了很久，最后选了一款功耗在30W左右的推理加速卡，算力不算顶尖，但胜在稳定和生态成熟。

端侧的场景是最碎片化的。手机、摄像头、智能音箱、可穿戴设备，每个品类的功耗预算和算力需求都不一样。端侧芯片往往和SoC深度绑定，选型的时候不能只看芯片本身，还要看整个平台的软件栈支持情况。

2.3 按架构流派分类：GPU、FPGA、ASIC、存算一体

架构流派决定了芯片的“性格”。GPU是通用性最好的，编程模型成熟，生态完善，但功耗和成本也最高。FPGA是灵活性最好的，可以针对特定算法做硬件级优化，但开发门槛高，需要硬件工程师介入。ASIC是能效比最好的，针对特定算子做硬化，但一旦流片就不能改，适合出货量大的场景。存算一体是最近几年比较热的方向，把计算单元和存储单元放在一起，减少数据搬运的开销，但成熟度还在爬坡阶段。

我个人的经验是，如果你不确定未来算法会不会变，那就别碰ASIC。我见过一个团队为了省功耗选了ASIC方案，结果半年后模型结构一改，芯片直接跑不动新算子，整个项目被迫推倒重来。FPGA适合算法还在快速迭代的阶段，但你要有足够的硬件团队来支撑。GPU虽然贵，但它是“不会错”的选择，至少不会因为生态问题把你卡死。

2.4 按算力档位和精度支持分类

算力档位不是越高越好，这个道理说起来简单，但实际选型的时候很容易被“峰值算力”这个数字带偏。我见过太多人拿着TOPS数字对比来对比去，最后选了一个峰值算力很高但实际利用率很低的方案。

真正该看的是“有效算力”，也就是在你的模型结构下，芯片能实际跑出来的吞吐量。这个数字和峰值算力之间可能差好几倍。影响有效算力的因素很多：内存带宽够不够、算子支持全不全、编译器的优化水平怎么样、批处理大小能不能拉上去。

精度支持也是一个关键维度。有的芯片只支持INT8，有的支持FP16，有的支持BF16甚至FP8。如果你的模型对精度敏感，那就不能选只支持低精度的方案。但反过来，如果你的模型本身就可以量化到INT8而不掉点，那选一个INT8算力强的芯片反而更划算。

3. 选设备时真正该看的六个核心维度

3.1 算力之外，先看内存带宽和容量

这是我踩过的最大的坑。早期选型的时候盯着TOPS看，觉得算力够了就行，结果模型一跑起来发现瓶颈全在内存上。芯片的算力再高，如果数据喂不进去，那也就是个摆设。

内存带宽决定了数据从显存搬到计算单元的速率。对于大模型推理来说，内存带宽往往比算力更关键，因为推理过程是内存密集型的，每生成一个token都要把整个模型权重读一遍。我实测过一个场景，两款芯片峰值算力差了一倍，但因为内存带宽的差异，实际推理吞吐量只差了20%。

内存容量则决定了你能跑多大的模型。模型权重、激活值、KV Cache都要占显存。如果你要跑长上下文，KV Cache的占用会线性增长，这时候显存容量不够就直接OOM了。我的经验是，选型的时候至少留出30%的显存余量，否则稍微改改批处理大小或者上下文长度就会爆。

3.2 软件栈成熟度：编译器、算子库、框架支持

软件栈这个东西，用的时候感觉不到它的存在，一旦出问题就是大问题。我经历过一次算子不支持的情况，模型里用了一个比较新的激活函数，结果芯片的算子库里没有对应实现，只能回退到CPU跑，性能直接掉了一个数量级。

评估软件栈成熟度，我一般看几个点：一是主流框架的支持情况，PyTorch和TensorFlow的模型能不能直接转换过去；二是算子覆盖度，特别是你模型里用到的那些非标准算子；三是编译器的优化能力，能不能自动做算子融合、内存复用、流水线编排；四是调试工具好不好用，出了问题能不能快速定位。

提示：软件栈的评估一定要用你自己的模型去实测，不要只看官方文档里的支持列表。文档里写“支持”和实际跑起来“能用”之间，可能隔着好几个版本迭代。

3.3 功耗与散热约束：别让电费和风扇成为瓶颈

功耗这个维度，在云端场景下可能没那么敏感，但在边缘和端侧就是生死线。我做过一个车载项目，最初选的方案算力很漂亮，但功耗到了75W，散热方案怎么改都过不了热测试，最后只能换方案。

功耗约束要从系统层面看，不能只看芯片的TDP。芯片功耗加上外围电路的功耗，再加上散热系统的功耗，才是整个系统的功耗预算。风冷、液冷、被动散热，不同的散热方式对应的功耗上限完全不同。被动散热的场景下，芯片功耗通常不能超过15W，否则温度压不住。

还有一个容易被忽略的点是功耗的动态范围。有的芯片在满载和空载之间的功耗波动很大，这对电源设计提出了更高的要求。如果电源模块的响应速度跟不上，就会出现电压跌落导致系统不稳定。

3.4 生态兼容性与迁移成本

迁移成本是我在做方案对比时一定会算的一笔账。从现有方案迁移到新方案，需要投入的人力、时间、以及可能的风险，这些都要折算成成本。

生态兼容性主要体现在几个方面：一是模型转换工具链是否完善，能不能把现有模型无缝迁移过去；二是API是否兼容，需不需要重写推理代码；三是社区活跃度，遇到问题能不能找到人帮忙；四是长期维护承诺，厂商会不会持续更新驱动和工具链。

我一般会做一个简单的迁移成本评估表，把各个维度的迁移工作量按人天估算，然后加到总成本里。有时候一款芯片本身便宜，但迁移成本很高，算总账反而不划算。

3.5 供应链稳定性与长期供货承诺

这个维度在平时可能感觉不到，但在缺货周期里就是决定性的。我经历过一次芯片断供，项目做到一半发现买不到货了，只能紧急切换方案，浪费了两个月的时间。

评估供应链稳定性，我一般会问几个问题：芯片是自有产能还是代工，代工厂的产能分配情况怎么样；厂商的财务状况是否健康，有没有持续经营的风险；这款芯片在厂商的产品路线图里处于什么位置，是主力产品还是过渡产品；有没有明确的长期供货承诺，比如五年或者七年。

注意：对于生命周期比较长的项目，比如工业控制、车载、医疗设备，一定要选有长期供货承诺的芯片。消费类芯片的迭代周期可能只有一两年，跟不上你的项目节奏。

3.6 总拥有成本：不只是芯片单价

总拥有成本包括采购成本、部署成本、运维成本、迁移成本、以及机会成本。芯片单价只是其中一部分，有时候甚至不是最大的一部分。

部署成本包括服务器、电源、散热、机架空间等配套设施的投入。运维成本包括电力消耗、故障率、维护人力等。迁移成本前面说过了。机会成本则是选错方案导致的项目延期或者性能不达标带来的损失。

我一般会做一个三年期的TCO测算，把上面这些成本都折算进去，然后对比不同方案。有时候一款芯片单价贵30%，但因为功耗低、故障率低、迁移成本低，三年算下来反而更便宜。

4. 实操：从需求梳理到最终选型的完整流程

4.1 第一步：明确你的模型和场景约束

选型的第一步不是看芯片，而是看自己的需求。我一般会先回答几个问题：模型是什么结构，参数量多大，输入输出的形状是什么；推理的延迟要求是多少，吞吐量要求是多少；部署环境是什么，功耗和散热的约束是什么；预算是多少，包括硬件预算和人力预算。

这些问题看起来简单，但实际做的时候很容易漏。我见过一个团队选型的时候只考虑了推理延迟，没考虑吞吐量，结果上线之后发现单卡吞吐量不够，只能加卡，成本直接翻倍。

把这些问题整理成一个需求文档，越具体越好。比如“模型是BERT-base，输入序列长度128，批处理大小32，要求P99延迟低于50ms，部署在边缘服务器，功耗不超过75W，单卡预算不超过两万”。有了这个文档，后面的选型就有了明确的筛选标准。

4.2 第二步：用场景约束做第一轮筛选

拿着需求文档，开始做第一轮筛选。这一轮的目标是把120多种缩小到10种以内。

筛选的逻辑很简单：功耗不满足的去掉，显存不够的去掉，精度不支持的去掉，生态不兼容的去掉。这一轮不需要看性能数据，只看硬性约束。比如你的功耗上限是75W，那所有TDP超过75W的方案直接排除，不用犹豫。

我一般会做一个筛选表格，把候选芯片的硬性参数列出来，然后逐项打勾打叉。这一轮下来，通常能筛掉80%以上的选项。

4.3 第三步：用实测数据做第二轮对比

剩下的10种左右，就需要用实测数据来对比了。实测的重点是有效算力和实际功耗。

有效算力的测试方法很简单：拿你自己的模型，在目标芯片上跑一遍，测吞吐量和延迟。注意要测不同批处理大小下的表现，因为批处理大小对吞吐量的影响很大。还要测不同输入长度下的表现，因为有些芯片在长序列上的性能衰减比较明显。

实际功耗的测试需要用功率计，测满载和空载的功耗，以及功耗的波动范围。如果条件允许，最好把芯片装到目标系统里测，因为外围电路和散热系统也会影响整体功耗。

提示：实测的时候一定要用真实模型，不要用厂商提供的benchmark。厂商的benchmark通常是优化过的，和你的实际场景可能差很远。

4.4 第四步：算总账，做最终决策

实测数据出来之后，就可以算总账了。我一般会做一个加权评分表，把各个维度的得分乘以权重，然后加总。

权重的设定取决于你的项目特点。如果是成本敏感的项目，采购成本和功耗的权重就高一些；如果是性能敏感的项目，有效算力和延迟的权重就高一些；如果是长期项目，供应链稳定性和生态兼容性的权重就高一些。

算完总账之后，通常会有两三个方案得分接近。这时候就需要做一些主观判断了。我的经验是，如果两个方案得分差不多，选生态更好的那个，因为生态好的方案在后续开发和维护中会省很多事。

4.5 第五步：小批量验证与灰度上线

最终决策之后，不要一次性大批量采购。先买一两块做小批量验证，把整个部署流程跑通，确认没有隐藏的坑。

小批量验证的重点是：驱动和固件能不能正常安装，模型转换工具链能不能跑通，推理服务的稳定性和一致性怎么样，长时间运行会不会出现性能衰减或者内存泄漏。

验证通过之后，再灰度上线，先切一小部分流量到新方案上，观察一段时间。如果没有问题，再逐步扩大比例。这个流程虽然慢，但能避免一次性踩大坑。

5. 常见问题与排查技巧实录

5.1 模型转换失败：算子不支持怎么办

算子不支持是模型转换阶段最常见的问题。表现是转换工具报错，提示某个算子没有对应的实现。

排查思路是这样的：先确认是哪个算子不支持，然后看这个算子能不能用其他算子组合替代。比如有些芯片不支持某个特殊的激活函数，但可以用基础算子拼出来。如果替代不了，就看能不能把这个算子放到CPU上跑，虽然性能会受影响，但至少能跑通。

如果算子不支持的情况很普遍，那说明这款芯片的软件栈成熟度不够，可能需要考虑换方案。我一般会在选型阶段就做一次算子覆盖度检查，把模型里用到的所有算子列出来，逐个确认支持情况。

5.2 性能不达预期：瓶颈定位的四个方向

性能不达预期的时候，不要急着换方案，先定位瓶颈在哪里。我一般从四个方向排查：计算瓶颈、内存瓶颈、通信瓶颈、调度瓶颈。

计算瓶颈的表现是计算单元的利用率很高，但吞吐量上不去。这时候要看是不是算子实现效率低，或者精度设置不合理。内存瓶颈的表现是计算单元经常空转，等数据。这时候要看内存带宽是不是不够，或者内存访问模式是不是不友好。通信瓶颈在多卡场景下比较常见，表现是加速比远低于线性。调度瓶颈的表现是任务分配不均匀，有的计算单元忙死，有的闲死。

定位瓶颈的工具一般是厂商提供的性能分析工具，可以看各个单元的利用率和等待时间。如果没有工具，也可以用排除法，逐个改变参数看性能变化。

5.3 功耗超标：从芯片到系统的排查路径

功耗超标的时候，先确认是芯片本身功耗高，还是系统其他部分功耗高。用功率计分别测芯片供电和系统供电，就能区分开。

如果是芯片功耗高，看是不是负载太高，或者频率设置不合理。有的芯片支持动态调频，可以根据负载调整频率和电压，能省不少电。如果是系统功耗高，看是不是电源转换效率低，或者散热系统功耗大。

还有一个容易被忽略的点是待机功耗。有的芯片在空载的时候功耗也不低，如果业务有明显的波峰波谷，待机功耗就会拉高整体能耗。

5.4 长期运行稳定性：内存泄漏与热衰减

长期运行稳定性是上线之后才会暴露的问题。最常见的是内存泄漏和热衰减。

内存泄漏的表现是运行时间越长，内存占用越高，最后OOM。排查方法是定期打印内存占用，看是不是单调递增。如果是，就要检查代码里有没有未释放的资源，或者驱动有没有已知的内存泄漏问题。

热衰减的表现是运行一段时间后，性能逐渐下降。这是因为芯片温度升高之后，为了保护自己会降频。排查方法是监控芯片温度，看是不是接近了温度墙。如果是，就要改善散热条件，或者降低环境温度。

5.5 常见问题速查表

6. 我个人的选型心得与避坑建议

6.1 不要迷信峰值算力，有效算力才是关键

峰值算力是理论值，实际能跑出来多少取决于软件栈和模型结构。我见过太多方案在纸面上算力碾压对手，实际跑起来却被对手反超。选型的时候一定要用真实模型实测，不要只看规格书。

6.2 生态比参数更重要，迁移成本要算进去

生态好的方案，开发效率高，遇到问题容易找到解决方案。生态差的方案，可能参数很漂亮，但开发过程中处处碰壁，最后项目延期。迁移成本一定要算进总账里，有时候生态好的方案虽然贵一点，但总成本反而更低。

6.3 留足余量，别把功耗和显存卡得太死

选型的时候要留余量，功耗留20%到30%的余量，显存留30%以上的余量。业务是会增长的，模型是会变大的，如果一开始就卡得太死，后面稍微一改就要换硬件。

6.4 小步快跑，先验证再放量

不要一次性大批量采购，先小批量验证，跑通整个流程，确认没有隐藏问题之后再放量。这个流程虽然慢，但能避免一次性踩大坑。我见过太多团队为了赶进度跳过验证阶段，结果上线之后问题频出，反而更慢。

6.5 关注长期供货，别选过渡产品

对于生命周期比较长的项目，一定要选有长期供货承诺的芯片。过渡产品可能一两年就停产了，到时候被迫迁移，成本很高。选型的时候要问清楚厂商的产品路线图和供货承诺。

6.6 建立自己的评估框架，不要被厂商牵着走

厂商的销售和技术支持都有自己的立场，他们推荐的不一定是最适合你的。建立自己的评估框架，用统一的标准去对比不同方案，才能做出客观的决策。我的评估框架包括需求文档、筛选表格、实测数据、加权评分表，这套流程走下来，基本不会出大错。

这个内容后续还可以这样扩展：一是针对特定场景做更细化的选型指南，比如边缘视频分析、大模型推理、车载计算等；二是补充更多实测数据，建立不同芯片在不同模型下的性能数据库；三是跟踪新架构的成熟度，比如存算一体、光计算等方向的进展。这些方向我后续会陆续整理，有兴趣的可以持续关注。