前言

写了一行 PyTorch 代码，model(input)，然后期待它在昇腾NPU上跑起来。这个过程看起来理所当然，但背后究竟发生了什么？你的模型是怎么被拆解、被翻译、被优化，逐渐变成可以在华为昇腾芯片上执行的指令的？很多人以为这中间只是"编译器把代码转成机器码"，但实际的链路远比这个认知要复杂和精密得多。

整个链路的核心由两层关键组件构成：CANN框架中的 ge 图引擎和 metadef 算子定义框架。ge 负责管理计算图的构建、优化和执行调度，而 metadef 则提供了算子的标准化定义语言，让每一个算子都能被正确地描述、注册和调用。理解这两个组件之间的关系，实际上就是在理解一张深度学习计算图是如何在昇腾NPU上从 Python 表达式变成可执行指令的完整旅程。本文将围绕这两个仓库，沿着计算图的流动方向，逐层拆解其中的机制和逻辑。

第一章：计算图是什么——把神经网络翻译成数学表达式

在讨论 ge 和 metadef 之前，我们需要先回答一个更根本的问题：计算图到底是什么？很多初学者会把计算图理解为"代码的执行流程图"，这个理解虽然不算错，但远远不够精确。计算图本质上是一种数学表达的有向无环图，它把神经网络中的每一个操作——矩阵乘法、加法、激活函数、卷积——都抽象为图中的节点，而数据在这些节点之间的流动则被抽象为边。

当我们用 PyTorch 或 MindSpore 写模型代码时，框架在内部会做一件极其重要的事情：把用户写的 Python 表达式"延迟执行"地转换成一张计算图。这个转换过程叫做"微分"或者"构图"，取决于框架的实现方式。以 PyTorch 的 torch.jit.trace 为例，它会实际运行一次前向传播，把每一个操作记录下来，构建出完整的计算图。但这只是一种构图策略——更激进的策略比如 MindSpore 的静态图模式，会直接在 Python 层做语法分析，把代码彻底翻译成计算图表示。

为什么要有计算图？因为 NPU 硬件无法直接理解 model(input) 这种 Python 表达式。昇腾NPU 的计算单元需要的是精确的、底层的数据流描述：哪些数据从哪个地址读取，经过什么样的运算，产出什么样的结果，写入到哪个地址。没有计算图，这一层翻译就无处着手。计算图充当了 Python 世界和硬件世界之间的中间表示层，它把神经网络的数学本质抽离出来，形成了一个可以被优化器分析、被执行器调度的结构。

从数据流的角度看，计算图的每一个节点并不是孤立的。一个节点的输出往往会作为多个后续节点的输入，形成复杂的依赖关系。比如在一个典型的 ResNet 块中，残差连接会让两条数据流汇合，这意味着计算图必须能够表达"多入多出"的节点关系，以及由此产生的拓扑排序需求。没有良好的图结构抽象，这种依赖关系的表示就会变得支离破碎，丧失全局优化的可能性。

计算图的另一个重要特性是它的可优化性。因为图结构完整地呈现了所有算子之间的关系，优化器可以在这个层面上做全局分析，而不是被代码的执行顺序所束缚。常见的优化手段包括公共子表达式消除、死代码消除、算子融合、常量折叠等等——这些优化在源代码层面做会非常困难，但在计算图层做却可以做到精确和彻底。这也正是为什么昇腾NPU需要一个强大的计算图管理层，而不是简单地把每个算子直接翻译成硬件指令。

第二章：ge 的职责——计算图的管理者

ge 仓库（https://atomgit.com/cann/ge）坐落在 CANN 框架的第3层（昇腾计算编译层）和第4层（昇腾计算执行层）之间，是整个链路中的核心枢纽。它的定位非常明确：作为计算图的管理者，负责图的构建、优化、调度和执行。理解 ge 的职责，需要从三个维度来看：图的表示、图的优化、以及图的执行。

