从昇腾 910 到昇腾 310P，一套 Skill 打通扫描、迁移、验证与交付。

Ascend C 算子从昇腾 910 迁移到昇腾 310P，往往不是简单地新增一个 SoC 名称。Host 注册、构建路由、kernel 宏分支、DataCopy 语义、dtype 能力、tiling key 和尾块写回都可能成为迁移过程中的隐性风险。

本文介绍的 op-ascend-migration Skill，聚焦昇腾 910 到昇腾 310P 的迁移场景，提供一套从静态扫描、路线选择、兼容改造到验证交付的标准化流程。

背景介绍

随着昇腾硬件代际持续演进，越来越多已有 Ascend C 自定义算子需要从昇腾 910 路径扩展到昇腾 310P。对开发者而言，迁移的难点并不只在"能不能编译"，更在于迁移后的能力边界是否清晰、源代际路径是否被保留、目标代际是否真正通过精度与功能验证。

在实际工程中，一个算子的代际支持通常分散在多个位置：Host 侧 AddConfig、opFile.value 路由、CMake 和 build.sh 的 SoC 清单、kernel 中的 __CCE_AICORE__ 或 __NPU_ARCH__ 分支、测试配置，以及算子内部的搬运和流水逻辑。人工逐项排查不仅耗时，也容易遗漏。

迁移挑战

以常见的昇腾 910 算子迁移到昇腾 310P 为例，开发者经常会遇到以下问题：

• Host 侧声明了昇腾 310P，但 kernel 仍然误走源代际专用路径。
• 昇腾 310P 路径上仍然存在 DataCopyPad 或非 32B 对齐写回，导致尾块覆盖相邻逻辑输出的风险。
• BF16、量化或其他 dtype 能力被机械复制，但昇腾 310P 路径缺少 kernel、tiling 和精度验证结果。
• 构建、测试、SoC 路由脚本没有同步更新，导致代码看似迁移完成，实际不会进入昇腾 310P 验证链路。
• 只修改单个文件，没有形成可复查的改动清单、验证命令和残余风险说明。

因此，昇腾 910 到昇腾 310P 的迁移需要的不只是经验清单，而是一套能够主动发现风险、约束修改范围、沉淀验证结果的工程流程。

Skills 架构设计

op-ascend-migration Skill 将昇腾 910 到昇腾 310P 的迁移拆成"扫描识别、路线选择、分层改造、验证交付"四个核心环节。它的目标不是用模板覆盖所有场景，而是在不破坏源代际路径的前提下，帮助开发者选择最小足够的昇腾 310P 迁移方案。

环节	重点检查项	典型产出
静态扫描	Host 注册、构建清单、kernel 宏、dtype、DataCopyPad、binary/config	昇腾 310P 迁移画像、风险提示
路线选择	是否只需兼容注册，是否需要 dtype 收窄，是否存在尾块写回风险	昇腾 310P 迁移方案、修改边界
分层改造	Host AddConfig("ascend310p")、构建 SoC 清单、昇腾 310P 可达 kernel 分支	代码改动清单、测试清单
验证交付	构建、精度、功能验证，或明确的静态审查结论	迁移报告、残余风险

阶段一：静态扫描，先建立迁移画像

迁移开始前，Skill 会优先运行静态扫描器 scan_ascendc_migration.py，对算子仓库或算子目录进行模式识别。扫描目标覆盖 Host、kernel、构建脚本、测试配置和静态 config 文件，避免开发者一上来就陷入局部代码修改。

OP_ASCEND_MIGRATION_SKILL_DIR="/path/to/op-ascend-migration"
python3 "$OP_ASCEND_MIGRATION_SKILL_DIR/scripts/scan_ascendc_migration.py" --target .

扫描器会统计 AddConfig("ascend310p")、opFile.value、SUPPORT_COMPUTE_UNIT、ASCEND_SOC_UNITS、DataCopyPad、__CCE_AICORE__、__NPU_ARCH__、tilingKey、runtime_kb、dtype 等模式，并输出审查提示。

阶段二：路线选择，先确认昇腾 310P 改造边界

Skill 不会默认把所有源代际能力都复制到昇腾 310P，而是先判断目标路径需要做到哪一步。

