过去一年我和团队跑了不少智算中心每次都会被问到同一个问题你们这颗AI芯片跑xxx模型到底行不行说实话benchmark上是行的跑分漂亮得很GPU算力tops排行里也有一席之地但一接到真实业务就很容易现原形。这不只是某一家国产芯片厂商的困境而是整个国产算力生态共同的坎——算子生态。CNCC2026上这个话题被摊开聊了很多轮既有技术路线之争也有生态建设的务实讨论。我干脆把这段时间的思考和踩坑整理成文聊聊国产AI芯片算子生态到底是什么、怎么建、难在哪、往哪走。这篇文章适合正在做国产芯片适配的算法工程师、做算子库开发的同学以及采购国产算力但被兼容性问题折磨的架构师。我会从算子断层讲起拆解算子生态的底层结构再分享一次完整的算子移植调优实战最后聊聊AI编译器路线和CNCC2026上释放出来的行业信号。1. 算子断层国产AI芯片跑分漂亮生产环境却拉胯1.1 “算力”这个词被误用了太久大家聊算力喜欢看峰值但这几年做国产芯片的人都明白真正决定业务能不能跑起来的不是理论峰值而是“可得算力”。可得算力可以粗略拆成一个公式可得算力 硬件峰值 × 算子覆盖率 × 算子平均效能硬件峰值是芯片出厂指标好查但算子覆盖率和平均效能才是决定真实体验的部分。举个例子某国产加速卡标称FP16算力两百多T跑ResNet50这类经典模型卷积、池化、ReLU、全连接都是算子库里的“常客”覆盖率极高整体利用率能到六成以上。可一旦换成一个多模态模型里面出现了一些自定义算子、特殊归一化逻辑、稀疏化处理覆盖率哗啦一下掉到80%再算上效能折损最终体验可能只剩峰值的15%。业务方的第一反应是“这卡不行”但实际上硬件没变变的是算子和硬件的匹配度。这就是我常说的算子断层硬件能力在算子生态接不住算力就漏掉了。1.2 算子到底是什么为什么成了芯片的命门“算子”在不同领域含义略有差别机器视觉的halcon里有大量算子数学领域有拉普拉斯算子但在AI芯片语境里算子指的就是神经网络的基本计算单元卷积、矩阵乘、归一化、激活、Softmax、Attention、各类Pooling等等。一个Transformer模型拆开以后落到底层就是几十上百种算子的组合。框架把模型翻译成计算图计算图里的每个节点最终都要在芯片上找到对应的可执行实现。这个“可执行实现”就是算子库和编译器的工作。对英伟达来说cuDNN里沉淀了几百个高性能算子配合编译器把卷积、GEMM映射到Tensor Core上对国产芯片来说如果没有等价的算子实现框架就只能把该节点退回CPU执行或者干脆报错。一个模型里只要出现三五个不支持的算子性能就会断崖下跌整个推理流程都变得不可用。所以算子生态的本质不是“把函数名对上”而是“在特定芯片硬件上把每一类计算高效实现出来”。算子覆盖率决定能用算子效能决定好用这两件事是国产AI芯片从“可跑分”走向“可生产”的命门。1.3 算子断层的真实代价算子断层不只是技术问题放在智算中心运营里就是实实在在的账。我见过一个真实案例某项目采购了一批国产加速卡验收时跑通了标准模型但上线一个工业质检模型时因为缺少几个自定义算子的高效实现只能用AI框架的自动回退机制把算子扔到CPU上执行CPU和GPU之间存在频繁的数据搬运单batch推理延迟从预期的20ms膨胀到300ms生产线直接卡死。算子断层还会带来隐性成本模型开发者为了把模型塞进国产芯片不得不反复修改网络结构、替换算子、调整超参数这些“适配成本”比芯片采购成本还高。这也是为什么很多单位在选型时更看重“生态成熟度”而不是单纯看跑分——同样的网络在成熟生态里几天上手在断层生态里几个月挣扎。2. 算子生态的三层地基指令集、编译器、算子库缺一不可2.1 从硬件指令到框架算子中间的三层结构很多人以为算子生态就是“芯片厂商提供一堆函数库”其实站在系统角度看它是一个上下分层的结构。底层是芯片指令集和硬件抽象层决定这张卡能执行哪些基础运算比如向量指令、矩阵乘指令、访存指令。中间是编译器和运行时负责把模型计算图做图优化、算子选择、内存规划、指令调度很多编译优化策略就发生在这一层。再往上是算子库和框架适配层这就是我们平时说的cuDNN、CANN对标的那一层里面是手写的高性能算子实现以及和PyTorch等框架的算子映射关系。这三层各有各的难处。底层难在指令集设计是否贴合主流模型的计算模式中间难在编译器能否把通用计算映射成高效指令序列上层难在算子覆盖度是否足够、每个算子是否榨干了硬件潜力。国产芯片的早期方案大多重底层轻上层结果就是芯片做出来了模型却跑不动。2.2 为什么不靠“CUDA兼容”一招走天下很多国产芯片打出的第一张牌是“CUDA兼容”核心思路是通过翻译层把CUDA代码转译到自己的硬件后端上让英伟达的既有代码跑起来。这个思路落地成本低但天花板非常明显。我自己做过相关测试一个中等复杂度的自定义算子用翻译层跑在国产芯片上性能通常只能达到同等算力英伟达产品的五到七成复杂算子或大量使用共享内存的kernel损耗更严重。原因在于CUDA不仅仅是一套API它背后的编程模型、内存模型、线程调度模型与英伟达的硬件紧密耦合翻译层很难把每个隐性的性能假设都还原到新硬件上。更何况cuDNN这类库里的算子实现是高度启发式的翻译层能翻译的是用户代码库函数的内在逻辑翻译不动。所以行业里慢慢达成了一个共识兼容CUDA可以作为过渡策略帮用户先跑起来但长期还得有自己的算子生态。API层兼容解决“能不能用”算子生态才能解决“好不好用”。2.3 算子库为什么必须开源算子库的建设有一个绕不开的话题要不要开源。我的观点很明确面向开发者的算子库和编译器国产AI芯片必须拥抱开源。道理不复杂芯片厂商的人力写不完所有算子大模型时代模型结构迭代太快今天还在用的算子明天可能就被新结构取代靠厂商闭门造车根本跟不上。开源以后高校、用户、第三方ISV都能为生态补算子。我们看行业里几个头部国产芯片厂商现在基本上都把自己核心的算子库和编译器框架开源了这既是姿态也是策略。开源能让用户自定义算子时有一个明确的开发范式而不是面对一团黑盒只能提工单等待厂商排期。从我的实际体验看能阅读算子库源代码、能自己patch一块逻辑、能在社区里讨论kernel优化这种“安全感”是闭源SDK完全给不了的。不过开源不等于放开质量开源算子库的质量门槛反而应该更高因为每个算子在真实硬件上的性能表现用户都是可以用profiler量出来的。开源只是第一步透明和高效才是目的。3. 算子移植与调优实战从LayerNorm到ConvBNReLU融合3.1 一个LayerNorm的移植从两遍访存降到一遍理论讲多了容易飘还是落到实际项目上看算子怎么做。之前我们把一个开源多模态模型从CUDA平台迁移到国产芯片上模型里有大量LayerNorm算子。第一版实现很简单照着公式写先遍历算均值和方差再遍历做归一化。思路没问题但跑出来效率极低profiling显示这个算子只有峰值性能的20%左右。问题出在访存上。LayerNorm在一个token维度上先算统计量再归一化意味着同样一份数据要读两遍。对芯片来说访存的代价远比计算高两遍读数据等于白白浪费一半带宽。我们改用Welford在线算法单遍计算均值和方差顺道把归一化的统计量算完数据只读一遍。单算子在向量化上再做优化后从最初的2.1ms降到0.8ms。这个算子本身不复杂但它的优化思路是通用的先把访存降下来再谈计算密度。3.2 不换思路会踩坑内存布局与tilingLayerNorm只是热身卷积和矩阵乘才是重头。国产芯片的指令集和英伟达不同内存布局差异尤其坑。很多芯片在硬件设计上对NCHW布局支持很差数据要先转换成类似NC1HWC0或NHWC的格式才能高效计算。我们有一阵子被一个GEMM类算子折磨各种优化手段上了半天性能始终上不去。后来仔细看硬件文档才发现数据在不同维度上的步长直接影响bank conflict和访存连续性。最后对数据重新做了tiling选了一组适合硬件的分块参数类似TILE_M64、TILE_N64、TILE_K16这样的组合L2命中率从57%提升到91%性能才真正起来。这里给做算子开发的同学一个忠告拿到一块新芯片先把它的内存模型、缓存层次、对齐要求摸透再动手写实现。顺序搞反了后面全是坑。还有一次我们把一个自定义的格式转换算子当作普通算子写在计算图里没有把它融合到上下游结果每次推理都要多付出两份全张量拷贝的代价这种布局转换算子看起来不起眼数据量一大就是几十毫秒的差距。3.3 ConvBNReLU融合一份权重算出三样活模型的性能瓶颈不全在单个算子更在于算子之间的中间张量读写。推理场景下Conv后面跟BN和ReLU是常见组合如果各做各的每算完一层就要把中间结果写回显存下一层再读出来。一个ResNet推理跑下来中间张量的搬运开销能占到总时间的30%以上。融合的思路是把BN在推理时的参数折叠进卷积权重。标准实现里BN推理可以化简成对卷积输出的线性变换y (x - mean) / sqrt(var eps) * gamma beta把这条公式合并到卷积里就等价于对卷积权重做一次缩放、对偏置做一次平移。实现时先加载原始卷积权重w和偏置b逐通道计算缩放系数scale再生成新的权重w和偏置bscale gamma / sqrt(running_var eps) w w * scale b (b - running_mean) * scale beta然后ReLU直接作为激活函数接在后端三层变一层中间张量不落显存。实测下来一个ResNet50推理从12.3ms降到了7.8ms这个优化完全不需要改动硬件就是算子实现和计算图层面的功夫。训练场景下不能这么简单地把BN折叠进去因为训练时BN的均值和方差是动态的但我们也可以做训练版的融合把Conv、BN的反向传播合并成一个融合kernel同样减少中间梯度的读写。算子融合这件事本质上优化的是“数据搬运”数值上完全等价性能差别很大。3.4 profiling揭示的真相瓶颈往往不在算子本身做算子优化的最容易犯的毛病是一拿到性能问题就闷头改算子kernel。但实际上很多模型在国产芯片上的性能问题根子根本不在算子计算本身。我们曾经优化一个视觉模型整体利用率只有30%怎么看都像是算子不够快。结果上profiler一看ComputeUtilization很低但MemoryThroughput和KernelLaunch开销非常高。真正的问题有三块一是框架的图优化没有把连续的transpose和contiguous操作消掉数据在推理链路上做了大量无谓的格式转换二是kernel启动过于频繁小算子太多启动开销淹没了计算三是计算图里有几个算子回退到了CPU执行每次都要做一次设备同步。把那几个CPU算子用等效GPU算子替换掉再在框架层面把连续的格式转换算子融合掉利用率从30%直接拉到70%以上。这个经验我想特别强调优化性能的第一步永远是看profiling数据定位访存、启动、同步、数据搬运的瓶颈再决定要不要动算子实现。只盯着kernel改等于蒙着眼睛擦玻璃。4. 手工优化到自动生成算子生态的演进分水岭4.1 手工写算子为什么不可持续算子移植做到一定阶段你会开始觉得不对劲这个模型好不容易跑通了下个月又发布了个新结构里面又冒出几个没见过的算子又要重新适配。这么玩人力根本接不住。问题的根源在于模型结构的演进速度远快于算子库的更新速度。FlashAttention就是典型例子2020年论文出来到主流芯片的算子库里成为标配中间隔了相当长一段时间。在这段空窗期里用户要么自己写kernel要么忍受慢速实现要么换模型。手工算子库可以做到“深度”在特定场景下做到极致性能但很难做到“广度”很难跟上所有新模型的需求。这就逼出了第二个方向让工具代替手用AI编译器自动生成算子。4.2 算子自动生成的三代路线算子自动生成不是新概念它的演进大致可以分三个阶段。早期是模板时代预先写好模板代码通过传参实例化卷积和GEMM的多种实现配合启发式搜索挑选最优配置。cuDNN底层有不少这种逻辑优点是稳定缺点是模板的抽象能力有限遇到奇异shape很容易退化成慢速路径。后来到了搜索时代以TVM的AutoTVM和Ansor为代表编译器通过定义搜索空间自动探索tiling、循环变换、向量化等组合找出一套在当前硬件上性能最好的kernel。Ansor能在一个高性能模板之外搜到意想不到的切分方式我自己在国产芯片上试过用AutoTVM针对一个3D卷积搜出来的实现比手动第一版快了一倍多。缺点是搜索开销大编译一次动不动几分钟甚至更久。当前的热点是以Triton和TensorIR为代表的编程语言时代。Triton的做法是提供一套Pythonic的编程模型开发者只需要描述计算逻辑编译器自动负责分块、并行、缓存调度。它的写法和手写CUDA相比门槛低一大截而且硬件后端可以替换。现在不少国产芯片厂商都在走“Triton前端自研后端”的路线就是这个原因把前端生态贴近社区主流后端对接自己的指令集。三代路线对比下来可以这样看路线开发效率性能上限适配新硬件成本代表工具模板库低高依赖模板质量中cuDNN、手工算子库搜索式编译器中较高中高TVM、Ansor、AutoTVM可编程编译器高高接近手写中Triton、TensorIR、MLIR4.3 自动生成在国产芯片上的特殊意义自动生成的路线对国产芯片有一个特殊价值新硬件没有历史包袱。英伟达的cuDNN积累了十几年手写算子库的起点很高而国产芯片往往指令集比较新、用户少、历史积累薄直接从手写算子库追赶短期内很难追上。但如果直接跳到一个设计良好的编译器架构上让代码生成器面向自家指令集产出kernel反而有可能在几类核心算子上追平甚至反超闭源库。我参与的一个项目就是绕过传统算子库直接用一个编译器前端把PyTorch模型翻译成目标芯片的指令。在卷积和GEMM这类规则的计算上自动生成的kernel已经能达到手写版本90%以上的效率在SSM、FlashAttention这类复杂计算上自动生成暂时还追不上手写kernel因为这类算子需要非常精细的访存调度编译器很难搜出那种手工设计的分块和流水线策略。所以我的实践结论是不要把自动生成和手写算子库对立起来它们各守一摊。规则型的卷算子交给编译器自动生成细碎行的融合逻辑和特殊数据流算子继续用手写kernel打磨。像拉普拉斯算子这种在图像处理里简单到不行的算子自动生成绰绰有余但像异构设备上的分布式通信算子、融合了特殊计算语义的精调算子还是有经验的工程师手工优化更靠谱。5. CNCC2026上的路线之争与开放生态拐点5.1 会上被反复争论的“手写算子库”与“编译器”之争CNCC2026关于算子生态的讨论我觉得最有价值的部分不是某个具体技术而是两条路线之间的正面碰撞。一派认为芯片性能的兑现必须靠手写算子库逐算子打磨这是cuDNN验证过的路径另一派认为大模型时代算子迭代太快手工优化不可持续编译器会让算子生态以更低的成本生长。我在这两派之间算不上中立因为我两边都做过。真实情况是手写算子库在局部性能上永远有优势但它在覆盖面上面临巨大的长尾成本编译器在覆盖面上有结构性优势但在最难的算子类型上很难比得过顶尖工程师的手工实现。CNCC2026上讨论到最后大家其实慢慢认同了一个观点这不是go or no-go的选择而是一个生态成熟度的问题。早期生态薄弱时靠编译器快速铺开覆盖面中期用手工优化锁定核心算子的性能制高点后期通过工具链和标准让两者共存。5.2 开放生态出现拐点我今年在CNCC上感受到一个明显的变化芯片厂商开始把算子库、编译器后端、甚至硬件行为级模拟器逐步开源。这跟两年前比是质的转变。过去开源只是放出SDK现在是连性能优化的那层秘密也拿出来了意味着厂商意识到生态要长出自己的生命力就不能只靠一纸NDA让三五家ISV闷头干。另一个拐点是算子IR层开始出现标准化迹象。不同厂商的芯片后端各不相同但如果大家能在计算图IR层面用一套中间表示描述算子语义那模型迁移成本就能大幅下降。做算子开发的同事应该对ONNX的算子集很熟ONNX定义了算子语义的标准但没定义性能怎么优化。CNCC2026上讨论的算子IR标准化想往前走半步把性能相关的属性比如数据布局、tiling偏好、融合约束也纳入标准化描述。这个若真落地以后换芯片就跟换浏览器内核一样页面还是那个页面收益是整体性的。5.3 算子生态向哪里演进从CNCC2026上的讨论和近一年的项目经验看国产AI芯片算子生态的演进路径会依次经历三个阶段。第一阶段是兼容移植期核心任务是让主流模型能在国产芯片上“跑通”靠CUDA兼容层、手动算子移植和框架补丁来扩大Coverage。这个阶段我们正在经历每个做国产芯片适配的团队应该都深有体会。第二阶段是自动生成与半自动优化期编译器成为算子覆盖的主渠道。前端编写算子的门槛降低后端通过AutoTVM、Triton风格的编译栈自动生成实现工程师主要精力放在核心算子的手工调优和融合策略上。第三阶段是标准与生态平台期算子语义和性能属性形成统一描述开发者编写一次算子可针对不同硬件生成不同优化版本这是整个行业真正扁平化的阶段。作为开发者不管你在哪个位置现在去了解编译器的基本逻辑、熟悉profiling工具链、练好手工调kernel的手感在三五年内都不会过时。因为技术路线可以变但“理解硬件、会看性能数据、能定位瓶颈”这套底层能力永远有用。我在实际项目里的体会是算子生态建设这件事比拼的是耐力而非技巧。它没有一击制胜的解决方案只能靠一层层堆。开头那个问题——国产AI芯片行不行——我的回答是芯片本身越来越行而决定它“行不行”的那层算子生态正在以肉眼可见的速度补起来。这个过程没有捷径但方向对了每一步都不白走。