谷歌放出 LiteRT Tensor API：一套 C++ 代码，CPU/GPU/NPU 通吃

端侧 AI 的老问题一直没变：想让模型在手机上跑得快，开发者往往要针对不同芯片重写一遍代码。11 月中旬，谷歌给出了一个新答案——LiteRT Tensor API，一套轻量级 C++ 接口，目标是让同一份计算图在 CPU、GPU 和 NPU 上都能跑。

一分钟速览：

• LiteRT Tensor API 允许开发者用 C++ 逐个算子搭建计算图
• 同一份图可跨 CPU、GPU、NPU 执行，减少针对硬件的重写
• 支持直接导入 Hugging Face 等来源的权重，支持零拷贝缓冲区互通
• 可配合编码智能体生成、修改、验证和基准测试模型图

它解决的是什么麻烦

传统做法是用 C++ 手写计算逻辑，控制力最强，但代价很高。实现代码和 Metal、OpenCL、Vulkan 等后端绑死，每增加一种硬件目标就要重写；想在 CPU、GPU、NPU 之间做零拷贝的数据互通和同步，还要把预处理、推理、后处理串起来，工程量惊人。

LiteRT Tensor API 把这些问题收进一层抽象：开发者仍然可以用算子级的方式定义模型结构，保留对架构、优化和加速器执行的控制，但同一张图可以通过 LiteRT 在不同硬件上运行，不必为每个新目标重新写一遍。

它还提供直接权重导入，能从检查点加载权重，包括 Hugging Face 上的文件；零拷贝缓冲区互操作则避免在预处理、推理和后处理之间反复复制加速器内存。对端侧应用来说，这两项直接关系到延迟和功耗。

让智能体来改图

这次发布里更值得注意的，是它对 AI 编码智能体的友好度。因为模型图是纯 C++ 定义的，编码智能体可以生成代码来构建、修改、验证和基准测试整张图，而不只是写几段胶水代码。

谷歌给了一个 SAM 2 多目标分割与跟踪的演示：同一份 C++ 代码分别跑在 macOS 笔记本的 Metal、iOS 手机的 Metal 和 Android 手机的 OpenCL 上。在 MacBook Pro 上，它比 Apple MLX（fp16，图像编码器加掩码解码器）快约 1.5 倍。

更有意思的是智能体做的优化：它把 SAM 2 的逐帧决策，比如“目标是否仍然可见”，从 CPU 代码搬进计算图；又重写了在 WebGPU 上触发 CPU 回退的操作，改用兼容 GPU 的算术运算。结果在 512×512 分辨率下，帧率从不足 10fps 提升到 30fps 以上，整个迭代由编码智能体完成。

什么时候该用，什么时候别用

Arm AI 总监 Laurence Moroney 在评论里给了一个务实的边界：只有在需要图级控制，或者希望把预处理和后处理留在加速器上时，才值得考虑这套 C++ API。换句话说，它不是要取代所有高层框架，而是补上“需要精细控制”的那一层。

谷歌公布的后续计划包括原生支持更多后端、增加对 NPU 友好的算子、自动全图量化，以及针对不同图像尺寸、批大小和序列长度的动态形状支持。这些能力决定了它能否从演示走向量产。

端侧竞争的新变量

端侧推理框架的竞争，过去比的是“支持多少算子、跑分多高”。LiteRT Tensor API 把另一个变量摆上台面：谁能让智能体参与到模型优化里。结构化原语越清晰，智能体越容易理解、修改和验证，优化循环也越快。

对开发者来说，短期价值是少写几套硬件适配；长期价值是模型图的优化可以部分交给智能体，人只负责定义目标和验收。端侧 AI 的瓶颈，正在从“能不能跑”转向“能不能低成本地跑好”。