先说图的表示。ge 定义了一套内部的计算图数据结构，这套结构能够完整地描述一个深度学习模型中的所有算子、所有的数据依赖关系、以及算子的属性信息。用户在 Python 层调用的每一个 nn.Conv2d 或者 nn.Linear，在 ge 层面都会对应到一个叫做"算子节点"的实体。节点之间通过"张量"来传递数据，张量在 ge 中有自己的形状信息、数据类型和内存布局。这种表示方式使得计算图从具体的框架实现中解耦出来——无论是 PyTorch 模型还是 MindSpore 模型，最终在 ge 这一层都变成了同一套图表示语言。

然后是图的优化。这才是 ge 最核心的价值所在。原始的计算图往往是"朴素"的，算子之间按照数学定义逐个排列，不考虑硬件特性和执行效率。ge 的优化器会对这张图进行一系列的 passes（轮转优化），每一个 pass 都负责解决一类优化问题。算子融合是最常见的优化手段之一。举个例子，卷积层之后通常会接一个批量归一化层和一个激活函数，从数学上看这是三次独立的运算，但在硬件上，三次运算意味着三次数据搬运和三次计算启动的开销。如果把这三次运算融合成一次，在一次内核调用中完成所有计算，数据只需要搬运一次，计算效率会显著提升。这种融合的判断和实施，就是 ge 优化器的职责。

ge 的优化还包括内存布局优化、算子重排序、内存复用等等。内存复用尤其值得关注——深度学习模型在推理或训练过程中会产生大量的中间张量，如果每一个张量都单独分配和释放内存，开销会非常大。ge 的优化器会分析计算图的数据依赖，计算出哪些中间结果可以复用同一块内存区域，从而大幅降低显存占用。这在昇腾NPU这种内存资源相对珍贵的硬件上，意义尤为突出。

收尾阶段则是图的执行。优化完成之后，ge 需要把计算图真正调度到昇腾NPU上运行。这不是简单的"按顺序执行节点"——调度策略直接影响硬件利用率。ge 的执行器会根据算子的依赖关系生成一个拓扑排序的就绪队列，然后根据昇腾NPU的计算单元状态动态决定下一个执行哪个算子。NPU 通常有多个计算核心（AI Core），ge 需要把算子分配到合适的核心上，同时处理好核心之间的数据同步问题。

下面的简化代码展示了 ge 如何表示一个最基本的计算图结构：

# 简化计算图节点定义
class Node:
    def __init__(self, name, op_type, inputs, attrs):
        # WHY: Node是计算图中的基本单元，代表一个算子
        # 每个节点记录自己的名字、算子类型、输入节点列表和属性字典
        self.name = name       # 算子名称，区分同名算子
        self.op_type = op_type # 算子类型，决定调度到哪类硬件单元
        self.inputs = inputs   # 输入张量列表，图拓扑关系在此体现
        self.attrs = attrs     # 算子属性，如卷积核大小、步长等

    def __repr__(self):
        return f"Node({self.name}, {self.op_type})"

# 构建一个简单的计算图：输入 -> 卷积 -> 激活 -> 输出
i = Node("x", "Host2Device", [], {})  # 从主机拷贝数据到NPU，初始化图输入
c = Node("conv1", "Conv", [i], {"kernel": (3,3), "stride": (1,1)})  # 卷积算子
a = Node("relu1", "ReLU", [c], {})     # 激活函数
o = Node("y", "Device2Host", [a], {})  # 结果拷贝回主机

graph = [i, c, a, o]
print("计算图拓扑顺序:", [n.name for n in graph])

这段代码用最朴素的方式演示了计算图的节点表示。name 用来在图中唯一定位每个算子，op_type 告诉执行器这个算子应该交给哪类硬件处理，inputs 则构成了图的边——它不只是一个简单的列表，而是图拓扑结构的直接体现。没有这个 inputs 列表，就无法确定节点之间的依赖顺序，也就无法做拓扑排序和优化。

