为什么是三个框架,为什么是现在

想在手机、树莓派、智能烤箱、或者没有独显的笔记本上跑神经网络,2026 年你有三个认真的选择:ExecuTorch、Apache TVM、LiteRT(也就是改名的 TensorFlow Lite)。三家的根本理念不同。选错代价是几周的移植工作;选对,200ms/token 的 LLM 能压到 50ms。

这是一篇概念层的 deep dive,不是 benchmark。看完你会知道每个框架擅长什么、薄弱在哪、给定模型和硬件先抓哪个。

问题长什么样

三件事都得做:把 PyTorch / TensorFlow / JAX / ONNX 训出来的模型,在受限制设备上做优化,然后高效地跑在 CPU / GPU / NPU 上。三个框架在这三件事的解法上分叉:

  • 做多少编译。有些几乎原图跑,靠手写的算子库(XNNPACK、Core ML);有些把图一路编译到目标 CPU 的本地代码(TVM);LiteRT 在中间。
  • 硬件厂商怎么插进来。现代手机都有 NPU。三家对 NPU 态度不同——有的是整图 delegate 黑盒;有的是把子图编译进去;有的是 runtime 库调用。
  • 新模型架构怎么对待。2026 年最热的是 LLM 和 diffusion。有的框架把它们当”普通图”处理;有的有一类专属流水线(ExecuTorch 的 LLM examples、TVM 的 MLC LLM 系列、LiteRT-LM)。

ExecuTorch:PyTorch 原生路径

ExecuTorch 是 PyTorch Foundation 对「我在 PyTorch 训的模型,怎么在手机上跑」的回答。1.3.1 版 2026-05-29 发布;Meta 主导,和 torch.compile / torch.export 同属 PyTorch Edge。

架构

导出走 torch.export——和你用 torch.compile 时是同一套导出管线——产生 ExportedProgram,ExecuTorch 再降级成 flatbuffer .pte 文件。Runtime 是个小型 C++ 库,可选 backend delegate 做硬件加速。整个设计就是为嵌入:依赖最少,推理时不需要 Python,从 AR 眼镜到 MCU 都能跑。

后端

预编译 executorch pip 包绑了四个后端:

  • XNNPACK — x86 和 ARM 上的 CPU 推理,走 XNNPACK 算子库。这是默认。在 ARM NEON 上快,x86 上还行。
  • Core ML — iOS / macOS 上的 Apple Neural Engine 和 GPU。macOS / iOS 构建自带。
  • MPS — macOS / iOS 的 Metal Performance Shaders,补 Core ML 覆盖不到的 GPU 路径。
  • QNN — Linux x86_64 主机上的 Qualcomm AI Engine,面向 Snapdragon 设备。
  • OpenVINO — Linux 上的 Intel CPU / GPU。

要更偏的(MediaTek NeuroPilot、Samsung Exynos、自研 NPU),自己写后端——delegate API 稳定,社区已交付半打。ARM 后端(Cortex-M、Ethos-U 的 MCU)单独一个仓库。

强项

  • 模型是 PyTorch 又没做过重的图改写,导出基本是空操作。不用换一套框架重写模型。
  • LLM 和其他动态 shape 大图有一类专属支持,看 examples/models/llama runner 和长上下文的 AttentionSink 扩展。
  • 同一份 .pte 在所有后端跑,靠算子分区。所以你可以发布一个 artifact,runtime 按 op 自动派发 CPU / GPU / NPU。

短板

  • 非 XNNPACK 后端的算子覆盖不完整。一切正常直到碰到一个 NPU delegate 没有的算子,然后退回到 per-op CPU 执行,速度优势丢光。1.3 release notes 持续推进但仍是瓶颈。
  • 没有通用的图优化。TVM 有多年的自动调优基础设施;ExecuTorch 基本委托给 backend 厂商自带的优化。

Apache TVM:编译优先路径

Apache TVM(2019 年成为顶级项目,~13.6k stars,0.25.0 于 2026-06-24 发布)是三个里最老也最有野心的。它是一整套深度学习编译器栈,不只是 runtime。你写 Python;TVM 把模型吸进来,经过 Relax(图 IR)和 TensorIR(张量程序 IR),对算子实现做基于搜索的自动调优,最后吐出一个 C++ 源库或者 JSON artifact,运行时用 TVM runtime 加载。

架构

