---

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 领域与 Ascend 领域均已验证，是 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，含硬件接地评测
实证结论：通用 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
○ 三件套：可扩展数据合成 + 技能增强执行环境+ 稳定长上下文 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 算子智能开发实践》一文。该思路与方案分层架构高度一致，可借鉴“先生成算法骨架再降级到硬件”的两段式。

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 通用工具与框架

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

---

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