K3平台+自建Ascend C算子专用微调模型分层协同架构方案 用于本地部署的领域专有小型大语言模型

（结合AscendKernelGen技术审核报告完整版修订，补充全开源对标模型对比）

文档基础信息

1. 方案名称：K3平台+DeepSeek-R1-Distill-Qwen-32B昇腾算子垂直微调模型+OpenCode/CodeBuddy双模型协同架构
2. 适用硬件：昇腾910B NPU、CANN算子开发栈
3. 审核依据：arxiv 2601.07160《AscendKernelGen》、cudaLLM/CUDA-Agent/KernelLLM开源项目、flagos算子生成综述、昇腾官方CANN开发文档
4. 编制日期：2026年07月24日
5. 定位：面向CNN卷积算子自动化生成的领域专用大模型工程落地方案，解决通用大模型编写Ascend C内核隐性故障、调试成本高痛点；同步对标全行业开源算子生成模型，评估自研复用边界与重复造轮子风险

一、方案背景与问题现状

1.1 通用大模型开发Ascend C算子核心痛点

前期采用GLM5.2通用大模型直接生成昇腾AICore内核代码，批量验证存在系统性缺陷，根源为通用基座不具备昇腾硬件领域深度知识：

1. 预训练语料中Ascend C、Cube流水线、L0/L1片上显存、Tiling分块约束样本占比极低，模型无法内化昇腾硬件边界规则；
2. 仅掌握标准C/C++通用语法，对GM-L0/L1内存搬运、PipeQueue时序、数据对齐、CubeMma维度限制等硬件特有语义理解缺失；
3. 输出代码可通过编译，但运行时频繁出现缓冲区溢出、分片越界、流水线死锁、精度异常等隐性bug，无推导过程难以定位故障，算子调试周期大幅拉长。

1.2 行业开源算子生成模型整体现状

截至2026年7月，LLM自动生成硬件算子赛道已形成完整开源生态，分为昇腾Ascend C专用模型、CUDA/Triton GPU算子模型两大分支，全部验证同一结论：通用大模型无法胜任硬件内核生成，必须领域微调+执行反馈强化学习。

1. 昇腾领域已有成熟开源成品AscendKernelGen，与本方案目标完全重合；
2. GPU领域cudaLLM、CUDA-Agent、KernelLLM验证两阶段SFT+RL为行业SOTA标准路线；
3. flagos-ai产出完整领域综述仓库与综述论文，覆盖全赛道模型、数据集、评测基准。
   
   

1.3 方案核心定位

构建分层双模型职责隔离架构：专用垂直微调模型独占昇腾AICore内核生成、硬件约束推理；通用代码助手负责宿主工程封装、通用代码开发，结合K3平台路由分发实现算子全流程自动化开发。
同步对齐全部开源同类项目做选型对标，优先复用成熟开源模型降低自研成本，仅在开源基线不满足业务需求时开展二次微调，规避重复造轮子风险。

二、整体架构与分层职责设计

2.1 整体架构拓扑

K3平台请求路由层
├─ 内核生成专用接口 → DeepSeek-R1-Distill-Qwen-32B LoRA微调垂直模型（独占AICore Kernel、Tiling推导）
└─ 通用工程编码接口 → OpenCode/CodeBuddy通用代码模型（宿主代码、编译脚本、静态辅助审查）

2.2 双模型严格分工边界（禁止跨域混用）

2.2.1 OpenCode/CodeBuddy（通用代码大模型）

✅ 专属能力范围

1. Ascend C算子Host侧宿主调用代码、算子注册逻辑封装；
2. CMake/Makefile编译脚本、单元测试用例、Tensor输入输出构造；
3. 标准C/C++通用框架、代码注释、重构、语法基础报错修复；
4. 辅助静态代码审查（仅做基础语法风险识别，不替代硬件约束校验）。

❌ 严格禁止任务
独立生成__aicore__内核函数、推导Tiling分块策略、规划L0/L1片上存储、编排PipeQueue流水线；通用模型无昇腾硬件底层约束知识，直接生成内核必然产生隐性运行故障。

2.2.2 自建垂直微调模型（DeepSeek-R1-Distill-Qwen-32B LoRA）

✅ 独占核心任务（昇腾算子内核全链路推理生成）

1. 根据卷积超参（ksize/stride/pad/通道/数据类型/910B芯片）自动输出完整__aicore__ void ConvKernel内核；
2. 多维Tiling分块数学推导、L0/L1缓冲区容量计算、数据分片划分；
3. CubeMma矩阵乘调度、GM与片上存储双向搬运逻辑、PipeQueue流水线时序编排；
4. 主动规避昇腾硬件固有约束：片上存储上限、数据对齐、Vector/Cube并行维度限制；
5. 强制输出完整推理CoT过程，与代码绑定，故障可追溯定位。

❌ 不承担任务
上层Host工程代码、CANN算子注册、测试脚本、通用业务逻辑，交由通用代码模型处理。

三、全行业开源算子生成模型盘点与横向对比

3.1 昇腾Ascend C直接对标项目：AscendKernelGen（核心对标）

1. 基础信息

• 论文：arxiv 2601.07160（ACL 2026 Findings）
• 开源仓库：HuggingFace AscendKernelGen/KernelGen-LM-32B
• 基座：Qwen3-32B（同32B规模Qwen系基座，与本方案选型同级）
• 训练范式：SFT（Ascend-CoT v1/v2/v3数据集）+ Execution-Feedback RL两阶段训练
• 开源资产：完整模型权重、多源CoT算子数据集、生成+评测一体化框架、昇腾实机评测工具

2. 核心对标结论
   该项目与本方案目标100%重合，专门解决Ascend C算子自动生成问题，经学术验证性能全面超越GPT-4o、DeepSeek V3通用大模型；是本方案首要基线，优先评估复用，大幅降低从零自研成本。

3.2 CUDA GPU算子开源项目（方法论可复用参考）

3.2.1 ByteDance-Seed/cudaLLM

• 仓库：GitHub ByteDance-Seed/cudaLLM
• 配套数据集：ByteDance-Seed/cudaLLM-data
• 训练方案：SFT+RL两阶段流水线，近8万训练样本
• 参考价值：完整两阶段训练工程化流水线、实机反馈Reward设计方案，为本方案RL环节提供落地参考。

3.2.2 BytedTsinghua-SIA/CUDA-Agent

• 论文：arxiv 2602.24286
• 核心方案：大规模Agentic强化学习拆解算子开发流程
• 参考价值：支撑本方案“双模型分层协同”架构设计思路，可升级为Agent自动迭代工作流。

3.2.3 Meta facebook/KernelLLM

• 仓库：HuggingFace facebook/KernelLLM
• 基座：Llama 3.1 8B小模型
• 任务：PyTorch转Triton GPU内核生成
• 参考价值：反例验证，小模型+高质量垂直数据集可超越通用大模型；本方案32B基座选型需补充A/B评测，不盲目追求大参数量。

3.3 通用算子生成工具与综述仓库

3.3.1 flagos-ai 系列开源资产

• 仓库：awesome-LLM-driven-kernel-generation、KernelGen、KernelGenBench
• 配套综述论文：arxiv 2601.15727（领域系统综述）
• 参考价值：完整行业技术地图，覆盖全部算子生成模型、评测基准，方案设计前期必读，避免遗漏已有成熟技术。

3.3.2 TritonRL、omniCUDA

• TritonRL（arxiv 2510.17891）：纯CoT推理增强方案，无执行反馈，可作为消融实验参考；
• omniCUDA：跨语言算子转换方案，为本方案跨硬件语法迁移提供思路。

3.4 昇腾社区原生Agent实践

昇腾官方社区《基于Agent的Ascend 950 FFT算子智能开发实践》：采用“算法骨架预生成→降级Ascend C内核”两段式开发，与本方案分层架构高度契合，可借鉴业务落地流程。

3.5 开源模型综合对比矩阵

