LiteRT：TensorFlow Lite 的后继者如何重排端侧推理
项目速览：LiteRT，TensorFlow Lite 的后继者。是 Google 的设备端框架，用于通过高效的转换、运行时和优化在边缘平台上部署高性能 ML 和 GenAI。
秒懂
- 它是什么？
- LiteRT 承接 TensorFlow Lite，用 V2 的 Compiled Model API、统一 NPU 接口和 .litertlm 格式重组端侧推理链路。本文拆解它的转换管线、平台支持表里的星号和发布节奏。
- 适合谁用？
- LiteRT 适合要把推理放进手机、浏览器或 IoT 设备的团队，尤其当目标芯片落在 Android NPU 名单内；它不承担训练，也不是服务器推理工具。苹果平台要清醒：ANE 支持仍停在预告状态，现阶段只能按 CPU 加 Metal 估性能。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
TensorFlow Lite 的后继者：V2 的 Compiled Model API 换掉了什么
LiteRT 是 TensorFlow Lite 的官方后继项目，仓库描述把定位放在第一句：面向边缘平台的高性能机器学习与生成式 AI 部署框架，覆盖转换、运行时与优化三段。主语言 C++，许可证 Apache-2.0。名字换了，延续关系写在明面上，README 提供了从 TensorFlow Lite 与 LiteRT V1.x 升到 V2.x 的迁移指南。
V2 的变化集中在 Compiled Model API。README 列了四项：自动选择加速器，不再要求显式配置 delegate；真正的异步执行；便于做 NPU 分发；更高效的 I/O 缓冲处理。对从 TensorFlow Lite 过来的人，第一项分量最重。delegate 选型向来是端侧部署里最费神的一步，交给运行时自动判断能省掉一类配置错误。
GPU 侧的新东西叫 ML Drift，README 称通过新的缓冲区互操作，在多种 GPU 缓冲类型之间降低延迟，用来支撑生成式推理。NPU 侧是统一接口，宣称用同一套 API 访问主流芯片厂商的 NPU。这些说法都出自 Google 自己的 README，没有附基准数字，性能判断只能留到自己的模型上做。
What's New 一节还透露了边界的扩张方向。部署 LLM 走独立的 LiteRT-LM 仓库；浏览器里靠 LiteRT.js，基于 WebGPU 和 WASM 做客户端推理；连 AI 编码代理也被照顾到，README 称 LiteRT CLI 这个命令行工具集可以配合编码代理工作。端侧运行时附带代理工作流支持，这个组合在同类项目里少见，也说明 Google 想让模型部署的每一段都留在自家工具里。
从 PyTorch 权重到端侧运行：.tflite 与 .litertlm 两条支路
README 里那张 mermaid 图给出了完整数据流。起点是 PyTorch 模型，经 LiteRT Torch 转换，Hugging Face transformer 的 safetensors 也汇入这条路。常规模型输出 .tflite，生成式模型走 Generative Torch API 输出 .litertlm。图中量化前后的文件分别标成 .tflite 与 Optimized .tflite、.litertlm 与 Optimized .litertlm，可见量化是独立的一道工序，不是转换时的默认动作。
运行时分成两支。LiteRT-LM 消费 .litertlm，绑定覆盖 Python、C++、Kotlin、Swift 和 JS；LiteRT Runtime 消费其余模型，绑定是 C++、Kotlin 和 JS。执行后端列了三类：CPU 走 XNNPack，GPU 走 ML Drift，再加上已支持的 TPU 与 NPU。
有一处文档缝隙要记下：图上方的文字写着支持 PyTorch、TensorFlow 和 JAX 三种来源模型，图里却只画了 PyTorch 与 Hugging Face 两条入口，TensorFlow 和 JAX 的转换路径没有出现在图中。以文字为准还是以图为准，README 没有解释，动手前最好到 litert-torch 仓库和官方文档确认。
两条支路的分工也决定了依赖树的形状。只跑一个图像分类模型，引 LiteRT Runtime 加 XNNPack 就够；要跑量化后的 LLM，就得把 LiteRT-LM 连同它的多语言绑定一起拉进来。README 没有给出各组件的体积数据，包体大小需要在目标设备上自行验证。
平台支持表的读法：带星号的 NPU 还没交付
平台支持表是这份材料里信息密度最高的一张表。Android 行给出 OpenCL 与 OpenGL 两种 GPU API，NPU 一栏列了 Broadcom、Google Tensor、Intel、MediaTek、Qualcomm，其中 Qualcomm 在仓库里还有独立的 vendors 目录；S.LSI 名字后面带星号。iOS 与 macOS 的 GPU API 是 Metal，Apple Neural Engine 带星号。Windows 列 Intel，Web 列 WebNN，IoT 列树莓派，同样带星号。
表下脚注写明，星号的含义是即将交付。也就是说，当下真正可用的 NPU 支持集中在 Android 阵营，外加 Linux 与 Windows 上的 Intel 和 Broadcom；苹果平台的 ANE 还停在预告状态，iOS 与 macOS 目前能按 CPU 加 Metal 估算。部署目标若是吃满苹果芯片的神经引擎，这个仓库现在给不了，需要另查官方文档确认进度。
这张表也透露了项目的优先级。Google 自己的 Tensor 芯片、高通和联发科都在首发名单里，Web 端靠 WebGPU 补位。选型时把带星号的格子当成不存在，比当成路线图更安全。
还有一处容易被忽略：Linux 与 Windows 行的 GPU API 都写着 WebGPU，macOS 行才是 WebGPU 加 Metal 并列。桌面 Linux 上没有 OpenCL 或 Vulkan 的字样，GPU 加速走的是浏览器图形栈那一套 API。这对性能预期有直接影响，同一份模型在不同桌面系统上的 GPU 表现未必一致，README 对此没有给出解释。
六到八周一个稳定版：v2.2.0 前后的发布节奏
发布节奏 README 写得直白：每晚出 nightly 构建，稳定版目标六到八周一个。最近的 tag 能对上这个说法。v2.1.5 在 2026 年 5 月 18 日，v2.1.6 在 7 月 2 日，v2.2.0 在 8 月 13 日，两个间隔都约六周。构建状态表里，Linux、macOS、Windows 三条 nightly wheel 流水线挂在 GitHub Actions 上，另有一条面向 Android 的 CMake 构建。
这个频率对使用方意味着两件事。一是 API 会持续移动，V2 的 Compiled Model API 还在演进，锁定某个稳定版再排验证周期比较稳妥。二是 nightly 通道虽然新鲜，但把它接进生产构建，等于把上游的每次提交都变成自己的回归测试对象。从 V1 升级走官方迁移指南，TensorFlow Lite 与 LiteRT V1.x 两条来源都有覆盖，旧项目迁移前先把模型逐个过一遍转换。
还有一点材料本身的限制：这里能看到的三个 release 记录只有 tag、名称和发布日期，没有附变更说明。某次升级改了什么、有没有破坏行为，得去 release 页面或提交记录里翻。对嵌入式团队来说，升级评估的工作量不小，一个季度两次稳定版的节奏意味着这项工作是周期性的，不是一次性。
工具链散在五个仓库：litert CLI 只是入口之一
工具链不是一个仓库能装完的。主仓之外，README 链向 LiteRT-LM、litert-torch、litert-samples 和 LiteRT-CLI 四个仓库。CLI 的安装入口是 uv：先 uv venv 建一个 Python 3.13 的虚拟环境，再 uv pip install litert-cli-nightly，最后 litert --help 确认可用。包名里的 nightly 说明了现状，命令行工具只提供 nightly 渠道，README 没有给稳定版包名。
要做内存与图执行的精细控制，走仓库内的 Tensor API，一个以张量为中心的轻量 C++ 库，README 把它定位为移动端高性能张量操作。浏览器侧是 LiteRT.js，基于 WebGPU 与 WASM 做客户端推理。这些零件各有各的版本节奏，README 没有提供统一的兼容矩阵，组装与对齐的成本落在使用方头上，选型时要把这笔维护开销计进去。
CLI 那条安装命令里还有一个细节：README 提示，遇到依赖解析错误时设置 UV_INDEX_URL 环境变量可能有帮助，官方甚至直接给出了 PyPI 源地址。工具链对 uv 的绑定程度可见一斑，用惯 pip 或 conda 的团队要多一步适应，Python 版本锁定在 3.13 也不是所有环境都能立刻满足的。
模型从 litert-community 拿，示例看 litert-samples
不想自己转权重的场合，README 指向 Hugging Face 的 LiteRT Community 页面。最近新增的模型家族有三类：Gemma 4，标注为多模态、多种尺寸；ASR 语音识别集合；图像分类集合。这些模型卡的格式与量化情况 README 没有逐一说明，取用前要进模型卡核对。
第一次跑通的路径也写在 README 的路线表里。那张表按目标分流：升级旧项目的看迁移指南，转 PyTorch 模型的去 litert-torch，追性能的看 NPU 加速文档，跑浏览器端的应用走 LiteRT.js。想在移动端跑预训练模型，官方给了一个 Android Studio 实时图像分割 codelab，覆盖 CPU、GPU、NPU 三种推理方式；示例代码集中在 litert-samples 仓库的 compiled_model_api 目录，与 V2 的编译模型 API 对应。照着示例起步，比从空的 Android 工程接 native 库省事得多。
最后说一个贯穿全篇的观察：整份 README 没有一处性能数字。Superior、High-Performance 这类形容词反复出现，配套证据一个没有。端侧性能高度依赖具体芯片与模型，写不出通用数字可以理解，但阅读时要把这些词当作定位声明，不是承诺，更不是基准。
编辑结论
LiteRT 适合要把推理放进手机、浏览器或 IoT 设备的团队，尤其当目标芯片落在 Android NPU 名单内；它不承担训练，也不是服务器推理工具。苹果平台要清醒：ANE 支持仍停在预告状态，现阶段只能按 CPU 加 Metal 估性能。采用前核对两件事，目标芯片在平台表里是否带星号，模型走 .tflite 还是 .litertlm，后者要额外引入 LiteRT-LM。稳定版六到八周一个，验证与升级窗口按这个频率排。
社区笔记