前阵子做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%。也可以把售后与文档支持再加进去替代供应链稳定性的一项。评分维度权重参考核心关注点打分依据示例算力满足度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多种全部读完先把你的场景边界画清楚再去看清单很多纠结会自动消失。