前阵子我在整理端侧部署工具链的时候，列表越写越长：TFLite（现在叫 LiteRT） 、TFLite Micro、MNN、ncnn、TVM、microTVM……
第一反应是：同样是“把模型跑起来”，为啥要这么多框架？难道大家都在重复造轮子？
后来越看越觉得：这不是重复造轮子，而是大家在造不同地形的轮子——手机、微控制器、边缘盒子、带 NPU 的 SoC……每个地形对“轮子”的要求都不一样。
更刺激的是：传统模型（CV/ASR/小NLP）还好说，大模型（LLM/VLM/扩散） 出来后，端侧部署复杂度直接上了一个维度：KV cache、prefill/decoding、4bit 权重、采样循环……
于是问题变成：这些老框架还够用吗？谁能胜任大模型？
这篇文章就按我自己的“搞明白过程”，把端侧部署的几个关键方面串起来。
1）先把概念摆正：端侧部署不是“能跑”，而是“跑得像产品”
端侧的约束非常“物理”：
- 内存紧：不仅是参数大小，运行时中间张量、缓存也要命
- 带宽/拷贝贵：很多时候不是算子慢，是搬运慢
- 功耗和热：跑几秒降频，体验就塌了
- 设备碎片化：同一套 Android 机型，GPU/NPU 路径、驱动质量都可能不同
所以框架的差异，往往不在“能不能推理”，而在它对这些问题的默认答案是什么。
2）为什么会有这么多框架：因为端侧本来就分裂成几条世界线
我把它粗暴分成三种“哲学”：
A. 运行时派：我就是要一个稳定、通用、生态完整的 Runtime
代表：LiteRT（原 TFLite） 、ONNX Runtime Mobile、Core ML 等。
- LiteRT 是 Google 把 TensorFlow Lite 升级改名后的“端侧 ML & GenAI 运行时+工具链”，强调在边缘设备上跑得快、隐私好，并且已经把 GenAI 也纳入主叙事。(Google 开发者博客)
- ORT Mobile 则是典型的 “ONNX 为中心 + 多 Execution Provider（EP）” 的路线，移动端也有专门入口。(onnxruntime.ai)
- iOS 这边 Core ML 是系统级路线，定位就是“统一表示 + Apple Silicon 优化”。(Apple Developer)
它们的优点：生态稳、工具全、工程对接顺。
代价：你要接受它们的模型格式/算子覆盖/Delegate 或 EP 的边界。
B. 轻量引擎派：我只想要一个小、快、好交付的推理引擎
代表：ncnn、MNN（以及你可能会看到的 TNN / Paddle Lite 等）。
- ncnn 的自我定位很直接：面向移动平台优化、高性能、无第三方依赖、部署友好；并且支持 Vulkan 路线来做 GPU compute。(GitHub)
- MNN 的定位是“轻量高效的端侧深度学习框架”，覆盖转换/优化/推理等环节，而且你会发现它已经开始往 端侧 LLM 应用延伸（比如官方仓库里直接有 MNN Chat / MNN LLM Android 的示例与说明）。(GitHub)
这类框架通常在“我要交付一个 SDK（.a/.so） 、我要控制体积和依赖、我要 ARM CPU 上尽可能快”时很香。
C. 编译器派：我不只要跑，我还要“生成一个最适合这块硬件的可部署物”
代表：TVM、microTVM、以及更广义的“编译到端侧”的体系。
TVM 的官方定位是“机器学习编译框架：吃进预训练模型，编译生成可部署模块，跑在各种设备上”。(tvm.apache.org)
microTVM 则是把这条路继续往“更小、更裸”的设备推（面向微控制器/裸机/极轻 runtime 的世界），相关 Project API 也在 RFC 中描述过。(GitHub)
编译器派的魅力在于：
你可以把“框架能力”变成“你自己的 SDK 能力”
（你现在做的 AOT/MLF/模板化 SDK，本质就是这一脉的玩法）
3）同一个名字，不同世界：TFLite、TFLite Micro、TVM、microTVM 到底差在哪？
这里给一个“最不绕”的理解方式：
LiteRT（原 TFLite）：手机/边缘设备上的通用运行时
- 目标设备：Android/iOS/桌面/边缘（强调 ML + GenAI）
- 你关心：delegate/硬件加速、量化、模型转换、端侧性能
TFLite Micro（LiteRT for Microcontrollers）：MCU/超小设备上的推理库
- 目标设备：微控制器、DSP、超小内存设备（主打 int8 量化推理）(GitHub)
- 你关心：无 OS、静态内存规划、裁剪内核、可预测性
TVM：把模型编译成“能嵌入运行的产物”
- 目标设备：CPU/GPU/NPU/…（更偏“生成最适合的可部署模块”）
- 你关心：AOT、算子调优、代码生成、部署形态可控
microTVM：TVM 往微控制器/裸机走的分支
- 目标设备：更小、更裸、更极致受限的场景
- 你关心：Project API、端侧 runtime、设备端联调/调优工作流
一句话总结：
LiteRT/ncnn/MNN 更像“把模型塞进设备”；
TVM/microTVM 更像“把设备的特性塞进模型”。
4）市面上还有哪些端侧部署框架？（按“你在什么平台上”来记最省脑子）
手机/移动端通用
- LiteRT（原 TFLite） ：Google 端侧 ML & GenAI 主线
- ONNX Runtime Mobile：ONNX 中心，多 EP 路线
- ncnn / MNN：国内常见，偏轻量与工程交付
- Core ML（iOS） ：系统级主线
Android 的“系统级加速”提醒：NNAPI 已经 deprecated
很多人以前习惯把 NNAPI 当“统一 NPU 接口”，但 Android 官方已经明确：NNAPI 在 Android 15 被 deprecated，并给出了迁移指南；同时强调 HAL 仍继续支持。
这会让未来端侧加速更依赖“框架内置 delegate / 厂商栈”路线，而不是你直接押宝 NNAPI 的长期演进。
边缘盒子/PC/特定硬件生态
- OpenVINO + OpenVINO GenAI：Intel/边缘盒子常见，GenAI 提供 pipeline 级 API（不用自己写推理循环、tokenization 等）。
- TensorRT / TensorRT-LLM：NVIDIA 生态（Jetson/边缘 GPU/服务器）
MCU/TinyML
- TFLite Micro：MCU 端“成熟推理库”路线
- 以及围绕 MCU 的各种库/内核生态（比如 CMSIS-NN 等，这里不展开）
5）然后大模型来了：传统框架还能打吗？谁能胜任“端侧 LLM”？
我后来才意识到，大模型端侧部署难点不是“算子多”，而是“推理形态变了”。
传统模型：一次前向，输出完事。
LLM：prefill + decoding 循环，还要管理 KV cache、采样、停止条件、流式输出……
所以现在能“胜任大模型”的，往往不是单纯 runtime，而是带生成式推理循环的栈。
能打大模型的几条路线（按风格分）
1）通用 Runtime + GenAI 扩展（更像“产品级方案”）
- LiteRT GenAI：官方明确把“在移动/桌面/web 上高性能部署 GenAI，并利用 CPU/GPU/NPU 加速”写进了文档。
- ONNX Runtime GenAI：把 generative loop（tokenization、logits 处理、search/sampling、KV cache 管理）作为库的一部分提供出来。
- OpenVINO GenAI：同样强调“pipeline 级 API”，帮你省掉推理循环与细碎工程。
2）轻量/本地优先（更像“把 LLM 放进任何设备”）
- llama.cpp：目标就是“最小 setup、覆盖广泛硬件、做到很强的本地推理”。
- MLC-LLM / WebLLM：ML 编译 + 部署引擎路线，WebLLM 甚至把 LLM 带到浏览器里，用 WebGPU 加速，主打“无服务器、本地隐私”。
3）训练框架原生下沉（更像“PyTorch 自己的端侧答案”）
- ExecuTorch：PyTorch 官方定位就是“从手机到嵌入式系统甚至微控制器”的端侧推理方案。
4）传统端侧引擎也在“补课”
比如 MNN：你能在官方仓库直接看到 MNN Chat / MNN LLM Android 的说明与实现路径（已经不只是“跑个 CNN”了）。
6）把话说透：这篇文章最后我得到的“选型心法”
如果你也和我一样，看到一堆框架就头大，我建议用这三个问题把“世界线”切开：
Q1：目标设备是谁？
- 手机：LiteRT / ORT Mobile / ncnn / MNN / Core ML
- MCU：TFLite Micro 或编译器/内核生态
- 边缘盒子/PC：OpenVINO / TensorRT 等
Q2：模型是哪种？
-
传统模型：你主要在算子覆盖、量化、delegate/EP、工程裁剪上做文章
-
大模型：你必须优先看“是否提供 生成式推理循环 + KV cache 管理”
- LiteRT GenAI / ORT GenAI / OpenVINO GenAI 属于“直接能做产品”
- TensorRT-LLM 属于“你要极致性能就上它”
- llama.cpp / MLC-LLM / WebLLM 属于“本地优先、平台覆盖强”
Q3：你交付的形态是什么？
- App 内嵌：生态、升级、兼容性优先
- SDK 交付：体积、依赖、ABI、可裁剪优先（ncnn/MNN/TVM-AOT 常见）
结语：为什么框架越来越多？因为端侧“地形”越来越复杂
回到开头那个疑问：
为什么会有这么多框架？
我的答案是：端侧不是一个平台，是一片大陆。
有人在修高速公路（通用 runtime），有人在造越野车（轻量引擎），有人在搞定制装甲（编译器栈）；而大模型的出现，相当于突然引入了一种“必须带补给车队”的新作战方式（生成循环 + cache + 量化 + 内存管理），于是又诞生了一批 GenAI 专用栈。
补充一下：大模型端侧部署还可以使用MNN这些框架进行转换后在各个芯片厂商自己SDK平台进行部署（QNN、RKNN等）
