一段写得明明白白的Python函数，真正要在NPU上跑起来，中间隔着的不是一层解释器，而是一条完整的编译流水线。我在做算子迁移那阵子，把CANN pyasc这条Python语法到硬件指令的编译路径反复研究了很多遍，越看越觉得它像一座立交桥：上游是Python这种动态、解释执行、什么都留到运行时再决定的语言；下游是NPU这种只认指令、追求静态调度和极致并行的硬件。两头差异大到几乎不可能直接翻译，只能一层一层做中间表示，每一层丢掉一部分灵活性，换取一部分确定性和性能。
这篇东西就是我梳理整条编译流程的记录。适合三类人看：一是做算子迁移、想让自定义算子跑上NPU的算法工程师，你需要知道Python代码会经历哪些阶段才能变成可执行任务；二是做性能调优、总在猜"为什么模型跑不满"的工程师，很多性能问题根源根本不在算子本身，而在于图和调度；三是对AI编译原理感兴趣的学生或爱好者，拿一条真实链路当样本，比看教科书里的编译器理论要直观得多。
1. 先看全局：pyasc在哪一层，Python代码进NPU之前要过几道关
1.1 从解释器到NPU的完整链条
先给一条完整的链路铺开来看，后面每一节都会落在其中一段上：
- 用户写的Python脚本，首先被CPython解释器正常执行，普通运算照常走CPU；
- 当执行到张量相关的运算调用时，框架层会拦截下来，交给CANN的前端引擎；
pyasc负责解析Python语法和语义，把它翻译成一个算子级的有向无环图（DAG）；- 图引擎（GE）拿到这个图之后，做图优化、算子融合、内存规划；
- 算子编译层把优化后的图编译成NPU能执行的指令序列，同时生成任务描述；
- 运行时按图执行顺序，把任务提交给硬件调度器，最终由AI Core执行。
这条链路我习惯用"翻译公司"来类比：Python是英文原稿，NPU指令是目标语言。中间流程其实很像笔译工作流——AST解析相当于逐句切片和断句，图优化相当于编辑校稿、删掉冗余表达，算子编译和调度相当于排版和定稿。每一道工序处理的对象不同，关心的质量指标也不同：语法解析阶段关心"这句话到底想干什么"，图优化阶段关心"怎么表达才能少干活"，调度阶段关心"多核之间怎么配合才能不空转"。
1.2 前端引擎的分工：pyasc的边界在哪里
CANN里负责前端的其实不止pyasc一家。框架适配层、图引擎、算子编译工具链各有各的管辖范围，我一开始搞混过，所以先把边界画清楚：
| 层次 | 主要职责 | 输入 → 输出 |
|---|---|---|
| 框架适配层 | 对接不同AI框架的Tensor对象和API | 框架调用 → 统一描述的张量运算 |
| pyasc前端 | Python语法/语义解析、图构建 | Python源码/函数对象 → 算子级DAG |
| 图引擎 | 图优化、资源规划、图切分 | DAG → 优化后的可执行图 |
| 算子编译层 | 算子实现、tiling、指令生成 | 算子描述 → 硬件指令/二进制 |
| 运行时 | 任务下发、事件同步、资源管理 | 任务描述 → 硬件执行 |
pyasc的核心边界就在"Python语义到可优化图"这一段。很多人误以为它要负责全部编译工作，其实不是。它更接近编译原理里的"前端"，真正做指令生成的活在后面。理解这一点特别重要：你在优化Pass或算子调度里看到的各种怪现象，往往没法在前端改，反之亦然。出了问题先定位是哪一层，能省掉一大半排查时间。
1.3 不是所有Python代码都会进编译管线
还有一个刚接触时容易踩的认知坑：pyasc并不会把Python代码全部编译了。一个脚本里大量纯Python逻辑——文件读写、字符串处理、字典操作、列表推导——这些照常在主机端CPU上运行，根本不进编译管线。只有真正作用在张量对象上的运算，才会被识别并转化为图节点。
识别依据分两步：静态的AST分析先筛出候选的运算节点，动态的类型信息再做最终确认。比如x * w + b这段表达式，AST阶段看到的是两个BinOp节点，但编译器不知道x到底是普通数值还是张量，需要等到真实执行时拿到对象类型，才能决定是直接计算还是进图编译。
自定义算子也是这么进来的。你用某个装饰器或API把函数体注册进去，pyasc拿到的是函数对象，对其AST做一遍分析，把涉及张量的部分提取成算子逻辑，剩下的Python控制代码仍然留在主机端。这带来一个常见问题：自定义算子函数里如果写了太多Python层面的逻辑（比如大量dict操作、异常处理、动态属性访问），编译期很难静态处理，性能会受影响。后面专门讲。
2. 第一道变形：AST解析、作用域分析和张量操作识别
2.1 Python源码怎么变成语法树
pyasc的第一步，是把Python源码解析成一棵抽象语法树（AST）。这个过程用的是Python标准库的ast模块，原理很简单：
import ast code = "def f(x): return x * 2 + 1" tree = ast.parse(code) print(ast.dump(tree, indent=2))输出里能看到FunctionDef、BinOp、Return、Constant这类节点。这一步本身不算复杂，复杂的是后续遍历。pyasc会在AST上做一次深度遍历，同时维护一张作用域表（symbol table），记录每个变量的"身份"——是普通Python对象、张量、还是shape占位符。
这里有个容易忽略的细节：AST是纯静态结构，它只说明代码"长什么样"，不说明代码"会干什么"。真正的语义识别发生在遍历时结合类型信息的那一步。拿x * w来说，AST只能看出来这是个乘法表达式，只有当pyasc确认x和w都是张量对象时，它才会决定创建一个Mul算子节点并挂进图中。
2.2 一个简单函数如何变成图节点
用一个最常见的融合算子来演示：
def fused_op(x, w, b): y = x * w + b return y当pyasc拿到这个函数后，大致的图化过程是这样的：
x、w、b作为输入，先创建占位节点，同时记录各自的shape和dtype；x * w对应AST里的BinOp(Mult)，因为两个操作数都是张量，创建一个Mul节点，输入边指向x和w；- 结果再与
b相加，创建一个Add节点，输入边指向Mul的结果和b； b如果是个Python常量，会直接在图中创建一个Const节点，而不是当作输入；return y不产生节点，只是把y标记为图的输出。
最终得到的图就是一个很小的DAG：Const(w) -> Mul -> Add -> Output(y)。这里的"图"和用户平时理解的神经网络图不完全一样：它是算子级DAG，粒度更细，每个矩阵乘法、每个加法、每个reshape都是一个节点。这也意味着一个ResNet模型在pyasc手里会产生几百上千个节点，图优化和后端处理必须扛得住这个规模。
2.3 循环、分支和数据依赖怎么处理
比基础表达式麻烦的是控制流。Python的for循环在硬件上不可能直接执行，pyasc会做两种处理：如果循环边界是静态的（比如for i in range(4)），编译器倾向于把循环体展开，用4份子图替代；如果循环边界取决于运行时数据，就只能保留为控制算子，运行时根据条件决定进入哪个分支。
if/else的分支处理更典型。pyasc会把条件判断提炼成节点，两个分支分别构造成独立的子图：一个true_branch子图，一个false_branch子图。执行时根据条件张量的值，硬件会选择走哪条分支。
为什么要费这么大劲？因为NPU的指令调度是静态的。硬件在执行前就需要知道内存布局、指令顺序、数据依赖关系，如果控制流不显式化，编译期就没法做内存规划和指令排序，性能会大打折扣。这也是为什么很多AI编译器都强调"把所有东西显式化"——你越早把不确定性变成确定性，后端优化空间就越大。
2.4 shape推导和dtype推导：编译期确定性的来源
图构建之后，紧接着是shape和dtype推导。每个节点的输出shape必须确定下来，后端才能规划内存、切分tile、生成指令。推导规则通常沿着图的数据边传播：输入shape已知，乘法的输出shape等于广播后的形状；矩阵乘的输出shape由两个输入的M、K、N维共同决定。
实际项目中shape推导常常让人头疼，因为模型里总有人写动态shape的输入：有时batch维不确定，有时序列长度可变。pyasc对这种输入会插入动态shape占位符——rank确定但具体维数运行时才知道。这直接带来后果：动态shape意味着编译期没法做最激进的内存规划和算子融合，性能通常比静态shape差一截。所以我的习惯是，能固定shape的模型入口尽量固定，给编译器多留一点确定性。
3. 图优化：把一群"零散算子"改写成"趁手的算子"
3.1 优化Pass的基本套路：扫图、匹配、重写
图构建完成后，pyasc会把图交给图引擎做优化。优化过程由一串Pass组成，每个Pass就是一遍"扫描-匹配-重写"：遍历所有节点，用模式匹配找到可优化的子图结构，然后替换成更高效的等价结构。
常见的基础Pass包括：常量折叠（把Const(2) * Const(3)直接变成一个常量节点）、死代码消除（输出永远不会被用到的节点直接删掉）、公共子表达式消除（两个结构相同且输入相同的节点合并成一个）。这些和CPU编译器里的同名优化思路一致，但AI场景还有几个更关键的Pass：算子融合、布局转换、内存规划。
我曾经犯过一个理解偏差：以为优化Pass越多越好。实际不是。每个Pass本身要花时间遍历图，有些Pass重写之后还会让图的形态发生变化，反而影响后续Pass的匹配。所以编译器团队要花很大精力设计Pass的执行顺序——先做代数化简，再做算子融合，再做布局优化，最后做内存规划，这个顺序基本是固定套路。
3.2 为什么算子融合是性能关键
算子融合大概是整个图优化里收益最明显的一项。背后的原理很朴素：NPU上执行一个算子的成本，远不止"计算"本身。每个算子从HBM（片外内存）读取输入、计算、再把结果写回HBM。这个存取开销在数据密集型算子里往往占据大头。
以Conv + BiasAdd + ReLU为例。不融合时，卷积结果要写回HBM，BiasAdd再读出来算一遍，ReLU又读一遍。三次算子执行带来至少两次全量数据往返。融合之后，卷积算子在片上计算单元（UB）里完成计算后，中间结果停留在片上，紧接着做加偏置和激活，最后只把最终结果写回HBM。访存量直接砍掉一大半。
不过融合不是无脑叠加。我见过几种不适合融合的情况：一是某个中间结果被多个下游使用，融合会导致重复计算；二是两个算子的访存模式差异太大，硬融在一起反而破坏各自的流水；三是某些算子涉及精度敏感操作（比如fp16中间结果），融合会改变计算语义。什么时候该融，什么时候不融，这就是优化Pass里匹配规则设计的学问。
3.3 布局转换与5D格式：一个容易被低估的优化点
模型训练和推理阶段，用户侧的Tensor布局通常是NCHW或NHWC。但NPU硬件搬运数据时，更偏好一种按通道维分块的5D格式，类似NC1HWC0的形式。其中C0是硬件单次处理的数据块大小，和矩阵计算单元的K维度对齐。
这种格式差异决定了图优化阶段必须处理布局问题。有两种做法：要么在图里显式插入Transpose节点，要么把布局信息作为算子属性传下去，让算子内部处理。显式插入Transpose简单直接，但会带来额外的数据搬移开销——一个多余的转置节点，可能就是10%的性能损失。
实际调优时，我特别建议关注dump出来的图里有没有大量Transpose节点。如果发现模型里transpose满天飞，首先要怀疑布局推导没做好，而不是从算子实现层面找问题。好的布局优化会在编译期做全局分析，尽量避免插入多余转置，哪怕必须转换，也会尝试把转换融合到相邻算子的访存逻辑里。
3.4 内存规划与buffer复用：优化前后显存差异的来头
图优化的另一大项是内存分配。图中每个张量都需要内存空间，简单粗暴的方案是每个节点输出各占一块，这样显存占用会非常夸张。优化Pass会做张量生命周期分析：每个张量从哪个节点产生、到哪个节点之后不再被使用，然后允许生命周期不重叠的张量复用同一块内存。
同一张计算图，优化前每层都可能独占一整块中间buffer，优化后这些buffer被压缩复用，显存占用可能差出一倍以上。片上的统一缓冲区（UB）容量更小，任何大tensor都要切分成tile才能塞进去，所以内存规划还要和后面的tiling策略配合——先确定每个tile多大合适，再根据tile的生存周期规划UB里的buffer复用。
4. 最后一公里：指令生成、调度与任务下发
4.1 NPU算力单元：cube、vector、scalar三类分工
图优化完成之后，就到了最像"编译器后端"的阶段：把图节点映射到硬件指令。NPU内部不是单一大核，而是包含多种计算单元，各自擅长不同类型的运算：
| 计算单元 | 擅长场景 | 典型算子 |
|---|---|---|
| Cube单元 | 矩阵乘、卷积等张量密集型计算 | MatMul、Conv2D、BatchMatMul |
| Vector单元 | 逐元素、激活、归一化、类型转换 | Add、ReLU、Softmax、Cast |
| Scalar单元 | 地址计算、控制流、少量标量逻辑 | 索引计算、条件判断、循环控制 |
编译时最重要的一步就是"分诊"：判断每个图节点应该落到哪类单元上。一个融合后的算子可能同时用到多个单元：比如卷积融合算子，主体计算走Cube，加偏置和激活的尾部计算走Vector，地址偏移和tile循环控制走Scalar。这就是指令级异构——几条指令流互相配合完成一个算子。
4.2 从图节点到指令序列：tiling、调度、代码生成
图节点变成指令序列，核心过程有三个：tiling（切分）、调度（安排执行顺序）、代码生成（产出具体指令）。
tiling解决的是"放不下"的问题。一张大矩阵的乘法和卷积，片上UB一次装不下，必须切成小块依次计算。切分策略直接影响数据复用效率：比如矩阵乘法，如果tile切得太大，UB放不下；切得太小，数据搬移次数猛增。经典做法是沿着K维度切块，保证每个tile都能在UB里完成累加，再考虑L1/L2缓存层次决定循环顺序。
调度负责编排指令顺序和并行方式。数据搬运指令和计算指令之间可以重叠——搬运第N块数据的同时计算第N-1块，这就是双缓冲。多核场景则要做任务划分：按batch维或空间维把tensor切给多个AI Core，每个核独立执行一段计算，最后通过事件同步把结果对齐。
4.3 双缓冲、多核切分与事件同步
双缓冲是整个调度里最直观的优化手段。没有双缓冲时，AI Core的工作节奏是"搬数据-等数据-计算-等搬完-再搬下一块"，搬运和计算串行，计算单元大量空转。加上双缓冲后，数据搬运和计算变成两条流水线重叠执行，利用率能明显拉起来。
多核切分则是把一个大任务拆成多个核并行的小任务。比如一个[N, C, H, W]的特征图，可以按H维切成N份，也可以按batch维切分。切分粒度要平衡负载均匀度和通信开销——切得太碎，核间同步和事件管理成本反而超过并行收益。
事件同步用于保证数据依赖。AI Core之间可能存在上下游关系，CPU侧发任务和NPU侧执行也有先后依赖，这些关系都要靠事件机制显式表达。我在排查性能问题时，经常发现某些算子并行度上不去，根因就是事件同步粒度太粗，后一个核必须等前一个核全部完成才能启动，白白损失了流水线重叠的机会。
4.4 编译产物与运行时职责的划分
把优化后的图编译完，最终产物并不是一个单一的可执行文件，而是"算子二进制 + 任务描述"的组合。预置算子（框架自带的高频算子）通常已经有预编译好的二进制，编译期只需要填写shape参数、内存地址、tile切分信息，生成对应的任务描述即可。自定义算子则要经过完整编译流程，产出可执行的算子代码，再绑定到对应的图节点上。
编译期和运行时的职责划分很有意思：编译期把能定的全部定掉——指令序列、内存布局、依赖顺序、同步事件；运行时只做轻量工作——按图顺序把任务提交给硬件调度器，管理事件等待和资源回收。这种划分保证了执行阶段的开销足够低，也解释了为什么静态图性能稳定、可控，代价是编译耗时和灵活性损失。
5. 调试与调优：别靠猜，把中间产物拉出来看
5.1 怎么导出各阶段的中间图
我对这条链路最大的体会是：调优不能靠猜，一定要把中间产物导出来看。CANN工具链通常提供IR dump的开关，通过环境变量或配置文件开启后，会在指定目录里导出各阶段的图描述——前端构建的原始图、优化后的图、融合后的图、算子调度信息，甚至最终的任务描述。
导出后怎么做？我的习惯是固定一个benchmark小模型，任何改动前先导出一份基线，改动后再导一份，用diff工具对比两版图的差异。百试百灵。很多性能问题——比如某个融合没生效、某个转置节点莫名增多、某个算子被错误地拆分——在图上都是一目了然的，不比对着profile数据猜来猜去高效得多。
5.2 常见编译问题与定位路径
| 现象 | 可能根因 | 检查方法 |
|---|---|---|
| 图编译失败，报"无法推导shape" | 输入shape信息不足或算子语义不明确 | 检查输入定义，用静态shape跑一遍 |
| 算子不支持报错 | 图里出现了预置算子库之外的结构 | 确认算子是否注册，或拆成子算子 |
| 推理精度与参考值偏差 | 融合改变了计算语义，或fp16溢出 | 故意关闭该融合Pattern做对照实验 |
| 性能比预期低很多 | 布局转换节点过多、融合未生效、调度并行度不足 | 导出优化后图和profile数据对比定位 |
5.3 一个实际排查案例：多余的Transpose节点
拿一次实际性能排查来说。某次模型推理延迟总比预期高，profile里看到AI Core利用率不高，但访存时间很长。我先导出了优化后的图，顺手把图里所有节点类型统计一遍，赫然发现大量Transpose节点。
追下去才发现，前排算子输出的布局和后排算子期望的布局不一致，优化Pass没有推导出合适的布局传播，前端的适配层就插入了大量显式转置来兜底。每个转置都是一次完整的数据搬移，性能掉得理所当然。最终解法不是去优化某个算子，而是在图的布局推导逻辑里补了一条规则，让相邻算子的布局信息直接匹配，转置节点批量消失。这个案例给我的教训就是：性能问题要一层一层定位，最不值得做的就是从算子实现层面盲改。
5.4 编译耗时优化与缓存机制
大模型的图编译可能要持续几分钟到几十分钟，工程上非常影响迭代效率。好在编译链路普遍支持缓存和增量编译：不同输入的图如果结构一致，只有shape不同，很多中间产物可以复用。
缓存失效的坑也特别多。常见原因包括：环境变量变了、算子实现版本变了、shape精度变化（比如从int32到int64）、后端配置变了。每次缓存莫名其妙失效时，我会先把环境变量和算子库版本逐一比对，大多都能找到原因。另一个工程技巧是固化子图：把模型中稳定不变的那部分（比如backbone主干）单独编译成固化任务，运行时直接复用，只有动态部分走完整编译路径。
最后再分享一个对初学者最有用的建议：不要一上来就拿大模型练手。挑一个几十行的自定义算子函数，把整个链路从小跑通——构建图、导出中间IR、关闭某个融合Pattern、对比性能——每一步都亲眼看一遍产物变化。这个过程的收获，比读十遍文档都有用。我自己也是这么把CANN pyasc这条Python语法到硬件指令的编译流程真正吃透的。
