国产AI芯片选型六项核查：从模型适配到五年TCO

发布时间：2026/11/2 3:38:14

最近帮一家做行业大模型的朋友做国产AI芯片选型，从模型适配一路测到集群交付，前后折腾了三个多月。这个过程的收获比我想象中大得多：国产AI芯片这两年已经不是“能不能用”的问题，而是“怎么选、怎么用、怎么用得稳”的问题。但市面上的宣传口径五花八门，单卡算力、异构软件栈、集群互联、交付形态各有各的门道，稍不留神就会在“模型跑不起来”和“集群扩不动”两个坑之间反复横跳。所以我把这次选型过程中沉淀下来的六项核查整理出来，给准备做国产AI芯片选型、又不想只停留在PPT对比的团队做个参考。

这六项核查的顺序很重要：不是从算力开始，而是从模型适配开始，因为模型跑不跑得起来，决定了后面所有技术判断是不是空谈。然后再走有效算力、软件栈、集群互联、交付运维、五年成本这条线，每一关都会筛掉一批看起来很漂亮的方案。下面逐项拆开说。

1. 第一项核查：模型能不能跑，“支持”这两个字最不可信

1.1 先按自己的模型清单做适配矩阵

很多国产AI芯片厂商在宣传时会说“支持PyTorch”“支持主流大模型”。这句话在多数情况下没错，但“支持”和“生产可用”之间差着好几层：是原生算子直接跑在芯片上，还是通过算子映射桥接过去的？是官方适配过的特定模型版本，还是社区里某个分支的表现？是训练跑通了，还是只保证推理能出数？

我的建议是：在选型第一周，就拉一张自己的模型清单。这张清单不要写“大模型”这种模糊的词，要具体到：模型名称、参数量、是否做预训练、微调方式（LoRA还是全参数）、序列长度、并行策略、精度格式（BF16、FP16、INT8、FP8）。然后拿着这张清单去跟各家厂商逐项核对——他们官方验证过的模型列表里，有没有你要用的这些？验证时用的框架版本、并行策略、精度格式和你的生产环境有多大差异？

我们当时清单一列出来，立刻发现两个问题。一个是我们生产环境里要用到的某个分子生成模型，不在该芯片的官方适配列表里，走的是“社区用户验证过”的路线；另一个是我们在微调阶段会用长序列，而官方验证文档里最长只测到8K上下文，我们真要跑16K甚至32K。这两点看起来都不是硬伤，但会给后续排障埋雷。

1.2 算子覆盖只是入场券，精度对齐才是深水区

模型适配最常踩的坑是：模型能跑起来，Loss也能掉，但收敛曲线和参考实现差了一截。这个时候大多数人会怀疑超参数，少有人想到是算子精度的问题。

我的经验是，做适配核查时不能只看“跑没跑通”，要专门做两件事。第一件：把模型里的关键算子单独拎出来做数值对齐测试，包括LayerNorm、Softmax、RoPE、FlashAttention这一类高频算子。逐层对比该芯片输出和GPU参考输出，看最大绝对误差和余弦相似度。第二件：用小规模训练任务跑完整流程，比如用同样的随机种子、同样的数据切片，训练同一个小模型同样步数，对比Loss曲线的形状和最终精度。如果Loss曲线走势大致一致，但数值有明显偏移，就要警惕是不是某些算子的低精度实现或者近似算法导致的。

我们当时就遇到过一个很典型的案例：某国产芯片跑GPT类模型，前几百步挺正常，但梯度累积一段时间后Loss开始抖动，排查了两天才定位到是某个激活函数的算子实现里用了精度较低的近似计算，在梯度反传时放大了误差。这个问题在单卡、小模型上很难暴露，放到大规模集群上会被进一步放大。

所以模型适配这一关，建议按照“官方适配列表→自己模型清单→关键算子精度对齐→小规模端到端训练”四步走。每一步都留下可复现的测试脚本和日志，后面做集群交付验收时还要再跑一遍同样的测试，作为对照基线。

2. 第二项核查：把纸面TOPS还原成有效算力

2.1 三个口径最容易偷换概念

选型必看算力，但算力参数的水分也不少。国产AI芯片宣传册上最常见的是TOPS（Tera Operations Per Second），这里至少有三个口径要盯紧：精度口径、稀疏口径、实际利用率。