项目	适配硬件领域	基座规模	标准训练方法	开源交付内容	对本方案参考价值
AscendKernelGen	Ascend C昇腾算子	32B Qwen3	SFT+实机RL	模型+多版本数据集+评测框架	⭐⭐⭐⭐⭐ 直接对标，优先复用基线
cudaLLM	CUDA GPU算子	未公开	SFT+实机RL	训练代码+数据集	⭐⭐⭐⭐ RL训练工程方案复用
CUDA-Agent	CUDA GPU算子	未公开	Agentic RL	完整Agent调度代码	⭐⭐⭐⭐ 分层协同架构优化参考
KernelLLM	Triton GPU算子	8B Llama3.1	单阶段SFT	小尺寸模型权重	⭐⭐⭐ 基座规模选型反例参考
flagos-ai KernelGen	通用Triton算子	多基座	Agentic生成	Benchmark评测工具	⭐⭐⭐ 算子自动化评测体系搭建
TritonRL	Triton GPU算子	未公开	纯CoT无RL	理论论文	⭐⭐ 消融实验对比参考

3.6 对标总结与自研风险提示

1. 高度重合风险：AscendKernelGen已完整覆盖本方案全部诉求（32B基座、CoT数据集、SFT+RL训练、昇腾内核生成），若跳过基线评测直接从零自研，存在严重重复造轮子问题，技术评审、对外成果输出均存在短板；
2. 方法论统一：全赛道SOTA项目均采用两阶段训练，原方案仅SFT单阶段存在明显技术缺陷，必须补充RL执行反馈环节；
3. 数据集对标：Ascend-CoT v3样本量级、场景覆盖度远超本方案初始几千条样本规划，直接复用开源数据集可大幅降低数据建设成本。

四、基座选型论证（结合开源对标修正原方案论证缺陷）

4.1 优先选择DeepSeek-R1-Distill-Qwen-32B核心依据

1. 多步数学推理能力适配Tiling规划
   R1蒸馏模型原生强化长链式CoT推理，Tiling本质为多维分块数学规划，对比GLM5.2通用基座逻辑链深度更强，适配分块策略推导需求；
2. Qwen昇腾生态适配成熟
   Qwen系列基座在昇腾NPU训练、vllm-ascend推理部署链路完善，可无缝对接K3平台私有化推理服务；
3. 32K长上下文覆盖完整内核
   原生支持76K上下文窗口，可完整承载大尺寸卷积长内核、多轮Tiling推导文本，满足复杂算子生成长度需求；
4. CUDA并行代码预训练储备可迁移
   预训练阶段包含大量GPU并行调度、矩阵计算代码，并行编程范式可迁移至Ascend C Cube流水线开发；
5. 可控私有化微调
   支持LoRA轻量化微调，可叠加企业私有算子故障样本做增量优化。

4.2 选型缺陷与开源对标优化方案

1. 原方案硬伤修正：“CUDA样本充足等价Ascend C能力强”论据失效
   CUDA语料无法覆盖昇腾特有L0/L1隔离、PipeQueue、CANN约束，模型核心能力依靠垂直数据集，而非通用预训练语料；
2. 开源竞品对标选型：Qwen3-32B（AscendKernelGen原生基座）
   训练阶段同步开展DeepSeek-R1-Distill-Qwen-32B、Qwen3-32B双基座A/B评测，基于KernelGenBench昇腾算子基准测试集对比内核生成通过率、运行故障率，择优正式上线；
3. 降级过渡方案：短期算力不足、32B模型未完成训练时，临时启用DeepSeek-R1-Distill-Qwen-14B承担内核生成，业务不间断，训练完成后平滑切换。

五、标准化算子开发全流程（两段式流水线，故障分层定位）

5.1 阶段1：垂直模型生成内核+CoT推导（强制规范，不可省略）

1. 输入：卷积业务参数、目标硬件910B、L0/L1容量上限、Cube计算约束；
2. 固定Prompt范式（强制先推理、后输出代码）

你是昇腾Ascend C算子专业开发专家，硬件平台Ascend910B。
卷积参数：【ksize、stride、pad、输入输出通道、数据类型】
硬件约束：L0最大容量XX、L1容量XX，必须使用CubeMma实现卷积，合理划分Tiling分片，规避L0缓冲区溢出，保障流水线吞吐。
输出规范：第一部分完整Tiling推导过程（分片维度、缓冲区计算、流水线依赖关系），第二部分输出完整可运行__aicore__内核代码，使用```ascendc代码块包裹。

3. 输出产物：Tiling数学推导文档 + AICore内核代码；
4. 价值：运行卡死、精度异常时，可对照推导文本定位是分块错误、内存越界或流水线时序问题，解决无推导无法排障痛点。

5.2 阶段2：通用模型完成工程封装+辅助审查

将垂直模型输出的纯内核代码作为输入，下发CodeBuddy标准化指令：

1. 宿主代码封装指令

基于下述Ascend C __aicore__内核函数，完成：1. CANN框架算子Host注册代码；2. 输入输出Tensor构造测试main函数；3. 算子结果精度校验逻辑；4. 完整编译CMake脚本。

2. 静态风险审查指令

审查下方Ascend C内核代码，识别全部硬件风险：L0缓冲区越界、数据对齐违规、PipeQueue读写时序冲突、Cube输入维度不匹配、重复内存读写冲突，逐条列出风险点与修改方案。

5.3 调试分层定位规则（规避模型职责混乱）

1. 内核运行故障（分片溢出、Cube报错、流水线卡死）→ 归属垂直微调模型迭代优化，扩充错误修复样本至训练集；
2. 编译报错、算子注册失败、测试用例逻辑错误 → 归属CodeBuddy迭代修复；
3. 硬件底层强约束校验：不依赖LLM，接入CANN官方msKleaner静态检测工具、910B实机编译执行校验，作为RL阶段奖励信号来源。

六、模型训练完整技术路线（对标开源SOTA，补充原方案缺失RL环节）

原方案仅规划SFT+LoRA单阶段训练，存在复杂算子隐性bug无法根治的缺陷，本方案对齐AscendKernelGen、cudaLLM开源项目，升级为SFT监督微调+实机反馈RL强化学习两阶段标准范式。

6.1 数据集建设方案（对标Ascend-CoT，解决样本规模偏小问题）

1. 基础开源数据集：完整引入Ascend-CoT v3多源数据集，覆盖Tiling策略、内存搬运、错误修复、调试全场景样本；
2. 私有扩充样本：团队历史卷积算子、线上调试失败案例、故障修复代码，统一标准化预处理；
3. 样本格式规范：全部样本强制「CoT推导文本+```ascendc内核代码」成对存储，统一标识符、注释格式，与开源数据集格式对齐；
4. 规模目标：总样本量级对标Ascend-CoT v3，解决硬件约束组合爆炸覆盖不足问题。

6.2 阶段一：LoRA监督微调SFT

1. 训练框架：LLaMA Factory，LoRA轻量化微调，冻结主干模型权重；
2. 超参配置：mask_prompt=true，标准交叉熵损失，基础学习率适配昇腾训练集群；
3. 训练目标：让模型稳定输出“先Tiling推导、后内核代码”的固定格式，掌握基础Ascend C语法与硬件基础约束。

6.3 阶段二：Execution-Feedback RL强化学习（开源项目通用核心环节）

1. Reward奖励来源（实机闭环，对齐AscendKernelGen/cudaLLM方案）
   • CANN编译器编译通过率（正向奖励）；
   • 910B实机运行无卡死、无内存越界；
   • 算子输出结果与标准实现精度对齐；
   • Cube、PipeQueue时序无冲突扣分；
2. 训练价值：解决单纯SFT无法消除的隐性运行bug，大幅降低复杂卷积算子调试成本。

6.4 推理部署与K3集成

1. 微调后流程：LoRA权重与DeepSeek-R1-Distill-Qwen-32B基座合并；
2. 推理框架：vllm-ascend昇腾专用推理引擎，部署私有模型API服务；
3. K3平台集成：增加请求路由判别逻辑，区分“内核生成”“通用编码”两类请求，分流至对应模型接口；
4. 持续迭代机制：线上所有算子故障案例、修复代码自动入库，定期增量扩充SFT数据集，迭代更新模型。

七、项目落地执行时间表

