AutoFuse

导言

• DeepSeek V4 加大了与Ascend的合作；
• 在华为稼先上的技术报告，除了Ascend C对attention有算子优化；
• 通过pytorch的算子自动融合 AutoFuse 处理一些非常规的计算，可以实现E2E加速31%。并且说可以修改一行之间开启。

故了解相关概念，但是实际上 AutoFuse只适合非常规计算特别多，又没有人力投入的情况，可以考虑AutoFuse。但是对于Qwen3.5 这种优化后就只有一半Matmul/GMM，一半GDN的情况，AutoFuse接入的收益就不足了。

Inductor + AutoFuse 在架构上可以实现 E2E Vector 算子自动融合，但按当前公开文档看，不能认为它已经是开箱可用的产品能力。

更准确地说：

• 技术路线可行：PyTorch Inductor 负责从 PyTorch 图中发现可融合的 pointwise、broadcast、reduce 等计算结构；AutoFuse 负责将融合结构落到 Ascend C IR、Schedule、Auto Tiling 和代码生成。
• 当前公开支持有限：CANN AutoFuse 文档已经描述了“对接 PyTorch Inductor”的路线，但同时说明“当前版本不支持该技术路线”。
• **昇腾 PyTorch 当前推荐路径不是 backend="inductor"**：TorchAir 文档说明，昇腾 NPU 暂不支持 torch.compile 默认的 inductor backend，需要通过 torchair.get_npu_backend() 获取 NPU backend。

因此，如果问题是“现在能不能直接用 Inductor + AutoFuse 跑通端到端 Vector 算子自动融合”，答案是：公开版本下暂不能直接开箱使用。
如果问题是“这条路线能不能设计实现”，答案是：可以，而且是合理的工程方向。

技术定位

Inductor 和 AutoFuse 的分工可以理解为：

PyTorch Program
    |
    | torch.compile / TorchDynamo
    v
FX Graph / ATen Graph
    |
    | AOTAutograd / Decomposition / Functionalization
    v
Inductor IR / Fusion Group
    |
    | Inductor IR -> Ascend C IR
    v
AutoFuse FusedGraph
    |
    | Schedule / Auto Tiling / Codegen
    v
Ascend C Kernel
    |
    | Runtime Launch
    v
NPU 执行

其中：

• Inductor 更偏前端和中端：图捕获、算子分解、循环级 IR、fusion group、索引化简、维度折叠、循环顺序优化。
• AutoFuse 更偏 NPU 后端：自动确定融合范围、生成融合 kernel 源码、Auto Tiling、生成 Host/Device 交付件。
• Vector 算子融合 的核心收益来自减少中间 Tensor 落 GM、减少 MTE 搬运、降低小算子 launch 和调度开销。

公开 PyTorch 文档中提到，Inductor 会把 AOTAutograd 产生的 ATen/Prim 图进一步 lowering 到 loop-level IR，并创建 fusion group、做索引化简、维度折叠和循环顺序调优。CANN AutoFuse 文档则说明 AutoFuse 基于 Ascend C，支持自动融合范围识别、自动算子代码生成、Auto Tiling、动态 shape 和混合精度等能力。

当前边界

当前需要重点区分三种情况。

第一，AutoFuse 本身支持自动融合。

CANN AutoFuse 当前公开文档中说明，AutoFuse 支持的融合大类包括：

• Elemwise
• Broadcast
• Reduce
• Concat

其中 Elemwise 和 Broadcast 在开启 AutoFuse 后默认使能；Reduce 和 Concat 需要通过环境变量显式开启。

示例：

export AUTOFUSE_FLAGS="--enable_autofuse=true;--autofuse_enable_pass=reduce,concat"

第二，AutoFuse 的 Inductor 路线目前未公开支持。

CANN 9.0.0-beta.2 AutoFuse 文档中明确提到存在两条技术路线：

PyTorch Inductor -> Inductor IR 融合结构 -> Ascend C IR 图 -> Codegen

但同一段文档也说明：当前版本不支持该技术路线。

这意味着，虽然“Inductor + AutoFuse”是官方文档中描述过的方向，但在当前公开版本里不能作为可用能力依赖。

第三，昇腾 PyTorch 图模式当前走 TorchAir backend，而不是 Inductor backend。

TorchAir 文档中的示例是：

import torch
import torch_npu
import torchair

config = torchair.CompilerConfig()
npu_backend = torchair.get_npu_backend(compiler_config=config)

opt_model = torch.compile(model, backend=npu_backend)

文档同时说明 torch.compile 默认的 backend="inductor" 在昇腾 NPU 上暂不支持。因此，当前 PyTorch on Ascend 的图模式主路径是 TorchAir/GE，而不是原生 Inductor 后端。

