Menu
生成面向华为 Ascend（昇腾）设备的 NPU 迁移流程，包括环境与版本校验、模型导出/编译生成 OM、INT8 校准与量化、部署验证以及精度/性能对比。Use when the user mentions NPU迁移、昇腾、Ascend、ATC、OM、MindIR、StreamManager，或谈到模型编译/量化、精度回归与延迟吞吐评估。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Ascend C Kernel Code Optimization Skill. 使用本地RAG知识库检索优化经验，对算子kernel代码进行迭代优化。 核心流程: 识别bottleneck -> 检索RAG -> 生成修改 -> 评估 -> 迭代 Trigger examples: "optimize kernel", "优化 kernel 代码".
Detect and fetch the latest “Ascend C算子开发” PDF from the Huawei Ascend CANN Community Edition documentation, download page for a user-specified version, then convert the PDF into chapter-level markdown files and save them under ascend_dev_guide_sections/.
Generate, verify, and continuously improve AscendC custom kernels for user-specified operators using multi-kernel-bench.
| name | npu-migration-ascend |
| description | 生成面向华为 Ascend（昇腾）设备的 NPU 迁移流程，包括环境与版本校验、模型导出/编译生成 OM、INT8 校准与量化、部署验证以及精度/性能对比。Use when the user mentions NPU迁移、昇腾、Ascend、ATC、OM、MindIR、StreamManager，或谈到模型编译/量化、精度回归与延迟吞吐评估。 |
| argument-hint | [model-format] [soc-or-chip] [FP16|INT8] |
Mig_report.md（迁移变更与产物）、Mig_Readme.md（迁移后训练/推理）、Compare.md（性能与精度对比）。详见 mig_docs/README.md。当用户要把“现有模型/推理链路迁移到 NPU（昇腾/Ascend）”时，生成一个端到端迁移方案：环境校验 -> 导出/编译生成 OM ->（可选）INT8 校准与量化 -> 部署运行与基准评测 -> 精度/性能回归报告。并在关键节点给出命令模板（由 agent 按用户环境补齐参数）。
当用户通过参数调用本 skill（例如 /npu-migration-ascend ...）时：
$ARGUMENTS[0]=模型格式（MindSpore/ONNX/其他）、$ARGUMENTS[1]=目标芯片/型号（如 310P/910 等）、$ARGUMENTS[2]=目标精度（FP16/INT8）请优先向用户确认以下要点（没有就让 agent 采用合理默认，并在最后列出“仍需确认项”）：
npu-smi 与 atc --version 输出）requirements.txt、environment.yml、setup.sh、Dockerfile 等；基线推理入口脚本/命令；Python 版本与关键库版本（与基线一致）安全与合规：提醒用户不要在对话中粘贴密钥、内网地址、未脱敏的客户数据；校准集与日志分享前做脱敏。
如果用户希望你“立刻给可走的流程”，至少请补齐/确认这 3 项，然后直接进入“编译生成 OM”分支：
让 agent 输出一段“成功标准”并要求基线对齐：
目标：在真正 atc/生成 OM 之前，尽可能把“会编不过/编得过但跑不对/精度和性能大幅异常”的根因先分类并给出最小验证路径。
预判输出应包含 4 部分内容：编译链路、输入输出契约、算子/后处理风险、最小验证计划。
让 agent 明确并写出“本次编译走哪条链路”，例如：
atc 编译生成 OM同时让 agent 对“编译时必须一致”的信息做核对并列清单：
在不具备完整离线工具链评估的前提下，agent 需要基于模型结构做“高概率风险点”分类，并给出建议的验证方式：
让 agent 给出一个分阶段计划，避免一次编译就把问题扩大化：
Phase 计划要写明：
当精度目标是 INT8 时，agent 除了以上内容，还应额外输出：
N>=100，并说明按模型复杂度调整）让 agent 按下面顺序做环境检查，并把命令与关键结果回填到最终输出里：
npu-smi 或等价命令检查设备atc 存在且版本正确环境信息快照（建议写入迁移报告，便于复现与排障）：
| 项 | 值 |
|---|---|
| 机器/板卡型号 | |
npu-smi 关键信息（驱动/设备） | |
CANN / atc --version | |
| 推理运行时版本（若与编译分离） | |
目标 soc_version 与依据 |
根据用户提供的模型格式选择路径，agent 必须先做“分支选择”再给命令：
atc 编译生成 OM编译时在输出里强制包含：
atc/环境推断）编译前模型检查（ONNX 尤其建议）：
onnx 等工具核对 graph 输入输出名、维度、dtype；多输出时列出每个输出用途（便于后处理对齐）soc_version 填写原则：必须与目标硬件及当前 CANN 文档一致；不确定时让 agent 要求用户提供板卡型号 + 官方对照表或历史成功编译命令中的取值，避免猜测。
编译后最小验证（在投入大规模评测前）：
atc 命令行、生成日志路径、OM 文件路径写入迁移记录，便于回滚与对比产物与命名建议（便于多轮迭代）：
模型名、soc_version、precision、shape 策略、日期/迭代号atc 完整命令与日志让 agent 针对 INT8 给出可执行的校准流程与检查清单：
N>=100 起步，并提醒按模型复杂度与官方建议调整）目标：在同一输入分布、同一 batch/并发设置、同一测量口径下，给出可与基线对比的延迟与吞吐数据；并在性能不达标时能快速定位瓶颈属于预处理/后处理/IO/推理内核哪一段。
让 agent 在这一节必须输出 5 部分内容：测量范围、实验设置、指标口径、基准复现、性能报告模板。
让 agent 选择并写清楚性能测量口径，至少包含下列一种或多种（推荐“分段”）：
要求：性能报告中要明确“本结果包含/不包含哪些环节”，避免口径不一致导致误判。
让 agent 给出并坚持以下实验设置，并将其写入输出（便于复现）：
让 agent 使用以下指标集合并在报告里逐项填充（没有也要给出计算方法/公式）：
让 agent 给出“可复现输入与数据一致性”要求：
要求 agent 在最终输出中给出类似下面的结构（可用 Markdown 表格呈现）：
延迟 p50/p95、吞吐、batch size、测量口径（端到端/纯推理/分段）同时要求：强制保存编译/运行日志与 profiling 结果（如果可用），用于回归定位。
要求 agent 给出一份对比报告框架（即使没有最终数值，也要给出结构与需要的字段）：
数值一致性（在跑全量指标前强烈建议）：
精度、延迟、吞吐对比（见第 7～8 节与 mig_docs/Compare.md）主要是在数据集或基准集上算业务指标，回答「效果与速度够不够」。
模型本身的训练/推理测试侧重「实现与图是否健康、能否稳定跑通」，通常在更小粒度上做，与上者互补，不是替代关系：
| 类型 | 典型内容 | 回答的问题 |
|---|---|---|
| 推理侧（模型级） | 固定输入的 smoke：shape/dtype、无 NaN/Inf、输出范围合理；Golden 与基线逐元素或统计量对比；多输出头是否接对 | 推理链路、预处理、导出/编译是否与预期一致 |
| 训练侧（模型级，若迁移后仍训练） | 单 batch 或极少 step：前向+反向+优化器一步是否跑通；loss 是否为有限值；梯度是否异常（全零/爆炸）；checkpoint 保存再加载是否一致 | 训练脚本与 NPU 适配层是否可用，而非「收敛好不好」 |
| 自动化（可选） | pytest/CI 中的小型用例：CPU 参考 vs NPU 同输入输出一致性（允许量化误差阈值） | 回归时快速发现破坏性变更 |
让 agent 根据项目是否「仅推理」或「仍训练」给出建议，并在 Mig_report.md 的验证摘要中勾选是否已做：推理 smoke、Golden、训练 smoke（若适用）；全量精度/性能仍以 Compare.md 为准。
要求 agent 给出回滚与迭代建议：
说明：昇腾/ATC/编译器参数会随 CANN 版本与工具链变化。agent 在给出最终命令前，应先让用户确认
CANN/atc版本（或从atc --version推断），并只在确定的参数上写死，其余用占位符。
# 设备是否可见（以系统命令为准；不同安装包可能有等价命令）
npu-smi info
# 验证 atc 存在与版本
atc --version
atc --model="<path/to/model.onnx>" \
--framework=<ONNX_framework_id> \
--output="<path/to/output_dir>" \
--input_format=<NCHW_or_NHWC> \
--input_shape="<input_name>:<shape>" \
--soc_version="<target_soc>" \
--precision=<FP16_or_INT8>
若启用 INT8 量化/校准，agent 需要补上与你的 CANN 版本匹配的 calib/quant 参数，并明确“这些参数来自哪里”（例如配置文件路径、量化策略文件）。
atc --model="<path/to/model.mindir>" \
--framework=<MINDIR_framework_id> \
--output="<path/to/output_dir>" \
--soc_version="<target_soc>" \
--precision=<FP16_or_INT8>
# 具体工具/入口取决于你使用的推理框架（StreamManager / 推理样例 / 自研）
# agent 应根据当前工程选择“可复现”的基准命令与日志路径。
benchmark_app --model="<path/to/model.om>" --input="<path/to/input>" --batch_size=<N>
Task Progress:
npu-smi、atc --version、运行时依赖mig_docs/ 三份文档（见下方「规范输出」）迁移类任务结束时，agent 应指导或直接在用户仓库中维护一套 mig_docs/，与 skill 内模板结构一致（可从本 skill 目录 复制 mig_docs/ 到项目根目录或 docs/mig_docs/）。
| 文件 | 必填内容要点 |
|---|---|
mig_docs/Mig_report.md | 元信息、成功标准、环境快照、模型/OM 路径、完整 atc 命令、代码/配置/依赖变更清单、算子与后处理变更、验证勾选、风险与回滚、日志路径 |
mig_docs/Mig_Readme.md | 环境准备（依赖、CANN env、设备检查）、数据与预处理（与 IO 契约一致）、推理命令与参数表；若存在 NPU 训练则写训练入口与与迁移前差异，否则明确「仅推理」 |
mig_docs/Compare.md | 基线 vs 昇腾环境表、测量口径（延迟定义、warmup、iter、p50/p95、吞吐定义）、精度对比表、Golden 样本摘要、性能对比表、瓶颈与原始日志路径 |
命名约定：迁移报告文件名为 Mig_report.md（英文 report，避免拼写为 reprot）。
对话中的输出规范（除写文件外，回复正文应包含）：
mig_docs/Mig_report.md）。Mig_report 中的主要变更行数或关键文件列表；Compare 中的达标结论一行话。mig_docs/。最终回复建议包含：
mig_docs/ 交付状态：三份文档路径 + 是否已按模板填关键段（环境快照、ATC 命令、变更清单、对比口径）Example 1
Input: “我有一个 MindSpore 目标检测模型，要部署到昇腾 310P。想做 INT8，加速同时尽量不降精度。”
Output: 收集数据与版本（对齐输入预处理）-> MindIR 导出 -> INT8 校准/量化 -> atc 编译生成 OM -> 部署运行与基准评测 -> 精度/延迟回归报告（含错误定位路径）-> 在项目根目录维护 mig_docs/Mig_report.md、Mig_Readme.md、Compare.md。
Example 2
Input: “我只有 ONNX 模型，迁移到 Ascend 跑推理，并希望给出通用 ATC 编译命令。”
Output: 要求确认 atc --version、soc_version、输入输出 tensor 名称与 shape -> 给出 ONNX->OM 编译命令模板（按 CANN 补齐参数）-> 部署与基准命令模板 -> 给出“编译失败/运行失败/精度回退”排查路径 -> 将完整命令与对比结果写入 mig_docs/ 三份模板。
让 agent 在用户求助或内部复盘时，按清单索取或整理（脱敏后）：
atc 命令行（含所有参数）与 编译日志（或失败时的首尾错误段）atc --version、npu-smi 输出、目标 soc_version 与硬件型号常见编译失败归类（便于快速定性）：
input_shape / 多输入顺序错误