Ascend for PyTorch框架Skills实战系列——算子适配

在Ascend for PyTorch（TorchNPU）研发中，算子适配需求量大、细节繁杂。单个算子适配涉及14+个文件、13个步骤——YAML注册、C++ kernel实现、Meta入图推导、autograd反向绑定，任一环出错都会导致编译报错、精度对不齐，甚至构建中断。开发者常陷入"改一个文件、编译一次、报错再改"的循环，适配一个算子动辄数天，开发效率低。

针对这一痛点，昇腾推出面向TorchNPU算子适配的AI Skill方案，将子模块拉取、分支对齐、算子注册、kernel实现到编译验证的全链路沉淀为标准化流程，把依赖人工试错的过程转化为可跟随、可复现的操作路径，核心价值是降低适配门槛、减少流程性返工。

基于此，本文带来保姆级教程——30分钟用AI Skill跑通TorchNPU算子适配全流程。从环境准备、仓库拉取、算子注册、编译验证，每个步骤都提供详细的指导，新手也能一次跑通。

成果预览

以npu_gelu_mul算子为例，完整跑通了TorchNPU算子适配的13个步骤——从解析文档、注册算子、实现C++ kernel、补齐 Meta 推导，到一致性校验、编译、测试、文档和ATK验收，全部通过：三处描述0 mismatch、单元测试13/13、FakeTensor 2/2、ATK 500用例全过。这意味着算子适配从"依赖人工反复试错"变成了一条可复现、可验证、可推广的标准化流水线，核心价值是降低适配门槛、减少流程性返工。

环境准备清单

分步实施
Step 1：环境搭建（五步到位）

使用算子接入Skill技能，环境搭建只需五步：

1.执行git 命令：git clone https://gitcode.com/Ascend/op-plugin.git，拉取 op-plugin 代码：

2.准备conda环境+CANN 9.0+大模型GLM5.2（Python 3.10+torch 2.10），直接放在set_env.sh中，启动Agent之前，执行source set_env.sh

3.提供算子的2个输入文件（.md + _def.cpp），可选ATK文件)

4.将skills放入 .trae/skills/（或 .claude/skills/）；

5. 大模型选用GLM-5.2，即可下发命令开始适配。

Step 2：选择工作模式并下发命令

算子接入由 4 个核心技能协同完成，覆盖“适配生成 → 功能验证 → 精度保障 → 文档交付”全链路。op-adaptation是主编排，在关键节点调度其余三个技能：

输入：算子 .md + _def.cpp（+ 可选 ATK 用例）

│

┌──────────▼──────────┐

│ op-adaptation │

主流程编排：核心适配代码生成

│

解析→确认→生成→验证→构建 │

└───┬───────┬───────┬─┘

┌──────┘ │ └──────┐

▼ ▼ ▼

op-test op-apidoc op-delimitation

UT

功能验证 API 文档 ATK 泛化测试+定位定界

op-adaptation（算子适配）：主编排。接收算子 .md 与 _def.cpp，自动完成“解析输入 → 确认参数 → 生成 YAML → 推导反向 → 编写 C++ → 生成 Meta → 签名校验 → 编译构建”的闭环。

op-test（单元测试）：自动生成覆盖正例、负例和 FakeTensor 的单元测试，内置覆盖矩阵对账门禁，测试用例数与覆盖矩阵逐行比对，少一个都不放行。

op-delimitation（定位定界）：基于 CANN ATK 泛化测试用例自动执行，一旦失败即定位问题归属——是适配层、算子还是底层 ACL，给出明确结论。

op-apidoc（API 文档）：生成符合规范的中文 API 参考文档，确保接口说明准确、最新。

四个技能通过一份贯穿全流程的 CHECKLIST.md 协作——它是步骤间传递状态的主数据通道，让整个适配过程可追溯、可审查。

Step 3：按模式执行（三种演示）

（1）Create模式使用场景和演示

使用场景：从无到有接入算子到TorchNPU,Create 模式自动跑完整条链路。

工作流程：输入新算子的 .md 说明和 _def.cpp 原型，开发者只需做两件事：下发命令、确认几个关键场景（是否支持反向、是否需要图模式、版本变体等）。确认后从代码生成、编译安装到 UT 测试、ATK 定位定界，全部由4个技能完成。

使用演示（以npu_gelu_mul为例）:

1、下发命令，给提示词

2、根据实际情况确认场景

3、后面流程全部交给Skill,无需开发者参与

接口名称新增

C++ Kernel 文件开发

Meta推导注册

测试脚本

文档导航栏菜单添加

4、接入成功后，流程概览

（2）Modify模式

使用场景：为存量算子做接入。它覆盖 5 种典型改造场景：

工作流程：Modify 模式先做现状审计（discover）扫描算子在代码库中的状态，再做范围定界（scope）明确本次触及的文件并交开发者确认，最后按需执行（execute）被命中的步骤并强制走验收（编译 + 测试）。

Modify 模式的关键在于精准：只改该改的文件，绝不"顺手优化"无关代码。

使用演示（以npu_add_rms_norm_v2补齐为例）：

1、下发命令，给提示词

2、下面流程全部有Skill 完成，先确认修改范围 

3、按照步骤2中确定的修改范围执行（部分代码执行如下：测试UT、Meta注册）

4、成功接入后，流程概览

（3）M-adapt模式

使用场景：新一代 Ascend 950仅支持 aclnn 接口，不兼容昇腾A2/A3系列产品使用的老 ACL。大量存量算子需要"API 接口不变、底层新增 aclnn 路径"才能跑在Ascend 950上。M-adapt 的核心是一张状态判定表——技能先分析算子当前状态，再决定走哪条处理路径：

状态C和E才真正进入M-adapt，D转入Create，A/B直接跳过——每个算子都走最短的正确路径，避免重复劳动。

使用演示(以npu_cipou为例，适配Ascend 950):

1.下发命令

2.后面的命令由Skill 完成，明确算子当前状态为C状态

3.根据输入文档和模板完成代码开发

4.成功加入Ascend 950后，流程概览

Troubleshooting（FAQ）

Q1:Skills 放入目录后 Agent 未识别

确认目录为 .trae/skills/或 .claude/skills/（取决于所用 Agent 平台），且skills子目录结构完整（每个技能一个独立文件夹，含 SKILL.md）。

Q2：Create 模式生成后编译报错

查看CHECKLIST.md中哪一步未打勾。常见原因：Meta推导注册遗漏或autograd反向绑定签名不匹配。Skill会在编译构建阶段自动捕获并定位。

Q3：source set_env.sh后CANN 版本仍不匹配

确认CANN版本≥9.0，且set_env.sh中ASCEND_HOME_PATH 指向正确安装路径。M-adapt模式需额外确认aclnn库已包含在CANN中。

结语

算子接入Skill把TorchNPU适配这条"14+文件、13步骤"的复杂链路，编码为4个技能协同、3种模式覆盖、1份CHECKLIST贯穿的自动闭环。无论是从零新建算子（Create）、存量改造（Modify），还是跨平台迁移到 Ascend 950（M-adapt），开发者只需下发命令 + 确认关键场景，其余交给AI——让适配过程可复用、可验证、可追溯。

后续展望：

• 持续扩展Skill覆盖的算子类型与改造场景

• 深化ATK泛化测试与定位定界的自动化程度

• 推动CHECKLIST.md成为算子接入的标准交付物

资源链接：

• op-plugin代码仓：https://gitcode.com/Ascend/op-plugin

◆往期推荐◆

昇腾950系列超节点依托DeepSeek开源基础组件，释放极致性能