前言

在深度学习推理优化领域，算子融合技术一直是提升模型执行效率的核心手段之一。华为CANN（Compute Architecture for Neural Networks）作为昇腾AI处理器的软件栈基础，提供了完整的算子开发与优化框架。其中，graph-autofusion仓库承载了算子自动融合的核心能力，通过模式识别、融合决策与代码生成的完整链路，将原本需要手工优化的融合逻辑转变为可配置、可扩展的自动化流程。这一框架的出现，使得开发者能够从繁琐的逐算子优化中解放出来，将精力聚焦在模型结构的创新而非底层实现的打磨上。

graph-autofusion的设计理念源于对实际推理场景的深入观察。在神经网络执行过程中，连续的小算子往往会带来显著的调度开销和内存访问延迟，而手工融合虽然能够解决这一问题，却面临着维护成本高、可移植性差的困境。graph-autofusion通过构建可编程的融合规则引擎，让融合策略的编写从底层代码实现转变为高层规则描述，大幅降低了优化门槛。同时，框架内置的常见融合模式覆盖了主流模型结构的大部分场景，开发者开箱即用即可获得可观的性能收益。

从技术架构角度看，graph-autofusion位于CANN软件栈的中间层，向上承接计算图优化器的融合请求，向下驱动算子生成器产出融合后的实现代码。这一位置决定了它必须具备良好的扩展性和兼容性——既要支持新融合规则的快速添加，又要确保与现有算子生态的无缝对接。仓库中提供的pattern定义语言、cost model接口以及code generation模板，共同构成了实现这一目标的技术基础。

graph-autofusion能解决什么问题

算子融合的核心动机在于消除计算图执行中的冗余开销。在传统的图执行模式下，每个算子作为独立单元被调度执行，算子之间的中间结果需要写入全局内存再被下游算子读取。这种执行模式带来了两方面的问题：一是内存带宽成为性能瓶颈，大量数据搬运占据了执行时间的主要部分；二是调度开销累积，每个算子的启动、上下文切换都需要消耗处理器周期。

以ResNet网络中的典型结构为例，卷积层后接BatchNorm和ReLU是常见的组合模式。在未融合的执行方式下，卷积输出需要先写入内存，BatchNorm算子读取后计算并再次写入，ReLU算子最后读取并输出。这一过程中，数据经历了三次内存往返，而融合后的实现可以将三个算子的计算合并为单次kernel执行，中间结果驻留在片上存储或寄存器中，仅保留最终的输出写入。这种融合带来的收益不仅体现在内存带宽的节省，还包括kernel启动次数的减少和并行度的提升。

graph-autofusion解决的核心问题是将融合逻辑从手工编码转变为声明式规则定义。传统方式下，开发者需要为每一个待融合的算子组合编写专门的融合kernel代码，包括前向计算逻辑、反向梯度推导以及与框架的集成适配。这种方式的代价是巨大的：每增加一个融合模式，都需要完整的开发、测试和维护流程，且融合代码往往难以复用到其他算子组合上。graph-autofusion引入的模式匹配机制允许开发者用简洁的规则描述融合条件，框架自动完成从匹配到生成的全流程，极大提升了优化效率。

此外，graph-autofusion还解决了融合决策的一致性问题。在复杂计算图中，多个融合机会可能相互冲突，比如一个算子既可以与上游融合也可以与下游融合，选择不同的融合路径会带来差异化的性能结果。框架内置的cost model能够在多候选融合方案中进行量化评估，选择全局最优的融合策略，避免了人工决策可能带来的局部最优陷阱。

核心算法：pattern识别、融合决策、代码生成

graph-autofusion的技术实现围绕三个核心环节展开：pattern识别负责从计算图中发现可融合的算子组合，融合决策负责在多种候选方案中选择最优策略，代码生成负责将融合后的计算逻辑编译为可执行kernel。

pattern识别机制

pattern识别的基础是对计算图的遍历与匹配。框架接收的计算图以DAG（有向无环图）形式组织，节点代表算子，边代表张量依赖关系。pattern定义语言允许开发者描述目标算子组合的拓扑结构和属性约束，框架的匹配引擎在图中搜索满足条件的子图结构。

