CANN图引擎ge计算图优化原理深度剖析：昇腾NPU上算子融合、内存复用与多流并行的性能优化实战指南

前言

深度学习模型部署到昇腾NPU上跑推理，跑出来的性能跟预期差一大截，问题往往不出在模型本身，而出在计算图这个中间层没有处理好。昇腾NPU的计算图优化由CANN的图引擎ge负责，它承接了上游框架下发的计算图，进行算子融合、内存布局调整、执行路径编排等一系列操作，最终把图下沉到硬件上执行。如果不理解ge的优化逻辑，调出来的模型往往在NPU上跑得比CPU还慢——数据搬运开销把计算收益全吃掉了。

ge在CANN五层架构里属于编译层的核心组件，上接PyTorch、TensorFlow等框架，下接Runtime执行层。当一个TorchScript模型或者ONNX模型通过适配器进入昇腾生态时，最先接手的就是ge。它把外部图格式转换成内部Graph表示，随即启动一系列图优化pass。这些pass有的是通用优化，有的是面向昇腾硬件特性的定制优化，排列组合起来能对计算图做深度改写。融合算子就是在这个阶段生成的，原本分散在多个节点上的独立算子被合并成单个融合算子，一次性调度到Cube或Vector单元上执行，省掉中间结果的显存在读写。

理解ge的工作原理不是理论上的事，直接影响模型在NPU上的实际性能。想把模型推理延迟压到最低，想把显存占用砍一半，想让吞吐跑满硬件瓶颈，就必须知道ge在图层面做了什么、做了什么代价、留了什么空间给应用层做配合。这就是本文要讲的内容：ge的计算图优化原理，算子融合、内存复用、多流并行三条主线穿插推进，每个知识点都配实战代码和效果对比，看完能用在自己的模型部署场景里。

第一章 昇腾NPU计算图与ge引擎定位

1.1 计算图在NPU执行体系中的角色

深度学习框架在CPU侧构建计算图，图里的节点是算子，边是张量依赖关系。这张图在框架侧只负责表达计算逻辑，不涉及任何硬件相关的约束。一旦图被下发到昇腾NPU执行，整个执行环境就变了：NPU有独立的显存，有Cube矩阵计算单元和Vector向量计算单元，有DMA搬运引擎，有多个计算_stream_可以并行，硬件拓扑和CPU完全不同。计算图要在这套硬件上跑得高效，就必须经过一轮"翻译"和"优化"，ge就是这个翻译和优化环节的执行者。

把计算图理解成施工图纸会清晰很多。框架侧出的是建筑设计方案，说明这栋楼需要哪些构件、它们之间怎么连接。到了昇腾NPU施工现场，施工图纸要变成具体的工序安排：哪些工序可以合并同时做，哪些材料要提前备好放哪，施工过程中哪些环节可以省掉步骤。ge做的事就是把这些转化工作全部自动化完成。融合算子相当于把两道相邻的刷墙工序合并成一次喷涂，内存复用相当于提前计算好材料堆放位置省得反复搬运，多流并行相当于把互不依赖的施工段同时开多个工种来做。

NPU执行体系里，计算图从进入到最终下沉要经过几个阶段。框架适配层先把外部图格式转成ge内部的统一表示，这个阶段保留的是计算语义，跟硬件无关。此后ge的图优化引擎开始介入，对这张图进行深度改写，包括消除冗余节点、合并可融合算子、调整算子顺序、重排内存布局等。优化完成后，图被交给Runtime执行器，后者按照ge输出的执行计划调度算子到具体的硬件单元上。这套流程里ge负责的部分决定了最终执行效率的上限——Runtime只能按图索骥，如果图本身没有优化好，Runtime再高效也是巧妇难为无米之炊。

1.2 ge引擎在CANN架构中的位置

