AscendKernelGen：突破NPU算子生成瓶颈，大语言模型领域适配实现95.5%编译成功率

关键词：昇腾 Ascend、NPU 内核生成、大语言模型、领域适应、强化学习、评估基准

在人工智能飞速发展的今天，深度学习的计算需求呈指数级增长，传统的 CPU 和通用 GPU 已难以满足特定场景下的高效计算要求。为此，神经处理单元（Neural Processing Unit，NPU） 作为专为 AI 计算设计的领域专用加速器，逐渐成为现代 AI 基础设施的核心。华为推出的 Ascend（昇腾） NPU 平台，便是其中的典型代表，在处理深度学习工作负载时展现出显著的高性能优势。

然而，硬件性能的充分发挥，高度依赖于底层计算内核（Kernel） 的质量。这些内核是直接运行在 NPU 上的底层程序，负责执行具体的矩阵乘法、卷积、激活函数等计算任务。开发高性能的 NPU 内核是一项极具挑战性的工作：开发者必须使用厂商提供的、高度特化的领域特定语言（Domain-Specific Language, DSL），例如华为的 AscendC。这要求开发者不仅精通算法，还需深刻理解硬件的层次化内存系统、数据分块策略、异步流水线编程以及专门的向量/矩阵执行单元。这种高门槛导致内核开发成本高昂、周期漫长，且容易出错，成为 AI 应用在 NPU 上快速迭代和部署的主要瓶颈。

近年来，大语言模型在通用代码生成方面取得了巨大成功，为自动化内核开发带来了曙光。但现实却面临严峻挑战。

表 1 | 通用大语言模型在 NPUKernelBench 基准测试上的零样本性能表现。该表通过对比 Qwen3-8B、Qwen2.5-Coder-7B 等主流模型，清晰展现通用大语言模型在 NPU 核函数生成任务中的局限，尤其复杂 L2/L3 级任务执行成功率近乎为零，凸显领域适配的必要性。

如表 1 所示，即便是当前最先进的通用大语言模型（如 Qwen 3、Llama3.1 等），在零样本设置下生成 AscendC 内核代码的表现也极不理想。对于复杂的 L2/L3 级别内核，其执行成功率几乎为 0%。模型常常“幻觉”出不存在的 API，或者严重误用核心硬件接口，导致代码根本无法编译或运行。

这一困境揭示了当前代码生成方法的根本局限：通用的编程知识不足以支撑在高度专业化、硬件绑定的领域内生成正确且高效的代码。NPU 内核编程所需的知识——严格的 API 约束、与架构深度绑定的语义、对性能至关重要的优化模式——与通用编程语言截然不同。同时，该领域高质量的训练数据极其稀缺。

为了攻克这一难题，来自鹏城实验室、华为、中山大学和北京大学的研究团队提出了 AscendKernelGen（AKGen）——一个面向 NPU 内核开发的生成-评估一体化框架。该框架通过三个核心创新，显著缩小了通用大语言模型与硬件专用编码之间的鸿沟：

1. 构建高质量领域推理数据集（Ascend-CoT）：从真实内核实现中提取“思维链”，教模型像专家一样思考。
2. 训练领域自适应模型（KernelGen-LM）：通过结合执行反馈的监督微调与强化学习，让模型掌握硬件编程精髓。
3. 设计全面评估基准（NPUKernelBench）：建立从编译、正确性到性能的多维度、分层级评测体系。

图 1 | AscendKernelGen 系统概述，展示 NPU 核函数生成的数据构建、大语言模型训练和基于硬件的评估流水线。该图清晰呈现三大核心组件的联动：先通过文档、代码等构建 Ascend-CoT 数据集，再经 SFT 和 RL 训练 KernelGen-LM 模型，最后由 NPUKernelBench 完成编译、正确性与性能评估，形成闭环。

实验结果表明，经过 AKGen 框架训练后的模型，在复杂 L2 内核上的编译成功率从 0% 提升至 95.5%（Pass@10），功能正确率达到 64.3%，而基线模型则完全失败。

