企业官网建设流程全解析

1. 图引擎在整个CANN软件栈中的位置：模型优化为何要单独编译一层

做AI芯片软件栈的人都知道一个现象：硬件厂商总是把“编译器”和“运行时”打包在一起卖，而其中真正决定性能的不是底层的算子库代码，而是中间那层“图引擎”。CANN图引擎就是这样一层存在。先说结论：计算图的构建、IR（Intermediate Representation）的生成、算子的融合拆分、数据排布的推导、甚至跨卡通信的插入，全都在这一层完成。如果你只把它理解为“把框架图翻译成硬件指令”，那后面调优做的所有努力都会白费。

1.1 AI Core的硬件结构决定了图引擎的存在必要性

现在的AI加速芯片，比如昇腾系列处理器，它的AI Core跟CPU的核完全不是一回事。一个AI Core内部有Cube单元（矩阵运算）、Vector单元（向量运算）、Scalar单元（标量控制），还有L0 Buffer、L1 Buffer、L2 Cache这些存储层级。这意味着什么？意味着“把一个算子翻译成指令”这件事根本没那么简单。

举个例子：一个卷积算子，输入feature map可能几百MB，但AI Core的L0 Buffer可能只有几百KB。你不可能一次把整个矩阵塞进核里算完。必须切成小块，一块一块搬进去，每一块都做矩阵乘，算完再搬出来。谁来决定怎么切？谁来决定切的粒度？谁来安排搬运顺序？如果是每一个算子各自为战，整个计算图执行下来，会有大量反复搬运和等待。图引擎存在的第一层意义，就是把这些事从“算子内部实现”里剥离开来，放到全局视角去统一规划。

另一个更关键的点：AI Core是高度特化的硬件，它能高效执行的算子模式是有限的。很多在GPU上很自然的算子（比如某些带复杂索引的Gather），在AI Core上如果不做改写，性能会惨不忍睹。图引擎的作用，就是把框架传来的各种形状的算子，转换成AI Core“擅长”的形态。这个转换过程不是简单的语义等价变换，还夹杂着大量的性能考量和硬件约束。

1.2 从框架图到执行图，图引擎到底处理了什么

用户在PyTorch、MindSpore或者TensorFlow里写模型，框架会把模型转成自己的图结构。但框架图不是硬件能直接理解的东西。CANN图引擎接收的是框架图，输出的是可以直接下发的执行图，中间经过了几个阶段的处理。

第一阶段是解析和转换。把不同框架的图统一转成图引擎自己的IR。第二阶段是图优化，这也是神奇开始的地方：融合掉不需要的节点、去掉死节点、做常量折叠、推导每个算子的输入输出格式。第三阶段是算子落盘前的最后打磨：给每个算子计算tiling参数，确定数据搬运策略，分配物理内存，最后生成一个个可执行的任务。

这一套流程，可以类比成写代码时的编译过程：源代码（框架图）经过前端解析成AST（图引擎IR），中端做优化（各种优化pass），后端做指令选择（算子调度和tiling），最终生成汇编（任务下发序列）。跟传统编译器不同的是，图引擎优化的对象不是循环和寄存器，而是算子之间的数据流、内存复用、搬运隐藏。优化重点也完全不同。

1.3 和TVM等通用编译器思路的对照

说到这，用过TVM或者XLA的人应该会有种熟悉感。确实，CANN图引擎的核心思路跟这些通用深度学习编译器有相似之处：都是做一个中间表达，做调度优化，做代码生成。但有一个很大的区别：TVM的优化目标往往是通用硬件或者自定义的通用加速器，而CANN图引擎是绑定具体芯片架构来做的。

这个绑定关系意味着两层含义。第一，很多优化规则是“硬件感知”的。比如一个算子能不能和后面的算子融合，取决于融合后中间数据是留在L1还是L0，取决于后续算子的主计算单元是Cube还是Vector。这些细节不是从框架传过来的，是图引擎根据芯片规格查询到的。第二，图引擎可以针对特定的硬件行为做非常激进但是有把握的优化，比如对Matrix计算单元的利用率模型做精确建模，然后调整tiling策略。通用编译器通常不会做得这么“过”，因为要兼顾不同硬件。

