CANN开源graph-autofusion深度实践：Autofuse与SuperKernel双组件协同的算子融合优化实战

前言

在昇腾NPU上实现高性能模型推理，计算图的算子编排质量是决定性的胜负手。算子融合作为NPU性能工程中最具杠杆效应的优化手段，其核心价值在于将多个相邻算子合并为单一内核，从而削减算子间搬运开销、减少调度等待时间，并充分利用融合后的更大计算密度提升硬件利用率。CANN开放算子融合能力的思路并非从零构建封闭框架，而是通过graph-autofusion项目提供一组轻量、解耦、可独立引入的融合组件，让不同技术栈的开发者能够按需接入、按层叠加。

graph-autofusion项目当前已开源两个核心组件：SuperKernel和Autofuse。SuperKernel面向图编译阶段，基于JIT编译将多个子算子整体重编译为单一算子内核，重点优化算子调度开销、ICache命中率和核间同步效率；Autofuse则面向自动算子代码生成，在算子粒度上提供elementwise、reduce等常见融合模式的自动识别与融合内核生成，并内置Auto Tiling优化、动态shape和混合精度等能力。两者在设计哲学上保持一致：组件之间无隐式耦合，底层仅依赖AscendC与Runtime环境，引入成本极低。这一架构思路贯穿整个graph-autofusion项目的设计与实现，是理解其工程价值的关键所在。

autofuse模块：轻量化解耦架构

autofuse的设计目标并非替代图编译框架，而是作为计算图与融合决策之间的透明注入层。这意味着autofuse不需要开发者修改模型定义代码，不需要重写网络结构，也不需要在模型 forward 过程中埋入任何融合感知逻辑。所有融合判断与内核生成的职责由autofuse_headers在图遍历阶段完成，对上层框架保持无侵入。

autofuse_headers的即插即用设计是这一架构思路的具体体现。在Inductor接入场景中，开发者仅需在模型导入torch之后引入一个扩展模块，即可激活autofuse后端。融合决策在图lowering阶段由autofuse拦截注入，原有的模型代码完全无需修改，框架层面的改动仅限于这一行导入语句。这种设计在工程上有重要价值：当融合策略需要升级或者某个融合模式出现精度风险时，开发者可以通过更新autofuse版本来热切换融合行为，而无需重新部署模型代码本身。autofuse_headers以极小的接入成本提供了完整的融合能力输出，使得在已有生产网络中启用融合优化成为低风险操作。

融合决策的注入发生在计算图被遍历的过程中。当Inductor将PyTorch算子Lower到后端图时，autofuse遍历图中相邻算子对，根据算子类型、形状约束和硬件特性判断是否满足融合前置条件。满足条件的算子对被标记为融合目标，随后由codegen模块生成融合内核。整个过程对开发者是透明的，开发者通过Profiling输出中算子名称的变体（例如autofused_add_ge_拓扑哈希）来确认融合是否实际发生。如果某个算子未能融合，框架会输出包含具体原因的Fallback日志，开发者据此可以定位是形状不匹配、算子类型不支持还是其他约束导致融合失败。

# WHY: autofuse_headers以透明拦截方式注入融合决策，模型代码零改动# 框架在图遍历阶段自动完成算子对匹配与内核注入，实现无侵入式优化importtorchimporttorch_npuimporttorch.nnasnn# === 只需导入扩展模块，即完成autofuse后端激活 ===importinductor_npu_ext DEVICE="npu:0"torch.npu.set_device(DEVICE)classMyModel(nn.Module):def__init__(self):super().__init__()defforward(self,x,y,z):# 此处模型代码与NPU优化完全解耦# autofuse在图级别拦截torch.add与torch.ge# 自动注入融合决策，生成autofused_add_ge内核result=torch.ge(torch.add(x,y),z)returnresult model=MyModel().to(DEVICE)model=torch.compile(model,dynamic=False,fullgraph=True)x=torch.randn(128,50,device=DEVICE)y=torch.randn(128,50,device=DEVICE)z=torch.randn(128,50,device=DEVICE)model.eval()result=model(x,y,z)# 内部执行autofused_add_ge融合内核

