国产AI芯片算子生态：从算子缺失到性能调优的破局实践

在准备CNCC2026分享材料的过程中，我把这几年在国产AI芯片适配和算子开发上踩过的坑、趟过的路重新捋了一遍。说实话，2026年聊"算力瓶颈"已经不能只盯着GPU供应量了。大模型训练、推理的需求摆在那里，集群可以堆起来，卡可以批量上，但真正决定一个模型能不能跑起来、跑得快不快的，是芯片上的算子生态。

很多人以为算力瓶颈是硅片层面的物理限制，我以前的看法也差不多。直到亲手把一个LLM推理服务从N卡迁移到国产加速卡，才发现瓶颈根本不是"多少TFLOPs"的问题，而是软件栈里缺了关键算子之后，整条链路直接卡死。模型写好了调用torch.matmul，底层得有人把它翻译成能在硬件上高效执行的kernel。这一层如果做得不完整，再高的峰值算力都只是个好看的数字。

这篇文章我不打算做宏大叙事，就聊聊我理解中的算子生态到底是什么、国产AI芯片在这个方向上的演进路径，以及一个开发者在实际迁移中会经历什么。CNCC2026的主题是算力破局，但我认为真正的破局点，恰恰是从一颗芯片被"真正用起来"的那一刻开始的。

1. 算力瓶颈的本质：芯片不"难产"，难的是让每种芯片都"好用"

1.1 一块芯片等于多少实际算力

先看一个简单公式：实际可用算力 = 峰值算力 × 软件栈效率。

NVIDIA的卡之所以强，不只是因为晶体管密度高，而是它的软件栈把峰值算力兑现了。CUDA生态里沉淀了三十年的底层库，cuDNN里有几百个针对不同shape、不同精度、不同硬件代次优化过的卷积和注意力实现。你调一个API，它自动帮你选择最优kernel，实测利用率和理论峰值之间的差距很小。

国产AI芯片这几年在硬件指标上追得很快，峰值TOPS、HBM带宽、互联速率都摆上台面了。但软件栈效率是另一回事。我见过一些部署项目里，同样的模型在N卡上能跑到60%多的算力利用率（MFU），迁移到国产卡上直接掉到30%以下。你说硬件不行吗？不一定。更多时候是算子库里没有对应的高性能kernel，编译器也没有做好自动调度，连数据搬运都吃了大半时间。

还有个常见的误解：算力是"芯片自带的"。实际上算力是芯片和软件共同提供的服务。换句话说，算子生态的完善度，直接决定了一张卡在你手里是一块高性能计算单元，还是一块昂贵的"半成品"。

1.2 精度体系里的算力账本

从FP64到FP32、FP16、BF16再到INT8，每一档精度背后都是算力和精度的权衡。我经常看到有人把"TOPS"和"TFLOPS"混为一谈。这里先厘清：TOPS通常指INT8整数运算的峰值，TFLOPS是浮点运算的峰值。两者衡量的是不同类型的计算。

FP64 vs FP32 vs FP16/FP16 vs INT8的算力需求差异是数量级的：

大模型训练为什么依赖算子生态的优化？就是因为算力约束下，你不可能全用FP32跑千亿参数模型，必须靠FP16/BF16混合精度、梯度缩放、分片等技术把显存和算力平衡好。这些技术落到硬件上，全是算子在承担。

而推理侧的低比特量化（INT8）更是如此。一个模型如果转换后出现数值溢出或精度坍塌，不是芯片"不行"，而是算子层的量化实现没做好。国产算子库在INT8支持上曾经相当薄弱，很多算子只能回退到FP16再转INT8，性能打骨折，数据来回搬运还增加延迟。这几年各家逐步补齐了量化算子，但深度和NVIDIA仍有差距，这是现实。

1.3 AI算力集群的系统结构约束

再往外看一层。单卡算力再高，集群层面跑不动，瓶颈就转移到体系结构上。一个典型的AI算力集群，构成大概分四块：

• 计算节点：AI加速卡、CPU、本地内存，卡间通常用NVLink之类的高速互联。
• 高速网络：节点间通信，RDMA/InfiniBand或RoCE，负责分布式训练的张量并行、流水线并行通信。
• 存储系统：模型权重、数据集、checkpoint的读写，要求高吞吐、低延迟。
• 调度与集群管理：资源分配、任务编排、故障恢复。

