谷歌开源 LiteRT

面向边缘/终端设备的高性能机器学习与生成式 AI 部署框架，强调“转换（conversion）—运行时（runtime）—优化（optimization）”一体化工作流，并把重点放在端侧推理性能与硬件加速落地。LiteRT 的定位并非“从零重写”，而是 TensorFlow Lite（TFLite）的更名与演进路线：Google 在 2024 年 9 月明确表示，LiteRT 是 TFLite 的新名称，目标是更贴近多框架生态（PyTorch/JAX/Keras 等），同时对既有应用尽量“低扰动”。文件格式层面也保持兼容：.tflite 扩展名与 FlatBuffer 格式不变，原有 .tflite 模型可由 LiteRT 读取。

LiteRT 2.x 将重心从传统的 Interpreter（解释器式执行）推向 CompiledModel（编译式/硬件感知执行）API：官方文档将其定义为“现代标准”的端侧推理接口，优先承载新的性能特性与加速能力；其核心机制包括自动选择 CPU/GPU/NPU 后端、异步执行，以及更高效的 I/O 缓冲管理（面向端到端延迟而非仅算子吞吐）。

在 GPU 侧，Google 在 2026 年 1 月 28 日的更新中宣布：此前在 Google I/O 2025 预告的“高级加速能力”已进入 LiteRT 生产栈并对开发者可用；GPU 引擎以 ML Drift 为核心，覆盖 OpenCL / OpenGL / Metal / WebGPU，目标是让同一套推理逻辑跨 Android、iOS、桌面与 Web 平台更一致。官方给出的量化口径是：相较旧版 TFLite GPU delegate，LiteRT GPU 平均可实现约 1.4× 性能提升；并通过“异步执行 + 零拷贝 buffer 互操作”降低 CPU 介入和内存搬运带来的系统级开销，特定场景宣称最高可到约 2× 的端到端加速。

NPU 侧，LiteRT 把“端侧碎片化”作为主要工程问题：不同 SoC 的编译器/运行时差异会迫使应用层处理大量适配。Google 的描述是，LiteRT 提供统一 NPU 部署工作流以抽象底层厂商 SDK，并提供 AOT（可选的预编译）与 JIT（端上编译）两种策略；同时保持失败回退到 GPU/CPU 的路径。2026 年 1 月的官方文章还指出，面向 MediaTek 与 Qualcomm 的首批“生产级”NPU 集成已可用，并给出“最高可达 CPU 100×、GPU 10×”这类性能宣称（需注意这通常依赖模型结构、算子覆盖与具体硬件）。

在“模型来源”上，LiteRT 明确把自己定位为多框架端侧推理栈：官方文档写明支持从 PyTorch、TensorFlow、JAX 转换到 .tflite 或 .litertlm；GitHub 仓库也给出两条典型路径——经典模型通过 Torch Converter 转成 .tflite 并配合量化工具做资源约束优化；LLM 路线则通过 Generative Torch API 重新表述/转换，再接入 LiteRT-LM 进行端侧推理与编排。

从工程成熟度看，GitHub Release 显示 LiteRT v2.1.0 被标注为“beta release”，并声称 API 已稳定且达到与 TensorFlow Lite 的功能对齐（feature parity），同时把 GPU/NPU 加速作为关键增量：运行时侧加入自定义算子支持（custom op dispatcher）、CMake 构建、预编译 C++ SDK（libLiteRt.so）、以及 CompiledModel 的 Profiler/ErrorReporter/ResizeInputTensor 等接口；GPU 侧扩大 WebGPU/Dawn 与 OpenCL 覆盖，并为 Metal/WebGPU 增加异步执行。Release 文案同时“官方推荐开发者开始迁移到 LiteRT”。

Github
 
 
Back to Top