SuperKernel：从单算子模式到融合模式库

SuperKernel的技术定位与autofuse形成互补。如果说autofuse解决的是"哪些算子可以融合"，那么SuperKernel解决的是"融合后的算子如何高效执行"。SuperKernel的核心理念是将整个子算子序列在编译期整体重编译为单一内核，而非在运行时逐一调度各个子算子。编译期的全局视角使SuperKernel能够获取所有子算子的先验信息——包括每个算子的类型、前后序依赖、核类属性（Vector核还是Cube核）——从而实施运行时无法实现的深层优化。

SuperKernel定义了融合模式的物理实现方式。autofuse在计算图层面执行子图同构检测，通过模式匹配识别出可融合的算子子图；SuperKernel则接收这些子图信息，将抽象的融合意图转化为具体的融合内核实现。两者在graph-autofusion项目中的协同关系由此清晰：autofuse负责判断"融合什么"，SuperKernel负责实现"如何融合"。开发者使用SuperKernel时，通过with torchair.scope.super_kernel("sk_name"):语句块标注需要融合的算子范围，框架在图编译阶段对这些被标注的子图进行整体融合。

子图同构检测是autofuse实现自动融合的核心算法环节。其作用场景在于：当开发者或自动化工具无法穷举所有融合场景时，同构检测算法在运行时动态遍历计算图，将图中的算子子结构与已注册的融合模式进行结构化匹配，自动发现可融合的算子组合。这种模式化的自动发现能力大幅扩展了融合优化的覆盖范围，使得即便没有显式标注，autofuse也能在计算图中识别出elementwise类型+elementwise类型、elementwise类型+broadcast类型、elementwise类型+reduce类型等标准融合场景。

# WHY: 子图同构检测在计算图优化中承担"模式发现"角色# 通过遍历图中相邻算子并与预注册融合模式做结构化匹配# 实现融合目标的自动发现，无需开发者穷举标注所有融合场景defdetect_fusion_subgraph(graph,fusion_patterns):""" graph: 计算图对象，包含节点列表与边关系 fusion_patterns: 预注册的融合模式集合（每个模式包含拓扑结构与算子类型约束） 返回: 所有匹配成功的子图片段列表 """candidates=[]# 存储遍历过程中发现的候选融合子图# 从图中提取每个节点的拓扑签名与属性签名fornodeingraph.nodes:signature=extract_node_signature(node)# 遍历预注册模式，寻找结构匹配forpatterninfusion_patterns:ifis_structurally_isomorphic(node,pattern):candidates.append(node)# 对候选片段进行形状兼容性校验，过滤维度不匹配的子图valid_subgraphs=[]forcandidateincandidates:ifvalidate_shape_compatibility(candidate,fusion_patterns):valid_subgraphs.append(candidate)returnvalid_subgraphs# 交给codegen模块生成融合内核

Profiling集成：融合失败的诊断机制

算子融合在理论上收益清晰，但在实践中并非所有算子组合都能成功融合。shape约束不匹配、算子类型超出支持范围、内存布局冲突、混合精度不兼容等问题都可能导致某个候选融合对最终无法生成融合内核。autofuse在这种情况下会跳过融合，回退到单算子执行模式。如果缺乏诊断手段，开发者只能通过对比融合前后的性能数据来推断融合是否发生，这种间接推断方式效率极低且无法指导具体的优化方向。

autofuse提供了结构化的融合失败原因dump机制。通过设置环境变量，框架将每个未能融合的算子对的失败原因写入JSON文件，文件内容包括：失败错误码、目标算子类型、约束冲突的具体描述（例如"shape不满足融合条件"或"算子类型不在支持列表中"）、以及触发时的张量维度信息。开发者读取这些JSON文件可以准确定位融合失败的技术原因，从而判断是修改模型结构、调整输入shape还是等待框架版本更新以获得更宽泛的融合支持。