CANN五层架构中，ge处于第三层即昇腾计算编译层。这个层级的定位是把高层计算描述转成低层执行指令，有点像传统编译器的前端优化和中间代码生成部分。ge之上是第一层的昇腾计算语言层，PyTorch用户通过PyTorch Adaptor接入、TensorFlow用户通过TensorFlow Adaptor接入，框架侧传入的是TorchScript或TensorFlow Graph格式。ge之下是第四层的昇腾计算执行层，Runtime接收ge输出的下沉模型，按照ge编排好的执行计划驱动算子在Ascend芯片上真正跑起来。

ge在架构中的独特之处在于它是"图层面"的唯一入口。算子层面的加速有ops-math、ops-nn、ops-transformer这些专门的算子库，但模型整体的优化必须在图层面做才有意义。一个包含十几个算子的模型，如果只优化单个算子的实现而不处理算子之间的协作方式，优化效果极为有限——数据在显存和计算单元之间来回搬运一次的开销，可能比一次计算本身还要大。ge处理的是算子之间的协作关系：数据流怎么组织、算子调度顺序怎么排、显存缓冲区怎么复用。这些都是图层面才有的信息，单个算子库给不出来。

从仓库关系看，ge是多个框架后端的核心依赖。TorchAir、TFA（Triton GE Backend）这些推理框架都依赖ge来做图的优化和下沉。这意味着只要你在昇腾NPU上跑推理，不管用的是PyTorch还是Triton还是TensorFlow，ge都是必经之路。理解了ge的优化行为，就能理解为什么同样的模型在不同框架、不同配置下跑出来的性能差异那么大——差异的根源往往就在ge对图做了什么样的改写。

1.3 内部Graph表示与节点抽象

ge内部用一套自己的图表示体系来描述计算逻辑。这套体系的核心是节点（Node）和张量（Tensor）两类实体：节点代表算子行为，张量代表数据。节点有类型属性，不同类型对应不同的计算语义，比如MatMul、Conv2d、ReLU、LayerNorm等。张量有形状（shape）、数据类型（dtype）和内存布局（layout）三个基本属性，形状描述维度、数据类型描述精度、内存布局描述在显存中的排布方式。

节点之间通过输入输出张量建立依赖关系，构成一张有向无环图（DAG）。这个DAG是ge所有优化操作的对象。节点上附加的属性会直接影响ge的优化决策，比如某个节点的输出张量如果标记为"后续算子需要访问"，ge就不能把这条边做融合；某个节点如果标记为"外部引用"，ge就必须保留对应的张量实体不能做内存复用。理解这套属性体系有助于理解ge的优化边界：哪些优化能做、哪些优化不能做，不取决于ge的心情，而取决于用户通过属性系统传达的约束。

张量的内存布局是ge优化决策中的关键变量。昇腾NPU支持多种内存布局格式，包括NCHW、NHWC、ND等，不同的算子类型对内存布局的适配度不同。Conv2d在NCHW布局下效率最高，而某些融合算子可能需要NHWC格式做输入。ge在图优化阶段会分析每个算子的内存布局需求，在不破坏计算语义的前提下，对张量布局做等价转换，使得整个计算链路尽可能在最优布局下执行。这个过程叫做内存布局重排，是ge最常见的优化操作之一。

第二章 计算图优化pass体系

2.1 pass框架的基本工作原理

图优化pass是ge对计算图做改写的基本单元。一个pass读入一张图，做特定类型的改写，输出改写后的图。这个过程可以类比成流水线上的质检员：图纸进来，每个质检员检查一个方面，有问题就改，没问题就过。ge的执行引擎负责调度这些pass按照预定的顺序依次处理同一张图，前一个pass的输出直接作为后一个pass的输入，形成一条优化流水线。

pass框架的核心设计原则是模块化和可组合性。每个pass只关注一个优化目标，不级联承担多个职责。这样做的好处是优化逻辑清晰可维护，不同的pass可以独立开发、测试和调优。同时pass之间可以灵活组合，不同场景可以启用不同的pass序列，比如推理场景和训练场景的优化策略差异较大，通过配置选择不同的pass组合就能适应。ge内置了几十个不同类型的pass，覆盖常量折叠、算子融合、布局优化、内存规划、调度重排等各个优化维度。