先说精度口径。同样是“300 TOPS”，是FP16下的，还是INT8下的，单位完全不同。INT8的TOPS一般能到FP16的两倍甚至更高，如果拿INT8的指标去对标别人FP16的指标，数字好看但没意义。大模型训练和推理的主流格式还是BF16/FP16，所以数量级上要优先对比BF16或FP16下的稠密算力。

再说稀疏口径。有些芯片的TOPS指标是建立在稀疏计算假设上的，也就是利用了权重中的零元素跳过计算。但大模型训练阶段的稠密矩阵乘法占比极高，稀疏率远达不到厂商的假设值。换句话说，纸面稀疏算力只能作为参考，稠密算力才是训练场景里真正用得上的数字。

最后是实际利用率。纸面峰值算力是理论极限，真实跑起来要打个折扣。大模型训练里，矩阵乘法占大头，但Attention的计算、通信同步、CPU调度、数据加载都在抢时间，GPU这类硬件把MFU（模型算力利用率，Model FLOPs Utilization）跑到40%以上就算不错，国产芯片的实测量级目前差距不小。我们实测某国产芯片跑7B模型训练，MFU只有20%出头，同样负载在参照硬件上能到40%以上。这还只是训练；推理场景更复杂，受显存带宽和Batch Size影响，算力利用率可能更低。

2.2 显存和带宽决定你能跑多大模型，而不只是算得快

另一个容易被忽视的维度是显存容量和显存带宽。它们直接决定你能跑多大模型、多大Batch，而不是单纯决定“算得快不快”。

以7B模型为例：BF16精度下，光权重就要14GB。训练场景还要算上梯度、优化器状态（Adam优化器一套状态轻松翻几倍），一张卡如果只有32GB显存，跑7B全参数微调基本是寸步难行。推理场景看似好一些，但序列长度上去了，KV Cache会迅速吞噬显存：我们测过一个70B模型在4K长度、Batch 16下的推理，KV Cache要占掉20GB以上。如果芯片的显存带宽不够，Batch往上加之后，生成延迟会急剧恶化——因为推理的瓶颈往往不在计算，而在访存。

所以这一项核查，不要只看厂商给的显存大小，要看三件事：同精度下权重占多少、长序列下KV Cache占多少、Batch变大之后延迟和吞吐的曲线怎么走。我们当时做了一个“单卡推理吞吐测试表”，把相同模型、相同并发、相同精度下的吞吐拉出来对比，数据一出来，很多宣传语就不攻自破了。

2.3 功耗和散热不到位，峰值算力就是PPT数字

算力还有一个隐形变量是功耗和散热。大功率AI芯片在高负载下如果散热跟不上，会触发降频保护，实际算力直接打折。这一点在芯片单体测试时往往不明显，因为散热条件好；但放进机房、塞进高密度机柜之后，情况完全不同。

我见过一个真实案例：某团队采购的国产AI服务器，标称整机功耗上限和机房单机柜供电容量不匹配，机器满载运行不到半小时就触发机柜级限电，性能被压掉两成。后面花了额外的成本改造供电和散热，交付周期拖了一个多月。所以选型阶段，一定要让厂商提供“满载持续运行下”的功耗、温度和降频曲线，最好是能实测——找一台样机，跑满半小时，看芯片温度和实际算力是否稳定。别只对着PPT上的TDP做判断。

3. 第三项核查：软件栈的迁移成本，往往比芯片差价更大

3.1 训练栈里那些“原生支持”的水分

芯片本身的硬件规格只是门槛，软件栈决定的是你的工程团队要投入多少人力、多少时间才能把模型稳定跑起来。这一关如果没看清，后续痛苦的是程序员和算法工程师。

先说训练框架。现在绝大多数大模型训练都在PyTorch生态里，DeepSpeed、Megatron-LM这类并行框架是标配。国产芯片的“支持PyTorch”通常分三种级别：第一种，PyTorch官方分支直接跑，算子全部落到芯片上；第二种，基于厂商自己维护的PyTorch分支，大部分算子能跑，少数高阶算子走模拟或者CPU回退；第三种，只覆盖了核心训练链路，模型一用上高级特性就开始报错。

我们踩过的坑是：某个芯片跑最常见的GPT类模型没问题，但只要在模型里加上分组查询注意力（GQA）或者某种相对位置编码，就会出现“算子未实现”的报错，最后不得不改模型实现去迁就芯片。这种隐性移植成本会吃掉团队大量的开发时间。

