1. 从57到120一份AI芯片调查背后的选型逻辑去年年底的时候我帮一个做边缘推理的团队整理硬件选型清单。一开始我们只列了57种芯片方案涵盖市面上主流的训练卡、推理卡、嵌入式模组和FPGA加速方案。结果三个月后再更新这个数字直接翻到了120多种。不是我们刻意去凑数而是这个市场本身在快速膨胀——新架构、新封装、新内存方案层出不穷几乎每个月都有新的加速器产品冒出来。这件事让我意识到一个问题选AI芯片这件事早就不是“看算力大小”那么简单了。你打开任何一个芯片厂商的产品页满眼都是TOPS、TFLOPS、带宽、功耗这些数字但真正落到项目里这些数字往往不能直接告诉你“这块卡能不能跑我的模型”“这套方案三年后会不会被淘汰”“同样的预算我到底该选GPU还是FPGA”。这篇文章想聊的就是我从这份调查里梳理出来的选型框架。不管你是刚接触AI硬件的新手还是正在做集群规划的老手我都尽量把“看什么参数”“为什么看这个参数”“什么场景下这个参数不重要”讲清楚。核心关键词就几个AI芯片、加速器、GPU、CPU、FPGA但我会把它们放在具体的选型场景里说而不是干巴巴地列规格表。先说结论性的判断选AI芯片本质上是在选一个“匹配度”——匹配你的模型结构、匹配你的部署环境、匹配你的团队能力、匹配你的预算周期。任何一个维度错配再高的算力数字都是浪费。下面我按这个逻辑一层层拆开讲。2. 先搞清楚你的负载到底吃什么资源2.1 训练和推理是两套完全不同的选型逻辑很多人一上来就问“哪块卡算力最高”这个问题本身就有问题。因为训练和推理对硬件的要求差异极大甚至可以说是两个不同的市场。训练阶段的核心瓶颈通常在显存容量和显存带宽而不是纯算力。为什么因为大模型训练时参数、梯度、优化器状态、激活值都要放在显存里。你算力再高显存装不下模型就得做模型并行或梯度累积通信开销立刻把算力优势吃掉。我见过不少团队买了高算力卡结果因为显存不够batch size只能开到很小GPU利用率长期在30%以下。推理阶段则更看重延迟、吞吐和能效比。同样是跑一个模型云端批量推理和边缘实时推理的要求完全不同。云端可以堆batch来提升吞吐边缘端往往batch1这时候算力利用率、内存访问效率、甚至芯片的调度策略都比峰值算力更重要。所以我在调查表里给每款芯片都打了两个维度的标签训练适配度和推理适配度。有些芯片训练很强但推理性价比低有些芯片推理延迟极低但根本不适合训练。不区分场景直接比算力是选型里最常见的坑。2.2 算力数字背后的三个陷阱第一个陷阱是精度标注不统一。有的厂商标INT8算力有的标FP16算力有的把稀疏算力也标出来。你看到“256 TOPS”和“128 TFLOPS”放在一起根本没法直接比。我的做法是统一换算到同一精度下再对比通常以FP16稠密算力为基准INT8算力除以2作为参考。第二个陷阱是峰值算力和有效算力差距巨大。峰值算力是理论最大值实际能跑到多少取决于内存带宽、互联带宽、编译器优化程度。我一般会看两个指标算力利用率MFU和内存带宽比算力/带宽。如果算力很高但带宽跟不上实际性能会被内存墙卡死。第三个陷阱是互联能力被低估。单卡算力再强多卡训练时如果互联带宽不够扩展效率会断崖式下跌。我在调查表里专门加了一列“互联带宽”包括卡间互联和节点间互联。对于需要多卡并行的场景这一列的重要性甚至超过单卡算力。2.3 内存和带宽最容易被忽视的硬指标显存容量决定了你能跑多大的模型显存带宽决定了你跑得多快。这两个指标在选型时的优先级我认为高于纯算力。举个具体的例子一个7B参数的模型FP16精度下光权重就要14GB左右加上激活值和KV Cache推理时至少需要20GB以上的显存才比较从容。如果你选了一块算力很高但只有16GB显存的卡要么量化到INT8要么做模型切分都会带来额外的工程复杂度。带宽方面我习惯算一个“理论最短推理时间”模型大小除以显存带宽。比如14GB的模型带宽是900GB/s理论最短时间约15.5毫秒。实际推理时间通常是这个数字的2到5倍取决于计算图和调度效率。这个估算方法虽然粗糙但能快速判断一块卡是否适合你的模型规模。2.4 功耗和散热部署环境决定上限功耗这个参数在实验室里可能不重要但到了实际部署环境就是硬约束。边缘设备有功耗墙数据中心有机柜供电和散热上限。我在调查表里把功耗分成了三档低于75W适合边缘无风扇场景75W到300W适合边缘服务器或工作站300W以上必须配主动散热和足够供电。这里有个经验厂商标的TDP通常是最大功耗实际运行功耗取决于负载。但选电源和散热时必须按TDP来留余量一般建议电源余量不低于30%。我见过因为电源余量不足导致训练过程中断电的案例损失的不只是硬件还有几天的训练进度。3. GPU、FPGA、ASIC三条技术路线的取舍3.1 GPU通用性最强但成本也最高GPU目前是AI加速的绝对主力原因很简单生态成熟、通用性强、开发门槛相对低。CUDA生态积累了十几年主流框架对GPU的支持最好遇到问题也最容易找到资料和社区帮助。但GPU的问题也很明显。首先是成本高端训练卡的价格一直居高不下而且往往需要配套的高带宽内存和互联方案整体系统成本更高。其次是功耗高端GPU的TDP动辄300W以上对供电和散热要求很高。最后是供应周期热门型号的交付周期可能长达数月。我的建议是如果你的团队没有很强的硬件定制能力模型结构又可能频繁调整GPU仍然是最稳妥的选择。通用性带来的容错空间在项目早期比算力数字更重要。3.2 FPGA灵活但门槛高适合特定场景FPGA的优势在于可定制数据流和极低延迟。对于某些特定算子比如自定义的量化推理、特殊的卷积结构、或者需要极低延迟的实时处理FPGA可以通过定制流水线实现比GPU更高的能效比。但FPGA的代价是开发周期长、门槛高。你需要有硬件描述语言或高层次综合的经验需要理解时序收敛、资源分配、流水线设计。一个中等复杂度的推理加速器从设计到稳定运行往往需要数月时间。而且FPGA的算力密度通常不如同代GPU不适合大规模并行训练。我在调查表里给FPGA的定位是推理专用、延迟敏感、批量小、模型结构稳定的场景。比如工业质检、医疗影像实时处理、金融风控推理。这些场景下FPGA的能效比和确定性延迟是GPU很难替代的。3.3 ASIC极致能效但灵活性最低ASIC是为特定算法定制的芯片能效比通常最高但一旦流片就无法修改。这类芯片适合算法已经非常稳定、出货量足够大的场景。对于大多数团队来说ASIC不是直接选型的对象而是云服务商或大厂自研的底层硬件。不过现在很多云厂商提供的AI加速实例底层就是自研ASIC。作为用户你不需要直接面对ASIC的开发复杂度但需要了解它的限制算子支持可能不完整自定义模型可能需要适配迁移成本较高。3.4 CPU别忽视它在推理和调度中的角色虽然CPU不是AI加速的主力但在整个系统里扮演着不可替代的角色。数据预处理、后处理、任务调度、小模型推理这些环节往往由CPU完成。如果CPU性能不足会成为整个流水线的瓶颈。我在选型时会关注CPU的单核性能、内存通道数、PCIe通道数。单核性能影响预处理速度内存通道影响数据吞吐PCIe通道数决定了能挂多少加速卡。很多人在选加速卡时只看卡本身忽略了主机CPU和主板是否匹配结果卡插上去跑不满带宽。3.5 三条路线的对比框架维度GPUFPGAASIC通用性高中低开发门槛低高极高能效比中高极高延迟确定性中高高适合场景训练通用推理专用推理大规模固定负载成本结构硬件贵、开发便宜硬件中、开发贵流片贵、量产便宜这张表不是绝对的但能帮你快速判断技术路线。如果你的模型还在快速迭代选GPU如果模型稳定且延迟敏感考虑FPGA如果出货量极大且算法固定才考虑ASIC。4. 选型实操从需求到清单的完整流程4.1 第一步量化你的模型需求在打开任何厂商的产品页之前先把自己的需求量化。我通常会让团队填一张表模型参数量多少B推理精度要求FP16/INT8/INT4目标延迟单次推理多少毫秒目标吞吐每秒多少请求部署环境云端/边缘/终端功耗上限多少瓦预算范围单卡/整机这张表填完很多选项会自动被排除。比如功耗上限75W那300W的卡直接不用看了延迟要求5毫秒以内那大部分云端推理方案都不合适。4.2 第二步算清楚显存和带宽需求显存需求的计算方法模型权重 激活值 KV Cache 框架开销。权重是参数量乘以精度字节数激活值取决于batch size和序列长度KV Cache在长序列推理时可能比权重还大。框架开销一般留2到4GB。带宽需求可以用“模型大小除以目标延迟”来估算。比如14GB的模型目标延迟50毫秒那带宽至少需要280GB/s。实际选型时留2到3倍余量因为有效带宽通常只有峰值的50%到70%。4.3 第三步匹配互联和扩展需求单卡够不够用取决于模型能不能放进单卡显存。放不下就需要多卡多卡就要看互联带宽。卡间互联带宽低于100GB/s时多卡并行的扩展效率会明显下降。节点间互联如果是万兆网络跨节点并行的效率会更低通常只适合数据并行不适合模型并行。我在调查表里专门标注了每款芯片的互联方案NVLink、PCIe、专用互联、以太网。不同方案的实际带宽和延迟差异很大选型时必须和你的并行策略匹配。4.4 第四步评估软件栈和生态这一步最容易被忽视但往往决定项目成败。芯片的软件栈成熟度包括框架支持、算子覆盖、编译器质量、调试工具、社区活跃度。我的评估方法是拿一个你实际要跑的模型在目标芯片上做一次端到端测试。不要只看厂商的benchmark因为那些通常是精心优化过的。自己跑一遍看算子是否都支持精度是否对齐性能是否达标遇到问题有没有文档和社区支持。4.5 第五步算总拥有成本不只看单价总拥有成本包括硬件采购成本、电费、散热成本、机柜空间、运维人力、开发适配成本、迁移成本。有些芯片单价便宜但开发适配成本很高有些芯片单价贵但生态成熟上线速度快。我一般会算一个“三年总成本”把上述所有因素折算进去。对于快速迭代的项目上线时间比硬件差价更重要对于长期稳定的负载能效比和运维成本权重更高。5. 常见问题与排查技巧实录5.1 算力达标但实际推理慢问题出在哪这是最常见的问题。原因通常有三个内存带宽瓶颈、算子未优化、batch size不合适。排查顺序先看显存带宽利用率如果接近峰值但算力利用率很低说明是内存瓶颈再看算子覆盖用profiler看哪些算子耗时最长是否走了低效实现最后调batch size太小浪费算力太大增加延迟。5.2 多卡训练扩展效率低怎么定位先看单卡利用率如果单卡都跑不满多卡肯定更差。然后看互联带宽利用率如果互联带宽接近峰值说明通信是瓶颈。最后看并行策略数据并行、模型并行、流水线并行的通信模式不同需要匹配不同的互联方案。5.3 功耗和散热导致的降频问题高端芯片在散热不足时会主动降频导致性能波动。排查方法是监控运行频率和温度如果频率明显低于标称值说明散热有问题。解决办法包括改善风道、提高风扇转速、降低环境温度、限制功耗墙。5.4 软件栈不兼容导致的部署失败不同芯片对框架版本、算子库、驱动版本的要求不同。部署前一定要在目标环境做完整测试不要假设开发环境能跑通生产环境就一定能跑通。我见过因为驱动版本不匹配导致推理结果错误的案例排查了很久才发现是底层库的问题。5.5 常见问题速查表现象可能原因排查方向算力利用率低内存瓶颈/算子未优化看带宽利用率、profiler多卡扩展差互联瓶颈/并行策略不当看互联带宽、调整并行性能波动大散热降频/功耗墙监控频率和温度部署失败软件栈不兼容检查驱动、框架、算子版本精度不达标量化误差/算子实现差异对比FP32基线、逐层排查6. 一些实操心得和避坑建议6.1 不要追求最新要追求最稳芯片行业迭代很快但最新发布的芯片往往驱动和软件栈不够成熟。我一般建议等产品发布后至少半年等驱动稳定、框架适配完善、社区反馈充分后再考虑。早期采用者可能拿到更高的峰值性能但也可能踩到更多的坑。6.2 先租后买降低试错成本现在很多云平台提供按小时计费的加速实例。在决定大规模采购之前先租用目标芯片跑一遍实际负载验证性能、兼容性和稳定性。这个环节花的时间和小钱能避免后期的大损失。6.3 留足电源和散热的余量电源余量建议不低于30%散热余量建议不低于20%。不要按标称TDP刚好配电源因为瞬时功耗可能超过TDP。散热方面如果环境温度可能超过35度需要额外留余量。6.4 关注供应链和生命周期芯片的供应周期和生命周期直接影响项目规划。有些芯片可能在你项目上线后不久就停产导致后续扩容困难。选型时尽量选择供应稳定、生命周期长的产品或者提前做好替代方案。6.5 软件适配成本要提前算如果团队之前只用过某一家的芯片迁移到另一家需要重新学习工具链、调试方法、优化技巧。这个学习成本往往被低估。我在评估时会问团队有没有相关经验如果没有预留多少时间做适配6.6 建立自己的测试基准不要完全依赖厂商的benchmark。建立一套自己的测试基准包含你实际要跑的模型和真实数据。这套基准不仅能用于选型还能用于后续的性能监控和优化效果评估。6.7 关注总拥有成本而非单价最后再强调一次芯片单价只是总成本的一部分。电费、散热、运维、开发适配、迁移成本都要算进去。对于长期运行的负载能效比的影响可能超过硬件差价。7. 从120种回到3种收敛选型的方法调查表从57种扩展到120多种但最终落到具体项目上通常只会收敛到2到3种方案。收敛的过程就是不断用实际约束去过滤功耗上限过滤掉一批显存容量过滤掉一批软件栈兼容性过滤掉一批预算范围过滤掉一批供应链稳定性过滤掉一批剩下的选项再通过实际测试做最终决策。选型不是找“最好”的芯片而是找“最匹配”的芯片。匹配度越高后期踩坑越少。我在实际项目中的体会是花在选型上的时间永远比花在后期补救上的时间值得。一份详细的调查表加上实际测试验证能帮你避开大部分常见的坑。芯片市场还在快速变化这份调查表也需要持续更新但选型的底层逻辑——匹配需求、验证实际、算清总账——是不会变的。