pass的执行时机由执行引擎统一控制，但pass内部的改写逻辑是逐节点进行的。以常量折叠pass为例，它遍历图中所有节点，识别出那些输入全是常量的节点，直接把计算结果算出来替换掉整个节点，省掉运行时的计算开销。再比如死代码消除pass，它从输出节点反向遍历，标记所有对最终输出没有贡献的节点，把它们从图中删掉。理解pass的基本工作模式，有助于理解ge为什么会做某些看起来"奇怪"的改写——每个改写背后都有一个明确的优化目标。

2.2 算子融合pass的类型与机制

算子融合是ge最核心的优化手段，也是对性能影响最大的一个环节。融合的本质是把两个或多个相邻算子合并成一个，合并后的融合算子在硬件上一次性调度执行，数据不需要写回显存再读出来，省掉中间的显存在读写开销。这个开销在NPU上不是可忽略的——一次显存在读写延迟通常在几百微秒量级，而一次矩阵乘法的执行时间可能也就几毫秒，如果中间夹杂了太多次短途搬运，整体延迟就会被显著拉高。

ge内置了多种融合模式。第一类是连续同构算子融合，比如两个相邻的卷积层如果满足特定条件就合并成一个。连续同构融合的条件比较严格，要求两个卷积的输入输出形状满足某种对齐关系，中间的激活函数类型相同且没有复杂的残差连接。第二类是跨类型融合，比如卷积后面接ReLU激活、卷积后面接偏置加法、矩阵乘法后面接Softmax等。跨类型融合的条件相对宽松，只要融合后在计算语义上等价且硬件上能支持融合后的调度，就能触发。

融合pass的执行分为两步。第一步是模式匹配：ge在计算图上扫描符合融合条件的算子序列，识别出可融合的候选。这个过程类似于在一串积木里找可以合并的相邻块，匹配规则定义了"什么样的块算相邻"。第二步是算子替换：找到候选序列后，ge生成一个新的融合算子节点替换掉原来的多个节点，同时更新依赖关系和内存布局信息。融合算子本身不是凭空生成的，它的内部实现由专门的融合算子库提供，ge负责的是融合策略和融合时机。

# 融合前的计算图（伪代码表示）classGraphBuilder:defbuild_conv_relu(self,x,w,b):# WHY: 这里先做卷积再过ReLU，数据要写回显存再读出来conv_out=self.conv2d(x,w,b)relu_out=self.relu(conv_out)returnrelu_out# 融合后的计算图classGraphBuilder:defbuild_conv_relu(self,x,w,b):# WHY: 直接用融合算子，数据在计算单元内部传递，不落显存fused_out=self.fused_conv_relu(x,w,b)returnfused_out

融合的效果取决于原始计算图中算子之间的依赖关系。如果两个算子之间有复杂的控制流或者需要被外部代码访问，融合就会被限制。融合pass有一个重要的约束机制叫"可融合性标记"，节点和张量都可以携带这个标记。开发者在构图时如果明确标记某个张量后续需要被外部访问，ge就会在融合判定时跳过相关节点，保证融合不会破坏用户对数据流的控制权。

2.3 计算简化与等价替换

算子融合是"做大动作"，计算简化则是"做小动作"。计算简化的目标是在不改变计算结果的前提下，用更少的计算步骤完成任务。这类pass包括常量折叠、代数简化、算子替换等子类型，每种子类型针对不同的简化场景。

常量折叠比较好理解：图上有些节点的全部输入在构图时就已经确定了，比如一个偏置张量在模型训练完成后是固定值。常量折叠pass把这类节点替换成计算结果的常量张量，运行时不需再为这些节点分配计算资源。这个优化对推理阶段特别有效，因为训练好的模型里大量参数都是常量。常量折叠还能级联触发：删掉一个常量节点后，可能导致新的节点输入全部变成常量，从而引发下一轮折叠。

