把一个训练好的模型塞进手机并跑出理想帧率，远比想象中困难。同样一个ResNet50，直接用框架原生CPU推理可能只有10 FPS，经过编译器优化后往往能提升数倍。这背后的差距，主要来自算子融合、内存复用、向量化计算和数据布局重排等一系列编译期优化。目前在移动端部署领域讨论度最高的三款编译器是TVM、Halide和Glow，它们虽然都服务于让模型跑得更快这个目标，技术路线却差异极大，理解这些差异是做对技术选型的前提。
一、TVM：自动调优路线的代表
TVM由华盛顿大学提出，后来演进为Apache开源项目，它的核心思想是让编译器自动搜索最优的底层实现，而不是依赖手写算子库。TVM内部分为两层中间表示：TE（Tensor Expression）负责描述计算逻辑，TIR（Tensor IR）则承载底层调度信息。开发者只需要用类伪代码的方式声明输出张量的每个元素如何由输入计算而来，调度器就会自动尝试不同的循环切分、向量化、并行化方案，并通过实测耗时挑出最优解。
这套自动调优机制在TVM里叫AutoTVM和后来的Ansor（AutoScheduler）。Ansor不依赖人工编写的调度模板，而是在整个搜索空间内自动探索，对常见卷积、矩阵乘等算子在ARM CPU上往往能逼近甚至超过手写NEON汇编的水平。代价是调优时间较长，一个模型完整调优可能需要数小时，所以TVM提供了调优缓存机制，把搜索结果落盘复用。
import tvm
from tvm import relay
# 加载ONNX模型并编译到ARM CPU目标
mod, params = relay.frontend.from_onnx(onnx_model, {"input": (1, 3, 224, 224)})
target = tvm.target.arm_cpu() # 或 "llvm -mtriple=arm64-linux-gnu"
with tvm.transform.PassContext(opt_level=3):
lib = relay.build(mod, target, params=params)
# 导出部署产物，可在安卓端通过TVM Runtime加载
lib.export_library("model_android.so")
对移动端团队而言，TVM最大的吸引力是工程通用性：一份前端代码可以覆盖ONNX、TensorFlow、PyTorch等主流格式，后端可以切换到ARM CPU、Adreno GPU甚至自定义NPU。缺点是Runtime体积和编译链路的复杂度都不低，如果只部署一两个固定模型，引入TVM可能显得过重。
二、Halide：算法与调度分离的经典范式
Halide诞生于MIT，最初为图像处理pipeline设计，后来被广泛用于移动端算子开发，Google的HDR+算法、许多手机厂商的相机降噪链路都基于它。Halide最核心的贡献是把算什么和怎么算彻底分离：函数体只描述计算规则，schedule单独指定循环顺序、分块、向量化、并行与数据驻留策略，同一份算法描述配不同schedule可以产生性能相差数十倍的代码。
这种分离在移动端价值巨大。同一套卷积算法，在骁龙大核和小核上最优的分块参数完全不同，在Halide里只需改schedule，算法代码一行不动。相比之下，手写NEON intrinsic时每种目标都要重写一遍。Halide的调度原语也相当丰富，split、reorder、vectorize、tile、compute_at等组合起来，可以精细控制缓存行为和中间数据的生存位置。
Func blur_x, blur_y;
Var x, y, xi, yi;
// 算法描述：水平方向加权和
blur_x(x, y) = (input(x-1, y) + input(x, y) + input(x+1, y)) / 3;
blur_y(x, y) = (blur_x(x, y-1) + blur_x(x, y) + blur_x(x, y+1)) / 3;
// 调度：分块 + 向量化 + 行级融合，减少blur_x中间数据落内存
blur_y.tile(x, y, xi, yi, 64, 4)
.vectorize(xi, 8)
.fuse(x, y, x)
.parallel(x);
blur_x.compute_at(blur_y, x).vectorize(x, 8);
blur_y.compile_to_static_library("blur_arm", {input}, "blur");
Halide的定位更接近高性能算子开发语言而非完整编译器，它没有图级别的模型优化能力，不负责算子自动融合和量化。所以实践中常见组合是：上层用其他框架做图优化，底层算子用Halide实现。它生成的是干净的C++代码或对象文件，没有运行时依赖，这点对包体积敏感的App非常友好。
三、Glow：面向图级别的静态编译
Glow是Meta开源的编译器，技术路线与前两者不同：它聚焦在计算图级别的优化，底层直接复用LLVM生成机器码。模型加载后先经过Graph优化阶段完成算子融合、常量折叠、死代码消除和内存规划，然后Lower到LLVM IR，再针对ARM等目标生成原生代码。整个流程是纯静态编译，没有JIT环节，部署产物是独立可执行文件。
Glow的一个亮点是内存提前规划。它通过静态分析每个张量的生命周期，在编译期就把所有中间缓冲区分配好，运行时零动态内存分配。这对内存紧张的嵌入式设备和低端安卓机很关键，不仅避免了分配器开销，也让峰值内存可预测。量化方面Glow做了较深的类型系统支持，int8量化推理开箱即用，并有完善的量化profile工具链。
不过Glow的社区活跃度明显低于TVM，对新模型结构的支持滞后，自定义算子接入也需要写不少C++样板代码。它更适合模型结构相对固定、对启动延迟和内存确定性要求高的场景，比如端侧人脸检测、唤醒词识别这类长期驻留的轻量任务。
四、关键维度横向对比与选型建议
把三者的核心差异整理成表格会更直观：
| 维度 | TVM | Halide | Glow |
|---|---|---|---|
| 优化层次 | 图级加算子级自动调优 | 算子级，调度手动或自动混合 | 图级优化加LLVM后端 |
| 算子融合 | 自动，图优化Pass完成 | 不涉及，需上层框架 | 自动，编译期静态确定 |
| 量化支持 | int8与int4，工具链完整 | 需自行实现 | int8类型系统内建 |
| 运行时依赖 | 需TVM Runtime，体积较大 | 零依赖，生成C++对象文件 | 静态编译，无JIT |
| 调优成本 | 调优耗时长，结果可缓存 | 依赖经验，可控性强 | 几乎无需调优 |
| 社区活跃度 | 高，Apache顶级项目 | 中等，图像领域为主 | 偏低，更新放缓 |
从实际项目经验出发，选型可以简化为三条路径。模型来源多样、需要频繁更换目标硬件的团队优先考虑TVM，它的自动调优和多后端能力能显著降低适配成本，但要接受较重的工具链和调优时间。自研高性能算子、相机或图像处理链路的团队适合Halide，算法与调度分离让性能调优成为可复制的工程实践，且产物无运行时包袱。模型固定、追求确定性内存和快速启动的端侧任务可以评估Glow，静态编译带来的可预测性是它独有的优势。
还有一点值得注意：三者并不互斥。不少团队采用混合方案，图优化和量化交给TVM完成，个别性能瓶颈算子（如深度可分离卷积、自定义注意力变体）用Halide手写调度后注册回上层编译器。这种框架管图、专家管核的分工，往往能拿到接近硬件峰值的性能，同时保持整体流程的可维护性。移动端AI部署的本质是在延迟、包体积、内存和人力成本之间做权衡，编译器只是实现这个权衡的工具，理解每种工具的边界，比迷信任何单一方案都重要。