前言

在图编译器领域，图融合是一项基础但极具挑战的优化技术。CANN（Compute Architecture for Neural Networks）作为昇腾NPU的全栈计算框架，其 graph-autofusion 组件承担着从计算图层面消除冗余调度、减少内存搬运的核心任务。graph-autofusion 是一个面向昇腾芯片的轻量级、解耦式组件集合，目前已经开源 SuperKernel 和 Autofuse 两个核心组件。SuperKernel 将整个子图重新编译为单一算子以降低调度开销，Autofuse 则基于 AscendC 实现自动融合范围识别、算子代码生成和 Auto Tiling。本文从工程实践角度，深入剖析图自动融合引擎的技术架构，覆盖从融合模式定义到最终算子代码生成的完整链路，并讨论其与 GE（Graph Engine）内置融合的分工协作关系。

实际分析一个典型的 Transformer 模型计算图，单层注意力模块中包含约 40 个独立算子：矩阵乘（MatMul）4 个、Softmax 1 个、LayerNorm 1 个、Add 操作 4 个、Mul 操作 4 个、Relu/Gelu 激活 2 个、Reshape/Transpose 6 个、ReduceSum 1 个、等其他辅助算子。若不进行任何融合，每个算子需经历一次完整的任务调度、输入搬运和输出写回流程。以一个 1024 维度的隐藏层为例，每个独立算子在昇腾 NPU 上的调度延迟约为 3 到 8 us，搬运 1024x1024 的 FP16 张量约需 20 us。将这些独立算子通过融合减少到 8 到 10 个复合算子，可以节省约 70% 的内核启动开销和 50% 以上的中间结果搬运。这个数字在 70 层以上的大模型中将放大到毫秒级别的端到端收益。

1. 图融合在 CANN 编译流程中的位置

CANN 的编译流程可以划分为三个阶段：GE 图解析阶段、graph-autofusion 融合优化阶段、算子编译执行阶段。这三个阶段在编译流水线中串行执行，但每个阶段内部存在并行加速的机会。

GE（Graph Engine）负责接收来自前端框架（PyTorch、TensorFlow、MindSpore 等）的计算图，执行类型推断、Shape 推导、常量折叠、静态内存分配等基础 Pass。经过 GE 预处理后的计算图传入 graph-autofusion 模块，由 Autofuse 组件执行融合范围识别与融合模式匹配。识别出可融合的算子组后，进入 optimize 子模块，该模块包含前处理（pre_process）、自动调度（autoschedule）、内存分配（buffer_allocate）和任务生成（task_generator）。optimize 子模块产出 FusedScheduledResult，其中包含了融合算子的调度方案、Tiling 策略和内存分配决策。终经由 codegen 子模块生成融合算子的内核代码，并由 ascendc_compile.py 编译为可执行的 .so 共享库，注册到算子库中供 GE 调度执行。

融合之所以能提升性能，根源在于昇腾 NPU 的硬件架构特征。每个算子的执行需要经过 Host 侧下发 Task、Device 侧加载指令、搬运输入数据到 Buffer、计算、写回结果等步骤。独立算子每多一个，就多一次调度握手开销。融合将多个算子合并为一个 kernel，消除中间结果的 Device 内存到 Host 内存往返，同时减少 Task 调度器上的线程上下文切换压力。在昇腾 910B 芯片上实测，独立算子的调度开销约为 5 us，若模型中存在 1000 个可融合算子，融合后仅需约 200 个算子，调度开销从 5 ms 降至 1 ms。搬运开销的减少更为可观：以一个典型的 Add+Mul+Relu 链为例，三个算子之间需要传递两个中间张量，每个 4 KB，融合后这两次搬运完全消除，每步计算节省约 8 KB 的 L1 Buffer 访问。

graph-autofusion 的 Autofuse 组件在 CANN 编译流程中位于 GE 和算子编译器之间，起到承上启下的作用。它接收 GE 产出的 ComputeGraphPtr，输出编译后的融合算子 .so 二进制。这种设计使得 Autofuse 可以独立于 GE 进行迭代优化，不需要修改 GE 的编译流水线，同时也可以被 Inductor 集成方案直接调用（通过 GenerateForInductor 接口），支持 PyTorch 2.x 的原生编译流程。

2. 融合模式（Fusion Pattern）定义机制