表 7 | NPUKernelBench 上内核生成的评估结果，CR 为编译成功率，ER 为执行成功率。此表对比基础模型、SFT 后、SFT+RL 后模型在不同难度核函数上的表现，显示 SFT+RL 策略使复杂 L2 级核函数 Pass@10 编译率达 95.5%，证明领域自适应训练对提升核函数生成质量的显著作用。

这项研究不仅为自动化 NPU 内核开发提供了切实可行的解决方案，也为更广泛的领域专用代码生成指明了方向。

本文目录

• 零、关键问题
  • 问题一：依赖专家经验的数据构建方法论，是否难以泛化至未知或文档匮乏的新硬件平台？
  • 问题二：在高度结构化的评估基准下取得的成功，是否高估了模型在真实开放场景中的创造性编程能力？
• 一、NPU 内核编程：为何如此独特与艰难？
  • 1.1 结构化的内核编程抽象
  • 1.2 对 LLM 代码生成的深层挑战
• 二、AscendKernelGen 框架全景
  • 2.1 生成组件：从数据到模型
  • 2.2 评估组件：NPUKernelBench——严苛的“考场”
• 三、实验结果：从近乎失败到卓越成功
  • 3.1 编译与执行成功率大幅跃升
  • 3.2 性能超越专家基线
  • 3.3 消融分析与错误洞察
• 四、核心创新与意义总结
• 五、未来展望
• 六、结语

零、关键问题

问题一：依赖专家经验的数据构建方法论，是否难以泛化至未知或文档匮乏的新硬件平台？

局限与边界：方法论的依赖与评估的启示

问题一：知识基石依赖现有实现，新硬件平台如何“冷启动”？

Ascend-CoT 数据集的构建高度依赖于从现有华为 AscendC 内核实现与文档中提取“思维链”。这引出一个核心问题：该框架的效能是否本质上受限于现有专家知识的质量和覆盖范围？ 若面向一个更新、更复杂或文档不完善的硬件平台（如其他架构的NPU），缺乏大量现成优质实现可供“提炼”，这套“从专家代码反推推理模式”的数据构建方法论是否会失效？这是否揭示了该方法在“从零开始”探索未知硬件编程范式时的根本性局限？

局限性确实存在，它揭示了当前方法的核心是一种 “基于知识蒸馏的迁移” ，而非完全的“无中生有”。

1. 当前方法的本质与成功前提：AscendKernelGen 的成功，很大程度上依赖于华为 Ascend 平台已经具备了一个相对成熟、规范的编程模型（AscendC）、丰富的官方文档以及一批高质量的专家实现。Ascend-CoT 数据集所做的，是将这些已经凝结的、体系化的专家知识，通过“思维链”的形式解码并灌输给大语言模型。因此，其效能上限与这些源知识的质量、广度和结构性直接相关。

2. 面对新平台时的挑战：对于一个全新或文档不完善的硬件平台，这套方法将面临显著挑战：

   • 知识来源匮乏：缺乏足够多正确、优化的实现作为“种子”来提炼推理模式。
   • 试错成本极高：在缺乏清晰约束和范例的情况下，模型生成的错误代码难以诊断，构建有效“错误衍生监督”数据的初期过程会非常缓慢且低效。
   • “冷启动”难题：论文中强大的“两阶段训练”起点——监督微调，依赖于高质量的初始数据集。如果这个起点薄弱，后续的强化学习也难以收敛到好的策略。

3. 方法的可迁移性与未来方向：然而，这并不意味着方法论完全失效。其核心价值在于提供了一套框架：

   • 泛化的是“流程”而非“知识”：可以迁移的是“构建领域思维链数据”、“利用执行反馈进行迭代”的研发范式。对于新平台，研究者需要从更基础的工作开始，例如与硬件工程师合作，共同编写首批示范代码并标注推理过程，这相当于人工完成初代“知识蒸馏”。
   • 从“蒸馏”走向“协同进化”：在理想情况下，未来的系统可能不再是单向地从现有专家代码中学习，而是能与硬件专家互动，在探索新硬件特性的过程中，共同产生新的优化模式和最佳实践，即形成人机协同的知识创造闭环。论文结论部分提到的“探索方法论在其他平台的通用性”，正是向此方向迈出的准备。