融合失败诊断的核心价值在于支撑迭代优化循环。一个高效的融合优化流程通常包含以下步骤：第一步是通过Profiling数据确定性能瓶颈算子；接着开启融合失败dump，观察这些瓶颈算子是否被正确识别为融合目标；如果识别了但融合失败，从JSON文件中获取具体原因；根据原因调整模型图或输入配置；重新运行并对比性能数据。没有结构化的失败原因dump，这一迭代过程退化为盲目的试错，成本大幅上升。

# WHY: 融合失败诊断是迭代优化的必要基础设施# dump出的JSON文件将隐式的编译拒绝信息转化为显式的问题清单# 开发者可以据此定位shape不匹配、类型不支持等具体障碍# 避免在融合优化中进行低效的盲目试错# 启用融合图结构dump，观察成功融合的算子内部图结构# pbtxt文件可通过netron.app打开，直观展示融合后的算子子图exportAUTOFUSE_DFX_FLAGS="--codegen_compile_debug=true;--debug_dir=/path-to-dump/"# 禁用Inductor编译缓存，强制每次执行都重新触发融合流程# 适用于需要反复验证融合决策正确性的调试阶段exportTORCHINDUCTOR_FORCE_DISABLE_CACHES=1# 开启内核同步执行模式，每次kernel下发都等待完成# 便于确定首个报错的kernel位置，但会降低性能exportASCEND_LAUNCH_BLOCKING=1# torch原生调试开关，启用详细编译日志与中间产物保存exportTORCH_COMPILE_DEBUG=1

实战：Conv+BN+ReLU融合案例

Conv+BN+ReLU是卷积神经网络中出现频率最高的算子组合之一，也是融合收益最显著的典型场景。在未经融合的情况下，这三个算子依次执行：Conv产生特征图输出，BN读取该输出做归一化处理，ReLU再读取BN的输出做激活非线性映射。每两个算子之间都存在一次显式的内存读写操作，在NPU的Vector核上这类Memory Bound模式的性能损失尤为突出。

Conv+BN+ReLU融合后，上述三次算子执行和两次中间内存访问被合并为单一融合内核。Conv的计算结果直接作为BN的输入，BN的结果直接流向ReLU，数据在核内寄存器级别流转，无需写回全局内存再重新读取。对于大分辨率特征图（例如ResNet-50中Conv3阶段的输出），这一改动直接消除了两段高数据量的内存搬运耗时，而这两段搬运往往占据整体执行时间的相当比例。

在autofuse框架中启用Conv+BN+ReLU融合无需显式配置。autofuse内置的elementwise+elementwise融合规则覆盖了Conv的输出属于Vector计算域的特性，BN的elementwise算子和ReLU的非线性操作均在支持范围内。当模型通过Inductor Lower到NPU后端时，autofuse自动遍历计算图并识别出Conv-BN-ReLU这一连续链路，注入融合决策后生成融合内核。如果开发者使用torchvision等标准库提供的模型，开启融合的方式仅需在导入torch之后增加一个扩展模块导入语句，框架会遍历模型图中的所有可融合模式并自动应用，无需逐层检查。

在实际项目中，开发者可以通过开启DFX dump来验证Conv+BN+ReLU是否被成功融合。在--debug_dir指定的路径下，每个融合算子对应一个.pbtxt图文件，其中autofused_conv_bn_relu_拓扑哈希命名的kernel表明融合成功。开发者还可以通过对比融合前后的op_summary文件，量化融合带来的性能提升：融合后Conv+BN+ReLU的总耗时对应单一融合算子的执行时间，而融合前为三个独立算子的耗时之和，两者的差值即为融合收益。

SuperKernel与Autofuse的协作模式

在实际模型优化项目中，SuperKernel和Autofuse并不是互斥的选择，而是面向不同粒度的互补工具。SuperKernel工作在算子指令级别的融合优化，它将相邻的计算算子合并为一个JIT编译的内核，消除算子间的调度开销和内存搬运延迟。这种融合方式对算子的边界关系有严格要求——只有输入输出能够直接映射、中间张量不产生额外存储需求的算子序列才适合SuperKernel融合。

