让AI学会给昇腾NPU调优！复旦联手华为小艺，算子生成成功率达95.5%

把模型部署到昇腾 NPU 上，计算逻辑确定之后，还有一道难题：怎样让底层实现充分利用硬件？同一个注意力计算，分块、搬运、并行和同步方式不同，运行时间就可能明显不同。

大模型能够生成代码，Coding Agent 还能调用工具、编译运行并迭代修改，但当其面对知识储备不足的硬件平台，应该怎样完成编译、纠错到性能优化的完整流程，再把经验用于下一个算子？围绕这个问题，复旦大学与华为小艺团队提出 SAGE，将知识冷启动、工具增强诊断与经验学习连接起来。

• 论文标题：From Experience to Expertise: Adoption-Aware Memory Learning for Data-Scarce NPU Kernel Synthesis
• 论文链接：https://arxiv.org/pdf/2609.35568

一、从代码生成到高性能实现，还缺什么？

1. 算子开发为什么需要硬件经验？

深度学习模型中的矩阵乘法、归一化、注意力等计算，最终都由硬件上的程序执行。算子内核（kernel）就是承担这些计算的底层实现。数学公式描述 “算什么”，算子开发还要决定 “数据放在哪里、每个核处理多少工作、搬运和计算怎样配合”。

对工程师而言，优化往往涉及几类判断：

• 数据分块：一个张量不能总是一次放进片上存储，需要拆成合适大小的块；块太大可能超过容量，太小又可能增加搬运和调度开销。
• 并行划分：任务能否分给更多计算核，核之间是否均衡，有没有只用到少量核的情况。
• 搬运与计算：能否减少中间结果的重复读写，或者让数据准备与计算重叠。
• 同步依赖：哪些等待是保证正确性所必需的，哪些等待过于保守，限制了流水执行。

这些选择相互影响。改变分块可能需要重新安排缓冲区；增加并行度可能改变同步关系；减少一次数据块搬运，也可能要求调整后续计算的读取方式。一个能运行的实现，只是性能优化的起点。

2. Agent 怎样完成这条开发流程？

本文中的 Coding Agent，是能够写代码、调用工具并依据反馈迭代修改的大模型开发助手。算子开发包含以下环节：

• 生成实现：根据输入、输出和计算逻辑，组织 host 侧配置与 kernel 侧代码。
• 编译修复：处理接口、类型、模板参数和配置问题，得到可执行候选。
• 正确性验证：在真实设备上运行，与参考结果比较，检查数值误差及运行异常。
• 性能优化：建立正确版本的时延基线，定位瓶颈，尝试更快的实现。

每次修改都可能重新引入错误，因此优化后的候选仍要重新编译、验证和测量。同步少了一次，程序可能快了，也可能读取尚未写完的数据；并行多开几个核，可能提升吞吐，也可能破坏工作划分。性能收益必须建立在正确性通过的基础上。

这也意味着，Agent 不仅需要代码生成能力，还需要理解诊断信息、选择工具、保留测试记录，以及从多次尝试中识别可复用的做法。

3. 已有方法走到了哪一步？

大模型算子开发已经形成了几条互补路线。理解它们各自解决的问题，有助于看清 SAGE 的出发点。

这些路线已经让模型从 “一次生成” 走向 “在设备上反复验证”。但在公开代码较少的平台上，仍然需要解决一个基础困难：模型在熟悉平台上的能力，不能直接等同于它在新硬件上的开发能力。

论文引言引用的一项研究报告显示：GPT-5.2 在 KernelBench Level-1 任务上的 CUDA 正确率为 92%，Ascend C 正确率为 14%，相差 78 个百分点。这组已有研究的数据说明，迁移到昇腾时，需要补充的既有 API 用法，也有内存层次、计算单元协作（如 AIC 与 AIV）和同步约束等硬件知识。

二、我们希望集中解决三个问题

第一，硬件知识不足，原始资料也难以直接变成开发经验。

• 模型知识现状：大模型面对陌生硬件时，可能知道某个接口的名称，却不清楚它与完整实现的关系。能够阅读一些专家代码，但不代表已经理解其适用条件。
  
• 后训练之外的路：后训练需要足够多的高质量数据，比较困难，而外部知识提供了另一条路径：构造初始知识，并从实现对照中提炼能指导后续开发的规则。
  
