企业官网建设流程全解析

SuperKernel Stage O 选项调优：graph-autofusion 自动调优流程中从 Sbest-SEED 到 Sbest-BASE 的选项冻结实战

【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾（Ascend）芯片的轻量级、解耦式组件集合，旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件，未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion

本文以 graph-autofusion 仓库中的 Stage O 调优技能定义 SKILL.md 为主体，完整还原 SuperKernel 自动调优流水线中“winner 全局编译选项探索”这一阶段的执行流程：如何校验阶段任务、冻结选项矩阵、建立五轮稳定基准（O0-INCUMBENT）、逐项单选项试验与回滚，以及 DCCI（Data Cache 相关控制选项）的条件诊断分支。读完本文，你可以掌握 Stage O 的完整门禁规则、命令行调用方式，以及它如何在源码层面被sk_options_manager等组件实际承接。

一、Stage O 在自动调优流水线中的位置

Stage O（Option Tuning）是 SuperKernel 自动调优会话中一个承上启下的阶段。按 winner-option-sweep.md 给出的生命周期，它在 S 候选粗选之后、普通 winner profiling（Stage B）之前执行：

S0 -> S1/S2/S3/S4 clean screening -> Sbest-SEED -> O0-INCUMBENT -> O1/O2/... -> Sbest-BASE -> [optional isolated multistream branch -> derived-family BASE] -> [Sbest-SMAP] -> whole_scope_clean_validation optional only when explicitly requested by the user or frozen experiment plan: Sbest-P* -> Sbest-FINAL

其中Sbest-SEED是粗选胜出的脚本，Sbest-BASE是全部 O 轮结算后保留下来的脚本和选项组合。controller-legacy-contract.md 的 “Stage O: Sweep Winner Options Before Profiling” 一节进一步强调：O 轮必须在收集 winner profile 之前完成Sbest-SEED -> O0/O* -> Sbest-BASE的探索，且“缺少 profiling 假设”永远不是跳过某个普通选项试验的合法理由——普通选项不等待 profiling 假设，直接以端到端 clean 性能实测裁决。

从技能目录结构看，Stage O 是一个受控的独立阶段入口：phase.json 声明了该阶段的元信息：

{ "schema_version": "superkernel-phase-manifest-v1", "phase": "stage_o_option_tuning", "agent_id": "sk-stage-o-option-tuning", "skill": "superkernel-stage-o-option-tuning", "runtime_tools": [ "analyze_performance.py", "experiment_ledger.py", "render_round_report.py" ] }

runtime_tools指向的三个分析工具（性能对比、实验台账、轮次报告渲染）实际存放在公共运行时脚本目录 superkernel-runtime-common/scripts 下，例如 analyze_performance.py。

二、控制面交接：只接受冻结的输入，只输出冻结的结果

SKILL.md 对 Stage O 的输入边界规定非常严格：

• 输入：只接受stage_o_option_tuning任务（agent id 为sk-stage-o-option-tuning），且必须携带一个已冻结的Sbest-SEED、active wrapper 已接受的选项值（accepted option values）、以及 S0 边界内的干净产物（S0-bound clean artifacts）。
• 执行约束：本阶段只应在被superkernel-auto-tune控制器以sk-stage-o-option-tuning身份委托时运行；必须阅读控制器的 Stage O 契约及 winner-option-sweep.md、dcci-option-tuning.md 两份参考协议。
• 交接输出：返回结算完整的选项矩阵、所有证据/失败现场（failure scenes）、保留的精确选项映射（exact option maps）、Sbest-BASE身份、台账（ledger）路径，以及中文的下一步指引。在控制器封存该结果之前，不得对 BASE 做 profiling，也不得启动任何可选分支工作。

这种“只进冻结输入、只出冻结结果”的设计，保证了 Stage O 的产出（选项组合）在后继的 P/FINAL 源码区间分支中保持不可变——controller-legacy-contract.md 明确要求：冻结进Sbest-BASE的选项映射在整个 P/FINAL 期间 immutable，这些轮次不得再探测、增删、替换、收窄、放宽或组合选项值。