Autofuse则工作在算子代码生成级别，它关注的是单个算子内部的融合优化策略。对于一个elementwise算子链，Autofuse可以自动识别出mul、add、relu的组合模式，生成合并的融合内核，在上层发出一次调用请求即完成整个链路的计算。这种融合方式不需要手动编写融合算子代码，Autofuse的自动模式识别引擎会根据计算图的拓扑结构自动匹配合适的融合模板。

两者的协作体现在模型的计算图优化流程中。当模型从框架导出为CANN可执行的om模型时，Autofuse在计算图层面的算子图案匹配阶段发现elementwise链路的融合机会并生成融合内核模板，SuperKernel在指令编译阶段将这些模板实例化为具体的NPU可执行指令序列。这种从图层面到指令层面的两级协作，覆盖了算子融合的不同维度，比单级融合方案覆盖更完整的优化空间。
融合失败的诊断信息对于大型模型的优化迭代具有直接价值。在语言模型场景中，attention层的多个linear映射算子的融合规则可能在混精度数据类型匹配环节失败，原因是query和key的dtype配置不一致。开发者根据诊断日志可以快速定位到模型脚本中的数据类型设置错误，修正后重新导出om模型即可获得正确的融合路径。这种可观测性设计让graph-autofusion不再是"黑盒"优化工具，而是可调试、可迭代的工程化组件。

效率对比

在昇腾NPU上对多种融合场景进行基准测试，使用torch_npu.profiler采集NPU内核执行耗时，对比融合前后关键性能指标的变化。以下数据基于Ascend 910系列芯片的标准推理配置，测试输入shape为典型生产网络尺寸，每次采集取100次推理的平均值。

从上述数据可以观察到几个明确的收益来源分类。对于Conv+BN+ReLU这类Memory Bound场景，融合的核心收益来自内存搬运时间的削减——两次中间tensor写回+读取的消失直接反映在总耗时中。对于elementwise链（Add+Ge），收益主要来自kernel launch次数的减少和ICache命中率的提升，融合后单一内核的指令空间连续性更好，预取效率更高。对于reduce链（Mul+ReduceSum），收益来自数据流在核内寄存器级闭合，避免了全局内存的写回和重新读取。对于SuperKernel融合场景，收益体现为算子调度开销的量级削减，特别是在长推理链路中，N-1次调度等待时间的累加是可观的头开销。

架构设计思路

graph-autofusion在组件设计上遵循的分层解耦原则值得深入分析。autofuse_headers作为最轻量的接入层，核心上是一组纯头文件，包含融合决策API和图遍历回调接口，不需要编译时依赖，不需要额外的运行时守护进程，开发者只需在模型入口处引入导入语句即可激活能力。这种设计将融合能力的接入门槛降到最低，使得即便是在已有大规模生产网络的工程团队中推广，也不需要对现有部署流程做任何结构性调整。

autofuse_headers之上的融合决策引擎与SuperKernel的内核生成引擎各自独立演进。融合决策引擎关注图结构的模式识别与形状约束判断，内核生成引擎关注融合后的代码如何充分利用硬件特性进行效率优化。SuperKernel在编译期拥有完整的子算子信息视图，这是它区别于autofuse自动融合生成的核心优势。编译期的全局视图使得SuperKernel能够实施ICache Preload（在当前子算子执行前预加载后续子算子指令）、Early-Start（前序算子的数据搬运指令与后续算子的初始化标量指令在Aicore与Vector核间并发）、以及细粒度同步范围控制（连续Vector算子仅执行全Vector核同步，而非全核同步）等深层优化。这些优化在autofuse的运行时JIT路径中难以实现，因为autofuse在生成内核时并不掌握完整的网络级先验信息。