• 难点和解法：仅把长篇文档放进上下文，仍然需要模型在当前任务中完成筛选和理解。我们希望让基础知识文档承担明确职责，再通过生成实现与专家实现的对照（后面会介绍的差分学习），提炼具体的开发模式。

第二，测试反馈往往不足以定位错误，也不足以确定优化方向。

• 反馈信号 1：编译信息 & 精度：编译日志通常包含接口、类型或代码位置等信息，精度测试则主要返回 tensor 结果、输出差异或 runtime error。它能说明实现未通过测试，却难以定位错误发生在哪个计算阶段，或是否源于数据搬运与同步依赖。
  
• 反馈信号 2：性能数据：性能测试也有类似困难。一个 latency 数值能回答 “当前实现用了多长时间”，却难以回答 “下一步应该改什么”。总时延包含有效计算，也可能包含数据搬运、核间等待及不必要的同步。同样是慢，搬运过多、并行不足和等待过长，需要不同的优化动作。
  
• 反馈方案：需要设计一套 Harness，让 Agent 调用 debug tools 和 profiling tools --> 编译 / 执行 --> 精度测试 --> 性能测试 --> 定位错误与性能瓶颈分析。

第三，记忆系统要能准确评估经验价值，并持续自进化。

• 记忆系统：已有记忆方法将正确性测试和性能测量结果转换为数值反馈，用于更新经验价值评分：修复成功或时延下降提供正向反馈，失败提供负向反馈。一次迭代的测试结果应当怎样分配给不同经验，才符合它们的实际使用情况？背后需要一套专家记忆自进化系统。
  

• 核心问题：

• 经验检索：上千条经验一股脑塞到 Agent 的 Context 不现实，经验需要检索匹配。
  

• 经验标签：怎么知道这个经验是用于优化什么类型的算子、是用在语法诊断还是性能优化，经验需要有一套标签机制

• 经验应用：检索出来的经验，需要有一套 Harness 去配合 Agent 实现目标代码优化。

• 经验更新 & 进化：检索系统通常是按语义检索出相近的经验，但相关性高并不能代表能有效地解决当前的问题，需要设计 Reward 信号的分配策略。见图 1（a），之前的 SOTA 对这一批经验无论是否被使用，都给同样的 Reward，并且经验在不同算子之间无法复用；见图 1（b），我们则认为只有被采纳的经验才有 Reward 信号，不同算子间的经验可以共享。

• 热经验机制：常用的经验可以固定放到一个区域，这样在优化某个算子的时候，省去了反复检索和匹配的开销。但 context 有限，因此，需要选择通用经验 --> 提炼为简洁规则 --> 长期不用需要清理。

• 经验系统冷启动：冷启动就像大模型的 SFT，从现有的算子数据中，快速适配一把，成本低见效快。经过冷启动的系统，能在 Level 1 和 Level 2 的任务有更好的表现，能够处理 Level 3 的部分问题。

这三个问题对应四块相互衔接的工作：知识冷启动、工具增强诊断、经验价值评估与通用规则巩固。系统保留经验的适用条件、采用记录与测试结果，新任务中的有效性仍由设备验证。

图 1｜上半部分：检索四条经验、只采用一条，测试反馈应怎样用于经验价值评估；下半部分：采用的该条经验在不同算子中反复有效后提炼为常驻规则。图中的 Reward 表示由测试结果得到的评分反馈

三、知识冷启动：从文档整理到差分挖掘

第二节的第一个问题就是硬件知识不足。Agent 一开始面对的是陌生的昇腾平台，此时没有任何历史修复和调优记录可查：Ascend C 的原始语法和 API 文档篇幅长，直接塞进上下文既占空间，又难以落到 “这个接口在完整算子里怎么用” 的层面。冷启动要解决的，就是在系统还没有任何经验时，给开发一个可用的硬件知识起点。SAGE 的做法分两步：先人工整理职责明确的基础文档，再通过实现对照挖掘文档给不出的模式。

1. 先准备三份职责明确的基础知识文档

系统冷启动时尚无历史修复和调优记录。我们从官方 Ascend C API 文档、算子开发工具指南和最佳实践中蒸馏并人工整理知识，形成三份轻量参考文档，作为开发与调试的基础知识入口：

• Ascend C 速查表：帮助查找接口、基本约束和常见用法，减少开发过程中的基础知识缺口。
• 调试指南：帮助理解错误类型，选择可以获取 0 进一步证据的工具和检查方法。
• 实现示例：提供完整算子的组织参考，让模型理解 host 侧配置与 kernel 侧计算怎样衔接。