我自己最早接触图引擎时，最大的误区就是把它当成一个“CPU编译器”来理解。后来动手看实际生成的IR和执行序列，才意识到它的核心工作更像一个“软硬件协同调度器”——既要做传统的编译优化，也要做数据搬移规划、内存复用到极致的资源管理。

2. 计算图构建阶段的细节：IR生成、算子解析与形状推导

很多人以为“计算图构建”就是把框架传过来的网络结构用数据结构存起来，没什么技术含量。但实际做下来才发现，图构建阶段隐藏了大量“脏活累活”：不同框架的算子语义差异怎么对齐、动态shape怎么表达、算子属性缺省值怎么补齐、数据格式怎么推导。这个阶段稍微粗糙一点，后面优化pass全都会出问题。

2.1 框架端图如何转换为图引擎的计算图

不同框架的图表达方式有很大差异。PyTorch在动态图模式下，图是边执行边构建的，很多算子是在C++层以函数调用的方式出现的；MindSpore的静态图有自己的一套IR；TensorFlow则是严格的dataflow graph。CANN图引擎要做的事，是把这些“方言”统一成自己的一套“普通话”。

这一步有个很基础但容易忽视的问题：算子映射。框架里的Conv2d，在图引擎IR里对应什么类型？这需要查一张注册表，这张表里记录了每个框架op到引擎内部op的映射关系、参数转换方式、默认属性值。听起来简单，但坑很多。比如PyTorch的Conv2d有个groups参数，MindSpore的Conv2d叫group，同一个参数在不同框架里默认值、边界检查都不一样。图引擎做转换时，必须把这些差异抹平，保证后续所有pass看到的算子语义是一致的。

我当时调试过一个拼包问题（Pack/Unpack），发现两个框架出来的图，一个把pack操作表达成Reshape+Transpose，另一个是专门的Pack算子。如果图引擎不做统一，后续的融合规则就得针对这两种表达分别写，工程量直接翻倍。所以一个好的图引擎，第一步就要把“等价但形态不同”的算子表达规整为少数几种标准形态。

2.2 形状推导与数据格式推导

图构建阶段，另一个核心工作是形状推导（Shape Inference）和数据格式推导（Format/Data Layout Inference）。

形状推导不是简单地把输入shape沿着算子张量计算一遍。因为框架传来的图，节点之间的shape可能是缺失的、部分是动态的，还有各种约束条件。图引擎需要根据每个算子的推导规则，推断出所有中间张量的shape，才能为后续的内存规划提供依据。这一步如果推错，后面内存分配会直接踩到野指针。

数据格式推导则容易被刚接触的人忽略。以昇腾硬件为例，内部算子计算偏好NCHW还是NC1HWC0这种5维格式？卷积在Cube单元上跑，需要的数据排布往往是一种特殊分形格式。而框架传来的通常是最朴素的NCHW。如果每个算子都在自己的输入输出接口上做格式转换，那么整个图会插入海量的transdata节点，性能直接崩掉。

图引擎的做法是：维护每个算子的输入输出格式偏好，做一次全局的格式传播。能不改就不改，必须改的地方，尽量把transdata节点融合进算子边界或者相邻的搬运流程里。我记得有一个很经典的优化：两个卷积之间如果只隔一个elementwise的ReLU，完全可以把ReLU两边都用卷积偏好的内部格式表达，这样就没有显式transdata。看起来只是少了几次数据重排，实际显存带宽节省非常多。

2.3 预处理优化：常量折叠、死节点消除与并行控制

图构建完成后，在真正进入复杂优化前，通常会先跑一遍“卫生pass”。这类pass技术含量不一定高，但对后续优化的有效性影响很大。

常量折叠最好理解：某个节点的所有输入都是常量，那图引擎直接把这个节点的输出算出来，变成一个常量节点。一个很典型的case是BN（Batch Normalization）在推理模式下，scale、shift、mean、var这四个参数如果全部是常量，那个BN节点的计算其实可以预先合并成一次乘加。图引擎在构建阶段就把它算完，图里就只剩一个Mul+Add，后面做算子融合时轻快很多。

