LiteRT, Core AI, ONNX Runtime，三者都是为了将参数量在数亿至数百亿级别的大模型部署到端侧设备的运行环境（Runtime）。
机器学习模型的部署曾经高度依赖于云端庞大的计算资源和数据中心。但是随着生成式人工智能（Generative AI）和大型语言模型（LLM）能力的不断下探，以及对用户数据隐私、低延迟交互、离线可用性和云端高昂每Token成本的综合考虑，将参数量在数亿至数百亿级别的大模型部署到端侧设备（如智能手机、个人电脑、物联网设备及浏览器）成为不可逆转的行业趋势。
1. 大模型和运行环境（Runtime）的区别
- 大模型本身就是经过训练，得到的一个静态的、机器复杂的数学处理流程（计算图）大模型基础概念以及海量训练好的数据（参数权重）。它定义了“输入什么”和“经历哪些计算”就能得到“输出”
- 运行环境（Runtime） 就是总调度，因为模型的计算量太大了，如果只让CPU干，速度会极其缓慢。运行环境的作用就是把整个庞大的计算图切分成多个较小的子图，然后评估设备上现有的各种硬件能力，将不同的子图分配给最擅长处理它们的执行提供者（比如通用的CPU、擅长图形和并发计算的GPU，或者专门用于AI矩阵加速的NPU）去执行。除了分配计算和中间数据，针对现在的大语言模型（LLM），运行环境还额外承担了一项重要工作：管理生成循环和缓存。因为大语言模型是逐个字往外蹦的，运行环境必须在内存里保存好之前已经计算过的数据（即KV缓存），这样生成新词是，各个CPU、GPU、NPU就不需要把整句话从头到尾再算一遍，从而保证了回答的速度和效率。
2. LiteRT, Core AI 与 ONNX Runtime对比
| 评估维度 | LiteRT(Google) | CoreAI(Apple) | ONNX Runtime（微软及开源社区） |
|---|---|---|---|
| 生态与战略定位 | 移动端优先、跨平台（Android/Web/iOS）、注重边缘物联网（IoT） | Apple生态闭环（iOS27+/maxOS 27+） | 全平台通用，PC桌面端和云端优势显著，跨平台兼容性第一 |
| 大模型专有框架抽象 | LiteRT-LM编排层（处理KV Cache、会话克隆） | 统一原生Swift API、原生动态图与状态执行支持 | onnxruntime-genai包装库（内置Generative AI Loop与Logits处理） |
| 主要模型格式 | .tflite/.litertlm（基于FlatBuffers） | .aimodel | .onnx |
| 底层硬件抽象机制 | 依赖Delegate委托层（如ML Drift，NNAPI，QNN） | 原生系统级集成，统一内存调度（ANE，GPU，CPU） | 依赖Execution Providers（EPs）机制与子图切分 |
| 模型转换入口 | ai_edge_torch（基于TorchDynamo的高保真转换） | coreai-torch（基于最新的torch.export.ExprotedProgram） | 庞大的第三方转换器体系（如Hugging Face Optimum库中的optimum.onnxruntime） |
| 最适合 | 端侧统一部署，小到中模型，本地多模态 | Apple生态内中到大模型，本地隐私有限，原生App集成 | 跨硬件、跨云边端、吞吐优先与企业级互操作 |
3. 移动端运行的二进制体积与加速器支持对比
| 运行环境引擎 | 附加二进制足迹（增加的App体积） | Android硬件加速 | iOS硬件加速支持 |
|---|---|---|---|
| LiteRT | 约3.2MB | NNAPI/GPU Delegate | Metal Delegate |
| ONNX Runtime | 约8.5MB | NNAPI/QNN Developer | CoreML/MPS |
| Core AI | 0MB（系统原生内置） | N/A | 原生ANE/GPU/CPU的统一调度 |
| LiteRT凭借极具针对性的精简架构，在移动端取得极佳的轻量化表现，仅需引入3.2MB的依赖库。 | |||
| 相较之下，ONNX Runtime 追求庞大算子生态的 100% 求解率与全平台兼容，不可避免地导致了较重的二进制体积（8.5 MB，约为 LiteRT 的 2.5 倍），并在初始化的构建标志与配置上显得更为复杂。 | |||
| 而在功耗管理与发热控制层面，闭源的 Core AI 拥有最高统治力。因为它是系统底层的调度者，能将密集运算直接映射到功耗极低的 ANE（神经引擎）硅片电路上；而在 Android 或 iOS 平台上使用 LiteRT 或 ONNX 调度通用 GPU 时，连续高负载推理极易在数分钟内触发严重的温控降频（Thermal Throttling），大幅拉低每瓦性能（Performance-per-watt）。 |
4. 对比总结
LiteRT代表“跨端侧产品化”，Core AI代表“Apple原生极致化”，ONNX Runtime代表“跨生态工业底座化”。 小模型到中模型（移动端、浏览器、物联网、本地多模态）：LiteRT通常最合适。中到大模型（Apple生态内，重交互、重本地隐私、重Swift集成）：CoreAI非常强，尤其适合iPhone/Mac/Vision Pro一套代码多复用的产品。中到超大模型，或者同时要求云/边/端混合、跨framework、跨硬件后端、可接Triton/K8s：ONNX Runtime更稳妥，尤其在NVIDIA、Intel、Huawei Asend等异构硬件环境中更有显示可操作性。
5. 对于目前的探探项目
在双端需要保持较高一致性的前提下，LiteRT 是值得重点评估的方案，但目前还不能直接认定它一定优于 ONNX Runtime。
LiteRT 的主要优势是 Android 生态结合较深，支持 CPU、GPU、NNAPI 以及部分芯片厂商提供的 NPU Delegate；在 iOS 上也可以通过 Metal Delegate 使用 GPU，或通过 Core ML Delegate尝试利用 Apple Neural Engine。对于能够被 Delegate 完整接管的移动端模型，LiteRT有可能在延迟、功耗和包体方面取得较好结果。
但这些优势都取决于具体模型、算子覆盖率、量化方式和目标设备。不能使用脱离模型与设备条件的固定数据，直接声称 LiteRT 的包体一定是某个数值，或者 ONNX Runtime 的延迟和功耗一定明显更差。两种 Runtime 都支持按模型裁剪包体，也都可能通过系统或硬件加速后端执行模型。
同时，现有中台产物和大量第三方开源模型以 ONNX 为主。统一使用 LiteRT 意味着需要维护 ONNX 到 TFLite 的转换链路，并持续验证算子兼容性、数值一致性和硬件 Delegate 覆盖情况。因此，统一 Runtime 带来的端上维护收益，需要与模型转换和回归成本一起评估。
更稳妥的决策方式是选择若干代表性模型，在相同设备和相同精度条件下比较：
- ONNX Runtime + XNNPACK / NNAPI
- LiteRT + XNNPACK / GPU / NPU Delegate
测试真实的包体增量、模型加载时间、预热后延迟、内存、功耗、Delegate 覆盖率和输出误差。如果 LiteRT 在 Android 端表现出足够明显且稳定的收益，同时 ONNX 转换链路能够自动化，再考虑将其作为主要运行环境；否则，双端直接使用 ONNX Runtime 仍然是工程成本更低、模型兼容性更直接的方案。
6. 具体案例
LiteRT能找到明确写出“同一套Runtime部署Android+iOS”的商业产品案例；ONNX Runtime能证明双端技术可行，也有大量商业产品使用，但公开点名“双端移动App都统一使用ORT”的案例很少。
LiteRT
1. 爱奇艺SmileSR
2019年的文章，那个时候LiteRT还叫TensorFlow Lite SmileAR 是爱奇艺的移动端 AR 方案，包含人脸关键点、表情和 AR 特效等视觉模型。爱奇艺公开说明，它使用 TensorFlow Lite（现在称 LiteRT）的 C++ 接口实现跨平台部署：
同一套 TFLite 模型与 C++ 推理层
├── Android：Java 封装
├── iOS：Objective-C 封装
└── Windows：C++ 封装
这套 SmileAR SDK 被交付给爱奇艺内部多个业务单元，用于移动产品和直播功能。该案例证明了“大型 C 端 App、实时视觉、Android+iOS 统一 LiteRT”是实际落地过的。
2. Smart Baduanjin
Smart Baduanjin 是一个通过手机摄像头识别八段锦动作的应用。开发团队明确写到，他们需要把模型部署到 iOS 和 Android，并最终采用 TensorFlow Lite 实现实时动作识别。 它涉及：
- 摄像头实时输入
- 人体动作识别
- 连续端侧推理
- Android/iOS 双端部署 这比“上传头像时执行一次颜值评分”计算压力更大，因此至少能说明 LiteRT 双端运行视觉模型不是只停留在 Demo 层面。
ONNX Runtime
1. 官方完整项目
ONNX Runtime官方完整支持Android/iOS双端
Android
├── Java/Kotlin
├── C/C++
├── XNNPACK
└── NNAPI
iOS
├── Objective-C
├── C/C++
├── XNNPACK
└── Core ML
微软官方提供了同一超分辨率应用的 Android 和 iOS 实现，以及分别针对 Android 图像分类和 iOS 目标检测的完整项目。 所以技术上，完全成立，但是缺少明确证明ONNX被用于商业App的案例。
原因可能是LiteRT比较早，2017年TensorFlow Lite就发不了，ORT在2020年前后才正式推出。而且LiteRT一开始就是面向移动和嵌入式河北的架构，Andorid+iOS是核心场景。ORT则同时覆盖服务器、Windows、浏览器、云端和移动端，公开案例不一定专门强调Mobile。