国产集群这几年被吐槽最多的是两个地方：一是卡间互联带宽和协议生态不统一，二是指挥系统（调度器、通信库）和硬件之间磨合不够。算子只是软件栈的一小块，但它是紧贴着硬件的最底层，上面每一层都要通过它来呼吸。算子生态不完整，即便集群架构设计得再合理，计算节点上也跑不满。

我在实际调优里发现，很多时候瓶颈并非算子本身的算力，而是"数据搬运"。比如一个融合算子把三次kernel launch合并成一次，数据在片上缓存里复用，速度立刻翻倍。这就是算子生态的价值——它不是在帮芯片解决计算问题，而是在帮计算任务节省数据搬运的成本。《算力约束下提升大语言模型能力的资源配置建模》这类研究之所以热门，本质上也是在承认：算力总量是一回事，如何通过软件和资源编排把算力兑现成“有用计算”是另一回事。

2. 算子生态到底是什么：从数学库到编译器的四层结构

讲算子生态之前，先拆解一个最简单的Transformer block。里面包含哪些算子？Linear（GEMM）、LayerNorm/RMSNorm、Softmax、GELU/SiLU激活函数、RoPE位置编码、Attention打分、FlashAttention的融合kernel、CrossEntropy Loss等。这些只是"数学算子"层面。再往下，每个算子还要处理tiling（分块）、数据布局转换、向量单元和矩阵单元的分工、片上内存调度、流水线重叠……这些东西写起来极其琐碎，生态就是把这些琐碎沉淀成可复用的软件资产。

2.1 算子API层：模型落地的最小单元

开发者最熟悉的，是PyTorchtorch.nn里那一堆接口。每个接口背后都映射到一个或一组算子。所谓算子，简单说就是"对一个或多个张量执行的基本数学运算"。Matmul是一个算子，Conv是一个算子，Softmax也是一个算子。

但模型落地时，算子API层的完整性最关键。为什么？因为框架层在导入模型的时候，会把计算图逐个算子翻译成下层库的调用。如果某个算子在目标硬件上没有实现，整个图就断了，只能要么CPU回退（奇慢无比），要么干脆跑不起来。

我在迁移TorchVision系列模型时踩过这种坑：一个F.grid_sample算子国产库没实现，整个分割模型直接崩塌。所以算子API的覆盖度，是衡量生态成熟度的第一把尺子。

2.2 高性能算子库：芯片差异的主战场

算子API只是接口，接口之下的高性能实现才是拉开差距的地方。以NVIDIA为例，cuDNN和cuBLAS占了半壁江山。这些库之所以强悍，因为里面针对不同GPU架构、不同tensor shape、不同精度组合，预置了大量kernel变体，运行时再通过启发式搜索选择最优版本。

国产芯片对应的是各自的高性能算子库，比如昇腾的CANN/ACL、寒武纪的CNNL/BANG、燧原的等行业库等。每家的硬件架构不同：有的有矩阵计算单元，有的有向量单元，有的还分高算力核和低算力核。同一个GEMM算子，在N卡上是基于Tensor Core的cuBLAS kernel，在国产卡上则要基于各自的矩阵单元重写。写kernel只是第一步，还要调tiling策略、调流水、调重计算以减少访存。这活儿非常吃硬件知识积累，也是各家生态差距最深的地方。

我见过一个真实的性能对比：同一个BERT模型推理，固定batch size和序列长度，N卡在TensorRT下做得很好，完全静态优化；国产卡走动态shape路径，算子反复做shape推断和内存分配，延迟是前者的三倍。这说明算子库不只是"有"，还要考虑推理引擎场景下的静态化、图优化能力。

2.3 编译器与自动调优：降低算子开发门槛

算子库是人工优化的极致，但这门手艺稀缺。于是行业把希望寄托在编译器上。TVM、MLIR、Triton这些项目干的事，就是让开发者用接近Python的高级描述写kernel，再让编译器自动生成针对目标硬件的代码。

这套思路在国产芯片上格外重要。因为每家芯片的底层指令集、张量单元规模都不一样，手工生态覆盖不了所有模型。有了统一的编译器中间表示（IR），理论上可以做到：算子描述写一次，编译到不同硬件。