结论：是的，当前方法严重依赖于源生态的成熟度，在“从零开始”探索全新范式时存在“冷启动”瓶颈。但它为解决硬件编程自动化问题提供了经过验证的技术框架和路径。将其应用于新平台，并非简单的技术移植，而是一个需要投入前期领域知识注入的、更具挑战性的新工程与科研过程。

问题二：结构化评估下的成功，是否高估了模型的真实创造力？

论文的核心成功指标（如 L2 内核 95.5%的编译率、64.3%的正确率）严重依赖于 NPUKernelBench 这个精心设计的评估环境，该环境提供了标准化的模板、API 描述和测试用例。这是否在本质上将问题从“开放式的代码生成”规约为了“在强约束和脚手架下的填空与适配”？当面对真实工业场景中更模糊的需求描述、需要自行设计完整算子接口、或与复杂异构系统集成时，当前框架所展现的能力有多少能得以迁移？换言之，NPUKernelBench 的“保护性”评估是否可能高估了模型真正的、脱离脚手架后的“创造性”编程与系统集成能力？

这个问题区分了“在特定考场取得高分”和“解决真实世界问题”的能力。必须承认，NPUKernelBench 的评估环境确实提供了一个强大的“脚手架”，在一定程度上降低了问题的完全开放性。

1. 评估环境的“保护性”体现：

   • 任务规约化：通过 api_desc.md 和代码模板，将开放式的自然语言需求转换成了高度结构化、包含明确接口约束的规格说明。这避免了模型在需求理解、接口设计上的模糊性。
   • 问题空间裁剪：模板预先定义了主机与内核的代码骨架、函数签名甚至文件结构，模型的任务很大程度上是完成核心算法逻辑和正确调用 API 的“填空题”或“改错题”，而非从零开始的“设计题”。
   • 双路径设计的启示：论文中“仅设备路径”与“主机+设备路径”的区分，本身就承认了这两种不同难度的场景。即使在更难的“主机+设备路径”中，模板的约束依然很强。

2. 这是否意味着能力被高估？——需要辩证看待：

   • 对于“内核实现”核心能力，评估是有效的：脚手架剥离了工程外围的复杂性，恰恰让我们能孤立地、清晰地评估模型是否掌握了硬件编程最核心、最困难的精髓——异步流水线、同步、边界处理、内存层次管理。论文中模型从完全失败到能生成正确高效内核的飞跃，证明它确实学会了这些本质技能。这些技能是创造性编程的基础。
   • 对于“系统集成与设计”能力，目前确实评估不足：真正的“创造性编程”还包括：根据模糊需求自主设计算子接口、在复杂系统上下文（如图编译器）中集成、处理非标准的异构交互等。当前框架尚未测试这些。

3. 研究的合理定位与演进方向：在技术发展的早期阶段，通过构建受控环境来攻克核心难点是必要且科学的策略。这好比先教机器人熟练掌握使用各种工具（核心技能），再让其面对一个杂乱的工作间去完成综合项目。NPUKernelBench 就是这个训练“工具使用技能”的精密工作台。

   • 论文的贡献在于证明，在给予清晰规格和框架的情况下，LLM 可以卓越地完成此前被认为不可能的硬件内核编码。
   • 未来的演进必然如论文展望所述，需要逐步“拆除脚手架”：减少模板的提示、引入更模糊的需求描述、在更大的系统代码库中进行集成测试。这将是一个渐进的过程，而本研究为此奠定了坚实的能力基础。

结论：是的，当前评估环境在一定程度上简化了真实世界的复杂性，模型在完全开放场景下的“端到端”系统设计与集成能力仍需进一步验证。然而，这并不削弱本研究的核心突破——它证明了在明确框架内，LLM 能够习得并运用低层硬件编程的深刻逻辑。这是迈向更通用自动化编程的关键一步，下一步才是将这种能力从“工作台”解放到“整个车间”。

一、 NPU 内核编程：为何如此独特与艰难？

要理解 AscendKernelGen 的创新价值，首先必须深入 NPU 内核编程的本质。与在 CPU 上编写高级语言程序不同，NPU 内核编程是一种高度结构化、显式控制硬件的低层编程范式。

