AI 编译栈层级总览：从计算图到部署，每篇工作在哪一层

同一批 systems 论文分担的是同一条流水线的不同段：从 PyTorch 等框架的计算图，到图级 IR、图级变换、算子拆分与 kernel 编排、kernel 内调度与 codegen，最后到运行时执行。 本文先把这条管线拆成可对齐的层次，再逐篇给出每个工作的层级位置、输入、输出、完成了什么，并把分层结论汇总成一张总览图（§2 图 1）。

先说结论性的判断：

1. TVM^[1] 与 MLIR^[2] 属于同一类角色——端到端编译栈及其基础设施：torch/graph 进，各 lowering 管线出，中间靠 pass 与多层 IR 推进；
2. TASO^[3]、Pet^[4] 属于"图级优化 pass"：替 TVM/框架的图优化层提供自动生成或更强的等价变换，相当于"另一个图优化层"；
3. OLLIE^[5] 把搜索空间从"预定义算子可表达的图"扩大到一般张量代数表达式，仍是表达式层；
4. Korch^[6] 介于图与 codegen 之间：先算子拆分再编排 kernel——决定"哪些 kernel、算什么"，不发明新的 kernel 内容；
5. Mirage^[7] 跨图级与 kernel 级联合搜索，MPK^[8] 把任务图编译成单个 megakernel 并自带设备内 runtime；
6. TileLang^[9] / PipeThreader^[10] 是同一开源工作线的两个名字（论文 PipeThreader、开源仓库 TileLang），活在 kernel 内部：tile DSL、单元映射与流水排程；Hexagon-MLIR^[11] 是用 MLIR 搭起来的一条具体 NPU 编译栈。

1. 参考流水线与分层标准

直接把项目塞进"Expression / Schedule / Execution"三层会踩坑：这三个词混了程序表示、优化决策、执行过程三种标准，所以单个项目经常归不了位。更稳的对齐方式是按软件职责沿编译流程分段，正面回答"从计算图到部署，中间发生了什么"：

流水线各段的形状与各工作的覆盖范围,统一汇总为 §2 的图 1——纵向四列即上表 ②–⑤ 段,横向长条给出每个项目实际覆盖的编译段。

两个补充约定：

• 跨层是常态：TileLang 同时提供 DSL（L4 之上的接口）和编译后端（L4/L5 的生成物）；TVM 覆盖 L2–L5 全部；MPK 同时伸到 L5 的设备内 runtime。总览表和 SVG 里要画"覆盖条"，而不是给每个项目强行分配唯一一层。
• schedule 分三处发生：tile / 循环 / 单元映射这类静态决策在编译期（L4）；依赖就绪后派发任务发生在运行时（L5）；指令级调度发生在硬件内部，编译器和 runtime 管不到。三者不能合成一个"Schedule 层"。

2. 层级总览

主管线的四个编译段（②–⑤）与各工作的角色定位汇总为图 1：纵向四列是主管线编译段——输入是框架导出的计算图，输出是可直接部署的推理产物；段内圆角卡片给出每个工作在该段做的事；横向长条给出每个项目实际覆盖的编译段；MLIR 作为基础设施以虚线画在主管线下方，向上支撑 ② 与 ④，Hexagon-MLIR 是它的实例化产物。

读图时只需记住两点：

• 长条与卡片不是两套层级：卡片是"这个工作做什么"，长条是"它管到哪几段"（例如 Mirage 的卡片职责在 ④ 附近描述，长条却横跨 ②–④，表示它同时做代数变换与 kernel 生成）；
• MLIR（虚线）是旁路基建：支撑 ②③④，自身不是主管线上的一段；用 MLIR 搭出的 Hexagon-MLIR 条才是主管线上的实例。

3. 逐篇详述

3.1 TVM[1]：端到端编译栈的参照系（L2–L5）

输入是各框架导出的模型描述；输出是针对 CPU / GPU / JavaScript 等目标的优化代码与执行 runtime。它分两半：Relay 做图级（L2）的优化与 pass 编排，下半是算子级的张量表达式 + schedule 搜索与 codegen（L3–L4）。TVM 对这批工作最大的意义是定义了"上游在 Relay、下游在算子级"这条骨架：TASO、Pet、OLLIE 这些工作都在替它的某一层找更优解，而不是另起炉灶。这条线的作者脉络也一路延续：TASO 在 Stanford 完成（第一作者 Zhihao Jia）^[3]，Jia 到 CMU 后的 Korch^[6]、Mirage^[7]、MPK^[8] 接力做向 kernel 编排与 megakernel。

3.2 MLIR[2]：基础设施，不是流水线上的层（S1）

MLIR 的贡献不是"多一个优化 pass"，而是把 IR 方言本身做成可组合的基础设施：dialect 定义、pass 管线、progressive lowering。它解决"每个领域自建一套 IR 重复造轮子"的问题（这一点在本分类MLIR 原始论文笔记里已经展开）。所以它在图里画在管线旁边，位置与"torch 进来的第一站"无关；Hexagon-MLIR^[11] 才是用它搭出的具体管线实例。