死节点消除的作用亦不可小觑。很多框架出来的图里，有一些算子计算结果并没有被后续节点消费，比如我只为了取中间某个分支的loss，主干上的某些节点仍然会被带上。不把它们清掉，后面的内存规划和任务调度都会给这些无用节点白白分配资源，虽然不影响正确性，但影响可执行图的体积和启动时间。

并行控制则稍微“偏门”一点。它负责给图划分成不同的“控制流块”，决定哪些算子可以并行下发、哪些有数据依赖必须串行。这个信息会一直传递到最后的任务调度阶段。做得好的图引擎，在构建期就为后续的流水线执行打好了基础；做得粗糙的，到了执行期调度器只能靠猜，就会频繁出现AI Core空转等待数据的问题。

3. 图编译的核心优化机制：算子融合、Tiling与内存规划

图构建完之后，真正决定性能的大头在图编译阶段。我可以很直接地说：算子融合、Tiling策略和内存规划这三件事，占据了图引擎优化工作量的七成以上。每件事展开都够写一篇文章，这里我把它们放在一起讲，是因为这三者是强耦合的——融合的策略影响tiling的可行性，tiling的结果又决定内存规划的方式。

3.1 算子融合的收益和边界条件

算子融合的动机非常朴素：AI Core的算力很强，但搬运带宽是瓶颈。如果算完一个算子，把中间结果写回DDR，下一个算子再把它从DDR读回来，这个“写回再读入”的带宽浪费是纯开销。融合的本质，是把中间结果尽量留在片上，或者直接在寄存器/Buffer之间传递。

图引擎里常见的融合有两类：一类是相邻元素级算子的融合，比如Conv+BN+ReLU融合成一个算子，中间特征图不落DDR；另一类是更复杂的“多算子拼核”融合，比如两个独立的卷积在数据无依赖的情况下放到同一个核上交替执行，提高Cube单元的利用率。

但融合不是无代价的。它有一个边界条件：片上存储装得下融合后算子的所有中间数据。假设一个卷积的输出feature map是32x128x56x56，中间要经过BN和ReLU，如果后两者需要暂存整个feature map才能算，那L0/L1 Buffer一下就爆了。实际工程里，图引擎通常只在确认融合后tiling参数依然可行时，才真正实施融合。我看过一些融合失败的分析日志，十次里有七八次都是“UB size overflow”直接拦下的。

3.2 Tiling策略：从shape到AI Core执行的切分

Tiling这个词，可能很多人只在CANN文档里见过，不了解它的分量。一句话解释：Tiling就是把一个大的算子计算，切成AI Core能一次执行的小块。切小了浪费算力，切大了放不进片上存储，所以tiling是一个典型的约束优化问题。

拿Conv来举例。假设输入是N=1, C=64, H=224, W=224，Cube单元做矩阵乘时，通常要把它转成某种分形块。具体切分要考虑几个维度：Batch维能不能切、Channel维怎么切、H和W的空间维怎么切。每切一个维度，都对应不同的数据搬运量和片上缓存占用。

我做过的一个简化tiling计算，逻辑大致是这样的：

# 假设目标AI Core的UB大小为256KB，输入输出都按fp16计算 # 卷积 kernel=3x3, stride=1, pad=1, C_in=64, C_out=128, H=W=224 ub_size_bytes = 256 * 1024 dt_size = 2 # fp16 # 一次tile对应的中间占用： # 输入块：tile_h * tile_w * C_in * dt_size # 权重块：3*3 * C_in * C_out * dt_size # 输出块：tile_h * tile_w * C_out * dt_size # 粗略估算，若 tile_h=32, tile_w=32： input_block = 32 * 32 * 64 * 2 # 128KB weight_block = 3 * 3 * 64 * 128 * 2 # 144KB，通常放L1/L2，不完全占UB output_block = 32 * 32 * 128 * 2 # 256KB，直接爆了 # 所以需要把C_out再切小，比如 C_out_tile=32： output_block = 32 * 32 * 32 * 2 # 64KB # 这样输出+输入约192KB，勉强放下，还要留出做双缓冲的空间