流水线大概这样:

  1. Frontend 吃模型。PyTorch(通过 Relax,支持 ExportedProgram)、ONNX、TensorFlow,还有几个其他。
  2. Relax 是图级 IR。做大改造:算子融合、布局规划、量化标注、为 BYOC(Bring Your Own Codegen)目标做分区。
  3. TensorIR 是张量级 IR。一个算子的计算 schedule 用它表示,自动调优器才能修改。
  4. MetaSchedule(或者老的 AutoScheduler)在循环分块大小、向量化宽度、展开因子、内存布局上做搜索。它在目标机器上跑,实测 kernel 时间,保留最好的 schedule。
  5. Codegen 输出 LLVM(x86 / ARM CPU)、CUDA / HIP(NVIDIA / AMD GPU)、Metal / Vulkan / OpenCL / SPIR-V(手机和 Web GPU),或者 BYOC 目标比如 NNAPI / Android。
  6. Runtime 是个小型 C++ 库——TVM-Runtime,加载编译后的 artifact。推理时不需要 Python。

杀器是自动调优器:你告诉 TVM「让这个 conv 在 Pixel 8 的 Cortex-A510 上跑快」,它花几小时搜 schedule 空间,常常找到手写品质的 kernel,吐出来。当你的目标很偏时——自研加速器、没人写 delegate 的 NPU、没人优化过的模型架构——这就是为什么 TVM 是首选。

强项

  • 找不到 delegate 的硬件。TVM 后端有 Hexagon DSP、WebGPU、WASM、RISC-V Vector,还有一长串学术加速器。目标越偏,三个里只有它能编译得出来。
  • 有时间调优时,顶到极限性能。几小时 MetaSchedule 搜索下来,经常比手写 kernel 快 10–30%。代价是搜索成本不低。
  • 不绑定厂商。编译目标是 LLVM 加你自己的目标硬件,不用谈 SDK 授权。

短板

  • 构建很重。编译 TVM 本身就要几小时。依赖树(LLVM、cuDNN、厂商 SDK)对只发一个目标来说是真负担。
  • 动态 shape 和控制流还是别扭。Relax 有改善但自动调优器基本假设 shape 大部分静态。LLM 通过 MLC LLM(TVM 上面的垂直编译器)能跑,但那是单独仓库,得同步。
  • 写的代码比另外两家多。ExecuTorch 导出就一个 Python 调用;TVM 是个脚本,导入对的前端、配置目标、跑调优器、导出 artifact、打包 C++ runtime。模板能帮忙但真是个项目。

LiteRT:runtime + delegates 路径

LiteRT 就是改名的 TensorFlow Lite——Google 在 2024 年重组 AI Edge 部门时正式改名。核心思路没变:小型 interpreter 跑 .tflite flatbuffer 模型,可插拔 delegate 把图的某些部分丢给 GPU 或 NPU。2026 年新的是 CompiledModel API 和统一的 NPU 厂商支持。

架构

模型(原本是 TensorFlow SavedModel,现在也能是 PyTorch 通过 ai-edge-torch、JAX 通过 jax2tf)过 LiteRT converter 转成 .tflite,interpreter 跑。Interpreter 一算子一算子走图。碰到属于 delegate 的区段(比如所有 conv),把整个子图丢给 delegate;其他的 CPU 跑内置 kernel 库。

2026 年的新东西是 CompiledModel:不再一算子一算子 delegate 跑,而是让 runtime 把整个图编译到目标加速器,返回一个可调用对象。Runtime 自动挑最好的后端(CPU / GPU / NPU)。这是认真做性能该走的路——老的 Interpreter API 还能用,但新投入都在 CompiledModel。

后端和 NPU 支持

LiteRT 在 2026 的 NPU 故事是三个里最完整的。Google 提供第一方集成:

  • Google Tensor(Pixel 手机)——通过 Google Tensor SDK 的 AOT 编译。
  • Qualcomm AI Engine Direct——AOT 和 on-device(JIT)编译都行。
  • MediaTek NeuroPilot——AOT 和 JIT 都能。
  • Intel OpenVINO——x86 推理。
  • Samsung Exynos AI LiteCore。

GPU 是标准 GPU delegate(Android 上的 OpenGL / OpenCL,iOS 上的 Metal)。CPU 有 reference kernel 加 XNNPACK——有意思的是这意味着 LiteRT 和 ExecuTorch 共享同一个 CPU 后端。

NPU 集成用 Dispatch API 加 Compiler Plugin 模型:每个 NPU 厂商提供插件,知道怎么把 LiteRT 图降到他们编译器的 IR,runtime 调进去。这比 delegate 模型更干净的解耦——厂商不用拿 LiteRT 的词表重写算子,把子图编译进去就行。