1.1 结构化的内核编程抽象

我们可以将一个 NPU 内核视为一个静态结构化的程序，它在单一的复制执行模板下，共同规定了全局数据分区、异步流水线阶段和显式同步语义。

• 数据并行与显式索引：一个内核程序会在多个处理单元上复制执行。每个实例操作由逻辑块索引决定的全局数据切片。因此，代码必须显式计算全局内存偏移、有效数据范围和边界条件，而不能依赖运行时隐式索引。
• 显式异步流水线：数据加载、计算和写回被映射到独立的硬件单元，并期望在时间上重叠。这种重叠并非由运行时管理，而是需要内核程序通过同步原语显式编码流水线阶段间的生产者-消费者关系，形成一个静态定义的执行时间表。
• 低层接口与紧耦合：这种结构通过低层编程接口暴露，要求显式指定内存访问模式、步长、掩码和同步事件。因此，算术计算、数据移动和控制流在内核代码中紧密耦合，无法自动推断或优化。

1.2 对 LLM 代码生成的深层挑战

这种结构化的抽象给基于 LLM 的代码生成带来了超越局部代码合成的推理需求：

1. 长程语义依赖：内核的正确性常常依赖于在核外计算、运行时传入的辅助参数（如块索引、分块因子、边界大小）。这些参数在多个流水线阶段中被引用，并同时控制内存访问和同步行为。生成正确代码需要 跨分离的代码区域保持语义一致性。
2. 显式同步推理：异步流水线阶段仅通过手动插入的同步原语通信。正确的执行依赖于这些操作的精确配对和排序。缺失、冗余或错序的同步会导致死锁或静默数据风险，这使得正确性 依赖于对动态执行顺序的推理。
3. 边界敏感的算术推理：数据维度常与硬件偏好的块大小不对齐，内核代码必须通过偏移计算和掩码逻辑显式处理边界情况。这需要对循环边界、索引和有效性条件进行 精确的算术推理。
4. 布局感知的表示推理：不同流水线阶段可能在为特定执行单元优化的不同物理数据布局上操作。内核代码必须 正确管理布局转换，同时保持逻辑张量语义。

正是这些深层次的、与硬件紧密相关的推理需求，让仅接受通用代码训练的 LLM“束手无策”。AKGen 框架正是为了赋予 LLM 这些“硬件思维”能力而生。

二、 AscendKernelGen 框架全景

AscendKernelGen 是一个统一的研究框架，旨在系统性地研究基于 LLM 的低层 NPU 内核生成、验证与评估。

图 1 | AscendKernelGen 系统概述，展示 NPU 核函数生成的数据构建、大语言模型训练和基于硬件的评估流水线。该图清晰呈现三大核心组件的联动：先通过文档、代码等构建 Ascend-CoT 数据集，再经 SFT 和 RL 训练 KernelGen-LM 模型，最后由 NPUKernelBench 完成编译、正确性与性能评估，形成闭环。

如图 1 所示，AKGen 集成了三个紧密耦合的核心组件：领域特定推理数据集（Ascend-CoT）、内核生成模型（KernelGen-LM）和结构化评估基准（NPUKernelBench）。它们共同形成了一个闭环的“生成-评估”循环。

2.1 生成组件：从数据到模型

2.1.1 Ascend 思维链数据集 (Ascend-CoT)

为了解决低层 NPU 编程数据稀缺的问题，团队构建了 Ascend-CoT。这不是一个普通的代码片段集合，而是一个捕捉了 AscendC 内核开发所需结构化推理过程的精选数据集。

• 来源与构建：数据集并非简单收集原始代码，而是从真实的算子实现和官方文档中精心构建。其中，对于工业级复合算子，会先将其系统分解为逻辑纯净的主机-内核代码对，每个对应对应一个单一的执行场景，以此精准捕捉主机端分块逻辑与设备端内核执行的交互。
• 核心内容：强调对内核正确性至关重要的显式流水线构建、同步逻辑和算术推理模式。
• 构成：包含三部分互补数据：
• 基于文档的推理数据：将官方手册转化为带有显式推理链的问答对，注入硬件抽象和 API 语义知识。
• 以代码为中心的思维链数据：从真实 AscendC 算子中提取，解释内核结构、内存移动和计算逻辑，并展示主机端分块逻辑与设备端内核执行的交互。
• 通用推理数据：融入高质量的开源数学、代码推理数据，以保持模型的通用问题解决能力。