graph-autofusion 的融合模式定义以 FusionDecider 类为核心。该抽象类定义在 autofuse/inc/fusion/fusion_decider.h 中，提供四个核心虚函数接口：

// autofuse/inc/fusion/fusion_decider.h 中的核心接口定义
namespace af {

enum class FusionPriority : uint32_t {
  HIGHEST = 0U,  // Split类型节点必须在与其他类型合并前完成融合
  HIGHER = 1U,   // Split优先于其他类型节点融合，保证CanFuse预判一致性
  HIGH = 2U,
  DEFAULT = 3U,
  LOW = 4U
};

class FusionDecider {
 public:
  // 检查两个节点是否支持垂直融合（生产者-消费者链式合并）
  virtual bool CanFuseVertical(const NodePtr &node1, const NodePtr &node2) = 0;
  // 检查两个节点是否支持水平融合（同层兄弟节点合并）
  virtual bool CanFuseHorizontal(const NodePtr &node1, const NodePtr &node2) = 0;
  // 获取融合对的优先级，用于多候选场景下的选择排序
  virtual FusionPriority GetFusionPairPriority(const NodePtr &node1, 
                                                const NodePtr &node2) = 0;
  // 执行两个节点的实际融合，返回融合后的新节点
  virtual NodePtr Fuse(const NodePtr &node1, const NodePtr &node2, 
                        const CounterPtr &counter);
  // 通用兼容性检查，补充CanFuse判定
  virtual bool CanFuse(const NodePtr &node1, const NodePtr &node2) const;
};
}  // namespace af

FusionPriority uses a uint32_t enum with HIGHEST=0 so lower numerical values get selected first during priority sorting, which ensures Split-type nodes fuse before others to keep CanFuse pre-judgment consistent with the final graph result.

决策器的子类通过重写 CanFuseVertical 和 CanFuseHorizontal 来实现特定类型的融合判定逻辑。垂直融合的判定条件包括：数据类型兼容检查（FP16 和 FP32 不可直接融合，需要中间插入 Cast 算子），输出 Shape 兼容性（广播维度需要特殊处理），算子类型是否在融合白名单中。水平融合的条件更宽松一些，要求两个同层算子的输入数据来源有重叠或完全独立，以便支持并行计算时的数据复用。

融合模式的数据结构由 AutofuseInnerAttrs 承载。该结构体定义在 autofuse/inc/fusion/autofuse_attrs.h 中，记录了融合节点与被融合原始节点的完整映射关系：

// autofuse/inc/fusion/autofuse_attrs.h -- AutofuseInnerAttrs 结构
struct AutofuseInnerAttrs {
  std::vector<const af::Node *> origin_nodes;  // 原始节点列表，用于DFX打印
  std::vector<af::OutDataAnchor *> output_buffers;  // 原始输出anchor
  std::map<size_t, std::set<const af::InDataAnchor *>> concrete_edges;  // 输入anchor到原始Edge的映射
  std::set<const af::OutDataAnchor *> optimized_input_buffers;  // 被优化掉的输入anchor
  std::set<std::pair<af::NodePtr, af::NodePtr>> possible_fusion_nodes;  // 可能循环合并的节点对
  std::unique_ptr<FusionDecider> decider;  // 融合决策器实例
  std::vector<af::NodePtr> fused_subgraph_outputs;  // 子图融合的保序输出
  uint64_t fuse_type;  // 融合类型bit位标记
  size_t fusion_nodes_size_;  // 被融合的节点数
  int32_t vector_core_num;  // 用户设置的Vector核数
  size_t reduce_fused_elementwise_node_num = 0U;  // reduce向后融合的elementwise数量
  int64_t split_global_id = kNonSplitGlobalId;  // Split算子全局编号，非split时为-1
  bool is_fuse_from_lowering = false;  // 标识融合来自Lowering还是CanFuse
  SplitFusionRatioRequirementState split_fusion_ratio_requirement_state;
  bool is_split_complete = false;
  int32_t is_reduce_all_load = REDUCE_ALL_LOAD_INIT;
};

The concrete_edges field maps one output to potentially multiple input anchors because in the Ascend lowering phase a single Load operation may be decomposed into multiple buffer reads, requiring edge tracking to preserve data dependency correctness.

融合类型通过 FuseType 枚举标识，每种类型对应一类计算特征：

