体系结构论文（107）：AscendOptimizer: Episodic Agent for Ascend NPU Operator Optimization

AscendOptimizer: Episodic Agent for Ascend NPU Operator Optimization这篇文章讲的是什么这篇文章关注的是华为 Ascend NPU 上的 AscendC operator optimization。它不是做“从零生成一个 kernel”而是做如何在极度缺少公开经验、缺少训练数据的情况下把已有 AscendC operator 持续优化得更快。作者提出的核心系统叫 AscendOptimizer。它把一个 Ascend operator 拆成两个耦合部分1. host 侧的 tiling program2. device 侧的 kernel program然后分别用两种不同策略去优化1. Stage I对 host 侧 tiling 做 evolutionary-guided program search。2. Stage II对 kernel 侧代码做 optimization rewind experience retrieval guided rewriting。最后在这两个阶段之间交替迭代。简单说这篇文章的核心观点是Ascend 上最缺的不是“一个万能模型”而是“能自己积累优化经验的机制”。为什么 Ascend operator 优化难1. Ascend 和 CUDA 的差异不只是语法差异文章在引言里借 Table 1 强调了一件事通用甚至前沿模型在 CUDA 上还能做出像样结果但在 AscendC 上几乎崩掉。Table 1 里1. DeepSeek-R1 在 CUDA 上 Pass1 为 52.6%在 AscendC 上只有 1.4%。2. Claude Sonnet 4 在 CUDA 上 47.0%在 AscendC 上 2.1%。3. Qwen3-235B 在 CUDA 上 44.2%在 AscendC 上 0.7%。这不是“差一点”而是两个数量级的差距。作者认为这背后不是简单的语法问题而是知识稀缺问题1. Ascend 公开实现少。2. host-kernel 协同知识难学。3. buffer、tiling、pipeline、同步这些低层细节不在通用语料里。2. Ascend operator 不是一段单体 kernelAscendC operator 是一个“两段式工件”1. host 侧 tiling program决定怎么分块、怎么搬数据。2. device 侧 kernel code决定怎么调度计算、怎么做 pipeline。很多小白会误以为“kernel 优化”就是改 kernel 本体但在 Ascend 上不是。性能往往由这两部分共同决定。所以文章不是把优化问题看成“改一段代码”而是看成一个 host-side tiling device-side kernel 的联合优化问题。3. 为什么不能只靠传统搜索因为这个空间非常离散、非凸而且充满隐式约束1. tile 稍微改一下就可能 UB 爆掉。2. 某个数据搬运策略改一下就编译失败。3. kernel 层面的同步、映射、pipeline 又有另一套结构性规律。所以作者认为1. tiling 更像强约束、离散、脆弱的程序搜索问题。2. kernel rewrite 更像结构化模式迁移问题。这就是后面双阶段设计的理论基础。一. Introduction作者先从大模型训练和推理开讲说现在模型越来越大算力越来越关键而operator 是 computation graph 的原子执行单元它直接影响训练吞吐在线推理延迟。这段的意思很标准硬件峰值再高算子写得差实际性能也起不来。为什么需要自动优化作者指出未优化算子通常吃不到硬件性能原因包括memory bandwidth wall复杂的 instruction pipeline constraints编译成功率低profiling 噪声大。所以“算子自动优化”就成了一个桥梁问题一边连接上层算法一边连接底层硬件。为什么 GPU 上好做Ascend 上难做这一部分是全文最重要的逻辑铺垫。CUDA 生态为什么能成功作者说 NVIDIA GPU 这边已经形成了一整套自动优化技术路线早期TVM、Ansor 这种搜索型 autotuning后来Astra、PRAGMA 这种 LLM/agent 驱动优化再往后基于 profiling、compiler feedback、硬件反馈的闭环优化。关键原因不是“GPU 更容易”而是GPU 有大量开源代码提供了丰富的隐式优化模式。换句话说CUDA agent 能做起来很大程度上是因为训练语料和先验太丰富了。为什么迁移到 Ascend 很难作者紧接着指出把这套自动化方法照搬到 DSA/NPU 上会遇到严重问题尤其是 AscendAscend 用的是Da Vinci architecture它有显式管理的 memory hierarchy不像 GPU 靠 cache 自动帮你处理很多事AscendC 需要开发者自己 orchestrate数据搬运UB 中数据布局同步。这里你可以把它理解成GPU很多细节被 runtime / compiler / cache 屏蔽了Ascend很多细节要你亲自管所以对 agent 来说Ascend 优化更难因为它不是纯粹“写个 kernel”就完事而是得知道UB 容量约束tile 怎么切同步怎么放pipeline 怎么铺搬运和计算怎么重叠这属于更强的硬件感知软件优化。作者说一个 AscendC operator不是单体 kernel而是一个two-part artifacthost-side tiling programdevice-side kernel programhost-side tiling program 干什么它决定输入怎么切块一个 tile 多大数据怎么搬到片上搬几次搬运和执行如何匹配这本质上决定的是“where data move”kernel program 干什么它决定指令怎么发计算怎么流水化SIMD / vector 指令怎么用同步点怎么安排这本质上决定的是“how instructions flow”为什么单改 kernel 不够作者明确说porting a kernel is insufficient: performance is co-determined by where data move and how instructions flow.它的意思是在 GPU 上你可能常常把优化理解成“把 kernel 写得更好”但在 Ascend 上kernel 再好tiling 不对也会慢因为数据搬运和片上 buffer 利用本身就是性能决定因素所以这篇文章不是单纯做 kernel rewrite而是在做host tiling device kernel 的联合优化Table 1 给了一个非常关键的数据同样是 SOTA 大模型CUDA kernel 的 one-shot generation pass rate 还能到 44%52%而 AscendC 只有 0.7%2.1%。这张表的意义作者用这张表不是为了说“模型太弱”而是为了证明Ascend 上的问题不是单纯语法问题而是知识稀缺问题。也就是说大模型生成 AscendC 代码失败不是因为不会写 C 风格代码而是因为它不懂tiling 约束pipeline orchestrationbuffer overflow 风险API 约束Ascend 特有执行模式。所以这篇文章的方向不是继续赌“更强大模型一次写对”而是转向通过反馈闭环 自举经验库让优化过程可持续逼近正确解。核心 insight作者在这一段给出了全篇最核心的 insightwhen external data are insufficient, we can bootstrap experience internally by exploiting the structured nature of code.翻成更直白的话就是既然外部没有足够的专家数据那就从代码本身的结构性出发自举出优化经验。它后面分两部分讲对 tiling 来说tiling 空间不连续稍微一改可能从“快”变成“编不过”但这种脆弱性反过来也是优势因为真实硬件反馈会直接告诉你可行 / 不可行快 / 慢。所以 tiling 适合用硬件反馈驱动的搜索。对 kernel 来说kernel 优化模式比较结构化比如 pipelining、vectorization、latency hiding 这些是可迁移的虽然没有现成 bad-to-good 数据但你可以从好代码出发故意 rewinding自己造出 bad-to-good 轨迹。所以 kernel 适合用经验抽取 检索增强重写。Table 2 是一张定位自己方法贡献边界的表。比较维度有三个Optimizes Existing Impl.Automatic OptimizationTraining-free几类方法对应关系大概是ASPLOS’25 / Hermes能优化已有实现但不是自动化 end-to-end更偏专家主导分析优化AscendKernelGen自动生成但不属于 training-free更偏从零生成而不是优化现有实现AscendOptimizer优化已有实现自动化training-free。作者想占据的生态位很明确不是专家调优系统不是重训练模型的方法也不是只做从零生成而是一个“不依赖额外训练”的现有 AscendC 算子自动优化系统。二、方法把 AscendOptimizer 分成两个阶段1. Stage IEvolutionary-Guided Program Search2. Stage IIOptimization-Rewind based Experience Bootstrapping然后用 alternating optimization 的方式在两者之间切换。作者的核心思想很聪明如果外部数据不够那就从执行反馈和已有强实现里“自己长经验”。具体来说1. 对 tiling不依赖规则库直接让硬件反馈告诉你什么可行、什么更快。2. 对 kernel不是盲目搜索而是从少量好的 seed kernel 出发故意把它们“去优化”从而构造 bad-to-good 轨迹再把这些优化经验存进可检索经验库。这个想法比“再堆一点 prompt engineering”或者“直接全靠 RL 搜索”更有结构感。Figure 1 里 Stage I 和 Stage II 并不是两个彼此独立的方法而是对同一个目标的两种互补求解。作者在文字里把它正式化成给定 operator O {T, K, S}其中1. T 是 host 侧 tiling function2. K 是 AI Core 上的 kernel code3. S 是静态属性如 shape、dtype、layout优化目标是在真实硬件上最小化执行延迟。Figure 1 真正想表达的是1. Stage I 通过硬件反馈去摸清可行 tiling 区域。2. Stage II 通过经验库和语义改写去突破 kernel 结构瓶颈。3. 两者交替迭代因为更好的 tiling 会改变 kernel 可发挥空间更好的 kernel 也会改变 tiling 的收益结构。这就是典型的 alternating optimization 思路。Stage IEvolutionary-Guided Program Search作者认为 tiling 优化的特点是1. 高度依赖 shape 和 layout。2. 解空间不连续。3. 很难抽象成通用规则。所以他们不试图先手写规则库而是把它建模成 program search。具体来说1. 先构造一个 base tiling function 模板。2. 在模板里放 evolution markers。3. 让 LLM 基于这些可变位置做变异。4. 再用真实 NPU 的 compile / execute / correctness 反馈作为 fitness。这里的核心不是“用了 evolutionary search”而是作者把硬件反馈本身当作边界探测器。因为在 Ascend 上可行域很脆1. 编译不过就说明违反约束。2. 精度不对就说明语义错。3. 延迟变好才说明真的有效。这使得 Stage I 更像一种“在硬件围栏内的程序进化”。Stage IIOptimization RewindStage II 的想法非常值得单独讲。作者观察到1. Ascend 上缺乏成体系的“差代码 - 好代码”配对数据。2. 但如果你手头有一小批不错的 kernel其实可以反向构造这种数据。怎么构造就是所谓 optimization rewind1. 从一个优化过的 expert kernel 出发。2. 故意把其中某些优化去掉也就是“去优化”。3. 于是你就能得到 slow version 和 fast version 的差别。4. 再总结出这次优化的 motif / strategy。这本质上是在自己制造“bad-to-good trajectory”。这个想法很聪明因为它绕开了一个现实障碍没有人会系统保存“所有糟糕版本是怎么一步步被优化好的”但你可以从好版本往回拆。作者进一步把这些轨迹蒸馏成可检索的 experience bank用于在线优化时的 retrieval-augmented rewriting。这使得 Stage II 不是纯搜索而是“带经验回放的结构化改写”。Algorithm 1 的本质是一个面向 Ascend 算子的交替优化框架外层循环逐轮继承当前最优解内层先在固定 kernel 下搜索更优 tiling再在固定 tiling 下重写更优 kernel并通过真实硬件上的编译、正确性和延迟反馈来筛选候选最终得到联合优化后的最优实现。Figure 3 可视化了经验库里的优化策略语义聚类。作者想说明两件事1. 有些 cluster 对应官方文档里的典型 best practice例如 tiling、double buffering。2. 还有一些 cluster 并不能直接映射到文档显式分类比如更细粒度的同步、向量化非有限值检查、去高延迟标量指令等。这张图的意义是经验库不只是把官方最佳实践重新抄了一遍而是从实际 benchmark operator 里挖掘出一些“文档没系统整理、但真实反复出现”的模式。这也是论文相对有说服力的地方。如果经验库只是文档摘录那创新性会很弱而 Figure 3 试图证明它确实挖到了额外结构。Alternating OptimizationFigure 4 以 foreach pow scalar and tensor 为例展示优化轨迹。这里作者每 10 次迭代切换一次 Stage I / Stage II。图里看到的现象很有代表性1. Stage I 很快给出约 1.09x 提升。2. 但之后会 plateau。3. Stage II 通过经验检索和语义重写打破 plateau。4. 在某个关键改写后速度直接跳到 2.31x。这说明1. 仅靠 tiling/execution tuning 能吃掉一部分剩余空间。2. 但真正大的突破往往来自 kernel 结构改写。Figure 5 把其中一个关键 rewrite 展开从 remainder-based per-core quota assignment 改成 block-level load balancing nested scan across tensors。简单理解就是原方法按余数分配任务可能造成核间负载不均新方法按 block 更均匀地分配并且做跨 tensor 的嵌套扫描从而减少尾部不平衡提高利用率。这属于很典型、很硬核的性能优化逻辑。三、实验作者从 cann-ops 官方 AscendC operator 仓库里出发筛出了 127 个 operator 作为最终测试集。这里还有一个很重要的说明Stage II 构造经验库用的 seed kernels 就来自同一个 127-operator benchmark。作者专门解释说这不是传统机器学习意义下的 train/test leakage因为他们不是在追求泛化评测而是在做 training-free、episodic、transductive optimization。这个解释在系统优化语境里是成立的。换句话说这篇文章不是在回答“你能不能泛化到一个完全没见过的 Ascend operator”而是在回答“面对当前要优化的这批 operator你能不能把它们调快”。这两种问题不能混淆。Table 3 报告了在 level1 / level2 / level3 上BoN5、BoN40、OpenEvolve 和 AscendOptimizer 的表现。指标包括1. GM几何平均 speedup2. fast1.03. fast1.24. fast1.45. fast2.0先看总体趋势1. BoN 增加采样预算从 5 到 40只带来有限收益。2. OpenEvolve 比 BoN 更强说明迭代优化比单纯多采样更有效。3. AscendOptimizer 在三层上都是最优。具体看数值1. Level 1GM 1.08fast1.0 46.51%。2. Level 2GM 1.21fast1.0 49.35%fast1.2 18.18%。3. Level 3GM 1.81fast1.0 71.43%fast2.0 28.57%。这里最值得注意的是1. Level 2 提升很扎实说明方法对中等复杂 operator 很有效。2. Level 3 样本只有 7 个所以虽然结果亮眼但统计稳定性有限不能过度夸大。总体来说Table 3 能支持一个比较强的结论AscendOptimizer 相比纯采样和通用迭代优化框架在 Ascend 场景下确实更有效。Figure 2 给的是 speedup 的 CDF。这张图比单纯报 GM 更有意义因为它说明1. 不只是个别 operator 被拉得特别高2. 而是有相当比例的 operator 获得了稳定中等提升3. 同时右侧长尾又表明少数 operator 能获得非常大收益。作者给出1. 39.7% 的 operator 至少 1.1x2. 30.2% 至少 1.2x3. 19.0% 至少 1.5x4. 14.3% 至少 2.0x这张图增强了结果可信度因为它显示收益不是完全由极端个例撑起来的。Table 4 对比1. 只有 Stage I2. 只有 Stage II3. 完整 AscendOptimizer结果很有代表性1. Stage IGM 1.09fast1.0 38.58%说明它善于保底、扩大可行解覆盖面。2. Stage IIGM 1.12fast1.2 和 fast1.4 更强说明它更擅长做中高强度结构优化。3. 完整系统GM 1.19fast1.0 和 fast2.0 最好。这和作者的理论叙事是吻合的1. Stage I 更像参数/调度层面的外圈搜索。2. Stage II 更像结构层面的内核重写。3. 两者结合才能同时拉高平均水平和高端收益。