这三份文档分别支持接口使用、故障排查和完整实现组织，经过人工整理后作为自动开发的共同起点。

2. 差分挖掘：通过实现对照，补充文档难以直接给出的模式

有了基础知识文档后，我们让 Agent 生成简单的 Level-1、Level-2 算子。当生成实现编译成功后，再与专家实现进行对照，从差异中提炼可复用的实现模式，写入冷记忆。

差分挖掘分析同一计算的不同实现，将代码差异与硬件约束联系起来，再提炼经验及其适用条件：

• 生成实现与专家实现：提供可以直接比较的代码对象。
• 差异及硬件原因：分析实现组织、数据处理或执行依赖为什么不同。
• 可复用模式：将对当前代码的观察转为后续开发能够查阅的经验。
• 适用条件：说明规则在什么情况下值得参考，避免把一种写法当作通用答案。

例如，分块差异需要结合片上容量、搬运粒度和尾块处理解释；同步差异需要检查数据依赖是否满足。提炼出的模式以实际代码和硬件约束为依据。

图 2｜冷启动知识构造：整理基础参考，生成简单算子，在编译成功后对照专家实现，再将可复用模式写入冷记忆

四、工具调用：从 “测试失败” 到 “知道下一步检查什么”

1. 用不同工具回答不同问题

最终输出和总时延能判断正确性与性能，却难以定位原因。为此，我们向 Agent 提供可以自主调用的调试和性能分析工具：

调试工具帮助回答 “哪里可能出错”，性能分析工具帮助回答 “时间主要花在哪里”。它们补充了测试结果，却仍需要结合代码和硬件知识解释。

检查中间 tensor 可以区分输入读取、计算与同步问题；分析执行过程可以判断并行利用、等待与搬运开销。工具由 Agent 自主调用，形成提出假设 → 获取诊断证据 → 定向修改 → 重新验证的闭环。

2. Mla 案例：中间结果怎样帮助定位错误？

论文中的 Mla 是一个融合注意力算子，包含矩阵计算、softmax、位置编码和后续矩阵乘法。它需要不同计算单元协作，也需要保证每一步读取的数据已经准备好。

最初的实现遇到了计算配置与执行挂起问题。Agent 先分开不同矩阵计算的配置，修正计算任务类型；随后，将单个 token 的路径单独检查，再处理循环中的跨核同步关系。挂起被解决后，问题进一步表现为可检查的数值不一致。

真正关键的线索来自 DumpTensor 显示 softmax 输入为零。最终输出测试只能说明整个算子有误，而中间结果告诉我们，应回到 softmax 之前检查数据和计算路径。后续修复涉及：

• 等待异步矩阵计算写入完成，保证后续读取时数据已经可用。
• 处理非连续输入布局，使用 AutoContiguous ()。
• 补全位置编码相关维度，建立完整的 Q/K 表示。

这些修改共同形成首个正确实现。中间结果将问题范围缩小到特定计算阶段，再结合输入布局与同步依赖定位具体原因。

3. 正确之后，诊断目标转向性能

得到正确实现后，Agent 需要建立时延基线，再围绕瓶颈尝试改进。Mla 后续主要沿三个方向优化：

• 减少不必要的等待：将过于保守的全局屏障替换为满足依赖的事件同步。
• 提高并行利用：按 query token 将工作分配到多个核。
• 减少中间搬运：调整后续矩阵计算的读取路径，避免一次中转拷贝。

其中一次双缓冲尝试破坏了搬运依赖，因而被回退。某种优化技巧是否有效，取决于当前实现的依赖关系。诊断证据、知识规则和正确性测试需要一起参与判断。

经过验证的修复路径、优化做法和适用限制可以进入经验库，供后续任务参考。Mla 各阶段的性能收益将在实验部分展示。

五、经验学习：

评价实际使用效果，保留可复用规则

SAGE 将完整经验保存在冷记忆中，按需检索；将经过验证并提炼的规则放入热记忆，直接提供给后续任务。两者分别类似 “详细开发笔记” 和 “常用开发准则”。

图 3｜Agent 结合检索经验、常驻规则与设备反馈开发算子；ATU 更新经验价值评估，UGC 在有限上下文中选择和更新通用规则

1. ATU：哪些经验真正参与了开发？

采用追踪效用估计（Adoption-Traced Utility Estimation，ATU），将实际采用记录与测试结果结合，用于更新经验价值评估。

