1. 选型之前先想清楚你到底在为什么场景买卡国产AI芯片这个话题过去两年我从各种角度被问过不下几十次。有人拿着一个开源模型想跑推理有人要搭一个几十张卡的小集群做微调还有人只是想把现有业务从进口卡上迁一部分出来做备份。这三种需求对应的选型逻辑完全不同但绝大多数人上来第一句话就是哪家芯片性能强这恰恰是最容易踩坑的问法。我先把结论摆在前面国产AI芯片选型的本质不是比峰值算力而是比你的模型能不能在上面跑起来、跑得稳、跑得划算。峰值算力是最容易拿到的数字也是最容易误导人的数字。一张卡标称多少TFLOPS和你的Transformer模型在上面实际能跑到多少tokens/s中间隔着编译器、算子库、显存带宽、互联拓扑四道坎。所以这篇文章我不打算给你一个推荐清单那种东西三个月就过期。我想给你一套核查框架——六项核查从模型适配一路查到集群交付。你拿着这套框架去和任何一家厂商聊都能问出真东西而不是被一堆跑分截图带着走。先说清楚适用人群如果你只是个人开发者想买一张卡玩玩这篇文章可能偏重了你更需要的是看社区里有没有人跑通你的模型如果你是企业里负责算力选型、模型部署、集群建设的工程师或技术负责人那这六项核查基本覆盖了你从POC到上线的全流程。关键词里的模型适配集群交付算力约束这几个词我会在对应章节里逐个拆开讲。还有一个前置认知必须建立国产AI芯片不是一个统一品类而是几条技术路线并存。有走通用GPGPU路线的有走专用加速器路线的有从训练切入的有从推理切入的。它们的软件栈成熟度、算子覆盖度、生态兼容性差异极大。你拿A家的经验去套B家大概率翻车。所以下面的每一项核查我都会告诉你为什么这项重要以及怎么问才能问出真相。2. 核查一模型适配度——别信支持主流模型这句话2.1 为什么模型适配是第一道生死线买卡的第一步不是看硬件参数是看你的模型能不能在上面跑。这句话听起来像废话但我见过太多团队在硬件选型会上讨论了半天互联带宽和显存容量最后发现目标模型里的某个注意力变体在候选卡上没有对应算子实现整个方案推倒重来。模型适配度这件事厂商的销售材料里通常写一句支持主流大模型这句话的信息量约等于零。因为主流是个模糊词而你的模型可能恰恰不在他们的主流清单里。真正要核查的是三个层次框架层、算子层、精度层。框架层指的是你的训练或推理框架能不能对接上。PyTorch是大头但很多国产芯片对PyTorch的支持是通过一个适配层做的这个适配层的版本跟进速度直接决定了你能不能用上新特性。比如你的代码用了较新的PyTorch版本里的某个API而适配层还停留在旧版本那就得改代码。改代码这件事在POC阶段无所谓在上线阶段就是工期风险。算子层是最容易出问题的地方。Transformer本身的结构算子就那么些但现在的模型为了追求效果各种变体层出不穷。注意力机制有标准多头、有多查询、有分组查询还有各种位置编码的变体。激活函数从ReLU换到SwiGLU再到各种门控变体。归一化从LayerNorm到RMSNorm。这些算子在通用GPU上有成熟的CUDA实现但在国产芯片上每一个都需要厂商的算子库里有对应的高性能实现。没有实现怎么办要么回退到慢速的通用实现性能直接掉一个数量级要么你自己写那成本就不可控了。精度层是最近越来越重要的一环。现在模型训练和推理普遍用混合精度BF16、FP16、FP8各有各的用法。国产芯片对每种精度的支持程度不一样有的卡BF16性能很好但FP8支持不完整有的卡FP16没问题但BF16是模拟出来的。你的模型如果强依赖某种精度这一项就必须提前确认。2.2 怎么问才能问出真实的适配情况我总结了一套问法比你们支持XX模型吗有效得多请给我一份你们算子库的算子清单我对照我的模型结构逐个核对。这句话一出口对方就知道你是懂行的。算子清单是硬指标有没有一目了然。我的模型用了XX注意力变体和XX归一化你们有没有对应的融合算子注意问的是融合算子不是能不能实现。能实现和能高性能实现是两回事。如果某个算子没有实现你们的回退方案是什么性能损失大概多少这个问题能逼出真实情况。负责任的厂商会告诉你哪些算子还在补齐不负责任的会说都能支持。能不能给我一个测试环境我把我的模型跑一遍这是终极核查手段。任何口头承诺都不如你自己跑一遍。POC环境是必须争取的不给测试环境的厂商直接排除。提示POC阶段一定要用你自己的真实模型不要用厂商提供的Demo模型。Demo模型是精心调优过的跑得好不代表你的模型跑得好。2.3 一个真实的适配踩坑案例我经手过一个项目模型主体结构很标准但用了一个比较新的旋转位置编码变体。候选芯片A的算子库里有一个旋转位置编码算子名字对得上但实现的是旧版本。结果模型能跑起来loss也能下降但收敛速度比预期慢了很多。排查了两周才发现是位置编码算子的数值行为和预期有细微差异。这种问题最坑因为它不报错只是效果不对。后来我们的做法是在POC阶段不只跑通还要跑一个收敛性对比。用同样的数据、同样的超参在参考实现和候选芯片上各跑一小段对比loss曲线。曲线对得上才算真正适配。这一步多花两三天能省掉后面两周的排查。3. 核查二算力真实性——峰值数字背后的三个折扣3.1 峰值算力为什么不能直接信每张卡的规格书上都印着一个漂亮的峰值算力数字单位是TFLOPS或者TOPS。这个数字是在理想条件下测出来的特定精度、特定矩阵尺寸、特定数据布局、算子完全融合、没有访存瓶颈。你的真实模型跑起来能拿到峰值的百分之几十就算不错了。我把这个折扣拆成三层你在评估时逐层往下扣第一层折扣精度折扣。规格书上的峰值通常是某种特定精度下的数字。如果标的是INT8的算力而你的模型跑BF16那实际可用算力要按BF16的规格算。有些厂商会把不同精度的峰值混在一起宣传你要看清楚你用的精度对应哪个数字。第二层折扣访存折扣。大模型推理是典型的访存密集型任务尤其是自回归生成阶段每生成一个token都要把整个模型的权重读一遍。这时候瓶颈不在计算单元在显存带宽。一张卡算力再高如果显存带宽跟不上生成速度照样上不去。所以看规格时显存带宽和算力的比值比单独看算力更有意义。这个比值太低说明这张卡更适合计算密集的训练不太适合访存密集的推理。第三层折扣互联折扣。单卡性能再好集群里卡和卡之间通信跟不上整体性能就被拖累。这一点在核查五项里会详细讲这里先记住单卡算力是上限互联能力决定你能拿到多少。3.2 用有效算力代替峰值算力做评估我建议你在评估表里不要填峰值算力填有效算力。有效算力的估算方法是拿你的真实模型在目标卡上跑一个标准benchmark测出实际的tokens/s或者samples/s再反推等效算力利用率。具体操作上我会要求厂商提供三类数据测试项测试内容关注指标单卡推理你的模型固定batch sizetokens/s、首token延迟单卡训练你的模型固定step数samples/s、显存占用多卡扩展2卡、4卡、8卡扩展效率曲线扩展效率曲线特别重要。理想情况下8卡的吞吐应该是单卡的8倍但实际能做到6倍就算不错。如果某家厂商的扩展效率曲线在4卡之后明显掉头说明它的互联方案有瓶颈你上大规模集群时要慎重。3.3 算力约束下的资源配置思路热词里有个算力约束下提升大语言模型能力的资源配置建模这个词很学术但背后的工程问题很实在当你手里的算力有限时怎么分配资源才能让模型效果最好我的经验是分三个优先级第一优先级是保证推理的显存够用。模型权重、KV Cache、中间激活这三块加起来不能超过显存。如果显存不够要么量化要么减batch size要么换更小的模型。量化会损失精度减batch影响吞吐换模型影响效果都是妥协。所以选卡时显存容量要留足余量别卡着线选。第二优先级是保证训练的通信不成为瓶颈。训练时梯度同步是刚需互联带宽不够多卡训练的加速比会很难看。如果预算有限宁可少买几张卡但把互联做好也不要买一堆卡结果通信拖后腿。第三优先级才是追求单卡峰值算力。因为前两项不满足峰值算力根本发挥不出来。这个优先级顺序和很多人的直觉相反但它是被无数项目验证过的。我见过太多集群卡都是好卡但因为互联方案拉胯实际利用率不到三成。4. 核查三软件栈成熟度——决定你后期维护成本的关键4.1 软件栈为什么比硬件更难评估硬件参数是静态的软件栈是动态的。一张卡的算力今天是多少明年还是多少但它的软件栈今天能跑什么明年可能就完全不一样了。这既是机会也是风险机会在于厂商持续投入软件栈会越来越好风险在于你上线时的软件栈如果不够成熟后面每个版本升级都可能带来新的适配工作。评估软件栈成熟度我通常看四个维度编译器成熟度。国产芯片大多有自己的编译器把上层框架的图编译成芯片能执行的指令。编译器的优化能力直接决定性能。评估方法是看它对你模型里那些非标准结构的处理能力。标准结构大家都能编译好差异在边缘情况。算子库覆盖度和更新频率。前面讲过算子覆盖度这里补充一点要看更新频率。新模型新算子层出不穷算子库半年不更新说明厂商投入不足。可以问一句你们算子库最近三个版本都新增了哪些算子从回答里能听出投入力度。调试和 profiling 工具。这一点经常被忽略但极其重要。模型跑得慢你得知道慢在哪。有没有好用的profiling工具能不能看到每个算子的耗时、显存占用、访存效率直接决定你的调优效率。没有profiling工具调优就是盲人摸象。社区和文档。文档质量、示例代码数量、社区活跃度这些软指标反映的是生态健康度。一个文档都写不清楚的厂商你指望它的技术支持能好到哪去4.2 软件栈评估的实操清单我把上面四个维度落成一份可以逐项打分的清单你在POC时对照着过一遍编译器能否编译你的完整模型编译时间多长编译后的性能相比eager模式提升多少算子库你的模型用到的算子覆盖率是多少缺失的算子有没有替代方案算子库版本更新周期是多久工具链有没有profiling工具能不能定位到算子级别有没有显存分析工具文档API文档是否完整有没有针对你这类模型的端到端示例文档更新是否跟得上版本技术支持提issue的响应时间有没有专属的技术支持群遇到算子缺失能不能推动厂商排期这份清单里我最看重的是工具链和技术支持。工具链决定你自己能不能解决问题技术支持决定你解决不了时有没有人帮你。这两项弱后面运维会非常痛苦。4.3 软件栈的版本锁定策略还有一个实操经验上线时一定要锁定软件栈版本。国产芯片的软件栈迭代快新版本可能带来性能提升也可能引入新的兼容性问题。上线环境不要追新用经过验证的稳定版本。升级要单独安排测试周期不要在生产环境直接升。我见过一个团队生产环境自动跟随厂商的最新驱动结果某次驱动更新后某个算子的数值行为变了模型输出出现细微偏差排查了一周才发现是驱动的问题。后来他们把所有环境都做了版本锁定升级走变更流程。这个教训值得所有人记住。5. 核查四集群互联能力——多卡之后才见真章5.1 单卡好不代表集群好单卡测试跑得漂亮一上多卡就原形毕露这是国产芯片集群交付里最常见的翻车场景。原因在于单卡测试只考验计算和访存多卡测试还要考验卡间通信。而卡间通信恰恰是很多国产方案的短板。集群互联要核查三个层面卡内互联、节点内互联、节点间互联。卡内互联指的是芯片内部各个计算单元之间的数据通路这个通常由芯片设计决定你改不了但可以通过benchmark间接评估。节点内互联指的是同一台服务器里多张卡之间的通信。主流方案有几种带宽和延迟差异很大。这一层是集群性能的关键因为大模型训练和推理的通信大部分发生在节点内。节点间互联指的是跨服务器的通信。这一层走网络带宽通常比节点内低一个数量级延迟高一个数量级。所以集群设计的一个核心原则是尽量把通信密集的并行策略放在节点内把通信稀疏的放在节点间。5.2 怎么测互联能力测互联能力我推荐用集合通信benchmark测几个关键操作All-Reduce训练时梯度同步用的最关键的指标。看不同数据量下的带宽和延迟。All-Gather张量并行和序列并行常用。Reduce-Scatter和All-Reduce配合使用。点对点通信流水线并行用。测试时要注意小数据量看延迟大数据量看带宽。很多方案大数据量带宽不错但小数据量延迟很高这会影响那些通信频繁但单次数据量小的场景。还有一个容易被忽略的点通信和计算能不能重叠。理想的集群里卡在通信的同时计算单元不应该闲着。这需要软件栈的支持。评估时可以问厂商你们的通信库支持计算通信重叠吗有没有相关的优化5.3 集群规模化的扩展效率扩展效率是集群交付的核心指标。定义是N卡的实际吞吐除以单卡吞吐再除以N。理想值是100%实际能做到70%到85%就算优秀。扩展效率随规模下降是正常的但下降的斜率很关键。如果从8卡到16卡效率从80%掉到50%说明互联方案在规模化时有瓶颈。这时候你要么接受这个效率要么换方案。我通常会要求厂商提供扩展效率曲线横轴是卡数纵轴是扩展效率。这条曲线比任何单点数据都有说服力。如果厂商拿不出这条曲线或者曲线只到8卡就断了那大规模交付的风险就要自己承担。注意扩展效率的测试必须用你的真实模型和真实并行策略。厂商用他们优化过的模型测出来的曲线参考价值有限。6. 核查五交付与运维——上线才是真正的开始6.1 交付不只是硬件到货很多人把交付理解成硬件到货、上架、通电。这只是交付的起点。真正的交付包括硬件交付、软件交付、模型交付、运维体系交付。硬件交付相对标准化但要注意批次一致性问题。不同批次的卡固件版本、性能表现可能有细微差异。大规模集群里这种差异会被放大。所以交付时要确认固件版本统一并且做全量burn-in测试。软件交付包括驱动、编译器、算子库、通信库、监控工具这一整套。这一套的版本兼容性要提前验证。我见过驱动和通信库版本不匹配导致集群性能减半的案例排查了很久。模型交付指的是你的模型在目标集群上的最终性能表现和稳定性。这一步要在交付前完成验收测试不能等到上线后才发现问题。运维体系交付是最容易被忽略的。监控怎么做告警怎么配故障怎么定位备件怎么管理这些都要在交付阶段就建立起来。6.2 运维阶段的高频问题根据我的经验国产AI集群运维阶段的高频问题集中在几类显存碎片化。长时间运行后显存会出现碎片导致原本能跑的任务跑不起来。解决办法是定期重启服务或者用支持显存池化的方案。算子数值漂移。前面提过某些算子在特定输入下数值行为可能和预期有差异。这类问题隐蔽性强需要建立输出一致性监控。通信超时。大规模集群里网络抖动或某张卡异常都可能导致通信超时。要有完善的超时重试和故障隔离机制。驱动和固件兼容性。升级驱动或固件前一定要在测试环境验证生产环境不要轻易动。6.3 建立自己的验收标准厂商的验收标准是厂商的你要建立自己的。我的建议是至少包含这几项验收项验收方法通过标准单卡性能跑你的模型benchmark达到POC承诺值的90%以上多卡扩展2/4/8卡扩展效率8卡扩展效率不低于70%稳定性72小时连续运行无异常退出、无性能衰减故障恢复模拟单卡故障任务能自动恢复或优雅退出监控覆盖检查监控指标关键指标全覆盖、告警可用这份验收标准要在合同里写清楚验收不通过的处理方式也要写清楚。口头承诺在交付阶段一文不值。7. 核查六生态与长期支持——别买完就成孤儿7.1 生态健康度的判断方法最后一项核查是生态和长期支持。这一项最虚但也最影响你的长期成本。判断方法有几个看厂商的客户案例。不是看它宣传了哪些大客户而是看这些客户有没有持续采购。一次性采购可能是试点持续采购说明真的用起来了。看开源贡献。厂商有没有向主流开源框架提交代码有没有维护自己的开源项目开源贡献是技术投入的硬证据。看社区活跃度。开发者社区的问题响应速度、文档更新频率、版本迭代节奏这些都能反映生态健康度。看路线图。厂商有没有公开的产品路线图路线图是否清晰可信一个没有路线图的厂商你很难判断它明年还在不在。7.2 长期支持要谈进合同长期支持不能只靠信任要谈进合同。关键条款包括软件栈维护周期厂商承诺维护当前软件栈多少年算子补齐承诺新模型新算子的支持响应时间技术支持SLA问题响应时间、解决时间备件供应硬件备件的供应周期迁移支持如果未来要迁移厂商提供什么支持这些条款看起来繁琐但每一条都对应着真实的成本。我见过因为厂商停止维护某个软件栈版本被迫整体迁移的案例成本极高。7.3 多供应商策略最后一个建议不要把所有鸡蛋放在一个篮子里。国产AI芯片还在快速演进期技术路线没有收敛。如果你的业务对算力依赖度高建议至少评估两家供应商关键业务做双栈适配。双栈适配有成本但相比被单一供应商锁定的风险这个成本是值得的。适配层做得好的话切换成本可以控制在可接受范围内。8. 把这六项核查串成一条决策链六项核查讲完了最后说说怎么把它们串起来用。我的做法是做一个加权评分表六项核查各占一定权重根据你的业务场景调整权重。比如如果你的场景是推理为主模型适配度和算力真实性权重高集群互联权重低。如果是训练为主集群互联和软件栈成熟度权重高。如果是长期业务生态和长期支持权重高。每一项核查下面再细分打分项POC阶段逐项打分。最后算总分但总分不是唯一决策依据。任何一项核查出现一票否决级别的问题比如你的核心模型根本跑不起来那总分再高也不能选。这套方法我用了几年帮不少团队避开了选型坑。它不能保证你选到最好的芯片因为最好是个伪命题但它能帮你避开最差的选择并且让你对每个选择的风险心里有数。国产AI芯片这个领域变化很快今天的最佳选择明年可能就不是了。但核查框架是稳定的因为它核查的是本质问题模型能不能跑、算力是不是真的、软件好不好用、集群能不能扩、交付靠不靠谱、生态能不能持续。这六个问题无论技术怎么演进都是选型时必须回答的。我个人在实际操作中的体会是选型过程中最值钱的不是厂商给的跑分数据而是你自己在POC环境里跑出来的真实数据以及和厂商技术团队深入交流时问出的那些不好回答的问题。前者验证能力后者验证诚意。两者都过关这个选择才靠谱。