昇腾 SuperKernel DCCI 选项调优协议证据门禁下的 Stage O 逐 SK/逐 Child 归因与联合修复【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion导读本文以 graph-autofusion 仓库.claude/skills/superkernel-auto-tune技能集中的 DCCI 调优协议文档为核心完整讲解 SuperKernel Stage O 阶段针对 DCCI 选项族dcci_disable_on_kernel、dcci_before_kernel_start、dcci_after_kernel_end的调优决策流程从首轮 disable-all 探测、clean A/B 门禁判定到劣化时的 diagnostic profiling 采集、逐 SK/逐 Child 归因再到唯一允许的 beforeafter 联合修复轮以及最终必须产出的报告清单。读完本文你将掌握一套无收益即拒绝、劣化才诊断、修复必须可复现归因的严格调优方法论并了解其与仓库中 sk_options_manager.cpp、sk_task_builder.cpp、artifact_contract.py 等实现之间的对应关系。一、协议定位DCCI 是什么、约束谁的 Stage ODCCI 是 SuperKernel 在 kernel 执行边界提供的一组与缓存控制相关的运行时选项。从 sk_options_manager.cpp 的默认选项工厂可以看出它由三个字符串列表型StringListOptOption选项组成均按内核函数名kernel funcName做正则匹配选项名类型语义从代码与协议推断dcci_disable_on_kernel字符串列表匹配命中的 kernel 关闭 DCCI 行为对应kDebugOptionDisableDccidcci_before_kernel_start字符串列表命中的 kernel 在其开始前插入 DCCI 操作dcci_after_kernel_end字符串列表命中的 kernel 在其结束后插入 DCCI 操作选项的实际生效逻辑位于 sk_task_builder.cpp 的BuildFuncTaskDebugOptions它综合 kernel 的capBits.disableDcci来自编译产物 SK_BIND 的声明与三个 option 的匹配结果组装出disableDcci/dcciBeforeKernelStart/dcciAfterKernelEnd/enableDcciAfterFunc等 debug option 位如果 option 声明了 disable 但编译产物能力位未声明会打出一条SK_BIND mismatch的告警——这正是协议要求exact 值必须由同一推理环境的 probe 接受的底层原因之一配置能被解析器接受不代表与当前编译产物语义一致。本协议只约束winner 的 Stage O阶段的 DCCI option 调优。在 winner-option-sweep.md 描述的 O 轮生命周期中Stage O 位于Sbest-SEED粗选胜出之后、Sbest-BASE全部 O 轮结算之前S0 - S1/S2/S3/S4 clean screening - Sbest-SEED - O0-INCUMBENT - O1/O2/... - Sbest-BASE一个关键前提是Stage O 冻结Sbest-BASE后Diagnostic profiling 不能作为 clean 性能证据。也就是说profiling 采集出来的数据只用于定位劣化原因绝不掺入任何性能结算样本。二、固定顺序四步走完 DCCI family 决策协议规定 DCCI 调优必须严格按固定顺序执行不允许跳跃或自由发挥第 1 步唯一首轮 trial 是 disable-all从不带任何 DCCI option 的五轮稳定O0-INCUMBENT出发只派生一个首轮 DCCI trial且仅设置dcci_disable_on_kernel: - .*注意两点硬约束dcci_before_kernel_start和dcci_after_kernel_end不作为独立的显式 O trial运行exact 值dcci_disable_on_kernel[.*]必须被同一推理环境的readytrueprobe 接受即 probe 返回的accepted_values中必须包含该 exact 值不得硬编码模型名、固定层数或预设某个网络独有算子。第 2 步与无 DCCI 的 O0 直接比较完成 correctness 校验并运行至少三个独立 clean process与不带任何 DCCI option 的 O0 直接比较。采纳条件为mean improvement严格为正协议明确不设固定百分比收益门槛通过 median-run direction、P90 和 stddev 门禁。只有三项全部满足才补足五轮并复核稳定性最终采纳dcci_disable_on_kernel[.*]。采纳后不再运行 before/after trial——disable-all 本身已经是完整候选没必要继续折腾。第 3 步无收益则整族拒绝若 disable-all 没有收益且落在噪声带内则拒绝整个 DCCI family保留 O0。此时同样不运行 before/after——不为制造候选而运行。若发生可重复的性能劣化才进入下述诊断分支。第 4 步功能失败不是性能劣化入口correctness failure、crash、hang 或 timeout不是性能劣化诊断入口。遇到这些情况按失败现场协议保存证据并直接拒绝 DCCI family不得用 profiling 掩盖功能失败。三、劣化诊断采集artifact_contract 与不可变 manifest当 disable-all 出现可重复劣化时进入条件诊断 profiling。这是 Stage O 中 DCCI 唯一被允许使用 profiling 的时机且对采集纪律要求极其严格。3.1 采集条件与身份链对同一个冻结 source、scope、workload、precision、TP、cache、warmup 和设备分别采集不带 DCCI option 的 fresh diagnostic profileO0 侧dcci_disable_on_kernel[.*]的 fresh diagnostic profiledisable-all 侧。在任一 profiling NPU 命令启动前必须为两侧各自的新空 profile root 执行python3 skill-dir/scripts/artifact_contract.py begin采集结束后由同一 collection producer采集侧生产者执行python3 skill-dir/scripts/artifact_contract.py finalize这两步保证了 manifest/session 是采集时生成的不可变身份链而不是运行后根据已有文件补造的。manifest 至少绑定exact execution config、workload、source revision、round/role、launcher command/PID/起止时间、ASCEND_PROF_SK_ON、预期 artifact以及 profile-ownedsk_meta归档位置。从 artifact_contract.py 的源码可以看到该机制的实现基础SCHEMA_VERSION 1.0、采集标记文件.collection-session.json、按 capture role 约束的ROLE_FILES例如candidate_profile角色必须同时包含kernel_details、task_time、trace_view以及 origin/updated graph、sk_fused_nodes、sk_scope_split、super_kernel等 SK 侧产物sk_prof则是可选的OPTIONAL_FILE_ROLES。这套 role→file 映射正是两侧都必须包含哪些文件的程序化定义。3.2 两侧必须包含的 artifact类别具体内容profiler 产物kernel_details.csv以及 collection manifestSK metadataprofiling 进程自己产生的完整 SK metadataorigin/updated graph、sk_fused_nodes.log、scope/split 和可用的 fusion failure evidenceSK 时间线完整的sk_prof_device.json等价地active runtime 实际产生的sk_prof_x.json文件名并记录ASCEND_PROF_SK_ON设置环境身份exact config、workload、source revision、命令、health、fingerprint 和 declared changeprofiling producer 必须在finalize前把自己产生的 profiler 文件、SK metadata 和可选的sk_prof归档至该侧 role root。两种常见操作被明确判定为无效只把结果目录复制到raw-run的 runner结束后从共享sk_meta/目录手工复制 metadata。这两者都不能证明 artifact 属于该 profile process不得作为 DCCI 归因输入。两侧完成后先对两份 manifest 执行artifact_contract.py validate-set再交给只读分析 Agent。3.3 采集阻断hard stop规则任一 session/manifest 缺失、无效或 artifact 不是 profile-process-owned →采集阻断保留原始日志和缺失路径停止逐 SK/child DCCI 归因从新的空 root 重新采集不得从raw-run、共享 metadata 或sk_prof事后重建/修补 manifest阻断情况下不得输出 child regex 或执行联合修复轮。3.4 child trace 不完整时的处理若super_kernel.log或等价证据出现buffer is full, stop dump the time of nodes说明该 child trace 不完整。此时可以保留 per-SK profiler 比较但必须先缩短采集窗口、重新取得完整的sk_prof才能做 child 归因。四、逐 SK 与逐 Child 归因诊断采集完成后分析遵循先 SK 后 child、先整体后局部的两级归因。4.1 逐 SK 对比对比两侧每一个fused SK而不是只看最慢的那一个跨进程连接禁止使用 raw SK/task/stream/node ID、生成 hash 或绝对时间戳必须使用结构 identitystructural identity和 graph occurrence这正对应 structural_association.py 这类结构关联工具的设计动机要求映射唯一双方至少有三个对齐的 post-warmup occurrence并使用P50/P90/MAD 动态阈值输出全部结果significantly slower、significantly faster 和 neutral SK 都要报告不能只报告最慢的一个主判据是SK interval/wallduration sum只作调度或 lane 工作量诊断的辅助证据。4.2 逐 Child 分解对每一个显著劣化的 SK使用完整且可归属的sk_prof与同进程 metadata按ordered child position分解逐 child 比较 wall span、max-lane、P90 和 MADduration sum只作次要证据只有 child wall 或 execution 通过显著性门禁才进入修复集合。4.3 生成 canonical op 并集对全部显著劣化 SK 的显著劣化 child取canonical op token 的稳定去重并集并报告每个 token来自哪些 SK/position完整 metadata symbol样本数、P50/P90/MAD、delta 和分类。协议特别强调不得从算子名称、邻接关系或仅 duration-sum 增长猜测修复目标——修复目标的唯一合法来源是逐 child 显著性证据。五、联合修复轮DCCI 唯一的双 pointer 例外5.1 生成窄 regex 并用 probe 验证对 child 并集生成能匹配完整 metadata symbol、包含 canonical op token 字面量的窄 regex。先用同一推理环境 probe 验证两个 option 的最终 exact list。修复配置必须为dcci_disable_on_kernel: - .* dcci_before_kernel_start: 全部显著劣化 child 的稳定去重 regex list dcci_after_kernel_end: 与 before 完全相同的 regex list5.2 为什么这是唯一例外普通 Stage O 轮遵循one-pointer规则一次只相对当前 incumbent 修改一个 RFC6901 JSON Pointer。而联合修复轮允许同时改变 before/after 两个 pointer——这是普通 one-pointer 规则下 DCCI family 的唯一例外。作为对价协议要求禁止before-only、after-only、逐 child 或排列组合 trial配置 diff 必须证明除这两个 pointer 外其余均与 disable-all 诊断配置一致必须证明相对 O0 只包含完整的 DCCI family 设置。5.3 门禁与结算联合修复轮同样要完成 correctness 和至少三个独立 clean process并直接与五轮稳定无 DCCI 的 O0比较。只有达到完整 option-trial 门禁才补足五轮并把 disable、before、after三项作为不可拆分的组合采纳。特别强调仅相对 disable-all 恢复、但仍不优于 O0不能采纳若联合修复仍无收益、劣化、失败或不正确 → 拒绝整个 DCCI family 并恢复 O0停止继续扩展 child list后续只有新的用户要求或新的独立证据才能创建另一轮 DCCI 调优。关于不设固定百分比收益门槛这一判定可以在 analyze_performance.py 中找到实现侧印证OPTION_TRIAL_MIN_IMPROVEMENT_PCT 0.0即只要严格为正0%即满足最低门槛其余交给 median-run direction、P90、stddev 与 spread 门禁裁决。该脚本在 winner 协议中的典型调用方式为python3 runtime-skill-dir/scripts/analyze_performance.py \ --baseline experiments/Sbest/O0-INCUMBENT/CLEAN \ --candidate O1experiments/Sbest/O1/CLEAN \ --option-trial --warmup 8 \ --json-out experiments/Sbest/O1/option-trial-summary.json六、必须报告DCCI family 的完整证据清单DCCI family 的中文报告和机器结果至少包含以下六类内容缺一不可汇总指标O0、disable-all、联合修复各自的 clean run 数、worst-rank mean、median-run、P50、P90、stddev、spread、门禁与 incumbent 变化采集证据两份 diagnostic collection 的路径和 fingerprint以及kernel_details.csv、SK meta、sk_prof的完整性状态逐 SK 统计全量逐 SK 对比统计、显著劣化 SK 表和阈值逐 child 统计每个劣化 SK 的 child timing 表、最终 child 并集及 symbol-to-regex 映射配置证据exact disable/before/after option 设置、probe evidence 和 config diff结论联合修复是否采纳未采纳时说明 SK/child 分析结论和未能转化为端到端收益的事实。证据边界相关性不等于因果协议最后给出了一条重要的认知红线不得把相关性写成 DCCI/cache 根因。只有完整联合修复相对 O0 的 clean A/B 能证明该 option 组合是否值得采纳它仍不能单独证明某个 child 或 before/after 位置的机制因果。换言之即使联合修复被采纳其报告也应如实说明这是组合级证据而非某个正则位点的机制级归因。七、与相邻协议的关系DCCI 调优不是孤立的。在技能集内部它与以下文档/实现协同构成完整的 Stage O 证据链winner-option-sweep.md定义 O 轮生命周期、冻结superkernel-winner-option-matrix-v1矩阵、O0 五轮稳定基线要求worst-rank mean spread ≤ 5%以及普通 option 的逐 pointer 规则DCCI 条件分支要求完整执行 dcci-option-tuning.mdcontroller-legacy-contract.md承载 Stage O 的硬证据门禁、option 规则与 profiling 规则failure-scene-reporting.mdcorrectness failure、crash、hang、timeout 等失败现场的证据保存协议analyze_performance.py实现 clean 样本汇总、spread 门禁与 option-trial 对比artifact_contract.py实现诊断采集侧的 role→file 契约与不可变 manifestsuper_kernel_sub_op_infos.pyJIT 侧解析子算子是否声明call_dcci_disable_on_kernel/ before / after是 option 与子算子语义挂钩的实现侧入口。实际运行时配置可参考 example02_sk_options/main-dav-2201.py在torch.compile(..., backendnpugraph_ex)的super_kernel_optimize_options中同时给出三个 DCCI 选项示例为全量[.*]并可与auto_op_parallel、early_start、aggressive_opt_strategies等其他 O 矩阵项并列配置super_kernel_debug_options中的debug_sync_all、debug_op_exec_trace、debug_cross_core_sync_check、debug_per_op_max_core_num则属于调试选项按协议Debug options 永不进入 O 矩阵或 clean 样本。结语DCCI 调优协议的全部条款可以浓缩为一句话能用 clean 端到端实测解决的绝不动用 profiling动用 profiling 的必须同时满足采集不可变、归因可追溯、修复可复现、结论不越界。这套方法把 DCCI family 从三个可随意排列组合的开关收敛为一个 disable-all 首轮 至多一次联合修复的最小实验空间既保证了候选质量也守住了性能结论的证据边界。对于需要在昇腾 SuperKernel 场景下自行开展 Stage O 选项调优的工程师本文给出的流程、命令与报告清单可以直接作为执行 checklist 使用。【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考