القائمة
生成面向华为 Ascend（昇腾）设备的 NPU 迁移流程，包括环境与版本校验、模型导出/编译生成 OM、INT8 校准与量化、部署验证以及精度/性能对比。Use when the user mentions NPU迁移、昇腾、Ascend、ATC、OM、MindIR、StreamManager，或谈到模型编译/量化、精度回归与延迟吞吐评估。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 / 多输入顺序错误