执行入口：先校验再下发工具

SKILL.md 规定执行的第一步是运行阶段入口脚本：

python3 scripts/execute_phase.py --task <dispatch-task.json>

该入口 execute_phase.py 是一个极简包装器：

from pathlib import Path import sys sys.path.insert( 0, str(Path(__file__).resolve().parents[2] / "superkernel-auto-tune" / "scripts") ) from phase_entrypoint import run raise SystemExit(run(manifest=Path(__file__).resolve().parents[1] / "phase.json"))

它加载上一节的phase.json，交给 phase_entrypoint.py 统一处理。从源码结构看，phase_entrypoint.run的职责是“Validate one dispatched phase task and emit its executable tool plan”：它校验 manifest 的schema_version必须为superkernel-phase-manifest-v1、检查phase/agent_id/skill/runtime_tools四个必填字段，并逐一确认runtime_tools中声明的每个脚本在superkernel-runtime-common/scripts目录下真实存在，任一缺失即抛错。也就是说，execute_phase.py先验证当前 Stage O 派发任务合法，再“发出”选项分析、台账和逐轮报告三类工具的可用执行计划——这正是 SKILL.md 中“validates the current Stage O task and emits option, ledger, and per-round report tools”一句的底层实现。

三、冻结选项矩阵：O1 启动前的强制动作

在 O1 开始前，必须冻结superkernel-winner-option-matrix-v1选项矩阵。winner-option-sweep.md 规定矩阵至少覆盖以下类别：

矩阵每一项必须包含id、category、option、value、配置中的 RFC6901 JSON Pointer、原值、probe evidence、风险等级和最终状态。最终状态只能是accepted、rejected、failed、blocked、skipped五者之一；blocked/skipped必须给出中文原因和证据——“profiling 没有直接证据”不是合法原因。合法的 blocker 包括：wrapper 未接受 exact value、缺少运行前提、用户未授权对应风险、预算已明确耗尽。

另外有两条明确的候选来源纪律：不得把check_environment.py内置样例当成网络专用候选全集；条件联合修复的窄正则必须来自 fresh 劣化 child 证据和当前编译产物的真实 symbol inventory，通过--option-values-json交给同一推理环境中的 probe 验证，不得硬编码模型名、固定层数或预设某个网络独有算子。

这些选项并非纸面概念，它们在 SuperKernel 的 AOT 选项管理器中有真实注册。sk_options_manager.cpp 中可以看到 DCCI 三选项均以StringListOptOption注册、auto_op_parallel以数值选项注册（默认0，范围0~1）：

{aclskOptionType::DCCI_DISABLE_ON_KERNEL, []() -> std::unique_ptr<OptOptionBase> { return std::make_unique<StringListOptOption>("dcci_disable_on_kernel", aclskOptionType::DCCI_DISABLE_ON_KERNEL); }}, // ... {aclskOptionType::AUTO_OP_PARALLEL, []() -> std::unique_ptr<OptOptionBase> { return std::make_unique<NumberOptOption>("auto_op_parallel", aclskOptionType::AUTO_OP_PARALLEL, 0, 0, 1); }}, {aclskOptionType::DCCI_BEFORE_KERNEL_START, []() -> std::unique_ptr<OptOptionBase> { return std::make_unique<StringListOptOption>("dcci_before_kernel_start", aclskOptionType::DCCI_BEFORE_KERNEL_START); }}, // ... {aclskOptionType::DCCI_AFTER_KERNEL_END, []() -> std::unique_ptr<OptOptionBase> { return std::make_unique<StringListOptOption>("dcci_after_kernel_end", aclskOptionType::DCCI_AFTER_KERNEL_END); }},

