核心要点

  • 能定位三者：TFLite 偏移动/嵌入式，ONNX Runtime 偏跨平台互操作，Core ML 偏苹果生态深度集成

  • 能说硬件后端：TFLite 用 GPU/NNAPI 委托，ONNX Runtime 用 Execution Provider，Core ML 直通 Apple NPU（ANE）

  • 能抓核心差异：生态绑定、算子支持覆盖度、硬件加速后端，是选型三大维度

  • 能给选型建议：仅苹果端选 Core ML，安卓/嵌入选 TFLite，多端统一与模型互转选 ONNX

标准回答

三者本质都是端侧推理运行时与模型格式，差异集中在生态、算子支持与硬件后端。

TFLite

面向移动与嵌入式，模型体积小、运行时轻量，通过 Delegate 机制把算子委托给 GPU、NNAPI 或厂商 NPU 加速，安卓与 IoT 场景成熟。

ONNX Runtime

以跨平台与互操作为核心：ONNX 是开放交换格式，多框架可导出，再由 ONNX Runtime 通过不同 Execution Provider（CPU、CUDA、CoreML、NNAPI 等）在各平台运行，适合需要一套模型跑多端的场景。

Core ML

苹果生态原生方案，与 iOS/macOS 深度集成，可直接调度 Apple Neural Engine（ANE）获得高能效，开发体验好，但只服务苹果设备。

选型

只面向苹果端用 Core ML；安卓/嵌入式用 TFLite；要跨多端统一或在框架间互转，用 ONNX 作中间格式 + ONNX Runtime。

常见误区

⚠️ 常见踩坑

以为换个格式就能自动获得加速——实际能否调用 NPU 取决于算子是否被该后端支持，遇到不支持算子会回退 CPU；以及忽视格式转换中算子缺失/语义差异导致的精度或可用性问题。

追问

追问 1：遇到目标格式不支持的算子怎么办？

常见做法：用支持的算子等价改写或拆解、升级运行时版本、注册自定义算子，或在导出前替换模型中的非标准算子。否则该算子会回退到 CPU 执行，破坏整条加速链路。要在目标设备上实测各算子的后端落点。

追问 2：为什么端侧 LLM 常用 GGUF 而不是这些格式？

GGUF 专为本地 LLM 推理（如 llama.cpp 生态）设计，内置低比特量化方案与权重打包，便于在 CPU/移动端高效加载与运行大语言模型；而 TFLite/ONNX/Core ML 更通用，针对一般神经网络。端侧 LLM 看重低比特量化与内存布局，故常走 GGUF 路线。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。

📚 知识库

📖 术语表

🛠️ AI 工具

  • llama.cpp

    高性能 C++ LLM 推理引擎，支持在 CPU/GPU 上运行各种开源大语言模型，GGUF 量化格式首创者，本地 AI 生态核心基础设施

  • onnx

    开放神经网络交换格式（ONNX），21K+ stars。跨框架的 ML 模型表示标准，支持 PyTorch、TensorFlow 等框架间模型转换与互操作，是模型部署生态的基础规范

🎯 相关面试题