LiteRT.js 在浏览器中跑 AI 模型，速度碾压 TensorFlow.js

Dev.to ML 2026-07-26T17:22:59.900639

摘要：Google 官方宣称 LiteRT.js 配合 WebGPU 后速度比 TensorFlow.js 快 3 倍，实际测试在 MobileNetV2 上单次推理仅需 0.41 毫秒（约 2439 FPS），远超官方说法。即便换用更大的 EfficientNet-Lite4 模型，延迟也只升至 0.62 毫秒。WASM 后端也提供了稳定的 72 FPS CPU 方案，兼容性极佳。本文带你一探究竟。

从半信半疑到实测惊讶

不久前 Chrome 更新，官方号称把 Gemini Nano 塞进了浏览器；月初 Google 又宣称 LiteRT.js 搭配 WebGPU 后，速度最高可比 TensorFlow.js 快 3 倍。说实话，我第一反应是半信半疑——过去在浏览器里跑模型的“心理阴影”还在。但抱着试一试的心态跑了一遍测试，结果让我有点意外。

LiteRT.js 是什么？

简单来说，LiteRT.js 是 LiteRT 的 JavaScript 桥梁。它将原本原生的 C++ runtime 编译成 WebAssembly，并在浏览器中提供了 WebGPU、WebNN、WASM 三种后端选择。

这不是一个全新的 AI 框架，而是直接继承了庞大的 .tflite 生态。你在 Hugging Face（litert-community）或 Kaggle 上下载的大量预训练模型，都能直接拿来用。

测试环境

• 硬件：M2 Max（30-core GPU, 96GB 统一内存）
• 浏览器：Playwright + Chromium（开启 --enable-webgpu --use-angle=metal，使 WebGPU 直接走 Metal API）
• 测试模型：
• MobileNetV2 1.0 224（float32，13MB，3.5M 参数）
• EfficientNet-Lite4（float32，49MB，17M 参数）
• 流程：每组先行 Warmup 5 次，然后正式执行 50 次推理，分别记录 Cold Start（含 Shader 编译的首次执行）和稳定后的平均延迟。

MobileNetV2 结果：LiteRT.js WebGPU 仅需 0.41 毫秒

第一个结果出来时，我甚至怀疑是不是哪里搞错了——

• Cold start: 4.3 ms
• Average: 0.41 ms
• Min: 0.20 ms / Max: 0.80 ms
• StdDev: 0.12 ms
• Throughput: 2,439 FPS

每次推理平均只需 0.41 毫秒，50 次测试中最慢的一次也才 0.8 毫秒，标准差仅 0.12 毫秒，表现非常稳定。

一个小细节：WebGPU 的 model.run() 返回的是 Promise，实际 resolve 的时间点可能略早于 GPU 芯片真正完成计算，0.41 毫秒也许存在微小的乐观偏差。但即便我们“打折”到 1 毫秒，那也是每秒处理 1000 张图片的惊人性能。

而且 Cold Start 只要 4.3 毫秒，完全不像之前 WebGL 那样需要忍受漫长的首次编译等待（PTSD）。

WASM 后端：纯 CPU 的极限

同一个模型、同一套 runtime，把 backend 从 webgpu 换成 wasm：

• Cold start: 18.6 ms
• Average: 13.81 ms
• Min: 13.5 ms / Max: 14.3 ms
• StdDev: 0.17 ms
• Throughput: 72 FPS

13.81 毫秒（约 72 FPS）对绝大多数前端视觉应用来说已经绰绰有余，而且 WASM 的延迟同样非常稳定。它的最大价值在于绝对兼容性：不用操心用户显卡好坏或浏览器支持度，不挑硬件。

TensorFlow.js WebGL 对比

再看我们最熟悉的旧朋友 TensorFlow.js：

• Cold start: 10,014 ms（10 秒）
• Average: 10.82 ms
• Min: 10.2 ms / Max: 12.2 ms

Cold Start 长达 10 秒，稳定后的平均推理延迟 10.82 毫秒（约 92 FPS）。相比 LiteRT.js WebGPU 的 0.41 毫秒，差距远超官方宣传的“3 倍”，实际达到约 26 倍。

关键要点