但实践中的坑是：编译器的自动调度在简单算子上表现不错，遇到结构复杂的融合算子（比如FlashAttention）、或者需要精细控制的访存逻辑，自动生成的代码往往不如手写kernel高效。所以现实策略是"编译器打底 + 手写kernel补漏"。我们项目里经常干的事，就是先用Triton风格快速验证一个算子变体的可行性，再决定要不要投入人力手写优化版本。

2.4 框架适配和运行时：应用看到的最后一公里

最靠近应用的一层，是框架适配层。PyTorch通过torch.autograd注册算子的反向传播，通过torch.library扩展自定义算子，后端的torch_npu、torch_musa等库负责把标准算子的调用转发到国产底层库。

这里有个很容易被忽视的细节：运行时管理。显存分配策略、异步kernel执行、跨设备通信的流（stream）管理，这些都会影响实际性能。很多时候两个算子库kernel本身的性能差距没那么大，差在框架适配层没有做显存复用，导致每个step都频繁分配释放显存，开销巨大。

我后来做性能分析时习惯先用torch.profiler抓kernel耗时和显存事件，再看哪些算子是"计算慢"、哪些是"等待慢"、哪些是"搬运慢"。很多瓶颈根本不是算子算不过来，而是上一层的显存管理和通信等待把算子的时间拖垮了。

3. 国产AI芯片算子生态的演进路线：兼容迁移、融合优化到自建体系

3.1 第一阶段：跑通模型，算子映射是捷径也是瓶颈

早期国产芯片生态最务实的策略是"兼容"。你PyTorch里写什么算子，我做一层映射，翻译成我底层库的算子在硬件上执行。这条路保证了迁移成本最低，模型改动小，从N卡切过来心理障碍也小。

但兼容策略走到深处会发现一个问题：生态是被动跟随的。NVIDIA定义了一套算子集合，国产芯片只能去"对齐"这些接口，中间既没有话语权，也没有差异化优势。而且接口兼容不等于性能兼容，PyTorch算子到N卡底层库有cuDNN级别的优化，映射到国产库时往往只是"能跑的版本"，性能差一倍都很常见。

更头疼的是算子缺失。早期很多国产加速卡连F.scaled_dot_product_attention都没跟上，只能在模型层面拆解成多个基础算子来拼，又慢又占显存。跑通模型只是第一步，跑得快才是真生态。

3.2 第二阶段：算子融合和内存优化，吃满硬件

到了第二阶段，各家开始从"有没有"转向"快不快"。重点变成了融合算子开发，目标只有一个：少搬运数据、多复用片上内存。

一个典型的融合案例是FlashAttention。传统Attention实现需要把中间的注意力矩阵写入显存，再读回来算Softmax和加权求和，显存访问开销巨大。FlashAttention通过对注意力分数分块计算、在线Softmax，把整个计算融合在一个kernel里，避免中间量落回HBM，速度和显存占用双双受益。

国产芯片要追赶，就得在各自的硬件上实现类似或者更进一步的融合版本。我在昇腾上跑LLM时，CANN自带的FlashAttention实现配合它的矩阵单元确实可以把Attention耗时压得很低。但融合算子的开发成本很高，每个算子都需要硬件专家和算法工程师反复调试，单靠厂商一家很难覆盖到所有形态的模型结构。于是就有了开源社区协作、第三方算子库补充的局面。

另外，内存优化也是一大块。推理引擎里常用PagedAttention管理KV cache，用静态shape减少显存碎片，用pinned memory加速数据拷贝。这些技术跟算子库的配合关系很强，如果底层算子不支持某些特殊内存格式，上层引擎就施展不开。

3.3 第三阶段：体系化自建，面向大模型重新定义算子

到了2025、2026年，国产芯片算子生态开始进入第三阶段：不再只跟着NVIDIA的算子清单走，而是从大模型的实际计算特征出发，自主定义算子边界。

大模型时代涌现了不少新算子需求：MoE（Mixture of Experts）里的专家路由和分片通信，MLA（Multi-head Latent Attention）里的低秩KV压缩，Mamba里的状态空间扫描（SSM），以及各种高效微调方法里的低秩适配算子。这些算子如果还等着框架层去翻译映射，研发节奏完全跟不上模型迭代。国产算子生态必须有"定义算子"的能力，而不是只做"实现算子"的搬运工。

