1. 先从一张计算图说起：为什么我们需要图融合引擎
1.1 一个几乎所有人都会遇到的性能瓶颈
跑过昇腾平台模型训练或推理的朋友，大概率见过类似场景：写好的网络模型在 GPU 上跑得飞快，一迁移到昇腾 NPU 上，却发现性能怎么调都不对劲。算子耗时看着不高，但整体吞吐就是上不去。这时候打开 profiling 数据，你会看到大量极小耗时、极低利用率的算子密密麻麻排在时间轴上——问题往往出在计算图的“碎片化”上。
我在实际项目里遇到过最典型的一个案例：一个基于 Transformer 的推荐排序模型，原始 ONNX 导出后包含 470 多个算子节点。其中像Add、Mul、Cast、Transpose这类小算子占比超过 60%，单个算子执行时间只有几微秒，但调度开销、显存读写开销全都算进去之后，整体推理耗时愣是被这些小算子拖慢了近三倍。当时我第一个反应是“手动融合优化”——把相邻小算子合并成自定义算子。结果呢？模型是优化了，但换来的是脚本库爆炸、跨平台迁移困难、维护成本直线上升，而且换一个模型结构又得重新来一遍。
这就是图融合引擎存在的根本原因：让框架自动完成算子合并与图结构优化，而不是靠开发者手工去“缝缝补补”。
1.2 图融合到底在解决什么
先理清一个概念。计算图是深度学习中描述网络结构的数据结构：节点是算子，边是张量数据流。在理想情况下，每个算子都对应一次底层 kernel 执行。但真实情况是，框架层的算子粒度往往很细，NPU 执行这些细粒度算子效率非常低——因为每次 kernel 启动都有固定开销，每笔中间张量的写出和读入都有带宽成本。
图融合引擎做的事情，通俗点说，就是把计算图中可以合并执行的多个算子“捏”成一个更大的算子，减少 kernel 启动次数、减少中间张量的显存读写、提升计算密度。这里面的核心技术难点在于：什么算子可以合，什么不能合，以及怎么个合法。
CANN 的图融合引擎，配合graph-autofusion这个自动融合组件，正是昇腾平台解决上述问题的核心武器。它不只是在做简单的算子合并，更是一整套从图结构分析、模式匹配、收益评估到代码生成的优化流水线。这篇文章我结合自己的实际使用经验，把 CANN 图融合引擎的架构逻辑、核心优化范式、常见坑点拆开聊聊。
2. 架构视角拆解：CANN 图融合引擎到底由什么组成
2.1 融合引擎在整个 CANN 中的位置
要理解图融合引擎，得先明确它在 CANN 软件栈里的定位。CANN 的完整链路是：AI 框架（TensorFlow / PyTorch / MindSpore）→ 图编译器（GE，Graph Engine）→ 算子编译器（TBE / DSL）→ 运行时（Runtime）→ NPU 硬件。
图融合引擎属于 GE 层的关键能力，它工作在中间表示（IR）层面，输入是框架产出的计算图，输出是经过优化后的计算图。这层优化的核心输入不只包括图结构，还包括算子属性、张量 shape、数据类型、数据排布等信息。
graph-autofusion 在社区版本里体现为一套基于规则与模板的自动融合模块。它的名字很直白——graph + auto + fusion，即“计算图级别的自动融合”。它不是替代人工融合，而是把人工融合的经验规则化、模板化，然后自动套用到任意计算图上。
2.2 四大核心模块的分工
从实测和我阅读源码的经验来看，graph-autofusion 的逻辑架构大致可以拆成四层：
第一层是图预处理与规范化。融合引擎首先对输入计算图做规范化处理，包括算子类型统一、冗余节点消除、常量折叠、死节点消除等。这一层的主要目的不是融合，而是“清洗”——把不规范的图结构调整为标准形态，方便后续模式匹配。如果这层不做干净，后续融合规则很容易漏配或误配。
第二层是融合模式匹配。这是整个引擎的核心。系统内置了大量融合规则，每条规则本质上是“图结构子图模板 + 匹配条件 + 融合动作”的元组。比如一个经典规则：相邻的Conv2D + Bn + Relu三段结构，匹配为单算子ConvBnRelu。匹配过程会遍历计算图的所有节点，对每个节点尝试以它为起始节点进行子图匹配，命中规则后记录匹配结果。
第三层是收益评估。匹配成功并不代表一定要融合，融合引擎还会做代价模型分析——评估融合前后的理论耗时差异。基于昇腾底层算子的 cost model，估算出 kernel 启动开销节省了多少、中间张量读写减少多少、L2 cache 命中率提升多少，综合比较后再决定是否真正执行融合。
第四层是融合执行与代码生成。确定融合方案后，引擎会对匹配到的子图进行合并替换，生成新的融合算子节点，并更新数据依赖关系。若融合算子需要新的算子实现，则触发 TBE 算子自动生成流程，把融合逻辑编译成 NPU 可执行的 kernel。
在我实际使用中，这四层里最值得关注的是第二层和第三层。很多情况下模型编译时间特别长，就是因为匹配规则太多；而编译后性能提升不明显，则往往是因为收益评估太保守或者过于乐观。
2.3 graph-autofusion 在生态中的三种使用姿势
结合 CANN 的多种编译入口，graph-autofusion 并不只有一种调用方式。我总结了三种：
一种是框架默认开启。在 TensorFlow 1.15 的tf.session配置或 PyTorch 的torch_npu适配层中，图编译过程默认会走 GE 的优化流程，融合引擎自动生效。这是大多数用户无感知使用的方式。
一种是通过 AOE 工具辅助调优。AOE（Ascend Optimization Engine）是昇腾提供的专门调优工具，它会结合具体模型和实际硬件跑一些样本数据，通过感知式搜索找到更优的融合配置。和默认规则相比，AOE 更“个性化”，但代价是需要额外跑调优流程。
还有一种是自定义融合规则。高级用户可以基于 CANN 提供的融合规则接口，注册自己的融合模板。这种方式门槛较高，适合对底层执行细节非常熟悉、且默认规则无法满足需求的团队。我自己在自定义算子场景下用过这种方式，收益明显，但调试成本也不低。
3. 核心优化范式：那些最有价值的融合模式
3.1 小算子合并：最基础也最实际的收益
图融合引擎最朴素也最常用的能力，是消除“碎片算子”。典型场景是这样的：框架自动生成的图里，有很多只做逐元素运算的小算子，例如Add、Mul、Relu、Cast，以及各种Transpose、Reshape之类的搬数据算子。
在 NPU 上，单个逐元素算子的计算量和内存搬移量往往不成比例——“算得少、搬得多”。把这些算子合并成一个融合算子后，中间结果直接留在片上缓存，不再下到全局内存，节省非常可观。
我做过一个实验：对一个包含 30 多个小算子的图（只有全连接层、激活、dropout 等基础结构），不开融合时 NPU 利用率仅 32%，开启融合后利用率提升到 58%，端到端延迟降低 41%。最关键的是，模型代码一行没改，只是编译期自动完成的优化。
3.2 卷积类融合：Conv+Bn+Relu 及其变体
昇腾平台上最有代表性的融合模式之一，就是卷积相关算子链的融合。以Conv2D + BatchNorm + Relu为例，未融合时需要执行三次 kernel，中间张量在片上搬运两次、全局内存写读两次甚至更多。融合成单个算子后，一次 kernel 完成全部计算。
这类融合还包含各种变体：Conv + Relu、Conv + Bn、Conv + Add + Relu（残差结构）、DepthwiseConv + Bn + Relu等。在 ResNet 系列、MobileNet 系列、以及各种轻量化网络上，这类融合往往是收益最大的优化点。
值得留意的是，融合Bn算子时引擎会做“参数吸收”：把 BatchNorm 里的 scale、shift、mean、variance 这些参数，在编译期拆解并合并进卷积的权重和偏置里。这样不仅省了一次 kernel 执行，还省掉了推理时对 Bn 参数的运行时计算。这种优化对推理场景尤其重要，因为推理时 Bn 已经固定，不需要考虑训练时的 batch 统计量更新。
3.3 大算子组合融合：Transpose+MatMul 与注意力结构的专项优化
Transformer 结构在昇腾上大规模部署后，图融合引擎增加了很多针对注意力机制的专项融合模式。例如Transpose + MatMul + Softmax + MatMul这种典型的注意力计算链，在一段时间里是性能热点。
默认情况下，每一步都会产生完整的中间张量：Q 和 K 矩阵乘后的 scores 是[B, Head, L, L]的大矩阵，Softmax 要读一遍写一遍，第二次 MatMul 再读一遍。这么来回倒腾，带宽压力非常大。
融合引擎的优化思路是：把QK^T计算和 Softmax 融合在同一个 kernel 中，Softmax 所需的 row-max 和 row-sum 直接在片上计算，不必把完整的 scores 矩阵写回全局内存；或者更激进一点，把整个 attention 子图融合成一个融合算子。我在 35B 参数规模的生成模型上实测过，融合后的 attention 子图相比未融合版本能带来约 25% 的端到端加速，显存峰值也明显下降。
3.4 算子下沉与异构执行：利用硬件特性做更大尺度的优化
除了常规的算子合并，CANN 图融合引擎还有一种重要范式——算子下沉。所谓下沉，是指把原本由框架调度的多个算子“下沉”到硬件执行单元直接连续执行，减少主机侧的调度开销。
这个概念可以打个比方：厨师做菜时，不是每做完一道工序就跑到大厅汇报一次再回来做下一道，而是一次性把所有工序交代完，后厨连续做，最后统一出菜。算子下沉就是这种“一次性交代”的机制。
与算子下沉配合的还有异构执行策略：图融合引擎会根据算子特性，把适合 CPU 执行（如数据预处理、形状推导）和适合 NPU 执行的算子分配到不同设备上，最大化并行效率。这类优化通常对整体 pipeline 的影响很大，尤其在多卡推理场景下能明显降低 host 侧的瓶颈。
4. 实操：如何正确开启、验证与评估图融合效果
4.1 环境准备：版本选择与必备工具
要做图融合相关的实践，首先要选对 CANN 版本。我建议优先使用社区长期支持版本（如 5.1.x 或 6.x 系列），因为它们对 PyTorch 和 TensorFlow 的适配最成熟，图融合规则也更全。过老的版本缺乏很多新融合模式，而太新的版本可能存在社区适配滞后问题。
必备环境组件包括：CANN Toolkit、对应框架的适配插件（如 torch_npu）、以及 profiling 工具（msprof / CANN 自带的 msprof 工具链）。如果参加 CANN 挑战赛这类活动，官方通常会提供镜像环境，注意核对镜像里的 CANN 小版本号与实际代码匹配，不匹配时编译报错会非常隐蔽。
安装完成后，可以用一段极简的示例模型验证环境：
import torch import torch_npu class SimpleNet(torch.nn.Module): def __init__(self): super().__init__() self.conv = torch.nn.Conv2d(3, 64, 3, padding=1) self.bn = torch.nn.BatchNorm2d(64) self.relu = torch.nn.ReLU() def forward(self, x): return self.relu(self.bn(self.conv(x))) model = SimpleNet().npu() x = torch.randn(8, 3, 224, 224).npu() y = model(x) print(y.shape)这段代码能跑通，说明基础链路是通的。之后就可以打开 profiling 看融合情况了。
4.2 通过 profiling 验证融合是否生效
图融合是否真的生效，不能只看端到端耗时——耗时受很多因素影响。最可靠的验证方式是看 profiling 数据里的算子列表。以 msprof 为例：
msprof --application="python test_model.py" --output=./prof_data跑完后打开 timeline 视图，观察算子序列。如果融合生效，你会看到类似FusedConvBnRelu、FusedMatMulSoftmax之类的融合算子名，而不是拆开的Conv2D、BatchNorm、Relu依次排列。另外，算子总数会明显减少。未融合时可能有三四百个节点，融合后可能压缩到一百多个甚至几十个。
还要关注两个指标：一是 NPU 利用率（ai core utilization），融合后应该有所提升；二是 HB 内存读写量（HBM bandwidth），融合后中间张量减少，HB 读写的总量通常会降低。这两个指标配合算子列表，基本能确认融合是否达到了预期。
4.3 手动关掉融合，感受差距
为了更直观地理解图融合带来的收益，建议做一个对比实验：通过环境变量或配置文件关掉融合，然后对比同一模型在相同输入下的性能。
在 CANN 中，可以通过设置如下环境变量来控制不同层面的优化：
# 关闭图融合（具体变量名以版本文档为准） export DISABLE_FUSION=1 # 或通过 GE 配置传入跑一遍同样模型：
python test_perf.py --disable-fusion python test_perf.py --enable-fusion对比两者的耗时、算子数量、内存占用。我通常会把这种对比结果输出成表格并归档到项目文档中，后续做性能回归时直接拿来对照。之前在某推荐模型上做这个对比时，差距非常明显：融合开启后算子数从 470 降到 96，P99 延迟从 23ms 降到 11ms，效果立竿见影。
4.4 用 AOE 做感知式自动调优
默认融合规则是通用策略，对特定模型可能不是最优解。要榨取更大性能，可以跑 AOE 调优：
# AOE 调优配置示例 aoe --framework=5 --model=./model.onnx --job_type=2 --output=./aoe_resultAOE 会尝试多种融合策略，在目标硬件上实测效果，选出最优配置。整个过程可能比较耗时（视模型大小从十分钟到数小时不等），但收益值得。我在一个分割模型上试过，AOE 调优后比默认融合再提升约 12% 的推理速度。
需要提醒的是，AOE 的调优结果只在相同硬件型号、相同输入 shape 下最可靠。换硬件型号或改模型输入尺寸后，原来的最优配置不一定仍然最优，需要重新调。
5. 常见踩坑经验与排查技巧
5.1 编译时间暴增，是不是融合的锅
图融合引擎在编译期要做大量模式匹配和收益评估，模型复杂时编译时间可能从几十秒涨到几分钟。很多人误以为编译卡死了，其实只是在做融合搜索。
排查方法是看编译日志。CANN 的 GE 日志中会打印融合执行过程，如果出现 “Start to fuse graph ...” 之类的日志，说明正在融合阶段。如果编译时间呈指数级增长，可能是融合规则匹配复杂度偏高。此时可以通过配置控制参与融合的算子范围，或者跳过某些收益不大的融合规则。
我遇到过一种情况：输入模型包含动态 shape，引擎在收益评估阶段对每个 shape 组合都要做成本分析，导致编译时间暴增。后来通过固定输入 shape（例如用静态 shape 导出 ONNX）就明显缓解了。
5.2 融合后结果不对，精度异常
融合虽然通常只涉及计算顺序调整和中间结果复用，理论上对精度影响极小，但某些激进融合（例如对数值范围敏感的算子）可能导致精度下降。最常见的是混合精度场景下，Bn参数吸收后因为浮点运算顺序变化，引入了微小误差。
遇到这类问题时，第一步不要怀疑融合引擎有 bug，先把融合关闭，确认是不是融合导致的精度差异。如果是融合导致，第二步用 profiling 定位是哪个融合算子引起的——尽量把问题范围缩小到单算子级别。有时候问题不是融合本身，而是融合后算子实现存在数值边界问题（例如对极大值做 softmax 时精度处理不当）。此时可以考虑对这个特定子图禁用融合，或者升级 CANN 版本看是否已修复。
5.3 动态 shape 场景下融合失效
动态 shape 是图融合的天然敌人。当输入尺寸在运行时才能确定，很多融合模式要么无法匹配，要么生成的融合算子过于保守。比如在 NLP 模型里，内层MatMul的 shape 依赖序列长度，就经常导致注意力子图的融合失效。
我的经验是：推理场景尽量做 shape 固定化处理。比如用torch.jit.freeze或导出 ONNX 时固定序列长度，把动态维度用 padding 补齐。这样一方面让融合引擎有更多发挥空间，另一方面也能减小编译开销。如果业务上确实无法接受固定 shape，那就需要对关键子图做针对性优化，例如手工实现融合内核来代替融合引擎的工作。
5.4 融合后性能反而下降
融合并不是免费的午餐。在某些场景下，融合后的算子因为计算密度太高，反而导致 cache 压力增大或寄存器溢出，性能不升反降。我在实践中遇到过一个融合后性能退化的典型案例：把两个Large MatMul简单拼接成一个融合算子，结果中间结果在片上放不下，反而不如拆开分步执行流畅。
所以融合也要讲究“合适就好”。收益评估模块存在的价值就在这——不是所有能融合的都该融合。如果你发现某个融合点导致性能下降，可以通过融合白名单/黑名单机制，把这个融合规则单独禁用，保留其他有效优化项。这需要比较细致的 profiling 数据支撑，不能凭感觉拍板。
另外特别提醒：性能对比实验要在同一硬件、同一驱动版本、同一输入分布下进行，否则结论很容易失真。我习惯每轮实验都记录 CANN 版本、固件版本、模型 commit 号，方便复现和追查问题。
6. 挑战赛视角：如何将图融合知识转化为实战优势
6.1 学习路径建议
如果你想系统学习 CANN 图融合引擎，不要一上来就啃源码。我的建议是先跑通完整链路——用一个小模型在昇腾上完成训练或推理，再用 profiling 查看融合效果，建立“图变换会影响执行性能”的直观认知。然后看官方文档中针对图融合的章节，了解哪些融合模式是内置的。
接着可以尝试用不同结构的模型（CNN、Transformer、轻量化网络）分别统计融合前后的算子数和耗时变化，发现不同模型的融合收益差异。最后再深入源码，看具体规则的匹配条件与收益评估逻辑，这时候你的问题会非常有针对性。
6.2 比赛中最容易拿分的方向
当前 CANN 相关的开发者活动越来越多，比如 CANN 挑战赛这类面向开发者的实战活动。在这类比赛中，图融合通常不是一个单独赛道，但它常常是性能优化类任务的核心支撑技术。
如果你要参加模型迁移或性能优化类赛题，我的建议是：先建立一套完整的 profiling 基线，把未优化前的耗时、算子数、内存占用全量记录下来。然后从大算子下手——先看看有没有明显的低效子图可以融合，再看小算子的合并情况。通常对 Transformer 类模型，注意力子图是最大热点；对 CNN 类模型，卷积相关链是最大热点。
图融合调优切忌盲目试错。正确的做法是基于 profiling 定位热点子图，针对性分析该子图的融合潜力，然后验证效果。每一轮优化后重新 profiling，用数据驱动下一步决策。很多参赛团队吃亏在没有基线数据支撑，凭感觉调参，最后既浪费时间又难以令人信服。
6.3 一个可复用的优化检查清单
我把日常做图融合优化的经验整理成一份检查清单，分享出来供参考：
- 是否确认当前 CANN 版本与框架适配版本匹配
- 是否已在 profiling 数据中确认融合是否生效
- 是否已对比融合前后的算子数量、耗时、HB 读写量
- 是否已确认输入 shape 静态化（如无法静态化，是否已有针对性方案）
- 是否对热点子图确认了最优融合策略（默认规则还是 AOE 调优）
- 是否记录了 CANN 版本、硬件型号、基线性能数据
- 是否对融合后的精度做了回归测试
- 是否对融合黑名单/白名单做了必要配置
按这份清单走一遍，能少踩很多坑。
7. 写在最后的一点个人体会
做了一段时间的图融合相关优化后，我的最大感受是：图融合不是一个“开不开”的二值问题，而是一个层层递进的系统工程。默认开融合解决的是“从无到有”的基础问题，而要获得更优性能，需要理解图结构、理解硬件特性、理解融合的边界条件，再针对具体模型做定制化调优。
从昇腾平台的演进也能看出这个趋势：最初图融合是以固定规则为主，现在越来越强调感知式调优和自定义扩展。对开发者来说，掌握“如何观察融合效果”和“如何定位融合失效原因”这两项能力，比记住任何一条具体的融合规则都更重要。因为这些能力是可迁移的——换一个模型、换一个平台，这些方法论依然适用。
如果你正在接触 CANN 或昇腾的模型优化，建议从 profiling 开始入手，先花一周时间把工具链用熟，再来看融合引擎的各类策略。工具用得越熟，你对融合引擎的理解就越深，优化的方向感也就越清晰。