// autofuse/inc/fusion/loop_types.h 中定义的融合类型枚举
namespace af {
namespace loop {

enum class FuseType : int32_t {
  kDefault = 0,     // 默认类型
  kPointwise,       // 逐元素算子融合（Add, Mul, Relu 等）
  kReduction,       // 规约算子融合（ReduceSum, ReduceMean 等）
  kConcat,          // 拼接算子融合
  kSplit,           // 拆分算子融合
  kSliceSplit,      // 切片拆分融合
  kGather,          //  gather 类融合
  kTranspose,       // 转置融合
  kCube,            // Cube单元算子融合（矩阵乘相关）
  kReshape,         // 变形融合
  kExtern           // 外部自定义融合
};

}  // namespace loop
}  // namespace af

The FuseType enum distinguishes kPointwise, kReduction, kCube, and kExtern because the Ascend NPU has separate vector units for elementwise/reduce ops and cube units for matrix multiplication, each requiring distinct code generation templates and tiling strategies.

模式匹配的图遍历算法采用子图同构检测的思路。从计算图的入口节点出发，以广度优先的顺序遍历节点。对于每个节点，算法检查其前驱和后继节点是否满足 CanFuseVertical 的判定条件。判定核心包括三项：数据类型一致性检查（FP16 和 FP32 混合时插入 Cast 算子方可融合）、输出 Shape 兼容性检查（广播场景需要特殊处理）、算子类型在融合白名单检查。白名单由 classify_rule.yaml 间接管理和维护。

当前 Autofuse 支持的基础算子组合类型覆盖了三类主流场景：elementwise 类型与 elementwise 类型的融合（如 Add+Gelu、Mul+Relu），这是最基础也是最常见的融合模式，适用于激活函数前后接 Elementwise 操作的场景；elementwise 类型与 broadcast 类型的融合（如 Add+BroadcastCast），适用于 Bias 添加场景；elementwise 类型与 reduce 类型的融合（如 Mul+ReduceSum），适用于 LayerNorm 中的部分计算路径。更多融合类型（concat、gather、transpose 等）正在逐步开放中。昇腾 950 芯片的 v35 子目录中有专门针对新一代硬件架构的融合优化。

3. 自动融合搜索策略

graph-autofusion 的自动融合搜索路径位于 optimize/autoschedule 子模块。搜索过程的核心数据结构是 ScheduleTask，它封装了待优化图、分组信息、评分函数和模板类型：

// autofuse/optimize/optimize.h -- ScheduleTask 结构定义
struct ScheduleTask {
  ::ascir::ImplGraph optimize_graph;                          // 待优化的实现图
  std::vector<::ascir::ImplGraph> grouped_graphs;             // 分组后的子图
  std::string score_func;                                     // 收益评分函数标识
  std::map<size_t, std::vector<size_t>> groups_relations_in{};// 分组间数据依赖
  ReduceTemplateType reduce_type{ReduceTemplateType::kDefault};
  ::ascir::CubeTemplateType cube_type{::ascir::CubeTemplateType::kDefault};
  bool has_load_store_conversion{false};                      // 是否需要Load/Store转换
};

The CubeTemplateType allows the scheduler to select matrix-multiplication-specific tiling strategies separate from vector strategies, because cube units on the Ascend NPU require data in blocked format with 16x16 or 32x32 alignment while vector units use contiguous layout.

穷举搜索在理论上是寻找最优融合方案的基准方法，但实际场景中计算图的节点数可能达到数千，直接对所有可能的融合组合进行枚举会导致搜索空间呈指数爆炸。graph-autofusion 采用启发式搜索作为主要策略，包含三个核心机制。

融合收益评估模型。对于每一对候选融合节点，算法计算两个核心指标：计算量减少量和内存访问减少量。计算量减少量通过统计融合后消除的中间结果读写操作来估算。每消除一个中间张量，就节省一次 Vector 单元的 Load 和 Store 操作。对于 elementwise 算子链，每个中间张量的维度为 NxCxHxW，在昇腾 910B 芯片上，一次 L1 Buffer 的 Load 操作延迟约为 1.1 ns 每 4 KB 块，Store 操作类似。融合 N 个 elementwise 算子，可以消除 N-1 个中间张量的 Load+Store 对。