匹配过程采用子图同构检测算法。给定一个pattern定义，引擎首先提取其中的算子类型序列和连接关系，然后在计算图中寻找拓扑一致的候选子图。属性约束的检查在拓扑匹配之后进行，包括算子的输入输出shape、数据类型、属性参数等。这种两阶段匹配策略既保证了匹配的正确性，又避免了在属性检查上的无效计算开销。

pattern定义支持参数化模板，能够匹配一族算子组合而非单一固定结构。例如，连续element-wise算子的融合pattern可以定义算子数量的范围，而非固定为两个或三个。这种参数化能力使得一个pattern定义能够覆盖多种变体场景，减少了规则库的冗余。

Element-wise算子融合

Element-wise算子是神经网络中最常见的算子类型之一，包括激活函数、逐元素运算、归一化等。这类算子的共同特点是对输入张量的每个元素独立执行相同计算，不涉及跨元素的数据依赖。连续的element-wise算子是融合的理想对象，因为它们之间不存在复杂的依赖关系，融合后的计算流程容易构建。

典型场景如ReLU-BatchNorm融合、SiLU-Mul融合等。以ReLU-BatchNorm为例，两个算子的计算都是逐元素进行，融合后可以在单次遍历中完成两个计算，省去了中间结果的存储和读取。配置这类融合pattern相对简单，只需定义算子类型序列和连接关系，框架会自动处理匹配和生成。

# element-wise融合pattern定义示例
pattern = FusionPattern(
    name="relu_bn_fusion",
    nodes=[
        OpNode("bn", op_type="BatchNorm"),
        OpNode("relu", op_type="ReLU")
    ],
    edges=[("bn", 0, "relu", 0)],
    constraints=[
        ShapeConstraint("bn.output[0]", "relu.input[0]"),
        DtypeConstraint("bn.output[0]", "float16")
    ]
)

WHY这段代码重要：这段pattern定义展示了graph-autofusion的核心配置方式。通过声明式地描述算子节点和连接关系，开发者无需编写任何融合kernel代码，框架即可自动识别匹配的计算子图并生成融合实现。ShapeConstraint和DtypeConstraint等约束条件确保了融合只在安全的条件下执行，避免因shape或dtype不匹配导致的错误融合。

卷积后处理融合

卷积操作是卷积神经网络的核心，卷积层后通常接BatchNorm、激活函数、池化等算子。将这些后处理算子与卷积融合，能够显著减少内存访问开销，是推理加速的常用手段。

卷积融合的技术难度高于element-wise融合，因为卷积的计算涉及复杂的内存访问模式和多维数据布局。融合后的kernel需要妥善处理卷积输出的行主序布局与后处理算子的访问需求之间的关系。graph-autofusion内置的卷积融合模板已经针对这些细节进行了优化，开发者可以直接引用。

# 卷积后处理融合pattern定义
pattern = FusionPattern(
    name="conv_bn_relu_fusion",
    nodes=[
        OpNode("conv", op_type="Conv2D"),
        OpNode("bn", op_type="BatchNorm"),
        OpNode("relu", op_type="ReLU")
    ],
    edges=[
        ("conv", 0, "bn", 0),
        ("bn", 0, "relu", 0)
    ],
    constraints=[
        AttributeConstraint("conv.groups", lambda x: x == 1),
        ShapeConstraint("conv.output[0].dims[0]", lambda x: x >= 16)
    ]
)

WHY这段代码重要：卷积融合pattern增加了属性约束AttributeConstraint，限制融合只适用于groups=1的标准卷积。这是融合安全性的关键保障——分组卷积的内存布局与标准卷积不同，盲目融合可能导致数据访问错误。ShapeConstraint对batch维度的约束则是为了性能考量，小batch场景下融合收益有限，kernel编译开销可能抵消性能增益，框架通过这类约束自动跳过低收益融合。

Reduce算子融合

Reduce操作（如求和、求均值、求最大值）在注意力机制、分类器等结构中广泛使用。Reduce算子的特点是计算密集度低但内存访问模式复杂，将Reduce与相邻算子融合能够改善其执行效率。

