AI芯片选型避坑指南：从57种到120多种的调研方法论

前阵子做AI芯片选型调研，一开始列了个清单，只有57种。自己觉得已经挺全了，结果越查越心虚，等把所有云端、边缘、车规、嵌入式、FPGA和专用加速器都过了一遍后，清单变成了120多种。整个过程踩了不少坑，也把“选设备到底该看什么”这个问题反反复复推翻重来。这篇就把调研过程中的分类思路、选型维度和几条避坑经验一起写出来。不管你是给团队配训练服务器，还是给产品选边缘加速模块，只要对“AI芯片”这三个字的理解还在迷茫期，这篇文章应该能帮你省掉不少翻文档的时间。

1. 一份芯片调查为什么会从 57 种扩展到 120 多种

1.1 最初的 57 种：以“曝光率”为中心

最初收集的57种芯片，来源其实很朴素：往年技术大会上的展商列表、各家厂商发布过的AI加速产品、以及圈内经常被讨论的那些型号。当时的标准只有一个——“我听说过它”。这个标准很短视，但一开始确实没觉得有什么问题。毕竟在脑子里的第一版调研计划中，我预设的答案就是“AI芯片=加速卡”，只需要把型号和参数抄进表格，再排个高低就能交差。

真正开始逐个核对参数时才发现，那些曝光率高的芯片，绝大多数集中在云端训练和云端推理两类，形态也基本是独立加速卡和整机板卡。有一批嵌入式芯片、车规芯片、FPGA方案几乎没有一个进入最初的清单。它们不常见不等于不重要，只是不在技术大会的聚光灯下。这时我已经意识到，如果只按“听过”来筛，调研结果会有很大的幸存者偏差。

1.2 扩展过程：按场景、形态、代际重新展开

后来我换了一个思路：把“芯片”这个模糊的词，拆成几个更具体的维度——部署位置（云端、边缘、终端）、工作形态（独立卡、集成模块、系统级SoC）、功能定位（训练、推理、通用计算）、代际版本。按照这套维度重新过滤一遍，数量立刻开始涨。边缘计算盒子里那个不起眼的小芯片，自动驾驶域控制器上的车规级芯片，手机SoC里的AI单元，甚至以IP形式授权给其他芯片厂商的AI内核，都应该被纳入统计——它们不直接以一块插卡的形式出现，但实际出货量和使用量可能非常高。

除了形态，代际也带来大量增量。同一架构下的加速卡，经常会有好几档显存、功耗、频率版本；厂商还会为特定客户或特定市场提供定制型号。如果全部算上，数量远不止120多种。为了避免清单失控，我给自己定了一条相对保守的分类规则：只要型号具有独立的产品命名，或者在一个实际项目中不能随意互换，就单独占一行。按照这个口径，120多种是我调研后比较有信心的数字。

1.3 分类框架如何反哺选型

120多种听起来很多，但拥有分类框架后，选型反而简单了。因为选型本质上不是在一堆芯片里做“好坏对比”，而是先圈定几个自己能接受的边界：你的模型跑在什么场景？交付形态是整机还是卡？配套软件谁来维护？这些问题一旦定下来，剩下的选项通常不超过10个。

整份调查最后的价值，不是让读者记住120多个名字，而是借助足够广的覆盖建立一棵分类树。品牌、型号都挂在树上，选型时从树干往下走：计算场景→硬件形态→算力和显存区间→软件生态匹配。后面所有参数分析，都是在这个框架内完成的。

2. 选设备前先理清这几个基本问题

2.1 你是训练模型，还是只用模型做推理？

训练和推理对设备的要求差别非常大。训练阶段的瓶颈在“反复迭代”：每次前向反向都要把几十亿参数过一遍，消耗浮点算力，需要大规模并行，对数据精度和动态范围也更敏感。推理阶段则把重心转向“延迟和吞吐”：同样跑一个模型，可以接受排队等结果，也可以要求几十毫秒内出答案，选型完全不同。

举一个很常见的例子：服务端推理任务，很多时候不需要顶级训练卡，一块中端加速卡配合低精度量化就能达到不错的效果。训练场景，特别是用大模型做微调时，显存容量和互联带宽往往比单卡算子更快成为瓶颈。拿不定主意的话，先回答“训练为主、推理为主还是两者混合”，后面所有参数筛选才有意义。

2.2 你想要的是一块卡、一台整机，还是芯片级定制？

很多人在调研时没意识到，设备采购和芯片调研是两码事。你是在给团队选一套可用的部署方案，还是在做元器件选型？前者直接买整机或加速卡就行，电源、散热、底层固件都调好了；后者则需要关注芯片本身的接口、生命周期、功耗、供货周期这些更底层的问题。