2.1.2 内核生成语言模型 (KernelGen-LM)

以强大的基座 LLM（如 Qwen3-32B）为基础，利用 Ascend-CoT 进行领域自适应后训练，得到专精于低层 NPU 内核生成的 KernelGen-LM。其训练过程分为两个关键阶段：

阶段一：具有错误衍生监督的监督微调：仅靠静态监督，模型仍会在编译稳定性和数值正确性上频繁失败。为此，团队引入了创新的错误衍生监督策略。

图 2 | 用于 API 级和核函数级错误修正的错误衍生监督。此图体现错误衍生监督的双维度优化：先对 API 调用错误（如参数不匹配）聚类排序，构建 API 调试数据集；再针对核函数数值错误，生成核函数调试数据集，为 SFT 提供精准修正样本。

• API 级错误纠正：从真实的编译错误日志中构建纠错数据集。给定错误日志、内核上下文和相关文档，训练模型识别根本原因并生成纠正后的实现，见图 2。
• 内核级错误纠正：针对那些能编译但数值验证失败的“静默错误”。将这些错误内核与对应的真实实现（Ground Truth）配对，生成重构导向的思维链监督，指导模型分析数值失败原因并从零开始合成正确的内核实现。

这一阶段通过从实际失败中学习，让模型内化了对数值敏感的执行约束，在进入强化学习前大幅减少了无效候选方案，稳定了后续优化。

阶段二：基于执行偏好的强化学习：在 SFT 之后，模型已能生成满足基本约束的内核，但对于同一规范，仍可能存在多个在内存访问模式、累加顺序等方面有细微差别的有效实现。

此阶段引入基于执行的偏好信号驱动的强化学习。模型为每个任务采样多个可执行的候选内核，通过自动执行验证器产生基于数值精度和执行正确性的偏好关系。

• 偏好对构建：将通过编译和精度测试的内核作为正样本，将通过编译但未通过精度测试的内核作为负样本。
• 优化目标：使用直接偏好优化来更新模型，鼓励其产生更稳定、更准确的实现。

这一两阶段训练策略是 AKGen 成功的关键：SFT 打下遵守硬约束的基础，RL 则在此基础上进行细粒度的执行逻辑优化。

2.2 评估组件：NPUKernelBench——严苛的“考场”

一个强大的生成器需要一个同样强大的评估器。NPUKernelBench 是一个端到端的评估框架，用于系统评估 LLM 生成 NPU 内核的能力。它贯穿从任务指定、代码生成到编译、硬件执行和定量测量的全生命周期。

2.2.1 分层分类的任务设计

评估内核生成能力需要解耦多个难度来源。NPUKernelBench 通过两个正交维度分解任务难度：

• 算法复杂度：分为 L1（简单逐元素运算）、L2（常见神经网络算子）、L3（具有全局依赖性或动态控制流的复杂算子，如 Gemm、TopK）。
• 接口复杂度：区分为静态形状（编译时已知维度）和动态形状（运行时确定维度）任务。后者要求模型生成适应性的主机端逻辑，测试其鲁棒性。

表 2 | NPUKernelBench 中的内核任务分类。此表从静态 / 动态形状、任务类别、代表任务等维度，将核函数划分为 L1-L3 三个难度级别，覆盖 158 个任务，为系统评估模型在不同计算复杂度下的核函数生成能力提供清晰框架。

2.2.2 双路径评估设计

图 3 | 双路径评估设计。该设计区分静态形状（编译时已知维度，侧重优化）与动态形状（运行时适配维度，侧重鲁棒性）评估路径，静态路径易生成高效代码，动态路径需模型具备形状推理与动态控制流能力。

为了全面评估能力，NPUKernelBench 支持两种互补的评估路径（见图 3）：