强项

  • 2026 最完整的 NPU 故事。要发到带 Qualcomm / MediaTek NPU 的 Android 手机,而且想一个框架通吃,选 LiteRT 阻力最小。NPU 厂商自己有动机——这是他们的生意。
  • 最小的 runtime。为 MCU 裁剪过的 LiteRT 构建只有几百 KB 量级。ExecuTorch 大一些;TVM 更大。
  • 最成熟的工具链。TFLite 生态比另外两个多了五年的稳定期。converter 久经调试,profiler 能用,Model Explorer GUI 确实有用。

短板

  • PyTorch 优先的工作流是二等公民。能转 PyTorch 模型,但路径要经过 ONNX 或者 ai-edge-torch(Google 自己的转换器),你要信两步翻译。ExecuTorch 对 PyTorch 用户更顺滑。
  • Interpreter API 显老了。一算子一算子 + delegate 模型能用,但新功能都在 CompiledModel,而 CompiledModel 只干净处理 Float32——量化模型还是得用 Interpreter。
  • Google 主导治理。模型架构 Google 不优先,你可能等厂商补丁等到天荒地老。社区比 TVM 小。

并排看:后端覆盖、量化、模型类型

下面这张表汇总 2026 年现状。「Yes」是一类支持,「Partial」是带条件支持,「No」是要自己写后端或者换框架。

维度 ExecuTorch 1.3.1 TVM 0.25.0 LiteRT
CPU(x86、ARM) Yes(XNNPACK) Yes(LLVM) Yes(XNNPACK + ref)
NVIDIA / AMD GPU Partial(XNNPACK delegate 的 CUDA 路径) Yes(CUDA / HIP / Vulkan / OpenCL) Partial(GPU delegate,桌面端实验性)
手机 GPU Yes(MPS、Core ML、OpenCL 路径) Yes(Metal、Vulkan、OpenCL、SPIR-V) Yes(GPU delegate,成熟)
Apple Neural Engine Yes(Core ML delegate) Partial(Core ML BYOC) Yes(Core ML delegate)
Qualcomm NPU Yes(QNN) Partial(通过 BYOC 的 Qualcomm AI Engine,比别家弱) Yes(QNN via Compiler Plugin,AOT + JIT)
MediaTek NPU Partial(社区后端) Partial Yes(NeuroPilot,AOT + JIT)
Google Tensor NPU No No Yes(Tensor SDK,AOT)
Intel NPU / OpenVINO Yes(OpenVINO backend) Partial Yes(OpenVINO Compiler Plugin)
Samsung Exynos NPU No Partial Yes(LiteCore,AOT)
ARM Cortex-M / Ethos Yes(ARM 后端,单独仓库) Partial(Cortex-M,Ethos 通过 TVM-Micro) Partial(LiteRT Micro)
int8 / int4 量化 Yes(PT2E quant,per-backend) Yes(灵活) Yes(成熟,全流水线 quantization-aware training 工具链)
FP16 / BF16 Yes Yes Yes(CompiledModel),Partial(Interpreter)
动态 shape / LLM Yes(AttentionSink,LLM runner) Yes(MLC LLM 是生产路径) Yes(LiteRT-LM,较新)
ONNX 导入 通过 ONNX → ExportedProgram Yes(原生前端) 通过外部 converter
PyTorch 导出 原生(torch.export) 通过 ExportedProgram 前端 通过 ai-edge-torch
JAX 导入 通过导出到 ONNX Yes 通过 jax2tf
TensorFlow 导入 通过导出到 ONNX Yes 原生
License BSD-style(PyTorch 项目) Apache 2.0 Apache 2.0

几行值得点出来。Google Tensor NPU 只有 LiteRT 支持——故意的,SDK 从 Google 出。ARM MCU 三家都支持,但工具链质量 LiteRT Micro 最好(多年实战打磨),TVM 最弱(Hexagon 和 Ethos-U 能用但配置更多)。动态 shape LLM 三家现在都真够格——ExecuTorch 的 AttentionSink、MLC LLM 的预编译 artifact、LiteRT-LM 的近期发力,UX 趋同了。

性能:真正重要的是什么

