1. 算力芯片与推理专用芯片的赛道分野这两年跟做AI基础设施的朋友聊天话题绕来绕去总归会落到同一个问题上训练用什么卡推理用什么卡。前两年大家还习惯性把这两个场景混在一起谈觉得只要算力够大就能通吃但实际跑过大规模业务之后就会发现训练和推理对芯片的要求几乎是两个方向。训练要的是极致算力密度、大显存带宽、卡间互联的吞吐能力推理要的是低延迟、高并发、单位算力成本可控、功耗和散热友好。把这两件事拆开看国产AI厂商的分类推荐才有意义。我先把结论性的判断放在前面算力芯片训练向看的是集群能力和生态成熟度推理专用芯片看的是性价比和部署灵活性。这个判断不是拍脑袋来的是过去一年多我在几个实际项目里踩过坑之后总结出来的。有一次我们试图用一批推理卡去跑一个中等规模的微调任务结果卡在显存带宽上训练一轮的时间比预期多了将近三倍最后只能换回训练卡。反过来用训练卡去跑线上推理服务单次推理成本高得离谱QPS上不去电费账单看着心疼。所以分类推荐这件事本质上是在帮大家少走弯路。国产AI芯片这几年进步确实快从最早的“能用就行”到现在很多场景下“敢用、好用”中间经历了好几轮迭代。但市面上信息比较杂有的厂商宣传口径偏乐观有的参数表看着漂亮实际跑起来打折。我这篇内容想做的事情是把算力芯片和推理专用芯片这两条线分开讲清楚然后按厂商类型做一个相对务实的分类推荐同时把选型时容易忽略的细节、参数背后的真实含义、以及实际部署中的坑都摊开来说。适合正在做AI基础设施选型的工程师、技术负责人也适合刚接触国产AI芯片、想快速建立认知框架的读者。需要提前说明的是芯片行业变化很快具体型号的参数和供货情况随时可能调整我讲的是选型思路和判断维度具体采购时还是要以厂商最新资料和实测数据为准。另外我尽量不堆砌参数表而是把参数和实际场景对应起来讲这样更有参考价值。2. 算力芯片选型的核心判断维度2.1 算力密度与显存带宽的真实关系很多人选训练卡第一眼看的是峰值算力比如多少TFLOPS这个数字确实重要但它不是全部。我见过不少项目在选型时被峰值算力吸引结果实际训练效率上不去问题往往出在显存带宽和卡间互联上。打个比方算力像是发动机的马力显存带宽像是油箱到发动机的油管粗细马力再大油供不上车也跑不快。训练大模型时参数更新需要频繁读写显存带宽不够就会导致算力单元空转等待。具体来说训练向的算力芯片要关注三个层次的指标。第一是单卡算力通常看FP16或BF16下的稠密算力注意是稠密不是稀疏稀疏算力在实际训练中很难跑满。第二是显存容量和带宽显存容量决定了能放多大的模型或batch size带宽决定了数据搬运的速度。第三是卡间互联带宽做数据并行或模型并行时梯度同步的开销直接受互联带宽影响。这三个指标要匹配着看任何一个短板都会成为瓶颈。我个人的经验是如果预算有限优先保证显存容量和互联带宽算力可以适当妥协。因为算力不够可以靠增加卡数来补但显存不够或者互联太慢增加卡数反而会让效率进一步下降。这个判断在多个项目里验证过尤其是参数量超过百亿的模型互联带宽的影响非常明显。2.2 软件生态与框架适配的隐性成本硬件参数之外软件生态是另一个容易被低估的维度。国产算力芯片早期最大的痛点就是生态很多主流框架和算子库适配不完整导致迁移成本很高。现在情况好了很多但不同厂商之间的生态成熟度还是有差距。选型时要重点看几个方面对主流深度学习框架的支持程度、常用算子的覆盖情况、是否有成熟的迁移工具链、社区活跃度和文档质量。这里有个实操建议在正式采购前一定要拿自己真实的模型和训练脚本做一轮迁移测试。不要只看厂商提供的benchmark那些通常是优化过的理想场景。我吃过一次亏某厂商的demo跑得飞快但我们自己的模型迁移过去之后有几个自定义算子没有对应实现只能回退到CPU执行整体速度直接掉了一个数量级。后来花了额外的时间做算子适配项目进度受了影响。所以迁移测试这一步不能省而且要测自己最核心、最复杂的那个模型。另外生态这个东西有网络效应用的人越多问题暴露得越充分修复也越快。选型时可以看看目标厂商在开源社区的存在感以及有没有同行业公司在用。同行的实际使用反馈比任何宣传材料都靠谱。2.3 集群规模扩展的线性度评估训练大模型很少用单卡通常是几十卡甚至上千卡的集群。这时候集群扩展的线性度就成了关键指标。所谓线性度就是卡数翻倍时有效算力能不能接近翻倍。理想情况下是线性的但实际中由于通信开销、调度损耗通常会有衰减。衰减多少直接决定了集群的实际利用率和成本。评估线性度不能只看厂商给的曲线要自己设计测试。我的做法是先用小规模集群跑一个基准任务记录单卡有效算力然后逐步增加卡数观察有效算力的变化曲线。重点关注两个点一是从单机多卡到多机多卡的跨越点这里通信开销会明显上升二是目标规模下的衰减比例比如目标是64卡就重点测32卡到64卡这一段。如果衰减超过30%就要慎重考虑因为这意味着你花了两倍的钱只买到了一点几倍的算力。还有一个容易被忽略的点是故障恢复和容错。大规模集群里单卡故障是常态如果故障恢复机制不完善一次故障可能导致整个训练任务重跑损失的时间成本很高。选型时要了解厂商在容错和断点续训方面的方案成熟度这个在实际运营中比峰值算力更影响整体效率。3. 推理专用芯片的关键指标拆解3.1 延迟、吞吐与并发能力的三角平衡推理场景和训练场景的诉求差异很大最核心的是延迟、吞吐和并发这三个指标的平衡。延迟是单次请求的响应时间吞吐是单位时间能处理的请求数并发是同时能处理的请求数。这三个指标互相制约提高并发通常会增加延迟追求低延迟又可能牺牲吞吐。选型时要先明确自己的业务场景更看重哪个。比如在线交互类应用像对话系统、实时推荐对延迟极其敏感用户等超过一两秒就会流失这时候要优先保证低延迟吞吐可以靠堆机器来补。而离线批处理类任务像批量图片审核、文档分析对延迟不敏感更看重吞吐和成本这时候可以选吞吐优化型的推理卡。我见过有团队用低延迟卡去跑离线批处理成本高得没必要也有团队用高吞吐卡跑在线服务用户体验很差。所以第一步是先把自己的业务场景归类。推理专用芯片通常会在架构上做针对性优化比如支持INT8、INT4等低精度量化用精度换速度和功耗。量化对推理精度的影响需要实际评估有些模型量化后精度损失很小有些则比较明显。建议在选型阶段就用目标模型做量化测试看精度下降是否在可接受范围内。3.2 量化精度与模型压缩的适配性量化是推理专用芯片的核心能力之一但不同芯片对量化方案的支持程度不一样。常见的量化方案有训练后量化PTQ和量化感知训练QAT前者实现简单但精度损失可能较大后者精度保持好但需要重新训练。芯片对这两种方案的支持情况直接影响你能用哪种量化策略。还有一个维度是支持的量化位宽。INT8比较通用大部分推理卡都支持INT4和更低精度则因芯片而异支持得好的话能大幅降低显存占用和功耗但精度风险也更高。我的建议是如果业务对精度要求高优先选INT8支持成熟的芯片如果精度容忍度较高且追求极致成本可以尝试INT4但一定要做充分的精度验证。模型压缩方面剪枝、蒸馏这些技术对芯片的依赖相对小一些但芯片的算子支持情况会影响压缩后模型的执行效率。比如剪枝后产生的稀疏结构如果芯片对稀疏计算支持不好压缩带来的收益就会被抵消。选型时要了解芯片对稀疏计算、动态shape等特性的支持程度。3.3 功耗、散热与部署环境的约束推理服务通常部署规模大功耗和散热的影响会被放大。一张推理卡功耗差几十瓦乘以几百上千张电费和散热成本差距就很可观了。尤其是边缘部署场景功耗和散热往往是硬约束机房条件、供电能力、散热方案都要提前考虑。我参与过一个边缘推理项目部署环境是普通的机柜没有专门的液冷条件。最初选的卡性能很好但功耗偏高机柜温度压不住只能降频运行实际性能打了折扣。后来换成功耗更友好的推理卡虽然峰值性能低一些但能稳定满血运行整体吞吐反而更高。这个教训是选型不能只看峰值性能要看在目标部署环境下的可持续性能。另外推理卡的形态也值得关注比如是标准PCIe卡还是其他形态对服务器兼容性、部署密度都有影响。有些场景下多张小卡比一张大卡更灵活能更好地匹配业务波峰波谷。这些都要结合自己的机房条件和业务特点来权衡。4. 国产AI厂商的分类与推荐思路4.1 全栈型厂商的适用场景国产AI厂商大致可以分成几类第一类是全栈型从芯片到框架到应用都有布局。这类厂商的优势是软硬件协同做得好整体方案成熟度高迁移和部署相对省心。如果你团队规模不大没有太多精力做底层适配或者项目周期紧、希望快速上线全栈型厂商是比较稳妥的选择。全栈型厂商的芯片通常在自家框架上跑得最好但迁移到其他框架时可能会有性能损失。选型时要确认你的技术栈和厂商生态的匹配度。如果你的团队已经深度绑定某个框架就要重点评估跨框架的兼容性。我接触过一些团队因为框架不匹配用全栈方案反而比用通用方案更折腾这就得不偿失了。这类厂商的另一个特点是服务支持相对完善有问题能找到人解决。对于缺乏底层经验的团队来说这个价值不小。但也要注意全栈方案可能带来一定的锁定效应后续想换供应商的成本会比较高。所以初期选型时要考虑长期的技术自主性。4.2 专用型厂商的差异化优势第二类是专用型厂商聚焦在推理或者某个特定场景把单点做到极致。这类厂商的推理专用芯片往往在性价比、功耗、延迟等某个维度上有明显优势。如果你的业务场景明确、需求聚焦专用型厂商的产品可能比通用方案更合适。专用型厂商的挑战在于生态相对窄适配工作需要自己做更多。但如果你的模型相对标准用的都是常见算子适配成本其实可控。我见过一些团队用专用推理卡跑标准化的CV模型迁移很顺利成本比通用方案低不少。关键是要提前做好适配评估别等到部署阶段才发现问题。这类厂商的迭代速度通常比较快能针对特定场景快速优化。如果你的业务场景比较特殊通用方案覆盖不好可以看看有没有专用型厂商在做类似方向。不过也要注意厂商的持续经营能力芯片是个长周期生意选型时要考虑供应商的长期稳定性。4.3 云厂商自研芯片的整合价值第三类是云厂商自研的芯片这类芯片通常和云服务深度整合按需使用、弹性伸缩省去了自己采购和运维的麻烦。对于业务波动大、不想在基础设施上投入太多精力的团队云上方案很有吸引力。尤其是初创团队前期用云上算力快速验证跑通之后再考虑自建是比较务实的路径。云厂商自研芯片的优势是整合度高和存储、网络、调度系统协同优化整体效率往往比自建集群好。但灵活性和自主性会受一些限制比如只能用云厂商提供的实例规格不能完全按自己需求定制。另外长期来看云上单位算力成本通常高于自建业务规模大了之后要算一笔总账。我的建议是早期用云上方案快速起步同时保持对自建方案的评估。当业务量稳定、算力需求可预测之后再考虑混合部署或者自建把核心业务放在自建集群上弹性部分继续用云。这样兼顾了灵活性和成本。5. 实操选型流程与验证方法5.1 需求梳理与场景归类选型第一步不是看芯片而是梳理自己的需求。我通常会让团队先回答几个问题模型规模多大、训练还是推理为主、延迟和吞吐哪个优先、部署环境有什么约束、预算范围多少、团队技术栈是什么。把这些理清楚选型范围就能缩小一大半。需求梳理时容易犯的错是把需求定得太宽泛比如“要性能好、要便宜、要生态好”这种需求没法指导选型。要把需求量化比如“推理延迟P99小于100毫秒、单卡吞吐不低于多少、功耗不超过多少瓦”。量化之后不同方案的优劣就一目了然了。场景归类也很重要。训练场景、在线推理、离线推理、边缘推理对芯片的要求差异很大。先把场景定下来再去找对应类型的芯片比漫无目的地比较参数高效得多。我一般会做一个简单的需求矩阵把各个维度的权重标出来然后给候选方案打分这样决策更客观。5.2 小规模POC测试的设计要点需求明确之后下一步是做POC测试。POC不要贪大用小规模集群跑真实业务负载就行。关键是测试用例要贴近实际用自己真实的模型和数据不要用厂商提供的demo。测试指标要提前定好包括有效算力、延迟分布、吞吐、功耗、稳定性等。POC测试有几个细节要注意。一是测试时间要足够长至少跑满一个完整的业务周期观察有没有性能抖动或者内存泄漏。二是要测异常场景比如单卡故障、网络抖动时的表现。三是要记录迁移成本包括人力投入和时间投入这部分隐性成本很容易被忽略。我做过的一个POC芯片性能达标但迁移过程中发现几个关键算子需要自己实现额外花了两周时间。如果只看性能数据这个方案是合格的但算上迁移成本性价比就下降了。所以POC报告里一定要包含迁移成本评估。5.3 总拥有成本的计算模型选型最终要落到成本上但成本不只是采购价格。总拥有成本包括硬件采购、机房改造、电力、散热、运维人力、迁移适配、后续升级等。我一般会做一个三年期的成本模型把各项成本折算进去这样比较才有意义。硬件采购只是冰山一角电力和散热在推理场景下占比很高。以一张功耗300瓦的卡为例一千张卡一年电费就是一笔不小的数目再加上散热实际成本可能比采购价还高。所以功耗指标在推理选型中的权重应该更高。迁移适配成本也要算进去。如果迁移需要投入大量人力这部分成本可能超过硬件差价。我见过为了省硬件钱选了迁移成本高的方案最后总成本反而更高的案例。所以成本模型要全面不能只盯着采购价。6. 常见问题与避坑经验实录6.1 参数虚标与实测差距的识别芯片参数虚标是个老问题尤其是峰值算力很多是在理想条件下测出来的实际跑业务根本达不到。识别方法很简单就是自己实测。实测时要注意测试条件比如batch size、精度、是否开启特定优化这些都会影响结果。厂商给的参数只能作为参考实际性能以自己测试为准。还有一个坑是“理论支持”和“实际可用”的差距。比如某芯片理论支持某个算子但实际使用时发现性能很差或者有bug。这种情况在国产芯片早期比较常见现在好一些但仍有。应对方法是POC阶段尽量覆盖自己用到的所有算子别留死角。6.2 供货周期与长期维护的考量芯片供货周期是个现实问题尤其是需求旺盛的时候交期可能很长。选型时要了解厂商的产能和供货情况别等到部署时才发现拿不到货。另外要关注厂商的长期维护承诺包括驱动更新、算子库迭代、bug修复等。芯片是个长周期投入选一个能长期陪伴的供应商很重要。我建议在合同里明确供货周期和维护条款把关键承诺落到纸面上。同时保持对备选方案的关注避免单一供应商依赖。技术路线变化快保持一定的灵活性对长期发展有利。6.3 生态锁定风险的规避策略生态锁定是选型时要警惕的风险。用了某家的芯片和框架后续想迁移到别家成本可能很高。规避策略是尽量用标准化的接口和框架把业务逻辑和底层硬件解耦。比如用ONNX等中间格式做模型转换用标准化的推理服务框架这样换硬件时迁移成本会低很多。另外不要把鸡蛋放在一个篮子里。核心业务可以用一家边缘业务用另一家保持对多家方案的了解和测试。这样既能享受单一方案的深度优化又能保持技术选择的灵活性。我见过一些团队因为深度绑定一家后续议价和升级都很被动这个教训值得吸取。常见问题排查思路解决建议实测性能远低于标称检查测试条件是否一致确认精度和batch size用真实业务负载重新测试与厂商确认优化配置算子不支持或性能差梳理模型用到的算子清单逐个验证提前做算子适配或选择算子覆盖更全的方案集群扩展效率低测试不同规模下的有效算力曲线优化通信配置或调整并行策略推理延迟波动大检查是否有资源争抢、散热降频隔离资源改善散热设置合理的并发上限迁移成本超预期记录迁移各环节的人力时间投入优先选生态成熟方案预留迁移缓冲时间最后分享一个我自己的习惯每次选型都会建一个决策日志把候选方案、测试数据、决策理由、后续观察点都记下来。过半年回头看能验证当初的判断对不对也能为下一次选型积累经验。芯片选型没有一劳永逸的答案业务在变技术在变保持记录和复盘的习惯比任何一次选型决策都重要。