CANN graph-autofusion SuperKernel 优化与调试选项实战AOT 样例 example02_sk_options 全解【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion本文基于 graph-autofusion 仓库super_kernel/examples/aot/example02_sk_options/下的 AOT 样例系统讲解 SuperKernel 的 optimize/debug options 如何配置、如何随torch.compile下发到编译管线以及仓库中SuperKernelOptionsManager对这些选项的解析、校验与默认值处理。读完本文你能完整跑通该样例dav-2201/dav-3510双架构理解super_kernel_optimize_options与super_kernel_debug_options中每个开关的语义、取值范围和源码级实现依据并掌握静态编译产物与 eager 真值校验的工程做法。一、样例定位与运行方式该样例README的定位是演示 SuperKernel 的 optimize/debug options并用 eager 执行结果校验静态编译static kernel compile输出。它属于 SuperKernel AOTAhead-Of-Time编译链路的官方示例与example01_dual_stream、example03_kernel_pybind并列专注于编译期选项这一主题。在仓库根目录执行bash super_kernel/examples/aot/example02_sk_options/run.sh --npu-archdav-2201要点说明该样例支持dav-2201和dav-3510两种 NPU 架构通过--npu-arch参数指定脚本会根据架构选择对应的 attention 网络脚本run.sh 中的case分支dav-2201选main-dav-2201.pydav-3510选main-dav-3510.py运行设备为当前可见 NPU脚本本身不做设备选择由torch_npu默认调度前置依赖是torch_npu的npugraph_ex编译后端与 SuperKernel 静态编译能力CANN 环境已安装运行前请先确认环境。1.1 run.sh 的完整执行流程run.sh 只有 26 行核心逻辑但它串联了完整的清理—编译—校验—回滚闭环值得逐段拆解。其公共函数来自 common.shsource ../scripts/common.sh参数解析sk_parse_npu_arch基于getopt解析--npu-arch并做白名单校验sk_validate_npu_arch只接受dav-2201|dav-3510其余值报错退出码 2工作区清理sk_cleanup_local删除上一轮残留的log、tmp、sk_meta、kernel_meta、profiling、static_kernel_compile_outputs、aclnn_static_shape_kernel_outputs、.static_kernel_records.json保证每次运行从干净状态开始日志捕获执行sk_run_python_with_log以tee方式把 Python 进程的全部输出写入tmp/run.log并通过PIPESTATUS[0]返回真实退出码静态编译产物校验sk_check_static_kernel_outputs ... required检查static_kernel_compile_outputs/下是否生成了*.run安装包同时排查*_compile_error.log由于传入了required没有生成.run包即判定样例失败——这正对应该样例静态编译产物 eager 真值校验的双重验收标准退出回滚trap sk_uninstall_static_kernel_from_log EXIT保证无论成功失败退出都会从run.log中提取本次安装的uninstall.sh路径并执行卸载。该函数还做了严格的安全校验卸载脚本必须位于$ASCEND_HOME_PATH/opp/static_kernel/ai_core/包名/uninstall.sh与本次生成的*.run包一一对应拒绝执行符号链接、路径逃逸含..或不属于本包目录的脚本避免误删系统已装的静态内核。这套生成即校验、退出即回滚的脚本结构对自建 SuperKernel AOT 回归脚本有直接参考价值。二、被测网络双架构 attention 图样例主脚本中的Network是一个刻意构造的多 op 图用于覆盖 SuperKernel 优化选项的实际作用面。以 main-dav-2201.py 为例其前向拓扑为query, key, value, length | v [fia_01] npu_fused_infer_attention_score | v [res] npu_moe_gating_top_k_softmax_v2 (k1024) | v [quant] npu_dynamic_quant - to(float16) | v [ifa_01] npu_incre_flash_attention --- key, value, length | v [fia_02] npu_fused_infer_attention_score --- key, value, length | ----------- torch.add --- npu_grouped_matmul | v outputs: (add_01, ifa_01)输入规模batch3, seq_len256, hidden1024全部float16上 NPUlength[99,199,180]表示逐样本变长序列图中同时包含 fused attention、MoE gating top-k softmax、动态量化、增量 flash attention、grouped matmul 与 elementwise add存在跨 op 的数据依赖与并行可能正是 SuperKernel 跨核融合、op 并行等优化选项需要处理的典型场景。两个架构版本的主要差异对比 main-dav-3510.py项目dav-2201 版dav-3510 版中间 attention opnpu_incre_flash_attention增量解码形态npu_fused_infer_attention_scoredecode 形态序列长度参数单一actual_seq_lengthslength拆分为actual_seq_lengthsquery_lengths与actual_seq_lengths_kvkv_lengthsquery 长度[1,1,1]模拟 decode 场景输出(add_01, ifa_01)(add_01, fia_decode_01)也就是说同一套 options 配置会分别作用于两种不同形状的 attention 图上这对验证选项行为的架构无关性以及架构相关内部选项的自动开启见下文很关键。三、SuperKernel 优化选项详解样例通过torch.compile(..., backendnpugraph_ex, options{...})把 SuperKernel 选项带入编译管线核心字段是super_kernel_optimize: True总开关和super_kernel_optimize_options。样例中实际启用的优化选项如下取自两个主脚本中完全一致的build_model()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, }, }, super_kernel_debug_options: { debug_sync_all: 0, debug_op_exec_trace: 0, debug_cross_core_sync_check: 0, debug_per_op_max_core_num: 0, }, },3.1 优化选项逐项解析各选项的名称、类型、默认值与合法取值范围由 sk_options_manager.cpp 中的默认选项工厂表DEFAULT_OPTION_FACTORIES与SetOptOptionValue解析逻辑共同定义选项枚举与结构体定义见 super_kernel.h。选项类型默认值合法范围样例取值与含义auto_op_parallel整数0[0, 1]0关闭自动 op 并行dcci_before_kernel_start字符串列表空模式串[.*]对所有 kernel 在启动前允许 DCCI 调度策略dcci_after_kernel_end字符串列表空模式串[.*]对所有 kernel 在结束后允许相应 DCCI 策略dcci_disable_on_kernel字符串列表空模式串[.*]对所有 kernel 施加该禁用策略early_start整数0ACLSK_EARLY_START_DISABLED[0, 1]1启用 early start 全局选项aggressive_opt_strategies结构体全 0见下激进融合策略开关补充说明源码中同样注册、但样例未显式设置的优化选项它们会走默认值preload_code整数默认1合法范围 [0, 2]split_mode整数默认4合法范围 [1, 4]splitCntstream_fusion整数默认1合法范围 [0, 1]kernel_mapkernel 名映射aclskKernelMapOption每个条目最多 4 个sknlNamesubuf_lock_ignore_kernel字符串列表配置按名字模式忽略 MIX kernel split的 opopt_extend_option/debug_extend_option字符串 map 形式的扩展预留位。3.2 模式串正则匹配规则dcci_*系列选项接受的是 kernel 名模式列表。从源码结构看SuperKernelOptionsManager::MatchRegex与IsValidRegexPatternsk_options_manager.cpp仅支持字符字母、数字、_、-、.、*其中.匹配任意字符*为通配模式不允许以*开头且不能为空因此样例中的.*表示匹配所有 kernel是对全部 op 生效的写法实际项目中通常换成如MatMul_*这样更窄的模式只对被怀疑受 DCCI 影响的 kernel 生效。匹配逻辑基于二维动态规划matchFlag[m1][n1]对每个 kernel 名逐一尝试列表中所有模式命中任一即返回真。3.3 aggressive_opt_strategies位掩码语义aggressive_opt_strategies对应 C API 结构体aclskAggressiveOptStrategieseventBreakerBypass/valueBreakerBypass/taskBreakerBypass三个字段其含义在 super_kernel.h 的注释中定义得很明确eventBreakerBypass为 event breaker 策略预留样例未设置解析侧校验其取值在 0 到类型上限之间valueBreakerBypass值依赖内存等待策略的位掩码取值为枚举aclskValueBreakerBypassFlag0b00ACLSK_VALUE_BREAKER_BYPASS_NONE拒绝 notify/wait 配对关系保持 wait 不可融合0b01ACLSK_VALUE_BREAKER_BYPASS_PAIRED_WAIT对于配对的 notifywait仍要求既有规则通过否则 SuperKernel 优化退出0b10ACLSK_VALUE_BREAKER_BYPASS_UNPAIRED_WAIT对于规则检查后没有对应 notify 的 wait放行其融合。样例取0b10即允许这类单边 wait 参与融合——这是一种更激进但需自行验证数值正确性的策略taskBreakerBypass为 1 时启用默认节点旁路合法范围 [0, 1]。样例取0b00即关闭。解析侧对这三个字段分别调用GetValidatedUintValue做范围校验越界时打SK_LOGW并回退到默认值如value_breaker_bypass默认ACLSK_VALUE_BREAKER_BYPASS_NONE而不是直接报错。3.4 选项解析与校验机制源码视角SuperKernelOptionsManager::ParseOptionssk_options_manager.cpp是选项进入 SuperKernel 的唯一入口其行为要点先执行RegisterDefaultOptions()注册全部默认选项 → 注册内部选项 → 应用架构相关选项下一节展开遍历aclskOptions数组逐项调用SetOptOptionValue同一optionType重复出现时只取第一个后到项打 warning 跳过因此 Python 侧 options dict 的键不应重复下发数值选项统一走NumberOptOption::SetValue的 [min, max] 区间校验越界回退默认值字符串列表选项不允许空列表所有生效值最终可通过ToJson()序列化sk_dump_json.cpp 相关链路会将其落盘到 JSON dump便于排查我下发的选项到底生效成什么样。3.5 架构相关的内部选项ApplyArchSpecificOptions会根据当前 kernel 架构GetCurrentSkKernelArch()见 sk_common.h自动开启内部选项SkInnerOptionType用户不可直接设置只能通过 JSON dump 观察dav-3510DAV_3510自动开启mix_kernel_split与simt_op_supportdav-2201DAV_2201不开启保持默认。这解释了样例为何要按架构拆成两套 main 脚本同样的选项配置在两种架构上的内部行为基线本身就不同attention 网络形态prefill vs decode也需要分别构造。四、SuperKernel 调试选项详解super_kernel_debug_options下的四个开关在样例中全部显式置0关闭但它们的语义与联动关系值得讲清楚默认注册与联动逻辑均在 sk_options_manager.cpp调试选项默认值合法范围作用debug_sync_all0[0, 1]置 1 时进入调试模式EnableDebug()判debug_sync_all 1执行路径上加入全同步行为用于定位跨核时序问题debug_op_exec_trace0[0, 1]开启 op 级执行 tracedebug_cross_core_sync_check0[0, 1]开启跨核同步检查debug_per_op_max_core_num0[0, 1]开启每 op 最大核数限制调试一个重要的联动规则当debug_per_op_max_core_num被置 1 时解析逻辑会自动补开debug_cross_core_sync_check若其当前不为 1 则自动置 1并打日志[DEBUG_PER_OP_MAX_CORE_NUM] auto-enabled DEBUG_CROSS_CORE_SYNC_CHECK。因此在样例中如果只把debug_per_op_max_core_num改为 1实际生效的调试面会比字面上多一项——读 dump JSON 或日志时可以留意这一自动开启。调试选项与优化选项的分层设计super_kernel_optimize_optionsvssuper_kernel_debug_options让性能调优实验与正确性排查可以独立开关这也是该样例将两组选项显式全量列出的原因它本身就是这两组选项的活文档。五、正确性校验eager 真值 vs 静态编译输出样例main()的验证流程是静态编译可信度的标准姿势两个主脚本一致固定随机种子torch.manual_seed(1234)、np.random.seed(1234)生成输入先用未编译的eager_model跑一遍torch.npu.synchronize()后detach().clone()保存期望输出再用torch.compile(backendnpugraph_ex, fullgraphTrue, dynamicTrue, options{...})编译后的模型跑同样clone 后的输入得到实际输出对两个输出分别做torch.testing.assert_close(actual, expected, rtol1e-3, atol1e-2)通过后打印两份输出摘要shape、dtype、mean以及真值校验通过 / 测试完成!失败路径区分返回码断言失败返回 1真值校验失败其他异常返回 2 并打印 traceback。结合run.sh的sk_check_static_kernel_outputs ... required该样例的最终通过条件是双重的Python 侧数值校验通过且static_kernel_compile_outputs/下确实生成了静态编译*.run包。对dav-2201版还额外校验了npu_incre_flash_attention输出ifa_out与add_out两条输出流。六、延伸阅读仓库内相关源码与文档选项定义与 C APIsuper_kernel.haclskOptionType枚举、各aclsk*Option结构体、aclskValueBreakerBypassFlag、aclskOptimize接口声明选项管理器sk_options_manager.hOptOptionBase类型体系、SuperKernelOptionsManager接口与CollectAllOptionsdump 工具、sk_options_manager.cpp默认值、范围校验、正则匹配、架构选项、JSON 序列化样例脚本run.sh、main-dav-2201.py、main-dav-3510.py、公共函数 common.sh姊妹样例example01_dual_stream双流场景与 example03_kernel_pybindpybind 自定义 kernel背景文档SuperKernel 开发者指南、SuperKernel 迁移设计以及仓库内 super_kernel/README.md。README 中指向的 TorchAir SuperKernel 使用说明属于外部仓库文档本文不展开本文所有选项语义均以本仓库super_kernel/源码为准。七、小结example02_sk_options用一份双架构 attention 图 一组显式列出的 optimize/debug options eager 真值校验构成了 SuperKernel 静态编译选项的最小可复现实验闭环。实践建议以样例为模板新建回归脚本时保留清理 → 编译 → 校验.run产物 → 退出自动卸载的run.sh结构可显著降低 AOT 实验的环境污染风险调整dcci_*模式串时记住限制字符集不允许以*开头.*只代表全量生效不应直接搬进生产配置尝试value_breaker_bypass0b10等激进策略后必须重新走 eager 真值校验流程并以 options JSON dump 确认实际生效值在dav-3510上注意mix_kernel_split/simt_op_support内部选项的自动开启行为基线与dav-2201不同。【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CANN graph-autofusion SuperKernel 优化与调试选项实战：AOT 样例 example02_sk_options 全解
CANN graph-autofusion SuperKernel 优化与调试选项实战AOT 样例 example02_sk_options 全解【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion本文基于 graph-autofusion 仓库super_kernel/examples/aot/example02_sk_options/下的 AOT 样例系统讲解 SuperKernel 的 optimize/debug options 如何配置、如何随torch.compile下发到编译管线以及仓库中SuperKernelOptionsManager对这些选项的解析、校验与默认值处理。读完本文你能完整跑通该样例dav-2201/dav-3510双架构理解super_kernel_optimize_options与super_kernel_debug_options中每个开关的语义、取值范围和源码级实现依据并掌握静态编译产物与 eager 真值校验的工程做法。一、样例定位与运行方式该样例README的定位是演示 SuperKernel 的 optimize/debug options并用 eager 执行结果校验静态编译static kernel compile输出。它属于 SuperKernel AOTAhead-Of-Time编译链路的官方示例与example01_dual_stream、example03_kernel_pybind并列专注于编译期选项这一主题。在仓库根目录执行bash super_kernel/examples/aot/example02_sk_options/run.sh --npu-archdav-2201要点说明该样例支持dav-2201和dav-3510两种 NPU 架构通过--npu-arch参数指定脚本会根据架构选择对应的 attention 网络脚本run.sh 中的case分支dav-2201选main-dav-2201.pydav-3510选main-dav-3510.py运行设备为当前可见 NPU脚本本身不做设备选择由torch_npu默认调度前置依赖是torch_npu的npugraph_ex编译后端与 SuperKernel 静态编译能力CANN 环境已安装运行前请先确认环境。1.1 run.sh 的完整执行流程run.sh 只有 26 行核心逻辑但它串联了完整的清理—编译—校验—回滚闭环值得逐段拆解。其公共函数来自 common.shsource ../scripts/common.sh参数解析sk_parse_npu_arch基于getopt解析--npu-arch并做白名单校验sk_validate_npu_arch只接受dav-2201|dav-3510其余值报错退出码 2工作区清理sk_cleanup_local删除上一轮残留的log、tmp、sk_meta、kernel_meta、profiling、static_kernel_compile_outputs、aclnn_static_shape_kernel_outputs、.static_kernel_records.json保证每次运行从干净状态开始日志捕获执行sk_run_python_with_log以tee方式把 Python 进程的全部输出写入tmp/run.log并通过PIPESTATUS[0]返回真实退出码静态编译产物校验sk_check_static_kernel_outputs ... required检查static_kernel_compile_outputs/下是否生成了*.run安装包同时排查*_compile_error.log由于传入了required没有生成.run包即判定样例失败——这正对应该样例静态编译产物 eager 真值校验的双重验收标准退出回滚trap sk_uninstall_static_kernel_from_log EXIT保证无论成功失败退出都会从run.log中提取本次安装的uninstall.sh路径并执行卸载。该函数还做了严格的安全校验卸载脚本必须位于$ASCEND_HOME_PATH/opp/static_kernel/ai_core/包名/uninstall.sh与本次生成的*.run包一一对应拒绝执行符号链接、路径逃逸含..或不属于本包目录的脚本避免误删系统已装的静态内核。这套生成即校验、退出即回滚的脚本结构对自建 SuperKernel AOT 回归脚本有直接参考价值。二、被测网络双架构 attention 图样例主脚本中的Network是一个刻意构造的多 op 图用于覆盖 SuperKernel 优化选项的实际作用面。以 main-dav-2201.py 为例其前向拓扑为query, key, value, length | v [fia_01] npu_fused_infer_attention_score | v [res] npu_moe_gating_top_k_softmax_v2 (k1024) | v [quant] npu_dynamic_quant - to(float16) | v [ifa_01] npu_incre_flash_attention --- key, value, length | v [fia_02] npu_fused_infer_attention_score --- key, value, length | ----------- torch.add --- npu_grouped_matmul | v outputs: (add_01, ifa_01)输入规模batch3, seq_len256, hidden1024全部float16上 NPUlength[99,199,180]表示逐样本变长序列图中同时包含 fused attention、MoE gating top-k softmax、动态量化、增量 flash attention、grouped matmul 与 elementwise add存在跨 op 的数据依赖与并行可能正是 SuperKernel 跨核融合、op 并行等优化选项需要处理的典型场景。两个架构版本的主要差异对比 main-dav-3510.py项目dav-2201 版dav-3510 版中间 attention opnpu_incre_flash_attention增量解码形态npu_fused_infer_attention_scoredecode 形态序列长度参数单一actual_seq_lengthslength拆分为actual_seq_lengthsquery_lengths与actual_seq_lengths_kvkv_lengthsquery 长度[1,1,1]模拟 decode 场景输出(add_01, ifa_01)(add_01, fia_decode_01)也就是说同一套 options 配置会分别作用于两种不同形状的 attention 图上这对验证选项行为的架构无关性以及架构相关内部选项的自动开启见下文很关键。三、SuperKernel 优化选项详解样例通过torch.compile(..., backendnpugraph_ex, options{...})把 SuperKernel 选项带入编译管线核心字段是super_kernel_optimize: True总开关和super_kernel_optimize_options。样例中实际启用的优化选项如下取自两个主脚本中完全一致的build_model()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, }, }, super_kernel_debug_options: { debug_sync_all: 0, debug_op_exec_trace: 0, debug_cross_core_sync_check: 0, debug_per_op_max_core_num: 0, }, },3.1 优化选项逐项解析各选项的名称、类型、默认值与合法取值范围由 sk_options_manager.cpp 中的默认选项工厂表DEFAULT_OPTION_FACTORIES与SetOptOptionValue解析逻辑共同定义选项枚举与结构体定义见 super_kernel.h。选项类型默认值合法范围样例取值与含义auto_op_parallel整数0[0, 1]0关闭自动 op 并行dcci_before_kernel_start字符串列表空模式串[.*]对所有 kernel 在启动前允许 DCCI 调度策略dcci_after_kernel_end字符串列表空模式串[.*]对所有 kernel 在结束后允许相应 DCCI 策略dcci_disable_on_kernel字符串列表空模式串[.*]对所有 kernel 施加该禁用策略early_start整数0ACLSK_EARLY_START_DISABLED[0, 1]1启用 early start 全局选项aggressive_opt_strategies结构体全 0见下激进融合策略开关补充说明源码中同样注册、但样例未显式设置的优化选项它们会走默认值preload_code整数默认1合法范围 [0, 2]split_mode整数默认4合法范围 [1, 4]splitCntstream_fusion整数默认1合法范围 [0, 1]kernel_mapkernel 名映射aclskKernelMapOption每个条目最多 4 个sknlNamesubuf_lock_ignore_kernel字符串列表配置按名字模式忽略 MIX kernel split的 opopt_extend_option/debug_extend_option字符串 map 形式的扩展预留位。3.2 模式串正则匹配规则dcci_*系列选项接受的是 kernel 名模式列表。从源码结构看SuperKernelOptionsManager::MatchRegex与IsValidRegexPatternsk_options_manager.cpp仅支持字符字母、数字、_、-、.、*其中.匹配任意字符*为通配模式不允许以*开头且不能为空因此样例中的.*表示匹配所有 kernel是对全部 op 生效的写法实际项目中通常换成如MatMul_*这样更窄的模式只对被怀疑受 DCCI 影响的 kernel 生效。匹配逻辑基于二维动态规划matchFlag[m1][n1]对每个 kernel 名逐一尝试列表中所有模式命中任一即返回真。3.3 aggressive_opt_strategies位掩码语义aggressive_opt_strategies对应 C API 结构体aclskAggressiveOptStrategieseventBreakerBypass/valueBreakerBypass/taskBreakerBypass三个字段其含义在 super_kernel.h 的注释中定义得很明确eventBreakerBypass为 event breaker 策略预留样例未设置解析侧校验其取值在 0 到类型上限之间valueBreakerBypass值依赖内存等待策略的位掩码取值为枚举aclskValueBreakerBypassFlag0b00ACLSK_VALUE_BREAKER_BYPASS_NONE拒绝 notify/wait 配对关系保持 wait 不可融合0b01ACLSK_VALUE_BREAKER_BYPASS_PAIRED_WAIT对于配对的 notifywait仍要求既有规则通过否则 SuperKernel 优化退出0b10ACLSK_VALUE_BREAKER_BYPASS_UNPAIRED_WAIT对于规则检查后没有对应 notify 的 wait放行其融合。样例取0b10即允许这类单边 wait 参与融合——这是一种更激进但需自行验证数值正确性的策略taskBreakerBypass为 1 时启用默认节点旁路合法范围 [0, 1]。样例取0b00即关闭。解析侧对这三个字段分别调用GetValidatedUintValue做范围校验越界时打SK_LOGW并回退到默认值如value_breaker_bypass默认ACLSK_VALUE_BREAKER_BYPASS_NONE而不是直接报错。3.4 选项解析与校验机制源码视角SuperKernelOptionsManager::ParseOptionssk_options_manager.cpp是选项进入 SuperKernel 的唯一入口其行为要点先执行RegisterDefaultOptions()注册全部默认选项 → 注册内部选项 → 应用架构相关选项下一节展开遍历aclskOptions数组逐项调用SetOptOptionValue同一optionType重复出现时只取第一个后到项打 warning 跳过因此 Python 侧 options dict 的键不应重复下发数值选项统一走NumberOptOption::SetValue的 [min, max] 区间校验越界回退默认值字符串列表选项不允许空列表所有生效值最终可通过ToJson()序列化sk_dump_json.cpp 相关链路会将其落盘到 JSON dump便于排查我下发的选项到底生效成什么样。3.5 架构相关的内部选项ApplyArchSpecificOptions会根据当前 kernel 架构GetCurrentSkKernelArch()见 sk_common.h自动开启内部选项SkInnerOptionType用户不可直接设置只能通过 JSON dump 观察dav-3510DAV_3510自动开启mix_kernel_split与simt_op_supportdav-2201DAV_2201不开启保持默认。这解释了样例为何要按架构拆成两套 main 脚本同样的选项配置在两种架构上的内部行为基线本身就不同attention 网络形态prefill vs decode也需要分别构造。四、SuperKernel 调试选项详解super_kernel_debug_options下的四个开关在样例中全部显式置0关闭但它们的语义与联动关系值得讲清楚默认注册与联动逻辑均在 sk_options_manager.cpp调试选项默认值合法范围作用debug_sync_all0[0, 1]置 1 时进入调试模式EnableDebug()判debug_sync_all 1执行路径上加入全同步行为用于定位跨核时序问题debug_op_exec_trace0[0, 1]开启 op 级执行 tracedebug_cross_core_sync_check0[0, 1]开启跨核同步检查debug_per_op_max_core_num0[0, 1]开启每 op 最大核数限制调试一个重要的联动规则当debug_per_op_max_core_num被置 1 时解析逻辑会自动补开debug_cross_core_sync_check若其当前不为 1 则自动置 1并打日志[DEBUG_PER_OP_MAX_CORE_NUM] auto-enabled DEBUG_CROSS_CORE_SYNC_CHECK。因此在样例中如果只把debug_per_op_max_core_num改为 1实际生效的调试面会比字面上多一项——读 dump JSON 或日志时可以留意这一自动开启。调试选项与优化选项的分层设计super_kernel_optimize_optionsvssuper_kernel_debug_options让性能调优实验与正确性排查可以独立开关这也是该样例将两组选项显式全量列出的原因它本身就是这两组选项的活文档。五、正确性校验eager 真值 vs 静态编译输出样例main()的验证流程是静态编译可信度的标准姿势两个主脚本一致固定随机种子torch.manual_seed(1234)、np.random.seed(1234)生成输入先用未编译的eager_model跑一遍torch.npu.synchronize()后detach().clone()保存期望输出再用torch.compile(backendnpugraph_ex, fullgraphTrue, dynamicTrue, options{...})编译后的模型跑同样clone 后的输入得到实际输出对两个输出分别做torch.testing.assert_close(actual, expected, rtol1e-3, atol1e-2)通过后打印两份输出摘要shape、dtype、mean以及真值校验通过 / 测试完成!失败路径区分返回码断言失败返回 1真值校验失败其他异常返回 2 并打印 traceback。结合run.sh的sk_check_static_kernel_outputs ... required该样例的最终通过条件是双重的Python 侧数值校验通过且static_kernel_compile_outputs/下确实生成了静态编译*.run包。对dav-2201版还额外校验了npu_incre_flash_attention输出ifa_out与add_out两条输出流。六、延伸阅读仓库内相关源码与文档选项定义与 C APIsuper_kernel.haclskOptionType枚举、各aclsk*Option结构体、aclskValueBreakerBypassFlag、aclskOptimize接口声明选项管理器sk_options_manager.hOptOptionBase类型体系、SuperKernelOptionsManager接口与CollectAllOptionsdump 工具、sk_options_manager.cpp默认值、范围校验、正则匹配、架构选项、JSON 序列化样例脚本run.sh、main-dav-2201.py、main-dav-3510.py、公共函数 common.sh姊妹样例example01_dual_stream双流场景与 example03_kernel_pybindpybind 自定义 kernel背景文档SuperKernel 开发者指南、SuperKernel 迁移设计以及仓库内 super_kernel/README.md。README 中指向的 TorchAir SuperKernel 使用说明属于外部仓库文档本文不展开本文所有选项语义均以本仓库super_kernel/源码为准。七、小结example02_sk_options用一份双架构 attention 图 一组显式列出的 optimize/debug options eager 真值校验构成了 SuperKernel 静态编译选项的最小可复现实验闭环。实践建议以样例为模板新建回归脚本时保留清理 → 编译 → 校验.run产物 → 退出自动卸载的run.sh结构可显著降低 AOT 实验的环境污染风险调整dcci_*模式串时记住限制字符集不允许以*开头.*只代表全量生效不应直接搬进生产配置尝试value_breaker_bypass0b10等激进策略后必须重新走 eager 真值校验流程并以 options JSON dump 确认实际生效值在dav-3510上注意mix_kernel_split/simt_op_support内部选项的自动开启行为基线与dav-2201不同。【免费下载链接】graph-autofusionGraph-autofusion 是一个面向昇腾Ascend芯片的轻量级、解耦式组件集合旨在通过自动融合技术加速模型执行。 目前已开源 SuperKernel 组件和 Autofuse 组件未来将持续开放更多自动融合相关模块。项目地址: https://gitcode.com/cann/graph-autofusion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考