1. 当前阶段：拉取AscendKernelGen开源模型完成基线评测；同步清洗Ascend-CoT v3数据集、归集私有故障样本，启动DeepSeek-R1-Distill-Qwen-32B LoRA SFT微调；搭建K3平台双模型请求路由逻辑；
2. 训练中期：SFT收敛后接入910B实机与CANN编译器，搭建RL强化学习训练闭环；同步开展Qwen3-32B基座A/B对照评测；
3. 模型上线阶段：完成两阶段训练，落地分层算子开发流水线，强制启用CoT推导输出规范；
4. 长期迭代：按月同步开源领域最新数据集更新，持续收集算子调试故障案例，增量训练优化垂直模型。

八、关键避坑规范（历史踩坑+开源对标+审核报告风险汇总）

1. ❌ 禁止：跳过AscendKernelGen基线评测直接从零完整自研；
   ✅ 项目门禁：上线前必须完成开源模型基线对比，评估复用可行性；
2. ❌ 禁止：将AICore内核生成任务下发CodeBuddy通用模型；
   ✅ 强制内核生成权限仅归属自建垂直微调模型；
3. ❌ 禁止：不强制CoT思维链，直接输出纯内核代码；
   ✅ 所有算子生成请求必须输出完整Tiling推导过程，纳入训练样本硬性格式；
4. ❌ 禁止：一段需求同时下发双模型，职责混用；
   ✅ 请求路由严格分层，内核、工程代码分两条独立链路处理；
5. ❌ 禁止：仅做SFT微调，省略实机反馈RL阶段（所有开源SOTA项目均标配）；
   ✅ RL为必选环节，否则复杂算子隐性故障无法根治；
6. ❌ 禁止：仅依赖LLM做硬件约束校验；
   ✅ 配套msKleaner、CANN编译器、910B实机三重硬校验，作为RL奖励依据；
7. ❌ 禁止：仅使用几千条小规模样本训练；
   ✅ 基线数据集复用Ascend-CoT v3，保证场景覆盖度。

九、风险控制与备选方案

9.1 核心风险

1. 重复造轮子风险：AscendKernelGen已开源完整32B模型、数据集、训练框架，完全从零自研会造成算力、人力浪费，技术评审存在方案冗余问题；
2. 模型效果风险：仅SFT无RL、数据集规模不足时，复杂卷积算子仍存在大量运行故障，无法解决业务核心痛点；
3. 基座选型风险：DeepSeek-R1-Distill-Qwen-32B垂直能力弱于Qwen3-32B，无A/B评测直接上线会影响生成质量；
4. 技术滞后风险：未参考flagos领域综述、cudaLLM等开源项目，方案方法论停留在2025年认知，未跟进2026年SOTA两阶段RL路线。

9.2 风险应对策略

1. 基线先行策略：项目启动第一环节复现KernelGen-LM-32B开源模型，在自有卷积测试集完成全量评测，若满足业务需求直接复用，仅做少量私有样本增量微调；
2. 训练流程强制闭环：项目门禁校验两阶段SFT+RL完整训练链路，不允许仅交付单SFT模型上线；
3. 双基座A/B评测：训练阶段同步完成DeepSeek-R1-Distill-Qwen-32B、Qwen3-32B对照测试，以昇腾算子基准通过率为选型依据；
4. 定期同步开源生态：跟进flagos-ai综述仓库、AscendKernelGen版本迭代，持续吸收行业最优实践。

9.3 短期降级备选方案

32B模型训练周期较长、算力不足时，临时启用DeepSeek-R1-Distill-Qwen-14B作为内核生成模型，保障K3平台算子自动化开发业务不间断，待32B模型训练评测完成后平滑升级切换。

十、附录：标准化可复用Prompt模板

附录1：垂直模型【内核生成标准Prompt】