代数简化利用算术运算的交换律、结合律和分配律做等价替换。比如x * 0可以替换成常数0，x + 0可以替换成x，x / x可以替换成1。这些替换看起来是常识，但在复杂的计算图里，自动化的图优化pass能系统性地找到所有这类模式，比人工检查全面得多。ge还支持更复杂的代数等价替换，比如把log(exp(x))简化成x，前提是x的取值范围满足数学约束。

算子替换是一种更高级的简化策略，它的思路是用计算语义等价但执行效率更高的算子来替换原有算子。比如一个Expand + Reduce的操作序列，在某些形状条件下可以替换成更高效的聚合算子。一个复杂的Reshape + Transpose + MatMul序列，在某些张量形状满足特定条件时可以合并成一次更高效的矩阵运算。这类替换需要对张量形状做符号化的推理判断，是计算简化pass中最复杂的部分。

第三章 内存复用与显存优化

3.1 显存瓶颈对NPU性能的影响

昇腾NPU的显存带宽和容量都是有限的。当模型规模较大、batch size较大或者输入输出张量较多时，显存很容易成为瓶颈。显存在读写上的开销有两个层面：第一是容量层面的瓶颈，当显存不够时系统要把数据临时swap到Host内存里，这个开销数量级远高于显存内部读写；第二是带宽层面的瓶颈，即使显存够用，不同算子之间频繁的显存在读写也会占用显存带宽，导致计算单元在等待数据送达时处于空闲状态。

ge对显存问题的处理分为两个方向：容量优化和带宽优化。容量优化的核心手段是内存复用，即通过合理的显存规划，让不同时间使用的张量共享同一块显存区域，在时间维度上复用空间。带宽优化的核心手段是数据局部性优化，即通过调整算子执行顺序和融合策略，减少数据在显存和计算单元之间的搬运次数。算子融合同时服务于这两个目标：融合后中间张量不需要写回显存，既省了显存占用，又省了搬运带宽。

从工程角度看，显存优化是ge里最需要配合的部分。ge提供了显存规划的配置接口，应用层可以通过配置指定张量的生命周期、显存放的位置（OnChip还是OffChip）、是否允许复用等。如果应用层不提供这些信息，ge会按保守策略做规划，显存利用率往往偏低。反过来，如果应用层能准确描述每个张量的使用模式，ge就能做出激进的显存规划，在同样的硬件上跑起更大的模型。

3.2 内存复用策略的实现

内存复用的基本思想是"时间换空间"。同一个显存地址，在不同时刻被不同张量使用，只要这些张量的使用时间不重叠，它们就可以共享同一块显存区域。这个思路类似于拼车：不同乘客在不同时间段使用同一辆车，车还是那辆车，但运力利用率上去了。

ge的内存复用规划分为几个层面。第一个层面是生命周期分析：ge遍历计算图，为每个张量确定它的"存活区间"——从被产生到被最终消费的时间点为止。这个分析要考虑控制流分支和条件执行，同一个张量在不同的执行路径上可能有不同的生命周期。第二个层面是冲突图构建：把每个张量抽象成一个节点，如果两个节点的生命周期存在重叠，就在它们之间建立一条边，表示这两个张量不能共享显存。第三个层面是着色求解：把冲突图映射成图着色问题，用尽可能少的颜色（也就是显存块数量）为每个节点着色，保证相邻节点颜色不同。最少颜色数就是最优的显存块数量。

这个算法在数学上是NP完全问题，但计算图的结构性约束（通常是DAG而非任意图）使得实际求解效率可以接受。ge在实现上做了大量工程优化：对常见拓扑模式做模式化快速求解，对大规模图做分层规划，对实时性要求高的场景做近似求解。应用层如果关心具体的显存占用数字，可以通过ge提供的内存分析接口查看规划结果。

