CANN 模型推理优化编排中的 Plan Dashboard 模板从候选发现到最终验收的单一真相源实践【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer导读本篇文章面向在 cann-recipes-infer 仓库上使用model-infer-sota-approach高阶优化编排技能的开发者与 AI Agent系统讲解其核心编排工件——Plan Dashboard 模板.agents/skills/model-infer-sota-approach/references/plan-dashboard-template.md的设计意图、落盘布局、分层写者契约以及从 Baseline Profiling、候选发现、Plan 实施/review/派生循环到最终验收的完整使用方法。读完本文你将掌握如何在多方向并行优化多流、融合算子、prefetch、图模式、KVCache、量化、并行等中用一份 Dashboard 文件 每 Plan 一份明细文件来管理状态、证据与裁决确保优化过程可回查、可验收、可复现。1. Dashboard 在优化编排流程中的定位model-infer-sota-approach是 .agents 下针对已可运行的 baseline之上进行 profiling 驱动探索式优化的高阶编排技能。与按固定阶段推进的基础流程model-infer-optimize不同它不预设优化阶段而是以 profiling 数据为依据在多个不确定方向上并行试探再用 Plan 自循环实施 → 复核 → 派生 → 淘汰逐步逼近最优方案。其完整流程见 SKILL.md共 8 步确认推理场景与性能目标主 agent 交互依据 scenario-confirm.md构造推理输入并跑通精度基线scenario subagent依据 scenario-setup.md采集 baseline profilinground0profiling-instrumenter subagent非交互分析 baseline profiling主 agent 敲定拆解 specprofile-analyzer subagent 跑分析候选发现为每个候选来源并行拉 candidate subagent初始化 Plan Dashboard主 agent 唯一写者Plan 实施 / review / 派生循环最终验收。Plan Dashboard 模板服务于第 6 步之后的全部编排动作。它记录从推理场景、baseline profiling 分析、候选发现到Plan 实施 / review / 最终验收的整条过程是 Plan 状态的单一真相源。Dashboard 是单一文件约定落在optimization-analysis/case/plan-dashboard.md候选发现完成后才初始化在此之前产生的场景与 baseline profiling 产物也先记入本文件对应小节。2. 落盘布局一次优化案例的目录约定一次优化的所有产物固定按以下布局落到optimization-analysis/case/optimization-analysis/case/ ├── plan-dashboard.md 编排报告总览脊柱只放关键信息 状态 裁决主 agent 唯一写 ├── scenario.md 场景记录scenario subagent 产出§1 链接 ├── analysis/ 各候选来源的分析产物一来源一文件文件名取 §5 表的来源名 │ ├── source.md 一来源一文件来源名见 SKILL §5 表 │ └── … ├── plans/ 每个 Plan 一份完整记录方案描述 / 细节 / 实施 / review / 派生不内联到 dashboard │ ├── plan-A.md │ └── … └── perf/ perf-breakdown 的工作目录采集 分析的 profile 与报告全在这内部结构和文件名归 model-infer-perf-breakdown本流程不感知其中perf/的内部结构由model-infer-perf-breakdown技能自己管理本流程只把它当作工作目录、读取它产出的报告不重新定义它的契约。此外progress.md共享状态文件不在本 case 树内——它的位置由主 agent 解析、找不到就创建找不到时用.agents/skills/model-infer-optimize/templates/progress_template.md创建作为跨 agent 共享上下文 subagent 实施 / 踩坑 / 验证过程日志沿用model-infer-optimize的常驻区 / 工作区 / 归档约定编排器读它取上下文、往工作区写过程。引用关系遵循一份分析派生多个 Plan不重复的原则baseline 性能报告 ──证据──► analysis/source.md ──派生──► plans/plan-A.md / plan-B.md / … 时间分布 理论 gap 一份分析多 Plan 共享 每 Plan 一份完整记录即baseline 性能报告时间分布 理论 gap作为证据支撑analysis/source.md一份方向级分析可被多个 Plan 共享每个 Plan 再各自维护一份完整记录。3. 分层与写者总览 / 明细 / 方向级分析三层分离Dashboard 体系分为总览和明细两层每个 Plan 一份独立明细文件dashboard 只做总览dashboard总览主 agent 唯一写本文件 §1–§7只放关键信息 状态 裁决——场景与基线、Baseline Profiling、候选发现记录、Plan Dashboard 表每 Plan 一行plan_id / 来源 / 优化类型 / skill / 互斥组 / 可叠加 / 状态 / round / 证据摘要 / 淘汰·保留原因 / plan 文件链接、当前采纳的实现、Round 记录、最终验收。结构固定、与优化方向无关。明细每个 Plan 一份plans/plan-id.md领域 subagent 产出方案描述、方案细节领域自由块、实施记录、Review 记录、派生记录全写在这里不内联到 dashboard。结构由对应单点 skill 定义、主 agent 不解析。candidate 落初稿方案描述 方案细节该 Plan 的 implementer / reviewer 在循环里追加记录。模板见 plan-file-template.md。方向级分析产物module/op DAG、候选等一个来源一份analysis/source.md被该来源所有 Plan 共享由 candidate 产出。边界契约plan 文件里写多细由领域 skill 自己发挥但每个 Plan 必须把编排裁决需要的少数信息上浮到 dashboard 表——是否真实生效、收益性能以分析报告为准、精度、enable / 回退、副作用汇成「证据摘要」 状态。写者规则dashboard§1–§7只有主 agent 写plans/plan-id.md由该 Plan 的 candidate / implementer / reviewer 产出与追加。主 agent 读 plan 文件做裁决、把关键信息 状态镜像进 dashboard 表不改 plan 文件的内层结构subagent 不写 dashboard。dashboard / progress.md / plan- .md 三者分工互不复制文件职责谁写plan-dashboard.md只管状态指示Plan 状态、采纳实现、round 裁决是 Plan 状态的单一真相源主 agentprogress.md跨 agent 共享上下文 subagent 实施 / 踩坑 / 验证过程日志常驻区 / 工作区 / 归档主 agent 维护常驻区各 round subagent 追加工作区plans/plan-id.md每个 Plan 的方案 spec 与 round 级结论摘要candidate / implementer / reviewer三者各司其职、不互相复制看状态查 dashboard、看过程与共享上下文查 progress.md、看单个 Plan 的方案查它的 plan 文件。这套文件也是主 agent 跨上下文压缩重建状态的依据关键节点要即时回写、不要攒到收尾。4. Dashboard 七个章节逐节详解4.1 §1 场景与基线记录优化的出发点是后续所有分析的前提模型 / case、代码目录、推理入口推理场景性能目标可选精度 / 功能口径场景记录文件scenario.md路径输入样本 / 构造脚本基线运行命令基线精度 / 功能结果。结合仓库实际场景确认的细节见 scenario-confirm.md主 agent 应先勘察后提问——从models/model/目录的infer.sh其中的YAML_FILE_NAME、config/*.yaml文件名编码phase、卡数、并行、量化以及已有的progress.md、baseline/baseline_metadata.json等产物中整理候选场景清单再一次性结构化确认 Q1 场景 / Q2 workload 侧重 / Q3 精度口径 / Q4 性能目标可选/ Q5 输出归档目录。例如 models/deepseek_r1/config/decode_r1_rank_16_16ep_a8w8.yaml 这类文件名即编码了 decode 阶段 / 16 卡 / 16 EP / W8A8 的场景维度。4.2 §2 Baseline Profiling 与性能分析round0本节对应 round0采集由 profiling-instrumenter subagent 做非交互分析由 profile-analyzer subagent 跑非交互其拆解 spec 由主 agent 在派发前与用户交互敲定。这是后续所有 round 做同口径对照的基准。记录内容包括profiling 采集命令 / 产物路径perf-breakdown 工作目录性能分析报告路径关键瓶颈摘要时间分布 top 模块 实测/理论 gap top 算子热点模块 / 文件 / 算子数据质量或采集风险。从 subagent-prompt-templates.md 可见采集与分析由两个独立 subagent 完成profiling-instrumenter用model-infer-profiling插入或启用采集要求保留关闭开关、不污染普通推理路径profile-analyzer用model-infer-perf-breakdown产出含「时间分布」和「逐算子实测 / 理论 gap need optimization 清单」两类证据的报告。性能收益的一切判定都以这份分析报告为准不拿裸 wall-clock 数字当结论依据。4.3 §3 候选发现记录候选由多个 candidate subagent 并行产出来源在 SKILL §5 候选发现表注册multi-stream / wiki / perf-insight 三个来源。每个来源一行source取来源名。候选之间的互斥 / 叠加关系留到第 4 节由主 agent 裁定实施用哪个单点 skill 在第 7 步按 Plan 内容定不在此列。来源分析产物候选数量摘要sourceanalysis/.md注意候选先发现Dashboard 后初始化。场景、精度、baseline profiling 和候选发现没全部完成前不要初始化 Dashboard这也是 decision-rules.md 中初始化 Dashboard 的前提口径记录在案、场景跑通、采集方式建立、baseline 分析完毕、至少一个来源返回候选或明确判定无候选。4.4 §4 Plan Dashboard核心状态表每个 Plan 一行只放关键信息 状态明细在plan 文件链接的plans/plan-id.md。plan_id来源优化类型单点 skill互斥组可叠加状态round证据摘要淘汰 / 保留原因plan 文件Plan-Acandidate-1group-1yes/no待实现plans/plan-A.md字段说明11 个字段逐一继承原模板定义plan_id稳定 ID派生新 Plan 时递增不复用旧 ID来源候选发现 subagent或derived-from Plan-X/roundN优化类型多流、融合算子、prefetch、图模式、KVCache、量化、并行等单点 skill实施该 Plan 用的单点技术 skill由主 agent 在第 7 步按 Plan 内容判断填入多流 Plan 已知是model-infer-multi-stream不是编排器候选发现阶段可留空互斥组跨方向的互斥关系由主 agent 在初始化时裁定同组内最终只保留一个或一组兼容的通过Plan互不影响的写不同组可叠加填yes或no标yes的 Plan 即便各自通过仍要在验收时验证叠加效果状态只允许待实现/通过/淘汰round当前状态对应的全局 round 编号证据摘要只写可回查的摘要从 plan 文件上浮不贴长日志或 raw 表淘汰 / 保留原因一句话写核心原因若派生了新 Plan写明派生目标plan 文件该 Plan 的完整记录plans/plan-id.md。状态机语义decision-rules.md状态含义待实现还没实施或证据不足但仍有继续实施、调测的价值通过有明确收益或必要价值且功能、精度、回退路径和副作用都已检查通过淘汰无收益、风险过高、实现失败、破坏功能或精度或被同一互斥组里更优的 Plan 替代判通过需同时满足reviewer 建议通过或主 agent 掌握更强证据、代码路径真实执行到、功能精度满足口径、达到保留标准、enable/回退路径清楚可用、不破坏已通过 Plan、互斥组内无更优 Plan。出现 reviewer 明确判失败、功能精度稳定性编译出问题、无收益或收益低于噪声、引入明显副作用、与已通过 Plan 冲突、组内已有更优 Plan 等任一情况则优先标淘汰标淘汰后必须记录淘汰证据、代码是否已回退或 enable 是否关闭、是否派生新 Plan。4.5 §5 当前采纳的实现列出当前通过、构成最终方案的 Plan 集合随通过 / 淘汰 / 替代实时更新最终验收时即最终采用方案。互斥组里只列最终保留的那个可叠加的并列。plan_id优化类型单点 skill采纳的实现代码改动 enable 开关收益摘要plan 文件这一节保证了最终方案 已落地的通过 Plan 集合随时可审计是最终验收时方案汇总的依据。4.6 §6 Round 记录只做索引每个 round 选了哪个 Plan、是否重采、裁决结论本轮的实施 / review / profile 明细写在对应plans/plan-id.md里。roundplan_id是否重采 profilingprofile 产物目录主 agent 裁决round1是 / 否沿用 roundXround 编号全局递增、不复用每一个 Plan、每一档强度、每一次尝试都用独立的全局递增roundN记录派生出的 Plan 也分配新的roundN既不复用旧编号、也不与旧 round 合并。是否重采 profiling 由主 agent 判断详见第 5 节不强制每轮都重采。4.7 §7 最终验收进入本节前先对最终代码路径重采一次 profiling与 round0baseline做同场景、同口径对照。逐项确认是否已无待实现Plan是否再无可派生的、仍有潜在收益的新 Plan所有通过Plan 是否都已应用到最终代码可叠加 Plan 的组合效果是否已实测验证同一互斥组是否只保留最终采用的 Plan所有淘汰Plan 是否已回退或被开关关闭最终精度 / 功能是否仍满足第 1 节的场景口径最终性能是否按 baseline 同口径对照以 profile-analyzer 报告为准最终采用方案、淘汰方案摘要、剩余风险。5. Round 推进何时重采 profiling、如何派生新 Plan5.1 重采判据每轮收尾、主 agent 准备挑下一个 Plan 时只围绕一个问题判断现有的 profiling 数据还能不能支撑接下来的收益判断。需要重采的情况用 profiling-instrumenter profile-analyzer复用 baseline 的分析配置、不再与用户交互上一轮改动改变了算子下发时序、计算图结构、dtype 或 layout——多流、融合、图模式、量化通常都属此类reviewer 反映现有 profile 已经对不上当前代码、不足以判断收益要切换到新的优化方向或下钻到此前没采过的热点模块准备给某个方案下通过 / 淘汰终裁需要一份与当前代码严格对应的最新 profile进入最终验收前对最终代码路径至少重采一次用于与 baseline 做同口径对照。可以不重采、沿用现有数据的情况本轮只动了开关或参数、没有改变算子下发和计算结构且仍用同一份数据对照改动与性能结构无关纯精度修复、注释或日志调整。无论是否重采性能收益判定一律以 profile-analyzer 的分析报告为准时间分布、与 baseline 的 Δ%、逐算子实测 / 理论 gap 变化不拿裸 wall-clock 数字直接下结论。5.2 派生新 Planimplementer、reviewer 和主 agent 都可以提议派生最终由主 agent 写入 Dashboard。派生是追加而非改写——旧 Plan 原样保留新 Plan 另起编号初始状态一律待实现。常见触发核心假设被推翻但证据指向另一条路径同一优化点还有不同编排 / 算子 / 参数 / 图模式路径没试过原方案落地成本过高但存在更小切口reviewer 发现更低风险或更高收益的变体淘汰原因是实现路径不合适而非优化点没价值多个已通过 Plan 组合后出现退化需要专门治理。5.3 互斥与叠加裁定同一互斥组最终只保留一个、或一组明确兼容的通过Plan新 Plan 替代旧 Plan 时把旧 Plan 改为淘汰原因写明被 Plan-X 替代可叠加的 Plan 可以同时通过但必须在最终验收里实测叠加后的代码路径和指标不能想当然认为收益可加两个单独通过的 Plan 组合后若退化追加一个组合验证 round必要时淘汰组合收益更差或风险更高的一方。跨方向的冲突如融合算子改写 attention与多流切分 attention、图模式 Plan与多流 Plan要在初始化 Dashboard 时就识别单个 candidate 只看自己一个方向、看不到全貌必须由主 agent 统一归并、标好互斥组和可叠加性。6. 每 Plan 一份明细plans/plan-id.md的结构Plan 明细模板见 plan-file-template.md每个 Plan 一份、不内联到 dashboard。candidate 落初稿方案描述 方案细节 参考 wiki该 Plan 的 implementer / reviewer 在循环里追加 round 级结论摘要主 agent 只读它做裁决、把关键信息 状态镜像进 dashboard 表、不改其结构。结构如下# plan_id方案名 ## 方案描述 优化什么、为什么可能有收益、怎么验证、主要风险在哪。自由组织不强制字段。 ## 实施参考 wiki 页面 candidate 查到的、与本 Plan 实施相关的 wiki 页面 ID没挂载 wiki 或无相关页面则留空。 ## 方案细节领域 skill 自填 结构由该 Plan 的单点 skill 定义。例如多流方向按 model-infer-multi-stream 的 plan-detail-fragment 填写流分组 / 汇合点 / 方案 DAG / 强度 / GE auto-reorder 风险 / overlap_pct 实测 / enable·回退 / 副作用。裁决要看的信息要上浮到 dashboard 表的「证据摘要」。 ## 实施记录 | round | implementer 摘要 | 关键文件 / 产物 | enable / 回退路径 | 派生建议 | | --- | --- | --- | --- | --- | ## Review 记录 | round | reviewer 结论 | 功能 / 精度 | 性能 / 指标引自分析报告 | 副作用 | 建议动作 | 派生建议 | | --- | --- | --- | --- | --- | --- | --- | ## 派生记录 | round | 触发现象 | 派生 Plan | 来源 | 说明 | | --- | --- | --- | --- | --- |注意实施 / 踩坑 / 验证的过程明细写在progress.md工作区共享状态文件跨 agent 共享沿用model-infer-optimize约定plan 文件的实施记录 / Review 记录只放 round 级结论摘要不复制过程流水。这保证了 dashboard 薄、plan 文件精、progress.md 全的三层粒度。7. 与仓库实践结合的落地要点在 cann-recipes-infer 仓库中实际使用该模板时有几个与仓库结构强相关的落地要点场景与 YAML 对应models/model/config/*.yaml的文件名即场景编码如 models/deepseek_r1/config/decode_r1_rank_128_128ep_a8w8c8_mtp.yaml 表示 decode / 128 卡 / 128 EP / W8A8C8 / 带 MTP选场景 选 YAML基线运行命令固定为bash infer.sh入口 source executor/scripts/set_env.sh 与 executor/scripts/function.sh把config/YAML_FILE_NAME作为配置调launch启动也可显式python infer.py --yaml_file_path config/scenario.yaml详见 scenario-setup.md。可复现基线固定提示词dataset/default_prompt.json或写死自定义 prompt、固定形状input_len / seq_len、batch、output_len、固定确定性解码do_sample: false或 temperature0并确认随机种子已在infer.py固定torch.manual_seed(42)torch.npu.manual_seed_all(42)。判定口径可机判LLM 用基线输出 token ids / 文本逐字对比 最低可用性门槛可读、不重复、非全零、不提前 EOSMoE / 量化模型允许有界误差并记录误差范围图像 / 视频生成固定 seed 和 step 数、比对关键指标或可视一致。不要只写看起来对。enable / 回退纪律每个 Plan 实施必须保留 enable 开关或写清回退方式仓库 YAML 中常见的enable_multi_streams、enable_superkernel、enable_profiler、exe_mode等开关即为此类设计的实例方便淘汰时干净隔离、不影响最终 profile。性能证据统一仓库中infer.py打印的 wall-clock 计时只能作为自验证参考最终收益判断一律以 profile-analyzer 产出的分析报告为准。8. 总结Dashboard 模板的三大设计原则从 plan-dashboard-template.md 全文可以提炼出该模板支撑多方向并行优化的三大设计原则状态与证据分离dashboard 只放关键信息 状态 裁决结构固定、与方向无关证据细节沉淀在analysis/source.md与plans/plan-id.md过程流水沉淀在progress.md三者各司其职、互不复制写者独占与上浮机制dashboard 只有主 agent 写subagent 只回摘要和路径、把裁决所需证据上浮到 dashboard 表从机制上杜绝多人写同一文件的冲突裁决有据可查Plan 状态只有待实现 / 通过 / 淘汰三种判通过 / 淘汰 / 派生 / 互斥叠加均有明确的规则集decision-rules.md支撑最终验收逐项对照、以同口径的 profile-analyzer 报告为准保证榨性能的过程可回放、结论可复现。对于在 CANN 平台上对 LLM 与多模态模型推理进行多方向探索式优化的团队而言这套 Dashboard 模板提供了把并行试探 逐步收敛落到文件层面管理的标准范式也是 Agent 在长周期优化任务中维持上下文一致性的关键基础设施。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考