CANN Graph-Autofusion 超核（SuperKernel）Layer 与 Pipeline 分析指南：从证据采集到 winner 生命周期决策

CANN Graph-Autofusion 超核SuperKernelLayer 与 Pipeline 分析指南从证据采集到 winner 生命周期决策【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion导读本文围绕 CANN graph-autofusion 开源仓库中superkernel-auto-tune技能体系下的 Layer/Fusion/Pipeline 分析参考文档展开系统讲解如何以证据驱动的方式重建网络结构、盘点每一个生成的超核SuperKernel简称 SK、解读融合碎片化、逐 SK 分类性能、分析 Cube/Vector 调度与 DCCI 假设最终把结论喂给 winner 生命周期。你将掌握一套结构性元数据缩小假设空间、实测 profiling 决定 keep/prune的完整分析方法论以及配套的analyze_sk_meta.py等脚本的实战用法。1. 分析目标与五类必答问题Layer 与 Pipeline 分析的核心原则是不要只依赖聚合延迟或子算子深度来下结论。结构性元数据scope、stream、op 序列、层归属用于缩小假设空间而测量到的 profiling 数据才决定保留keep还是裁剪prune。在开始分析前需要回答以下五类问题重复层每个重复 layer 中实际执行了哪些算子和流streamSK 归属每一个生成的 SK 属于哪些子算子、区间range与流断点位置scope、资源、依赖、runtime-task 和不支持算子unsupported-op的 break 分别发生在哪里融合收益哪些被融合的源区间改善了、保持中性、还是发生了回退regress并行性存续基线baseline的 Cube/Vector 并行在 SK 内部是否仍然保留2. 必需的证据清单与采集纪律在相同 workload 控制下必须收集以下证据对应参考文档 Required Evidence 章节证据项用途SK-off 的kernel_details.csv模型清单inventory与源区间基线SK-on 的kernel_details.csv仅用于选中 winner 及其 BASE、以及明确请求的 P/FINAL 轮candidate 进程自有的sk_meta该 profiling 进程自己产生的融合元数据baseline_profile与candidate_profile两份 collection manifest证明两侧采集的不可变身份链可选sk_prof_device_deviceId.json子算子调度child scheduling诊断source-confirmed task/range map源码确认的任务区间映射active wrapper option probe确认 wrapper 接受的精确 option 值一个重要的纪律Profiler、元数据、child trace 与 debug 产物都只是诊断用途做 clean timing干净计时时必须关闭它们否则会污染性能样本。3. Candidate 生命周期从 Stage A 到 winner profilingStage A 主要依靠源码加单个 SK-off 诊断 profile重建模型然后以正确性与 clean timing 筛选 S 个候选S1/S2/S3/S4 等筛选轮这一阶段不做逐 SK 的融合映射。只有选中一个 winner 后对 winner 的每个 profiling round 才按如下顺序执行执行与正确性通过execution and correctness pass采集 candidate 诊断 profile 与完整元数据并打 fingerprint两份 collection manifest 全部校验通过由全新的只读分析 Agent将每个可靠映射的 SK 与 SK-off 基线分类只有分析结果驱动 BASE 动作与明确请求的 P/FINAL 动作。非 winner 的 S 候选在进入该生命周期前就停止。值得强调的是deep_fusion_reproducible、child count、深度直方图与碎片化程度都只是描述性拓扑字段它们永远不会决定是否运行 profiling、也永远不会决定某个 range 是否有收益。4. 重建每一个 Layer重建 layer 时应使用 sibling 性能分析器的schema 1.2 profile-vs-baseline 工作流对应 profiling-fusion-analysis.md不要使用 partial-profile 或 inventory-only 的兼容 CLI 模式。一个完整的模型清单inventory必须包含从源码/config 确认的期望重复层数量每一层的有序operator_sequence、task range、op 状态、core family、时长分布与 stream ID每层 Cube/Vector/MIX 数量与重叠情况重复层之外的 embedding、final norm、LM head、sampling、通信与 helper 工作静态内核static-kernel占比与显式 unknown/non-static 行。当layer_analysis.status为 partial/unavailable 时需要提供源码确认的映射例如{ task_ranges: [ {layer: 0, model_id: 48, start_task_id: 3, end_task_id: 39}, {layer: 1, model_id: 48, start_task_id: 40, end_task_id: 76} ] }仓库中 pipeline fixture 的 layer-map.json 给出了这种映射的样例layer 0model_id 48start_task_id 10end_task_id 99。注意缺失的 layer 名称是证据缺口evidence gap不是零工作量层不能把没有记录当成没有工作。5. 盘点每一个 SKanalyze_sk_meta 实战SK 元数据盘点由 analyze_sk_meta.py 完成。参考文档给出的调用方式为python3 runtime-skill-dir/scripts/analyze_sk_meta.py \ experiments/S3/S3-BASE/compat/sk_meta \ --json-out experiments/S3/S3-BASE/sk-meta-summary.json \ --round-name S3-BASE \ --effective-min-child-nodes 1 \ --round-report-out experiments/S3/S3-BASE/round-report.json该脚本会递归扫描sk_fused_nodes.log、sk_fusion_fail_reasons.log、sk_scope_split.log三类日志见脚本中的LOG_NAMES解析出每个 SK 的model ID、生成函数名、源码 scope、layer/segment 与精确边界函数名形如sk_id_scope_start_op_end_op声明/解析出的 child count 与count_reliable声明数量与解析数量不一致时以解析值为准完整有序的 child 算子列表与 kernel/core 类型task/block 数、stream ID、MIX 切分与isScheModeOncontrol-core 调度模式证据源片段、break 原因以及 compat/verify 出现次数。同时脚本按 layer 汇总SK 数量、child-count 的 min/P50/P90/max/直方图、单 child SK 数量、scope 碎片、stream、breaks、断连disconnect指标与控制核control-core状态。命令行参数方面--effective-min-child-nodes默认值为 5但它只是描述性的effective/shallow分桶阈值从不参与过滤 profiling、replay、scope 候选或性能分析脚本注释中明确注明--round-name还用于推断scope_kindS1/S1-auto/automatic-aot 归一化为automatic_aot其余为manual。重要约束这些结构性字段不能自动转化为 keep/prune 决策。脚本输出的performance_action一律是pending_profiling_analysis必须等待 fresh profiling 分析。6. 解读融合碎片化Fragmentation对反复出现的sk_scope_split.log快照应按 source、scope、trigger、reason 去重同时保留 raw、duplicate、unique 三组计数。脚本中的_disconnect_metrics会计算fused_groups_per_100_child_nodes作为碎片化指标——但它度量的是碎片化程度而不是融合覆盖率。比较每一层时聚合均值可能掩盖首层/末层的异常必须使用源码边界与 profiler occurrence 映射后再行动。常见的 break 阶段有三类scope 放置问题意外落在范围外、多余的 scope 名称、资源边界option 匹配存在匹配的直接原因且 wrapper 接受精确值算子适配问题unsupported/custom/non-static/runtime-task 工作。_build_break_action_plan还会按类别给出行动优先级scope 配置类NOT_IN_SCOPE、IN_UNFUSIBLE_SCOPE、EXCEED_SCOPE_MAX优先修正 marker 与 scope 名称资源类RESOURCE_INSUFFICIENT在依赖/资源边界切分依赖类deadlock、external depend、isolated event保留依赖顺序只在 owner 确认后测试匹配的 aggressive option算子类OP_UNSUPPORT、SIMT_OP_UNSUPPORT先移出 scope、留待下一阶段适配。核心原则是激进的 option 不能替代依赖证明。7. 逐 SK 性能分类与收益判定性能分析由独立的只读分析 Agent 按 superkernel-fusion-performance-analysis 执行主对比公式为baseline interval P50 P50(max(child end) - min(child start)) candidate SK P50 P50(SK duration) improvement baseline interval P50 - candidate SK P50duration sum P50 只是次级指标因为多流 child 的时长相互重叠直接求和会重复计算并夸大融合前耗时。分析还使用 P90、occurrence 数、MAD 动态阈值、映射置信度与 fingerprint 来支撑结论。分类与动作对照如下对应 profiling-fusion-analysis.md 第 6 节classificationaction语义beneficialkeepinterval 改善越过动态 MAD 阈值neutralprune数据充分但没有明确收益regressedpruneSK interval 明确劣化insufficient_evidencereprofile或block映射、样本、fingerprint 或 artifact 不足不改 scope每个 range 至少需要三个可靠 occurrence相对动态噪声带至少 3%绝对变化至少 1us。每个人类可读性能表必须包含interval P50、duration sum P50、SK P50、MAD 阈值、分类/动作、映射置信度、分析 Agent 与条件证据绑定。8. Cube/Vector 调度分析基线 profiling 识别跨流 C/V 重叠candidate SK 的 child trace 必须包含完整的 CUBE 与 VECTOR 事件且 stream ID 可靠才能声称串行化或重叠保留。参考文档给出如下判定表证据解释下一步实验无基线 C/V 重叠没有需要保留的并行性继续按性能驱动的 scope 搜索有基线重叠且 SK 保持并行调度保留仅当 interval 有收益才 keep有基线重叠但 SK 串行化直接调度假设若被接受跑一次单 rangeauto_op_parallel1诊断child trace 不完整/歧义证据不足Reprofile不改 scopeMIX/Cube 或同资源竞争资源假设一次精确边界实验手动重排manual reordering只是兜底方案必须依次完成证明 producer/consumer、event、通信、cache mutation 与 barrier 边只重排相互独立的工作保留确定性 scope 与 stream 语义归档源码 diff 与生成的任务顺序重复正确性、fresh profile-vs-baseline 分析与 FINAL 交互检查。9. DCCI 假设的成立条件与边界DCCIData Cache/一致性相关 option family只有在以下条件全部满足时才是一个假设该 range 是 neutral/regressed存在直接的 scalar/cache profiler 证据显式 config/environment 提供了 DCCI 状态有一个窄的、精确接受的 value 匹配目标 child symbol。Stage O 结束后DCCI 与所有其他 Option 值保持冻结。P/FINAL 可以保留 DCCI 作为诊断假设但不得安排 DCCI 或其他 Option 实验。冲突或未知的 DCCI 状态不会改变 interval 分类。完整的 Stage O 调优协议见 dcci-option-tuning.md从五轮稳定O0-INCUMBENT派生唯一首轮 trialdcci_disable_on_kernel[.*]有收益则采纳无收益拒绝整个 family只有可重复劣化时才做 disable-all 与 O0 的 paired diagnostic profile再对显著劣化 child 生成同一组 before/after 窄正则做一次联合修复 trial且必须直接优于 O0 才采纳。10. 喂给 Winner 生命周期只有 clean timing 的 winner 才进入默认生命周期先完成完整的 BASE 与必需的 SMAP 结算再执行whole_scope_clean_validation。P/FINAL是可选的源码范围分支只在用户或冻结实验计划明确请求时启动BASE 或 SMAP 完成本身绝不会自动启动它。BASE保留 beneficial 的 SK并把精确的 neutral/regressed range 提议给 P。P只移除不重叠的精确源码范围同时保持执行正确绝不改变任何 Option。批量 P 要求所有范围在同一source_file且每对 half-open 区间机器可证明互不重叠。FINAL组合保留的 range 后 fresh profiling检查范围间交互全部beneficial/keep才允许 clean timing。S1 automatic AOT在匹配的条件 fingerprint 下人工复测前保留所有提议结果。一个 absent、invalid、no_gain、blocked或failed的可选分支会保留 incumbent现任方案并且不阻塞 whole-scope 验证。所有路径、内容 fingerprint、分析 Agent ID、声明变更与决策都要写入 schema 2 账本experiment ledgerlayer/pipeline 解读与 blocker 一律用中文撰写。11. 方法论的底层逻辑从源码到分析的证据链整个分析体系贯穿一条证据链源码 scope 语义 - SK 元数据sk_meta- profilingkernel_details.csv/task_time.csv/trace_view.json- 分类动作keep/prune/reprofile/block- schema 账本。从源码结构看auto_tune_session.py 扮演唯一控制器角色冻结 session、为每个待处理 phase 派发全新的 host-native 通用子 Agent、校验结构化 handoff并始终到达 Final 报告步骤。各逻辑 workersk-intake-preparation、sk-s0-baseline、sk-stage-a-scope-selection、sk-stage-o-option-tuning、sk-base-profile-source-mapping、sk-optional-experiments、sk-final-e2e-report之间不得越权一个子 Agent 只拥有当前 phase且必须先运行scripts/execute_phase.py --task dispatch-task.json通过校验才能认领 handoff。也就是说本文描述的 layer/pipeline 分析并不是一次性的性能报告而是被编排进一个可恢复、可验证、证据门控的调优流水线中的关键环节——结构性元数据负责看清网络实测 profiling 负责决定取舍二者缺一不可。延伸阅读分析参考全文layer-and-pipeline-analysis.mdProfiling 采集与分类协议profiling-fusion-analysis.md只读性能分析技能superkernel-fusion-performance-analysisWinner 选项探索协议winner-option-sweep.mdDCCI Stage O 调优协议dcci-option-tuning.mdSK 元数据盘点脚本analyze_sk_meta.py控制器会话脚本auto_tune_session.pypipeline 测试夹具layer-map 样例layer-map.json【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考