这个例子非常粗略，真实图引擎要考虑多级buffer、DMA对齐、双缓冲叠加，比这复杂得多。但核心逻辑就是这样：根据片上存储算出一个可行的tile尺寸，再根据tile尺寸决定数据搬运的序列。

从优化角度说，图引擎做的tiling策略通常有若干挡位：快的、稳的、省显存的。不同场景会触发不同策略。比如静态shape且shape不大，图引擎会选择偏大的tile，减少循环次数、减少调度开销；如果是动态shape或者shape特别大，就会退化成更保守的切法。

3.3 内存规划与数据搬运的隐藏方式

图编译阶段还有一件大事：内存规划。传统框架里，每个算子的输入输出张量都会在显存里分配独立的空间，简单但浪费。图引擎做的是更极致的复用：分析张量的生命周期，能复用同一块物理内存的张量就尽量复用。这背后本质上是图染色问题。很多工程化实现并不追求理论最优，而是用一种近似算法快速给出可用的复用方案。这个方案的效果直接决定了同一个模型在CANN上能比朴素运行时省多少显存，对跑大模型尤其重要。

数据搬运的隐藏，是我觉得图引擎里最具巧思的部分。AI Core执行算子时，计算单元经常“等数据”。如果让搬运和计算完全串行，AI Core利用率可能不到50%。图引擎的解决方案是双缓冲（Double Buffering）甚至多级流水：当前tile在计算时，下一个tile的数据已经开始从DDR往L1搬运，再下一个tile从L1往L0搬运。这样搬运与计算重叠，利用率为之一高。

要做到这一点，图引擎在生成任务序列时，会在DMA指令和计算指令之间插入合适的依赖/同步关系，既要保证语义正确（不能提前覆盖还没算完的数据），又要最大化并行。我自己在分析执行序列时看到过一种“三阶段流水”的结构：DMA从DDR到L1、DMA从L1到UB、AI Core计算，三者各差一个tile，流水线铺得很满。如果没有图引擎这一层，单靠手写算子，想全局做到这种重叠几乎不可能。

4. 自动优化阶段：AOE调优、内存复用与大模型图切分

前面说的图编译优化，很多是基于预置规则的。但规则不可能覆盖所有场景，尤其当模型结构特殊、算子组合非常规时，需要额外的自动调优机制来补齐性能短板。CANN里承担这部分工作的就是AOE（Ascend Optimize Engine）以及一系列图级自动优化策略。

4.1 算子自动调优和AOE的整体流程

AOE的思路可以概括成：针对目标模型、目标硬件，跑一组可配置的调优任务，搜出一组当前最优的算子实现参数或图优化开关。它不是取代图引擎的规则优化，而是作为规则的补充——尤其是当某个算子的性能对shape、格式、硬件版本都很敏感时，预置规则很难覆盖所有花样。

实际使用AOE时，最直观的入口是配置调优模式。调优过程中，图引擎会针对特定算子下发多个版本的候选实现，在硬件上实际跑一遍，统计耗时，选出最优结果，写进调优结果文件。后续再对该模型做编译时，读到结果文件后直接加载最优配置，不需要重新搜。

这里我要提醒一个不少人忽略的点：AOE的调优结果跟shape强相关。你用一个固定shape调出来的参数，换一个动态shape或者换一个不同的序列长度，优势可能直接消失。所以AOE调优一定要用跟线上一致的shape、一致的精度选项、一致的数据格式。我之前遇到过一个很糟的case：AOE在某形状下把某个Matmul的tiling方式调成了对L2 Cache非常激进的分块，换一个shape后，访存局部性变差，性能反而比默认值倒退了20%。后来排查了很久才发现是AOE结果文件是拿旧的shape调出来的。

4.2 Buffer Fusion与内存复用

前面提到内存规划可以做张量生命周期分析，实际上还有一种更强的优化叫Buffer Fusion。它不只是“复用不同算子的输出内存”，而是把多个算子中间的多个临时buffer在物理上合并成一个连续的大buffer，然后根据每个算子的实际使用区间做“切豆腐块”式分配。