而每个选项值如何真正作用到 kernel 侧，从 sk_common.h 的TaskInfo结构可以看到 host 端把选项压缩为位掩码下发：bit1对应dcci_disable_on_kernel，bit4对应dcci_before_kernel_start，bit8对应dcci_after_kernel_end，bit32的enable_dcci_after_func由 host 端根据 disableDcci 和 afterKernelEnd 综合计算，kernel 侧只检查该 bit 即可，无需组合判断。这与 Stage O “先 disable-all 探测、必要时再补 before/after 正则”的策略在实现上完全吻合。

实际网络中的选项写法可参考 AOT 示例 main-dav-3510.py，它展示了通过torch.compile的super_kernel_optimize_options一次性传入全部选项的形态：

options={ "static_kernel_compile": True, "super_kernel_optimize": True, "super_kernel_optimize_options": { "auto_op_parallel": 0, "dcci_before_kernel_start": [".*"], "dcci_after_kernel_end": [".*"], "dcci_disable_on_kernel": [".*"], "early_start": 1, "aggressive_opt_strategies": { "value_breaker_bypass": 0b10, "task_breaker_bypass": 0b00, }, }, ... }

Stage O 的每个 matrix trial 本质上就是对该配置中单个 RFC6901 pointer 指向的值做一次性修改，而选项本身必须被这个选项注册表接受（exact value probe）。

四、O0 基准与逐项试验：一个 pointer、五项门禁、即时回滚

O0-INCUMBENT：五轮独立 clean 进程

从Sbest-SEED复制一份不带任何新增选项的O0-INCUMBENT，运行完整 correctness 和五个独立 clean process，并要求 worst-rank mean spread 不超过 5%。注意筛选阶段（S 轮）的三次样本不得代替 O0——这是协议中明确的分界线。

逐项试验规则

按冻结矩阵顺序处理每个 option/value，规则包括：

1. 普通 O 轮只相对当前 incumbent 修改一个 RFC6901 Pointer；不得改变 scope、源码、workload、precision、TP、cache、warmup、设备或其他运行控制。DCCI 联合修复是唯一例外（见下节）。
2. 每个 clean trial 先执行完整推理和 correctness，再运行至少三个独立 clean process；profiler、SK metadata、sk_prof、trace、debug sync 和 calibration 必须全部关闭。
3. 使用性能分析器对比 trial 与当前五次稳定 incumbent，controller-legacy-contract.md 给出的标准调用为：

python3 <runtime-skill-dir>/scripts/analyze_performance.py \ --baseline experiments/Sbest/O0-INCUMBENT/CLEAN \ --candidate O1=experiments/Sbest/O1/CLEAN \ --option-trial --warmup 8 \ --json-out experiments/Sbest/O1/option-trial-summary.json

4. 采纳门禁：均值增量必须严格为正（不设固定百分比收益门槛）、median-run 方向为正、P90 和标准差不劣化，才标记accepted。
5. accepted trial 把该 exact value 累积进 incumbent，补足到恰好五个 clean process，并复核 spread 不超过 5% 后，才能作为下一 O 轮的 baseline；未通过稳定性复核则撤销接受并标记failed。
6. rejected/failed trial立即恢复上一个 incumbent，保留日志、配置 diff、正确性、超时/崩溃和性能证据，不得继续携带该值。若failed不是实验启动前的环境原因，必须先按 failure-scene-reporting.md 在 winner 的EXPERIMENT_REPORT.md对应 O trial/attempt 小节记录失败现场，后续 O 轮不能覆盖它。
7. 全部矩阵项结算后，把最终 incumbent 的源码、scope、配置、选项、command 和五类 fingerprint 冻结为Sbest-BASE。即使没有任何选项获益，Sbest-BASE与Sbest-SEED等价，但仍需记录完整 O 矩阵。

关于失败现场，failure-scene-reporting.md 区分了环境类例外与非环境类失败：CANN 环境未加载、torch_npuruntime 无法加载、设备不受支持、option probe 未执行、wrapper 拒绝尚未启动的 exact value 等属于实验启动前的环境 blocker，只写入 environment probe 和父级报告；而一旦实验命令已启动，编译、执行、正确性、超时、hang、device fault 等一切失败都必须先封存现场（原始 stdout/stderr/plog、fingerprint、最后通过的 gate）再回退重试，且每个失败 attempt 都有八项必填内容（身份与阶段、冻结调用、可观察失败、现场 artifact、门禁进度、初步判断、控制与回退、后续定位入口）。