ge 在实际运行时的图表示远比这个简化的例子复杂，包含流控制节点、条件分支、循环结构等高阶特性。但即使只看这个简化版本，我们也能感受到计算图的核心设计思想：用节点表示算子，用边表示数据依赖，用拓扑排序表示执行顺序。

第三章：metadef 的职责——算子的标准化定义语言

如果说 ge 是计算图的"管理者"，那么 metadef（https://atomgit.com/cann/metadef）就是算子的"定义者"和"注册者"。metadef 仓库位于 CANN 框架的第3层，专门负责提供一套标准化的算子定义语言和框架。理解 metadef 的关键，在于纠正一个极其常见的误解：很多人以为"算子就是一个函数"，这是一个严重的认知偏差。

算子在深度学习框架中并不是一个普通的函数。函数只关心输入和输出，只关心计算逻辑本身。但算子除了这些之外，还必须包含形状推导规则、数据类型约束、内存布局要求、梯度定义（用于训练场景）、以及在特定硬件上的实现路径。举个例子，一个 ReduceSum 算子，在定义时必须说清楚：输出的形状如何根据输入的形状和 reduce 轴推导出来？不同数据类型（float16、float32、int8）是否都支持？如果支持，它们各自需要什么样的精度保证？reduce 操作在昇腾NPU上应该调度到哪个计算单元？这些信息如果用普通函数来表达，要么表达不了，要么表达得极其笨拙。

metadef 的设计思路就是为这些信息提供一套结构化的表达方式。metadef 定义了一套描述语言，开发者可以用这套语言精确地描述一个算子的所有元信息。一个算子在 metadef 框架下的完整定义通常包括以下几部分：算子的数学定义（即其计算语义）、输入输出的类型签名、形状推导规则、以及 TBE（Tensor Boost Engine）或其他后端的实现适配。

算子的数学定义是最核心的部分。metadef 用一种抽象但精确的方式来描述算子的语义，而不是直接写 CUDA 或 昇腾汇编代码。这种抽象的好处在于，同一个算子定义可以在不同的硬件后端上生成不同的底层实现——在昇腾NPU上走 TBE 路径，在 GPU 上走 CUDA 路径，metadef 的抽象层屏蔽了这些差异。这正是为什么 metadef 能够成为 CANN 框架中算子定义的统一入口。

形状推导规则是另一个容易被忽视但极其重要的部分。深度学习框架在运行前通常会做一次"形状推导"，根据输入的形状推算出中间张量和输出张量的形状，这样可以提前分配内存，避免运行时的动态分配开销。metadef 的算子定义中包含了形状推导逻辑，它告诉编译器：如果输入是 [batch, channel, height, width]，在某个轴上做了 reduce 之后，输出应该是 [batch, channel, 1, width] 还是 [batch, 1, height, width]。没有这个信息，编译器就无法做静态内存规划。

下面的代码片段展示了一个简化版的算子定义结构：

# 简化算子定义结构（metadef概念演示）
class OpDef:
    def __init__(self, name, inputs, outputs, shape_rule, dtype_rule):
        # WHY: OpDef定义了算子的完整元数据——输入输出格式、形状推导规则和类型推导规则
        # metadef的核心价值在于通过元数据规范化算子的接口行为
        self.name = name        # 算子名字，如"Conv2d"、"MatMul"
        self.inputs = inputs    # 输入描述：shape、dtype、format
        self.outputs = outputs  # 输出描述：shape、dtype、format
        self.shape_rule = shape_rule  # 形状推导函数
        self.dtype_rule = dtype_rule  # 类型转换规则

    def infer_shape(self, in_shapes):
        # 调用形状推导规则
        return self.shape_rule(in_shapes)

    def check_dtype(self, in_dtypes):
        # 检查类型兼容性
        return self.dtype_rule(in_dtypes)