另一个容易被忽略的点是分布式训练通信库。DeepSpeed和Megatron依赖后端通信库做集合通信，国产芯片配套的通信库是自研的还是兼容现有标准的？AllReduce的实现效率如何？机器数从一台扩到几十台时，通信库会不会成为瓶颈？这些在单卡测试时完全暴露不了，一定得上集群测。

3.2 推理引擎和性能工具链，决定上线速度

训练跑通只是第一步，生产系统还涉及推理引擎。目前主流的大模型推理方案已经高度工程化，像vLLM、SGLang、TensorRT-LLM这些框架里塞了大量优化：PagedAttention、Continuous Batching、投机解码、量化推理。国产芯片对这套生态的支持进展参差不齐。

有些芯片厂商给了自己的推理引擎，并且在自家硬件上做了深度优化，跑起来吞吐不差。但问题是这个引擎是否兼容OpenAI风格的API？能不能比较好地接入现有业务侧代码？是否支持常用的量化格式（INT8、INT4、FP8）？如果只能跑自家框架、不支持社区通用的推理服务接口，后面接业务系统会非常别扭。

性能工具链同样重要。训练和推理排障时，一个可用的Profiler能省下大量时间。我建议在选型阶段就提一个硬性要求：厂商提供性能分析工具，并能完整展示算子耗时、访存开销、通信耗时分布。工具要是太简陋，后面做性能调优就是盲人摸象。

3.3 版本迭代节奏怎么评估

软件栈还有一个容易忽略的维度：版本迭代的速度和质量。国产AI芯片的软件栈更新速度普遍很快，这是好事，但也带来兼容性风险。我们碰到过两次：一次是驱动升级后，训练框架报错，回滚驱动才恢复；另一次是新编译器版本改变了算子调度的行为，导致线上推理延迟波动变大。

所以选型时，不要只看厂商软件栈当前的能力，还要看他们的版本管理规范：有没有长期稳定版本？升级时是否向后兼容？第三方开发者提的算子请求，从提出到合入大概要多久？这些信息可以从厂商的官方技术社区、Release Notes、以及现有客户的反馈里摸到门道。也可以直接在选型阶段要求厂商提供“最近一年版本更新与关键问题修复列表”，作为软件栈健康度的一个侧面参考。

4. 第四项核查：集群互联是百卡扩展的分水岭

4.1 卡内强不算强，卡间快才算

如果只做单卡推理或者小规模训练，前几项核查基本够了。但“集群交付”这四个字意味着，你大概率是要搭一个几十卡甚至上百卡的集群出来。这个时候，卡间互联和集群通信能力成了决定成败的关键因素。

大模型训练里常用到张量并行和流水并行。张量并行对卡间通信带宽极其敏感——切分权重后，每一层的前向和反向都要做AllReduce同步，通信延迟和带宽损耗直接摊进每一步训练时间。流水并行虽然通信频率低一些，但对带宽和时延仍有一定要求。换句话说，如果卡间互联带宽很弱，单卡再强也发挥不出来。

对照起来看，主流方案里卡间互联能做到非常高带宽和低时延，这几乎成了高端AI芯片的标配。国产AI芯片的互联方案各有不同：有的走自研高速互联协议，有的走RoCE网络，有的依赖PCIe交换。不能说谁绝对不好，但一定要在选型时拿到实测数据，而不是听宣传。

4.2 实测AllReduce和端到端扩展性

集群互联的核查方法，我建议分两层。

第一层是单点通信能力测试。参考业界常用的集合通信基准测试工具（类似nccl-test），测一下多卡AllReduce在不同消息大小下的带宽和时延。重点关注两个数字：一是峰值带宽能到多少，二是小消息场景下的时延。大模型训练里既有很多大消息的AllReduce，也有大量小的控制消息，两者都要达标。

第二层是端到端扩展性测试。用一个固定规模的模型训练任务，分别跑1节点、2节点、4节点、8节点，记录每增加一批节点后训练吞吐的提升比例。理想情况下，吞吐应该接近线性增长；现实情况是，节点越多，通信占比越高，加速比曲线会往下弯。这个弯曲的陡峭程度，直接反映了芯片互联方案的成熟度。我们实测过一个方案，从4节点扩到8节点，加速比只有1.5倍左右，通信瓶颈非常明显，这种方案就不适合继续扩到更大集群。

4.3 拓扑感知与断点续训的坑

集群互联还牵扯到两个在实际运营中特别容易炸的点：拓扑感知和断点续训。