如果只是做模型训练和推理服务，买整机或插卡是最省心的选择。如果是做边缘设备，比如一套工业质检盒子或车载控制器，不能只看AI算力，还要看视频编解码能力、扩展接口、工作温度、BSP适配情况。把这条前提写清楚，120多种芯片里有一大半会自动被过滤掉。

2.3 维护这套设备的团队，手里有多少工程能力？

选型从表面看选的是硬件，实际上选的是生态。有的芯片峰值算力高，但配套框架比较封闭，出了问题文档少，社区活跃度低。有的芯片纸面参数没那么亮眼，但主流框架原生支持，社区里能查到各种踩坑记录，团队上手速度快很多。

我的建议是：在清单扩展过程中，把每个型号下的生态信息单独记一列。至少包括官方文档完整度、示例代码数量、主流推理框架支持状态、与集群调度工具的兼容性。这些信息一开始看起来很琐碎，但在真正部署时，直接决定了研发团队晚上九点能不能下班。

3. 选型时真正该盯着的核心参数

3.1 算力：峰值不代表你能用上

几乎所有芯片宣传都会给出一个很大的TOPS或TFLOPS数字。但要注意它是基于什么精度、什么稀疏化条件计算出来的。FP16算力可能是FP32的两倍，INT8在部分架构上还能翻倍，再加上稀疏计算，数字可以非常夸张。实际跑模型时能不能达到这个峰值，取决于算子是否被框架优化过、数据是否能完全加载到片上缓存、任务是否足够规整。

我在整理数据时，会把算力拆成三列：FP32、FP16、INT8。然后重点找有没有厂商发布过基于真实模型的性能报告。只有峰值没有基准测试的话，我会把它的有效算力按峰值的50%到70%来估算。很多型号纸面差距很大，真实模型上的差距反而没那么大，不要因为一个数字直接拍板。

3.2 显存和内存带宽：决定模型能跑多大、多快

大模型参数一旦超过显存容量，就得做张量并行、流水并行或卸载到CPU内存，性能瞬间掉一大截。所以选型时一定要把计划部署的模型规模列出来，反推最小显存需求。公式大概是这样：模型权重 + 激活值（推理时）+ 优化器状态（仅训练时）+ 推理缓存。这个算法听起来简单，但我在调研中发现很多人忘了算显存，只能买回来再想办法。

带宽同样关键。Transformer解码阶段对内存带宽极度敏感，因为每一步都要把模型权重从显存搬到计算单元。带宽不够，算力再高也会被卡在数据搬运上。所以在调研表里同时保留两个参数：显存容量和显存带宽。这两个指标比单纯的TOPS更能反映模型能不能被顺畅跑起来。

3.3 互联与扩展：单卡和集群之间的桥

很多应用单张加速卡已经扛不住大模型推理，并发请求上来以后，必须靠多卡甚至多机并联。这时卡间互联带宽、通信协议、是否支持多卡池化、是否兼容主流集群调度框架，就会变得非常关键。若一台设备只支持PCIe直连，对延迟敏感的多卡训练会很难受；若支持专用互联，多卡张量并行的通信开销能低很多。

调研时不要只看单卡规格，还要看厂商提供的互联拓扑图和官方支持的机内卡数上限。我见过有人买了几十张加速卡回来，结果同机只支持4卡互联，剩下全走网络，性能完全达不到预期。这类信息在官方文档里其实都有，只是前期容易被忽略。

3.4 功耗和散热：成本账本里的隐藏大头

功耗看着是次要参数，实际是运营成本的大头。假设一块加速卡300瓦，一台服务器插8块，光卡就2400瓦，加上CPU和整机，单柜功耗轻松超过4000瓦。如果没有足够的散热和供电冗余，就要限制功率墙，性能就会打折。

算一笔很简单的账：一块功耗200瓦和一块功耗350瓦的加速卡，如果都跑同样的模型并达到相近吞吐，按7x24小时运行、每度电1元算，单片功耗差150瓦，一年电费差约1314元。训练集群几百块卡，这个差异会放大到几十万元。采购价只是第一道成本，功耗才是长期项目里会被反复感知的东西。

3.5 软件生态与工具链：决定你晚上几点下班

芯片能不能发挥性能，一半靠硬件，一半靠软件。我调研时习惯给每类芯片打一个生态成熟度评分，重点看四点：官方编译器是否成熟，能否平滑对接主流训练推理框架；算子库覆盖度，特别是注意力、卷积、归一等常见操作的优化；调试工具和性能分析工具是否好用；社区文档是否齐全。

如果某款芯片性能很强，但算子需要自己写扩展，我一般会把它从候选列表里往后放。除非项目里有专门的底层优化角色，否则这个成本很可能吃掉所有性能收益。选设备不是选一个最强芯，而是选一套从模型到上线最快跑通的组合。