典型的Reduce融合场景包括矩阵乘法后接Reduce、element-wise计算后接Reduce等。融合的难点在于Reduce涉及跨维度的数据聚合，融合后的kernel需要重新设计并行策略以避免同步开销。graph-autofusion提供了Reduce融合的专用模板，处理了并行规约、原子操作等底层细节。

# Reduce融合pattern定义
pattern = FusionPattern(
    name="matmul_reduce_fusion",
    nodes=[
        OpNode("matmul", op_type="MatMul"),
        OpNode("reduce", op_type="ReduceSum")
    ],
    edges=[("matmul", 0, "reduce", 0)],
    constraints=[
        AttributeConstraint("reduce.axis", lambda x: x == [-1]),
        ShapeConstraint("matmul.output[0]", lambda s: s[-1] <= 1024)
    ]
)

WHY这段代码重要：Reduce融合pattern展示了框架处理复杂计算模式的能力。AttributeConstraint指定融合只适用于沿最后一维的Reduce操作，这是最常见的Reduce场景。ShapeConstraint对reduce维度大小的限制是为了确保融合后的并行效率——维度过大会导致单个线程块的计算量过大，反而降低性能。这些约束体现了graph-autofusion在自动化与可控性之间的平衡。

自定义融合规则配置

除了使用框架内置的融合pattern外，开发者还可以根据模型特点编写自定义融合规则。自定义流程包括pattern定义、约束条件编写、模板选择或自定义等环节。

# 自定义融合规则完整示例
class CustomSoftmaxFusion(FusionRule):
    def __init__(self):
        self.pattern = FusionPattern(
            name="softmax_dropout_fusion",
            nodes=[
                OpNode("exp", op_type="Exp"),
                OpNode("sum", op_type="ReduceSum"),
                OpNode("div", op_type="Div"),
                OpNode("dropout", op_type="Dropout")
            ],
            edges=[
                ("exp", 0, "sum", 0),
                ("exp", 0, "div", 0),
                ("sum", 0, "div", 1),
                ("div", 0, "dropout", 0)
            ]
        )
    
    def check_feasibility(self, match_result):
        # 自定义可行性检查逻辑
        exp_shape = match_result.get_shape("exp", 0)
        sum_axis = match_result.get_attr("sum", "axis")
        if len(exp_shape) > 4:
            return False  # 超过4维的张量暂不支持融合
        return True
    
    def get_template(self, match_result):
        return "softmax_dropout_template.tik"

WHY这段代码重要：这个完整的自定义融合规则展示了graph-autofusion的扩展能力。开发者不仅定义pattern结构，还可以实现check_feasibility方法进行复杂的可行性判断，并通过get_template指定代码生成模板。这种可编程的扩展机制使得框架能够适应各种特殊场景，而不仅限于预置的融合模式。对于有深度优化需求的团队，这一能力是框架价值的重要体现。

技术边界：什么场景不适合用它

任何技术工具都有其适用范围，graph-autofusion也不例外。清晰认识其技术边界，能够避免误用导致的性能退化或功能异常。

动态shape场景的限制

graph-autofusion的pattern匹配和代码生成都依赖于算子输入输出的shape信息。在静态shape场景下，框架可以在编译期确定所有tensor的尺寸，从而进行最优的kernel生成。然而，当模型涉及动态shape时，部分融合决策和优化必须在运行时进行，这超出了当前框架的设计范围。

动态shape的典型场景包括自然语言处理中的变长序列、目标检测中的动态anchor数量等。这类场景下，算子的输入输出维度在编译期无法确定，融合框架难以预先估算融合收益或生成最优的kernel配置。强行应用静态融合策略可能导致性能次优甚至功能错误。

对于这类场景，建议采用运行时融合或JIT编译技术。graph-autofusion目前不支持运行时融合，开发者需要借助其他工具或框架能力来处理动态shape的优化需求。

复杂控制流场景的不适用

graph-autofusion基于计算图的拓扑结构进行匹配和变换，这一前提在存在复杂控制流时受到挑战。控制流包括条件分支、循环等结构，它们使得计算图在执行时动态变化，无法在编译期确定完整的算子序列。

当模型中存在if-else分支时，不同分支可能包含不同的算子组合，融合pattern可能在某些分支中匹配成功而在另一些分支中无法匹配。这种不确定性使得融合决策变得复杂，当前框架不支持对这类场景的自动处理。类似地，循环结构中的算子融合涉及循环展开、迭代间依赖等复杂因素，也超出了框架的能力范围。