• 先记录采用情况，再分配阶段评分

• 价值评分既要稳定，也要能被新证据修正

• 让价值影响检索，同时保留相关性的主导作用

相关性回答 “是否与当前问题有关”，经验价值评估回答 “实际使用证据是否支持优先参考”。采用记录说明经验参与过诊断或修改，不能单独证明其独立贡献，需要与阶段结果共同形成评价依据。

2. UGC：哪些经验值得成为常用准则？

效用门控巩固（Utility-Gated Consolidation，UGC），进一步决定哪些经验应当进入常驻上下文，以及何时让出空间。

先要求跨算子证据，再衡量常驻空间的价值

经验需要价值评分为正、至少被采用 3 次，并覆盖至少 3 个不同算子，才进入巩固候选。重复采用减少单次使用的偶然性，跨算子覆盖则避免把同一任务中的多轮尝试直接当作通用性证据。Agent 随后提炼简洁规则，源经验与规则共享标识和价值评分。

• 固定容量，并让长期不用的规则逐步退出

被替换的规则退回可检索状态，源经验与历史记录继续保留。ATU 评价使用效果，UGC 再结合复用频率和文本成本分配常驻空间，形成冷记忆与热记忆之间的双向更新。

上述参数依据其数值作用与初步系统稳定性统一设定，所有基础模型与算子使用同一配置，没有逐模型或逐算子调优。

六、实验配置与结果：性能收益体现在哪里？

1. 硬件、预算和测量口径

实验在 Ascend 910C 上进行，候选算子接受真实硬件的编译、正确性与性能验证。主要配置如下：

• 设备资源：每台服务器 8 张加速卡、共 16 个 accelerator dies；每个算子评测 worker 分配一张卡。
  
• 软件环境：ARM64、Huawei Cloud EulerOS 2.0、CANN 8.5.1、驱动 25.5.1、Python 3.11.14、torch_npu 2.9.0。
  
• 模型服务：通过 vllm-ascend 0.18.0rc1 本地部署；DeepSeek-V4-Flash 使用 DP=4、TP=4，GLM-5.2/5.3 使用 TP=16。
  
• 交互预算：通过 Claude Code 组织开发流程，每个算子最多 30 轮，正确性修复与性能优化共享预算。

模型服务与算子评测使用不同的资源配置，单卡 worker 描述候选算子的执行资源。时延采用设备端 NPU Event 测量：预热 5 次，计时 100 次，报告平均值；候选与 torch_npu 使用相同输入及计时边界。NPUKernelBench 正确性要求最大绝对误差和最大相对误差均不超过 10⁻³。

2. Mla：从 0.420 ms 到 0.155 ms

在 Mla 的开发轨迹中，Agent 经多轮修复获得首个正确版本，随后利用剩余预算继续优化：

首个正确版本到最佳版本的自身加速为 2.71 倍，按报告时延计算，下降约 63.1%。这条轨迹体现了减少等待、提高并行度和减少搬运的组合收益。

3. 主实验：更多正确实现，也有更多实现快于参考

主实验覆盖 NPUKernelBench 的 88 个算子。四种配置共享基础模型、初始知识、工具、交互预算和评测环境，比较重点是记忆机制：

• Refinement：在当前算子内迭代，不保留跨任务经验。
• Static RAG：检索固定知识库，不继续写入经验或更新价值评分。
• Value Memory：参考 EvoKernel（ICML2026）的值驱动记忆机制，持续积累经验，对同轮检索经验采用相同的测试评分目标，再利用价值评分调整检索排序。
• SAGE：结合实际采用情况评价经验，并选择、更新常驻规则。

指示函数在最佳实现严格快于对应 torch_npu 实现时取 1，否则取 0；两项指标均按已解决算子统计，但比较基线分别是 torch_npu 与首个正确实现。

4. Backbone 能力：经验能否转化为性能收益？

外部记忆提供硬件知识，基础模型（backbone）仍负责理解诊断、修改代码和选择优化方案。采用同一 SAGE 机制与交互预算，三个模型的结果差异显著：

模型差异同时体现在正确性覆盖与迭代优化幅度：三者分别解出 1/18、8/18、16/18 个 Level-3 算子，自身优化加速中位数为 1.27、2.08、4.47 倍。Agent 需要理解工具反馈、判断经验的适用条件，并协调布局、搬运与同步修改；这些工作仍依赖模型能力。在共享的 30 轮预算中，较早获得正确实现也能留下更多优化机会，但实验未单独量化这一因素的贡献。