冒险选项的安全边界

• aggressive_opt_strategies的每个 accepted value 必须在独立进程中运行，设置明确 timeout，在 hang、device error、crash 或 correctness failure 后停止该 trial、回退 incumbent，再按 failure-isolation 流程读取 fresh plog；失败不能据此跳过矩阵中其他独立 option/value。
• event_breaker_bypass只有在 event 语义已审查且用户允许该风险时才运行，否则以“风险授权 blocker”结算。
• early_start=1缺少配套 operator-side adaptation 时结算为blocked，不能把“wrapper 接受”误写成“运行语义已满足”。
• Debug options永不进入O 矩阵或 clean 样本。

五、DCCI 条件分支：disable-all 先行，联合修复是唯一例外

DCCI 是 Stage O 中规则最特殊的选项 family，完整协议见 dcci-option-tuning.md。其核心逻辑可概括为“固定顺序 + 条件诊断 + 一次性联合修复”。

固定顺序

1. 从不带 DCCI 选项的五轮稳定O0-INCUMBENT派生唯一首轮 DCCI trial，仅设置：

dcci_disable_on_kernel: - .*

dcci_before_kernel_start和dcci_after_kernel_end不作为独立显式 O trial；exact[".*"]必须由同一推理环境的ready=trueprobe 接受。

2. 完成 correctness 和至少三个独立 clean process，与不带任何 DCCI 选项的 O0 直接比较。若 mean improvement 严格为正且通过 median-run、P90、stddev 门禁，则补足五轮、复核稳定性后采纳dcci_disable_on_kernel=[".*"]，不再运行 before/after trial。
3. 若 disable-all 无收益且落在噪声带内，拒绝整个 DCCI family，保留 O0，不为制造候选而运行 before/after。
4. correctness failure、crash、hang 或 timeout不是性能劣化诊断入口：按失败现场协议保存证据并拒绝 DCCI family，不得用 profiling 掩盖功能失败。

劣化诊断采集：paired manifest 契约

只有当 disable-all 出现可重复的性能劣化时，才进入诊断分支。此时需要为 O0 和 disable-all 各采集一份 fresh diagnostic profile（profiler 的kernel_details.csv、profile 进程自己产生的完整 SK metadata 包括 origin/updated graph 与sk_fused_nodes.log、完整的sk_prof_<device>.json及ASCEND_PROF_SK_ON设置记录、exact config/workload/source revision/fingerprint）。

采集的关键约束是“manifest 是采集时生成的不可变身份链”：在任一 profiling NPU 命令启动前，必须为两侧各自的新空 profile root 执行artifact_contract.py begin，采集结束后由同一 collection producer 执行finalize；两侧完成后先对两份 manifest 执行artifact_contract.py validate-set，再交给只读分析 Agent。manifest/session 至少绑定 exact execution config、workload、source revision、round/role、launcher command/PID/起止时间、预期 artifact 和 profile-ownedsk_meta归档位置，不能在运行后根据已有文件补造。只把结果目录复制到raw-run、或事后从共享sk_meta/手工复制 metadata，均不能证明 artifact 属于该 profile process，不得作为 DCCI 归因输入。任何 session/manifest 缺失或无效都属于采集阻断：保留原始日志、停止逐 SK/child 归因、从新的空 root 重新采集，且不得在该情况下输出 child regex 或执行联合修复轮。若super_kernel.log出现buffer is full, stop dump the time of nodes，该 child trace 不完整，需缩短采集窗口重取完整sk_prof后才能做 child 归因。

逐 SK 与逐 Child 归因