# 内存复用的配置示例（示意）classMemoryPlanner:defconfigure_reuse(self,graph,config):# WHY: 显式声明 x 和 y 不重叠，ge就能把它们规划到同一块显存config.set_lifetime("x",start=0,end=50)config.set_lifetime("y",start=60,end=120)config.set_reuse_group("group_a",["x","y"])# WHY: z 需要贯穿整个执行过程，不能和其他张量复用config.set_lifetime("z",start=0,end=200)config.set_exclusive("z")returngraph.optimize(config)

内存复用还有一个重要的约束维度是数据依赖。某些张量是算子融合产生的中间结果，它们的生命周期严格绑定在融合算子内部，不能被外部引用。ge在做复用规划时会识别这类约束，避免把外部需要的张量错误地复用掉。融合算子内部的中间张量则可以激进地复用，因为它们不会被外部代码访问，规划空间更大。

3.3 显存预分配与生命周期管理

除了复用策略，ge还提供显存的预分配机制。预分配的核心思路是提前为计算图分配好所有显存缓冲区，而不是在运行时动态申请。动态申请的问题是碎片化和延迟：每次申请显存都需要调用驱动接口，这个调用本身有开销；如果申请释放频繁，还会产生显存碎片，降低可用显存总量。

预分配的关键是精确计算每个张量需要的显存大小。张量的显存占用由形状、数据类型和内存布局共同决定。ge在图优化阶段会对每个张量的形状做符号化推理，得到形状的取值范围或精确值，据此计算出显存占用。对于形状在运行时才能确定的动态张量，ge采用上界估计的方式预分配足够的显存，保证运行时不会溢出。

生命周期管理是预分配策略的配套机制。ge维护一张显存使用时间线，记录每个显存块从分配到释放的时间区间。在这张时间线上，ge会寻找显存使用低谷期，在低谷期插入新的张量分配，平滑显存使用曲线。对于显存敏感的场景，比如大模型的单卡推理，可以通过调整算子顺序来人为制造低谷期，让ge的预分配策略获得更大的规划空间。

# 显存预分配示例（示意）classMemoryAllocator:defpreallocate(self,graph,device_id):# WHY: 一次性申请计算图所需的全部显存，避免运行时的动态申请开销total_size=self.estimate_graph_memory(graph)buffer=self.alloc_buffer(device_id,total_size)# WHY: 按生命周期顺序映射缓冲区，不同生命周期的张量分到不同偏移offset_map=self.plan_buffer_layout(graph,buffer)graph.set_buffer_mapping(offset_map)returngraph

第四章 多流并行与调度优化

4.1 多stream机制与并行度挖掘

昇腾NPU的计算硬件有多个并行执行单元，Cube单元和Vector单元可以同时工作，DMA引擎可以独立搬运数据。如果把所有算子串行调度到同一个计算_stream_上执行，硬件的并行度就没有被充分利用。ge的多流并行机制通过把算子分布到不同的计算_stream_上执行，挖掘硬件的并行能力。

stream是昇腾Runtime里的一个核心概念，可以理解成一条独立的计算流水线。每个stream有自己的算子调度队列，算子按顺序在stream上排队执行。不同stream之间的算子可以并行执行，只要它们之间没有数据依赖。ge的多流优化就是在保证数据依赖关系正确的前提下，把可以并行的算子分布到不同的stream上，最大化硬件利用率。

挖掘并行度的前提是正确分析算子之间的依赖关系。依赖关系有两类：数据依赖和控制依赖。数据依赖是指一个算子的输入张量来自另一个算子的输出，这两个算子必须串行执行。控制依赖是指一个算子的执行条件依赖于另一个算子的结果，比如条件分支。ge在分析依赖关系时优先处理数据依赖，控制依赖通常会限制并行空间。ge内置了一个依赖分析pass，输出一个依赖图作为后续并行调度的输入。