• LiteRT.js WebGPU 后端在 MobileNetV2 上达到 0.41 毫秒 / 2439 FPS，远超 TensorFlow.js WebGL 的 10.82 毫秒 / 92 FPS。
• WASM 后端提供 72 FPS 的稳定 CPU 性能，兼容性极佳。
• LiteRT.js 直接继承 .tflite 生态，Hugging Face、Kaggle 上的模型即拿即用。
• 对前端开发者意味着：浏览器端 AI 推理速度瓶颈已被大幅突破，实时视觉应用（如人脸检测、物体识别）现在可以部署到手机上甚至低端设备。

在浏览器端运行机器学习模型，LiteRT.js（基于 WebGPU）在吞吐量、冷启动延迟和大模型表现上全面碾压 TensorFlow.js（基于 WebGL）。实测数据显示，LiteRT.js WebGPU 的推理延迟低至 0.41 毫秒，冷启动仅需 4.3 毫秒，而 TensorFlow.js WebGL 冷启动却要 10 秒以上。即便面对参数增大近 5 倍的模型，LiteRT.js 依旧维持 1600+ FPS，而 WASM 后端则直接崩到 8 FPS。

性能对比：LiteRT.js 吊打 TensorFlow.js

实际测试中，LiteRT.js 的 WebGPU 后端稳定运行后平均延迟仅 0.41 毫秒，帧率高达 2,439 FPS。冷启动时间更是惊人——4.3 毫秒，无论第几次打开页面都保持稳定。

反观 TensorFlow.js 的 WebGL 后端：虽然稳定后延迟 10.82 毫秒、帧率 92 FPS 还算流畅，但冷启动简直是噩梦。WebGL 第一次执行时必须编译 Shader，硬生生卡了 10 秒才出结果。Chrome 虽然会缓存编译好的 Shader，第二次打开能降到 359 毫秒，但只要用户首次访问或习惯清缓存，这 10 秒就是硬伤。

三个后端完整对比：

为什么 WebGPU 能吊打 WebGL？ 两者设计基因完全不同。WebGL 是把神经网络运算硬塞进 3D 图形的 Fragment Shader 里，而 WebGPU 从第一天就是为通用计算（Compute Shader）和 ML 推理设计的。

大模型测试：EfficientNet-Lite4

小模型表现好不稀奇，换个大模型试试？我用 EfficientNet-Lite4（参数量 17M，文件 49MB，输入 300x300，Top-1 准确率 80.4%），参数大概是 MobileNetV2 的 4 倍多。结果令人吃惊：

EfficientNet-Lite4 (WebGPU)
- Cold start: 0.8 ms
- Average: 0.62 ms
- Min: 0.40 ms / Max: 1.10 ms
- StdDev: 0.15 ms
- Throughput: 1,623 FPS

参数量多了近 5 倍，延迟竟然只微增 50%？这是因为 GPU 上计算密集度随通道数增加而提高，反而更能吃满 GPU 的并行计算核心。

WASM 在大模型上直接崩了

把同样的 EfficientNet-Lite4 丢给 WASM 后端，结果悲催：

EfficientNet-Lite4 (WASM / XNNPACK)
- Cold start: 131.8 ms
- Average: 124.37 ms
- Throughput: 8 FPS

参数量多 4.85 倍，WASM 延迟多了 9 倍——延迟几乎跟模型大小线性增长，没有 GPU 那种并行红利。

对比加速比更直观：

如果你的应用目前只能用 WASM，模型选择会被死死卡在 MobileNetV2 这种轻量级规模。但一旦能用 WebGPU，几乎可以放飞自我。

聊聊实务限制

优点讲完，说说实测中遇到的坑和现实限制：

Batch Inference 的限制

本想一次喂 2 或 4 张图片做批推理，结果代码直接报错。原因是现成的 .tflite 模型在导出时已经把 Batch 维度锁死在 [1, 224, 224, 3]。前端做批处理不能像 Python 那样随意传 Tensor，必须自己通过 Multiple Model Instances 或 Web Worker Pool 来并行处理。

手动内存管理

LiteRT.js 必须手动调用 .delete() 来释放 Tensor。刚开始踩了几次坑，后来发现只要落实 cleanup，内存会稳定在 16~18MB，完全没有泄漏。估计后续会有更贴心的补丁。

移动端与浏览器兼容性

（本段内容属于第 1 段或第 3 段，此处略——编者注）

查看原文