# Conv2d算子定义示例
conv_def = OpDef(
    name="Conv2d",
    inputs=[{"shape": "NCHW", "dtype": "float16"},  # 输入特征图
            {"shape": "KCRS", "dtype": "float16"}],  # 卷积核
    outputs=[{"shape": "NCHW", "dtype": "float16"}],
    shape_rule=lambda s: [s[0], s[1], s[2]//2+1, s[3]//2+1],  # 简化的shape推导
    dtype_rule=lambda d: d  # 类型直通
)
print("Conv2d输出形状:", conv_def.infer_shape([[1, 3, 32, 32], [64, 3, 3, 3]]))

这段代码演示了 metadef 算子定义的核心要素。shape_rule 和 dtype_rule 是 metadef 区分普通函数的根本所在——它们不是计算逻辑，而是元信息。没有这些元信息，编译器就无法在编译期做形状推断和类型检查，也就无法做内存预分配和代码生成。很多初学者把算子理解为"一个实现了数学运算的函数"，这个理解只对了三分之一；剩下的三分之二——形状推导和类型规则——才是算子定义的精髓所在。

metadef 的另一个重要作用是算子注册和发现机制。当一个新的算子在 metadef 中被定义并注册之后，ge 在构图和优化时就能"看到"这个算子，知道它有哪些属性、应该如何处理它的形状推导、如何在执行阶段调用它。这个注册-发现机制是连接 metadef 和 ge 的关键纽带。

第四章：两者的协作——ge 如何调用 metadef 定义的算子

现在我们已经分别理解了 ge 和 metadef 的职责，接下来最重要的问题是：它们是怎么协作的？一张计算图从构图到最终执行，中间经过了哪些步骤，metadef 的算子定义又是如何被 ge 所使用和调度的？

协作的核心链路是这样的：用户在 Python 层写下的模型代码，第一步被前端框架（如 MindSpore 或者通过 CANN 的 PyTorch 适配层）解析并转换为一个初始的计算图表示。这个初始图中的算子是"高层语义"的，比如 Conv2d、BatchNorm、ReLU 这样的名称。在这个阶段，算子只是一个抽象的数学操作，还没有绑定到任何具体的硬件实现。

然后，这个图被交给 ge 的优化器进行处理。ge 的优化器在分析图结构时，遇到每一个算子节点，都会去 metadef 的注册表中查找该算子的完整定义。这个查找过程不仅仅是"找到算子名字对应的实现代码"那么简单——ge 需要从 metadef 中获取的东西远比实现代码要多。形状推导规则告诉 ge 当前这个算子的输出形状是多少，ge 就可以据此做内存预分配。数据流信息告诉 ge 这个算子的输入输出之间有什么约束关系，ge 就可以判断两个相邻算子是否可以被融合。数据类型信息告诉 ge 是否有类型转换的需求，ge 就可以插入隐式的类型转换节点。

举个例子。当 ge 的优化器发现图中连续出现了 Conv2d -> BatchNorm -> ReLU 这样的序列时，它会去 metadef 查找这三个算子的定义。如果 metadef 中定义了"Conv-BN融合规则"和"BN-ReLU融合规则"，ge 就会尝试将这些节点融合成一个等价的单一算子节点。这个融合操作在原来的图中会消除两个中间张量的内存分配，而融合后的新算子在 metadef 中也有对应的定义，告诉 ge 这个融合算子的形状推导规则和硬件实现路径。ge 最终将融合后的图发送给昇腾NPU的执行单元，执行单元根据 metadef 提供的硬件实现信息，加载对应的内核程序，完成计算。

这种协作模式的关键在于"分层解耦"。metadef 负责"算子是什么"和"如何描述它"，ge 负责"图应该怎么优化"和"算子应该怎么调度"。metadef 不需要知道算子在图中被如何排列和优化，ge 也不需要知道算子的底层硬件实现细节。两者的边界通过标准化的算子定义接口来划定，任何一方发生变更都不会影响到另一方的核心逻辑。

从另一个角度看，metadef 提供的不仅是静态的定义信息，还包括一些动态的执行提示。比如某些算子在昇腾NPU上对内存对齐有特殊要求，metadef 的定义中就会包含相应的 attr 信息，告诉 ge 在调度这个算子之前需要确保输入数据的内存布局满足条件。ge 在做调度决策时就会参考这些提示，选择合适的执行时机和方式。这种信息传递贯穿整个图优化和执行的过程。

metadef 和 ge 的协作还体现在自动微分（AutoDiff）场景中。当 ge 管理的计算图用于训练而非推理时，需要为前向算子生成对应的反向梯度算子。metadef 中定义的反向算子语义为 ge 提供了梯度图的构建依据，ge 根据这些信息自动插入反向算子，生成完整的计算图用于反向传播。没有 metadef 的梯度定义，ge 的自动微分功能就成了无源之水。

理解了 ge 和 metadef 的协作机制之后，我们可以直观地感受到两者配合所带来的效率提升。以下表格从几个关键维度概括了计算图在引入 ge 优化和 metadef 标准化定义之后，与原始朴素路径之间的差异。

维度	不经过ge优化	经过ge优化后	差异来源
图执行效率	算子逐个独立调度	算子融合与调度优化	减少调度开销与内存读写
内存占用	中间张量各自独立分配	内存复用与显存优化	消除冗余缓冲区分配
形状/类型处理	运行期动态推导与转换	编译期静态推断	减少运行时开销
算子可复用性	需为每种shape组合单独实现	metadef统一描述自动适配	降低算子维护成本

第五章：一张图的生命周期——从 Python 到 NPU

前面几章已经从概念上拆解了 ge 和 metadef 的职责与协作关系，本章用一个更加具体的端到端视角，完整追踪一张计算图从 Python 层到昇腾NPU可执行指令的全过程。这个过程大致可以分为五个阶段：前端解析、图构造、图优化、代码生成和硬件执行。

在第一阶段，用户的 Python 模型代码被前端框架解析。这个解析过程可能是 eager 模式的（PyTorch 默认的行为），也可能是静态图模式的（MindSpore 的静态图语法，或者 PyTorch 的 torch.compile）。无论哪种模式，前端都需要把 Python 语义转换成一种中间表示。对于 CANN 体系来说，这个中间表示最终会被适配到 ge 的图结构中。转换过程中，每个 Python 层面的 nn.Conv2d、nn.Linear 调用都会对应到一个 ge 内部的算子节点，节点之间的数据依赖关系通过张量的 use-def 链来建立。

第二阶段是图的构造和初步验证。ge 在接收到前端传来的算子列表之后，会构建完整的计算图，并检查图的合法性——是否有孤立的节点、是否存在环形依赖（循环神经网络虽然也有循环，但通常通过特殊的循环节点来表示，而不是真正的环形图）、输入输出的类型是否匹配等等。这个阶段的图是"原始图"，还没有经过任何优化。

第三阶段是 ge 的核心工作：图优化。ge 的优化器会按顺序执行一系列优化 passes。常见的优化序列大致如下：第一步做常量折叠，把图中所有可以预先计算的值（如卷积核的权重）在构图阶段就计算出来，避免重复计算。然后做算子融合，把多个相邻的算子合并成更高效的融合算子。接着做内存优化，通过数据流分析消除不必要的中间张量，合并可以共享内存的缓冲区。末尾一步做调度优化，根据算子的硬件亲和性重新排列执行顺序，提高昇腾NPU的计算单元利用率。

下面的端到端示例代码演示了一个简化版的图构建和优化流程：

# 简化的图构建与优化流程演示
class ComputeGraph:
    def __init__(self):
        # WHY: ComputeGraph是整张计算图的容器
        # nodes列表按拓扑顺序存储所有算子节点，供后续优化Pass遍历
        self.nodes = []  # 图中的算子节点列表

    def add_node(self, op, inputs, attrs):
        # inputs是其他节点的索引，表示数据依赖
        self.nodes.append({"op": op, "inputs": inputs, "attrs": attrs})

    def fold_const(self):
        # 常量折叠：把可以预计算的节点替换为常量
        folded = []
        for n in self.nodes:
            if n["op"] == "Const":
                folded.append(n)  # 常量节点保留
            elif all(self.nodes[i]["op"] == "Const" for i in n["inputs"]):
                # 所有输入都是常量，则此节点也可折叠
                folded.append({"op": "Const", "inputs": [], "attrs": n["attrs"]})
            else:
                # 重映射输入索引
                remap = {old: new for new, old in enumerate(folded)}
                n["inputs"] = [remap[i] for i in n["inputs"] if i in remap]
                folded.append(n)
        self.nodes = folded

    def fuse_ops(self):
        # 算子融合：把连续的小算子合并
        fused = []
        i = 0
        while i < len(self.nodes):
            if (i + 1 < len(self.nodes) and
                self.nodes[i]["op"] == "Conv" and
                self.nodes[i + 1]["op"] == "ReLU"):
                # 融合Conv+ReLU为一个节点
                fused.append({
                    "op": "ConvReLU",
                    "inputs": self.nodes[i]["inputs"],
                    "attrs": {**self.nodes[i]["attrs"], "fused": "ReLU"}
                })
                i += 2
            else:
                fused.append(self.nodes[i])
                i += 1
        self.nodes = fused

# 构建一个简单网络：Const -> Conv -> ReLU -> Conv -> ReLU -> Output
g = ComputeGraph()
g.add_node("Const", [], {"value": [[1, 2], [3, 4]]})  # 模拟权重常量
g.add_node("Conv", [0], {"k": 3})                      # 第一层卷积
g.add_node("ReLU", [1], {})                             # 第一层激活
g.add_node("Conv", [2], {"k": 3})                      # 第二层卷积
g.add_node("ReLU", [3], {})                             # 第二层激活

print("优化前节点数:", len(g.nodes))
g.fold_const()
g.fuse_ops()
print("优化后节点数:", len(g.nodes))
print("优化后算子列表:", [n["op"] for n in g.nodes])

这个端到端示例展示了 ge 图优化中两个最基本也最重要的 passes。常量折叠 fold_const 通过分析节点输入是否为常量来判断哪些节点可以在编译期就确定结果，从而省去运行时的重复计算。算子融合 fuse_ops 则把相邻的 Conv 和 ReLU 合并成一个 ConvReLU 节点——在昇腾NPU的实际硬件上，这样做可以避免中间结果的内存写出和读入，相当于把三次数据搬运变成一次，效果非常显著。实际工程中，ge 的优化 passes 远不止这两个，但思想是一致的：分析图的结构规律，利用这些规律来消除不必要的计算和内存操作。

第四阶段是代码生成。经过优化之后的计算图，ge 会将其转换为昇腾NPU可以理解的指令流。这个转换过程根据目标硬件的特性和 metadef 中定义的算子实现路径，为每个图节点生成对应的硬件指令序列。对于使用了 TBE（Tensor Boost Engine）的算子，ge 会触发 TBE 的代码生成器，生成基于昇腾NPU指令集的算子实现。对于可以直接映射到硬件原生指令的算子，ge 则生成简化的调度指令。

第五阶段收尾为硬件执行。生成的指令被加载到昇腾NPU的计算单元上，由 ge 的运行时子系统负责调度和执行。执行器会管理数据的搬运（Host 到 Device 以及 Device 到 Host）、计算单元之间的同步、以及执行过程中可能出现的异常处理。整个执行过程对上层是完全透明的——用户感知到的只是 model(input) 返回了正确的结果，而背后实际上是 ge 和 metadef 协同工作的复杂系统工程。

---

https://atomgit.com/cann/ge
https://atomgit.com/cann/metadef