3.3 TASO[3]：自动生成图级代数替换（L2）

输入：DNN 计算图。输出：等价、开销更小的图。TASO 的关键在"生成"二字：从基本代数公理出发，用验证引擎自动推导出候选图替换（substitution），再在整个替换空间里搜索最优应用方式——过去的图优化器靠人或工具手工写规则，TASO 属于把图优化层的规则生产本身自动化^[3]。这第一次把"图级优化 ≈ 更强的 pass 管线"这件事做实了。

3.4 Pet[4]：部分等价变换 + 自动纠错（L2）

输入：DNN 计算图。输出：等价性被修复过、且开销更小的图。Pet 的动机是 TASO 一类严格等价变换太保守：有很多优化只在部分输出前缀的意义上等价（例如拓扑结构改变、算子增减）。Pet 允许这些不等价的变换存在，再靠自动纠错（automated corrections）修补被破坏的部分^[4]。层级上与 TASO 同段，特点是把图级变换的"可做"范围放宽。

3.5 OLLIE[5]：一般张量代数表达式的推导搜索（L2→L3 表达空间）

输入：张量程序。输出：更优的表达式（可直接进入后续 kernel 生成）。Pet / TASO 的搜索空间是"预定义算子集合可表达的图"，OLLIE 把表达式空间扩大到一般张量代数表达式，用 derivation-based（推导演绎）的混合搜索（探索式 + 引导式）找它们之间的变换^[5]。它意味着上游的表达层本身也是可搜索对象——图级优化与算子表达的边界变得模糊，但仍在"选表达"而不做"定 codegen"。

3.6 Korch[6]：算子拆分 + 优化 kernel 编排（L3）

输入：DNN DAG。输出：可直接部署在 GPU 上的可执行文件。Korch 与过去贪心式算子融合的关键差异在先拆后编：先把张量算子拆分（fission）成一组基本张量代数原语，再把"这些原语如何编排成 kernel"形式化成带约束优化问题，用现成的 binary linear programming 求解器搜全局最优编排^[6]。它不属于 TASO 那一类的代数替换，也不像 TileLang 那样写 tile 调度——它做的正是 L3 的决策：哪些原语进哪个 kernel、kernel 边界放哪。这也是为什么它比图优化层低一档、又比 kernel codegen 高一层。

3.7 Mirage[7]：三级 µGraph 超优化（L2–L4 联合）

输入：张量程序。输出：优化后的 µGraph，包含代数变换、schedule 变换与新生成的自定义 kernel^[7]。Mirage 的意义在于中游与下游的联合：同一个 µGraph 表示里同时覆盖 GPU 计算层级的 kernel 级、thread block 级、thread 级，使代数变换（图级）与代码生成（kernel 级）可以在一个搜索里交互。正因为表达能力横跨这三层，下游的 MPK^[8] 拿它的输出（或其生态内的张量程序）做 megakernel 才是顺路的——这两项工作同属 mirage-project 仓库^[7][8]。

3.8 MPK[8]：megakernel 编译 + 设备内 runtime（L4–L5）

输入：多 GPU 模型推理的张量程序。输出：一个 CUDA megakernel + in-kernel runtime，跑在单个 persistent kernel 里^[8]。MPK 的编译端做 SM 级任务图（把任务及依赖切到 SM 粒度）、给每个任务生成 CUDA；runtime 端在 kernel 内部用去中心化的派发让任务流水起来——绕开 kernel-per-operator 模式下的 kernel 边界与 launch 开销。所以 MPK 的层级跨度是 L4 → L5，同时占住两个相邻段：编译端（L4）编排任务图并生成每个任务的代码，runtime 端（L5）在设备内运行时派发这些任务。把它简单归为"只做调度优化"会漏掉前一半，只看作"完整编译器"又会漏掉设备内 runtime 这一半^[8]。

3.9 TileLang / PipeThreader[9][10]：kernel 内部的表达与调度（L4）

两者是同一条工作线的两个名字：PipeThreader 是论文（OSDI'25）的名字，TileLang 是同一工作的开源仓库与生态的名字——论文摘要直接把 TileLang 仓库列为开源地址^[10]，其后 TileLang 仓库独立演化为通用 tile DSL 生态（含 CUDA 与 Ascend 后端的分工，见专篇表 1）。 所以图中只画一张卡，不能当成两个独立系统。定位：

• TileLang^[9] 输入 Python 风格 tile DSL，输出面向 CUDA / Ascend 等设备的代码。它把"写 kernel"这件事从"写完整 kernel 代码"提升成"写 tile 级拆分与搬运描述"，覆盖 L4 的表达接口和 L4 内的 codegen；
• PipeThreader^[10] 的论文贡献是用 sTask-graph / sEU 抽象，把 L4 里 tile 划分 → tile 到专用执行单元映射 → 流水排程三个决策做成联合搜索，输出 sProgram^[10]。

3.10 Hexagon-MLIR[11]：用 MLIR 搭的具体 NPU 编译栈（L2–L4）

它是"MLIR + 具体硬件"组合的实例化：从图 / tensor 级 dialect 一路 lower 到 Qualcomm Hexagon NPU（HVX-vector 单元）的可执行代码。它贡献的是"dialect 栈 + progressive lowering 到一个真实 NPU"怎么搭，而非提供新的图优化或 kernel 搜索算法。详细展开在已有专篇。

4. 归层讨论：几个容易画错的点

1. TASO / Pet / OLLIE 画在图级、也画在"pass 层"，别拉去和 kernel 编排并列。它们不改变"kernel 怎么写"，只改变"图里有哪些算子、以什么代数形式出现"^[3][4][5]。
2. Korch 不属于"tile 调度"：它不写 tile、不做循环排程；它回答"kernel 边界在哪、原语怎么归属 kernel"^[6]。把 Korch 与 TileLang 画在同一层会误导。
3. Mirage 与 MPK 是上下游配套：Mirage 在图 → kernel → block → thread 三级上找更优 µGraph，MPK 把任务图变成 megakernel 并提供设备内 runtime^[7][8]；单独看 MPK 时要注明它不是独立 compiler 前端。
4. schedule 不等于 runtime 也不等于硬件：tile / 循环 / 单元映射等决策发生在编译期（Korch / TileLang / PipeThreader），任务派发发生在kernel 内 runtime（MPK），指令级流水发生在硬件内部，编译器和 runtime 都管不到。三层"调度"含义不同，图 1 与归层时都要分开标注。
5. MLIR 与 TVM 同级画法：TVM 是具体的一条端到端管线，MLIR 是搭管线的基建——或两者都画，或二选一，但MLIR 必须与 Hexagon-MLIR 区分（前者是 dialect infra，后者是 NPU 编译栈实例）。

5. 相关阅读

• MLIR 原始论文：动机与设计原则
• Hexagon-MLIR：NPU 编译栈
• PipeThreader 与 TileLang：kernel 表达与流水

参考文献

1. Chen T, Moreau T, Jiang Z, et al. TVM: An Automated End-to-End Optimizing Compiler for Deep Learning[C]//13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). USENIX Association, 2018. https://www.usenix.org/conference/osdi18/presentation/chen.
2. Lattner C, Amini M, Bondhugula U, et al. MLIR: Scaling Compiler Infrastructure for Domain Specific Computation[C]//2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 2021: 2-14. https://ieeexplore.ieee.org/document/9370308.
3. Jia Z, Padon O, Thomas J, et al. TASO: Optimizing Deep Learning Computation with Automatic Generation of Graph Substitutions[C]//Proceedings of the 27th ACM Symposium on Operating Systems Principles (SOSP 19). ACM, 2019. https://dl.acm.org/doi/10.1145/3341301.3359630.
4. Wang H, Zhai J, Gao M, et al. Pet: Optimizing Tensor Programs with Partially Equivalent Transformations and Automated Corrections[C]//15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21). USENIX Association, 2021. https://www.usenix.org/conference/osdi21/presentation/wang.
5. Zheng L, Wang H, Zhai J, et al. OLLIE: Derivation-based Tensor Program Optimizer[J]. arXiv preprint arXiv:2208.02025, 2022. https://arxiv.org/abs/2208.02025.
6. Hu M, Venkatram A, Biswas S, et al. Optimal Kernel Orchestration for Tensor Programs with Korch[J]. arXiv preprint arXiv:2406.09465, 2024. https://arxiv.org/abs/2406.09465.
7. Wu M, Cheng X, Liu S, et al. Mirage: A Multi-Level Superoptimizer for Tensor Programs[C]//19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). USENIX Association, 2025. https://www.usenix.org/conference/osdi25/presentation/wu-mengdi.
8. Cheng X, Zhang Z, Zhou Y, et al. MPK: A Compiler and Runtime for Mega-Kernelizing Tensor Programs[C]//20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 26). USENIX Association, 2026. https://www.usenix.org/conference/osdi26/presentation/cheng.
9. Tile-AI. TileLang[EB/OL]. 2026. https://github.com/tile-ai/tilelang.
10. Cheng Y, Wang L, Shi Y, et al. PipeThreader: Software-Defined Pipelining for Efficient DNN Execution[C]//19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). USENIX Association, 2025. https://www.usenix.org/conference/osdi25/presentation/cheng.
11. Absar M J, Baskaran M, Sharma A, et al. Hexagon-MLIR: An AI Compilation Stack For Qualcomm's Neural Processing Units (NPUs)[J]. arXiv preprint arXiv:2602.19762, 2026. https://arxiv.org/abs/2602.19762.