跨模型记忆迁移进一步区分了知识与模型能力的作用。在同一 88 算子的只读重评中，接收模型使用 GLM-5.2 积累的记忆，评测期间不再更新记忆：

• DeepSeek-V4-Flash：相对自身演化的记忆，ER 从 64.8% 提高到 72.7%， 从 64.9% 提高到 71.9%。
  
• Qwen3-Coder-Next：ER 从 31.8% 提高到 40.9%， 从 28.6% 提高到 38.9%。

迁移提升说明更强模型积累的经验具有复用价值；但接收模型仍未达到 GLM-5.2 的表现，表明经验质量与运用经验的能力共同影响结果。工程选型应同时考察模型服务成本、正确性覆盖和优化幅度。这里反映的是具体模型的综合差异，未分离参数规模、训练数据等因素的作用。

5. 任务顺序：先积累较简单任务的经验是否更有效？

论文固定选取 25 个 Level-2 算子和全部 18 个 Level-3 算子，比较三种任务安排。各组从相同初始记忆开始，使用相同的单算子预算，任务结束后更新记忆且不重复求解；结果只统计 Level-3，在对应经验写入前记录。

混合执行与先后执行使用相同的 43 个任务，因此后两组更直接反映顺序的影响：先完成 Level-2 后，Level-3 ER 比混合执行高 16.7 个百分点， 高 7.8 个百分点。仅处理 Level-3 的组不含额外的 Level-2 开发过程。结果支持先积累较低难度经验、再处理复杂算子的安排；这是独立任务流，统计范围与主实验不同。

6. 更复杂的任务与机制验证

在 xCCL 的 16 个更复杂算子上，系统继承已有记忆并继续更新。使用 GLM-5.3 时，正确解出数量由 GLM-5.2 的 11/16 提高到 13/16。在两者都解出的 11 个算子上，相对 torch_npu 的加速中位数从 3.32 倍提高到 7.32 倍；稀疏注意力算子 sparse_flash_attention 从 23.35 倍提高到 43.99 倍。这说明差异既涉及覆盖范围，也涉及同一任务上的优化质量。

GLM-5.3 在全部 13 个已解出算子上的加速中位数为 10.86 倍，其统计集合与上述配对结果不同。

图 4｜xCCL 已解出算子的加速比，虚线表示与 torch_npu 持平

在 GLM-5.2、88 个算子的消融设置下，完整 SAGE 的  为 86.9%；去掉 UGC 后为 82.7%，随机选择常驻规则为 78.8%，对所有检索经验采用相同阶段评分为 79.2%。这些结果支持结合实际采用情况评估经验价值，并有依据地选择常驻规则。

收益仍然随任务变化。GLM-5.2 在正确通过的 Level-3/GMM 任务上，相对 torch_npu 的加速范围为 0.38—71.41 倍，其中也有慢于参考的实现。因此，应结合覆盖比例与典型优化幅度判断效果，单算子结果还需要进一步验证能否转化为实际模型的端到端收益。

七、权衡与未来工作

SAGE 将初始硬件知识、工具增强诊断与经验更新结合起来，让 Agent 可以在自我迭代中持续优化昇腾算子并积累经验与可复用知识，但面向实际工程部署时，还有几类工作需要推进：

• 更复杂的融合算子与更长调优流程：联合探索布局、调度、搬运与同步，保留多条候选路径，避免过早固定实现方案。当前 30 轮设置尚未覆盖长周期的复杂融合内核开发。

• 可追踪的共享经验库：保存规则来源、代码修改及测量记录，支持多人协作；明确适用条件，并处理软件版本变化、规则冲突和过时知识。

• 更多输入与硬件配置：扩展不同 shape、dtype 与芯片架构下的优化，检验哪些旧经验可以复用，哪些需要重新验证。

• 完整开发成本：同时统计模型调用、编译、设备评测和记忆维护的时间与资源，衡量性能收益与开发投入的关系。

• 端到端效果与工具链集成：将生成算子接入实际模型及现有开发流程，测量整体时延、吞吐和尾延迟，并保留性能回退路径。

作者简介

第一作者：范珑骁，复旦大学计算智能与创新学院在读博士生，师从孙未未教授，研究方向包括大模型高效推理，Agent 自进化系统等。

文章来自于"机器之心"，作者 "范珑骁"。