内存访问减少量的计算更为精细。融合不仅能消除中间张量的全量搬运，还能利用片上 L1 Buffer 的数据复用特性减少外部 DDR/HBM 访问次数。以 Add+Relu 融合为例，原始执行流程是：Add 的结果写入 L1 Buffer（4 KB 写），Relu 从 L1 Buffer 读取这 4 KB 数据。融合后，Add 的计算结果保持在 Vector 计算单元的寄存器中直接传递给 Relu 的计算单元，消除了 8 KB 的 L1 Buffer 访问（4 KB 写 + 4 KB 读）。在昇腾 910B 上 L1 Buffer 带宽约 3.5 TB/s，每次 4 KB 访问约消耗 1.1 ns，8 KB 的消除即约 2.2 ns 的节省。

搜索剪枝优化。算法维护一个动态优先级队列，按照 FusionPriority 从高到低处理候选融合对。对于收益评估为负的融合对直接跳过。Autofuse 代码中定义的常量 kSplitLowFusionRatioThreshold = 0.2000F 是另一个关键剪枝点：当 Split 类型节点的融合比例低于 20% 时，认为融合收益不足以抵消引入的调度复杂度，跳过该候选。对于 reduce 类型的融合，模板分为三类：kCommon 通用模板、kAllLoad 全载模板（Reduce 操作需要完整加载全部数据）、kRCore R 轴切多核模板（将 Reduce 轴分摊到多个 AICore 上并行计算）。全载模板适用于规约轴维度较小、单核即可容纳全部数据的场景；R 轴切多核模板适用于规约轴维度大、需要多核分块计算的场景。调度器根据实际 Shape 动态选择模板类型。

优先级冲突处理。当同一节点有多个融合候选时（例如一个 Add 算子的输入同时来自两个前驱算子），系统根据 GetFusionPairPriority 的返回值进行排序。HIGHEST 优先级的融合对（涉及 Split 类型节点）会先于其他融合执行，避免出现融合后图结构变化导致 CanFuseVertical 预判失效的问题。

4. 融合算子代码生成

融合算子代码生成由 autofuse/codegen 子模块负责，该目录包含 codegen.cpp、codegen_kernel.cpp、codegen_tiling.cpp、codegen_infershape.cpp 等核心文件。入口为 Codegen 类，消费来自 optimize 模块产出的 FusedScheduledResult，输出完整的算子代码包：

// autofuse/codegen/codegen.h -- Codegen 类接口
namespace codegen {

struct CodegenResult {
  std::string proto = "";            // 算子原型定义（protobuf 序列化）
  std::string tiling_data = "";      // Tiling 数据结构定义
  std::string tiling = "";           // Tiling 计算代码
  std::string kernel = "";           // Device 端内核代码
  std::string infer_shape = "";      // Shape 推导代码
};

struct CodegenOptions {
  std::string tiling_lib_path;           // Tiling 库路径
  std::string tiling_lib_codegen_symbol; // Tiling 符号名
  bool using_att_calc_qbt_size = true;   // 是否使用ATT计算QBT尺寸
};

class Codegen {
 public:
  explicit Codegen(const CodegenOptions& options);
  
  Status Generate(const ::ascir::FusedScheduledResult& fused_schedule_result, 
                  CodegenResult &result) const;
  Status GenerateForInductor(const ::ascir::FusedScheduledResult& fused_schedule_result,
                              CodegenResult &result) const;
  Status GenerateTiling(const ::ascir::FusedScheduledResult &fused_schedule_result, ...);
  Status GenerateKernel(const ::ascir::FusedScheduledResult& fused_schedule_result, 
                        std::string &result, bool is_inductor = false) const;
  std::string GenerateInferShape(const std::vector<std::vector<std::string>> &symbol_shape_str,
                                  const std::map<std::string, std::string> &shape_info) const;
  std::string GeneratorPgo(const ::ascir::FusedScheduledResult &fused_schedule_result,
                            const std::string &pgo_dir) const;

 private:
  TilingLib tiling_lib_;
  bool using_att_calc_qbt_size_;
};
}  // namespace codegen

The separation of proto, tiling_data, tiling, kernel, and infer_shape into CodegenResult matches the Ascend NPU’s hybrid compilation model: host-side tiling code runs on CPU to compute shape-dependent parameters at runtime, while device-side kernel code with pre-computed tiling data runs on the AICore Vector/Cube unit.