从工程可维护性角度看，graph-autofusion的模块化架构使得不同角色的开发者可以在各自层级独立工作。图优化工程师专注于融合规则与同构检测算法的迭代，算子优化工程师专注于SuperKernel内核的生成质量与硬件适配，而业务开发者仅需掌握autofuse_headers的接入方式。这种关注点分离直接降低了大型团队的协作摩擦——没有人需要为了一个小范围的融合规则调整而去修改整个图编译框架。

融合生态的当前状态与实践建议

graph-autofusion项目目前SuperKernel组件处于成熟可用状态，提供了完整的文档体系、样例工程和Profiling对比脚本，开发者可以直接参考样例在Ascend 910系列芯片上运行端到端融合推理并量化收益。Autofuse组件面向PyTorch Inductor生态，支持elementwise类型+elementwise类型、elementwise类型+broadcast类型、elementwise类型+reduce类型等融合场景的自动识别与代码生成，更多融合场景的支持正在持续开放中。

对于希望在生产网络中引入融合优化的开发者，建议从以下路径入手：第一步是使用autofuse提供的pointwise样例（add+ge融合）和reduce样例（mul+reducesum融合）验证融合环境是否正常，通过Profiling输出的算子名称确认融合实际发生；接着在开发环境中对目标网络启用autofuse，通过--debug_dir路径下的pbtxt文件验证融合图结构的正确性；结尾开启融合失败dump，逐一处理JSON文件中记录的融合失败原因，对于框架尚未支持的融合场景，在autofuse更新版本中持续跟进支持范围的扩展。

对于对算子调度开销敏感的场景，SuperKernel提供了更直接的性能收益路径。开发者通过torchair.scope.super_kernel语句块显式标注融合范围，框架在图编译期完成子算子的整体融合与多维优化。SuperKernel的样例工程中提供了带融合与不带融合的性能对比脚本，开发者可以通过修改sk_model和no_sk_model的配置获得精确的融合收益数据，指导融合范围的调优决策。

整体而言，graph-autofusion在昇腾NPU上建立了一个开放、可扩展的算子融合生态。SuperKernel和Autofuse两个组件分别覆盖了编译期全局优化和运行时JIT优化两条技术路径，互为补充而非互为替代。组件之间的无隐式耦合设计使得团队可以根据自身的技术栈深度和优化需求选择性地引入其中一个或同时启用两者，在不增加系统复杂度的前提下获得有保障的性能收益。

graph-autofusion在实际模型中的应用表现出明显的硬件利用率改善。在ResNet50推理任务中，使用SuperKernel融合Conv+BN+ReLU后，AI Core的计算周期数减少，片上缓存的利用率得到提升，算子调度的内部开销同步压缩。对于Transformer类的Attention计算链，Autofuse的elementwise融合策略将连续的多头注意力中的mask、softmax和matmul合并为两级流水线执行，减少了中间张量的读写次数。

融合失败诊断与Profiling数据解读

在实际使用graph-autofusion的过程中，并非所有算子组合都适合融合。当某些算子的计算模式不匹配现有融合模板时，Autofuse会回退到非融合执行路径。graph-autofusion提供了Profiling集成机制来诊断这种融合失败——当设置特定的环境变量后，系统会在指定目录下输出融合失败原因日志文件。

这些Profiling日志以JSON格式记录了每条融合规则的触发条件和匹配结果。例如，对于elementwise融合规则，日志会给出匹配失败的算子的具体原因——可能是算子的输入秩不匹配、数据类型不一致、或者使用了未支持的动态shape。开发者根据这些日志可以精确定位哪些算子链需要手动编写融合算子，无需盲目重写整个计算图。

Profiling配置的环境变量包括日志输出路径的设置和详细控制：设置较高的日志级别会输出每条融合规则的匹配情况，包括成功匹配的规则ID和匹配耗时；设置较低的级别则只记录失败的融合规则，减少日志写入的性能影响。在生产环境推荐使用较低级别的日志输出，在开发调试阶段则打开详细日志以获得完整的融合决策链路。

仓库地址：https://atomgit.com/cann/graph-autofusion