LiteRT.js 正在超越 TensorFlow.js

使用 WebGPU 的 LiteRT.js 在 M2 Max 台式机 GPU 上运行 MobileNetV2 推理仅需 0.41 ms，可达到 2,439 FPS——在相同硬件上比 TensorFlow.js 快了 25 倍以上。对于更大的模型，这种差距会进一步扩大，将基于 Web 的机器学习带入了曾经只有原生应用才能达到的性能层级。

为什么这项基准测试至关重要

开发者一直使用 TensorFlow.js 进行设备端推理，通常通过 WebGL 后端实现。WebGL 将张量操作映射到浏览器的 2D 图形流水线中；它虽然兼容性极强，但并非为深度学习模型所需的大规模并行计算而设计。WebGPU 作为下一代图形 API，提供了对 GPU 计算单元的直接访问。LiteRT.js 是第一个为 TensorFlow-Lite 模型提供 WebGPU 后端推理引擎的库，据 Google 报告，其速度提升了三倍。独立测试显示出更大的增益，这引发了一个问题：WebGPU 是否会成为 Web 端机器学习的默认路径。

测试是如何进行的

我们对两个图像分类模型——MobileNetV2 和 EfficientNet-Lite4（均已转换为 TensorFlow-Lite 格式）进行了基准测试。测试在搭载 Apple Silicon M2 Max 芯片的设备上运行。对于每个模型，我们测量了多次迭代中单次前向传播的延迟，并报告了每秒帧数 (FPS)。我们同时使用 WebGL 后端的 TensorFlow.js 运行相同的模型，并记录了每个库的冷启动时间。

结果：速度与启动

  • MobileNetV2

    • LiteRT.js (WebGPU): 0.41 ms 延迟 → 2,439 FPS
    • TensorFlow.js (WebGL): 10.82 ms 延迟 → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): 0.62 ms 延迟 → 1,623 FPS
    • TensorFlow.js (WebGL): 未报告，但 MobileNetV2 已显示出超过 25 倍的优势。

TensorFlow.js 在进行第一次推理之前，需要大约 10 秒 (10,014 ms) 来编译其 WebGL 着色器 (shaders)。而 LiteRT.js 在 4.3 ms 内即可就绪，这基本上消除了交互式应用的冷启动惩罚。

当我们将模型大小增加五倍时，延迟仅上升了 50%，这证实了 GPU 的并行性吸收了大部分额外的工作量。其结果是开辟了一个性能新前沿，让浏览器无需经过服务器往返，即可处理实时视频流、AR 叠加层或视觉模型的快速原型设计。

数据背后隐藏的问题

  • 批处理 (Batching) – 大多数 TensorFlow-Lite 模型将 batch 维度锁定为 1。原生并不支持在单次调用中输入多张图像，这迫使开发者必须启动 Web Workers 或手动构建输入流水线。
  • 内存管理 – LiteRT.js 不会自动对 GPU 张量 (tensors) 进行垃圾回收。开发者必须对创建的每个张量调用 .delete()，否则在进行几百次推理后可能会面临耗尽 GPU 显存的风险。
  • 硬件覆盖范围 – WebGPU 在桌面版 Chrome 和 Firefox 上表现稳定。移动端浏览器——包括 Android 上的 Chrome 和 iOS 上的 Safari——仅在实验性标志 (flags) 后端提供该 API，甚至完全不支持。在这些平台上，WASM 后端仍然是唯一通用的路径，但对于较大的模型来说，其速度明显较慢。

这些限制意味着，虽然原始速度令人印象深刻，但实现这一速度所需的工程努力可能并不简单。

局限性与权衡

TensorFlow.js 的 WebGL 后端仍然提供近乎通用的兼容性。针对混合受众（桌面端、Android、iOS）的开发者可以依赖单一的代码路径，虽然吞吐量较低，但可以在任何地方运行。WASM 后端几乎可以在任何硬件上运行，但在本文测量的较大模型上，其表现落后于 WebGPU。

当目标是启用 WebGPU 的桌面环境时，LiteRT.js 的优势便显现出来。它可以直接运行 .tflite 模型，让开发者无需转换即可从 Hugging Face 或 Kaggle 获取模型，从而保留原始的量化 (quantization) 和性能。其权衡在于部署范围较窄，且需要谨慎进行资源处理。

开发者应考虑的事项

  • 目标平台 – 对于仅限 Web 的桌面工具（例如实时应用风格迁移的设计应用），使用 LiteRT.js 配合 WebGPU 可能是最佳选择。
  • 模型大小 – 计算密集型的大型模型从 GPU 并行化中获益最多；对于小型模型，可能并不值得投入额外的工程成本。
  • 内存规范 – 规划显式的张量删除操作，或者将推理调用封装在能够自动释放资源的范围内。
  • 回退策略 (Fallback strategy) – 为无法启用 WebGPU 的浏览器提供 WASM 或 WebGL 回退方案，以确保应用对更广泛的用户群体保持可用。

总结

LiteRT.js 证明了 WebGPU 可以将基于 Web 的推理推向亚毫秒级水平，在桌面级 GPU 上提供的速度是 TensorFlow.js 的 25 × 以上。该技术仍处于成熟阶段，开发者必须应对批处理限制、手动内存清理以及有限的移动端支持。对于追求实时性能的桌面优先体验，这个新库提供了一条极具吸引力的发展路径；而对于实现跨平台覆盖，较旧的 WebGL 和 WASM 后端仍然不可或缺。