前言写了一行 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 Corege 需要把算子分配到合适的核心上同时处理好核心之间的数据同步问题。下面的简化代码展示了 ge 如何表示一个最基本的计算图结构# 简化计算图节点定义classNode:def__init__(self,name,op_type,inputs,attrs):# WHY: Node是计算图中的基本单元代表一个算子# 每个节点记录自己的名字、算子类型、输入节点列表和属性字典self.namename# 算子名称区分同名算子self.op_typeop_type# 算子类型决定调度到哪类硬件单元self.inputsinputs# 输入张量列表图拓扑关系在此体现self.attrsattrs# 算子属性如卷积核大小、步长等def__repr__(self):returnfNode({self.name},{self.op_type})# 构建一个简单的计算图输入 - 卷积 - 激活 - 输出iNode(x,Host2Device,[],{})# 从主机拷贝数据到NPU初始化图输入cNode(conv1,Conv,[i],{kernel:(3,3),stride:(1,1)})# 卷积算子aNode(relu1,ReLU,[c],{})# 激活函数oNode(y,Device2Host,[a],{})# 结果拷贝回主机graph[i,c,a,o]print(计算图拓扑顺序:,[n.nameforningraph])这段代码用最朴素的方式演示了计算图的节点表示。name用来在图中唯一定位每个算子op_type告诉执行器这个算子应该交给哪类硬件处理inputs则构成了图的边——它不只是一个简单的列表而是图拓扑结构的直接体现。没有这个inputs列表就无法确定节点之间的依赖顺序也就无法做拓扑排序和优化。ge 在实际运行时的图表示远比这个简化的例子复杂包含流控制节点、条件分支、循环结构等高阶特性。但即使只看这个简化版本我们也能感受到计算图的核心设计思想用节点表示算子用边表示数据依赖用拓扑排序表示执行顺序。第三章metadef 的职责——算子的标准化定义语言如果说 ge 是计算图的管理者那么 metadefhttps://atomgit.com/cann/metadef就是算子的定义者和注册者。metadef 仓库位于 CANN 框架的第3层专门负责提供一套标准化的算子定义语言和框架。理解 metadef 的关键在于纠正一个极其常见的误解很多人以为算子就是一个函数这是一个严重的认知偏差。算子在深度学习框架中并不是一个普通的函数。函数只关心输入和输出只关心计算逻辑本身。但算子除了这些之外还必须包含形状推导规则、数据类型约束、内存布局要求、梯度定义用于训练场景、以及在特定硬件上的实现路径。举个例子一个ReduceSum算子在定义时必须说清楚输出的形状如何根据输入的形状和 reduce 轴推导出来不同数据类型float16、float32、int8是否都支持如果支持它们各自需要什么样的精度保证reduce 操作在昇腾NPU上应该调度到哪个计算单元这些信息如果用普通函数来表达要么表达不了要么表达得极其笨拙。metadef 的设计思路就是为这些信息提供一套结构化的表达方式。metadef 定义了一套描述语言开发者可以用这套语言精确地描述一个算子的所有元信息。一个算子在 metadef 框架下的完整定义通常包括以下几部分算子的数学定义即其计算语义、输入输出的类型签名、形状推导规则、以及 TBETensor 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概念演示classOpDef:def__init__(self,name,inputs,outputs,shape_rule,dtype_rule):# WHY: OpDef定义了算子的完整元数据——输入输出格式、形状推导规则和类型推导规则# metadef的核心价值在于通过元数据规范化算子的接口行为self.namename# 算子名字如Conv2d、MatMulself.inputsinputs# 输入描述shape、dtype、formatself.outputsoutputs# 输出描述shape、dtype、formatself.shape_ruleshape_rule# 形状推导函数self.dtype_ruledtype_rule# 类型转换规则definfer_shape(self,in_shapes):# 调用形状推导规则returnself.shape_rule(in_shapes)defcheck_dtype(self,in_dtypes):# 检查类型兼容性returnself.dtype_rule(in_dtypes)# Conv2d算子定义示例conv_defOpDef(nameConv2d,inputs[{shape:NCHW,dtype:float16},# 输入特征图{shape:KCRS,dtype:float16}],# 卷积核outputs[{shape:NCHW,dtype:float16}],shape_rulelambdas:[s[0],s[1],s[2]//21,s[3]//21],# 简化的shape推导dtype_rulelambdad: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的计算单元利用率。下面的端到端示例代码演示了一个简化版的图构建和优化流程# 简化的图构建与优化流程演示classComputeGraph:def__init__(self):# WHY: ComputeGraph是整张计算图的容器# nodes列表按拓扑顺序存储所有算子节点供后续优化Pass遍历self.nodes[]# 图中的算子节点列表defadd_node(self,op,inputs,attrs):# inputs是其他节点的索引表示数据依赖self.nodes.append({op:op,inputs:inputs,attrs:attrs})deffold_const(self):# 常量折叠把可以预计算的节点替换为常量folded[]forninself.nodes:ifn[op]Const:folded.append(n)# 常量节点保留elifall(self.nodes[i][op]Constforiinn[inputs]):# 所有输入都是常量则此节点也可折叠folded.append({op:Const,inputs:[],attrs:n[attrs]})else:# 重映射输入索引remap{old:newfornew,oldinenumerate(folded)}n[inputs][remap[i]foriinn[inputs]ifiinremap]folded.append(n)self.nodesfoldeddeffuse_ops(self):# 算子融合把连续的小算子合并fused[]i0whileilen(self.nodes):if(i1len(self.nodes)andself.nodes[i][op]Convandself.nodes[i1][op]ReLU):# 融合ConvReLU为一个节点fused.append({op:ConvReLU,inputs:self.nodes[i][inputs],attrs:{**self.nodes[i][attrs],fused:ReLU}})i2else:fused.append(self.nodes[i])i1self.nodesfused# 构建一个简单网络Const - Conv - ReLU - Conv - ReLU - OutputgComputeGraph()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]forning.nodes])这个端到端示例展示了 ge 图优化中两个最基本也最重要的 passes。常量折叠fold_const通过分析节点输入是否为常量来判断哪些节点可以在编译期就确定结果从而省去运行时的重复计算。算子融合fuse_ops则把相邻的 Conv 和 ReLU 合并成一个 ConvReLU 节点——在昇腾NPU的实际硬件上这样做可以避免中间结果的内存写出和读入相当于把三次数据搬运变成一次效果非常显著。实际工程中ge 的优化 passes 远不止这两个但思想是一致的分析图的结构规律利用这些规律来消除不必要的计算和内存操作。第四阶段是代码生成。经过优化之后的计算图ge 会将其转换为昇腾NPU可以理解的指令流。这个转换过程根据目标硬件的特性和 metadef 中定义的算子实现路径为每个图节点生成对应的硬件指令序列。对于使用了 TBETensor Boost Engine的算子ge 会触发 TBE 的代码生成器生成基于昇腾NPU指令集的算子实现。对于可以直接映射到硬件原生指令的算子ge 则生成简化的调度指令。第五阶段收尾为硬件执行。生成的指令被加载到昇腾NPU的计算单元上由 ge 的运行时子系统负责调度和执行。执行器会管理数据的搬运Host 到 Device 以及 Device 到 Host、计算单元之间的同步、以及执行过程中可能出现的异常处理。整个执行过程对上层是完全透明的——用户感知到的只是model(input)返回了正确的结果而背后实际上是 ge 和 metadef 协同工作的复杂系统工程。https://atomgit.com/cann/gehttps://atomgit.com/cann/metadef