| --- |
| language: |
| - en |
| - zh |
| license: apache-2.0 |
| library_name: transformers |
| pipeline_tag: text-generation |
| datasets: |
| - AscendKernelGen/Ascend-COT-v2-json |
| base_model: |
| - Qwen/Qwen3-Coder-30B-A3B-Instruct |
| tags: |
| - code-generation |
| - npu |
| - ascend |
| - chain-of-thought |
| --- |
| |
| # AscendKernelGen/KernelGen-LM-MoE-30B |
|
|
|  |
| [](https://arxiv.org/abs/2601.07160) |
|
|
| ## Overview |
|
|
| **KernelGen-LM-MoE-30B** is a state-of-the-art domain-adaptive large language model designed for low-level NPU kernel generation, targeting Huawei Ascend hardware with the AscendC programming language. |
|
|
| Built upon the **Qwen3-Coder-30B-A3B-Instruct (Mixture-of-Experts, MoE) backbone**, the model is further specialized through domain-adaptive post-training on the Ascend-CoT dataset, followed by reinforcement learning with execution feedback. |
|
|
| --- |
|
|
| ## Links |
|
|
| - **Paper:** https://huggingface.co/papers/2601.07160 |
| - **Code:** https://github.com/weich97/NPUKernelBench |
| - **Datasets:** https://huggingface.co/AscendKernelGen/datasets |
|
|
| --- |
|
|
| ## Introduction |
|
|
| Our framework, **AscendKernelGen (AKGen)**, systematically bridges the gap between general-purpose code generation and hardware-specific programming via a closed-loop pipeline of data construction, training, and evaluation. |
|
|
| ### Ascend-CoT Dataset |
|
|
| A high-quality, domain-specific dataset enriched with **Chain-of-Thought (CoT)** reasoning. It integrates: |
|
|
| - Documentation-grounded reasoning |
| - Code-centric reasoning from real-world kernel implementations |
| - General structured reasoning chains |
|
|
| This enables the model to capture the intricate logic required for low-level NPU kernel development. |
|
|
| --- |
|
|
| ### Domain-Adaptive Post-Training |
|
|
| We introduce a two-stage optimization pipeline to obtain **KernelGen-LM**: |
|
|
| - **Supervised Fine-Tuning (SFT):** |
| Leveraging error-derived supervision to correct API misuse and numerical inaccuracies |
|
|
| - **Reinforcement Learning (DPO):** |
| Guided by execution-based correctness and performance feedback |
|
|
| This combination significantly enhances both syntactic validity and runtime reliability. |
|
|
| --- |
|
|
| ### Hardware-Grounded Evaluation |
|
|
| We validate performance using **NPUKernelBench**, a comprehensive benchmark evaluating: |
|
|
| - Compilation success |
| - Functional correctness |
| - Runtime performance (latency) |
|
|
| All evaluations are conducted on real Ascend hardware across varying task complexities. |
|
|
| --- |
|
|
| ### Performance Highlights |
|
|
| KernelGen-LM demonstrates substantial improvements on complex Level-2 kernel generation tasks, successfully solving problems where general-purpose LLMs (e.g., Qwen3, Llama3.1) completely fail. |
|
|
| --- |
|
|
| ## Representative Case Studies |
|
|
| ### Example: Effect of Knowledge Injection |
|
|
| The following case study, which concerns the usage of the `Muls` instruction in AscendC, demonstrates the qualitative improvement brought by CoT-based domain knowledge injection in both professional knowledge comprehension and code generation capability. |
|
|
|  |
|
|
| **🤔 Original response (before training):** |
| The response exhibits substantial uncertainty, as indicated by expressions such as “possibly” and “assuming.” The model attempts to reason by analogy from general programming knowledge, yet lacks an accurate understanding of AscendC-specific APIs, the precise usage of the `Muls` instruction, and its architectural context within the Ascend processor. The provided code example (e.g., involving `hip/hip_runtime.h`) is incorrect and explicitly reveals the model’s lack of domain-specific knowledge, as evidenced by statements such as “insufficient documentation” and “cannot be implemented.” |
|
|
| **🎓 Improved response (after training):** |
| The response demonstrates clear expert-level reasoning. |
|
|
| * **🧠 Structured reasoning (`<think>`)**: The model first analyzes the `Muls` instruction in terms of its operational background (vector multiplication), key parameters (e.g., `src0`, `dst`), and essential data layout constraints (e.g., whether `src0` must be a scalar or allocated in a specific region). |
| * **✅ Accurate implementation**: It then provides correct and concrete implementation steps, including initialization, local tensor memory management through `InQueue` and `OutQueue`, data movement (`CopyIn`), and the core computation invocation (`ScalarValue`). |
| * **⌨️ Code correctness**: The final generated code example (`aicore__void Compute()`) correctly employs the AscendC API and demonstrates an accurate understanding of both data queuing and vector instructions. |
|
|
| ### Example: Comparison of Generated Operators |
|
|
| The following example, which concerns the implementation of a `Swish` operator in AscendC, illustrates the qualitative improvement brought by CoT-based domain knowledge injection in handling complex operator implementation and tiling strategy design. |
|
|
|  |
|
|
| **🤔 Original response (before training):** |
| The response exhibits substantial uncertainty in the critical tiling strategy, with phrases such as “possibly,” “obviously not feasible,” and “assuming.” Although the model attempts a simple arithmetic division (`1024/48 = 21.33`), it fails to understand Ascend core scheduling mechanisms and cannot handle non-divisible remainders appropriately. Its implementation of the `Swish` operator itself is also confused, with an inaccurate composition of operations such as `Negate`, `Reciprocal`, and `Multiply`, and an imprecise understanding of the required APIs. The response ultimately concludes that compilation would fail. |
|
|
| **🎓 Improved response (after training):** |
| The response demonstrates clear expert-level reasoning. |
|
|
| * **🧠 Structured reasoning (`<think>`)**: The model first accurately analyzes the mathematical formulation of the `Swish` operator, namely $y = x \times \mathrm{sigmoid}(x)$, together with the input specification. More importantly, it designs a robust tiling strategy by correctly identifying the total workload (`1024`) and the number of cores (`48`), and by formulating an uneven remainder-aware workload distribution scheme (the first 47 cores process 21 elements each, while the last core processes 37 elements). |
| * **✅ Accurate implementation**: The model then correctly realizes this tiling strategy in the `Init()` function by computing `blockLength` and `remainder`. In the `Compute()` function, it provides a correct and concrete operator implementation pipeline, combining AscendC instructions such as `Muls`, `Exp`, `Adds`, and `Div` to construct the sigmoid function step by step and ultimately complete the `Swish` computation. |
| * **⌨️ Code correctness**: The final generated code examples (`aicore__void Init()` and `aicore__void Compute()`) correctly employ the AscendC API, demonstrating not only an accurate understanding of the operator’s mathematical logic, but also a deep mastery of multi-core parallelization and tiling strategies. |
|
|
| ## Citation |
|
|
| ```bibtex |
| @article{cao2026ascendkernelgen, |
| title={AscendKernelGen: A Systematic Study of LLM-Based Kernel Generation for Neural Processing Units}, |
| author={Xinzi Cao and Jianyang Zhai and Pengfei Li and Zhiheng Hu and Cen Yan and Bingxu Mu and Guanghuan Fang and Bin She and Jiayu Li and Yihan Su and Dongyang Tao and Xiansong Huang and Fan Xu and Feidiao Yang and Yao Lu and Chang-Dong Wang and Yutong Lu and Weicheng Xue and Bin Zhou and Yonghong Tian}, |
| journal={arXiv preprint arXiv:2601.07160}, |
| year={2026}, |
| url={https://arxiv.org/abs/2601.07160} |
| } |