CANN Graph AutoFusion深度实践：昇腾NPU计算图自动算子融合的Pass调度策略与内存带宽优化调优实录
前言
推理引擎在实际部署中面临的性能瓶颈，往往不是计算本身，而是数据在存储层级之间的来回搬运。当一个深度学习算子图被逐个节点执行时，每个算子都要从高带宽内存（HBM）读取输入、写出结果，中间结果像流水线上每道工序之间的半成品一样堆在传送带上等待下一步处理。这套流程在芯片架构层面制造了大量空闲等待——前一个算子写完，后一个算子才能读；Cube核算完，Vector核才能开工。这种流水线式的串行执行，将昇腾NPU的理论算力锁死在内存墙的另一边。
graph-autofusion仓库正是为解决这个问题而来。作为昇腾CANN异构计算架构下的一个轻量级、解耦式自动融合组件集合，它包含两个核心模块：SuperKernel负责将多个调度单元合并为一个统一算子来压缩调度开销，Autofuse则负责在编译期自动识别可融合的算子组合并生成融合后的单一kernel代码。两者在CANN软件栈中的位置并不重叠——SuperKernel工作在调度层面的融合，Autofuse工作在算子内部的计算图融合——但最终目标一致：减少数据在HBM和计算单元之间的搬运次数，提高Cube和Vector计算单元的实际利用率。
这篇文章从工程实践的角度出发，以Autofuse为主要分析对象，探讨融合规则引擎如何判断哪些算子可以合并、编译期的AutoFusion Pass如何从后向前扫描计算图并完成子图替换、以及融合前后的内存带宽行为发生了怎样的本质变化。文章结合graph-autofusion仓库中autofuse子模块的真实代码路径和Inductor集成方式，给出可操作的调试方法和量化评估思路。
融合规则引擎：哪些算子可以合并
为什么需要融合规则而不是手动指定
在没有融合能力的编译器里，工程师如果想让Conv+BN+ReLU三个算子合并成一次执行，只能手写一个融合算子，然后维护一套独立的代码路径。这套做法的代价是：每换一种模型结构就要重新评估融合收益、每加一个激活函数就要新写一个kernel、手写的融合算子还容易在精度边界上出现难以追踪的数值偏差。autofuse的设计思路是把「判断是否应该融合」这件事从人手里拿走，交给编译器在编译期自动决策。规则引擎就是这个自动决策系统的核心。
autofuse的融合规则定义在autofuse/ascir/fusion_rule/目录下的YAML文件中，每条规则描述了一种可融合的算子组合模式、融合所需的约束条件、以及融合后的输出形态。从autofuse当前已支持的范围来看，elementwise类型算子之间的融合是最基础的模式——add、sub、mul、div、ge、le等逐元素运算因为不需要跨数据索引的依赖，完全可以在同一个kernel里完成全部计算。pointwise类型和broadcast类型的组合也是常见的融合场景：一个shape为[256, 100]的tensor和另一个shape为[1, 100]的broadcast tensor之间做逐元素运算，两者维度兼容、数据类型一致，中间结果不需要写回HBM就可以直接流入下游。
融合判定条件的物理含义
shape兼容性是第一个硬约束。两个算子要融合，前提是上游算子的输出shape能够直接作为下游算子的输入shape，中间不需要插入任何reshape或broadcast改变内存排布。如果两个算子之间的数据流存在隐式broadcast或者维度扩展，编译器就无法在编译期确定融合后的tensor layout，导致kernel代码生成失败。数据类型一致性是第二个约束——int32和float16混在一起做融合没有工程意义，因为两种数据类型在Cube核和Vector核上的执行单元路径完全不同，强行融合只会引入不必要的类型转换开销，反而可能让性能更差。
第三个约束是「无中间输出依赖」，这个条件最容易被忽略却最关键。在一个融合组里，每个中间结果的唯一消费者必须是下一个即将被融合的算子。如果某个算子的输出除了被下游融合算子消费之外，还同时被图中另一个分支引用，那这两个算子就不能融合——因为融合意味着消除中间结果的显式存储，如果另一个分支需要用到这个中间值，那融合就破坏了图的正确性。autofuse在融合范围识别阶段会检查每个候选算子的所有出边（outgoing edges），只有当所有出边都指向同一个下游算子时，这条融合路径才是合法的。
elementwise算子和reduce算子的融合稍微特殊一些。reduce操作（sum、mean、max等）会把一个维度压缩掉，融合后生成的数据shape和原始elementwise算子的输出shape不再相同。这意味着element+reduce的融合只能在reduce算子只有唯一一个上游输入时才能成立——如果reduce还有其他非融合路径的输入，就无法消除中间结果的存储。autofuse对这类场景做了精细化处理：element+reduce的融合收益在于elementwise计算产生的中间tensor可以跳过HBM写回直接流入reduce单元，减少一次HBM写入和一次HBM读取。
# 融合规则配置示例（elementwise类型之间的融合）fusion_pattern:type:elementwise_chainops:-add-sub-mul-div-relu-sigmoidconstraints:-shape_compatible:true-dtype_match:true-single_consumer:true-memory_layout:NCHWcodegen:template:pointwise_fusion_kernel.cu.j2tiling_strategy:auto_tilingYAML配置把融合规则从C++编译链路中解耦出来，规则可以直接修改而不用重新编译整个项目。约束条件用布尔标签而非硬编码的if-else链，使得新增一种融合模式时只需要追加配置条目，降低了维护成本。codegen字段直接指定代码生成模板的路径，实现了「识别融合机会」和「生成融合代码」两个阶段的清晰分离。
AutoFusion Pass调度：编译期如何自动执行融合
Inductor集成链路
autofuse在CANN软件栈中的接入点不是底层GE（Graph Engine），而是PyTorch Inductor的npu扩展层。具体来说，autofuse通过torchair项目中的inductor_npu_ext模块接入Inductor的编译流程。当用户在一段PyTorch代码里import inductor_npu_ext之后，后续所有torch.compile调用产生的计算图都会经过autofuse的后端处理管线，而不再是原生Inductor的默认流程。
这个集成方式的设计考量在于：Inductor在PyTorch生态中已经是事实标准的图编译基础设施，大量模型直接基于Inductor进行部署优化。把autofuse的融合能力接入Inductor而不是重写一套新的图编译器，意味着不需要用户改变任何已有的模型写法，只需要在代码开头加一行import就能启用自动融合。对于已经在使用torch.compile进行推理加速的团队来说，这个迁移成本几乎为零。
从后向前的扫描策略
AutoFusion Pass的核心调度逻辑并不是一次性对整张计算图做全局优化，而是采用从后向前的扫描策略，逐节点判断是否可以触发融合。这个策略背后有一个很直观的动机：融合的方向总是从下游算子向上游算子扩展——一个ReLU要不要和前面的Conv融合，取决于ReLU是否只有一个上游输入，而ReLU本身是否应该被融合则取决于它是否只有一个下游消费者。从后向前扫描时，每个节点在被处理时都已经有了完整的下游信息，可以就地做出是否参与融合的决策。
具体实现中，这个扫描过程发生在autofuse/codegen目录下的融合图构建阶段。编译器先把原始的计算图转成一张内部表示的融合图（fusion graph），图中的每个节点对应一个待融合的算子候选。每条边标记了算子之间的数据依赖关系和内存layout信息。Pass从前向后来遍历这张融合图，对每个节点执行匹配规则检查：如果当前节点和它的所有下游直接消费者都满足某条融合规则的约束条件，就把它们合并成一个融合节点。合并后的融合节点替代原有的多个节点，继续参与后续的扫描过程。
# AutoFusion Pass的核心调用链（伪代码，基于仓库源码结构）defrun_autofuse_pass(graph):# 第一步：对原始计算图做拓扑排序，从叶子节点开始sorted_nodes=topological_sort(graph,direction='backward')fusion_graph=FusionGraph()fornodeinsorted_nodes:candidates=find_fusion_candidates(node)forpatterninfusion_rules:ifpattern.match(candidates):fused_node=fuse(candidates,pattern)fusion_graph.replace(candidates,fused_node)break# 第二步：对融合后的图做auto tilingfornodeinfusion_graph.nodes:tile_plan=att.AutoTilingGenerator.generate(node)# 第三步：触发代码生成fornodeinfusion_graph.nodes:codegen.GenerateKernel(node,tile_plan)从后向前扫描而非从前往后，是因为融合的扩展方向天然是向下游的——一个新融合节点能否继续向上融合，取决于上游是否还有满足条件的节点可以并入。提前固定扫描方向避免了循环依赖问题。拓扑排序保证了每次处理一个节点时，其所有下游节点的融合状态已经确定，这是一个稳定的事件顺序。
子图替换与代码生成
融合节点确定之后，接下来要做的是把原始计算图中的多个算子替换为单个融合算子。这个过程叫做子图替换（subgraph replacement）。autofuse在替换时并不修改原始图的拓扑结构，而是在融合图的层级上重新生成一个kernel——这个kernel的逻辑等价于原来多个算子的组合，但在内存访问模式上做了针对性优化。
代码生成模块（codegen目录）负责把融合图节点转换为Ascend C代码。它内置了多个Jinja2模板，分别对应不同类型的融合模式：pointwise融合用pointwise_fusion_kernel模板，reduce融合用reduce_fusion_kernel模板，混合类型融合则用mixed_fusion_kernel模板。每个模板里包含了算子融合后的计算逻辑、tiling切分策略、以及内存搬运指令的插入位置。
值得注意的是，融合后的kernel代码不再包含显式的中间结果存储指令。原来Conv算子写出的中间结果直接被ReLU读取，这一步HBM读写在融合后会变成寄存器级别的数据传递——Cube核的计算结果通过cube2v指令直接送到Vector核的输入缓冲区，不需要经过HBM中转。
内存带宽分析与融合收益量化
HBM读写成为推理瓶颈的根本原因
昇腾达芬奇架构的AI Core内部存在两个物理上分离的计算单元：Cube矩阵计算单元负责矩阵乘加运算，Vector向量计算单元负责逐元素运算、归约操作和数据类型转换。在没有融合的情况下，一个典型的CNN推理图包含大量Conv→BN→ReLU→Conv的链式结构。Conv在Cube核上执行，产生的结果必须写回HBM；BN在Vector核上执行，从HBM读入数据；ReLU又在Vector核上执行，再次从HBM读入数据、写回HBM。每个算子边界都意味着一次HBM写入（W）和一次HBM读取（R），HBM的访存带宽成为整个流水线的吞吐量上限。
对于一个包含N个算子的模型图，如果不做任何融合，HBM的读写次数约为2N次（每个算子一次读、一次写）。如果把其中K个连续的算子融合为一个kernel，HBM的读写次数变为2（N-K+1）——中间K-1个算子的边界完全消失，只剩融合组的输出写回和下一组的输入读取。这个削减量随着融合链长度的增加而线性增长，但融合收益并不总是线性的：过长的融合链会导致kernel体积增大，指令缓存（ICache）的命中率下降，Early-Start等并行优化策略的效果也会因为依赖关系变复杂而打折扣。
msprof视角下的融合前后对比
在昇腾NPU上，msprof（Model Studio Profiling）工具是观察内存带宽行为的标准手段。使能autofuse之后，通过设置环境变量TORCH_COMPILE_DEBUG=1可以让Inductor把每个融合算子的中间图结构dump到指定目录，其中以autofused_为前缀的子目录就是融合后算子的白盒结构。打开对应的pbtxt文件，可以看到融合后kernel内部的算子边界已经全部消失，变成了一条单链的计算指令序列。
在msprof的性能分析报告中，最核心的指标是aiv_mte2_time（输入数据从HBM搬运到计算单元的耗时）和aiv_mte3_time（计算结果从计算单元写回HBM的耗时）。在未使能autofuse的单算子场景下，每个算子都有独立的mte2和mte3时间，这些时间累加起来构成了模型推理中相当可观的固定开销。使能融合之后，一个融合算子只产生一对mte2/mte3，但这一对的绝对数值往往也比单个算子时大——因为融合算子处理的数据量是多个算子数据量之和。真正体现融合价值的是总耗时（total_time）的变化：融合后mte2/mte3的次数大幅减少，即便单次mte2/mte3的耗时略有上升，总的内存搬运开销仍然显著低于融合前。
## 融合前后效率对比 | 维度 | 使用前（未融合） | 使用后（autofuse融合） | 差异来源 | |------|----------------|----------------------|---------| | HBM读写次数 | 每个算子独立读写，N个算子约2N次HBM交互 | 融合后减少为约2(N-K+1)次，K为融合链长度 | 中间算子边界消失，中间结果不再写回HBM | | 单算子调度开销 | N个算子产生N次调度指令下发与同步等待 | 融合为K个算子后调度次数减少到(N-K+1) | 减少了K-1次调度头开销 | | 内存带宽利用率 | 每个算子边界触发HBM读写，带宽利用呈脉冲式 | 融合后计算密度提升，单次搬运数据量增加，带宽利用更持续 | 中间数据留在计算单元内部而非HBM | | ICache命中率 | 每个小kernel指令集小，ICache频繁换入换出 | 融合kernel体积增大，ICache预加载机制（ICache Preload）提升命中 | SuperKernel融合组优化策略在autofuse场景的间接收益 | | 推理端到端延迟 | 多个算子串行执行，HBM读写与计算完全分阶段 | 融合kernel内部Early-Start允许计算与搬运指令部分重叠 | 指令级并行减少了流水线空闲 |融合收益的边界在哪里
融合不是越多越好，这在工程实践中是一个容易被忽视的常识。autofuse的融合范围识别阶段会跳过那些融合收益不明显的场景，在日志中打出Fallback aten.xxxx $reason: xx原因信息。常见的跳过原因包括：算子的输出被多个下游消费者引用（违反了single_consumer约束）、shape不兼容需要插入隐式broadcast、算子包含动态shape依赖导致编译期无法确定tiling参数、或者算子组合的代码生成模板尚未实现。
对于那些融合失败的场景，用户可以通过AUTOFUSE_DFX_FLAGS="--codegen_compile_debug=true;--debug_dir=/path-to-dump/"环境变量开启详细日志，逐条分析失败原因。这些日志不仅记录了失败的原因，还包含了编译器在决策点时的中间状态——哪些约束满足了、哪些约束没有满足——有助于工程师判断是融合规则配置问题还是模型本身的图结构问题。
从量化角度评估融合收益，最直接的方法是使用msprof对比同一模型在单算子模式和Inductor+Autofuse模式下的表现。具体操作是：先注释掉torch.compile调用，让模型完全走单算子下发流程，记录所有算子的总耗时；再启用torch.compile并导入inductor_npu_ext，记录融合后所有融合算子的总耗时。两者的差值除以融合前的总耗时，就是这次融合的相对收益比。
在项目中实践autofuse：代码示例与调试
Pointwise算子融合实战
autofuse提供的样例展示了两种最常见的融合场景。第一个样例af_add_ge.py演示了如何将add和ge两个pointwise算子自动融合。
#!/usr/bin/env python3# 导包importtorchimporttorch_npuimporttorch.nnasnn# === 核心：导入 inductor_npu_ext 后，才能走到 Autofuse 后端importinductor_npu_ext# 昇腾 NPU 配置DEVICE="npu:0"torch.npu.set_device(DEVICE)# 构造简单模型classMyModel(nn.Module):def__init__(self):super().__init__()defforward(self,x,y,z):result=torch.ge(torch.add(x,y),z)returnresult# 使能 NPU + Inductor + Autofusemodel=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)# 开启 profilingexperimental_config=torch_npu.profiler._ExperimentalConfig(export_type=[torch_npu.profiler.ExportType.Text],profiler_level=torch_npu.profiler.ProfilerLevel.Level2,aic_metrics=torch_npu.profiler.AiCMetrics.PipeUtilization,)withtorch_npu.profiler.profile(activities=[torch_npu.profiler.ProfilerActivity.CPU,torch_npu.profiler.ProfilerActivity.NPU],on_trace_ready=torch_npu.profiler.tensorboard_trace_handler("./profiling"),experimental_config=experimental_config)asprof:for_inrange(100):result=model(x,y,z)import inductor_npu_ext放在所有业务代码之前是一个隐性约束——Inductor的npu扩展在第一次torch.compile调用时就会初始化融合后端，如果在import之前已经创建了计算图节点，autofuse就看不到这些节点，导致这些算子无法参与融合。fullgraph=True参数强制要求模型图在编译期完全Lowering到Inductor，避免存在未Lowering的ATen算子（这些算子在Lowering失败后会以单算子形式fallback，不经过autofuse后端）。
Elementwise+Reduce融合实战
第二个样例af_mul_reducesum.py演示了pointwise算子和reduce算子之间的融合模式。mul产生的中间结果直接流入sum，不需要写回HBM。
#!/usr/bin/env python3importtorchimporttorch_npuimporttorch.nnasnnimportinductor_npu_ext DEVICE="npu:0"torch.npu.set_device(DEVICE)classMyModel(nn.Module):def__init__(self):super().__init__()defforward(self,x,y):result=torch.sum(torch.mul(x,y))returnresult model=MyModel().to(DEVICE)model=torch.compile(model,dynamic=False,fullgraph=True)x=torch.randn(256,100,device=DEVICE)y=torch.randn(256,100,device=DEVICE)model.eval()experimental_config=torch_npu.profiler._ExperimentalConfig(export_type=[torch_npu.profiler.ExportType.Text],profiler_level=torch_npu.profiler.ProfilerLevel.Level2,aic_metrics=torch_npu.profiler.AiCMetrics.PipeUtilization,)withtorch_npu.profiler.profile(activities=[torch_npu.profiler.ProfilerActivity.CPU,torch_npu.profiler.ProfilerActivity.NPU],on_trace_ready=torch_npu.profiler.tensorboard_trace_handler("./profiling"),experimental_config=experimental_config)asprof:for_inrange(100):result=model(x,y)sum操作会改变tensor的维度，因此mul+sum的融合有一个隐含前提：sum的输出不再参与图中其他计算分支。如果mul的输出同时被其他地方引用，autofuse会拒绝融合这个组合，只让mul以单算子形式存在。设置model.eval()是为了关闭Dropout等训练专属的随机行为，确保profiling结果具有可重复性。
融合图的可视化调试
调试autofuse最有效的方式是将融合后的内部图结构导出到文件，然后用netron.app打开查看。在代码中加入以下环境变量即可：
exportTORCH_COMPILE_DEBUG=1exportAUTOFUSE_DFX_FLAGS="--codegen_compile_debug=true;--debug_dir=/tmp/autofuse_debug/"exportTORCHINDUCTOR_FORCE_DISABLE_CACHES=1执行上述配置后重新运行模型，会在/tmp/autofuse_debug/目录下生成每个融合算子对应的pbtxt文件。这些文件描述了融合后kernel的完整计算图结构——哪些原始算子被合并了、数据在不同计算单元之间的流向、以及tiling切分后的数据块划分。打开pbtxt文件时，netron会将图的节点和边渲染为可交互的可视化界面，每个节点上标注了算子类型和shape信息。
需要特别注意的是，TORCHINDUCTOR_FORCE_DISABLE_CACHES=1会强制每次执行都重新走完整的编译流程，导致首次启动耗时显著增加。这个选项只适合调试阶段使用，生产环境务必去掉，否则每次模型加载都会触发完整的JIT编译。
融合失败的典型原因与排查方法
在实际网络中，融合失败的原因主要集中在以下几个方面。最常见的是图的依赖分支导致single_consumer约束无法满足：模型中的某个算子（比如一个共享的embedding lookup）通常会被多个后续算子同时引用，这种多消费者结构天然无法和任何一个单一消费者做融合。autofuse对这种情况的处理方式是跳过融合、在日志中记录Fallback aten.xxx: multiple consumers，而不是强行融合导致结果错误。
shape不兼容是第二个高频问题。很多网络中存在隐式的broadcast——某层输出的shape是[Batch, 1024, 1, 1]，下一层将其broadcast到[Batch, 1024, H, W]。虽然PyTorch在运行时能自动处理这种broadcast语义，但autofuse的编译期融合无法在不知道实际H和W的情况下生成正确的tiling参数。对于这类动态shape依赖的场景，当前版本的autofuse会选择不融合，以保证编译成功。
第三类问题是代码生成模板缺失。autofuse目前内置的模板覆盖了elementwise+elementwise、elementwise+broadcast、elementwise+reduce等主流模式，但对于concat、gather等更复杂的索引类算子，融合模板尚未实现。如果用户的模型中大量使用了这些尚未支持的算子组合，autofuse的融合覆盖率会显著低于预期。
结尾
graph-autofusion仓库的autofuse模块展示了一条务实的自动化融合路径：不需要用户手动识别融合机会、不需要为每种模型结构重写融合kernel，编译器在图编译阶段自动完成识别、判定和代码生成的全流程。从内存带宽的角度看，融合的核心价值不在于减少总的计算量，而在于把计算单元之间需要经由HBM中转的数据流压缩到寄存器级别——这才是昇腾NPU在Memory Bound场景下真正需要解决的矛盾。autofuse当前支持的融合模式仍有扩展空间，concat和gather等索引类算子的融合模板落地之后，覆盖的模型类型会更加广泛。
仓库链接：https://atomgit.com/cann/graph-autofusion