可实现方案

如果要真正实现 “Inductor + AutoFuse E2E Vector 算子自动融合”，需要补齐一条编译链路。

核心工作包括：

1. TorchDynamo 捕获 PyTorch 前向图
2. AOTAutograd 捕获训练场景下的反向图
3. Decomposition 将复杂 ATen 算子降解为基础 Prim/ATen
4. Inductor 生成 loop-level IR 和 fusion group
5. 识别可映射到 AutoFuse 的 vector 子图
6. 将 Inductor IR 转换为 Ascend C IR / AscIR
7. 构造 AutoFuse FusedGraph
8. AutoFuse 完成 Schedule、Auto Tiling、Codegen
9. 编译 Ascend C kernel 并注册运行时调用
10. 对不支持的子图回退到 GE、ACLNN 或 eager

推荐从以下算子模式开始：

Pointwise 链：
    y = sigmoid(x) * scale + bias

Broadcast + Pointwise：
    y = x * gamma + beta

Reduce + Pointwise：
    y = sum(x, dim=-1)
    z = y * scale

Normalize 类结构：
    mean -> sub -> square -> reduce -> rsqrt -> mul -> add

初期不建议一开始覆盖复杂动态控制流、复杂 view、scatter/gather、不规则索引、原地写和别名复杂的训练图。

关键难点

实现难点不在于单个算子，而在于 IR 语义对齐和运行时闭环。

主要挑战如下。

IR 映射

Inductor IR 是 loop-level 表达，关注 loop、index、buffer、stride、shape symbol。AutoFuse/AscIR 需要表达 Ascend C API、搬运、UB、Vector 计算、tiling 结构。两者之间需要稳定的 lowering 规则。

Inductor Pointwise/Reduction
    -> Axis / Size / Load / Compute / Store
    -> AscIR Graph

Shape 和 stride 语义

PyTorch Tensor 支持复杂 stride、view、expand、slice 和非连续内存。Vector 融合要么支持这些 stride 语义，要么提前 materialize 或回退。

融合收益判断

不是融合越多越好。需要考虑：

• UB 容量
• 重计算代价
• 中间结果复用次数
• MTE 搬运量
• shape 大小
• reduce 轴位置
• broadcast 扩展方式
• kernel launch 开销
• 编译时间

动态 shape

AutoFuse 文档中提到其支持动态 shape，但 E2E PyTorch 动态 shape 还需要 Inductor symbolic shape、guard、cache 和 AutoFuse tiling 之间协同。否则容易出现频繁重编译或错误复用。

训练场景

训练场景除了 forward，还涉及 backward 图、梯度累积、view replay、alias、mutation、optimizer。建议先做 inference，再逐步扩展到 training。

工程判断

可以把结论压缩成一句话：

Inductor + AutoFuse 是实现 E2E Vector 算子自动融合的合理架构，但当前公开版本下更像是待补齐的技术路线，而不是已可直接使用的产品功能。

如果目标是当前落地：

• PyTorch on Ascend 当前应优先使用 TorchAir backend。
• AutoFuse 当前可通过 CANN 支持的图编译路径使用，但不等同于 Inductor 路线。
• 如果要自研 Inductor + AutoFuse，需要实现 Inductor IR 到 Ascend C IR 的 bridge、runtime wrapper、fallback 和验证体系。

如果目标是做编译器架构演进：

• Inductor 负责图捕获与融合发现。
• AutoFuse 负责 NPU 亲和的 Schedule、Tiling 和 Codegen。
• 二者结合可以形成比较理想的 PyTorch E2E 自动融合路径。

参考资料

• PyTorch 2.x 文档：Inductor backend、loop-level IR、fusion group 和硬件后端集成说明
  https://docs.pytorch.org/get-started/pytorch-2.0/
• CANN AutoFuse 简介：AutoFuse 基于 Ascend C，支持自动融合范围识别、代码生成、Auto Tiling 等能力
  https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/900beta2/graph/graphdevg/autofuse_1_0000.html
• CANN AutoFuse 使能方式：支持 Elemwise、Broadcast、Reduce、Concat 融合能力及环境变量配置
  https://www.hiascend.com/document/detail/zh/CANNCommunityEdition/900beta2/graph/graphdevg/autofuse_1_0004.html
• Ascend Extension for PyTorch TorchAir 图模式指南：torch.compile 使用 NPU backend，NPU 暂不支持默认 inductor backend
  https://www.hiascend.com/doc_center/source/zh/Pytorch/600/modthirdparty/torchairuseguide/Ascend%20Extension%20for%20PyTorch%206.0.0%20%E5%9B%BE%E6%A8%A1%E5%BC%8F%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97%EF%BC%88TorchAir%EF%BC%8901.pdf