先看拓扑感知。一个集群内部的网络拓扑可能有层级差异，有的卡在同一个交换域，有的要跨交换机绕一圈。如果通信库和任务调度器不做拓扑感知，就可能出现随机分配任务，把本可以近距离通信的任务分到了跨交换域的位置，白白多出一截延迟。很多国产方案的调度器对拓扑感知的支持还不完善，需要运维侧手动配置，这个要提前确认。

再看断点续训。大规模集群训练持续几天甚至几周，故障是常态，断点续训的能力决定了故障之后要损失多少时间。我们在一次实测中发现，某方案中断点保存的触发机制不够灵活，默认每隔固定步数保存，而恢复时需要重新初始化通信组，一旦有节点卡死，整个任务要等较长时间才能重新拉起。这些小细节在单节点演示时完全看不出来，只有真正跑到百卡规模才会暴露。

5. 第五项核查：交付验收要按“三年运行”来设计

5.1 交付形态和机房条件的匹配

谈完算力和互联，来说交付。国产AI芯片的集群交付通常会遇到一个现实问题：机房条件是否匹配。

整机柜交付和散件交付是两种完全不同的体验。整机柜通常预装好了供电、散热和网络布线，开箱接电就能用，但要求机柜的尺寸、承重、供电规格和厂商的整机柜设计匹配。散件交付灵活一些，但意味着集成、调测、布线的活都要自己的运维团队干，交付周期拉长不说，排障边界也变模糊了——是卡的问题、网络的问题，还是主板兼容性的问题，厂商和整机厂商之间容易互相推诿。

我们在选型时就遇到一个选择：A厂商提供整机柜方案，但要求机房提供液冷条件；B厂商可以风冷散件交付，但对机柜数量和空间利用率不友好。最后我们做了机房现状的详细盘点，包括单机柜供电余量、空调制冷量、地板承重，才确定哪套方案能落得下去。如果你还没有做过这个盘点，建议第一步先做机房基础设施评估，再回来和厂商谈交付形态。

5.2 故障率、备件和服务响应

芯片不可能不坏，关键是坏了之后怎么办。选型阶段的商务谈判里，一定要把几个指标写进合同或者SLA里：故障率承诺（比如年度故障率上限）、备件备机的响应时限（比如4小时到场，还是24小时到场）、远程支持的技术深度。

大模型训练集群最怕的事情之一是单卡故障拖垮整个任务。如果集群里有一张卡坏了，训练任务可能因为通信超时而大面积中断。所以除了芯片本身，还要关注服务器的管理接口是否支持带外监控，能快速定位故障卡；厂商是否提供备卡机制，坏卡之后能不能在最短时间内完成替换。我们实际经历过一次：某批服务器运行一个月后，陆续有几张卡报HBM ECC错误，由于厂商备件储备不足，单张卡的替换周期拖到了两周，期间该节点的训练任务只能降级运行。

5.3 运维监控和固件升级的日常操作

交付不稳不炸，但运维的日常工作量可能被低估。我的建议是在选型阶段就问清楚三件事。

第一件事：有没有统一的监控运维平台，能看到每张卡的功耗、温度、显存、带宽利用率、报错日志？是做进了云平台还是纯命令行工具？这决定了运维团队的上手成本。第二件事：固件和驱动的升级机制是否平滑？能不能批量去做？升级失败有没有自动回滚？我们之前遇到过一次固件与当前驱动版本不匹配，导致部分卡识别不到，最后要靠人工逐台刷写的局面，这个教训很深刻。第三件事：厂商是否提供定期健康巡检服务？还是一次性的交付调测？这两者的差别，要在商务阶段就确认清楚。

运维这一关的结论很直接：交付不是一个时间点，而是一个带售后服务的持续过程。合同里没有写清楚的支持范围，后面都会变成额外成本和时间损失。

6. 第六项核查：五年TCO账里最容易漏掉的三个数

6.1 等效算力成本：把利用率算进去

采购芯片时最直接的对比是“单卡价格”，但这张卡能产出的有效算力是多少，才是成本核算的真正分母。

我们用过一个简单的公式：等效算力成本 = 单卡采购成本 /（峰值算力 × 实际利用率）。因为不同芯片在相同负载下的利用率差异非常大，单看单价会得出完全错误的结论。举个例子，A卡单卡价格只有B卡的七成，但在相同7B推理负载下，A卡利用率低导致需要更多卡才能满足并发需求，折算下来单位吞吐成本反而比B卡高。这种账必须算在“等效吞吐”上，而不是“单卡价格”上。