1. 三年了国产AI算力芯片到底有哪些牌子能打这两年问我国产AI算力芯片的人越来越多问题基本长这样“除了英伟达国产的AI芯片到底有哪些我们项目想留个Plan B或者干脆就上国产方案应该怎么选”说实话三年前这是个很尴尬的问题能数的牌子一只手就够而且大多停留在PPT和送测阶段。到了现在牌桌上的人已经不少但真正能稳定供货、软件栈能跟上、社区里有真实落地案例的数来数去仍然没超过五家。我先给一个全景视图把当前市场上主要的国产AI算力芯片品牌、代表产品、技术路线大致列一遍后面再逐个说我的使用感受。品牌代表产品系列技术路线主攻方向软件栈关键字生态成熟度华为昇腾昇腾310P / 910B / 910CNPU云端训练推理、边端推理CANN、MindIE、MindSpore最高寒武纪思元370 / 590 等NPU数据中心推理训练、边缘推理BANG、NeuWare较高海光信息深算DCU系列GPGPU数据中心训练推理HIP、ROCm兼容路线中高燧原科技云燧i20 / i30NPU云端训练推理燧原自研SDK中等摩尔线程MTT S4000 / S80GPU图形通用计算推理MUSA、CUDA迁移工具中等壁仞科技BR100 / BR104通用GPU云端训练推理自研软件栈偏低天数智芯天垓100通用GPU训练推理自研软件栈偏低百度昆仑芯昆仑芯P200系列自研架构自家云业务推理为主自研外部基本拿不到阿里平头哥含光800ASIC内部图像/推理业务自研外部基本拿不到这张表已经把大方向说清楚了。但我要强调一句更重要的经验判断一个牌子的芯片能不能用不要只盯TOPS、TFLOPS这些数字先问自己三个问题——能不能买得到货SDK有没有人持续维护社区里有没有人拿它真实跑通了你要用的模型三个问题都答“是”的掰着手指头数其实没几个。先说说华为昇腾。它是我目前见过生态最完整的国产AI算力芯片系列。昇腾310P主打边端推理功耗低适合AI盒子、边缘服务器这类场景昇腾910B和910C则是数据中心级别的训练和推理都能扛。软件栈层面有CANN作为统一编程接口MindIE专门做推理引擎MindSpore做训练框架再加上昇腾对vLLM、PyTorch的适配一直在推进整体用起来的体验在国产芯片里确实是独一档。寒武纪是另一家绕不开的。它的思元系列在云端推理卡市场有一定存在感尤其在某些智算中心的项目里出场率不低。寒武纪的BANG语言和NeuWare推理框架和昇腾的CANN类似属于自研封闭体系能不能用好取决于官方算子库覆盖多少、PyTorch适配到位不到位。海光和摩尔线程走的是另一条路GPGPU兼容路线。海光的深算DCU基于类似GPU的架构目标是让CUDA代码迁移成本更低摩尔线程则是用MUSA这套生态做CUDA兼容。这条路的逻辑很简单——英伟达生态太强了与其物理隔绝不如先兼容、再迁移让工程师不至于推倒重来。实际用下来迁移成本确实低不少但“兼容”不等于“百分百通用”遇到冷门算子照样要自己改性能也要重新调。至于燧原、壁仞、天数它们的技术底子不差具体产品也各有亮点但商业可持续性和社区生态是明显短板。你在项目选型时如果追求长期稳定交付容错率会比较低。百度昆仑芯和阿里含光基本属于“大厂内部自用”外部团队主要在云服务里间接调用别指望能拿到芯片自己开发。2. 为什么突破口是推理和边端而不是训练很多人一听国产AI芯片第一反应就是“能不能训大模型”。这个想法可以理解但方向其实偏了。真正适合国产芯片切入的战场是推理和边端而不是正面硬刚大模型训练。先说训练。今天的大模型训练集群拼的已经不只是单卡算力而是通信带宽、分布式并行框架、故障恢复、大规模调度这些全都要往上叠。英伟达在这个领域积累了好多年大规模集群的调度和通信库都是围绕CUDA生态转的。国产芯片要追上去不是单卡性能拉平就完事还得把整个训练体系做起来包括HCCL这类集合通信库、分布式训练框架的适配、超节点之间的高速互联。这是一场体系化硬仗短期内性价比不高。训练还有一个特点市场玩家少、任务重、换卡成本极高。一套训练集群动辄成百上千块卡只有少数大厂和科研机构在买。选完卡之后整个框架都锁定在上面了后面再换芯片迁移成本几乎等于重新搭一套生产系统。所以训练市场很难成为国产芯片的突破口——不是不想做是周期太长、投入太大。反过来看推理。推理是“一次训练、无数次调用”的持续消耗过程一个模型在线上跑起来之后每一次用户请求都在烧算力并发越高、场景越多、推理算力需求越大。从行业统计来看全球AI算力消耗中推理的占比一直在快速攀升很多智算中心在实际运营中推理负载已经超过训练负载。需求的碎片化天然给不同芯片留了生存空间对话机器人、语音识别、图像检测、辅助驾驶、视频分析每个场景对芯片的诉求都不一样有的要极低功耗、有的要超低时延、有的只要便宜。推理场景的芯片设计逻辑也和训练完全不同。训练需要大量高强度矩阵运算追求极致吞吐推理则更看重时延、功耗、并发调度效率并且允许特化。NPU和ASIC这类电路在推理上的优势恰恰是“扔掉不必要的通用能力专攻矩阵乘法和内存搬运”。打个不太严谨的比方训练芯片是“全能重型卡车”什么都得能拉推理芯片是“市区穿梭的电动三轮车”你只需要它跑固定路线便宜、省电、好停车就行了。后者正是国产芯片更有机会做好的形态。边端就更明显了。把模型推理下沉到数据产生的地方本身就是确定的趋势摄像头旁边、产线边缘、汽车里、机器人体内。这些场景有三个更切实际的需求第一是隐私和数据不出域很多行业的原始数据不能轻易上云第二是离线可用性现场网络一断本地推理必须继续工作第三是成本和功耗端侧设备不可能像数据中心一样又大又耗电。这三个条件放在一起几乎就是为国产AI算力芯片量身定制的赛区。边端对绝对算力的要求没那么高反而更看重能效比、供货稳定性和定制化能力这些恰好是国内芯片设计的强项。3. 推理部署实测别只看TOPS要看tokens/s讲完为什么再说怎么用。无论你选哪个牌子的芯片最后都得落到跑模型这件事上。我在国产芯片上部署LLM推理的环节踩过不少坑下面这些经验应该能帮你省下几个礼拜的调试时间。3.1 推理链路里最该盯的三个指标做LLM推理部署大部分人第一步是看官方标称的TOPS、TFLOPS这其实是品牌宣传语言不是工程语言。真正要盯的指标是以下三个首字延迟TTFT, Time To First Token。用户发一句话模型第一个字多久出来。对话场景如果首字延迟超过一两秒用户体感就会明显变差。这个指标受模型大小、输入长度、KV Cache命中、推理引擎的调度效率影响跟芯片的“矩阵乘法峰值算力”关系反而不是最直接。生成速度tokens/s。每秒生成多少个token决定对话的流畅度。很多人说的“跑XX B模型多少 token/s”指的就是这个。它更依赖内存带宽、算子的融合程度、量化方式。并发吞吐量综合TPS。一个推理服务在同时处理N路请求时每秒合计能出多少token。这个指标决定了你的服务器能支撑多少用户直接关系到采购和扩容。这三个指标组合起来才是推理场景需要关注的“有效算力”。峰值算力可能高得吓人但一旦多路并发、上下文变长、batch动态变化实际表现可能掉得很难看。反过来有些峰值算力平平的芯片靠连续批处理和算子优化到位在线上的吞吐反而很能打。3.2 软件栈是真正的分水岭国产AI算力芯片在片上算力的差距其实在缩小真正拉开差距的是软件栈。目前市面上基本是三种形态第一种完全自研封闭体系。典型代表是昇腾的CANN和寒武纪的BANG。这套路子的上限取决于官方算子库的覆盖度以及推理框架的适配程度。某个关键算子没覆盖你就得自己用低阶接口去写某个推理引擎没适配很多开源工具链带来的便利就用不上。昇腾好就好在投入大对Qwen等主流模型的适配出得比较及时寒武纪也在逐步追赶。第二种CUDA兼容路线。海光的HIP、摩尔线程的MUSA都属于这一类。好处是工程师的已有技能能直接迁移很多CUDA代码可以直接编译或者小幅修改跑通难点在于“兼容”不是100%覆盖遇到冷门算子、特殊精度组合、特定优化库还得自己手工改。迁移得越深踩到的坑越细比如某个算子函数名支持了但语义有细微差别性能忽高忽低。第三种开源推理框架的适配层。比如昇腾的vLLM-Ascend、寒武纪对vLLM/SGLang的部分适配以及各家推理引擎工具包。这一层做得好不好决定了量产部署效率。我自己的经验是判断一个国产芯片推理能力怎么样别听发布会直接去看vLLM支持哪些硬件后端、官方提供哪些模型适配示例。有就是有没有就是没有PPT里写“未来支持”的一律按没有算。3.3 用国产芯片跑Qwen3-8B真实记录的浮动区间说点具体的。我在昇腾910B上用MindIE和vLLM的昇腾适配跑过Qwen3-8BFP16权重输入输出长度控制在2K以内并发16路。记录下来的整体吞吐大致在每秒千级token的区间浮动首字延迟在几十毫秒级别。这个数字放到英伟达上对比还有差距但已经不是说不能用。真正值得注意的是版本波动——同一个模型、同一块卡推理引擎换一个版本性能就可能差出两倍这在我测试初期非常常见。如果你也准备在国产芯片上跑大模型推理我的建议是先做四件事用你自己的业务数据跑一遍不要用官方示例模型和脚本官方示例普遍挑过算子看不出真实水平连续跑至少一周看重启频率、内存泄漏、显存碎片等生产环境问题对比至少两个推理引擎版本看清楚性能差异和API变化再锁定一个版本投入生产测一下长上下文场景下的表现很多NPU在序列长度拉到4K以上时会因为内存带宽和KV Cache管理而明显掉速。对了如果你对推理引擎的内部机制感兴趣可以去翻一翻vLLM这类开源项目的源码重点看PagedAttention和连续批处理Continuous Batching的实现。理解了这两个东西你就知道为什么“峰值算力高”不等同于“在线吞吐高”。现在社区里也有专门让学习者读源码的迷你项目把引擎最核心的调度逻辑剥出来讲对理解推理性能瓶颈特别有帮助。4. 边端落地的“非芯片”坑功耗、带宽与软件适配云端的推理好歹还有服务器、机房、运维团队兜底。到了边端情况完全不一样很多做惯了云端的人一上手就被打懵。芯片本身倒是没什么大问题真正出问题的全是芯片之外的工程细节。4.1 散热和功耗直接影响标称算力边端设备普遍是密闭小盒子没有机房空调没有强风冷。一个整机功耗只有25W的边缘AI盒子芯片、内存、网口、散热全部挤在一个巴掌大的空间里。标称算力再高散热压不住触发降频之后实际吞吐直接跳水这是最容易被忽略的问题。我见过一个项目选了标称INT8算力很高的一块边端推理卡结果装进无风扇壁挂盒子里连续满载跑半小时后温度飙升推理帧率掉到标称的三分之一。后来是加散热片、调整推理线程的负载分配、压低部分算子的功耗方式才把稳态性能稳住。所以选边端芯片时不要只看算力要问三个更实际的问题持续满载的功耗是多少支持的散热方案是什么带载条件下能稳定跑多久不掉速4.2 内存带宽和KV Cache决定能跑多大模型边端芯片绝大多数用的是LPDDR4X、LPDDR5这类低功耗内存带宽通常在几十GB/s级别和云端HBM动辄TB/s的带宽差距巨大。这就带来一个硬约束边端只能跑中小参数模型而且必须量化。举个例子一个8B参数模型FP16权重就要16GB内存这已经超过绝大多数边端设备的内存容量了就算强行塞进去推理时的KV Cache还得继续吃内存长上下文直接爆。所以边端做LLM推理通常只能跑1B到4B这种级别的量化模型或者干脆只跑视觉检测这类CNN模型。必须在选型阶段就想清楚你的业务模型多大能不能量化到INT8甚至更低精度量化之后精度损失业务能不能接受这些问题没想明白就去选芯片后面改造模型的成本会比芯片本身还高。4.3 预处理、后处理才是边端算力的隐形黑洞这是我在边端项目里踩得最深的坑。很多人以为只要NPU算力够整个流程就跑得动大错特错。NPU只负责算卷积和矩阵乘法图像解码、缩放、归一化、letterbox这些预处理操作以及框选、保存结果这些后处理操作全部要CPU来扛。以在边缘盒子上跑YOLOv11目标检测为例模型推理本身可能只需要20毫秒但如果摄像头RTSP拉流、OpenCV解码、图像缩放全挤在CPU上做整条链路的帧率可能只有个位数。我把预处理里的解码和缩放任务改到硬件编码器再把推理结果通过队列异步写盘帧率才真正跑起来。具体来说YOLOv11这类模型的推理结果保存也有讲究如果同步往硬盘写图片或JSON写盘慢就会反过来阻塞推理线程正确做法是单独开一个消费者线程做落盘。还有一个非常隐蔽的坑模型转换时的输入尺寸固定问题。很多端侧NPU的推理引擎要求输入是静态shape比如固定640x640、固定序列长度。模型在训练时是动态输入迁到端侧必须固定下来。你的业务如果存在不同分辨率的图片、不同长度的文本就要在转换前想清楚统一成什么尺寸否则上线后会发现一批样本推理效果很怪却怎么也定位不到原因。5. 最后说选型我用几条原则帮你排除掉一半选项聊了这么多最后回到最实际的选型问题。我在多个项目里试过不同牌子的国产AI算力芯片也见过不少同行踩坑之后来跟我抱怨。总结下来选型其实就是三张表的事。5.1 按场景直接对号入座使用场景优先考虑的芯片方案理由云端大模型训练昇腾910B/910C、海光深算DCU整体软件栈和分布式适配相对成熟云端LLM推理昇腾、寒武纪思元系列对主流开模型适配及时推理引擎优化较深云端传统CV推理海光、摩尔线程迁移成本低兼容性好边端AI盒子视频检测昇腾310P、寒武纪低功耗卡能效比高开发资料齐全车规/机器人类端侧需按具体规格筛选常温消费级和车规工规差别巨大必须实测这张表只给了大方向具体到同一品牌里的不同型号还是要按第3节说的真实推理指标去测不能只看型号和标称算力。5.2 三个踩出来的通用原则第一不要只看峰值算力要看有效算力。同一个芯片在不同推理引擎、不同量化方式下表现差距极大。厂商宣传的是理想条件你业务跑的条件永远不理想。第二不要把迁移成本想得太低。即使走CUDA兼容路线哪怕编译直接通过性能也往往达不到预期。算子级优化、内存分配调整、数据搬运裁剪这些工作省不掉。计划里至少要预留一个月的性能调优时间而且一定要安排懂底层的人去做。第三开发阶段锁定版本组合不要频繁升级。国产芯片的软件迭代很快这既是好事也是风险。我见过一个项目SDK小版本一升推理结果格式变了耗了两天排查才发现是版本问题。稳妥做法是验证通过后锁住芯片固件、SDK、推理引擎三者的版本组合项目交付前不做任何升级。5.3 给刚起步团队的务实建议如果你的团队没有国产芯片经验又正好在做选型我强烈建议先别急着买硬件。现在主流云平台大多能开到昇腾、寒武纪的云实例先按小时租用把你的真实模型拿上去跑把训练、微调、量化、推理、压测全流程走一遍让算法、开发、运维三个角色都实际碰一遍。这时候再判断买不买、买多少、买卡还是买整机心里才有底。算力芯片这行纸上谈兵的成本远比你想象的高。最后分享一个小经验。很多团队评测国产芯片时习惯用标准benchmark和跑分脚本这样测出来的结论其实参考价值有限。我后来养成了一个习惯把线上真实业务的流量录下来做回放发到目标芯片上用完整业务链路跑几天记录成功率、P99延迟、崩溃次数。跑分漂亮不如下线稳定这条经验帮我躲过了好几次“看上去性价比很高”的选型陷阱。