4.2 依赖感知的并行调度

并行调度的目标是最大化硬件并行度，同时保证依赖约束。ge的调度策略分为几个层次。第一层是粗粒度并行：在依赖图上找到没有直接依赖关系的算子组，把它们分发到不同stream上执行。这一层主要处理互不依赖的算子块，比如模型中并列的多个分支。第二层是细粒度并行：在单个算子内部，如果算子的输入张量可以被分块处理，就启用算子内部的并行执行模式，比如对大矩阵做分块矩阵乘法。分块并行需要在数据布局和融合策略上做配合，不是独立能做好的。

# 并行调度的配置示例（示意）classStreamScheduler:defschedule(self,graph,num_streams):# WHY: 分析数据依赖图，找到可并行的算子组dep_graph=self.analyze_dependencies(graph)# WHY: 把没有依赖关系的算子分到不同stream，并行度翻倍groups=self.partition_parallel_groups(dep_graph,num_streams)fori,groupinenumerate(groups):self.assign_to_stream(group,stream_id=i%num_streams)returngraph.compile()

并行度的提升不是无限的。stream之间如果存在隐式的资源竞争，并行度提高反而会导致性能下降。比如两个stream同时访问同一个显存区域的不同偏移，硬件的显存控制器可能产生冲突导致等待。ge的调度策略会考虑这种冲突，对关键路径上的算子做优先调度，对容易产生资源竞争的算子做错峰调度。

4.3 数据搬运与DMA并行

数据搬运是NPU执行中容易被忽视的性能杀手。一个典型的模型推理流程里，数据从Host到Device的拷贝、Device上的显存在读写、计算单元之间的数据传递，都属于数据搬运范畴。如果这些搬运操作串行嵌入在计算流程中，计算单元就要停下来等数据到达。

ge的优化策略是把数据搬运和计算并行起来。在算子A开始执行时，DMA引擎同时启动算子B所需数据的预取，让算子B在数据到达时立即开始执行，不需要额外的等待时间。这个策略叫做异步预取，是ge在调度层面做数据并行化的一种手段。异步预取的前提是正确识别预取窗口：预取太早会占用额外显存，预取太晚则赶不上计算时机。ge在图优化阶段分析每个张量的消费时机，计算出最优的预取时间点。

DMA并行的另一个方向是多通道DMA。昇腾NPU的DMA引擎支持多个独立通道，可以同时搬运多路数据。ge在做调度规划时会识别可并行搬运的数据流，把它们路由到不同的DMA通道上，充分利用DMA的并行带宽。这个优化在大模型场景下特别有效，因为大模型的数据搬运量巨大，单通道DMA往往成为瓶颈。

第五章 模型下沉与推理实战

5.1 模型下沉的完整流程

模型下沉是ge的核心输出物：一个经过优化、可直接在昇腾NPU上执行的计算图。下沉的完整流程从框架模型开始，经过图导入、图优化、算子编译、资源分配、执行计划生成等环节，最终得到一个可以交给Runtime执行的静态计算图。理解这个流程的每个环节，有助于在遇到性能问题时定位瓶颈所在。

图导入阶段由框架适配器负责。PyTorch模型通过Torch Adaptor导入，TensorFlow模型通过TensorFlow Adaptor导入，ONNX模型通过ONNX Adaptor导入。适配器把外部框架的计算图表示转换成ge内部的Graph表示，这个转换过程中会保留框架侧提供的所有计算语义信息。导入质量直接影响后续优化的效果——如果适配器在转换过程中丢失了某些优化信息（比如算子的精度属性），ge就没法做出最优的优化决策。

