把模型部署到昇腾 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），将实际采用记录与测试结果结合，用于更新经验价值评估。
先记录采用情况，再分配阶段评分
Agent 对每条检索经验记录 “采用／未采用” 及理由，评测前必须补齐记录。一个阶段可以包含多轮修改，经验的作用可能直到最终实现才显现，因此阶段结束后再汇总、去重并评分。令 为检索经验集合， 为其中至少被采用过一次的经验集合。
正确性阶段通过验证，阶段得分 ；优化阶段取得改善时，，其中两项时延分别对应最佳正确实现与首个正确实现。使用相对时延下降比例，让不同运行尺度的算子都能按改进幅度评价。失败或未取得改善时，使用 ，论文设置 。
对每条经验 ，本次反馈为：
这里 是采用经验的条数。存在采用条目时，平分使其反馈总量等于阶段得分，避免仅因采用条目更多就增加总分。例如从 1 ms 降到 0.6 ms，得分为 0.4；采用两条经验时各得 0.2，未采用的检索经验各得 −0.2。负向反馈保持较小幅度，因为阶段失败或未采用，均不足以说明一条硬件经验本身有害。
价值评分既要稳定，也要能被新证据修正
经验价值评分 从 0 开始，将历史评分与本次反馈加权组合：
是按阶段去重的累计检索次数， 控制本次反馈的权重。检索记录增多时，更新幅度减小，减少单次结果造成的波动；论文设置 ，保证新反馈至少保有 5% 的权重。这样，任务类型或上下文变化后，旧经验的评价仍能调整，避免历史评分长期固化。更新是历史评分与本次反馈的加权平均，因此评分也始终处于反馈范围 内，为后续检索重排提供数值边界。
让价值影响检索，同时保留相关性的主导作用
系统先按相关性取得候选池，再用价值评分重排：
为当前问题的相关性评分， 控制历史价值的调节强度。按上述设置， 保持在 ，乘数范围为 ：历史效果可以调整相关候选的排序，但调节幅度受控；候选池本身仍只由相关性决定。
相关性回答 “是否与当前问题有关”，经验价值评估回答 “实际使用证据是否支持优先参考”。采用记录说明经验参与过诊断或修改，不能单独证明其独立贡献，需要与阶段结果共同形成评价依据。
2. UGC：哪些经验值得成为常用准则？
效用门控巩固（Utility-Gated Consolidation，UGC），进一步决定哪些经验应当进入常驻上下文，以及何时让出空间。
先要求跨算子证据，再衡量常驻空间的价值
经验需要价值评分为正、至少被采用 3 次，并覆盖至少 3 个不同算子，才进入巩固候选。重复采用减少单次使用的偶然性，跨算子覆盖则避免把同一任务中的多轮尝试直接当作通用性证据。Agent 随后提炼简洁规则，源经验与规则共享标识和价值评分。
候选还需要与已有常驻规则竞争空间。UGC 按单位上下文长度对应的价值排序：
是经验价值评分， 是估计访问频率， 是规则占用的 token 数。冷记忆阶段，频率由“检索次数／有资格被检索的阶段数”估计。乘以频率，是让常驻空间优先服务经常需要的知识；除以长度，是考虑持续提供该规则的上下文成本。同样有效且常用时，表达紧凑的规则更适合常驻。
固定容量，并让长期不用的规则逐步退出
常驻预算设为 10K tokens，限制热记忆随任务积累而增长。每次更新将已有规则与新候选合并，按 排序，从空集合开始重建：能放下就加入，放不下则跳过，继续检查后续候选。因此，新旧规则按同一标准竞争，较短的候选也有机会进入。
常驻规则绕过检索，访问频率改按实际使用情况更新：
指示函数在本阶段使用该规则时取 1，否则取 0。 控制频率估计对近期使用情况的响应速度：取 0.1 时，保留 90% 的历史估计，再加入 10% 的本阶段信号，平滑近期变化，减少单次未使用对优先级的影响。连续 7 次更新未使用时，频率估计约降至原来的 48%；在价值评分与长度不变时，常驻优先级也按相同比例下降。
被替换的规则退回可检索状态，源经验与历史记录继续保留。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：结合实际采用情况评价经验，并选择、更新常驻规则。
指标分别回答三个问题：ER 看预算内正确解出多少算子； 看已解出的算子中多少快于 torch_npu；自身优化加速看首个正确版本到最佳版本的加速比中位数。
令 为已正确解出的算子集合，两个性能指标与论文一致：
指示函数在最佳实现严格快于对应 torch_npu 实现时取 1，否则取 0；两项指标均按已解决算子统计，但比较基线分别是 torch_npu 与首个正确实现。
SAGE 正确解出 84/88 个算子。相对 Value Memory， 提高 11.2 个百分点，自身优化加速中位数从 3.36 倍提高到 4.47 倍。这里比较的是统一框架中的记忆机制，冷启动知识与诊断工具没有单独进行增益测量。
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 自进化系统等。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