1. 如果算子逻辑简单，且 dtype、搬运和 tiling 在昇腾 310P 上没有差异，优先采用最小改造：补齐 Host 注册、构建清单和测试配置。
2. 如果源路径包含 BF16、量化或平台专用实现，则先确认昇腾 310P 是否真的支持对应能力；不支持的能力需要明确收窄，不能机械暴露。
3. 如果 kernel 中存在 DataCopyPad、非 32B 对齐写回或复杂尾块处理，则必须进入 kernel 差异审查，确认昇腾 310P 可达路径不会读写越界。

关键原则：不要为了让昇腾 310P 编译通过而删除或削弱昇腾 910 路径；没有昇腾 310P 编译、精度或功能验证结果时，也不要声称"迁移完成"。

阶段三：Host 与构建路由，先保证昇腾 310P 路径可达

Host 侧迁移采用"最小足够"原则。简单算子可以只新增 AddConfig("ascend310p")；当昇腾 310P 需要 target-specific flag、不同 kernel 或 dtype 收窄时，再构造独立的 OpAICoreConfig。

构建侧则需要同步检查 CMakeLists.txt、build.sh、SUPPORT_COMPUTE_UNIT、ASCEND_SOC_UNITS、SOC_ARRAY、test_soc_config.yaml、get_soc_version.py 以及 op_host/config/ascend310p 目录。Skill 会提醒开发者确认新增文件不会被错误排除，也不会误路由到不兼容的源代际目录。

阶段四：Kernel 差异处理，重点处理 DataCopy 与尾块风险

在 kernel 侧，昇腾 310P 迁移最容易被忽略的是搬运语义和尾块边界。Skill 会把这些差异前置成迁移决策，减少"照搬源代际代码"的风险。

DataCopyPad 检查：逐点检查 DataCopyPad 是否位于昇腾 310P 可达路径上。GM（Global Memory）到 UB（Unified Buffer）场景需要确认 padding tail 是否会被后续计算读取；UB 到 GM 场景不能简单向上取整写回，必须证明 GM 行尾 padding 可覆盖，或使用 tail-safe 写回方案。

32B 对齐与尾块写回：如果输出 shape、stride 或 block 划分导致尾块不足 32B，迁移时需要明确写回策略。能编译不代表安全，关键是确认不会覆盖相邻逻辑输出，也不会把 padding 数据带入后续计算。

dtype 能力收窄：如果源路径声明了昇腾 310P 暂未验证的 dtype，Skill 会建议先收窄能力边界，等 kernel、tiling 和精度验证补齐后再开放。

阶段五：验证与交付，让迁移结果可复用

跨代际迁移的最后一步，是把"改了什么、支持什么、没支持什么、验证到了哪里"写清楚。Skill 的完成标准要求输出简短迁移报告，包含改动文件、昇腾 310P 注册、支持 dtype、构建/测试命令与结果，以及残余风险。

• 报告 DataCopyPad 替换状态、尾块对齐风险、dtype 能力收窄情况。
• 记录昇腾 310P 构建命令、AclNN 测试命令、精度结果和失败项。
• 如果目标硬件、编译器或测试环境不可用，报告明确标记为"静态迁移"或"静态审查"，不把缺失验证包装成完成态。

一次迁移的推荐输入与输出

输入	输出
已有 Ascend C 算子工程，包含 op_host / op_kernel / 构建脚本 / 测试配置	昇腾 310P 迁移画像，包含 Host、kernel、构建、测试、dtype 和搬运风险
源代际与目标代际，例如昇腾 910 -> 昇腾 310P	昇腾 310P 迁移路线、修改建议、能力边界和验证清单
可选的编译器、NPU 环境、AclNN 测试或 msprof profiling 条件	构建/精度/功能验证结果，或明确的静态审查结论

总结

昇腾 910 到昇腾 310P 的 Ascend C 算子迁移，本质上是一项工程一致性工作：既要让昇腾 310P 路径可达，也要确保源代际能力不被破坏；既要处理 Host 和构建配置，也要审查 kernel 中真正会执行的搬运、计算和同步路径。

op-ascend-migration Skill 将这些经验沉淀成可执行的扫描器、分路线参考和报告标准，帮助开发者把迁移过程从"靠经验逐项翻代码"，推进到"先扫描、再选择路线、按检查结果修改、按验证交付"的标准流程。

待续：从昇腾 910 到昇腾 950，一套 Skill 继续打通扫描、迁移、验证与交付。

社区共建：欢迎开发者贡献 Skills，共同完善昇腾 AI 生态。

开源地址：https://gitcode.com/Ascend/agent-skills