model-infer-sota-approach：CANN 模型推理极致性能优化的 Agent 编排技能设计解析

model-infer-sota-approachCANN 模型推理极致性能优化的 Agent 编排技能设计解析【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer导读本文是 CANN 推理优化样例仓库 cann-recipes-infer 中model-infer-sota-approach模型推理极致性能优化技能的设计文档解析。该技能面向已经跑通框架适配与精度 baseline 的模型以 profiling 数据为唯一驱动力通过「多方向并行发现潜在优化项 → Plan 自循环验证收敛」的编排方式在 baseline 之上继续挖掘多流、prefetch、融合算子、图模式、KVCache、量化、并行等单点优化的组合空间。读完本文你将掌握这套 Agent 技能的整体编排架构、Plan 状态机与派生机制、分层状态文件的读写契约以及 profiling 驱动下的证据口径与最终验收标准并能结合仓库源码理解其与基础优化工作流model-infer-optimize的边界关系。1. 技能定位在 baseline 之上的探索式深度优化model-infer-sota-approach是一个编排型 Skill它的起点不是从零适配而是一条语义正确、精度可复现的推理路径。它只负责整条编排——从推理场景建立、精度基线、profiling 采集与分析到潜在优化项发现、Plan 实施、review、派生和最终验收具体的代码改造则交由各单点技术 skill 完成本技能不介入。1.1 核心特征不预设固定阶段与 docs/agent/model-infer-optimize-design.md 中描述的基础优化工作流不同——后者采用 migrator → 并行 → KVCache → 融合 → 量化 → 图模式 → 总结的固定阶段流水线——model-infer-sota-approach刻意不预设固定阶段优化方向并非预先排定的流水线而是由 profiling 分析识别得出再用统一的 Plan 状态机逐个验证、收敛。这种设计的依据在于基础适配阶段的优化路径是确定的可按固定阶段顺序执行完毕但 baseline 之上的深度优化某个方向是否有收益、收益多大、方向之间是否冲突均需依赖 profiling 才能判定。预设的阶段流水线在此反而会限制探索——它预先假定了方向与顺序而真实瓶颈往往落在标准路径之外。1.2 适用场景与前置条件适用场景包括已有可运行 baseline需在其上继续进行 profiling 驱动的深度优化优化方向不止一个、且彼此可能互斥或叠加需要统一编排、并行试验、逐个验收涉及融合算子、prefetch、图模式、多流、KVCache、量化、并行等多种优化项的统一调测编排。前置条件非常明确模型必须已完成框架适配并已有一个可运行、可复现精度的 baseline。如果模型尚未适配进框架、或尚无 baseline应先完成框架适配与基线建立对应基础优化工作流的阶段 0再进入本技能。仓库 AGENTS.md 的行为约束中也同样规定单独使用 model-infer 系列 skill 时若模型尚未完成框架适配或基线采集应建议用户先通过model-infer-optimize完成阶段 0。1.3 设计目标多方向并行发现在不确定的多个优化方向上并行发现潜在优化项降低遗漏优化点的风险探索可收敛用 Plan 自循环将试验一个方向 → 验证 → 保留或淘汰 → 派生新方向结构化使探索式优化可收敛、可追溯证据驱动裁决一切性能判断以 profiling 分析报告为准不以裸计时直接得出结论状态可接力通过分层状态文件支持跨 agent、跨 round、跨上下文压缩的状态接力。1.4 职责边界边界说明只编排不替工主 agent 负责阶段推进、全部用户交互、prompt 组装、Dashboard 维护、最终验收不直接执行采集 / 分析 / 实施不嵌套编排编排职责由本技能独占不调用其他编排流程具体优化交给它调用的单点技术 skill实施 skill 按 Plan 内容定用哪个单点 skill多流 / prefetch / 融合 / 图模式 / 量化 / 并行等由主 agent 在 Plan 实施阶段按 Plan 内容判定作为 implementer 的领域 skill 传下去将编排与实施彻底分离是为了让本技能能复用所有现有及未来的单点优化 skill而无需关心其内部实现同时禁止编排流程互相嵌套避免上下文与职责的混乱叠加。仓库中这些单点 skill 对应的原理文档即 docs/cann/zh/multi_stream_principles.md多流、docs/cann/zh/prefetch_principles.md权重预取、docs/cann/zh/npu_graph_optimization.md图模式、docs/cann/zh/super_kernel.mdSuperKernel等它们构成编排层所调度的实施能力池。2. 整体编排架构2.1 编排流程总览主 agent 按 8 个步骤推进前 6 步是线性准备第 7 步是 Plan 自循环第 8 步是最终验收。可以看到固定的是编排骨架可变的是具体执行哪些 Plan、迭代多少轮由证据决定。线性准备的 1–6 步为探索建立地基场景、基线、profiling、分析、潜在优化项第 7 步才进入真正的探索循环。2.2 主 agent 独占编排 subagent 执行主 agent 是唯一的编排者与交互方所有具体执行——采集、分析、潜在优化项发现、实施、复核——均派给 subagent。这样做有两个目的隔离上下文采集与分析的输出冗长实施与复核涉及大量代码细节将它们留在各自 subagent 的上下文中主 agent 只接收结论摘要与产物路径避免主上下文被无关信息占满角色隔离分析、实施、复核分属不同 subagent职责边界清晰如 reviewer 禁止改代码降低单个 agent 同时承担多角色导致的越界与漏检。2.3 性能分析栈边界profiling 的采集与分析交给两个独立 skill本流程只调用、不重复它们的内部契约skill职责在本流程中的角色model-infer-profiling采集 profiling 数据kernel_details.csv等由 profiling-instrumenter subagent 调用model-infer-perf-breakdown分析 profiling一份报告同时给出「时间分布」和「逐算子实测/理论 gap」两类证据本流程唯一性能分析入口由 profile-analyzer subagent 调用采集方式、拆解粒度、理论值计算等均属各 skill 的内部实现本流程不予感知。本技能只规定一条对外契约所有性能收益判断均以model-infer-perf-breakdown产出的分析报告为准详见第 7 节。在仓库实际代码中profiling 采集能力的基础设施已经就位executor/utils/profiler_context.py 提供create_profiler与ProfilerManager基于torch_npu.profiler实现按ProfilerPhasemm_encode/prefill/decode分段管理 profile 生命周期并通过enable_profiler开关控制默认关闭时为 no-op 的FakeContextManager。配置入口对应 docs/common/inference_config_guide.md 中ModelConfig.enable_profiler是否启用性能分析器默认 False开启后产物输出到output_path/prof/目录。这正是一个可被 profiling-instrumenter subagent 重复开关、可回退的采集机制。3. Subagent 角色设计3.1 角色清单与职责本技能编排六类 subagent全部由主 agent 派发subagent职责主要产物写权限scenario构造可复现推理输入、跑通精度基线、定判定口径scenario.md、输入样本 / 构造脚本progress.md 工作区profiling-instrumenter为已跑通场景插入 / 启用 profiling 采集可重复、可关闭、可回退采集命令、profiling 产物目录progress.md 工作区profile-analyzer用 perf-breakdown 分析本轮 profiling产出「时间分布」「实测/理论 gap」两类证据性能分析报告progress.md 工作区candidate从某一个来源第 4 节表一行发现潜在优化项产出 Plan 草案analysis/source.mdprogress.md 工作区implementer用 Plan 指定的单点 skill 实施单个 Plan代码改动、plan-id.md实施记录代码 progress.md plan 文件reviewer复核验收 implementer 的工作判通过 / 淘汰 / 保持plan-id.mdReview 记录progress.md plan 文件禁改代码所有 subagent 均为非交互它们不与用户对话所需的交互信息由主 agent 在派发前确认、随 prompt 传入。每次派发前主 agent 从references/subagent-prompt-templates.md取对应模板、替换占位符。3.2 主 agent 作为唯一交互方交互前置subagent 无法与用户对话而某些步骤又必须由用户确认如优化场景的锁定、perf-breakdown 的拆解口径。本技能的处理方式是交互前置——将全部用户交互收敛到主 agent在派发 subagent 之前先行确认再将结果作为 spec 随 prompt 下传场景确认第 1 步由主 agent 直接完成先从仓库勘察备选场景、检查前置条件再带着备选项以结构化提问与用户确认perf-breakdown 拆解 spec第 4 步由主 agent 先读model-infer-perf-breakdown了解其所需字段拆解模块偏好、structure / cluster spec 等与用户确认后作为分析 spec 传给 profile-analyzersubagent 据此非交互地执行分析——包括第一次 baseline。baseline 确认的 spec 在后续重采轮复用无需再次确认。如此既保证 subagent 全程非交互、输出可控又不遗漏必要的用户决策。3.3 派发规范主 agent 的 dispatch prompt 遵循以下规范对所有 subagent 一致生效配置继承主 agent每个 subagent 的 model、thinking、上下文强度均与主 agent 一致不降级、不缩短推理、不更换配置只回摘要与路径subagent 将详细产物落盘回传给主 agent 的仅有结论摘要、证据文件路径与需主 agent 决策的问题不将长日志 / 完整 profile / 原始表回传至主上下文dispatch 不转述上下文dispatch 仅给出模板字段与路径subagent 进场先读主 agent 传入的progress.md获取共享上下文场景 / 精度口径 / baseline 瓶颈 / 已通过 Plan / 当前 round 目标主 agent 不在 prompt 中复述这些Dashboard 只读Plan Dashboard 由主 agent 独占维护subagent 可读取以了解全局但不直接写入自身产出通过回传摘要交主 agent 落库性能口径统一凡涉及性能收益的结论一律以 profile-analyzer 报告为准不以裸 wall-clock 数字作为判定依据。设计考虑dispatch 不转述上下文、subagent 统一从progress.md获取上下文是为了让 prompt 保持简洁、避免 prompt 覆盖 skill 内的流程定义同时使共享上下文具有单一来源progress.md不在 prompt 与文件之间产生分叉。这与基础优化工作流 docs/agent/model-infer-optimize-design.md §3.3 的派发规范一脉相承。3.4 协作信息流以第 7 步 Plan 循环的一个 round 为例主 agent 与各 subagent 的协作时序如下准备阶段第 1–6 步的信息流与此类似主 agent 顺序派发 scenario → profiling-instrumenter → profile-analyzer再为来源表每个来源并行派发 candidate最后由主 agent 归并并初始化 Dashboard。4. 潜在优化项发现机制4.1 多来源并行发现潜在优化项发现是本技能探索的入口。主 agent 不预设优化方向而是为每个来源并行派发一个 candidate subagent让不同来源从各自角度发现潜在优化项再统一归并。每个 candidate 只负责一个来源、只写入自身的产物文件、互不干扰因此可并行执行。4.2 来源注册表与可扩展性潜在优化项的来源在 SKILL.md 的来源表注册当前注册三个来源来源source方法产物文件multi-stream用model-infer-multi-stream做整网 / 模块 / 算子 DAG 拆解、判定并行性每个并行点给出 ≥2 种多流编排方案analysis/multi-stream.mdwiki查 CANN-Infer-Wiki检索该模型 / 场景适用的优化手段不限多流analysis/wiki.mdperf-insight读 baseline perf-breakdown 的 insight 产物整理优化项连续 vector 区间 → 融合、冗余搬运 → prefetch、理论偏离 Top → 重点算子analysis/perf-insight.md其中multi-stream来源的判定依据可对照 docs/cann/zh/multi_stream_principles.md多流并行的成立条件在于多个算子的输入都依赖于同一个前驱算子的输出、彼此之间没有数据依赖——前置算子输出同时被 B、C 两条分支消费B、C 之间无数据依赖即可分别承载于两条 Stream 并行执行而perf-insight中冗余搬运 → prefetch的映射则对应 docs/cann/zh/prefetch_principles.md 中描述的判断条件profiling 确认目标算子是 memory-bound、目标权重足够大、目标算子前存在安全的依赖窗口。设计考虑来源采用注册式、可扩展的设计——新增一个来源即在来源表增加一行candidate 的 prompt 模板保持不变。若某个来源当前未挂载关联的工具 / skill如 wiki 的 MCP 未挂载主 agent 跳过该行。这使潜在优化项发现的覆盖宽度可随能力增长而扩展无需改动编排骨架。4.3 来源内判互斥、跨来源归并每个 candidate 只负责一个方向因此来源内的互斥 / 叠加关系由该 candidate 自行判定并写入产物文件跨来源的互斥 / 叠加关系单个 candidate 无法看到全貌例如融合算子改写 attention与多流切分 attention分属两个来源却作用于同一段计算必须由主 agent 在初始化 Dashboard 时统一归并、裁定。主 agent 在第 6 步归并时还会合并重复或等价的优化项例如多个来源均指向 MoE 多流 overlap归并为同一个 Plan编排变体作为该 Plan 的内部强度阶梯。4.4 先发现、后初始化 Dashboard若在潜在优化项缺乏证据支撑时即初始化 Dashboard后续裁决将无从依据。因此本技能强制先完成潜在优化项发现、再初始化 Dashboard——下列信息齐备后方可初始化推理场景及精度 / 功能口径已记录在案场景已跑通即便被阻塞也已查清原因且用户仍要求继续baseline 的 profiling 采集方式已建立或已有可直接复用的数据baseline profiling 已分析完毕产出了可回查的报告至少有一个 candidate 返回了潜在优化项或所有来源均已明确判定无优化项。用户若直接提供一份优化列表仅作为种子分配给对应来源的 candidate仍须经规范化后再进入 Dashboard增删合并须说明原因。5. Plan 自循环机制Plan 自循环是本技能的核心潜在优化项发现给出一批待验证的优化方向Plan 循环负责将它们逐个实施、验证、保留或淘汰并在过程中派生新方向直至收敛。5.1 Plan 状态机全程只允许三种状态状态含义待实现尚未实施或证据不足但仍有继续实施、调测的价值通过有明确收益或必要价值且功能、精度、回退路径和副作用都已检查通过淘汰无收益、风险过高、实现失败、破坏功能或精度或被同一互斥组里更优的 Plan 替代设计考虑状态刻意只设三种避免部分完成疑似有效之类的模糊中间态——任一 Plan 在任意时刻都明确处于待办 / 保留 / 丢弃之一使 Dashboard 成为可快速通览全局的状态真相源。证据不足但仍有价值的情形归入待实现可继续调测而非新增状态。5.2 全局递增 round每一个 Plan、每一档强度、每一次尝试都用独立的全局递增roundN记录派生出的 Plan 也分配新的roundN既不复用旧编号、也不与旧 round 合并。设计考虑round 是全局单调递增的时间轴而非每个 Plan 各自的局部计数。这样任意一次尝试包括同一 Plan 的不同强度、不同锚点都有唯一编号profiling 产物、Dashboard 裁决、plan 文件记录可借 roundN 一一对应避免编号复用导致的证据错配。5.3 实施 → review → 派生循环从待实现Plan 中选一个分配roundN进入循环选定 Plan / 分配 roundN → 主 agent 按 Plan 内容判断实施用哪个单点 skill → 主 agent 判断本轮是否需要重采 profiling见 §7.2 → implementer subagent 用选定的 skill 实施当前 Plan →需要时派发 profiling-instrumenter profile-analyzer 产出 round{N} profile → reviewer subagent 复核并验收 implementer 的工作 → 主 agent 按 decision-rules 更新状态、处理派生建议 → 仍有待实现或新派生的 Plan则继续下一 round实施 skill 由主 agent 按 Plan 内容定作为 implementer 的领域 skill 传下去reviewer 用同一个 skill 复核。implementer只实施当前一个 Plan不一并修改其他 Plan发现更合理方案时可建议派生但不得覆盖当前 Plan。reviewer 负责复核验收可以建议派生但不改代码、不自行修复、不回退代码。5.4 派生机制探索过程中常出现这样的情形——当前 Plan 并不完全成立却指向了一条更优的实现路径。派生机制将这种发现结构化为追加而非改写——旧 Plan 原样保留连同其证据与裁决新 Plan 另起plan_id与roundN、初始状态待实现。如此优化路径的演化全程可追溯不会因迭代出新版本而覆盖上一版的证据。implementer、reviewer 和主 agent 都可以提议派生最终由主 agent 写入 Dashboard。常见触发当前 Plan 核心假设被推翻但证据指向另一条可行路径同一优化点还有未试过的编排 / 算子 / 参数变体原方案落地成本过高但存在更小切口reviewer 确认有收益但还有更优变体Plan 被淘汰的原因是这条实现路径不合适而非优化点无价值多个已通过 Plan 组合后退化需专门治理组合。派生记录要写清派生自哪个 Plan / round、来源是 implementer / reviewer 还是 main、触发现象、新旧 Plan 的差异。5.5 互斥与叠加裁定潜在优化项来自不同来源机制上可能互斥、也可能正交可叠加必须由主 agent 统一裁定互斥组同一互斥组最终只保留一个、或一组明确兼容的通过Plan新 Plan 替代旧 Plan 时把旧 Plan 改为淘汰原因写明被 Plan-X 替代可叠加可叠加的 Plan 可以同时通过但不得默认收益可线性叠加——必须在最终验收中实测叠加后的代码路径与指标两个单独通过的 Plan 组合后若退化追加一个组合验证 round必要时淘汰组合收益更差的一方。跨方向的冲突要在初始化 Dashboard 时就识别§4.3单个 candidate 无法看到全貌。5.6 状态裁决规则每轮 implementer / reviewer 返回后主 agent 按以下规则裁决完整判据见references/decision-rules.md判通过reviewer 建议通过或主 agent 掌握更强证据该 Plan 代码路径在确认场景里真正执行到功能精度满足口径目标指标达到保留标准性能目标可选时也要说清保留价值enable 开关 / 回退路径清楚可用不破坏已通过 Plan互斥组内当前没有更优的已通过 Plan。判淘汰reviewer 明确判失败非缺一次可补的验证功能 / 精度 / 稳定性 / 编译出问题无收益或收益低于噪声且无继续空间引入明显副作用拖累其他模块、内存暴涨、多出 shape/layout 转换、图模式退化与已通过 Plan 冲突且本身更弱互斥组内已有更优 Plan。淘汰后必须记录三件事淘汰证据、代码是否已回退或 enable 是否已关闭、是否由此派生新 Plan。保持待实现或追加 round实现未完成但卡点可修复reviewer 只指出证据不足需补验证方向成立只是强度 / 参数 / 局部实现还要调本轮暴露新问题但不足以证明 Plan 无效。6. 分层状态管理设计本技能横跨多个 subagent、多个 round并可能跨多次上下文压缩状态管理必须明确回答三个问题谁读、谁写、何种信息存于何处。为此将状态分为三类文件各司其职、互不复制。6.1 三类文件分工文件管什么写者读者plan-dashboard.mdDashboard 总览状态指示Plan 状态机、当前采纳实现、round 裁决——Plan 状态的单一真相源只有主 agent主 agent 裁决subagent 只读了解全局progress.md共享状态文件跨 agent 共享上下文 subagent 实施 / 踩坑 / 验证过程各 subagent 追加工作区主 agent 维护常驻区所有 subagent 进场先读plans/plan-id.mdPlan 明细单个 Plan 的方案 spec round 级结论摘要该 Plan 的 candidate / implementer / reviewer主 agent 读它做裁决三者互不复制看状态查 Dashboard看过程与共享上下文查 progress.md看单个 Plan 的方案查对应的 plan 文件。设计考虑将状态过程方案分到三类文件是为了让每类信息有唯一归属避免同一信息在多处副本之间产生分叉。Dashboard 只存放高频读写的状态与裁决保持精简、便于快速通览冗长的过程记录归入 progress.md每个 Plan 的领域细节保存在各自的 plan 文件中主 agent 不解析其内部结构。6.2 落盘布局一次优化的所有产物固定落到约定路径optimization-analysis/case/optimization-analysis/case/ ├── plan-dashboard.md 编排总览脊柱只放关键信息 状态 裁决主 agent 唯一写 ├── scenario.md 场景记录scenario subagent 产出 ├── analysis/ 各来源的分析产物一来源一文件文件名取来源表来源名 │ ├── source.md │ └── … ├── plans/ 每个 Plan 一份完整记录方案描述 / 细节 / 实施 / review / 派生 │ ├── plan-A.md │ └── … └── perf/ perf-breakdown 工作目录采集 分析的 profile 与报告内部结构归 model-infer-perf-breakdown本流程不感知progress.md共享状态文件不在本 case 树内——其位置由主 agent 解析不存在时则创建沿用model-infer-optimize的常驻区 / 工作区 / 归档progress_history.md约定。它是项目级的跨 agent 共享上下文与过程日志编排器读取它获取上下文、向工作区写入过程。这一约定与 docs/agent/model-infer-optimize-design.md §4.1 的progress.md常驻区 工作区 progress_history.md历史归档设计保持一致。引用关系一份分析派生多个 Plan不重复baseline 性能报告 ──证据──► analysis/source.md ──派生──► plans/plan-A.md / plan-B.md / … 时间分布 理论 gap 一份分析多 Plan 共享 每 Plan 一份完整记录6.3 写者规则与单一真相源Dashboard 只有主 agent 写subagent 不写 Dashboard自己的产出通过回传摘要交主 agent 镜像进表plans/plan-id.md由该 Plan 的 candidate / implementer / reviewer 产出与追加candidate 落初稿方案描述 方案细节implementer / reviewer 在循环里追加 round 级结论摘要主 agent 读它做裁决、把关键信息 状态镜像进 Dashboard 表但不改 plan 文件的内层结构progress.md的常驻区由主 agent 维护、工作区由各 subagent 追加写入前先读现有内容。设计考虑让 Dashboard 成为 Plan 状态的单一真相源且只有一个写者主 agent是为了杜绝多 agent 并发写同一状态文件造成的覆盖与不一致。subagent 的产出一律先写入各自的文件再由主 agent 单点镜像进 Dashboard使状态流向收敛。6.4 总览 明细分离Dashboard 分总览与明细两层总览Dashboard场景与基线、Baseline Profiling、潜在优化项发现记录、Plan Dashboard 表每 Plan 一行plan_id / 来源 / 优化类型 / 单点 skill / 互斥组 / 可叠加 / 状态 / round / 证据摘要 / 淘汰·保留原因 / plan 文件链接、当前采纳的实现、Round 记录、最终验收。结构固定、与优化方向无关。明细每个 Plan 一份plan-id.md方案描述、方案细节领域自由块结构由对应单点 skill 定义、实施记录、Review 记录、派生记录不内联到 Dashboard。边界契约plan 文件的详尽程度由领域 skill 自行决定但每个 Plan 必须将编排裁决所需的少数信息上浮到 Dashboard 表——是否真实生效、收益性能以分析报告为准、精度、enable / 回退、副作用汇成「证据摘要」 状态。Dashboard 的 Round 记录只做索引每轮选了哪个 Plan、是否重采、裁决结论本轮明细写在对应 plan 文件里。6.5 跨上下文压缩的状态重建编排过程可能很长主 agent 的上下文会被压缩。这套分层文件同时是主 agent跨上下文压缩重建状态的依据——Dashboard 给出全局状态、progress.md 给出共享上下文、plan 文件给出单 Plan 细节。因此要求关键节点即时回写、不延后至收尾阶段每轮裁决、每次派生、每次状态变更都立即落盘使任意时刻均可从文件重建出完整的编排状态而不依赖主 agent 的上下文记忆。这也与 AGENTS.md 行为约束中及时持久化长任务中关键结论、设计决策、调试发现要及时写入文件如 progress.md上下文压缩会丢失未保存的信息的原则一致。7. profiling 驱动与证据口径7.1 唯一性能真相源一切性能收益判断均以profile-analyzer产出的分析报告为准——以报告给出的时间分布、与 baseline 的 Δ%、以及逐算子实测 / 理论 gap 变化为依据不以裸 wall-clock 数字infer 脚本打印、time.perf_counter计时等直接得出结论。设计考虑裸 wall-clock 易因采样噪声、口径不对等而产生误导。尤其在多流等场景主流-only busy与单流 full-work属于不对等口径直接相减会得到失真的收益数字。统一以分析报告为真相源并要求重采轮与 baseline 做同口径对照方能区分真实收益与口径偏差。需要注意的是perf-breakdown 分析的是 in-graph kernel若瓶颈落在图外的 host-dispatch 开销上分析报告无法捕捉需采用对应的 clean full-wall 口径补充测量——但仍须在固定、可复现的口径下进行而非临时裸计时。仓库侧可供采集的原始数据面已经具备如前文所述executor/utils/profiler_context.py 以torch_npu.profiler为底层配置ProfilerLevel.Level1与AiCMetrics.PipeUtilization可采集 NPU / CPU activitydocs/common/inference_config_guide.md 给出了enable_profiler: True的配置入口AGENTS.md 常用命令中也说明性能分析YAML 中设 enable_profiler: True结果在 prof/ 目录。kernel_details.csv这类逐算子明细数据即由此类采集产生供 perf-breakdown 做时间分布与理论 gap 分析。7.2 round 之间是否重采的判据是否重采 profiling 由主 agent 判断不强制每轮都重采。判断只围绕一个问题现有 profiling 数据能否支撑后续的收益判断。需要重采用 profiling-instrumenter profile-analyzer复用 baseline 分析配置上一轮改动改变了算子下发时序、计算图结构、dtype 或 layout——多流、融合算子、图模式、量化等改造大多属于此类reviewer 反映现有 profile 已与当前代码不符不足以判断收益切换到新的优化方向或下钻到此前未采集过的热点模块准备给某个方案下「通过 / 淘汰」终裁需要一份与当前代码严格对应的最新 profile进入最终验收前对最终代码路径至少重采一次用来与 baseline 做同口径对照。可以不重采、沿用现有数据本轮仅改动开关或参数未改变算子下发与计算结构且仍以同一份数据做对照改动与性能结构无关纯精度修复、注释或日志调整。7.3 同口径对照与 baseline 基准第 3 步采集得到的即为baselineround0profile是后续所有 round 做同口径对照的基准。baseline 在第 4 步确认的分析 spec 会被后续每个重采 round复用、无需再次向用户确认重采轮与 baseline 做同口径对照得出 Δ%。最终验收时以与 baseline 相同的场景、相同的指标口径做对照并以 profile-analyzer 报告为准。设计考虑固定一个 baseline 基准 固定一套分析 spec是所有轮次收益可比的前提。若每轮各自变更口径Δ% 将失去意义因此 spec 一次确认、全程复用baseline 一次采定、反复对照。8. TaskList 编排与验收8.1 任务骨架进入 skill 后先建准备阶段任务到潜在优化项与 Dashboard 为止T1. 确认推理场景与可选性能目标 T2. 派发 scenario subagent 构造推理输入并跑通精度基线 T3. 派发 profiling-instrumenter subagent 采集 baseline (round0) profiling非交互 T4. 主 agent 确认 perf-breakdown 拆解 spec再派发 profile-analyzer 执行 baseline 分析 T5. 为来源表每个来源并行派发 candidate subagent 发现潜在优化项 T6. 初始化 Plan Dashboard归并优化项并裁定跨方向互斥 / 叠加T6 之后进入 Plan 循环每选定一个 Plan 就新建一组 TR{N} 任务N 为全局递增 round 编号本轮做完即逐项关闭再为下一个 Plan 或派生 Plan 建下一组TR{N}.1 选定当前 Plan分配 roundN准备上下文判断本轮是否需要重采 profiling TR{N}.2 主 agent 按 Plan 内容确定单点 skill派发 implementer subagent 实施 TR{N}.3 按需重采并分析 round{N} profiling TR{N}.4 派发 reviewer subagent 复核并验收 implementer 的工作 TR{N}.5 主 agent 更新 Plan 状态、记录证据、处理派生建议决定下一步无待实现 Plan 后建最终验收任务TF1–TF5见 §8.3。8.2 不用长驻任务覆盖循环设计考虑不要建进入 Plan 循环这种一个任务覆盖整个循环的长驻任务——它会一直停在in_progress、不反映真实进度。Plan 循环的轮数事先未知取决于派生多少 Plan用每轮一组 TR{N} 任务来表达循环每轮的任务组在本轮内闭合下一轮再开新组。这样 TaskList 的粒度始终对应当前正在推进的 Plan/round进度可见、可断点接力。8.3 不轻易收尾与最终验收本技能强调不轻易收尾必须所有 Plan 都转为通过或淘汰且确认再无可派生的、仍有潜在收益的新 Plan才进入最终验收。最终验收前先重采一次profiling与 round0baseline做同场景、同口径对照然后逐项确认TF1. 确认所有 Plan 均为通过或淘汰无待实现 Plan TF2. 确认再无可派生的、仍有潜在收益的新 Plan TF3. 确认所有通过 Plan 已应用且可叠加 Plan 的组合效果已实测验收 TF4. 确认所有淘汰 Plan 已回退或被开关关闭不影响最终 profile TF5. 汇总最终方案、淘汰原因与剩余风险补充确认项同一互斥组内状态自洽最终只保留一个或一组明确兼容的通过Plan最终精度 / 功能仍满足第 1 步约定的场景口径最终性能用与 baseline 同一场景、同一指标口径以 profile-analyzer 报告为准。设计考虑探索式优化容易在收益趋缓时过早停止而不轻易收尾 逐项验收清单将收尾确立为一个具有明确门禁的状态——只有当 Plan 空间穷尽无待实现、无可派生且最终态经同口径实测确认后才视为完成。9. 与基础优化工作流的关系与定位将model-infer-sota-approach放在整个 Agent Skill 体系中看其定位非常清晰基础优化工作流docs/agent/model-infer-optimize-design.md以model-infer-optimize为编排入口按固定阶段migrator → 并行 → KVCache → 融合 → 量化 → 图模式 → 总结推进适用于从框架适配到 baseline 建立的确定性路径并沉淀了 migrator、parallel、kvcache、fusion、quantization、graph-mode、precision-debug、runtime-debug 等一批单点 skill极致性能优化技能本文档以 profiling 驱动、Plan 自循环为核心适用于baseline 之上的非确定性深度探索调度 multi-stream、prefetch、superkernel 等进阶单点 skill以及基础工作流中已沉淀的融合、图模式、量化等能力。两者共用同一套 Agent Team 模式与progress.md状态机制AGENTS.md 中给出了完整的 Skill 路由表与行为约束后者正是前者在性能空间挖掘维度上的自然延伸。仓库中 docs/cann/zh 目录下的多流、prefetch、图模式、SuperKernel 原理文档以及 docs/cann/en 的英文对照构成了这些单点 skill 的领域知识底座可被 candidate / implementer / reviewer 按需加载。参考索引本文档docs/agent/sota-approach-skill-design.md基础优化工作流设计docs/agent/model-infer-optimize-design.md项目根指令与 Skill 路由AGENTS.mdInferenceConfig 配置指南enable_profiler 等docs/common/inference_config_guide.mdProfiler 采集实现ProfilerManager / create_profilerexecutor/utils/profiler_context.py多流优化原理docs/cann/zh/multi_stream_principles.mdPrefetch 优化原理docs/cann/zh/prefetch_principles.md图模式优化原理docs/cann/zh/npu_graph_optimization.mdSuperKernel 原理docs/cann/zh/super_kernel.mdSkill 体系初始化脚本scripts/init-agent.sh【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考