• 仅设备路径：框架提供一个固定的、预优化的主机驱动，仅评估 LLM 生成正确高效设备端内核代码的能力。这隔离了模型在 NPU 上实现核心计算逻辑的基本能力。
• 主机+设备路径：评估模型生成完整、可部署算子的能力。LLM 需要同时生成主机端控制逻辑和设备端内核实现，反映了实际部署场景。

2.2.3 自动化评估流水线

NPUKernelBench 是一个健壮的自动化框架，无缝集成四个传统上孤立的阶段：代码生成、编译评估、正确性评估和性能评估。

• 编译评估：检查生成的代码是否符合 AscendC 语法并成功编译。
• 正确性评估：在多样化输入配置下，通过逐元素对比预生成的标准答案（Golden Reference）来验证数值有效性。采用分层评分体系（任务级、难度级、总分）。
• 性能评估：在功能正确的基础上，测量内核在目标 NPU 上的执行延迟，并 与高度优化的厂商提供的内核性能进行对比，计算相对加速比。这强调了生成内核逼近生产级优化内核的能力，而非只看绝对耗时。

三、 实验结果：从近乎失败到卓越成功

团队进行了广泛的实验，验证了 AKGen 框架的有效性。实验设置以 Qwen3-32B 作为主干模型，在包含 158 个代表性内核 的 NPUKernelBench 上进行评估。

3.1 编译与执行成功率大幅跃升

表 7 | NPUKernelBench 上内核生成的评估结果，CR 为编译成功率，ER 为执行成功率。此表对比基础模型、SFT 后、SFT+RL 后模型在不同难度核函数上的表现，显示 SFT+RL 策略使复杂 L2 级核函数 Pass@10 编译率达 95.5%，证明领域自适应训练对提升核函数生成质量的显著作用。

表 7 展示了在不同采样预算（k）下，模型在各个训练阶段的性能。

• 基线模型惨败：在零样本设置下，基线的 Qwen3-32B 在复杂 L2/L3 内核上基本无法生成可运行代码，执行成功率为 0%。
• SFT 效果显著：经过监督微调后，模型性能发生质变。L2 内核的编译成功率从 0%飙升至 98.0%（Pass@10），执行成功率更是达到了 40.48%。 这说明 SFT 成功地将模型与内核生成的结构和语法要求对齐。
• RL 精细优化：强化学习阶段进一步提升了生成质量。在 Pass@10 指标下，L2 内核的执行成功率达到 64.28%，同时平均加速比从 SFT 的 1.50 倍提升至1.86 倍。 RL 通过执行反馈，教会了模型在多个有效实现中挑选出更优者。

图 4 | 各训练阶段在代表性内核上的 Pass@1 结果。图中对比基础模型、SFT 后、SFT+RL 后模型在 14 个核函数上的表现，可见 SFT 使平均 Pass@1 从 7.92% 升至 26.26%，RL 进一步提至 33.46%，复杂核函数（如 InplaceAttnSoftmax）提升更显著。

图 4 直观展示了在代表性内核上，随着训练阶段推进，模型首次生成即成功（Pass@1）的准确率稳步提升。

3.2 性能超越专家基线

更令人印象深刻的是性能表现。基线模型几乎不具备优化能力。而经过 AKGen 框架训练后，模型不仅生成了可执行的内核，更学会了面向性能的实现策略。

• 在 L2 任务上，SFT 后的模型实现了1.50 倍的加速比，已经超越了专家手写的基线性能。
• RL 进一步将 L2 的平均加速比提升至1.86 倍。

这表明， 模型通过接触内核中心的推理模式，已经内化了优化的分块、内存重用等策略，能够生成硬件高效的并行化模式，在大量实用 NPU 算子上达到了专家级甚至超越专家的性能水平。

3.3 消融分析与错误洞察

团队还进行了深入的消融分析，揭示了成功背后的关键因素：

