LiteRT 与 TensorFlow Lite 什么关系：迁移时看这几层

LiteRT 与 TensorFlow Lite 不是两个毫无关系的项目。Google 将 LiteRT 描述为从 TensorFlow Lite 基础上演进而来的端侧 AI 框架。对开发者来说，重点不只是品牌更名，而是先判断自己的工作负载属于经典 ML 还是生成式 AI，再选择模型格式、运行时 API 和硬件路径。

先区分“已有 TFLite 模型”和“端侧 LLM”

已有 .tflite 分类、检测、分割模型，不应因为 LiteRT 出现就自动重做。先检查当前 API 的兼容与迁移说明，确认是否能保持模型和调用链。

端侧 LLM 则是另一类负载：模型包、tokenizer、KV cache、流式生成与多模态输入都需要生成式模型专用能力。此时应研究 LiteRT-LM，而不是拿经典 Interpreter 示例硬套。

官方定位

Google 官方将 LiteRT 定位为从 TensorFlow Lite 演进而来的跨平台端侧 AI 框架，目标覆盖受支持平台上的 CPU、GPU、NPU 执行。它仍然服务经典模型，同时扩展现代端侧生成式 AI 的工程路径。

LiteRT-LM 在 google-ai-edge/LiteRT-LM 公开仓库开发，使用自己的模型包和 API。它不是“把 GGUF 改个后缀”，也不是所有旧 TFLite 示例的直接替换。

Gemma 官方运行指南把 LiteRT-LM 列为 Android 与 iOS 的端侧 LLM 部署路径，并描述 CPU、GPU、NPU 方向。实际模型和设备支持仍应以当前文档与真机验证为准。

迁移要看五层

层	要确认的问题
模型	当前 artifact 格式是否继续支持
API	初始化、输入、输出、线程模型是否变化
后端	设备上实际选中 CPU/GPU/NPU 哪条路径
生命周期	加载、取消、关闭、进程重建是否安全
测试	旧版本的输出与性能基线能否重放

不要一次同时升级模型、运行时、量化和业务 prompt。每次只改一个变量，才能知道差异来自哪里。

什么情况下先不迁移

如果现有经典模型已经稳定、设备覆盖明确、没有新能力需求，迁移的价值需要用维护成本和真实收益说明。追新版本本身不是产品目标。

若准备加入端侧 LLM、多模态或新的硬件路径，可以先做独立 POC，不要直接改生产链路。用同一输入集对照加载、输出、内存、持续运行和失败恢复。

构建一个运行时边界

业务层应依赖自己的接口，而不是把某个 LiteRT 类型传遍 ViewModel 与 UI：

interface InferenceEngine {
    suspend fun load(): Result<Unit>
    suspend fun run(input: Input): Result<Output>
    suspend fun cancel()
    suspend fun close()
}

这样经典模型与生成式模型可以拥有不同实现，测试也能注入 fake。迁移时变动集中在适配层。

验收清单

• 明确是经典 ML 还是生成式 AI。
• 固定迁移前 artifact 与运行时版本。
• 阅读当前官方迁移与兼容文档。
• 不用改后缀代替模型转换。
• 记录真机实际执行后端。
• 重放相同输入与输出验证。
• 测连续运行、取消、后台和释放。
• 保留回滚路径。

端侧 LLM 接入可继续看 LiteRT-LM Android 教程与 LiteRT-LM 和 llama.cpp 怎么选。Cove 英文运行时对比见 LiteRT-LM vs llama.cpp on Android。

---

本文最后核验于 2026-09-16，API 与兼容范围以 Google 当前官方文档为准。