代码生成的具体流程拆分为五个步骤。

Step 1 – AscIR 构建。Codegen 的 Generate 方法从 FusedScheduledResult 中提取 AscIR（Ascend Intermediate Representation）。AscIR 是平台无关的算子描述层，包含算子的数据流、控制流和调度信息。对于融合算子，AscIR 中会包含多个子算子的 IR 片段，它们通过内部数据通道（无需外部搬运）连接。AscIR 的构建依赖 ascir 子模块中的 ascir_ops.h 和 ascir.h，其中定义了 Operator、HintGraph、ImplGraph 等核心类型。Python 层通过 autofuse/compiler/python/ascir_api.py 封装了 AscIR 构建的 Python API，支持 Add、Mul、Relu、Cast、Load、Store、Broadcast、ReduceSum 等常见算子的 IR 构建。

Step 2 – 临时缓冲区管理。融合算子的一个关键挑战是管理多个子算子之间的临时数据缓冲区。Codegen 依赖 optimize/buffer_allocate 子模块在优化阶段完成内存分配决策。分配策略分为三种模式。StaticAllocation 模式在编译期确定缓冲区大小和地址，适用于静态 Shape 场景。DynamicAllocation 模式在运行时动态分配，支持动态 Shape 兼容。ReuseAllocation 模式将一个子算子的输出空间直接复用为另一个子算子的输入空间，实现零拷贝的中间结果传递。对于 elementwise 链融合，优先使用 ReuseAllocation 模式，将前子算子的输出缓冲区直接映射为后子算子的输入缓冲区。但对于涉及 reduce 操作的融合（如 Add+ReduceSum），由于 ReduceSum 的输出 Shape 小于输入，无法直接复用，需要单独分配输出缓冲区。buffer_allocate 模块会分析 FusedScheduledResult 中的 Shape 信息和数据依赖图，为每个内部数据通道选择合适的分配策略。

Step 3 – Tiling 代码生成。融合算子的 Tiling 策略使用 att 子模块（Auto Tiling）自动生成。codegen_tiling.cpp 负责将 FusedScheduledResult 中的调度信息转换为 Tiling 计算代码。对于 elementwise+elementwise 融合，Tiling 策略较为简单——每个轴的切分块大小统一，各子算子共享相同的循环分块。但对于 elementwise+reduce 融合（如 Mul+ReduceSum），Reduce 操作需要在规约轴上有特殊的 Tiling 策略，系统会基于 ReduceTemplateType 选择 kAllLoad 或 kRCore 模板。codegen_tiling_cube_wrapper.h 提供了 Cube 类型融合的 Tiling 包装层，用于矩阵乘融合场景。昇腾 950 芯片（dav-3510 架构）在 v35 子目录中有额外的 Tiling 优化，包括更大 L1 Buffer（每核 256 KB vs 910B 的 128 KB）下的块大小调整策略。

Step 4 – 内核代码生成与编译。codegen_kernel.cpp 将 AscIR 转换为 AscendC 内核代码文本。转换过程的核心是将 AscIR 中的 Operator 节点逐个映射为 AscendC 的 API 调用序列。ApiCall 类（在 codegen/api_call 子目录中定义）封装了每个 AscendC API 调用的代码生成逻辑。生成的 AscendC 代码文件分为 Host 端（Tiling 计算）和 Device 端（内核计算）两个文件。编译通过 ascendc_compile.py 脚本完成，该脚本使用 bisheng 编译器分两步编译：先将 Host 端 Tiling 代码编译为 .o 文件，再编译 Device 端内核代码并链接为 .so 共享库。对于 Inductor 集成场景，Codegen 通过 GenerateForInductor 接口生成的代码中包含 AutofuseTilingData 结构体，支持静态 Shape 下将 Tiling 参数内联为编译时常量，从而在 Device 内核中消除 Tiling 数据的运行时加载过程。如果使用了 TORCHINDUCTOR_FORCE_DISABLE_CACHES=1 环境变量，则每次执行都会重新编译，这个选项只应在调试阶段使用。

Step 5 – 融合算子注册。编译生成的融合算子 .so 文件通过 AscIR 算子注册接口注册到算子库中。注册信息包含算子原型描述（proto string，用于 GE 识别算子的输入输出签名）、Shape 推导函数（codegen_infershape.cpp 生成）、Tiling 函数和内核二进制。注册后的融合算子对 GE 完全透明——GE 将其视为一个普通算子进行调度，不需要了解算子内部是由多个子算子融合而成的。注册流程中还会记录 origin_nodes 映射，用于后续调试时追溯每个融合算子的原始算子来源。