• 模型规模敏感：更大的模型（32B）在捕获标准内核模式上表现更好，且是唯一能在复杂 L3 内核上取得可测量编译成功的规模，说明 足够的参数规模是处理复杂 NPU 内核推理的前提。
• 全参数微调优于 LoRA：在知识密集型的硬件代码生成任务中，全参数微调在编译率、执行率和最终性能上均显著优于低秩适配（LoRA）。因为前者允许深度注入复杂语义和逻辑依赖。
• 训练数据构成至关重要：移除真实内核代码会导致性能急剧下降，而增加数据规模能带来持续改进。
• 错误类型分布：对约 4000 个失败案例的分析发现，API 签名与重载错误（51.9%） 是最主要的失败模式，其次是数据类型转换错误（19.8%）。这表明当前模型已能生成语法良好的代码，但失败多源于需要精确推理 API 契约、硬件数据类型等语义约束 的深层问题。

图 7 | 内核生成错误类型分布（合并小类别）。该图统计 4000 次失败案例，API 签名与重载错误占比 51.9%（主导因素），数据类型转换错误占 19.8%，纯语法错误仅 3.7%，说明模型多因语义理解不足失败，而非语法问题。

四、 核心创新与意义总结

AscendKernelGen 工作的核心创新点可以概括为“一个闭环、两阶段训练、三维评估”：

1. 构建领域专用的“思维链”数据闭环：首创性地从真实硬件编程场景中提炼结构化推理过程（Ascend-CoT），为 LLM 提供了学习“硬件思维”的优质教材，解决了数据稀缺和知识传递的根本问题。
2. 设计“纠错+优选”的两阶段模型训练范式：
   • 监督微调阶段 创新性地利用 错误衍生监督，从编译和数值失败中主动学习，提前排除大量错误模式，为模型打下坚实的约束遵循基础。
   • 强化学习阶段 利用 基于执行的偏好信号，在多个可行解中进行细粒度优化，推动模型生成不仅正确而且高效的内核。
3. 建立“编译-正确性-性能”三维一体的评估体系：NPUKernelBench 不仅是测试集，更是一个支持双路径（设备端/全栈）、多难度层级、自动化执行的 rigorous “考场”。其与硬件执行挂钩的评估方式，确保了研究结论的可靠性和实用性。

这项工作的意义远不止于提升华为 Ascend NPU 的内核开发效率。它有力地证明：

• 通用 LLM 向领域深度渗透是可行的，但需要精心设计的领域适应方法。
• “生成-评估”闭环 是推动 AI 用于复杂工程任务（如代码生成）的关键范式。
• 执行反馈 是优化低层、性能敏感代码的不可或缺的信号。

五、 未来展望

尽管取得了突破性进展，研究团队也指出了未来的方向：

1. 攻克更复杂的 L3 内核： 当前对具有全局依赖和复杂控制流的 L3 内核生成能力仍有限，是下一步攻坚的重点。
2. 集成性能感知的奖励模型：在 RL 阶段，不仅考虑功能性正确，更进一步集成以 最小化延迟、逼近硬件理论峰值 为目标的奖励模型。
3. 方法论泛化：将 AKGen 框架的核心思想（领域 CoT 数据构建、执行反馈驱动的训练、硬件在环评估）推广到其他新兴加速器平台如其他 NPU、DPU 等， 推动 AI 驱动的软硬件协同设计生态更加繁荣。

六、 结语

从通用代码生成的辉煌，到专用硬件编程的窘境，再到 AscendKernelGen 带来的破局之路，这项研究为我们展示了 AI 赋能极端专业化领域的一条清晰路径：深度理解领域知识、紧密耦合硬件反馈、构建闭环迭代系统。

当大语言模型被赋予了“硬件工程师”的思维链和“硬件本身”的严格考官后，它们便能跨越知识的鸿沟，从“纸上谈兵”的代码写手，蜕变为能够产出高质量、高性能底层代码的“硅基工程师”。

这不仅将极大解放硬件工程师的生产力，更可能催生全新的芯片设计与应用开发范式，加速人工智能基础设施的进化历程。

• MultiKernelBench：首个覆盖英伟达GPU、华为NPU、谷歌TPU的Kernel生成基准，涵盖14类算子285项测试。
• NPUEval：评估AMD硬件LLM向量化NPU Kernel——102个机器学习算子、编译器反馈与 50%+向量化峰值效率。
• ProfilingGuided+LLM协同：TritonForge突破 Triton内核优化瓶颈，成功率42.7%且最高提速5倍。

关注“鲸栖”小程序，掌握最新AI资讯