这个阶段我看到的变化是：厂商开始发布面向LLM的专用推理引擎和配套算子库，给出标准化的大模型部署范式（预填充/解码分离、连续批处理、投机采样）。连续批处理（Continuous Batching）需要动态调度不同请求的KV cache分配；投机采样需要同时跑一个大型模型和一个小型草稿模型，它们的算子组合调度模式各不相同。这些都不是通用算子库能完全覆盖的，必须形成体系化自建的方案。

4. 迁移到国产芯片的一次完整实操复盘

理论讲了一堆，说说我实际操作中的一个完整迁移案例。项目背景是：把一个千亿参数规模的对话模型从NVIDIA GPU推理服务迁移到国产加速卡集群，目标是在保证精度和延迟达标的前提下，尽量压低单卡成本和集群总成本。

4.1 迁移前的调研：从部署目标倒推算子依赖

我的第一步不是切代码，而是盘点算子依赖清单。

把模型导出为ONNX或者用PyTorch的torch.jit.trace，然后跑一遍算子提取脚本，统计出来模型用到的算子种类、数量、耗时占比和shape分布。这一步很关键，因为真正决定生态瓶颈的是那些"高频+高耗时"算子，比如GEMM、Attention、LayerNorm，以及几个自定义的融合算子。

我列了一个优先级清单：

• P0：GEMM系列（Linear、Embedding、Score计算），必须高性能。
• P0：Attention相关（SDPA或FlashAttention融合算子），必须跟目标硬件的矩阵单元匹配。
• P1：Norm系列（LayerNorm、RMSNorm），融合实现以降低访存。
• P1：激活函数（GELU、SiLU等），通常是融合在GEMM里实现的。
• P2：自定义算子（RoPE、IndexPut、TopK等），如果目标库缺失，考虑改模型实现绕开。

同时还要确认部署形态：是动态batch还是静态batch？是否使用连续批处理？是否要支持投机采样？每个决策都会直接影响需要哪些算子变体。

4.2 算子替换与数值对齐的排查链路

迁移过程中最难的不是代码改动，而是"行为一致性"的验证。模型代码从import torch改成import torch_npu，再改device类型，三十分钟搞定。但跑出来的结果对不对、精度差多少，得一点一点抠。

我的排查链路如下：

1. 单算子级验证：对高频算子单独构造随机输入，对比N卡和国产卡的输出，记录最大绝对误差和相对误差。GEMM这种算子误差可能在1e-6量级，Softmax因为累加顺序不同可能到1e-5。这是正常的。但如果误差到1e-2级别，就说明算子实现有问题，比如累加用了低精度。
2. 小模型整图验证：用一个小配置（比如只跑一个Decoder层）走完整图，对比每一层的中间激活值。重点盯梯度消失、NaN、Inf这类异常信号。
3. 全模型单卡验证：跑通后再上全模型，验证loss曲线跟参考实现是否一致。
4. 多卡分布式验证：确认通信算子的数值一致性，排除allreduce顺序不同带来的误差累积。

我遇到的第一个坑是RoPE实现差异。原模型里RoPE是用复数乘法实现的，国产库的算子走的是不同的数学展开路径，结果是每个位置的旋转角度差了一个微小浮点误差。单层看不出来，堆到几十层之后，困惑度（perplexity）明显变差。最后只能在算子层做对齐，并给自定义RoPE算子补了一个融合的高性能版本。

另一个坑是masked softmax的数值问题。训练时用了attention mask，推理时某些实现会通过加负无穷大来屏蔽无效位置。国产算子库对-inf的处理和原来不一样，导致屏蔽位置偶尔传出一个非零值，推理结果在长文本场景偶尔崩。排查了很久才发现是算子对特殊值的处理语义没对齐。

4.3 性能调优的真实数据：从28%利用率到55%

跑通只是第一步，性能才是关键。第一次全模型跑通时，算力利用率（MFU）只有28%左右。这个数字在N卡部署时大概是55%~60%，差距巨大。我复盘了性能数据，问题出在几个方面：