图优化阶段是ge的核心价值所在。几十个优化pass按照预定的策略顺序依次处理导入后的计算图，每个pass完成一个特定维度的优化。这个阶段是可配置的，应用层可以通过开关选择启用哪些pass、调整pass的执行顺序、指定某些节点的优化约束。配置得当可以让性能大幅提升，配置不当则可能让性能劣化。ge默认的优化策略是保守的，适合大多数场景，但对特定场景有极致性能需求的应用层，可以通过自定义配置激活更激进的优化。

5.2 推理场景下的图优化实操

推理场景的优化和训练场景有显著差异。推理是纯前向计算，没有反向梯度，没有参数更新，算子之间的依赖关系固定，优化空间相对更大。同时推理对延迟和显存更敏感，batch size通常较小，优化目标更聚焦于单次推理的延迟而非吞吐量。

在推理场景下，ge的优化策略可以做几方面的强化。其中一个重点是激进的算子融合：推理阶段的算子序列通常是固定的，不像训练阶段那样需要动态构建计算图，ge可以提前识别所有可融合的模式，一次性完成融合。融合后的算子在硬件上调度时，数据流更紧凑，延迟更低。

# 推理场景下的图优化配置（示意）classInferenceOptimizer:defoptimize_for_inference(self,graph):# WHY: 推理场景关闭梯度相关pass，省掉不必要的优化开销config=self.default_config()config.disable_passes(["GradBackward","GradientCheckpoint"])# WHY: 开启推理专用的高强度融合passconfig.enable_inference_fusion()config.set_aggressive_fusion(True)# WHY: 推理通常是小batch，启用内存优化减少显存碎片config.enable_memory_reuse(True)config.set_memory_budget_mode("tight")returngraph.optimize(config)

其次是精度配置。推理可以在某些场景下使用混合精度，即部分算子用FP16替代FP32，在精度损失可接受的前提下大幅提升计算效率和降低显存占用。ge支持细粒度的算子级精度配置，可以在图上指定哪些算子用FP16、哪些保留FP32。这个配置需要应用层根据模型特性做调优，没有统一的最佳实践。

5.3 使用前后的效率对比

在昇腾NPU上使用ge的图优化能力前后的性能差异可以从三个维度来看：延迟、显存占用和吞吐量。这三个维度相互关联但存在权衡，侧重其中一个往往会牺牲另一个，ge的优化配置提供了在不同维度之间做权衡的手段。

这个对比表展示的是概括性描述，反映的是ge在不同优化策略下的典型效果差异。实际数字取决于模型规模、batch size、硬件配置和具体的优化配置。关键是理解这些优化维度是可以独立或组合配置的：如果你对延迟敏感，可以优先开启融合pass；如果你对显存敏感，可以优先开启内存复用pass；如果你有多块NPU，可以同时开启多流并行pass。ge的优化空间是弹性的，取决于应用层对配置的把控程度。

从实战经验看，把ge的图优化能力用到位，通常能让模型在NPU上的实际性能比"裸跑"版本提升一个数量级。裸跑版本的计算图没有经过任何优化，算子之间的协作方式完全由框架侧决定，数据搬运频繁、显存碎片多、硬件并行度低。经过ge优化后，融合算子消除了大部分中间张量读写，内存复用减少了显存峰值，多流并行压榨了硬件的并行算力，综合效果就是NPU的利用率从百分之三四十提升到百分之七八十。

结尾

ge图引擎是昇腾NPU计算图优化的核心枢纽，它的优化决策直接影响模型在NPU上的执行效率。算子融合消除了中间张量的显存在读写，内存复用把显存利用率压到极致，多流并行把硬件并行度充分释放出来。三条优化主线相互交织，共同构成了ge的优化体系。理解这些原理不是为了变成ge的开发者，而是为了在工程实践中知道什么时候该配合ge、怎么配合、在什么节点上做手工干预比依赖自动优化更有效。工程优化的终极目标不是用最复杂的配置，而是用最合适的配置把硬件潜能释放出来。ge提供了这个舞台，剩下的取决于应用层对这张计算图的理解深度。

仓库链接：https://atomgit.com/cann/ge