复杂控制流场景的优化通常需要更高层次的编译技术，如XLA、TVM等框架采用的图重写和循环优化策略。graph-autofusion聚焦于算子级别的融合优化，与这些框架在优化层次上有所不同。

已有手工优化kernel的冲突

在某些场景下，开发者已经针对特定算子组合编写了高度优化的手工融合kernel。这类手工kernel往往针对特定模型和硬件进行了深度调优，性能可能优于graph-autofusion自动生成的融合实现。

当计算图中同时存在手工kernel和自动融合机会时，需要谨慎处理两者的关系。如果自动融合框架将手工kernel的输入输出算子纳入融合范围，可能导致手工kernel被替换为自动生成版本，反而造成性能退化。框架提供了黑名单机制来排除特定算子或子图参与融合，开发者应当利用这一机制保护已有的优化成果。

此外，手工kernel的维护成本和可移植性问题应当在决策时综合考虑。自动融合虽然在某些场景下性能略逊，但其自动化和可扩展的优势在长期维护中具有重要价值。

调试与可解释性需求

算子融合本质上是将多个计算单元合并为一个黑盒，这一过程增加了模型执行的不可见性。在开发和调试阶段，开发者可能需要观察中间算子的输出结果来定位问题，融合后的kernel使得这种观察变得困难。

对于有强烈调试需求的场景，建议在开发阶段禁用融合优化，或使用框架提供的调试模式。graph-autofusion支持在运行时禁用特定融合pattern，开发者可以根据调试需要灵活控制融合行为。在生产部署阶段再启用融合优化，以获得最佳性能。

使用前后的效率对比

graph-autofusion带来的性能收益可以通过使用前后的对比来直观体现。这里从内存带宽、kernel启动开销、并行效率三个维度进行概括性描述，避免捏造具体数字。

在内存带宽方面，未融合的执行模式下，相邻算子之间的中间结果需要写入全局内存再被下游算子读取。对于element-wise密集的网络结构，中间结果的数据量往往与输入输出相当，内存带宽占用显著。融合后，中间结果驻留在片上存储或寄存器中，仅保留必要的输入读取和输出写入。这一改变带来的内存流量减少是融合收益的主要来源，在内存带宽受限的场景下收益尤为明显。

在kernel启动开销方面，每个独立kernel的执行都涉及驱动层的调度、上下文切换等开销。对于计算量小的算子，kernel启动开销可能占据总执行时间的相当比例。融合将多个kernel合并为一个，启动次数的减少直接转化为时间节省。这一收益在element-wise算子链、小尺寸卷积等轻量计算场景下最为突出。

在并行效率方面，融合后的kernel拥有更大的计算规模，能够更充分地利用硬件的并行计算能力。独立的轻量算子往往难以填满处理器的计算单元，导致计算资源的闲置。融合后，多个算子的计算任务合并调度，可以设计更优的并行分解策略，提升计算单元的利用率。这一收益在batch size较大或特征图尺寸较大的场景下体现得更为充分。

综合来看，graph-autofusion带来的性能提升在各类模型和场景下呈现差异化表现。对于算子粒度细、内存访问密集的模型，收益更为可观；对于本身已经是计算密集型的大kernel场景，收益相对有限。开发者应当结合具体模型特点评估融合优化的价值。

总结

graph-autofusion作为CANN架构中算子自动融合的核心框架，通过pattern识别、融合决策、代码生成的完整技术链路，将原本依赖手工实现的融合优化转变为可配置、可扩展的自动化流程。框架的设计充分考虑了与CANN软件栈其他模块的协作关系，在GE、ops-*系列模块之间建立了清晰的接口边界，既保证了功能的完整性，又为后续的扩展和演进预留了空间。从应用角度看，graph-autofusion覆盖了element-wise融合、卷积后处理融合、Reduce融合等主流优化场景，内置的pattern库和代码模板能够满足大部分推理优化需求。同时，框架提供的自定义融合规则接口为有深度优化需求的团队打开了扩展空间，使得特定场景的优化策略能够以声明式方式快速实现。

---

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