这样做的好处，除了省内存，还有两个附带收益。一是减少内存分配和释放的次数。如果一个图里几百个算子的中间结果各自malloc，光是内存管理器的开销就够吃一壶。二是连续物理内存可以提升DMA搬运效率——大块连续内存的搬运带宽利用率明显高于小块碎片。

Buffer Fusion的难点在于正确性判断：内存可以被复用，但有多种依赖关系要守。比如两个算子p和q的中间buffer能否重叠，必须证明p的输出在q使用完之前不会被覆盖，且p和q之间不能有fork/join的复杂依赖。图引擎内部其实是把这个问题抽象成区间调度的。实操中我看到过融合后性能没问题但精度对不齐的情况，基本都是“内存复用越界”导致，排查时要把buffer占用范围dump出来对齐算子生命周期。

4.3 分布式场景下的图切分与通信优化

大模型时代，单卡装不下模型，图优化必须在“多卡拆分”的语境下重新考虑。图引擎在这里的工作，通常叫“图切分”或者“分布式图优化”。

图切分的第一步，是把一个巨大的计算图按照某种策略切成多份，分配给不同的卡。常见的有按层切分（Pipeline Parallelism）、按张量维切分（Tensor Parallelism）。图引擎要做的是在切分处自动插入通信算子，比如AllReduce、AllGather、ReduceScatter。这些通信算子在IR里也是节点，可以被优化。

第二步更重要：通信优化。通信优化的核心是减少通信量和隐藏通信时延。比如把多个小的AllReduce合并成一个大的AllReduce，能减少通信次数；又比如重算（Recompute）策略，把某些中间结果不保存，反向传播时重新算一遍，以减少通信量；再比如把通信和计算重叠，让一块数据在通信的同时，另一块数据继续做矩阵乘。

图引擎在这步的难点在于：切分方案和通信方案互相影响，而搜索空间是指数级的。所以工程实现上，通常会先基于预设规则做一个合理的初始切分，再通过若干轮迭代优化。看过系统里实际跑大模型的日志就会发现，图引擎在切分后还会对内存复用、AOE调优做二次调整——因为重新切分之后，单个算子的shape、数据排布可能都变了，原来的优化配置未必还适用。

5. 实测调优方法：从profiling数据定位图引擎瓶颈

前面讲的都是原理和机制，但日常做性能调优时，最大的敌人其实是“看不到图引擎内部发生了啥”。幸好CANN提供了profiling工具和dump机制，能让我们把图优化前后的细节拉出来看。这一节我讲讲自己实际用过的排查方法和一个典型case。

5.1 读懂profiling数据的层级关系

不少人拿到profiling报告，只会看一眼“总耗时”和“算子耗时排名”，然后就去改算子实现。但如果瓶颈真的是图引擎引入的冗余transdata、低效tiling或者不当的内存复用，只看算子耗时是看不出来的。

我建议按三个层次看数据。第一层看“图级视图”，确认整个执行图里有没有异常多的数据格式转换节点、有没有不该存在的搬运节点；第二层看“算子级视图”，找耗时大户，但重点看它的“理论计算时间 vs 实际耗时”的差距。如果实际耗时远大于理论计算时间，大概率是搬运没隐藏好或者tiling切太小；第三层看“硬件跟踪视图”，看AI Core利用率、DMA繁忙率、L2命中率这些指标。如果DMA一直很忙但AI Core经常空闲，说明流水线没铺满，问题常出在tiling粒度或同步策略上。

这三个层次是递进关系：先看图上有没有“多余的活”，再看单个算子干得有没有效率，最后看硬件层面干活时有没有空转。

5.2 一个真实调优案例：为什么Conv+BN没有合进去

我用一个实际排查过的问题来演示这套方法。某个模型在CANN上的性能比预期的差，profile出来发现大量Conv和BN分开了，图里到处都是“孤立”的BN节点。按经验，这种结构应该被融合进Conv才算正常。

第一步，看图级视图，确认融合是否被跳过。第二步打开图引擎的编译日志（设置环境变量ASCEND_GLOBAL_LOG_LEVEL=1，并开dump图），把优化前和优化后的图各存一份对比。对比后发现：有一部分Conv+BN确实融合了，但另一部分没有。没融合的那部分有几个共性：它们的输入不是标准的NCHW，而是某个自定义5D格式。

