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