Subagent 调用参数详情【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills本文档是 PerformanceOptimizationAgent 调用各阶段 Subagent 的唯一执行手册。每个 Step 包含调用参数、关联 Skill、完成验证、约束提醒。Step 1性能数据采集与分析Subagent 调用参数{ description: 性能数据采集与分析, subagent_type: ascendc-perf-analysis-expert, prompt: 请对以下待调优的 demo 代码进行性能数据采集与分析按 **运行 demo 采集数据 → 性能分析 → 输出调优方案** 三阶段顺序执行 - 源码目录{code_dir} - 测试用例文件{cases_csv}CSV 格式包含所有测试用例的 shape、dtype、attrs 等参数。**若 case 数量超过 20 个仅取前 20 个** - 输出目录{output_dir}性能数据、报告等所有产出物落盘到此目录下 --- ### 阶段一运行 demo 并采集性能数据 1. 编译运行 {code_dir} 中的 demo 代码确保可正常执行 2. **对 {cases_csv} 中全部用例**使用 /ops-profiling 逐个 case 采集上板性能数据msprof aiv_time - **禁止只选代表性用例**每个 case 都是用户关注的必须全部采集 - 所有测试用例均须在 NPU 上运行禁止 host 侧短路绕过 kernel 3. 从 profiling 数据中获取每个 case 的 aicore/aiv 耗时记录数据来源profiling供后续分析使用 【输出阶段一】 - **全部 case** 的性能数据采集产物profiling 目录存放到 {output_dir}/perf_per_case/ 下 - 每个 case 的 aiv_time 汇总表 - 采集失败时停止不进入阶段二 --- ### 阶段二性能分析 1. 加载 /ascendc-perf-optimize进行建模和流水分析形成多个性能调优方案 2. **逐 case 分析**对 {cases_csv} 中的**每一个 case** 进行性能瓶颈分析 - 给出该 case 的 bound 类型VEC/MEM/SCALAR BOUND和具体瓶颈指标 - 将瓶颈特征相同的 case 归并到同一组在组内统一说明 - **每个 case 必须在报告中出现**不允许遗漏或仅以同上替代 3. case 归并分组维度按优先级dtype → bound 类型 → shape 规模S/M/L→ 特殊值特征 【输出阶段二】 - 多个性能调优方案 - 全部 case 的瓶颈分析结果按组归并展示但每个 case 独立列出 - 分析失败时停止不进入阶段三 --- ### 阶段三输出《性能调优方案》 ⚠️ 以阶段二分析结论为输入**禁止**重做分析或建模。 1. **输出《性能调优方案》报告** - **最多 3 个性能调优方案**按预期效果从高到低排序 - 每个方案包含优化目标、调优后的 Tiling 参数、调优策略、参考的 skill 路径、**模板骨架**模板代码路径 关键结构摘要、**模板分支条件**该方案适用的 case 分支判定条件 - **逐 case 覆盖表**列出哪些 case 将被该方案优化以及每个 case 的预期改进方向和**所属模板分支** - 报告最后一节须包含case 覆盖清单以表格列出全部 case标注每个 case 归属的瓶颈组、适用方案、预期效果 - **方案融合规则** - 多个优化方向若涉及**不同模板且分支条件互斥**如 AR 路径 vs ARA 路径或 R ≤ 阈值 vs R 阈值**应融合为一个方案**一个 kernel 含多个模板分支而非拆成多个独立方案 - 若多个方向涉及**同一模板的同一分支**即对同一组 case 有不同优化策略则**选最优策略拆为多方案并列**由 Step 2 实测对比 - 融合方案的 case 覆盖表须标注每个 case 走哪个模板分支 【输出阶段三】 - 《性能调优方案》方案概览 具体措施 skill 路径引用 **逐 case 覆盖清单** - **报告必须落盘**到 {output_dir}/性能调优方案.md - 自由发挥处显式标注「知识库暂未收录」 --- 【验收标准】 - 三阶段按序完成不跳步、不倒序 - 《性能调优方案》可含多个可行方案显式标注覆盖维度 - 各阶段阈值与判据以当次打开的 skill 文件为准 - **全部 case 均已采集性能数据且在报告中出现** - 禁止修改算子源码 }Step 2方案实施Step 2 由PerformanceOptimizationAgent主 agent分两个阶段完成先并行分发方案实施再统一采集性能并生成报告。阶段 2a并行方案实施主 agent → 多个 impl subagent主 agent 读取《性能调优方案》对其中每个方案各启动一个ascendc-perf-impl-expertsubagent并行执行⚠️模板优先若《性能调优方案》中标注了✅可直接拷贝使用的模板 .h 文件prompt 中须将模板文件完整路径传递给 impl expert并明确要求直接拷贝使用禁止从头重写。impl expert 遇到 MicroAPI 编译报错时须先尝试命名空间别名等最小修复禁止直接降级。{ description: 实施方案方案名称, subagent_type: ascendc-perf-impl-expert, prompt: 请实施以下单个性能调优方案 - 算子源码目录{code_dir} - 方案描述从《性能调优方案》中提取该方案的完整内容含模板代码路径、关键骨架结构、模板分支条件、逐 case 模板映射 - 方案标识方案名称用于目录命名 - 测试用例文件{cases_csv}CSV 格式用于精度验证 - 输出目录{output_dir}优化代码等产出物放到此目录下 **模板优先指令** - 若方案中标注了模板 .h 文件路径且分类为✅可直接拷贝使用**必须直接拷贝这些 .h 文件到项目 op_kernel/ 目录**仅做最小适配命名空间别名、TilingData 字段补充、include 路径修正禁止从头重写 - 模板内的 MicroAPI VF 计算RegTensor、MaskReg、LoadAsFp32、StoreFromFp32 等必须原样保留禁止降级为高层 API - 遇到 MicroAPI / Reg API 编译报错时必须按以下顺序尝试修复 1. 命名空间别名如模板用 AscendC::MicroAPI::实际 CANN 为 AscendC::Reg::加 namespace MicroAPI Reg; 2. API 签名适配对照 CANN 实际头文件调整参数数量/类型 3. 头文件 include 路径修正 4. 仅当以上修复均无效时才降级对应分支并在返回结果中明确列出尝试过的修复手段和失败原因 【任务】 按 ascendc-perf-impl-expert.md 执行流程完成复制目录 → 实现代码 → 编译 → 精度验证。 目录命名{output_dir}/{算子名}_optimized_方案标识/从 {code_dir} 复制源码到此目录在此目录上修改 精度验证对 {cases_csv} 中**全部 case** 进行精度验证不遗漏 完成后返回优化代码目录路径、编译状态、精度验证结果逐 case PASS/FAIL 明细、**模板使用情况**哪些模板被直接拷贝使用、哪些被降级、降级原因及尝试过的修复手段。不采集性能、不生成报告。 }主 agent 等待所有 subagent 完成后进入阶段 2b。阶段 2b统一性能采集与报告主 agent 执行统一 msprof 采集对基线 所有优化方案目录按{cases_csv}逐个 case用 msprof 采集 aiv_time禁止只选代表性用例必须覆盖全部 case记录每个 case 在各个方案下的 aiv_time(us)精度确认确认所有方案对全部 case 精度均通过**生成《性能调优报告》**并落盘到{output_dir}/性能调优报告.md逐 case 内核时间对比表msprof aiv_time行 全部 case列 基线 各方案逐 case 分析对每个 case 明确写出当前存在的性能瓶颈是什么bound 类型 关键指标采用了什么优化手段引用具体方案加速比提升了多少基线 aiv_time / 优化后 aiv_time瓶颈特征相同的 case可以归并到同一组统一说明瓶颈和手段但每个 case 的加速比数据必须独立列出方案对照表和改进幅度最佳方案标注按全部 case 几何平均加速比明确标注本轮优化提升最明显的方案及其代码目录。该目录作为多轮优化下一轮的基线起点标注采集方式与数据路径【验收标准】所有方案编译通过、精度验证通过报告含每个 case的 msprof aiv_time 对比表和逐 case 分析瓶颈 → 手段 → 加速比所有 case 均在 NPU 上运行报告已落盘Step 3CANN-Bench 评测接入可选触发条件用户提供以下三项信息时主 agent 在 Step 2 完成后进入 Step 3参数必需说明cann_bench 代码路径是CANN-Bench 仓库根目录包含tasks/和评测脚本评测环境信息是目标 A5 芯片型号如 Ascend 950、CANN 版本、可用核数等接入 cannbench 的决策是用户明确要求接入 cannbench 评测或跑 A5 加速比阶段 3a确认 A5 基线数据详细方案见workflows/cannbench-a5-baseline-collection.md检查 cann_bench 代码路径下是否已有该算子的 A5 基线数据通常位于tasks/metadata/Ascend950DT_9582.json或scripts/baseline/output/若 A5 数据存在直接读取记录为基线参考值若 A5 数据不存在使用scripts/collect_baseline.py在 A5 真机采集见上述文档 §4产出合并写入tasks/metadata/Ascend950DT_9582.json记录基线baseline_perf_us/t_hw_us等核心指标阶段 3b原始基线 优化算子串行接入 CANN-Bench⚠️关键必须同时接入原始基线代码和优化后代码两套在同一 CANN-Bench 框架下评测才能剥离接入方式差异得出优化带来的净收益。⚠️ CANN-Bench 是单仓库不能并行操作。由一个 agent按顺序先接入基线代码、再接入优化代码。主 agent 启动一个agentascendc-perf-impl-expert或通用 agent执行以下任务{ description: CANN-Bench 基线优化串行接入, subagent_type: ascendc-perf-impl-expert, prompt: 请将原始基线算子和优化后算子**依次**接入 CANN-Bench 评测框架使用 direct_launch_example 方式。先完成基线接入再处理优化代码。 - 基线代码目录{code_dir}用户最初提供的待调优 demo 代码目录 - 优化代码目录{optimized_code_dir}Step 2 产出的最佳优化方案目录 - cann_bench 代码路径{cann_bench_dir} - 评测环境信息{env_info} - 测试用例文件{cases_csv} - 输出目录{output_dir}评测报告等产出物落盘到此目录下 【任务】 第一步接入原始基线代码 1. **理解 direct_launch_example 接入方式** - 参考 cann_bench 仓库中已有的 direct_launch_example如 tasks/level1/exp/ 下的接入代码 - direct_launch_example 的核心文件CMakeLists.txt含 add_executable、op_host/op.aschost 直调入口、op_kernel/op_kernel.asckernel 实现、scripts/run_all_cases.py批量测试脚本 2. **接入基线代码** a. 将基线代码目录复制一份作为 CANN-Bench 接入的工作副本不污染原始目录 b. 确保 CMakeLists.txt、run.sh、build.sh 等构建脚本正确配置--npu-archdav-3510 c. 将 {cases_csv} 中的测试用例转换为 cann_bench 的 cases.csv 格式 d. 编译并运行确认所有 case 可正常执行且精度通过 3. **评测基线** a. 运行 cann_bench 评测脚本跑分命令参考 workflows/cannbench-a5-baseline-collection.md §8.1对全部 case 采集 A5 性能数据 b. 记录基线代码的逐 case elapsed_us c. 将评测 JSON 报告保存到指定路径 第二步接入优化后代码 4. **接入优化代码** a. 以优化代码目录为基础确保 CMakeLists.txt、run.sh、build.sh 等构建脚本正确配置--npu-archdav-3510 b. 使用与第一步相同的 {cases_csv} 测试用例 c. 编译并运行确认所有 case 可正常执行且精度通过 5. **评测优化代码** a. 运行 cann_bench 评测脚本跑分命令参考 workflows/cannbench-a5-baseline-collection.md §8.1对全部 case 采集 A5 性能数据 b. 计算每个 case 的加速比A5 基线 / 优化后 elapsed_us 6. **输出结果** - 基线代码评测 JSON 报告路径含逐 case elapsed_us - 优化代码评测 JSON 报告路径含逐 case elapsed_us - 编译状态和精度验证结果两套各自 - 不生成最终报告 }主 agent 等待 agent 完成后进入阶段 3c。阶段 3c生成 CANN-Bench 评测报告主 agent 在两个 agent 均完成后统一生成报告采集 A5 性能数据从 Agent 1基线的评测 JSON 报告中提取基线代码的逐 case elapsed_us从 Agent 2优化的评测 JSON 报告中提取优化代码的逐 case elapsed_us**生成《CANN-Bench 评测报告》**并落盘逐 case A5 加速比表每行一个 case列至少包含A5 官方基线 baseline_perf_us来自 metadata原始基线代码 CANN-Bench elapsed_us原始基线 vs A5 官方加速比 baseline_perf_us / 原始基线 elapsed_us优化后代码 CANN-Bench elapsed_us优化后 vs A5 官方加速比 baseline_perf_us / 优化后 elapsed_us优化后 vs 原始基线加速比 原始基线 elapsed_us / 优化后 elapsed_us净优化收益SOL% perf_score评分汇总按评分公式计算各 case 得分及总分参考workflows/cannbench-a5-baseline-collection.md§8.2-§8.3方案对照与 Step 2 的优化方案关联说明优化效果在大规模基准上的验证情况优化净收益分析对比原始基线→A5官方和优化后→A5官方两列加速比分析优化在 CANN-Bench 框架下的真实提升幅度标注所有数据来源A5 基线数据路径 / 原始基线 profiling 路径 / 优化后 profiling 路径【验收标准】A5 基线数据已确认已存在或新采集原始基线代码和优化后代码均已接入 cann_bench 并编译通过全部 case 精度验证通过两套代码各自通过报告含每个 case 的三列加速比原始基线 vs A5 / 优化后 vs A5 / 优化后 vs 原始基线报告已落盘到{output_dir}/CANN-Bench评测报告.md报告格式通用规范所有报告必须包含以下字段供 PerformanceOptimizationAgent 解析判断**状态**: ✅完成 / ❌失败 / ⏭️跳过 **阶段**: 性能数据采集与分析 / 方案实施 / CANN-Bench 评测接入 **摘要**: 一句话描述本阶段结论 **详细内容**: 各阶段特定内容逐 case 覆盖格式适用于各阶段报告报告中涉及 case 列表时必须使用以下格式确保全部 case 覆盖无遗漏| Case | Shape | dtype | 瓶颈类型 | 适用方案 | 基线 aiv(us) | 优化后 aiv(us) | 加速比 | 备注 | |------|-------|-------|---------|---------|-------------|---------------|--------|------| | 1 | xxx | fp16 | VEC BOUND | 方案A | 14.1 | 6.0 | 2.35x | LUT 优化 | | 2 | xxx | fp32 | VEC BOUND | 方案B | 37.6 | 26.7 | 1.41x | Taylor8 | | ... | ... | ... | ... | ... | ... | ... | ... | ... |【免费下载链接】cannbot-skillsCANNBot 是面向 CANN 开发的用于提升开发效率的系列智能体本仓库为其提供可复用的 Skills 模块。项目地址: https://gitcode.com/cann/cannbot-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考