问题定位就清晰了：融合规则的匹配模式要求Conv的输出格式和BN的输入格式必须一致，而那个5D格式虽然语义上等价，但pattern匹配不出来。图引擎的规则是一种基于结构匹配的pass，它对“形态”非常敏感。解法也不是去改模型，而是在图优化配置里加上对该格式的标准化转换——把这个5D格式在进入融合pass前统一转回标准排布，或者配套的融合规则显式支持该格式。

这个case让我印象很深，因为它说明了图优化不是“万能魔法”，规则有边界，而edge case往往藏在数据格式的角落里。

5.3 图dump、IR可视化和调优日志的使用

图引擎调优，掌握“dump”和“log”是关键操作。

图dump一般能导出优化前后的计算图，格式是类似graph的文件或文本IR。用文本IR的时候，我习惯先搜transdata节点，数一数转格式出现几次，基本就能判断格式传播做得好不好；然后看有没有孤立的Cast节点、Const节点，它们往往对应常量折叠没做干净。

调优日志则要看几个关键标记。一是“fusion pass xxxxx start/end”，确认每个pass是否正常跑完；二是“ub size overflow”，这是融合被拒的常见原因；三是tiling日志里有没有fallback提示，比如“use default tiling strategy”。日志里一旦出现“fallback”，说明当前shape触发了保守策略，性能大概率不是最优，需要进一步用AOE做针对性调优。

我会建议做性能优化的同学养成一个习惯：每次改模型或者换shape，都先dump一版优化的图，和旧图做diff。图形化工具看不出来差异，但文本diff可以非常直观地发现新增的transdata、被拆开的融合算子、异常的内存分配变化，这些往往就是性能变化的来源。

6. 图引擎实战中的高频坑与个人经验

最后这部分，我来聊一些实战中反复踩到的高频坑。这些坑不一定写在CANN的官方文档里，但几乎每个做得深的人都会遇到。

6.1 静态图与动态shape的取舍

动态shape是个大坑。图引擎在编译阶段有大量的优化依赖于具体数值——shape、stride、对齐大小、buffer占用量。一旦shape是动态的，很多优化就没法做：tiling不能提前算死，内存复用不敢激进，算子融合也可能要保留更多运行时检查。

所以我的实际经验是：能转静态图就转静态图，不要轻易为了所谓“灵活性”牺牲编译优化空间。如果确实需要动态shape，尽量把动态维度限制在batch维或者序列长度维，并且给这些维度设置合理的上限。图引擎可以根据上限计算最坏情况的内存占用，很多优化仍有机会生效。

6.2 融合规则不是越多越好：UB容量边界

很多人会试图调整图引擎配置，把融合pass开到最激进，以为融合越多性能越好。但前面提到过，融合的硬边界是“UB容量”。强行融合导致tiling切到很小，反而增加循环开销；或者因为中间数据放不下，被迫退回非融合路径，那日志里会一堆overflow警告。

我个人的做法是：先跑默认配置，看profiling里AI Core利用率，如果利用率偏低，再看是搬运问题还是调度问题。只有确认瓶颈确实在算子间反复读写DDR，才考虑激进融合。激进融合之后一定做一次AB对比，不要假设融合一定是正的。

6.3 版本升级后图结构变化的排查方法

CANN版本升级之后，同一个模型的图结构可能变化很大，有时候性能变好，有时候莫名其妙变差。这种问题最考验图引擎的使用者。排查时第一件事不是看算子耗时，而是diff升级前后的优化图。我遇到过两次性能倒退，一次是升级后多了一个transdata节点，另一次是升级后融合规则的匹配优先级变了，导致某两个算子不再融合。如果没有图dump的diff，这种问题靠猜成本极高。

所以我的习惯是：升级版本之后，把之前压测过的每个模型都重新过一遍图diff和性能基线测试，不要因为接口没变就假设行为不变。

最后再分享一个小技巧：文本IR里搜transdata和Cast节点是个性价比极高的自检动作。实际上大部分图引擎性能问题到最后都能追溯到“格式转换变多”和“融合没合上”这两件事。多和这两类节点较劲，比盲目调优参数要有效得多。