4. 从实际调研中整理出的对比维度和速查表

4.1 一张可以拿来就用的选型评分表

经过这轮从57到120多种的扩展，我把所有调研字段收敛成8个维度，做成一张选型评分表。每个候选型号占一行，每个维度按1到5分打分，权重根据自己项目调整。我常用的基础权重：算力满足度25%、显存与带宽20%、软件生态20%、互联扩展15%、功耗散热10%、采购与部署成本5%、供应链稳定性5%。也可以把售后与文档支持再加进去，替代供应链稳定性的一项。

打分时不要只凭感觉。我给每个维度都设了一个“最低门槛”，比如软件生态低于3分就直接淘汰，哪怕算力打分再高也不考虑。这个硬性门槛能避免你被某个宣传亮点冲昏头。

4.2 不同场景的选型组合建议

评分表只能帮你排序，排完之后要回到场景里做最终确认。以下是我在不同项目中见过比较稳的参考组合。

大模型训练为主的场景：重点看显存容量、互联带宽和软件生态，单卡算力其次。训练卡数量通常不会太少，互联拓扑比单卡性能更影响整体效率。这个场景直接跳过只支持PCIe互联的小板卡。

云端推理服务：重点看INT8和FP16有效吞吐、显存带宽以及框架支持程度，同时对功耗敏感。服务端推理通常是7x24小时运行，长期电费占比重，可以用功耗换取更低的总拥有成本。

边缘视频分析：除了AI算力，还要看视频解码能力、内存通道、I/O接口和整机可靠性。很多边缘盒子同时处理多路视频流，如果解码位点不够，AI再强也跑不动整体任务。

嵌入式与车规类项目：生命周期和供应链稳定性优先级最高，其次才是算力。这个方向不适合只看参数表，还要确认BSP、操作系统支持和长期供货承诺。

5. 常见问题与避坑实录

5.1 只看TOPS和TFLOPS，被宣传数字带偏

第一版57种清单里，我几乎完全按峰值算力排序，结果发现很多小尺寸边缘芯片排得比云端卡还高。因为它们INT8算力数据很夸张，但实际跑高精度推理时掉的性能非常明显。后来我把排序分成训练精度和推理精度两列，再按真实场景比较，这个排名才不再误导人。峰值算力只能在同架构、同精度下面做粗筛，跨场景直接比较没有意义。

5.2 忽略内存带宽，推理延迟严重超标

曾经有一个模拟推理项目，单张卡理论算力很高，但实际跑一个7B级模型时，首token延迟非常难看。排查下来发现是内存带宽不足，权重读取成了瓶颈。把模型量化到INT8后，数据搬运量降为原来四分之一，延迟才回到可用范围。从那以后，我的调研表里带宽和容量都必须同时出现，缺一不可。

如果带宽卡脖子，单纯加算力不会有什么用。大语言模型这类输出型任务尤其明显，token-by-token生成时每一步都要读权重，带宽才是真正的决定因素。

5.3 软件生态适配成本超预期

另一位开发者最开始因为某芯片单价便宜选了它，结果算子兼容性差，项目组花了两周迁移、重写部分算子，最后还是换了方案。那次之后，我们调研表里都会标注主流训练推理框架的官方支持状态。没有原生支持的，除非团队里有底层专家，否则直接标“不推荐”。

生态成本很难用价格衡量。一个成熟生态能帮你省掉几周甚至几个月的适配期，而设备要跑三五年，这个时间差远比芯片标价重要。

5.4 调研过程中被反复验证的几条经验

总结几条对实战有帮助的经验。一是信息源要交叉验证，官网给的峰值性能只是起点，要找第三方评测和社区反馈。二是一份调研表必须有日期，因为芯片迭代很快，三个月前的参数可能已经过时。三是永远以“我要跑的模型”作为第一筛选条件，不要从参数表倒推应用场景。

四是别忽略配套成本。购买加速卡往往还要配服务器、交换机、存储和调试环境，这些加起来可能比芯片本身还贵。把这些写进调研表，选出来的方案才真正能落地。

最后说一点我自己的体会。把AI芯片从57种扩展到120多种，真正让我收获最大的不是那张越写越长的清单，而是它在逼着我把“选设备”这件事从拍脑袋变成一套流程。现在遇到朋友来问怎么选AI设备，我一般不会先说哪款芯片好，而是先问他们跑什么模型、什么场景、多少人维护。这几个问题回答完，答案往往自己就浮出来了。如果你也在做类似的调研，建议不要急着把120多种全部读完，先把你的场景边界画清楚，再去看清单，很多纠结会自动消失。