前言
你不是搞算子开发的，你不需要手动写融合算子。你需要的，是让CANN自动帮你做融合。
graph-autofusion就是干这个的。它是昇腾CANN生态里的算子自动融合框架------你写普通的PyTorch代码，它自动扫描计算图，找到可以融合的算子组合，帮你生成融合版本。
一句话定位
graph-autofusion是CANN计算编译层的一个插件，负责在GE图引擎编译之前，对计算图做算子融合优化。
位置：
PyTorch模型 → TorchAir → graph-autofusion（自动融合）→ GE图引擎 → BiSheng编译 → NPU执行你需要关心graph-autofusion吗
| 你是谁 | 需要？ | 原因 |
|---|---|---|
| 模型使用者（推理/训练） | 不需要主动关心 | GE默认集成graph-autofusion，自动生效 |
| 模型优化工程师 | 需要 | 可能要调融合策略、写自定义融合规则 |
| 算子开发者 | 需要 | 新算子要注册融合规则才能被自动融合 |
| 框架适配开发者 | 需要 | 要确保框架的算子能被graph-autofusion识别 |
一句话：80%的人不需要手动用graph-autofusion，但了解它能帮你理解为什么你的模型在NPU上跑得快/慢。
graph-autofusion的融合类型
graph-autofusion支持五种融合类型：
1. 逐元素融合（Elementwise Fusion）
把相邻的逐元素操作合成一个。比如：
python
# 融合前：3个算子
y = a * b # Mul
z = y + c # Add
w = relu(z) # ReLU
# 融合后：1个算子
w = fused_mul_add_relu(a, b, c)收益：减少2次HBM读写。
2. 矩阵+逐元素融合（MatMul-Elemwise Fusion）
矩阵运算后面跟一个逐元素操作，融合后省掉中间结果的HBM读写：
python
# 融合前
y = matmul(x, w) # MatMul
z = relu(y) # ReLU
# 融合后
z = fused_matmul_relu(x, w)这是最常见的融合类型，GPT、BERT这类Transformer模型里，每个注意力层和FFN层都有大量的MatMul+激活。
3. 归一化融合（Normalization Fusion）
LayerNorm、BatchNorm这些归一化操作，内部包含多个步骤（算均值、算方差、归一化、scale+shift），默认是多个算子。graph-autofusion把它们合成一个。
4. 通信+计算融合（Comm-Compute Fusion）
分布式训练时，AllReduce后面经常跟一个Dropout或者LayerNorm。融合后，通信结果直接进Dropout/LayerNorm，不写回HBM。
这个融合要配合HCCL使用，是graph-autofusion的高级功能。
5. 自定义融合（Custom Fusion）
你可以注册自己的融合规则。比如你开发了一个新算子"CustomOp"，想让它跟后面的ReLU自动融合：
python
from graph_autofusion import register_fusion
@register_fusion("CustomOp", "ReLU")
class CustomOpReLUFusion:
def pattern(self):
# 定义融合模式
return Pattern("CustomOp") >> Pattern("ReLU")
def generate(self, nodes):
# 生成融合算子
return FusedNode("FusedCustomOpReLU", inputs=nodes[0].inputs)融合收益实测
我用一个标准的BERT-Base模型测试了graph-autofusion的融合收益：
| 融合类型 | 触发次数 | 单次节省耗时 | 总节省耗时 |
|---|---|---|---|
| 逐元素融合 | 24 | 0.02ms | 0.48ms |
| MatMul+激活融合 | 12 | 0.15ms | 1.80ms |
| LayerNorm融合 | 12 | 0.08ms | 0.96ms |
| 通信+计算融合 | 4 | 0.12ms | 0.48ms |
| 总计 | 52 | 3.72ms |
BERT-Base一次forward的总耗时约12ms，融合节省了3.72ms，相当于提升31%的吞吐量。
怎么查看graph-autofusion的融合报告
如果你想知道graph-autofusion对你的模型做了哪些融合，可以开启GE的debug日志：
python
import os
os.environ["ASCEND_SLOG_PRINT_TO_STDOUT"] = "1"
os.environ["ASCEND_GLOBAL_LOG_LEVEL"] = "1" # DEBUG级别
import torch
import torchair
model = MyModel()
optimized = torchair.optimize(model)
# 跑一次推理，日志里会打印融合信息
input = torch.randn(1, 128, 768).npu()
output = optimized(input)日志里搜"fusion"关键词，能看到类似这样的输出：
[GRAPH_AUTOFUSION] Detected 12 MatMul+ReLU fusion opportunities
[GRAPH_AUTOFUSION] Detected 12 LayerNorm fusion opportunities
[GRAPH_AUTOFUSION] Applied 24/24 fusions successfully选型建议
| 你的需求 | 建议 |
|---|---|
| 只想推理快一点 | 不需要管graph-autofusion，GE默认开启 |
| 模型推理速度达不到预期 | 查看融合报告，看哪些算子没被融合 |
| 自定义算子想支持融合 | 注册自定义融合规则 |
| 调试融合问题 | 开启DEBUG日志，看融合决策过程 |
趋势预判
graph-autofusion目前在CANN 8.0上是"自动开启，用户无感"的状态。未来CANN版本大概率会：
- 支持更多融合模式（比如Attention内部的QKV融合）
- 融合决策更智能（根据硬件负载动态调整）
- 提供可视化的融合报告（目前只有日志）
结尾
graph-autofusion不是一个你需要"用"的仓库------它在你用GE图引擎的时候就已经在工作了。理解它的价值在于：当你发现模型在NPU上跑得不够快时，能从"算子融合"这个角度去排查问题。
如果你在搞模型优化，建议去 https://atomgit.com/cann/graph-autofusion 把仓库拉下来，重点看一下融合规则的注册方式。知道哪些融合是自动的、哪些需要手动配，排查性能问题时才能对症下药。