# 角色定义
你是资深昇腾Ascend C算子开发专家，硬件平台为Ascend910B NPU，精通CubeMma矩阵计算、L0/L1片上存储管理、PipeQueue流水线调度、Tiling分块优化。
# 输入需求
卷积参数：{ksize、stride、pad、in_channel、out_channel、data_type}
硬件约束：L0最大容量{XX}Byte，L1最大容量{XX}Byte，必须使用CubeMma实现卷积计算，禁止出现L0缓冲区溢出、数据对齐错误、流水线死锁。
# 输出强制规则
1. 第一部分输出完整Tiling推导过程：分片维度划分、L0/L1缓冲区大小计算、数据GM-L0搬运策略、PipeQueue流水线依赖关系；
2. 第二部分输出完整可运行__aicore__ ConvKernel内核代码，使用```ascendc代码块包裹；
3. 代码必须适配CANN标准Ascend C语法，规避910B硬件固有限制。
# 禁止行为
不允许直接输出代码省略推导过程，不允许超出片上存储容量分配缓冲区。

附录2：CodeBuddy【宿主封装+静态审查Prompt】

2.1 工程封装指令

基于下方Ascend C __aicore__卷积内核代码，完成全套算子工程开发：
1. 编写CANN框架适配的Host侧算子注册代码；
2. 构造输入输出Tensor、精度校验逻辑的main测试函数；
3. 编写完整CMake编译脚本，适配昇腾CANN编译环境；
4. 增加代码注释，分层封装调用逻辑，保证工程可直接编译运行。
内核代码：
【粘贴垂直模型输出ascendc代码】

2.2 硬件风险静态审查指令

审查下述Ascend C内核代码，逐条识别昇腾硬件运行风险：
1. L0/L1缓冲区容量越界、数据对齐不满足硬件要求；
2. PipeQueue读写时序冲突、重复读写片上存储；
3. CubeMma输入输出维度不匹配、并行单元调度违规；
输出格式：风险点位置+故障影响+可直接修改的优化方案。
待审查代码：
【粘贴ascendc内核代码】

十一、参考资料（完整覆盖审核报告全部文献/开源项目）

11.1 学术论文

1. arxiv 2601.07160《AscendKernelGen: A Systematic Study of LLM-Based Kernel Generation for Neural Processing Units》（ACL 2026 Findings）
2. arxiv 2601.15727 《Towards Automated Kernel Generation in the Era of LLMs》算子生成领域系统综述
3. arxiv 2602.24286 《Large-Scale Agentic RL for High-Performance CUDA Kernel Synthesis》CUDA-Agent论文
4. arxiv 2510.17891 《TritonRL: Training LLMs to Think and Code Triton Without Execution Feedback》

11.2 开源仓库与数据集

1. HuggingFace：AscendKernelGen/KernelGen-LM-32B、Ascend-CoT v1/v2-packed/v3-json
2. GitHub：ByteDance-Seed/cudaLLM
3. HuggingFace Dataset：ByteDance-Seed/cudaLLM-data
4. GitHub：BytedTsinghua-SIA/CUDA-Agent
5. HuggingFace：facebook/KernelLLM
6. GitHub：flagos-ai/awesome-LLM-driven-kernel-generation、flagos-ai/KernelGenBench、flagos-ai/kernelgen

11.3 昇腾官方资源

1. 昇腾社区技术博客：基于Agent的Ascend 950 FFT算子智能开发实践
2. CANN Ascend C官方开发文档、算子开发场景指南
3. msKleaner 昇腾静态代码检测工具

11.4 工程配套工具

1. LLaMA Factory：LoRA轻量化微调框架
2. vllm-ascend：昇腾NPU专用推理引擎
3. OpenCode、CodeBuddy：通用代码大模型服务

审核意见

这份审核报告的方向判断是对的——通用大模型 ≠ 昇腾领域专用模型，需要领域数据注入 + 实机执行反馈，这条主线与 2026 年 KernelGen 2.0、CUDA-Agent 等公开工作的路线完全一致。但在"对标对象是否真的已开源"、"选型论据是否成立"这两点上，原报告的个别说法需要校准。我把报告重写成一份结论先行、风险分级、建议可执行的整理版。

---

🎯 一句话结论

方案"做 Ascend C 专用模型"的方向正确，但**“从零自研 DeepSeek-R1-Distill-Qwen-32B + 单阶段 SFT”** 这条路径在 2026 年的开源生态里既不必要也不先进——应先评估已有的开源对标成品，并升级到 SFT + Execution-Feedback RL 的两阶段范式。

⚠️ 关于原报告中的 “AscendKernelGen/KernelGen-LM-32B/Ascend-CoT”：本轮检索未在 HuggingFace / arXiv 直接核实到该实体的开源仓库与论文（原报告引用的 arxiv 2601.07160 编号也未能在公开渠道验证）。建议先到 HuggingFace 与原论文页面做二次确认。但即便该具体成品不存在，"面向昇腾的 LLM 算子生成"赛道已有可借鉴的开源底座——众智 FlagOS 的 KernelGen 2.0 就是直接对标。

---

一、方案成立的部分（保留）

✅ “通用 LLM 直接写 Ascend C 会系统性翻车”——判断成立

• 昇腾 CANN 虽已全面开源开放（含 Ascend C 2.0、CATLASS 模板库、190+ Runtime 接口），但 Ascend C 涉及达芬奇架构 AI Core、Vector/Cube 单元、Tiling 约束、PipeQueue 时序等硬件特有语义，通用大模型预训练语料中样本极少
• KernelGen 2.0 在多芯片算子自动生成上的实践也印证：必须经过"生成 → 基线构建 → 验证测试"的完整生命周期闭环，裸生成不可用

✅ "双模型分层协同"架构合理

• 通用助手（CodeBuddy/OpenCode）负责宿主代码与工程化，垂直模型独占 kernel 生成——这与 CUDA-Agent 的 “agent 拆解任务 + 技能增强执行环境” 思路一致

---

二、方案存在的四个真问题（按严重度排序）

🔴 问题 1：训练范式落后——单阶段 SFT 不够

原方案只提 SFT + LoRA 单阶段，但 2026 年 SOTA 共识是 两阶段：

1. SFT 阶段：注入 CoT 推理样本（kernel 结构 + tiling 策略 + 内存搬运 + API 约束 + 错误修正）
2. RL with Execution Feedback 阶段：reward 来自 CANN 编译器通过率 + 910B 实机执行的正确性与性能校验

证据：CUDA-Agent 正是用大规模 Agentic RL，在 KernelBench 上取得 Level 1/2/3 加速率 100%/100%/92%，几何平均加速 2.11×，超越 Claude Opus 4.5 与 Gemini 3 Pro。缺 RL 阶段，复杂 Cube/卷积算子的隐性 bug（缓冲区溢出、对齐错误、时序死锁）不会被消除——而这恰恰是用户的核心痛点。

🔴 问题 2：基座选型论据有三处硬伤

原方案论据	实际问题
“支持上下文 32K”	DeepSeek-R1-Distill-Qwen-32B 基于 Qwen2.5 骨架，原生 context 76K+，32K 是低估
“社区 CUDA Kernel 储备充足”	对 Ascend C 不成立。CUDA 生态优势不能迁移到昇腾，Ascend C 公开语料极少
“R1 多步推理利于 Tiling”	CoT 能力来自蒸馏，在硬件约束推导上不一定强于已做领域 SFT+RL 的模型

更优基座选项：Qwen3-32B（2025 年 4 月发布，原生支持 119 种语言、32768 token 上下文、混合推理模式、支持 GRPO 训练），比 Qwen2.5 系的 R1-Distill 更新，且与昇腾生态亲和性已被验证（FlagRelease 已面向昇腾发布 Qwen3.5 等模型实例）。

🟡 问题 3：数据集"几千条"量级偏小

原方案提及的"几千条 SFT 样本"覆盖不了 tiling 空间与硬件边界约束的组合爆炸。参考基准：

• CUDA-Agent 构建了 6K 规模的 CUDA-Agent-Ops-6K 合成数据集，且经过严格的数据污染控制
• KernelLLM（Meta）用 Triton 编译器自动对齐构造 PyTorch↔Triton 配对样本，8B 模型在 KernelBench-Triton Level 1 单次推理得分 20.2，超过 GPT-4o(15) 和 DeepSeek V3(16)

启示：数据质量与结构化构造 > 数据规模。建议参考 KernelGen 与 CUDA-Agent 的做法，构建多源 CoT 数据集（kernel 结构 + tiling 策略 + 内存搬运 + API 约束 + 错误修正 + 调试样本）。

🟡 问题 4：CodeBuddy 做 Ascend C 静态审查——不够

CodeBuddy 基于腾讯混元代码大模型，本身也是通用基座，对 Ascend C 硬件约束同样不熟。静态审查必须交给 CANN 官方工具链：

• 毕昇编译器（Bisheng Compiler）的硬件亲和检查
• msKleaner 静态检查
• CANN 孪生调试（AscendC 的关键技术之一）
• LLM 仅做辅助审查，不做硬约束校验

---

三、开源生态对标盘点（修正版）

原报告列的 “AscendKernelGen” 未能在本次检索中核实，以下是已验证存在的对标对象：

直接对标（昇腾 / 多芯片算子生成）

🔷 众智 FlagOS KernelGen 2.0

• 面向多种 AI 芯片的算子生成自动化平台，覆盖"算子生成、基线构建、验证测试"完整生命周期
• 支持 Triton 和 Triton-TLE 两种语言
• 已适配昇腾等 6 款 AI 芯片（英伟达、海光、摩尔线程、华为昇腾、天数智芯、沐曦）
• 在英伟达上生成正确性和加速比显著超过 Claude Code；5 种国产芯片上生成正确性 >95%，>50% 算子性能优于芯片原生实现
• 用户通过自然语言/数学公式/已有实现描述需求，系统从算子生成知识库检索先验 → 生成 Triton 内核 → 与 PyTorch 基准做一致性校验 → 性能评测与自动化调优

💡 这是原方案最该优先评估的基线。它已经做了"昇腾上的 LLM 算子生成"，且走的是"生成 + 验证 + 调优"闭环，而非裸生成。

方法论对标（CUDA 领域，可借鉴训练范式）

🔷 ByteDance-Seed / CUDA-Agent

• 大规模 Agentic RL 系统，三件套：可扩展数据合成 + 技能增强执行环境 + 稳定长上下文 RL 训练
• 开源 CUDA-Agent-Ops-6K 数据集（6K 样本，严格污染控制）
• KernelBench 上 Level 1/2/3 加速率 100%/100%/92%，几何平均 2.11×
• 价值：证明"Execution-Feedback RL"在 kernel 生成上的决定性作用

🔷 Meta / KernelLLM

• 基座 Llama 3.1 Instruct 8B，PyTorch → Triton GPU kernel
• KernelBench-Triton Level 1 单次推理 20.2 分，超过 GPT-4o 和 DeepSeek V3
• 价值：8B 小模型 + 精专数据集即可打过通用大模型，对"必须 32B"构成反例

🔷 flagos-ai / KernelGen + KernelGenBench

• 众智 FlagOS 团队开源的算子生成平台与基准
• 综述论文 arxiv 2601.15727（系统综述）

昇腾官方生态侧

• CANN 全面开源开放：60+ 客户基于 CANN 打造 420+ 高性能算子；CATLASS、算子库、Ascend C、运行时等已全面开源到 GitCode
• 昇腾 Agent Skills 体系：华为已将数千名专家经验沉淀为 Skills，搭建 Agent 工作流，“开发者通过需求描述即可完成各类模型开发操作”
• Triton/TileLang 兼容：昇腾已实现 Triton 和 TileLang 接口 100% 兼容，性能可达 Ascend C 的 0.6~0.9 倍，开发周期缩短至一周，已支持 600+ Triton 算子和 300+ TileLang 算子

📌 关键信号：昇腾官方自己也在推 “Agent + Skills” 的算子开发范式，且 Triton/TileLang 路线已被官方认可为 Ascend C 的高效替代。原方案"死磕 Ascend C 原生生成"未必是最优解——Triton 路线可能开发周期更短、生态更成熟。

---

四、修订后的行动建议

第一步：先跑基线，别急着自研（最高优先级）

1. 拉取 众智 FlagOS KernelGen 2.0，在其已适配昇腾的平台上，用团队自有算子测试集跑一次端到端评测
2. 同时评估 Triton 路线：用昇腾原生支持的 Triton 接口 + KernelGen 的 Triton 生成能力，看是否满足业务需求
3. 若满足 → 直接复用，省去自研成本与重复造轮子风险

第二步：若基线不满足，再自研，但必须升级范式

若坚持自研 Ascend C 专用模型，按以下升级版路线：

基座选型 A/B：DeepSeek-R1-Distill-Qwen-32B  vs  Qwen3-32B
         ↓
数据集构造：参考 KernelGen 与 CUDA-Agent-Ops-6K 的做法，
        构建多源 CoT 数据集（≥ 同等量级）
         ↓
两阶段训练：
  阶段1 SFT：注入 CoT 推理样本
  阶段2 RL：Execution Feedback（CANN 编译器 + 910B 实机）
         ↓
评测闭环：接 CANN 编译器 + 910B 实机执行反馈
         ↓
静态审查：CANN 官方 msKleaner / Ascend Compiler + LLM 辅助

第三步：基座选型的判断依据要换

不要基于"通用预训练语料充足"做判断（CUDA 语料优势 ≠ Ascend C 语料优势）
要基于"垂直 SFT 数据集的可达性 + 与昇腾生态亲和性"做判断

具体 A/B 建议：

• DeepSeek-R1-Distill-Qwen-32B：优势是 R1 蒸馏的推理能力，劣势是 Qwen2.5 旧骨架
• Qwen3-32B：优势是原生长上下文 + 混合推理 + 已验证的昇腾亲和性，劣势是无 R1 蒸馏标签（但可用 GRPO 自训）

第四步：评测必须接实机

RL 阶段的 reward 必须来自：

• CANN 编译器通过率
• 910B 实机执行的正确性与性能校验

这是 SOTA 路线的硬性要求，也是原方案缺失的关键闭环。

---

五、原方案 vs 修订方案对比

维度	原方案	修订方案
基座	DeepSeek-R1-Distill-Qwen-32B（单一）	Qwen3-32B ↔ DS-R1-Distill 做 A/B
训练范式	SFT + LoRA 单阶段	SFT + Execution-Feedback RL 两阶段
数据集	几千条纯算子样本	多源 CoT 构造，量级对标 KernelGen / CUDA-Agent-Ops-6K
静态审查	CodeBuddy（通用模型）	CANN msKleaner/编译器 + LLM 辅助
是否自研	默认从零自研	先评估 KernelGen 2.0 基线，不满足再自研
语言路线	死磕 Ascend C 原生	Ascend C + Triton 双路线评估

---

六、风险提示（校准版）

⚠️ 原报告的风险点基本成立，但有一条需要修正：

• ✅ “仅 SFT 不做 RL → 复杂算子隐性 bug 不改善”——成立
• ✅ “数据集规模不足 → 泛化受限”——成立
• ⚠️ “AscendKernelGen 已开源 32B 模型 + 数据集”——本轮检索未直接核实到该具体仓库，建议以 HuggingFace/arXiv 原页面复核；但 KernelGen 2.0（众智 FlagOS）已开源且适配昇腾是已核实事实，"重复造轮子风险高"的结论依然成立，只是对标对象换成 KernelGen 2.0
• ➕ 新增风险：昇腾官方已原生支持 Triton/TileLang 且性能达 Ascend C 的 0.6~0.9 倍，纯 Ascend C 原生生成路线可能不是性价比最高的选择，建议同步评估 Triton 路线

---

六、开源同类模型盘点与对比
6.1 直接对标——Ascend C 领域已开源
用户要造的东西，学术界已经做出来并开源。这是本次审核最重要的发现。
6.1.1 AscendKernelGen / KernelGen-LM-32B
• HuggingFace 仓库：AscendKernelGen/KernelGen-LM-32B
• 论文：arxiv 2601.07160（ACL 2026 Findings 录用）
• 基座：Qwen3-32B（与方案的 DeepSeek-R1-Distill-Qwen-32B 同规模、同 Qwen 系）
• 训练：SFT（Ascend-CoT 数据集）+ RL with execution feedback，两阶段
• 数据集全部开源：Ascend-CoT-v1 / v2-packed / v3-json
• 框架：generation-evaluation integrated，含硬件接地评测
结论：通用 LLM 在 Ascend NPU 内核生成上失败率高，KernelGen-LM 经 SFT+RL 后显著超过 GPT-4o / DeepSeek V3 的单次生成。该成品是方案最直接的对标对象。
6.2 CUDA 领域同类开源（可借鉴方法）
6.2.1 ByteDance-Seed / cudaLLM
• GitHub：ByteDance-Seed/cudaLLM
• 数据集：ByteDance-Seed/cudaLLM-data（HuggingFace）
• 训练范式：两阶段 SFT + RL，8920 条 SFT 样本 + 71996 条 RL 样本
• 价值：两阶段训练流水线参考
6.2.2 BytedTsinghua-SIA / CUDA-Agent
• GitHub：BytedTsinghua-SIA/CUDA-Agent
• 论文：arxiv 2602.24286
• 特点：大规模 agentic RL，超过 Claude Opus-4.6 与 Gemini 3 Pro
• 价值：agentic RL 路线参考，方案双模型协同可升级为 agentic 工作流
6.2.3 Meta / KernelLLM
• HuggingFace：facebook/KernelLLM
• 基座：Llama 3.1 Instruct 8B
• 任务：PyTorch 转 Triton GPU kernel
• 特点：8B 小模型在 KernelBench-Triton 上超过 GPT-4o 与 DeepSeek V3
• 训练成本：仅 192 GPU 小时
价值：证明小模型 + 精专数据集可以打过通用大模型，对方案"32B 优先"的选型是一个反例参考。是否一定要 32B，值得再评估。
6.2.4 flagos-ai / KernelGen + KernelGenBench + awesome-LLM-driven-kernel-generation
• GitHub：flagos-ai/kernelgen、flagos-ai/KernelGenBench、flagos-ai/awesome-LLM-driven-kernel-generation
• 综述论文：arxiv 2601.15727（系统综述，含完整模型/方法清单）
• 价值：survey 仓库是该领域的"地图"，开工前必读
6.2.5 TritonRL 与 omniCUDA
• TritonRL（arxiv 2510.17891）：Triton kernel 训练，无执行反馈的纯推理-编码方案，CoT 推理增强方向参考
• omniCUDA：OpenMP 转 CUDA 自动转换，跨语言迁移方向参考
6.3 昇腾生态侧 Agent 实践参考
昇腾社区有《基于 Agent 的 Ascend 950 FFT 算子智能开发实践》一文（hiascend.com/developer/blog/details/02141212740341582013），做法是 Agent 先生成 Python 算法（限定只用 Ascend C 支持的计算），再生成 Ascend C kernel。该思路与方案分层架构高度一致，可借鉴"先生成算法骨架再降级到硬件"的两段式。
6.4 综合对比矩阵
七、综合结论与建议
7.1 综合结论
表 4 方案各维度审核结论
维度
评价
说明
方案整体方向
正确
与学术界主流路线一致
选型 DeepSeek-R1-Distill-Qwen-32B
存疑
不一定优于已开源的 KernelGen-LM-32B（Qwen3-32B 基座）
SFT + LoRA 单阶段
缺失
缺 RL with execution feedback，复杂算子仍会隐性 bug
双模型分工架构
合理
静态审查交给 CodeBuddy 不够，需配 CANN 编译器/msKleaner
数据集几千条
偏小
建议直接用 Ascend-CoT-v3 或在其基础上扩充
重复造轮子风险
高
AscendKernelGen 已开源 32B 模型 + 数据集 + 框架
7.2 行动建议
基于上述审核结论，建议按以下顺序推进：
7.2.1 先跑基线
拉取 AscendKernelGen/KernelGen-LM-32B 模型，在团队自有的卷积算子测试集上跑一次，评估是否满足业务需求。若满足，直接复用，省去自研成本。
7.2.2 若不满足再自研
若基线不满足，以 Ascend-CoT-v3 为底，叠加团队私有样本（错误修复案例），用 SFT + RL 两阶段训练。数据集规模至少达到 Ascend-CoT v3 的同等量级。
7.2.3 基座选型 A/B
若坚持自研，基座可在 DeepSeek-R1-Distill-Qwen-32B 与 Qwen3-32B 间做 A/B，用 KernelBench / KernelGenBench 做基准评测再决定。不建议基于"通用预训练语料充足"做判断，应以"垂直 SFT 数据集的可达性"为依据。
7.2.4 评测闭环必接实机
必须接 CANN 编译器 + 910B 实机执行反馈，作为 RL 阶段的 reward 来源。这是 SOTA 路线的硬性要求。
7.2.5 参考综述再定细节
参考 flagos-ai/awesome-LLM-driven-kernel-generation 综述仓库与 arxiv 2601.15727 综述论文，再敲定方案细节。该综述是该领域的"地图"，避免遗漏已有工作。
7.3 风险提示
• 若不顾及 AscendKernelGen 已开源的事实强行从零自研，可能被同行评议为重复造轮子，影响对外发表与社区评价；
• 若仅做 SFT 不做 RL，复杂算子的隐性 bug 问题不会显著改善，方案的核心收益无法兑现；
• 若数据集规模不足，模型在 tiling 空间与硬件边界约束的组合爆炸上覆盖不够，泛化能力受限

附：参考资料（已核实）

1. 众智 FlagOS 2.0 发布与 KernelGen 2.0 技术细节
2. 昇腾 CANN 全面开源开放进展
3. 昇腾 AI 开发者峰会 2026：CANN 开源、Triton/TileLang 兼容、Agent Skills
4. CUDA-Agent：大规模 Agentic RL for CUDA Kernel Generation
5. Meta KernelLLM：8B 模型在 KernelBench-Triton 超过 GPT-4o
6. 昇腾 CANN 生态：Ascend C 2.0、CATLASS、毕昇编译器
7. Qwen3-32B 基座模型规格

建议下一步：先到 HuggingFace 核实原报告提到的 AscendKernelGen 仓库是否真实存在；无论核实结果如何，都把 众智 FlagOS KernelGen 2.0 作为首要基线进行评估——这是当前公开材料里最接近"昇腾上的 LLM 算子生成成品"的对象。
八、附录：参考资料
8.1 学术论文
• AscendKernelGen: A Systematic Study of LLM-Based Kernel Generation for Neural Processing Units. arxiv 2601.07160, ACL 2026 Findings.
• Towards Automated Kernel Generation in the Era of LLMs. arxiv 2601.15727.
• Large-Scale Agentic RL for High-Performance CUDA Kernel Synthesis. arxiv 2602.24286.
• TritonRL: Training LLMs to Think and Code Triton Without Execution Feedback. arxiv 2510.17891.
8.2 开源仓库
• HuggingFace: AscendKernelGen/KernelGen-LM-32B
• HuggingFace Datasets: AscendKernelGen/Ascend-CoT-v1, Ascend-CoT-v2-packed, Ascend-CoT-v3-json
• GitHub: ByteDance-Seed/cudaLLM
• HuggingFace Datasets: ByteDance-Seed/cudaLLM-data
• GitHub: BytedTsinghua-SIA/CUDA-Agent
• HuggingFace: facebook/KernelLLM
• GitHub: flagos-ai/awesome-LLM-driven-kernel-generation
• GitHub: flagos-ai/KernelGenBench
8.3 昇腾官方资源
• 昇腾社区博客: 基于 Agent 的 Ascend 950 FFT 算子智能开发实践. hiascend.com/developer/blog/details/02141212740341582013
• CANN 算子开发场景. hiascend.com/cn/developer/operator
• Ascend C 编程文档. developer.huawei.com/consumer/cn/doc/hiai-Guides/cannkit-introduction-to-ascend-c-0000002122163424
8.4 通用工具与框架
• OpenCode: opencode.ai
• CodeBuddy: 腾讯云代码助手
• LLaMA Factory: LoRA 微调主流框架
• vllm-ascend: 昇腾 NPU 推理部署

K3 + 自建 Ascend C 算子专用微调模型 方案技术审核报告

审核对象：《K3 + 自建 Ascend C 算子专用微调模型（DeepSeek-R1-Distill-Qwen-32B 优先）+ OpenCode/CodeBuddy 协同架构》方案
审核性质：技术审核 + 开源生态对标

---

一、摘要

本报告针对《K3 + 自建 Ascend C 算子专用微调模型（DeepSeek-R1-Distill-Qwen-32B 优先）+ OpenCode/CodeBuddy 协同架构》方案进行技术审核，并就其选型与方法论对标当前开源生态中的同类模型。

审核结论：方案的核心方向正确——通用大模型不等于领域专用模型，必须通过监督微调（SFT）注入昇腾硬件领域知识——这一判断与 arxiv 2601.07160（AscendKernelGen 论文，ACL 2026 Findings）的实证结论一致。但在选型论证、训练阶段完整性、数据集规模与重复造轮子风险四个维度上存在显著问题。

关键发现：学术界已于 2026 年 1 月开源 AscendKernelGen 框架，含 KernelGen-LM-32B 模型（Qwen3-32B 基座）与 Ascend-CoT v1/v2/v3 数据集，方案所提"自研 32B 微调模型"已存在直接对标的开源成品。建议优先评估该成品的可用性，再决定是否从零自研。

---

二、方案概述与审核目标

2.1 方案核心主张

方案主张：通用大模型（如 GLM5.2）直接生成 Ascend C 算子内核会失败，原因是预训练语料中 Ascend C、Cube 流水线、L0/L1 显存隔离、Tiling 约束等样本极少；通用模型对昇腾硬件特有语义理解不足，生成代码常出现隐性 bug（缓冲区溢出、数据对齐、PipeQueue 时序错误），表面能编译但跑起来卡死或精度异常。

基于此判断，方案提出以 DeepSeek-R1-Distill-Qwen-32B 为基座，做 LoRA 微调，构建算子专用垂直模型；同时配套 CodeBuddy / OpenCode 作为通用代码助手，承担宿主代码、工程化封装、调试等通用任务，形成**"双模型分层协同"架构**。

2.2 审核目标

本次审核目标包含三项：

1. 审核方案核心判断与选型论据的成立性；
2. 审核方法论（数据集、训练、推理、集成）的完整性与先进性；
3. 盘点开源生态中是否存在可直接复用或对标的同类模型，评估重复造轮子风险。

---

三、审核范围、依据与方法

3.1 审核范围

审核范围限定为方案文本本身所阐述的技术路线与选型论证，不涉及 K3 平台的具体实现细节、私有数据集的真实规模与质量、内部 GPU/NPU 算力配置与训练进度。

3.2 审核依据

审核依据为公开学术资料与开源社区资源，主要包括：

• arxiv 2601.07160《AscendKernelGen: A Systematic Study of LLM-Based Kernel Generation for Neural Processing Units》（ACL 2026 Findings 录用）；
• HuggingFace 开源仓库 AscendKernelGen/KernelGen-LM-32B 及 Ascend-CoT v1/v2/v3 数据集；
• ByteDance-Seed/cudaLLM、BytedTsinghua-SIA/CUDA-Agent、Meta facebook/KernelLLM 等同类开源项目；
• flagos-ai/awesome-LLM-driven-kernel-generation 综述仓库及 arxiv 2601.15727 综述论文；
• 昇腾社区官方技术博客与 CANN 文档。

3.3 审核方法

采用**“对标式审核”**：将方案的核心论点与开源同类工作的实证结论逐项对照，识别方案成立的部分、论据偏弱的部分、方法论缺失的部分；并就每项给出可执行的改进建议。

---

四、核心发现：方案要点与对标结论

4.1 方案核心判断成立 ✅

结论：方案对"通用大模型不能直接写 Ascend C 算子"的判断成立，且已被学术界验证。

arxiv 2601.07160 的研究显示，SOTA 通用 LLM（包括 GPT-4o、DeepSeek V3 等）在 Ascend NPU 内核生成上的功能性通过率极低，尤其在 Tiling 推导、L0/L1 内存边界、PipeQueue 时序等硬件约束上系统性翻车。这一实证结论与方案对 GLM5.2 失败的归因分析高度一致。

此外，方案的**"双模型分层协同"架构**（通用助手负责工程化、垂直模型独占内核生成）也合理，与 CUDA-Agent 论文（arxiv 2602.24286）中 agent 拆解任务的思路一致。

4.2 选型论据存在硬伤 ⚠️

方案对 DeepSeek-R1-Distill-Qwen-32B 的选型论证存在三处硬伤：

表 1 选型论据问题清单

论点	问题	严重度
支持上下文 32K	实际基于 Qwen2.5 骨架，原生 context 76K+，32K 是低估	低
社区大量 CUDA Kernel 储备优于 GLM	对 Ascend C 不成立。Ascend C 社区样本稀缺，公开预训练语料占比几乎可忽略	高
Qwen 骨架昇腾生态成熟	站得住，但 Qwen3-32B 比 Qwen2.5（R1-Distill 基座）更新，AscendKernelGen 已用 Qwen3-32B 做基座	中
R1 系列多步推理优势利于 Tiling 推导	CoT 能力来自 R1 蒸馏，在数学规划类任务上不一定强于已经做过领域 SFT+RL 的模型	中

其中**“社区大量 CUDA Kernel 储备”**这一论据尤其需要警惕。DeepSeek-R1-Distill 的优势主要在 CUDA/Triton 类语料，迁移到 Ascend C 边界约束有限；Ascend C 的领域样本本就稀缺，方案不应基于"通用预训练语料充足"做选型判断，而应基于"垂直 SFT 数据集的可达性"做判断。

4.3 方法论缺失关键阶段 ⚠️

方案只提了 SFT + LoRA 单阶段，但当前 SOTA 路线是两阶段：

• 第一阶段 SFT 注入 CoT 推理样本；
• 第二阶段 RL with execution feedback（可执行反馈强化学习）。

ByteDance cudaLLM、CUDA-Agent、AscendKernelGen 全部采用两阶段方案。

缺失 RL 阶段意味着：单纯 SFT 后的模型在复杂卷积/Cube 算子上仍会大量隐性 bug，这正是用户之前的核心痛点。建议必加 execution-feedback RL 阶段，reward 来自 CANN 编译器与 910B 实机执行的通过率与精度校验。

4.4 数据集规模偏小 ⚠️

方案提及"几千条 Ascend C 算子 SFT 样本"，量级偏小。AscendKernelGen 的 Ascend-CoT 是多源构造（kernel 结构 + tiling 策略 + 内存搬运 + API 约束 + 错误修正 + 调试样本），迭代到 V3 版本。几千条纯算子代码样本，覆盖不了 tiling 空间与硬件边界约束的组合爆炸。

4.5 双模型分工中的辅助环节偏弱 ⚠️

方案让 CodeBuddy 承担"Ascend C 静态代码审查"任务（2.2 步），但 CodeBuddy 基于腾讯混元代码大模型，本身也是通用基座，对 Ascend C 同样不熟。建议补充 CANN 官方 msKleaner / Ascend Compiler 静态检查工具做硬约束校验，LLM 仅做辅助审查。

---

五、问题诊断与根因分析

5.1 问题汇总

表 2 方案问题诊断与影响

问题	根因	影响	建议优先级
选型论据"社区 CUDA 样本充足"对 Ascend C 不成立	将 CUDA 生态优势错误迁移到 Ascend C	基座选型决策依据不实	高
仅 SFT + LoRA 单阶段，缺 RL with execution feedback	方案写作时未对标 2026 年 SOTA 路线	复杂算子仍有隐性 bug，核心痛点未解	高
数据集仅几千条	未对标 Ascend-CoT v3 的多源 CoT 构造	组合爆炸覆盖不足	高
CodeBuddy 做 Ascend C 静态审查	将通用代码模型误用于领域约束校验	审查无效或漏报	中
未识别 AscendKernelGen 已开源	调研不充分	重复造轮子风险	极高

5.2 根因分析

上述问题可归纳为两条根因：

根因一：方案在选型与方法论论证时，未对标 2026 年 1 月已发表的 AscendKernelGen 论文与开源成品，导致论证依据停留在 2025 年的认知水平。该论文不仅验证了方案的核心判断，还直接给出了选型与方法论的反例（Qwen3-32B 基座 + 两阶段 SFT+RL + 多源 CoT 数据集）。

根因二：方案对"领域垂直模型"的方法论认知停留在 SFT 阶段，未跟进 agentic RL with execution feedback 的 SOTA 路线。这一路线在 CUDA 领域（cudaLLM、CUDA-Agent）与 Ascend 领域（AscendKernelGen）均已验证，是 2026 年的共识做法。

---

六、开源同类模型盘点与对比

6.1 直接对标——Ascend C 领域已开源

用户要造的东西，学术界已经做出来并开源。这是本次审核最重要的发现。

6.1.1 AscendKernelGen / KernelGen-LM-32B

• HuggingFace 仓库：AscendKernelGen/KernelGen-LM-32B（另含 8B 版本 KernelGen-LM-8B 及 RL 后版本 KernelGen-LM-32B-RL）
• 论文：arxiv 2601.07160（ACL 2026 Findings 录用，作者：Xinzi Cao 等，鹏城实验室 + 华为昇腾 + 中山大学联合）
• 基座：Qwen3-32B（与方案的 DeepSeek-R1-Distill-Qwen-32B 同规模、同 Qwen 系）
• 训练：SFT（Ascend-CoT 数据集）+ RL with execution feedback（DPO，基于执行正确性与性能信号），两阶段
• 数据集全部开源：Ascend-CoT-v1 / v2-packed / v3-json
• 框架：generation-evaluation integrated，含硬件接地评测（NPUKernelBench）

实证结论：通用 LLM 在 Ascend NPU 内核生成上失败率高（复杂 L2/L3 执行成功率约 0%），KernelGen-LM 经 SFT+RL 后：

• 复杂 Level-2 编译成功率从 0% → 95.5%（Pass@10）
• 功能正确率从完全失败 → 64.3%
• 性能在多数算子上超越专家基线

该成品是方案最直接的对标对象。

6.2 CUDA 领域同类开源（可借鉴方法）

6.2.1 ByteDance-Seed / cudaLLM

• GitHub：ByteDance-Seed/cudaLLM
• HuggingFace 模型：ByteDance-Seed/cudaLLM-8B（基于 Qwen3-8B）
• 数据集：ByteDance-Seed/cudaLLM-data（ModelScope）
• 训练范式：两阶段 SFT + RL
  • SFT 数据集：sft_cuda_llm_r1.parquet（由 DeepSeek R1、DeepSeek Coder-7B、Qwen2-32B 生成）
  • RL 数据集：rl_cuda_llm_0424.parquet（提供基于性能的 reward）
• KernelBench 性能：Level-1 Bo16 = 87，Level-2 Bo16 = 73，Level-3 Bo16 = 36
• 价值：两阶段训练流水线参考，含完整 verl 训练脚本

6.2.2 BytedTsinghua-SIA / CUDA-Agent

• GitHub：BytedTsinghua-SIA/CUDA-Agent（项目页 cuda-agent.github.io）
• 论文：arxiv 2602.24286
• 特点：大规模 agentic RL
  • 三件套：可扩展数据合成 + 技能增强执行环境（SKILL.md）+ 稳定长上下文 RL 训练
  • 6K 规模 CUDA-Agent-Ops-6K 合成数据集（seed 挖掘 → 组合合成 → 执行过滤，严格污染控制）
  • ReAct 风格 agent 循环，支持迭代编码-编译-调试-性能分析
  • 单轮 PPO 预热 → RFT actor 初始化 → 多轮 agentic RL（128K context，150 训练轮）
• KernelBench 成绩：Level-1/2/3 加速率 100%/100%/92%（vs torch.compile），几何平均 2.11×
• 超越对象：Claude Opus 4.5、Gemini 3 Pro
• 价值：agentic RL 路线参考，方案双模型协同可升级为 agentic 工作流

6.2.3 Meta / KernelLLM

• HuggingFace：facebook/KernelLLM
• 基座：Llama 3.1 Instruct 8B
• 任务：PyTorch → Triton GPU kernel
• 数据集：~25,000 条 PyTorch↔Triton 配对样本（TheStack 过滤 + torch.compile() 合成 + KernelBook）
• 训练：SFT 10 epoch，batch 32，仅 192 GPU 小时
• 特点：8B 小模型在 KernelBench-Triton Level 1 单次推理 20.2 分，超过 GPT-4o(15) 与 DeepSeek V3(16)；多推理次数下超过 DeepSeek R1
• 价值：证明小模型 + 精专数据集可以打过通用大模型，对方案"32B 优先"的选型是一个反例参考。是否一定要 32B，值得再评估。

6.2.4 flagos-ai / KernelGen + KernelGenBench + awesome-LLM-driven-kernel-generation

• GitHub：
  • flagos-ai/KernelGen（v2.0，AI 驱动的 Triton 算子自动生成平台）
  • flagos-ai/KernelGenBench（多来源、多芯片的统一算子生成评测基准）
  • flagos-ai/awesome-LLM-driven-kernel-generation（领域综述仓库）
• KernelGen 2.0 核心能力：
  • MCP 驱动的自动化工作流（生成 → 优化 → 测试 → 集成）
  • 日志驱动的自动错误修复、AI 驱动自动调优
  • 多硬件适配（英伟达、昇腾、摩尔线程、沐曦、海光 DCU、天数智芯）
  • IDE 集成（Claude Code / VS Code / OpenClaw / MCP agents）
  • 已支撑 FlagGems（全球最大跨芯片算子库，510+ 算子，80% 由 AI 自动生成）
• KernelGenBench：210 个算子（ATen 110 + vLLM 50 + cuBLAS 50），6 款芯片评测，150 亿 Token 验证规模，含防作弊机制
• 综述论文：arxiv 2601.15727（系统综述，含完整模型/方法清单）
• 价值：survey 仓库是该领域的"地图"，开工前必读

6.2.5 TritonRL 与 omniCUDA

• TritonRL（arxiv 2510.17891）：Triton kernel 训练，无执行反馈的纯推理-编码方案，CoT 推理增强方向参考
• omniCUDA：OpenMP 转 CUDA 自动转换，跨语言迁移方向参考

6.3 昇腾生态侧 Agent 实践参考

昇腾社区有《基于 Agent 的 Ascend 950 FFT 算子智能开发实践》一文（hiascend.com/developer/blog/details/02141212740341582013），做法是 Agent 先生成 Python 算法（限定只用 Ascend C 支持的计算），再生成 Ascend C kernel。该思路与方案分层架构高度一致，可借鉴"先生成算法骨架再降级到硬件"的两段式。

6.4 综合对比矩阵

表 3 开源同类模型综合对比

项目	领域	基座规模	训练方法	开源内容	对标价值
AscendKernelGen	Ascend C	32B (Qwen3)	SFT + RL	模型+数据集+框架	⭐⭐⭐⭐⭐ 直接对标
cudaLLM	CUDA	8B (Qwen3)	SFT + RL	代码+数据集	⭐⭐⭐⭐ 方法论参考
CUDA-Agent	CUDA	未公开	Agentic RL	代码+数据集	⭐⭐⭐⭐ 路线参考
KernelLLM	Triton	8B (Llama 3.1)	SFT	模型	⭐⭐⭐ 规模反例
flagos-ai KernelGen	Triton	多基座	Agentic	代码+benchmark	⭐⭐⭐ 工程参考
TritonRL	Triton	未公开	纯推理训练	论文	⭐⭐ 方向参考

---

七、综合结论与建议

7.1 综合结论

表 4 方案各维度审核结论

维度	评价	说明
方案整体方向	✅ 正确	与学术界主流路线一致
选型 DeepSeek-R1-Distill-Qwen-32B	⚠️ 存疑	不一定优于已开源的 KernelGen-LM-32B（Qwen3-32B 基座）
SFT + LoRA 单阶段	❌ 缺失	缺 RL with execution feedback，复杂算子仍会隐性 bug
双模型分工架构	✅ 合理	静态审查交给 CodeBuddy 不够，需配 CANN 编译器/msKleaner
数据集几千条	⚠️ 偏小	建议直接用 Ascend-CoT-v3 或在其基础上扩充
重复造轮子风险	🔴 高	AscendKernelGen 已开源 32B 模型 + 数据集 + 框架

7.2 行动建议

基于上述审核结论，建议按以下顺序推进：

7.2.1 先跑基线

拉取 AscendKernelGen/KernelGen-LM-32B 模型，在团队自有的卷积算子测试集上跑一次，评估是否满足业务需求。若满足，直接复用，省去自研成本。

7.2.2 若不满足再自研

若基线不满足，以 Ascend-CoT-v3 为底，叠加团队私有样本（错误修复案例），用 SFT + RL 两阶段训练。数据集规模至少达到 Ascend-CoT v3 的同等量级。

7.2.3 基座选型 A/B

若坚持自研，基座可在 DeepSeek-R1-Distill-Qwen-32B 与 Qwen3-32B 间做 A/B，用 KernelBench / KernelGenBench 做基准评测再决定。不建议基于"通用预训练语料充足"做判断，应以"垂直 SFT 数据集的可达性"为依据。

7.2.4 评测闭环必接实机

必须接 CANN 编译器 + 910B 实机执行反馈，作为 RL 阶段的 reward 来源。这是 SOTA 路线的硬性要求。

7.2.5 参考综述再定细节

参考 flagos-ai/awesome-LLM-driven-kernel-generation 综述仓库与 arxiv 2601.15727 综述论文，再敲定方案细节。该综述是该领域的"地图"，避免遗漏已有工作。

7.3 风险提示

• 若不顾及 AscendKernelGen 已开源的事实强行从零自研，可能被同行评议为重复造轮子，影响对外发表与社区评价；
• 若仅做 SFT 不做 RL，复杂算子的隐性 bug 问题不会显著改善，方案的核心收益无法兑现；
• 若数据集规模不足，模型在 tiling 空间与硬件边界约束的组合爆炸上覆盖不够，泛化能力受限。

---

八、附录：参考资料

8.1 学术论文

论文	arXiv	备注
AscendKernelGen: A Systematic Study of LLM-Based Kernel Generation for Neural Processing Units	2601.07160	ACL 2026 Findings，鹏城+华为昇腾+中大
Towards Automated Kernel Generation in the Era of LLMs	2601.15727	系统综述
Large-Scale Agentic RL for High-Performance CUDA Kernel Synthesis (CUDA Agent)	2602.24286	字节+清华
TritonRL: Training LLMs to Think and Code Triton Without Execution Feedback	2510.17891	CoT 推理增强方向

8.2 开源仓库

模型

• HuggingFace: AscendKernelGen/KernelGen-LM-32B（SFT 版）
• HuggingFace: AscendKernelGen/KernelGen-LM-32B-RL（RL 后版本）
• HuggingFace: AscendKernelGen/KernelGen-LM-8B（8B 小模型版）
• HuggingFace: ByteDance-Seed/cudaLLM-8B
• HuggingFace: facebook/KernelLLM

数据集

• HuggingFace Datasets: AscendKernelGen/Ascend-CoT-v1
• HuggingFace Datasets: AscendKernelGen/Ascend-CoT-v2-packed
• HuggingFace Datasets: AscendKernelGen/Ascend-CoT-v3-json
• ModelScope: ByteDance-Seed/cudaLLM-data
• HuggingFace Datasets: GPUMODE/KernelBook（KernelLLM 训练数据）

代码

• GitHub: ByteDance-Seed/cudaLLM
• GitHub: BytedTsinghua-SIA/CUDA-Agent
• GitHub: flagos-ai/KernelGen（v2.0）
• GitHub: flagos-ai/KernelGenBench
• GitHub: flagos-ai/awesome-LLM-driven-kernel-generation
• GitHub: weich97/NPUKernelBench（AscendKernelGen 官方评测框架）

8.3 昇腾官方资源

• 昇腾社区博客：《基于 Agent 的 Ascend 950 FFT 算子智能开发实践》— hiascend.com/developer/blog/details/02141212740341582013
• CANN 算子开发场景：hiascend.com/cn/developer/operator
• Ascend C 编程文档：developer.huawei.com/consumer/cn/doc/hiai-Guides/cannkit-introduction-to-ascend-c-0000002122163424

8.4 通用工具与框架

• OpenCode: opencode.ai
• CodeBuddy: 腾讯云代码助手
• LLaMA Factory: LoRA 微调主流框架
• vllm-ascend: 昇腾 NPU 推理部署

---

📌 一句话收束：方向对、论据偏、阶段缺、数据小、成品已存在——先跑 AscendKernelGen/KernelGen-LM-32B 基线，不满足再走 SFT+RL 自研，且基座务必做 A/B。