model-infer-sota-approach 状态裁决与 round 推进规则Plan 自循环收敛的实操指南【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer导读本文是 cann-recipes-infer 仓库中model-infer-sota-approach模型推理极致性能优化编排技能的状态裁决与 round 推进规则decision-rules.md的深度解读。该规则服务于一套 profiling 驱动的多方向探索式优化流程在已有可运行 baseline 之上并行发现候选优化项再用 Plan 自循环实施 → 复核 → 派生 → 淘汰逐步收敛到最优方案。读完本文你将掌握Dashboard 初始化的前提条件、待实现 / 通过 / 淘汰三态状态机的判通过与判淘汰的完整判据、round 之间是否重采 profiling 的决策依据以及派生新 Plan、互斥与叠加裁定、最终验收的操作细节并了解这些规则在 SKILL.md 与 sota-approach-skill-design.md 中的设计定位。一、规则在整套编排流程中的位置model-infer-sota-approach是一个高阶编排技能它不预设固定优化阶段而是以 profiling 数据为依据在多个不确定方向上并行试探用 Plan/round 自循环收敛。它只负责整条编排——从推理场景建立、精度基线、profiling 采集与分析到候选发现、Plan 实施、review、派生和最终验收具体的代码改造由它调用的单点技术 skill 负责。本规则文件decision-rules.md供主 agent使用覆盖三个关键时刻候选发现完成后初始化 Dashboard每轮 implementer / reviewer subagent 返回后裁决 Plan 状态通过/淘汰/ 保持待实现在两个 round 之间决定是否重采 profiling。约束优先序领域 skill 自身的正确性硬约束优先于本文件。即单点技术 skill 定义的验收要求高于编排层的通用裁决规则。主 agent 在流程中通过 SKILL.md 引用本规则Plan Dashboard 使用 plan-dashboard-template.md状态裁决、互斥/叠加判定、是否重采 profiling 和派生规则见本文件。设计层面的完整论证在 sota-approach-skill-design.md 的第 5 章Plan 自循环机制与第 7 章profiling 驱动与证据口径。二、初始化 Dashboard 的前提证据齐备才落盘Dashboard约定路径optimization-analysis/case/plan-dashboard.md是 Plan 状态的单一真相源且只有主 agent 写。规则明确Dashboard 只有在下列信息齐备后才能初始化提前初始化会让候选缺少证据支撑后面的裁决也无从落脚推理场景以及精度 / 功能口径已经记录在案场景已经跑通即便被阻塞也已查清阻塞原因且用户仍要求继续分析baseline 的 profiling 采集方式已经建立或者已有可直接复用的 profiling 数据baseline profiling 已经分析完毕产出了可回查的分析报告至少有一个 candidate subagent 返回了候选或者所有候选方向都已明确判定没有候选。如果用户直接给了一份优化列表它只作为候选种子仍要先经 candidate subagent 或主 agent 规范化再进入 Dashboard。这一先发现、后初始化的设计在 sota-approach-skill-design.md 中有明确论证若在候选缺乏证据支撑时即初始化 Dashboard后续裁决将无从依据。Dashboard 的完整字段结构场景与基线、Baseline Profiling、候选发现记录、Plan Dashboard 表、当前采纳的实现、Round 记录、最终验收见 plan-dashboard-template.md。三、状态定义只有三种状态全程只允许三种状态刻意避免部分完成疑似有效之类的模糊中间态状态含义待实现还没实施或证据不足但仍有继续实施、调测的价值通过有明确收益或必要价值且功能、精度、回退路径和副作用都已检查通过淘汰无收益、风险过高、实现失败、破坏功能或精度或被同一互斥组里更优的 Plan 替代设计考虑任一 Plan 在任意时刻都明确处于待办 / 保留 / 丢弃之一使 Dashboard 可快速通览全局。证据不足但仍有价值的情形归入待实现可继续调测而不是新增一个中间状态。该状态机同样出现在 SKILL.md 的全局约束状态只有三种和 plan-dashboard-template.md 的字段说明中。四、判通过六个条件全部满足下列条件全部满足才能标通过reviewer 建议通过或主 agent 掌握了更强的证据支持通过该 Plan 的代码路径会在第一步确认的推理场景里真正执行到而不是停在未触发的分支里功能和精度满足第一步约定的口径例如按 scenario-setup.md 建立的机判规则LLM 贪心逐 token 对齐 可读 / 不重复 / 非全零 / 不提前 EOS量化 / 生成类模型按模态调整目标指标达到该 Plan 的保留标准如果性能目标本身是可选的也要说清它的保留价值例如为后续 Plan 让出资源、或消除某一类瓶颈enable 开关、配置项和回退路径都清楚可用不破坏任何已经通过的 Plan若属于互斥组组内当前没有比它更优的已通过 Plan否则先处理替代关系再裁决。其中第 2 条代码路径真正执行到是评审中常见的坑一个 Plan 即使实现了如果它挂在某个未触发的开关分支上就不能算数。第 4 条与性能证据统一口径原则呼应——收益判断以 profile-analyzer 的分析报告为准而非裸 wall-clock 数字。五、判淘汰任一情况即触发出现下列任一情况优先标淘汰reviewer 明确判失败且失败不属于缺一次可补的验证功能、精度、稳定性或编译出问题目标指标没有收益或收益低于噪声且已无继续调测的空间引入了明显副作用拖累其他关键模块、内存暴涨、多出 shape / layout 转换、图模式退化等与已通过 Plan 冲突而它本身收益更低或风险更高同一互斥组里已经有更优的 Plan。标淘汰后必须记录三件事淘汰证据代码是否已回退或 enable 是否已关闭是否由此派生了新的 Plan。这三件事保证了淘汰是可回查、可追溯的不会留下污染最终代码路径的残留开关——这一点直接支撑 SKILL.md 最终验收中所有淘汰Plan 已回退或被开关关闭不影响最终 profile的门禁。六、保持待实现或追加 round不要急着淘汰下列情况不要急着淘汰可以保持待实现或新开一个 round 继续打磨实现还没完成但卡点是可修复的reviewer 只是指出证据不足需要补一次验证方向本身成立只是强度、参数、配置或局部实现还要继续调本轮暴露了新问题但还不足以证明 Plan 本身无效。与判淘汰的第一条判据对照reviewer 判失败时要区分失败与缺一次可补的验证——前者触发淘汰后者只触发追加一个验证 round。这与设计文档 sota-approach-skill-design.md 中证据不足但仍有价值的情形归入待实现的考虑一致。七、round 之间是否重采 profiling每轮收尾、主 agent 准备挑下一个 Plan 时先判断要不要重新采集 profiling再决定下一步。判断只围绕一个问题现有的 profiling 数据还能不能支撑接下来的收益判断。需要重采用profiling-instrumenter与profile-analyzer两个 subagent 产出本轮 profile复用 baseline 的分析配置不再与用户交互。触发条件上一轮改动改变了算子下发时序、计算图结构、dtype 或 layout——多流、融合算子、图模式、量化这类改造基本都落在这一类reviewer 反映现有 profile 已经对不上当前代码不足以判断收益要切换到新的优化方向或下钻到此前没采过的热点模块准备给某个方案下通过 / 淘汰的终裁需要一份与当前代码严格对应的最新 profile进入最终验收前对最终代码路径至少重采一次用来与 baseline 做同口径对照。可以不重采、沿用现有数据本轮只动了开关或参数没有改变算子下发和计算结构而且仍在用同一份数据做对照改动与性能结构无关例如纯精度修复、注释或日志调整。收益判定以分析报告为准无论是否重采性能收益的判定都以 profile-analyzer 的分析报告为准——看报告给出的时间分布、与 baseline 的 Δ%、以及逐算子实测 / 理论 gap 变化不拿裸 wall-clock 数字infer 脚本打印、time.perf_counter计时等直接下结论。这一口径在 SKILL.md 中被列为全局约束性能证据统一口径并在 sota-approach-skill-design.md 中有设计论证裸 wall-clock 易受采样噪声、口径不对等误导尤其在多流场景主流-only busy与单流 full-work属于不对等口径直接相减会得到失真的收益数字。八、派生新 Plan追加而非改写implementer、reviewer 和主 agent 都可以提议派生最终由主 agent 写入 Dashboard。派生是**追加而非改写**——旧 Plan 原样保留连同其证据与裁决新 Plan 另起编号。常见触发当前 Plan 的核心假设被推翻但证据指向了另一条可行的实现路径同一个优化点还有不同的编排、算子、参数或图模式路径没试过implementer 发现原方案落地成本过高但存在一个更小的切口可以先验证reviewer 确认当前实现有收益但还有风险更低或收益更高的变体值得一试Plan 被淘汰的原因不是优化点没价值而是这条实现路径不合适多个已通过 Plan 组合后出现退化需要派生一个专门治理组合的 Plan。派生记录要写清派生自哪个 Plan / round、来源是 implementer / reviewer 还是 main、触发现象、新旧 Plan 的差异新 Plan 初始状态一律为待实现。派生与 round 编号配套每个 Plan、每档强度、每次尝试都用独立的全局递增roundN记录派生出的 Plan 也分配新的roundN既不复用旧编号、也不与旧 round 合并。round 是全局单调递增的时间轴profiling 产物、Dashboard 裁决、plan 文件记录可借 roundN 一一对应避免编号复用导致的证据错配。相关模板见 plan-file-template.md 的派生记录表。九、互斥与叠加裁定同一互斥组最终只保留一个、或一组明确兼容的通过Plan新 Plan 替代旧 Plan 时把旧 Plan 改为淘汰原因写明被 Plan-X 替代可叠加的 Plan 可以同时通过但必须在最终验收里实测叠加后的代码路径和指标而不是想当然认为收益可加两个单独通过的 Plan 组合后若退化追加一个组合验证 round必要时淘汰组合收益更差或风险更高的一方。跨方向的冲突要在初始化 Dashboard 时就识别。每个 candidate subagent 只看自己一个方向像融合算子改写 attention与多流切分 attention、图模式 Plan与多流 Plan这类跨方向的互斥或兼容关系单个 candidate 看不到全貌必须由主 agent 统一归并、标好互斥组和可叠加性。这个来源内判互斥、跨来源归并的分工在 sota-approach-skill-design.md 有详细展开candidate 只判自己来源内的互斥 / 叠加并写入analysis/source.md跨来源关系例如多个来源均指向 MoE 多流 overlap由主 agent 在第 6 步归并为同一个 Plan编排变体作为该 Plan 的内部强度阶梯。十、最终验收收尾门禁清单收尾前必须逐条确认Dashboard 里没有待实现的 Plan所有通过Plan 都在最终代码路径里真实生效所有淘汰Plan 都已回退或被开关关闭互斥组状态自洽组内只剩最终采用的方案为通过可叠加 Plan 的组合效果已经实测验证最终精度 / 功能仍满足第一步约定的场景口径最终性能用同一推理场景、同一指标口径与 baseline profile 做了对照主 agent 已明确说明无法再派生出仍有潜在收益的新 Plan。这些确认项与 SKILL.md 的最终验收步骤一一对应plan-dashboard-template.md 的第 7 节还给出了可直接照填的验收表单是否已无待实现 Plan、淘汰方案摘要、剩余风险等。设计文档 sota-approach-skill-design.md 将其概括为不轻易收尾探索式优化容易在收益趋缓时过早停止而不轻易收尾 逐项验收清单把收尾确立为具有明确门禁的状态。十一、从规则到落地配套文件速览本规则不是孤立文件它与同目录下的姊妹文件共同构成可执行的编排闭环文件作用SKILL.md编排主流程8 步 Plan 循环 最终验收本规则是其状态裁决的判据来源decision-rules.md本文主题状态裁决、重采判据、派生、互斥叠加、最终验收plan-dashboard-template.mdDashboard 总览落盘布局与字段说明主 agent 唯一写plan-file-template.md每 Plan 一份的明细文件模板方案描述 / 实施 / Review / 派生记录scenario-confirm.md主 agent 确认推理场景与性能目标的交互细则scenario-setup.mdscenario subagent 构造输入、跑通基线、定判定口径的细则subagent-prompt-templates.md六类 subagent 的 dispatch 模板sota-approach-skill-design.md整套技能的设计文档Plan 状态机、派生机制、证据口径的论证十二、仓库中的实际应用场景本技能面向的优化对象正是本仓库中 models/ 下的各类模型推理样例与 ops/、module/ 中的加速算子模块。以仓库中的 agentic 优化报告为例hy3/agentic/optimization_report.md 展示了融合算子消化结构特殊点如 QK Norm 通过npu_rms_norm优化、Sigmoid Router 通过npu_moe_gating_top_k(norm_type1)融合以及Decode 路径适配 ge_graph 图模式的典型 Plan 落地方式longcat_flash_lite/agentic/progress_ep.md 则记录了阶段化推进与阶段 1 通过进入阶段 2这类与通过状态对应的推进节奏。对照本规则多流、图模式、量化这类改造会改变算子下发时序与计算图结构按第七节判据属于需要重采 profiling的类型融合算子与图模式的 Plan 若作用于同一段计算按第九节判据需要在初始化 Dashboard 时归并进同一互斥组。这些正是本规则在真实推理优化场景中的直接适用面。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考