• 数据搬运太多：模型里有大量小算子（Elementwise类），每个算子都要从HBM读一遍再写一遍。解决办法是算子融合，把多个Elementwise合并成一个：比如把Add、RMSNorm、GELU融合成一个大kernel，数据只访问一次。
• shape静态化不够：推理时动态shape导致每次launch都做shape推断和内存分配。我调整了部署策略，固定输入长度区间并padding到统一长度，配合静态图优化，kernel launch开销下降非常明显。
• 通信和计算没有重叠：多卡场景下，张量并行节点间的allreduce和后续计算完全串行。我把通信算子和计算算子放进不同stream里，并把部分计算重排到通信之前，把通信延迟藏进计算时间里。
• batch size不合适：国产卡的单卡显存比N卡方案小，我开始用大batch压测时直接OOM，后来改用PagedAttention和连续批处理，把不同请求的KV cache分页管理，显存利用率提升了40%。

调完一轮之后，MFU从28%提到了47%。接着又花了两个星期专攻GEMM算子的tiling参数和Attention算子的block size，才终于摸到55%，跟N卡方案打平。整个过程让我特别确信：算子生态的差距，一部分在厂商的库实现深度，另一部分在开发者的系统调优能力。

5. 算子生态的下一步：模型与芯片的协同，而不是生态从属

5.1 大模型结构变化倒逼算子重构

模型结构还在快速演进，算子生态也不可能静止。前几年大家都默认Transformer里的标准算子集合是"终点"，现在看明显不是。状态空间模型（Mamba）、混合架构（MoE+Attention+SSM）都在催生新的算子原语。这对国产芯片反而是机会——大家站在同一个新算子需求面前，谁先定义出高效的实现，谁就先拿到性能标杆。

我在做MoE模型部署时感受特别深。MoE的算力瓶颈不在矩阵乘法，而在专家路由的访存不规则性和通信开销。不同token路由到不同专家，每个专家处理的token数不固定，GPU利用率天然难拉高。国产芯片如果要在这个模型形态上做出特色，得从硬件调度和算子层面一起下手，比如软硬件协同实现动态路由的负载均衡。这已经超出了"照着CUDA生态抄一遍"的范畴，属于真正的差异化方向。

5.2 统一中间表示与开放标准的价值

算子生态要持续繁荣，只靠一家厂商闭门造车远远不够。行业里越来越多的人认识到统一中间表示（比如MLIR、ONNX）和开放算子规范的重要性。

为什么？因为模型和请求是多元的，不可能每出一个新模型，芯片厂商就马上补一个定制kernel。更现实的路径是：模型作者用开放描述语言写算子（类似Triton、Triton语言或者ONNX自定义算子），编译器自动适配到目标硬件，同时芯片厂商对高频算子提供手工优化版本作为"性能天花板"。

这对开发者也提出了新要求。只会调用torch.nn接口的时代可能还在，但如果你想在国产生态里做出差异化性能，就得理解算子描述、中间IR、自动调优这些概念。我团队里现在招人，特别看重候选人有没有写过自定义算子、有没有碰过编译器中间层，这比背多少模型结构更实用。

5.3 给后来者的三点建议

作为踩过不少坑的过来人，我给打算入局国产AI芯片生态的同行几个建议：

第一，从算子列表入手，不要从模型入手。拿到一个新模型，先做算子依赖分析，搞清楚你的目标硬件上哪些算子有高性能实现，哪些只能凑合跑。这个前置盘点可以帮你省掉后面一半的迁移时间。

第二，重视精度对齐，但不要追求无误差。浮点计算在不同硬件上有微小差异是正常的，你要做的是评估这个差异对最终任务指标影响有多大，而不是在算子层追求逐bit一致，那会消耗大量精力。

第三，把性能调优当成算子生态的一部分。不要一骂"生态不行"就完事。实际操作中，很多性能问题可以通过算子融合、通信重叠、显存复用这些手段解决。调优能力本身就是算子生态的延伸，也是你个人的核心竞争力。

个人体会最深的一点是：算子生态的构建不是芯片厂商单方面的事，下游开发者使用中反馈的每一个算子缺失、每一次性能数据对比，本质上都是在帮生态演进。与其等着生态成熟再入场，不如作为早期参与者，和国产加速卡一起长大。