华为Ascend写算子有多痛，这篇论文用Agent自己干了

2026年7月30日

做 AI 基础设施的人都清楚一个尴尬事实：CUDA 生态太厚了，但凡换个硬件平台，写算子的成本直接翻几倍甚至翻十几倍。华为 Ascend NPU 就是典型——910B 性能不差，但 Ascend C 的编程模型跟 CUDA 差别很大，社区积累薄，翻半天可能都找不到一个可以参考的实现。

7月29号上 arXiv 的一篇论文直接冲着这个痛点来的。题目叫 AgenticCANN: Automated Ascend C Operator Generation via Knowledge-Augmented Agentic Evolution，简单说就是让 LLM Agent 自己写 Ascend C 算子，写完还能自己迭代优化。

为什么非要折腾 Ascend C

大模型推理在国产 NPU 上跑，一个绕不过去的坎就是算子。Ascend C 是华为给昇腾 NPU 提供的编程语言，对标 NVIDIA 的 CUDA。但 CUDA 有二十年积累，GitHub 上几万个 kernel 示例，出问题了随手一搜就有答案。Ascend C 呢？论文里用的词是 "low-corpus NPU environments"——语料库严重不足。

之前业界用 LLM 自动生成 CUDA kernel 已经有些进展，但这波直接平移不过去。因为 Ascend C 的内存模型、调度方式、向量化指令集跟 CUDA 根本不是一个路子。LLM 在 CUDA 上学到的知识，在 Ascend C 上基本帮不上忙。

AgenticCANN 的核心思路是：不给 LLM 直接扔问题让它写代码，而是先灌一套结构化的硬件领域知识进去，再用多阶段的 Agent 演化策略来生成和调优。

知识注入才是真门槛

在做 elementwise 算子生成时，不注入知识的情况下 feasibility（生成能跑通的算子的比例）是 57%，注入知识后提升到了 86%。作者强调这个提升是普适性的，不是只对某个特定算子有效。

这套知识系统不是简单丢几篇文档进去，而是按开发全生命周期分层组织的——从上游的可行性判断（这个算子在 Ascend C 里能不能写、怎么写），到中游的代码生成，再到下游的性能调优。相当于给 Agent 配了一个芯片手册的「私教」，在每个阶段告诉它该注意什么。

演化策略：先发散再收敛

AgenticCANN 采用了 stage-adaptive agentic evolution 策略。LLM 做代码生成时有一个矛盾：探索阶段需要发散，多试不同的实现路径；调优阶段需要收敛，精准地对性能瓶颈下手。AgenticCANN 把这两个阶段分开处理，在前几轮大胆试错，后期再聚焦优化。

最终在华为 Ascend 910B 上测了 6 个算子，覆盖 5 种算子模式类别。elementwise 和 normalization 算子可行性达到 90-100%，fusion 算子 56%。在 1B 参数的 Pangu 模型推理 kernel 上，最高跑出了 6.65 倍加速。

这事意味着什么

对于正在 Ascend 上做推理部署的团队来说，这个方向如果真能落地，最直接的价值是不用再养一个专门的算子开发团队。很多长尾算子、小众融合算子，以前写一个要一两周，调通又一两周，现在可能 Agent 跑几轮就出来了——未必最优，但能跑、能用、性能不差。

论文目前还是学术阶段，离产品化还有距离。fusion 算子 56% 的可行性说明复杂场景下 Agent 仍然容易翻车。而且论文实验规模不算大，6 个算子覆盖有限，真正到生产环境的算子库可能需要更扎实的验证。

不过在降低算子生成门槛这件事上，这个方向切中了要害。大模型推理部署的瓶颈往往不在硬件峰值算力，而在软件生态的成熟度。后续有没有开源代码、能不能在更复杂的算子上复现这个结果，值得持续关注。

相关链接
- 论文页面：https://arxiv.org/abs/2607.26661