2026 没有干净的跨框架 benchmark——模型差异太大、后端差异太大、每个框架都挑自己擅长的 workload。几个可靠规律:

  • Qualcomm NPU 上,LiteRT 在同一模型上比 ExecuTorch 一致快 10–20%,因为 Qualcomm 插件和 LiteRT 编译器集成的时间更长,Google 和 Qualcomm 在这个面上关系更近。Pixel 的 Tensor NPU 上,只有 LiteRT 能跑。
  • CPU 唯一目标 + 自定义 shape,TVM 自动调优器赢的幅度随模型奇怪程度上升。标准 ResNet-50 在 ARM Cortex-A 上三家都在 5% 以内;带融合 attention 怪招的自定义 transformer,TVM 上快 2 倍,因为调优器找到了没人手写的 schedule。
  • Mac 上 LLM token 吞吐,ExecuTorch 的 MPS 后端和 LiteRT GPU delegate 同档。两者底层都是 Metal Performance Shaders,所以除 per-op 开销外大致同速。
  • 二进制体积,LiteRT 最小,ExecuTorch 中间,TVM 最大(除非你狠裁 runtime)。

更诚实的解读:性能主要取决于模型的算子被映射到目标硬件有多好,而这个映射是框架特定的。两个工程师拿着同一模型在同一部手机上,框架-backend 配对选错就能差出 3×。先在你的真实模型 + 真实硬件上跑一遍,再下结论。

什么时候用哪个

你在把 PyTorch 模型发到手机或嵌入式设备

先抓 ExecuTorch。导出路径最顺,LLM 工具成熟,大多数视觉 / 语音模型 per-backend delegate 覆盖足够。碰到算子覆盖的坑、又没 workaround 时再换。

你在发到有 LiteRT 一类支持的 NPU(Qualcomm、MediaTek、Pixel、Exynos、Intel)

用 LiteRT。厂商插件生态最完整,真能拿到 NPU 峰值性能。PyTorch 转换的摩擦是真的但一次性成本。

你在面向奇怪的硬件——自研加速器、WebGPU 浏览器、RISC-V vector、Hexagon DSP、新手机 SoC

TVM。三个里只有它有编译器基础设施能针对没人写过 delegate 的硬件。预留自动调优时间。

你在把小型模型发到 MCU

LiteRT Micro 或 ExecuTorch 的 ARM 后端。两者都行。LiteRT Micro 多年生产打磨;ExecuTorch ARM 后端和 PyTorch Edge 主生态整合更干净。

你是研究员,在比 kernel schedule 或研究编译器基础设施

TVM。TensorIR 和 MetaSchedule 是三个里学术最有趣的、文档最好的。ExecuTorch 的 runtime 内部不容易看;LiteRT 的 NPU 插件不开源。

你想要一个框架从手机到笔记本到服务器都覆盖

没有。三个桌面 GPU 路径都有,但没一个适合认真做服务端推理——那是 PyTorch / JAX / vLLM / SGLang 的活。端侧框架是为数据得留在设备上、或者延迟预算不允许往返的场景存在的。

2026 还没解决的

几家都没搞定的事:

  • NPU 碎片化还是房间里的大象。每个厂商的编译器想要略微不同的图、opset、量化格式。LiteRT Compiler Plugin 模型是最有希望的统一尝试,但真跨厂商可移植还远。ExecuTorch 的同款问题是 QNN 只服务 Qualcomm。
  • 动态 shape 量化三家都粗糙。静态 shape per-channel int8 能用;transformer 里 per-token int4 是研究级。多数 LLM 生产服务还在用 FP16 / BF16 权重 + int8 activation,光这样都得小心。
  • 跨模型 → 导出 → runtime 边界的 debug 糟透了。模型在 PyTorch 跑对、设备上跑出垃圾,失败可能来自量化校准、backend 缺算子、layout 变换、或导出脚本的 bug。三个都没有好工具。
  • 「随便塞 PyTorch 模型」的承诺是部分假话。三个都有每后端的支持算子列表,稍偏的模型都会撞墙。诚实版 pitch 是「随便塞任何标准模型」。

结论

2026 年,三个框架不再是彼此替代品——是不同场景的工具:

  • ExecuTorch 是把 PyTorch 训的模型发到手机和嵌入式设备的默认。
  • LiteRT 是发到 NPU 的默认,尤其 Android,也用于 MCU 部署。
  • TVM 是面向奇怪硬件目标、把奇怪模型架构挤出最后 10–30% 性能的默认。

三家团队都知道彼此——Meta 给 ONNX 贡献、Google 维护 LiteRT 同时内部用 TVM 做某些产品、TVM 社区和 Qualcomm AMD 协作。框架在共享基础设施(XNNPACK for CPU,通用量化格式)上收敛得比发散得快。再过两年你也许一个框架搞定一切;今天,先按硬件挑,再按模型挑。

最后修改： 2026年7月22日

作者

评论

发表评论

您的邮箱地址不会被公开。