1. 选型之前先想清楚你到底在解决什么问题做AI硬件选型这件事我踩过的坑比大多数人想象的多。早些年团队要上一个边缘推理项目需求方丢过来一句话——“找个能跑大模型的板子”结果我们花了三周时间对比了七八款加速卡和开发板最后发现真正的瓶颈根本不在算力而在功耗和散热空间。那次教训让我明白一个道理AI硬件选型的第一步不是看参数表而是把需求翻译成可量化的约束条件。很多人一上来就打开各种芯片厂商的官网对着TOPS每秒万亿次运算数字比大小这跟买车只看马力一样不靠谱。你需要先回答几个问题这个硬件要跑什么类型的模型是训练还是推理推理的话是云端批量推理还是端侧实时推理模型的参数量级是多少延迟要求是毫秒级还是秒级工作环境的供电和散热条件如何预算区间在哪这些问题不搞清楚后面所有的对比都是空中楼阁。我一般会把需求拆成四个维度来梳理。算力需求注意不是越大越好而是要匹配模型的计算图特征——有些模型吃INT8量化有些对FP16精度敏感有些瓶颈在内存带宽而非纯算力。内存与存储大模型推理时权重加载和KV Cache占用往往比算力更先成为瓶颈一个7B参数的模型在FP16下光权重就要占约14GB显存这个数字必须先算出来。功耗与散热嵌入式场景里一颗芯片的TDP直接决定了你的结构设计、电源选型和散热方案被动散热和主动散热的成本差距可能是数倍。接口与生态包括PCIe通道数、MIPI接口数量、以太网带宽以及最容易被忽视的软件栈成熟度——驱动、推理框架支持、量化工具链是否完善。我见过太多项目在硬件打样回来之后才发现推理框架不支持某款加速卡的自定义算子只能回退到CPU跑性能直接打了一折。软件生态的坑比硬件参数的坑深得多。所以这一章的核心结论就一句话先写需求规格书再看产品参数表。需求规格书里至少要包含模型类型与参数量、精度要求、目标延迟与吞吐、功耗上限、工作温度范围、接口清单、软件栈要求、预算区间这八项。写不出来说明你还没准备好做选型。2. 核心判断标准逐项拆解从算力到生态的完整评估框架2.1 算力指标怎么看TOPS之外的三个关键参数TOPS这个数字被厂商用烂了但它的参考价值有限。原因在于第一TOPS通常标注的是峰值算力实际利用率可能只有30%到60%第二不同精度下的TOPS不可直接比较INT8的TOPS和FP16的TOPS之间没有固定换算关系第三算力再高如果内存带宽跟不上数据喂不进去也是白搭。我评估算力时必看三个补充参数。内存带宽单位GB/s它决定了单位时间内能搬运多少数据参与计算。一个简单的估算方法是模型每推理一次需要搬运的数据量除以目标延迟得到所需的最小带宽。比如一个模型权重加中间激活值总共需要搬运2GB数据目标延迟10ms那带宽需求就是200GB/s低于这个值的硬件直接排除。缓存容量特别是L2和L3缓存对Transformer类模型的注意力计算影响很大缓存不够会导致频繁访问主存延迟飙升。实际利用率这个只能通过实测或参考第三方评测厂商PPT上的峰值数字打个对折再打个七折基本就是你能期望的真实水平。2.2 内存与存储被低估的瓶颈制造者显存或内存容量是硬门槛不够就是不够没有妥协余地。计算方法是模型权重占用 KV Cache占用 框架运行时开销 输入输出缓冲区。以Transformer推理为例KV Cache的占用等于 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批次大小 × 精度字节数。这个公式建议每个做选型的人都存下来我见过不止一个团队在部署长序列推理时被KV Cache撑爆显存。存储方面如果模型需要从磁盘动态加载存储的读取速度直接影响冷启动时间。NVMe SSD和普通SATA SSD的差距在模型加载阶段可能是十几秒和几十秒的区别。另外要注意存储的耐久度频繁的模型切换和日志写入会加速消耗闪存寿命。2.3 功耗与散热决定产品形态的隐形之手功耗指标不能只看芯片的TDP要看整个系统的总功耗。一颗标称15W的芯片加上内存、存储、接口芯片和电源转换损耗整板功耗可能到25W甚至更高。散热方案的选择直接跟这个数字挂钩5W以下可以完全被动散热10W左右需要散热片加适当风道20W以上基本要考虑主动风扇再往上就得上热管或液冷了。我一般会做一个简单的热设计估算总功耗乘以热阻得到温升。比如总功耗20W从芯片结到环境的热阻是5°C/W那温升就是100°C加上环境温度25°C结温直接到125°C超过大多数芯片的结温上限。这时候要么降低功耗要么改善散热降低热阻。这个计算在选型阶段就要做不要等打样回来发现烫手再改。2.4 软件生态决定开发周期的关键变量软件生态的评估我通常从四个层面入手。驱动与固件成熟度看厂商是否提供稳定的Linux内核驱动是否开源社区活跃度如何。推理框架支持主流框架如TensorFlow Lite、ONNX Runtime、PyTorch Mobile是否官方支持该硬件还是需要自己写后端。量化与编译工具链是否提供易用的量化工具能否把浮点模型自动转成硬件优化的定点模型支持哪些量化精度。文档与示例文档是否完整示例代码是否能直接跑通社区里有没有人踩过类似的坑。我的经验是如果一个硬件的软件生态需要你从零开始写算子适配那这个项目的周期至少要多出两到三个月而且后期维护成本极高。除非你是芯片原厂或者有专门的编译团队否则优先选生态成熟的方案。2.5 成本模型不只是芯片单价成本要算总拥有成本包括硬件BOM成本、开发人力成本、部署运维成本、功耗带来的电费成本、以及迭代换代的迁移成本。硬件BOM里除了芯片本身还要算上配套的电源管理芯片、内存、存储、接口连接器、PCB层数增加带来的成本。开发人力成本往往被低估一个生态不成熟的平台可能需要两个资深工程师投入数月做适配。部署运维成本包括远程升级、故障排查、备件库存。电费成本在规模化部署时不可忽视一个10W的设备和一5W的设备一万台部署一年的电费差距可能上万度。3. 实操选型流程从需求到决策的六步法3.1 第一步建立需求规格表我习惯用一张表格把所有约束条件列出来分为必须满足和尽量满足两档。必须满足的是硬门槛不达标直接淘汰尽量满足的是加分项用于最终排序。表格的列包括指标名称、目标值、最低可接受值、优先级、备注。比如算力这一项目标值可能是10 TOPS INT8最低可接受8 TOPS优先级为高备注写明模型类型和精度。这张表要跟所有利益相关方对齐包括算法团队、硬件团队、产品团队和采购。我吃过亏的地方是算法团队说“算力越大越好”产品团队说“成本越低越好”两边没对齐选型做到一半推翻重来。所以规格表一定要在选型开始前签字确认。3.2 第二步市场扫描与初筛根据规格表里的硬门槛做第一轮筛选。比如功耗上限10W那所有TDP超过10W的芯片直接排除内存容量要求8GB以上那所有板载4GB的排除。这一轮不需要看细节只看厂商公开的参数表就能筛掉大部分选项。初筛之后通常会剩下三到五款候选。这时候要开始收集更详细的信息找厂商要数据手册和参考设计看第三方评测报告在技术社区里搜实际使用反馈。我一般会重点关注社区里关于“坑”的讨论比如某款芯片的驱动在特定内核版本下有bug某款加速卡在批量推理时会有内存泄漏这些信息比官方文档有价值得多。3.3 第三步基准测试与实测验证参数表再好看不如实际跑一跑。基准测试要覆盖你的真实场景用你自己的模型在你的目标批次大小和序列长度下测延迟和吞吐。测试项目至少包括单次推理延迟、批量推理吞吐、峰值功耗、待机功耗、满载温度、冷启动时间、连续运行稳定性。测试时要注意控制变量环境温度保持一致散热条件保持一致软件版本保持一致。我见过有人拿A芯片在空调房测的数据跟B芯片在密闭机箱里测的数据对比这种比较没有意义。另外要测边界情况最长序列、最大批次、内存接近满载时的表现这些才是实际部署中最容易出问题的地方。3.4 第四步软件栈验证硬件跑分再高软件跑不起来也是零。软件栈验证要确认目标推理框架能否在该硬件上正常安装和运行模型转换工具是否支持你的模型结构量化后的精度损失是否在可接受范围内多线程和异步推理是否支持内存管理是否稳定。我一般会做一个最小可行验证拿一个简化版的模型走完从训练框架导出到目标硬件推理的完整流程。这个流程走通了说明基本链路没问题走不通就要评估适配的工作量和风险。这一步花的时间可能比硬件测试还长但绝对值得。3.5 第五步成本核算与商务评估技术过关之后算经济账。硬件单价、最小起订量、交期、付款条件、质保期限、技术支持响应时间这些都要跟供应商确认清楚。另外要问清楚长期供货承诺AI硬件迭代快如果一款芯片两年后就停产你的产品维护会非常被动。商务评估还要考虑供应商的配合意愿。有些供应商愿意提供参考设计、技术支持甚至联合调试有些则是卖完就不管。前者能帮你省下大量时间后者可能让你在出问题时孤立无援。3.6 第六步决策矩阵与最终选择把前面所有信息汇总到一个决策矩阵里每个指标按权重打分加权求和得到总分。权重的分配要跟需求规格表里的优先级一致。比如功耗是必须满足项那它的权重就应该高接口数量是加分项权重可以低一些。决策矩阵的好处是让选择过程透明化避免拍脑袋。但也要注意矩阵只是辅助工具最终决策还要考虑一些无法量化的因素比如团队对某个平台的熟悉程度、供应商的长期合作关系、技术路线的战略匹配度。4. 常见问题与排查技巧实录4.1 算力够但跑不快内存带宽瓶颈的识别与解决这是最常见的问题之一。表现是芯片的TOPS数字很高但实际推理速度远低于预期。排查方法是用性能分析工具看计算单元的利用率如果利用率很低但内存访问很频繁基本可以确定是带宽瓶颈。解决办法包括降低模型精度减少数据搬运量、优化数据布局提高缓存命中率、使用算子融合减少中间结果的读写、如果硬件支持的话增加内存通道或提高内存频率。4.2 精度下降超出预期量化策略的调整量化是端侧部署的常规操作但量化后的精度损失有时会超出预期。常见原因包括量化校准数据集与实际数据分布不匹配、某些层对量化特别敏感、激活值的动态范围过大。解决办法用更有代表性的校准数据、对敏感层保持浮点精度、使用混合量化策略、尝试不同的量化粒度per-tensor vs per-channel。4.3 散热设计不达标从选型阶段就要考虑散热问题往往在打样后才暴露这时候改设计的成本很高。预防措施是在选型阶段就做热仿真或至少做粗略的热计算留出足够的余量。如果实测温度超标临时解决办法包括降低芯片工作频率、改善风道、增加散热片面积、使用导热性能更好的界面材料。但这些都会带来性能损失或成本增加所以最好在选型时就选功耗更低的方案。4.4 软件兼容性问题版本锁定与升级策略AI软件栈的版本兼容性是个大坑。推理框架、驱动、固件、操作系统内核之间的版本依赖关系复杂升级一个组件可能导致另一个组件不工作。我的建议是在项目初期就锁定一套经过验证的版本组合记录在案不要轻易升级。如果必须升级先在测试环境完整验证确认所有功能正常后再推到生产环境。4.5 供应链风险备选方案与国产化考量AI芯片的供应链受多种因素影响交期波动大。选型时要考虑备选方案如果主选芯片缺货有没有pin-to-pin兼容的替代品或者软件栈兼容的另一款芯片。另外要关注芯片的长期供货承诺和停产通知周期避免产品上市后芯片停产。常见问题典型表现排查思路解决方向算力利用率低TOPS高但推理慢看计算单元利用率与内存访问频率优化数据布局、算子融合、降低精度量化精度损失大量化后准确率明显下降检查校准数据分布与敏感层混合量化、per-channel量化、敏感层保浮点散热超标满载温度超过结温上限测总功耗与热阻算温升降频、改善散热、换低功耗方案软件不兼容框架跑不起来或崩溃检查版本依赖关系锁定版本组合、测试环境先行验证供货不稳定交期延长或停产关注供应商通知与市场动态备选方案、pin-to-pin替代、提前备货这张表建议打印出来贴在工位上每次选型遇到问题先对照排查能省不少时间。5. 不同场景下的选型侧重点5.1 云端训练场景算力与互联是第一优先级云端训练对算力的要求没有上限同时多卡互联的带宽和拓扑结构非常关键。选型时重点关注单卡算力FP16/BF16为主、显存容量和带宽、卡间互联带宽NVLink或PCIe、对分布式训练框架的支持程度。功耗和散热在这个场景下反而次要因为数据中心有充足的供电和制冷能力。成本方面要算每美元算力而不是单卡价格。5.2 边缘推理场景功耗与体积决定成败边缘场景的约束条件最多功耗通常限制在几瓦到几十瓦体积受限于设备外壳散热往往只能被动。选型时优先看能效比每瓦算力而不是绝对算力。另外要关注接口的丰富程度边缘设备通常需要连接摄像头、传感器、执行器等多种外设。软件栈的轻量化也很重要完整的训练框架在边缘设备上跑不动需要专门的推理运行时。5.3 移动端与嵌入式场景极致功耗优化移动端和嵌入式场景对功耗的要求最苛刻通常以毫瓦为单位计算。这个场景下专用加速器NPU、DSP往往比通用GPU更合适因为它们在特定算子上的能效比高得多。选型时要关注是否支持目标模型的算子、量化工具链是否完善、内存占用是否够小、是否支持动态电压频率调整。另外要考虑芯片的封装尺寸移动设备对PCB面积非常敏感。5.4 多模态与大模型端侧部署内存容量是硬门槛多模态模型和大语言模型的端侧部署是近期的热点这类场景最大的瓶颈是内存容量。一个多模态模型可能同时包含视觉编码器和语言模型参数量叠加后对内存的需求很大。选型时首先要算清楚模型权重加KV Cache的总内存需求然后找内存容量满足且带宽足够的硬件。如果单芯片内存不够可以考虑多芯片方案或者模型分片加载但这会带来额外的复杂度和延迟。6. 我个人的选型心得与避坑清单做了这么多年的AI硬件选型我总结了几条血泪教训。第一条不要迷信峰值参数。厂商PPT上的数字是在理想条件下测出来的实际使用中能发挥出六七成就很不错了。评估时多参考第三方实测数据或者自己搭环境实测。第二条软件生态的权重至少占四成。硬件参数再漂亮软件跑不起来就是砖头。我宁愿选一个算力稍低但生态成熟的平台也不选算力高但需要大量适配工作的平台。时间成本比硬件成本贵得多。第三条功耗和散热要在选型阶段就做计算。不要等打样回来发现烫手再想办法那时候改设计的代价很大。一个简单的热阻计算就能避免很多麻烦。第四条永远准备备选方案。AI芯片市场变化快缺货、停产、涨价都是常事。主选方案之外至少准备一个软件栈兼容的备选方案确保供应链出问题时能快速切换。第五条跟供应商的技术支持团队建立直接联系。文档和社区能解决大部分问题但遇到深层次的bug或性能问题厂商的支持团队能帮你省下大量时间。选型时把技术支持响应速度作为一个评估项。第六条小批量验证后再批量采购。不管参数表多好看先买几片样品实际跑一跑。验证通过后再下批量订单避免批量采购后发现问题的尴尬。第七条关注芯片的生命周期。AI硬件迭代快选型时要问清楚厂商的长期供货承诺和停产通知周期。如果一款芯片两年后就停产你的产品维护会非常被动。最后分享一个我常用的快速评估方法拿到一款候选硬件后用半天时间做三件事——跑一个标准模型看推理速度测满载功耗和温度走一遍模型转换流程。这三件事做完这款硬件适不适合你的项目心里基本就有数了。这个方法帮我快速排除了很多看起来很美但实际不行的选项。