1. 国产AI芯片选型的底层逻辑与决策框架1.1 为什么“只看算力参数”是最容易踩的坑过去大半年我帮三个团队做过国产AI芯片的选型评估发现一个高度一致的现象大家第一反应都是拉一张表把各家芯片的峰值算力、显存带宽、制程工艺列出来横向对比然后挑数字最大的那个。这个思路在消费级显卡上或许行得通但在国产AI芯片的选型场景里几乎必然翻车。原因不复杂。国产AI芯片的生态成熟度和英伟达不在一个阶段峰值算力只是纸面参数真正决定你能不能把模型跑起来、跑得稳、跑得划算的是模型适配度、软件栈完整度、集群互联能力、交付运维体系这一整套东西。我见过太多案例某款芯片标称算力很漂亮结果团队拿到手发现主流开源模型跑不通算子缺了一大半最后项目延期两个月只能换方案重来。所以选型的第一原则是先看能不能用再看快不快最后看贵不贵。这个顺序不能颠倒。下面这张表是我在实际评估中常用的六项核查维度后面几个章节会逐项展开。核查维度核心问题权重建议模型适配目标模型能否直接跑通精度损失多少30%软件栈成熟度框架支持、算子覆盖、调试工具是否齐全20%集群互联多卡多机扩展效率如何通信库是否自研15%交付形态整机、板卡还是云服务是否含运维15%成本结构采购成本、功耗、迁移人力成本10%供应与支持产能稳定性、原厂响应速度、社区活跃度10%注意权重不是固定的如果你的场景是推理为主、模型固定模型适配的权重可以更高如果是训练为主、模型迭代快软件栈和集群互联的权重就要往上提。1.2 从“模型适配”倒推芯片选型的方法论我习惯用“倒推法”来做选型先锁定你要跑的模型清单再去看哪些芯片能覆盖这些模型最后在能覆盖的芯片里比性能和成本。这个顺序和很多人习惯的“先选芯片再想办法适配模型”正好相反但实测下来效率高得多。具体操作分三步。第一步列出你的模型清单包括基座模型、微调模型、以及未来半年可能引入的新模型。第二步对每个模型标注关键需求参数量、上下文长度、是否用MoE架构、是否依赖特定算子比如FlashAttention、RoPE变体。第三步拿着这份清单去和芯片厂商或代理商做POC测试重点看三件事能不能直接跑通、精度对齐结果如何、性能是否达标。这里有个经验不要只看厂商给的“已适配模型列表”那个列表往往是在理想环境下测出来的。你要自己准备一个“压力测试集”包含你最关心的两三个模型以及一些边界情况比如超长上下文、batch size拉满。我一般会要求厂商提供至少一周的测试环境自己动手跑一遍而不是只看他们的演示。1.3 集群交付为什么是选型的“最后一公里”单卡性能再好如果集群交付环节掉链子整个项目照样推不动。国产AI芯片的集群交付和英伟达生态有个显著差异很多厂商的互联方案是自研的不是标准NVLink或InfiniBand。这意味着你在做多机多卡扩展时通信库、拓扑结构、故障恢复机制都可能是厂商私有的通用性和可移植性会打折扣。我经历过一个典型案例某团队选了某款芯片做训练集群单机8卡测试时扩展效率能到0.85看起来不错。但扩展到4机32卡时效率直接掉到0.4排查发现是跨机通信走了以太网而厂商的通信库对以太网的优化很有限。最后只能缩减集群规模或者加钱上厂商推荐的高速互联方案。这个坑如果在选型阶段就核查清楚完全可以避免。所以集群交付核查的核心是问清楚互联方案是什么、扩展效率曲线长什么样、故障恢复要多久、有没有实际交付案例。最好能要到同规模集群的实测数据而不是单机数据。2. 模型适配的六项核查实操指南2.1 核查一框架与算子覆盖度怎么测框架支持是模型适配的第一道门槛。目前国产AI芯片对主流框架的支持情况大致分三档第一档是原生支持PyTorch和TensorFlow算子覆盖度高基本不用改代码第二档是需要通过厂商提供的转换工具做模型迁移部分算子需要重写第三档是只支持厂商自研框架迁移成本极高。我一般会用一个“最小可行测试”来快速判断框架支持水平拿一个标准的ResNet-50和一个7B参数的语言模型分别在目标芯片上跑训练和推理记录需要修改的代码行数、缺失的算子数量、以及精度偏差。如果ResNet-50都需要改代码才能跑通那这个芯片的框架支持基本不用考虑了。算子覆盖度有个容易被忽略的点训练和推理的算子需求不一样。推理场景下很多芯片对常见算子的支持都不错但训练场景下反向传播涉及的算子更多、更复杂有些芯片的正向算子齐全反向算子却缺了不少。所以如果你的场景是训练一定要单独测反向传播的算子覆盖。2.2 核查二精度对齐的实操方法与容忍标准精度对齐是模型适配里最耗时间、也最容易扯皮的环节。我的做法是分三层来测第一层是单算子精度第二层是单层精度第三层是端到端精度。三层都对齐了才能说这个芯片的精度是可接受的。单算子精度测试相对简单用厂商提供的测试工具跑一遍就行。单层精度需要你自己构造测试用例重点测那些对精度敏感的层比如LayerNorm、Softmax、以及注意力机制里的矩阵乘。端到端精度最直观直接拿你的业务模型跑一批真实数据对比输出结果的差异。容忍标准方面我的经验是分类任务Top-1精度偏差不超过0.5%生成任务BLEU或ROUGE偏差不超过1%基本可以接受。如果偏差超过这个范围就要排查是算子实现问题还是量化策略问题。有些芯片默认开启INT8量化精度损失会比较大这时候可以要求厂商提供FP16或BF16的选项。提示精度对齐测试一定要用你自己的业务数据不要用公开数据集。公开数据集上的精度表现往往比真实业务数据好因为公开数据集的分布更规范。2.3 核查三迁移成本怎么量化评估迁移成本是选型决策里最容易被低估的一块。很多团队只算了芯片采购成本没算迁移的人力成本和时间成本结果项目做完一算总账发现比用成熟方案还贵。量化迁移成本我一般从四个维度来估代码修改量、调试时间、性能调优时间、以及后续维护成本。代码修改量可以用“需要改动的代码行数占总行数的比例”来估经验值是低于5%算低5%到20%算中等超过20%算高。调试时间取决于厂商工具链的完善程度工具链好的话一周内能搞定工具链差的话一个月都未必能跑通。性能调优时间是最难估的。国产AI芯片的性能调优往往需要厂商原厂支持因为很多底层细节不公开。我一般会要求厂商承诺“性能调优支持时长”比如“保证在X人天内达到Y%的峰值性能”。这个承诺要写进合同不然项目后期很容易扯皮。2.4 核查四软件栈成熟度的五个观察点软件栈成熟度是个比较虚的概念我把它拆成五个可观察的点文档质量、调试工具、性能分析工具、社区活跃度、以及版本迭代频率。文档质量看两点一是API文档是否完整二是是否有端到端的示例代码。调试工具看是否支持断点调试、是否能看到中间层输出。性能分析工具看是否能定位到算子级别的耗时。社区活跃度看官方论坛或技术群的响应速度。版本迭代频率看厂商是否在持续投入而不是发完一代产品就不管了。这五个点里我最看重的是性能分析工具。因为国产AI芯片的性能调优高度依赖厂商工具如果工具不好用调优就是盲人摸象。我一般会要求厂商现场演示性能分析工具的使用看能不能快速定位到一个性能瓶颈。2.5 核查五集群互联方案的实测要点集群互联的实测我一般分三步走第一步测单机多卡第二步测多机多卡第三步测故障恢复。单机多卡测的是卡间通信效率重点看AllReduce、AllGather这些集合通信操作的带宽和延迟。多机多卡测的是跨机通信效率重点看扩展效率曲线是否线性。故障恢复测的是集群的鲁棒性重点看单卡故障后能否自动隔离、训练能否从checkpoint恢复。实测时有个技巧用你实际的模型和数据集来测不要用厂商提供的基准测试。厂商的基准测试往往是在最优配置下跑的和你的实际场景可能有很大差异。我一般会要求厂商提供至少两天的集群测试时间自己跑一遍完整的训练流程。2.6 核查六交付形态与运维支持的谈判要点交付形态分三种整机交付、板卡交付、云服务交付。整机交付最省心但灵活性差板卡交付最灵活但需要自己集成云服务交付最轻量但长期成本可能更高。我一般建议如果是长期稳定的训练任务选整机交付如果是短期或实验性任务选云服务交付如果有自己的服务器团队选板卡交付。运维支持的谈判要点有三个一是响应时间二是备件供应三是固件升级。响应时间要写进合同比如“4小时内响应24小时内到场”。备件供应要问清楚备件库的位置和备件覆盖率。固件升级要问清楚升级频率和升级方式有些厂商的固件升级需要停机这个要提前规划。3. 从单卡测试到集群交付的完整实操流程3.1 单卡基准测试的环境搭建与参数配置单卡测试是整个评估流程的起点目的是摸清芯片的基础性能底子。我一般会搭建一个标准化的测试环境包含以下组件操作系统Ubuntu 20.04或22.04这是国产AI芯片支持最好的版本驱动与固件用厂商推荐的最新稳定版不要用beta版框架版本PyTorch 2.0以上配合厂商提供的适配插件测试模型ResNet-50视觉、BERT-baseNLP、以及一个7B参数的语言模型测试参数方面我一般会跑三组batch size1延迟测试、batch size32吞吐测试、batch size256显存压力测试。每组跑100次迭代取稳定后的平均值。测试指标包括单次迭代耗时、吞吐量samples/sec、显存占用、功耗。这里有个细节一定要记录功耗。国产AI芯片的功耗差异很大有些芯片峰值算力高但功耗也高实际能效比未必好。我一般会算一个“每瓦性能”指标作为成本评估的参考。3.2 多机多卡扩展的效率曲线怎么画多机多卡扩展测试的目的是看集群的扩展效率。我一般会从1机1卡开始逐步扩展到1机8卡、2机16卡、4机32卡记录每个规模下的吞吐量然后画一条扩展效率曲线。扩展效率的计算公式是扩展效率 实际吞吐量 / (单卡吞吐量 × 卡数)。理想情况下扩展效率应该接近1但实际中会随着规模增大而下降。我的经验是8卡以内扩展效率应该在0.8以上32卡以内应该在0.6以上超过32卡能到0.5就算不错了。如果扩展效率下降太快就要排查通信瓶颈。排查方法是用厂商提供的通信分析工具看AllReduce操作的耗时占比。如果通信耗时占比超过30%说明通信是瓶颈需要考虑优化通信策略或换互联方案。3.3 集群交付的验收清单与测试用例集群交付验收是最后一道关卡也是最容易出问题的环节。我一般会准备一份验收清单包含以下项目验收项目测试方法通过标准硬件完整性逐卡检查型号、序列号、固件版本与合同一致网络连通性跑一遍全集群的ping和带宽测试延迟1ms带宽达标集合通信跑AllReduce、AllGather基准测试带宽达到理论值的70%以上训练稳定性跑24小时连续训练无中断、无精度异常故障恢复模拟单卡故障看恢复时间30分钟内恢复性能达标跑实际业务模型达到合同承诺的性能验收测试一定要在厂商工程师在场的情况下做测试结果双方签字确认。我见过太多案例验收时没测仔细上线后出问题厂商不认账最后只能自己扛。3.4 性能调优的常见手段与效果对比性能调优是集群交付后的持续工作。国产AI芯片的性能调优手段主要有四种算子融合、混合精度、通信优化、以及批处理优化。算子融合是把多个小算子合并成一个大算子减少kernel launch开销。混合精度是用FP16或BF16替代FP32提升计算吞吐。通信优化是调整AllReduce的策略比如用ring allreduce替代tree allreduce。批处理优化是调整batch size和梯度累积步数平衡显存和吞吐。这四种手段的效果差异很大。我实测下来算子融合一般能提升10%到20%混合精度能提升30%到50%通信优化能提升5%到15%批处理优化能提升10%到30%。具体效果取决于模型和硬件配置需要逐个试。注意混合精度虽然提升明显但精度损失也最大。如果业务对精度敏感建议先用FP16试不行再退回FP32。4. 常见问题排查与避坑经验实录4.1 模型跑不通的五大原因与排查顺序模型跑不通是选型阶段最常见的问题。我总结下来原因主要有五类算子缺失、框架版本不匹配、驱动固件版本不对、显存不足、以及权限配置问题。排查顺序我一般是这样先看报错信息如果是“算子未实现”那就是算子缺失如果是“版本不兼容”那就是框架或驱动问题如果是“显存溢出”那就是显存不足如果是“权限拒绝”那就是权限配置问题。算子缺失的解决办法是找厂商要补丁或者自己用CPU实现一个fallback。框架版本不匹配的解决办法是查厂商的兼容性矩阵换到推荐的版本组合。驱动固件版本不对的解决办法是重装驱动注意要按厂商文档的顺序装。显存不足的解决办法是减小batch size或开启梯度检查点。权限配置问题的解决办法是检查用户组和udev规则。4.2 精度异常的定位思路与修复案例精度异常比跑不通更隐蔽也更难排查。我遇到过一个案例某模型在国产芯片上跑推理输出结果和GPU上差异很大排查了两周才发现是LayerNorm算子的实现有bug厂商在最新固件里修复了。精度异常的定位思路是先定位到层再定位到算子最后定位到实现。具体做法是逐层对比输出找到第一个出现显著差异的层然后在这个层里逐个算子对比找到有问题的算子最后看这个算子的实现是否有已知问题。修复案例方面我遇到过三种典型情况一是算子实现有bug需要厂商修复二是量化策略过于激进需要调整量化配置三是数值精度不够需要开启FP32累加。这三种情况的修复难度依次降低第一种最麻烦因为要等厂商发版。4.3 集群训练中断的应急处理流程集群训练中断是运维阶段最头疼的问题。我一般会准备一个应急处理流程包含以下步骤立即保存现场保留日志、保留checkpoint、保留故障节点的状态快速定位故障节点用厂商提供的健康检查工具或者自己写脚本逐节点检查隔离故障节点把故障节点从集群里摘除让训练继续恢复训练从最近的checkpoint恢复注意要调整学习率事后分析分析故障原因更新运维手册这个流程的关键是快速隔离。我见过太多案例故障发生后团队花几个小时排查原因训练一直停着损失了大量算力。正确的做法是先隔离、先恢复再慢慢分析原因。4.4 选型决策的常见误区与纠正建议最后说说选型决策的常见误区。我总结下来有四个唯算力论、唯价格论、唯厂商论、以及唯案例论。唯算力论是只看峰值算力忽略实际可用算力。纠正建议是看实测性能不看纸面参数。唯价格论是只看采购价格忽略迁移和运维成本。纠正建议是算总拥有成本不只看采购价。唯厂商论是只看厂商品牌忽略具体产品。纠正建议是看具体型号的实测表现不看厂商光环。唯案例论是只看别人用了什么忽略自己的实际需求。纠正建议是先明确自己的需求再参考别人的案例。这四个误区里唯算力论和唯价格论最常见也最容易造成损失。我的建议是选型前先做需求分析明确自己的模型清单、性能要求、预算范围、以及时间窗口然后按六项核查维度逐项评估最后做决策。不要跳过需求分析直接看产品那样很容易被厂商的销售话术带偏。我在实际选型中还有一个体会不要追求“最好”的芯片要追求“最合适”的芯片。国产AI芯片各有优劣有的擅长推理有的擅长训练有的生态好有的性价比高。关键是找到和你需求最匹配的那一款而不是盲目追求参数最高的那一款。踩过几次坑之后我现在选型都会留一个“备选方案”万一主方案出问题能快速切换不至于项目停摆。