谷歌甩出 LiteRT.js：浏览器跑 AI 提速 3 倍，TF.js 时代要结束了

7 月 9 日，谷歌在开发者博客里悄悄放出了 LiteRT.js，一个专门用来跑浏览器端 AI 推理的新库。定位很直接——替代 TensorFlow.js 沿用多年的 JavaScript 内核。官方给出的数字是：在搭载 M4 芯片的 2024 款 MacBook Pro 上，相较现有方案速度最高提升 3 倍。

这事儿看着像常规版本更新，其实是谷歌 Web AI 技术栈的一次换血。TensorFlow.js 从 2018 年推出到现在快八年了，一直是浏览器端机器学习的事实标准，但它的性能天花板早就被开发者吐槽过无数次。LiteRT.js 的登场，基本可以理解为谷歌自己动手把这个天花板拆了。

为什么是现在？TF.js 的 JS 内核已经拖不动了

先说背景。TensorFlow.js 早期的核心思路是把机器学习模型跑在 JavaScript 里，靠 WebGL 做 GPU 加速。这套方案在 2018 年是很先进的，毕竟浏览器能跑神经网络本身就是个奇迹。但问题在于——JavaScript 是解释型语言，即便有 V8 的 JIT，跟原生代码比性能差距依然明显；WebGL 又是图形 API 硬凑出来的计算通道，做矩阵运算并不高效。

结果就是：稍微大一点的模型（比如 Whisper、Stable Diffusion 蒸馏版），在浏览器里跑起来延迟高得让人怀疑人生。开发者要么放弃客户端推理转投服务端，要么就得手动写 WebAssembly 优化关键算子——费劲。

LiteRT.js 的技术选型直接把这三块短板都补了：

• WebAssembly 做内核：二进制指令格式，接近原生代码执行速度，取代解释执行的 JS 内核
• WebGPU 做 GPU 加速：现代 GPU 计算 API，专为通用计算和图形渲染设计，比 WebGL 高效得多
• WebNN 做硬件后端：直接对接操作系统的神经网络加速器（比如 Apple Neural Engine、NPU）

三层加起来，才有了 M4 上 3 倍加速的成绩。

3 倍是怎么来的？看看谷歌的测试细节

谷歌自己的博客里说得挺谨慎——3 倍是在 M4 MacBook Pro 上测出来的，旧硬件和不同浏览器引擎上的实际表现"可能存在差异"。这话翻译过来就是：新硬件+Chrome 才能跑出这个数字，Safari 和 Firefox 上打个折是常态。

但即便打折，方向也是对的。因为 LiteRT.js 底层跑的是 .tflite 格式的模型——这是 LiteRT（原 TensorFlow Lite）用了很多年的移动端格式，生态非常成熟。也就是说，你在手机端跑得动的模型，理论上可以直接扔进浏览器跑，不需要额外做格式转换或者算子适配。

这一点其实比 3 倍加速本身更重要。以前 Web AI 开发者最头疼的一个环节就是模型转换：拿个 PyTorch 模型，先转 ONNX，再转 TF SavedModel，再转 TF.js 格式，中间还得处理各种算子不兼容的问题。LiteRT.js 复用了 LiteRT 的转换链条，等于把移动端已经踩过的坑都省了。

跟 ONNX Runtime Web 比，谁更能打？

这才是开发者真正关心的问题。目前浏览器端 AI 推理的主流选手是这么几个：

1. TensorFlow.js：老牌，生态最全，但性能落后
2. ONNX Runtime Web：微软出品，跨框架能力强，性能中上
3. Transformers.js：Hugging Face 出品，基于 ONNX Runtime Web，主打 LLM 场景
4. LiteRT.js：新来的，谷歌背书，性能对标 native

从技术架构上看，LiteRT.js 和 ONNX Runtime Web 其实思路很像，都是 WASM + WebGPU 的组合拳。区别在于生态绑定——LiteRT.js 天然亲和 TFLite/JAX/Keras 的模型，ONNX Runtime Web 则是通用格式。

对开发者来说，选型逻辑基本是：如果你已经在用 TF 生态或者做移动端 ML，LiteRT.js 是无脑选择；如果你在用 PyTorch 或者需要跨框架灵活性，ONNX Runtime Web 依然是更好的选项。

谁会真的用上？三个典型场景

浏览器端 AI 推理这几年一直是个"看起来很美"的方向，说了很多年，落地的产品并不多。核心原因就是性能不够——1 秒钟能出结果的事情，用户能忍；5 秒钟才出结果，用户直接关标签页。

LiteRT.js 把这个延迟阈值往下压了一截，能激活一批之前跑不动的场景：

• 实时视频处理：背景虚化、美颜、手势识别，Google Meet 这类产品已经在用了
• 端侧 LLM：小参数量模型（1B-3B）直接在浏览器里跑，隐私敏感场景的刚需
• 交互式 ML 教育：Kaggle、Colab 这类平台可以把演示做得更流畅

特别是端侧 LLM 这块。Chrome 内置的 Gemini Nano 走的是浏览器 API 路线（用户不可控），而 LiteRT.js 走的是开发者可控路线——你想跑什么模型自己决定，.tflite 格式的量化 LLM 现在越来越多。

一个小小的态度：这次谷歌的节奏踩对了

说句实话，谷歌在 Web AI 这块一直有点摇摆。deeplearn.js（2017）→ TensorFlow.js（2018）→ MediaPipe（2019）→ 现在的 LiteRT.js，每几年就重新造一次轮子，开发者跟着迁移也挺累。

但这次 LiteRT.js 的定位比较清楚：它不是要取代整个 TF.js 生态，而是把最底层的推理内核换掉。上层 API 谷歌明显在往兼容性方向做，迁移成本应该不会太高。加上 WebGPU 今年在各家浏览器的支持度终于稳定下来，时机也踩得比较准。

从更大的图景看，端侧 AI（不管是手机还是浏览器）在 2026 年会是一个明显的增长方向。云端大模型贵、慢、隐私差的问题越来越突出，能在客户端跑的活儿越来越会被推到客户端。LiteRT.js 这一步，算是给 Web 平台补齐了一块重要的拼图。

对于需要在服务端调用各类主流 AI 模型的开发者，OpenAI Hub（openai-hub.com）依然是国内直连、一个 Key 打通 GPT、Claude、Gemini、DeepSeek 的实用选择——但这次的话题里，主角是能让你完全不需要服务端的浏览器推理。

参考来源

• IT之家：谷歌发布 LiteRT.js 库，Web AI 推理最高提速 3 倍 - 国内媒体首发报道，包含官方博客核心信息与架构截图