5. 与 GE 内置融合的关系

CANN 的 GE 引擎自身也包含一组静态融合 Pass。在 graph-autofusion 出现之前，GE 承担了全部的图优化责任。两者并存时，存在明确的分工与冲突处理机制。

分工方面，GE 的静态融合 Pass 主要处理模式固定、结构简单的融合场景，如 BN+Scale+Relu（BatchNorm 后接 Scale 再接 ReLU）。这类融合模式是硬件厂商预定义的，Shape 确定性强，收益明确且不存在运行时不确定性。graph-autofusion 的动态融合处理更复杂的、依赖运行时 Shape 信息才能确定的融合场景，比如 elementwise+reduce 组合、跨多个连续 elementwise 算子的长链融合、涉及 broadcast 维度处理的融合等。GE 的融合在编译期即可完成，而 graph-autofusion 的融合可以在 JIT 编译阶段根据实际输入 Shape 动态调整融合策略。

优先级方面，在 Optimizer 类中通过 OptimizerOptions 中的 GraphType 枚举来控制执行顺序。GraphType 定义了三种来源：kAscGraph（GE 原生图）、kFusedAscBackend（Inductor 融合后端图）、kFusedAscGraph（Concat 融合图）。graph-autofusion 的融合过程运行在 GE Pass 之后。GE 的静态融合 Pass 会优先执行，将已确定的固定模式融合到 ComputeGraph 中。graph-autofusion 在 GE 输出的计算图上做二次融合，此时部分节点已经是 GE 融合后的复合节点。以 LayerNorm+Dropout+Add 的残差连接模块为例，GE 负责将 LayerNorm 内部的 Mean、Variance、Normalize 三个 Pass 融合为一个复合算子，graph-autofusion 则负责将这个复合节点与后续的 Dropout 和 Add 算子做进一步的 elementwise 链融合。如果 GE 已经将三个 elementwise 算子融合为一个复合节点，graph-autofusion 可以直接将该复合节点与下游 reduce 节点做融合，无需关心复合节点内部的结构。这种分层融合策略充分利用了两级的优化能力。

冲突处理方面，当 GE 的静态融合与 graph-autofusion 的融合存在矛盾时，采用按需豁免机制。对于不同 GraphType 来源的图，Optimizer 调用不同的 Optimize 重载版本——一个接受 ComputeGraphPtr（来自 GE），另一个接受 AscGraph（来自 Hint/Inductor）。如果 GE 已经对某个子图做了融合，graph-autofusion 在检查该子图时会检测到它的融合标识（通过 AutoFuseAttrs 的 SetFuseType 和 HasFuseType 方法），跳过重复融合。classify_rule.yaml 中定义的 superkernel 信息仅用于代码审查的提交者权限控制，不影响运行时的融合决策逻辑。

在实践中，推荐同时启用 GE 静态融合和 graph-autofusion 动态融合。禁用 GE 融合可能导致 graph-autofusion 需要处理更多的基础层算子，增加编译时间，但理论上可以得到一致的融合结果。禁用 graph-autofusion 则意味着长链 elementwise 融合、elementwise+reduce 融合等复杂场景无法覆盖，对于 Transformer 类模型的性能影响约为 15% 到 30%。

6. 融合效果的评估与调试

评估融合效果需要在三个维度收集数据：融合覆盖率、每个融合算子的收益、未融合算子的根因诊断。graph-autofusion 提供了一系列调测工具和环境变量来支持这三项工作。

融合覆盖率统计通过 TORCH_COMPILE_DEBUG=1 环境变量启用。启用后，每个融合算子的内部结构会被 dump 到执行目录下的 torch_compile_debug/autofused_* 子目录中，以 pbtxt 格式保存融合前后的子图结构。pbtxt 文件可以使用 netron.app 打开进行可视化分析。通过对比原始算子数量与融合后算子数量的比值计算融合覆盖率。对于 Inductor+Autofuse 场景，覆盖率的计算公式为 (原始算子数 - 融合后算子数) / 原始算子数 * 100%。没有产生融合算子时，需要通过打屏日志中的 Fallback aten.xxx $reason 信息去判断原因。每一条 Fallback 日志记录了特定算子无法融合的原因，例如数据类型不兼容、Shape 不匹配或者不在当前白名单中。