1. 跨进程对比每一个 fused SK 时必须使用结构 identity 和 graph occurrence 对齐，禁止用 raw SK/task/stream/node ID、生成 hash 或绝对时间戳直接连接；要求映射唯一、双方至少三个对齐的 post-warmup occurrence，并使用 P50/P90/MAD 动态阈值。
2. 输出所有 significantly slower、significantly faster 和 neutral 的 SK，不能只报告最慢一个；SK interval/wall 是主判据，duration sum 只作调度或 lane 工作量诊断。
3. 对每个显著劣化 SK，用完整且可归属的sk_prof按 ordered child position 分解，逐 child 比较 wall span、max-lane、P90 和 MAD；child wall 或 execution 通过显著性门禁才能进入修复集合。
4. 对全部显著劣化 SK 的显著劣化 child 取 canonical op token 的稳定去重并集；不得从算子名称、邻接关系或仅 duration-sum 增长猜测修复目标。

联合修复轮：Stage O 唯一的两 pointer 例外

对 child 并集生成能匹配完整 metadata symbol、包含 canonical op token 字面量的窄 regex，并经同一推理环境 probe 验证两个选项的最终 exact list 后，修复配置必须为：

dcci_disable_on_kernel: - .* dcci_before_kernel_start: <全部显著劣化 child 的稳定去重 regex list> dcci_after_kernel_end: <与 before 完全相同的 regex list>

这是 DCCI family 的一个联合修复 trial，允许同时改变 before/after 两个 RFC6901 Pointer——它是 Stage O one-pointer 规则的唯一例外；不执行 before-only、after-only、逐 child 或排列组合 trial。配置 diff 必须证明除这两个 pointer 外均与 disable-all 诊断配置一致。联合修复完成 correctness 和至少三个 clean process 后直接与五轮稳定无 DCCI O0 比较：只有达到完整 option-trial 门禁，才补足五轮并把 disable、before、after 三项作为不可拆分组合采纳；仅相对 disable-all 恢复、但仍不优于 O0，不能采纳。若联合修复仍无收益、劣化、失败或不正确，拒绝整个 DCCI family 并恢复 O0，停止继续扩展 child list——这也解释了 SKILL.md 中“DCCI begins only with disable-all; before/after child trials are illegal. A disable-all regression requires paired manifests and read-only analysis”这句话的完整含义。

报告层面，dcci-option-tuning.md 还规定 DCCI family 的中文报告至少包含：三轮（O0/disable-all/联合修复）的 clean run 数、worst-rank mean、median-run、P50、P90、stddev、spread、门禁与 incumbent 变化；两份 diagnostic collection 的路径与 fingerprint；全量逐 SK 对比统计与显著劣化 SK 表；每个劣化 SK 的 child timing 表、最终 child 并集及 symbol-to-regex 映射；exact 选项设置与 config diff。并且不得把相关性写成 DCCI/cache 根因——只有完整联合修复相对 O0 的 clean A/B 能证明该选项组合是否值得采纳。

六、与 P/FINAL 的边界及收尾交接

O 轮是 winner 全局选项探索，因此不需要某个 fused SK 的直接 scalar/cache、Cube/Vector 或 breaker 诊断证据；它仍需 accepted value、correctness 和 clean 增量收益三要素。当用户或冻结实验计划明确请求可选 P 分支时，P 仅裁剪 BASE 分析已证明的 neutral/regressed exact range，且Sbest-BASE选项映射在 P/FINAL 中保持冻结，不得再次调优；P 必须使用 fresh profile 与独立分析 Agent，O 轮收益不能替代某个局部 range 的直接性能与源码映射证据。

收尾时，Stage O 必须向控制器交出 SKILL.md 所要求的完整交接物：结算完整的选项矩阵、所有证据与失败现场、保留的精确选项映射、Sbest-BASE身份、ledger 路径，以及中文的下一步指引。只有在控制器封存该结果之后，才允许对 BASE 启动 profiling 或任何可选工作——这保证了整个自动调优流水线上每一轮的证据链都可审计、不可事后补写，也让 Stage O 的产出成为后续 profiling、源码映射与整体验证阶段唯一可信的选项基线。

【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾（Ascend）芯片的轻量级、解耦式组件集合，旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件，未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion