最近在帮一个端侧项目做推理引擎选型，被一个实际问题卡了很久：模型不大，但运行库体积动辄几十 MB，为了一个几 KB 的权重文件，硬要背上一整个带调度器、图解释器、算子注册表的运行时。直到我把目光放到 IREE（Intermediate Representation Execution Environment）上，发现它在“把调度和执行一起编译进产物”这条路上走得比我预想的远得多——甚至官方展示过一个 10 KB 级别的极简内核产物。这篇文章就从编译器、调度、执行、产物这几个关键词展开，把我这段研究 IREE 的心得完整记录下来，希望能帮你更快想明白“编译期该做什么，运行期不该做什么”。
适合看这篇的人有三类：一类是做端侧或嵌入式 AI 部署的，正在被运行时体积压得喘不过气；一类是对编译器本身感兴趣，想理解多层 IR 和静态调度怎么落地的；还有一类是把 IREE 当黑盒用，但想知道一条编译命令背后到底发生了什么。无论你是哪一类，我尽量不讲虚的，按真实的编译流水线一步步拆给你看。
1. 先搞清楚 IREE 在解决什么问题
1.1 传统推理引擎的“运行时包袱”
做模型部署的人都知道，传统推理框架通常分三块：图解释器、算子库、运行时调度器。图解释器负责在启动时把模型描述文件（比如 ONNX 或自有格式）解析成内部图结构；调度器拿到图之后，按照拓扑关系把算子逐个派发到 CPU 或 GPU；算子库则提供矩阵乘、卷积、激活这些底层实现。
这套架构在开发调试时很方便，因为图和执行是解耦的，你想在中间加一个算子、换一个设备、改一个 Layout，都相对灵活。但在“极致体积”场景下，这套体系就是灾难：图解释器不管你模型多大，解析框架、类型系统、错误处理逻辑总是要带的；算子库为了防止用户模型里冒出什么冷门算子，得提前编译进一大批实现；调度器里的线程池、内存池、设备抽象层，又是另一块固定开销。结果就是，哪怕你只跑一个 10 KB 的模型，运行时也给你附赠几十 MB 的“基础服务”。
这有点像你只是为了吃一碗泡面，却必须开一家整建制的中餐厅——灶台、蒸柜、洗碗间、厨师团队，一个都不能少。IREE 的思路截然相反：它想做的是“预制菜工厂”，菜谱在出厂前就已经固化成精确到步骤的执行计划，到了现场只需要拆开包装、按下微波炉按钮。
1.2 “编译期调度”和“运行期调度”的分界线
传统框架里，调度往往是运行期行为：模型加载后，运行时发现有两个算子的数据依赖不冲突，才决定让它们并行执行；某个算子在执行时才知道设备上有多少空闲内存，再决定怎么分配缓冲区。这些决策看起来“智能”，但每做一次决策都需要代码路径、数据结构、状态机来支撑，体积自然降不下来。
IREE 的核心思路是：我的模型是静态的，数据流在编译早期就能完全读透，那为什么不把调度结果直接“烧”进产物里？当一个算子在 CPU 上跑、另一个算子在 GPU 上跑，两段代码之间需要什么同步、谁先谁后、中间临时缓冲区摆在哪——这些全部在编译期定下来，运行期只负责按既定顺序机械执行。
当然，全静态也不是银弹。设备数量和运行时环境的变化（比如某块 GPU 突然不可用）确实需要一定的动态适配能力，所以 IREE 保留了一层非常薄、非常可控的运行时抽象，叫 VM（Virtual Machine）和 HAL（Hardware Abstraction Layer）。VM 处理的是“用极小的字节码描述执行流”，HAL 处理的是“用极小的接口抹平设备差异”。相比传统运行时那种庞大的实时解释和图优化引擎，这层执行上下文的体积和维护成本小了几个数量级，这也是“调度和执行一起烧进一个 10 KB 产物”这个故事能成立的前提。
2. 从模型图到 10 KB 产物的编译流水线
2.1 多层 IR 设计：Flow -> Stream -> HAL -> VM
IREE 不是把模型直接翻译成机器码，那样会无限复杂。它中间隔了好几层 IR，每一层解决一个特定问题。常见的一条路径是：
- 前端导入：把 TensorFlow、TFLite、ONNX 等模型转成统一的 MLIR 方言，比如 MHLO 或 TOSA，这一步解决的是“统一输入格式”问题。
- Flow 层：做闭源和开源都要做的数据流分析，建立张量级别的数据依赖图，同时把很多可以在编译期完成的常量折叠、形状推导、别名分析做掉。
- Stream 层：把 Flow 层的逻辑张量运算转换成实际设备上要跑的命令流。这里会做资源规划、执行顺序安排、屏障（barrier）插入、缓冲区生命周期管理。实际上的“调度”主要在这一层定型。
- HAL 层：把设备无关的命令流再翻译成具体的后端实现调用，比如 LLVM-CPU、CUDA、Vulkan、Metal。这一层负责把“我要做一次矩阵乘法”翻译成“我要启动一个 kernels 的 dispatch”。
- VM 层：最后把整个执行计划打包成 IREE VM 字节码模块，再加上 HAL 可执行二进制段（比如编译好的 ELF 或 SPIR-V），合成最终的
.vmfb文件。
为什么要把流程拆得这么碎？因为每一层都可以独立测试、独立优化。MLIR 这个基础设施相当于给了你一套乐高积木，每一层 IR 是一块积木，你可以任意组合、替换、调试，而不是在一整块硕大逻辑里翻问题。想复用同一份调度逻辑去支持 CPU 和 GPU？Stream 层不用改，只换 HAL 层后端就行。想新增一种硬件？本质上是写一个新的 HAL 方言转换器。这种多层设计带来的模块化收益，在实践里非常值得借鉴。
2.2 调度策略如何在编译期固定下来
这是很多人最好奇的部分：调度怎么能“烧”进产物？我拿 Stream 层的典型动作来举例。
这一步会把流图拆分成若干个 dispatch 区域，每个 dispatch 区域对应一个可以整块下发给设备的工作单元。至于怎么拆，要考虑很多东西：算子之间的数据依赖、哪些算子可以融合进同一个内核、哪些中间结果值得留在片上内存、哪些必须落到全局内存。IREE 的编译逻辑里会做缓冲区生命周期分析，如果一个中间张量的唯一消费方就是下一个算子，那这个缓冲区可以被复用或者直接融合，避免一次实际分配。
调度顺序是怎么固化的？Stream 层会生成一组带显式依赖关系的操作序列，同步点也被显式编码。一个典型的同步关系是：GPU 上的 dispatch A 完成之后，CPU 才能读回结果；CPU 写好的权重同步到 GPU 之后，GPU 上的 dispatch B 才能启动。这些关系不是运行时靠事件循环猜的，而是在编译期作为明确的 barrier 指令写进最终执行流。
更有意思的是常量内存规划。模型权重如果是静态的，IREE 会在编译期把它们直接嵌入到产物的数据段里，运行期不再需要从外部文件加载权重。比如你编译一个单算子模型，权重矩阵可以被编码成字节序列直接躺在.vmfb文件的某个段里，与调度指令并列。这就是“调度和执行一起烧进去”的直观含义：不止代码，连数据都提前“烧”好了。
2.3 为什么产物能小到 10 KB 量级
要澄清一下，10 KB 并不是任意模型都能达到的数字，而是 IREE 在极小模型、极简后端、以及激进裁剪条件下面对的实验边界。但它为什么能做到这么小，机制上是说得通的。
第一，IREE VM 字节码本身非常紧凑。它没有传统字节码那种复杂对象模型，每条指令短小、定长或者近定长，而且 export 表、类型表在编译时可以裁剪。你甚至可以把所有 export 符号全清掉，只保留一个入口。
第二，产物里没有图解释器和调度器。“图”的概念在编译期就被展开成了线性的字节码指令流，运行期只需要一个很小的 VM 循环，逐条解析执行。调度决策产生的分支判断、优先级排序、内存分配逻辑，全都在编译器里跑完了，产物里只剩结果。
第三，LLVM 后端的链接裁剪起作用。当目标指向 CPU，IREE 生成的是嵌入式的、自包含的 ELF 二进制，采用类似--gc-sections的方式把没用到的函数和段全部丢掉。再加上关闭调试信息、剥离符号表，剩下的就是干巴巴的机器码。
第四，它不依赖 libc 和完整标准库。在嵌入式模式下，IREE 可以配置成不链接运行时操作系统库，也不链接完整的 C++ 运行时。内存分配也走可替换的抽象接口，而不是硬编码依赖某一个平台原生实现。这样一来，产物体积没有“固定税”。
我自己实测时发现，一个简单的矩阵乘加模型，在关掉调试符号、打开裁剪、选对后端之后，从几十 KB 一路压到十几 KB 是完全正常的。当然，要跑到 10 KB 整，还需要把模型本身压到极简，并使用最精简的编译配置。但这个量级已经足够说明一件事：当你把调度决策从运行时移到编译期，体积的想象空间完全不一样。
3. 实操：从零编译一个最小调度产物
3.1 环境准备与最小模型选择
先交代一下环境：IREE 的 Python 包可以从官方发布渠道直接装，也可以从源码构建。如果你只是想先跑通流程，我建议优先用预编译好的iree-compiler和iree-runtime包，省去从零构建 LLVM 依赖的时间。源码构建的好处是你能切各种调试开关，坏处是初次构建可能要等很久，我在自己机器上完整构建一次大概花了几十分钟到一小时，取决于 LLVM 的并行编译设置。
模型选择方面，为了让产物体积足够小，我从最简单的“两输入相加”和“单矩阵乘”入手。实际操作里，你可以用iree-import-tf或iree-import-tflite把模型转成 MLIR，也可以直接用 MLIR 文本手写一个极小的函数。我更喜欢手写，因为能精确控制算子数量和形状，方便对比编译选项的影响。
下面这个极简计算图，表示y = A * x + b，我经常拿它当基准：
func.func @main(%arg0: tensor<4x4xf32>, %arg1: tensor<4x4xf32>, %arg2: tensor<4x4xf32>) -> tensor<4x4xf32> { %0 = stablehlo.multiply %arg0, %arg1 : (tensor<4x4xf32>, tensor<4x4xf32>) -> tensor<4x4xf32> %1 = stablehlo.add %0, %arg2 : (tensor<4x4xf32>, tensor<4x4xf32>) -> tensor<4x4xf32> return %1 : tensor<4x4xf32> }这个模型只有两个算子，数据依赖非常直观：先乘后加。它足够小，同时又能体现常量折叠与 dispatch 融合的效果。
3.2 关键编译参数行为拆解
iree-compile是核心入口，最影响产物行为的参数大概这几个。先看一个我用过的典型命令：
iree-compile \ input.mlir \ --iree-hal-target-backends=llvm-cpu \ --iree-llvmcpu-link-embedded=true \ --iree-llvmcpu-debug-symbols=false \ --iree-vm-bytecode-module-strip-source-map=true \ --iree-vm-bytecode-module-strip-export-all=true \ -o output.vmfb逐个说参数在干什么。--iree-hal-target-backends指定目标后端，llvm-cpu 是最通用、也最接近“本地机器码”的选择。--iree-llvmcpu-link-embedded=true让生成的 HAL 可执行段以自包含方式嵌入 ELF，而不是依赖运行时动态加载外部动态库。--iree-llvmcpu-debug-symbols=false直接决定产物里有没有 DWARF 调试信息，这一项对体积影响极大，我见过有人忘了关，产物凭空胖出三倍。--iree-vm-bytecode-module-strip-source-map和strip-export-all则把 VM 字节码模块里不需要的映射信息与导出符号全部剥离，就是刀法往里再收一圈。
优化等级怎么选？-O0产物小但执行慢，-O3性能好但编译器要花更多时间做向量化、循环展开和内联。我的经验是，体积敏感时先用-O0看是否够用，实测不够再往上加，不要一开始就盲目开满优化。IREE 的编译管线在高层优化上还有各种开关，比如启用更积极的算子融合策略的选项，开启后 dispatch 数量减少，同步开销下降，体积也有正面效果，但代价是编译时间变长。建议在一个固定 baseline 上逐个开关做 A/B 对比，别一次性全开，否则出了问题根本不知道是哪一步造成的。
3.3 解剖产物：看一个 10 KB 文件里到底装了什么
编出来的.vmfb是一个复合容器，不是一个纯 ELF，也不纯是字节码。你可以用 IREE 自带的iree-dump-module或者iree-benchmark-module --help选项去检查它的内部结构。大致能看到几个典型部分：VM 模块段（包含类型表、函数表、字节码指令）、HAL 可执行段（内嵌目标二进制）、常量存储段（嵌入权重或者常量数据）、以及元数据段。
如果我没有关闭符号表，还能用strings或者objdump在 HAL 段里看到一些函数索引名，比如matmul_4x4_f32之类的内核入口。一旦 strip 之后，这些名字都会消失，但是指令序列还在。一个非常小的模型，内部可能只有几条 VM 指令：
payload: module: main bytecode: (hal.executable) exec : load (hal.command.buffer) reserve, push, exec dispatch, pop (shape.constant) etc.这是我根据自己的经验和 IREE 反汇编输出整理的概念表示，不保证完全对应某个版本，但结构上是合理的。重点不是去死抠字节偏移，而是理解一件事：调度信息在这里已经变成了“顺序指令”，执行上下文是把这些指令一条条喂给 HAL，由 HAL 把 dispatch 发到具体设备。一个很小的 VM loop 就能驱动整个执行过程，没有复杂的图分析，没有昂贵的运行时类型解析，这是它体积瘦小的秘密。
3.4 产物再压缩的两个技巧
第一招是去掉调试符号和导出符号，这个上面讲过，代码里一行参数就能做到。第二招是使用压缩后的常量数据，尤其当模型输出物里主要体积来自权重时，可以在编译前对常量做量化（比如 fp32 转 fp16 或 int8），IREE 对量化模型支持成熟，体积收益显著。但是注意：量化会损失精度，实际部署前一定要拿真实数据评估精度变化，不要只看体积降了多少。
压完体积之后，还有一道工序是检查产物是否可加载。很多人在体积优化之后直接在目标设备上跑，结果报符号找不到或者格式不支持，才发现自己压过头了。经验是：把裁剪参数分档，从保守到激进依次递减，每一档都做一次加载和一次推理验证，找到刚好能通过的那一档。这样既拿到了能接受的体积，也不至于因为过度裁剪把自己坑进排查深渊。
4. 排查实录与避坑指南
4.1 产物不小反而变大，多半是这三个原因
如果你折腾半天，产物反而比预期大，先别怀疑 IREE 不行，大概率是踩了下面某个坑。
第一个原因是后端选择错误。选了 GPU 目标（比如 Vulkan）之后，IREE 可能还需要为 CPU 生成一份 fallback 实现，两份代码都塞进产物，体积自然翻倍。如果目标场景明确只要 CPU，那就限定llvm-cpu，不要手滑加多个 target backend。
第二个原因是调试信息与符号表没清理干净。生成代码里的局部符号、类型名称、源代码映射，看着不起眼，累计起来能占一大块。有些参数在不同 IREE 版本里默认值不一样，建议每次编译后都主动检查一下产物里有没有 DWARF 节或者完整符号表残留，不要想当然以为默认值是关闭。
第三个原因是链接模式搞混了。动态链接模式下，IREE 会生成对外部动态库的引用和加载代码，这不仅让产物不独立，还可能因为连带引用了很多库的重定位信息而膨胀。嵌入式链接模式在这件事上通常表现更好，能直接产出纯静态、自包含的二进制。
4.2 目标环境缺平台依赖
我在 Linux 上编译没问题，换到 Windows 部署时碰到过缺少某些 VC 运行时 DLL 的问题，当时报警信息很典型：找不到 msvcp140.dll 或 vcruntime140_1.dll。虽然 IREE 本身不含这些 DLL，但它生成的代码或运行时库可能链接了它们。在 Windows 上，你得确保目标机器安装了对应版本的 Visual C++ Redistributable，或者用静态链接的方式把运行时库编进去，后者体积更大但更省心。
另一个常见场景是嵌入式设备上运行，系统里没有动态加载器、没有可用的 libc 实现，甚至连浮点环境都可能不标准。这种情况下不要直接拿 PC 上生成的.vmfb硬塞，那等于把桌面的依赖习惯强加到嵌入式系统上。正确姿势是使用支持 embedded 模式的 HAL 后端，并且把内存分配、错误处理这些抽象接口实现到平台自身的机制上。
有一个我能给的最直接建议：先用ldd（Linux）或dumpbin /dependents（Windows）检查最终产物的动态依赖，把所有依赖项列个清单，再逐个决定是静态链入、手动拷贝还是换配置绕开。不要等到设备上跑出运行时错误才回头翻依赖，那会浪费很多时间去猜到底缺了哪个库。
4.3 dispatch 开销高于预期
模型很小，但实际推理速度没有想象中快，这也是一种常见的“调度和执行”问题。原因往往不是单个算子慢，而是 dispatch 太碎。每个 dispatch 代表一次设备命令提交，如果模型被拆成几十个极小 dispatch，每一次都有参数解析、命令缓冲区维护、可能还有同步等待的开销。叠加起来，一个小模型能被拖成一场“仪式”。
我的做法是先从 dump 结果里看 dispatch 数量，然后尝试把能融合的算子融合成更大的 dispatch。比如把elementwise连续操作合并，把可以直接折叠的常量表达式提前算完。IREE 的优化管线会自动做一部分，但自动融合策略有时不会覆盖所有情况，特别是模型中夹杂了自定义算子时，可能需要你手动改图结构，或者给关键路径上的算子写更紧凑的自定义内核。
还有一种情况是同步等待过长：你明明把两个 dispatch 设计成可以并行的流水线，但编译后的命令流里插了太多保守的 barrier，导致它们实际上串行执行。排查这类问题，要看 Stream 层的调度输出，检查 barrier 为什么会插入，是不是因为某些分析没有充分观察到数据依赖独立。这种问题往往需要结合模型结构本身去理解，没法靠统一参数一键修复。
4.4 从“技术拆解”到日常使用的几条经验
最后说几条我踩过坑之后总结出的习惯，如果你也准备在项目里引入 IREE，应该能用得上。
编译参数先固化一份 baseline。建议把常用的后端、优化等级、strip 开关写成一个脚本，每次验证新模型时都在同一组参数下对比，这样提交记录里不会出现五花八门的“效果”其实是参数漂移导致的。
活用iree-dump-module和反汇编工具，不要只盯着ls -l看大小。产物里到底有几个 dispatch、几条同步指令、多少字节的常量段，这些信息对排查性能问题远比“编译成功”更关键。
不要默认关注“实时修改模型后无需重编译”。IREE 的静态调度模型决定了模型一旦变化，产物必须重新编译，调度决策才会同步更新。如果你的业务有频繁换模型的场景，一定要考虑编译耗时和更新链路，否则一个很小的权重修改可能就要触发一次编译，部署节奏会不适应。
在多后端场景下，先用统一参数把 CPU 和 GPU 两个后端都跑通，再分别调体积优化。我见过有人一上来就把某个更激进的裁剪选项开给 GPU 后端，结果在驱动层就崩了。不同后端对于裁剪策略的容忍度不一样，稳妥的做法是一端一端分开验证。
个人体会
研究 IREE 这段时间，我最大的感悟是“编译期能做多少，决定运行期能省多少”这句话被验证到了极致。传统框架不是不好，而是它们为了通用性牺牲了太多静态优化的空间；IREE 恰恰选择了一条相反的路，把模型当成编译器的输入，把调度和执行变成编译结果的一部分。10 KB 不是神话，也不是每一个场景都必须追求的目标，但它像一个坐标系上的刻度，提醒我们体积优化的边界到底可以推到多远。如果你在做一个对产品体积敏感的推理项目，建议花一个周末亲手编一颗“最小内核”，把产物翻来覆去地 dump 几遍，你会对调度、执行、产物这三者的关系有一个非常直观的认知。