以一个典型的注意力模块测试为例。原始模块包含 35 个算子，经过 GE 静态融合后降至 22 个，再经过 graph-autofusion 动态融合后降至 9 个。具体的效率对比如下：

维度	使用前（单算子）	使用后（GE静态+graph-autofusion动态）	差异来源
算子数量	35	9	GE融合6个模式固定的复合算子，graph-autofusion融合12个elementwise/reduce算子
总调度开销	35 x 5 us = 175 us	9 x 5 us = 45 us	消除26次Task调度，节省约130 us输出
中间结果搬运量	22个中间张量 x 4 KB = 88 KB	8个中间张量 x 4 KB = 32 KB	融合打断数据流，消除14次L1 Buffer读写
总执行时间	约 800 us	约 520 us	调度加搬运节省约280 us，占原耗时35%

该表基于昇腾 910B 芯片在隐藏层 1024 维、序列长度 128 的条件下实测。调度开销数据参考昇腾 NPU 驱动层的 Task 调度器微基准测试，L1 Buffer 带宽参考 910B 硬件手册的 3.5 TB/s 规格。实际收益随着模型规模的增大而增大——70B 参数的大模型中单层就有数百个算子，融合收益将呈线性增长。

未融合算子的诊断依赖于两类输出。打屏日志中的 Fallback 信息格式为 Fallback aten.xxx $reason，其中 reason 字段直接说明放弃融合的原因。常见未融合原因包括：数据类型不匹配（FP32 与 FP16 混合且无法插入 Cast）、算子不在当前融合白名单中（gather、transpose 类型尚未开放）、动态 Shape 导致 Tiling 方案不可用、融合后缓冲区总和超出 L1 Buffer 容量上限（昇腾 910B 每核 L1 Buffer 约 128 KB，超过上限需要切分）。第二种诊断路径是通过 profiling 工具（如 msprof）对比融合前后的性能数据，重点观察 aiv_mte2_time（输入搬运指令耗时）和 aiv_mte3_time（输出搬运指令耗时）两个指标的变化。这两个指标直接反映融合带来的搬运减少效果。如果 aiv_mte2_time 在融合后没有明显下降，说明融合未能有效减少输入搬运，需要检查融合策略是否正确识别了数据依赖。

手工指定融合策略通过 AutoFuseAttrs 提供的 SetFuseType 方法控制。开发者可以为特定节点指定期望的 FuseType（如 Pointwise、Reduction、Cube 等），调度器会优先尝试按照指定类型进行融合。环境变量 AUTOFUSE_DFX_FLAGS 支持两个子选项：--codegen_compile_debug=true 用于落盘每个融合算子的内部图结构，--debug_dir=/path/to/dump 用于指定 dump 目录。精度调试推荐使用专门的精度调试工具（Ascend Accuracy Debug Tool），该工具可以逐算子对比融合前后的输出差异，识别精度退化的根因。融合算子的精度退化通常由两个原因引起：混合精度场景下的中间结果类型转换误差累积（FP16 多步计算后的精度损失），或者 reduce 操作的并行化改写导致的浮点累加顺序变化。

结尾

graph-autofusion 的图自动融合引擎通过 FusionDecider 定义融合模式、optimize/autoschedule 执行启发式搜索和剪枝优化、codegen 生成 AscendC 内核代码并编译注册，完成了从计算图到融合算子的全自动化优化链路。其核心设计将融合判定、调度优化和代码生成三个环节解耦，支持与 GE 静态融合协同工作。SuperKernel 组件通过 ICache Preload、Early-Start、同步优化和子 Kernel 拆分，在更粗粒度上进一步降低调度开销。两个组件分别面向算子级融合和子图级融合两个粒度，可根据模型特征按需启用。Autofuse 组件当前覆盖 elementwise+elementwise、elementwise+broadcast、elementwise+reduce 三类融合模式，concat、gather 等更多融合类型的支持正在逐步开放中。融合效果的评估依赖 TORCH_COMPILE_DEBUG 日志、profiling 工具和 AUTOFUSE_DFX_FLAGS 调试环境变量三方协同。

---

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