Google LiteRT.js 将高性能 Web AI 推理带入浏览器，但兼容性仍是考验

Google 于 7 月 9 日推出 LiteRT.js。尽管浏览器加速能力参差不齐，该库仍将其高性能 Web AI 推理运行时直接带入 JavaScript 应用。这个新库可以通过 WebGPU、实验性的 WebNN 支持，或基于 WebAssembly 的 CPU 后备方案，在本地运行机器学习模型。

重要的变化并不只是浏览器现在能够运行 AI 模型。TensorFlow.js 和 ONNX Runtime Web 已经具备这一能力。Google 正在将其原生、跨平台的 LiteRT 技术栈带入浏览器，使其能够复用为 Android、iOS 和桌面系统开发的优化成果。

这一决定给以 JavaScript 为先的推理库带来了压力，也在检验统一的原生运行时能否在碎片化的浏览器和硬件环境中提供一致的结果。Google 报告了显著的基准性能提升，但这些数据来自受控的 Apple M4 环境，而不是公共 Web 上形形色色的设备。

Google LiteRT.js 改变 Web AI 运行时层

Google LiteRT.js 让浏览器推理更接近原生边缘平台所使用的运行时。

Google 将 LiteRT.js 描述为 LiteRT 的 JavaScript 绑定，而 LiteRT 是其设备端推理技术栈。开发者可以加载 .tflite 模型，并在浏览器中执行，而无需将输入数据发送到远程推理服务器。

LiteRT.js 发布公告支持 JavaScript 和 TypeScript 应用。其初始软件包包含模型加载、编译和运行工具，以及涵盖向量搜索、目标检测、深度估计和图像放大的示例。

这种架构改变了核心工作发生的位置。早期的浏览器 AI 库通常通过面向 JavaScript 的内核或浏览器图形接口实现运算。LiteRT.js 则通过 WebAssembly 向浏览器开放 Google 的原生运行时。WebAssembly 是一种可移植的二进制格式，浏览器能够以接近原生的速度执行它。

随后，运行时会选择一条加速路径。XNNPACK 负责优化 CPU 执行，Google 的 ML Drift 层则通过 WebGPU 面向 GPU。WebNN 是一种新兴的浏览器神经网络硬件接口，旨在连接专用神经处理单元。

当加速路径不可用时，WebAssembly 也能提供后备方案。这一后备机制十分重要，因为 Web 应用无法假设每位访客使用的浏览器、驱动程序、GPU 或操作系统都相同。

Google 将此次发布定位为已经使用 .tflite 模型的团队的一次演进。这些团队可以在移动端、桌面端和 Web 端使用同一种模型格式，而不必单独构建浏览器流水线。

PyTorch 用户也可以通过 LiteRT Torch 接入这一路径。Google 表示，该转换工具可以将 PyTorch 模型转换为与 LiteRT 兼容的产物。随后，AI Edge Quantizer 可以在选定层中使用低精度表示，降低模型大小和计算需求。

此次发布还包括通过 npm 分发的 @litertjs/core 软件包。Google 同时在其 LiteRT 代码库中提供浏览器演示和集成示例。这些资源表明此次发布不只是路线图层面的声明，不过能否用于生产环境，仍取决于具体应用的模型和浏览器目标。

浏览器现在可以通过同一套更广泛的运行时家族，承载文本生成、目标检测、音频处理和嵌入模型，而这套运行时家族也被用于原生设备。这为已经交付边缘 AI 的团队提供了更清晰的部署路径。

本地运行的设计也改变了运行模式。输入数据可以保留在用户设备上，推理无需经过服务器往返，部分功能即使没有网络连接也能继续运行。

但这些优势并非自动成立。浏览器仍需下载模型和运行时，设备也必须拥有足够的内存和计算能力，才能执行工作负载而不影响响应速度。

因此，核心消息在于架构。Google 并不是首次引入基于浏览器的推理，而是让浏览器开发者能够使用一个经过多年原生边缘部署塑造的运行时。

为什么 Google LiteRT.js 的高性能 Web AI 推理正值其时

浏览器正在成为 AI 的执行目标，而不只是云端模型的界面。

大多数生成式 AI 产品仍会将提示词及其他输入发送到远程基础设施。这种模式非常适合大型模型、集中式更新，以及超出消费级硬件能力范围的工作负载。

然而，云端推理会带来网络延迟、持续的服务成本和数据传输方面的顾虑，也可能让原本可以本地完成的工作流依赖稳定的网络连接。

浏览器推理提供了另一种模式。应用下载合适的模型，在设备上处理数据，并在无需每次请求都联系推理端点的情况下返回结果。

这种方式适合模型体积较小且交互频繁的任务。摄像头特效、音频分类、文档嵌入、图像增强和目标追踪，都可以从避免反复网络请求中受益。

Google 的向量搜索演示就是一个例子。LiteRT.js 可以在浏览器中运行嵌入模型，将文本转换为数值表示，从而支持本地相似度搜索。

这种模式可以支持针对少量用户内容的私密搜索，也可以帮助应用先在本地对内容进行排序，再请求成本更高的云端模型。

此次发布之际，WebGPU 正在主流 Chromium 浏览器中成为一种实用的计算选项。WebGPU 通过一项围绕底层图形和通用计算设计的 Web 标准，开放现代 GPU 的能力。

WebNN 面向的是另一层。它为 Web 应用提供基于计算图的接口，浏览器实现可以将其映射到底层平台的加速框架。这些框架包括 Core ML 和 Windows ML，具体取决于系统。

WebNN 规范仍在发展，浏览器可用性也依然有限。Google 称 Chrome 和 Edge 中的 WebNN 支持仍处于实验阶段，因此它更像是面向未来的组件，而不是通用的生产路径。

这正是 LiteRT.js 需要多个后端的原因。在受支持的系统上，WebGPU 可以提供广泛的 GPU 加速；WebNN 最终可以实现高效的 NPU 执行；而 WebAssembly 则能让应用在其他环境中继续运行。

对 Google 而言，这一时机也反映出其产品组合面临的问题。该公司已经拥有用于浏览器机器学习的 TensorFlow.js，以及用于原生边缘推理的 LiteRT。维护相互分离的优化路径，会让改进成果更难跨平台复用。

共享运行时提供了更直接的解决方案。模型转换、量化、算子改进和针对硬件的优化，都可以流向多个部署目标。

对于需要在移动应用和 Web 应用中维护同一 AI 功能的开发者而言，这一策略意义重大。共享 .tflite 产物并不能消除所有平台差异，但可以减少他们需要管理的模型格式和运行时假设。

对于正在评估敏感材料本地处理方案的企业而言，这同样重要。将推理保留在设备上可以减少发送到外部系统的数据，不过开发者仍需检查分析、日志记录、模型下载和应用代码。

构建本地知识工作流的团队也面临类似选择。可搜索的知识库可以使用本地模型执行嵌入或分类等任务，同时将更大的云端模型留给更复杂的推理工作。

相比将所有 AI 任务都迁移到浏览器，这种混合模式可能更现实。LiteRT.js 强化了这一架构中的本地侧，但并没有消除对服务器的需求。

现有 Web 推理运行时首先会感受到压力。它们必须在模型兼容性、执行速度、软件包大小、开发者工具，以及跨浏览器表现等方面展开竞争。

云端专属的应用架构也会承受压力。如果常见的感知、搜索和媒体任务能够在客户端硬件上达到可接受的运行效果，开发者就多了一种控制延迟和基础设施使用量的方式。

原生运行时挑战以 JavaScript 为先的 AI

LiteRT.js 通过统一运行时展开竞争，而成熟的替代方案则依靠模型生态和浏览器覆盖范围。

TensorFlow.js 仍然是最具代表性的历史参照。它让开发者能够通过 JavaScript 构建和执行机器学习模型，并提供包括 WebGL 和 WebAssembly 在内的后端。

Google 现在认为，LiteRT.js 为 .tflite 模型提供了更好的执行路径。该公司表示，早期的 TensorFlow.js 方法依赖效率较低的基于 JavaScript 的内核，而 LiteRT.js 则通过 WebAssembly 开放原生 LiteRT 优化能力。

这一表述并不意味着 TensorFlow.js 已经过时。TensorFlow.js 支持模型创建、训练、张量运算和成熟的 JavaScript API。目前，LiteRT.js 的定位则更集中于高性能推理运行时。

这一差异很重要。使用 TensorFlow.js 进行交互式训练或自定义张量运算的团队，与部署固定且经过优化的 .tflite 模型的团队，需求并不相同。

Google 提供了在现有 TensorFlow.js 流水线中使用 LiteRT.js 推理的指导。这表明两者可以在迁移期间共存，而不是立即替代 TensorFlow.js 的所有使用场景。

ONNX Runtime Web 构成了更直接的竞争对比。它已经支持通过 WebAssembly、WebGL、WebGPU 和 WebNN 执行提供程序，在浏览器中运行推理。

Web 推理指南介绍了本地运行的优势，包括更低的延迟、离线运行、隐私保护和减少服务器工作量。该指南也承认了核心限制：客户端模型必须适应能力较弱硬件的性能边界。

ONNX Runtime Web 使用 ONNX 模型，而 LiteRT.js 专注于 .tflite 产物。格式选择可能比基准测试结果更重要，因为企业往往已经拥有成熟的转换、验证和部署流水线。

以 PyTorch 为中心的团队可能已经将模型导出为 ONNX。使用 LiteRT 的移动团队则可能更偏好 .tflite，因为它与现有的 Android 和 iOS 部署工作保持一致。

加速覆盖范围同样复杂。ONNX Runtime Web 除 WebAssembly 和传统 WebGL 外，还记录了对 WebGPU 和 WebNN 的支持。LiteRT.js 则使用 WebGPU、WebNN，以及由 XNNPACK 支持的 CPU 路径。

因此，两种方案都认识到同一个基本现实：目前没有任何一种浏览器加速 API 能覆盖所有重要设备。

战略差异在于运行时基础。ONNX Runtime 围绕 ONNX 格式，将跨平台推理系统扩展到浏览器。Google 则围绕 LiteRT 和 .tflite，将其边缘运行时扩展到浏览器。

这并不是一个快速软件包与慢速软件包之间的简单竞争，而是部署生态之间的竞争。

Google 在这场竞争中拥有多项优势。LiteRT 已与其移动端和边缘计算工具链建立联系。Kaggle 提供预训练模型，LiteRT 社区也在 Hugging Face 上维护模型。Ultralytics 还为 YOLO 模型增加了 LiteRT 导出支持。

Ultralytics 的集成让计算机视觉团队获得了一条从模型工具链通向浏览器的具体路径。Google 的演示通过 LiteRT 技术栈运行 YOLO26——一个目标检测模型系列。

其他演示则让加速效果变得更加直观。其中一个使用 Depth Anything V2 和 WebGPU，将摄像头画面转换为三维点云；另一个运行 Real-ESRGAN，将 128×128 像素的图像块放大到 512×512 像素。

这些示例展示了本地执行能够明显改善交互体验的工作负载。用户希望摄像头深度估计或图像处理能够持续响应，而不是反复上传数据、等待服务器返回结果。

不过，演示往往是在经过筛选的环境中进行的。它们并不能证明同一个模型在主流手机和笔记本电脑上都能快速加载、保持较长续航并维持稳定帧率。

因此，开发者是否采用这项技术，将取决于具体的运行细节。团队需要可预测的模型转换、完善的算子覆盖、实用的错误信息、可控的包体积，以及性能分析工具。

他们还需要清晰的迁移路径。只有在团队能够复现模型输出，并在不付出过高工程成本的情况下接入预处理和后处理流程后，运行时性能才真正有意义。

对于现有 LiteRT 用户而言，Google LiteRT.js 高性能 Web AI 推理具备可信的优势。它面临的挑战在于证明：这套共享运行时能够带来足够多的收益，从而吸引那些已经投入 ONNX Runtime Web 或 TensorFlow.js 的团队。

性能声明遭遇浏览器现实

Google 的基准测试结果令人鼓舞，但硬件多样性和实验性 API 限制了开发者能够得出的结论。

Google 表示，在经典计算机视觉和音频处理模型的 CPU 与 GPU 推理测试中，LiteRT.js 的性能最高可达到其他 Web 运行时的三倍。

该公司还报告称，在部分测试中，通过 WebGPU 和 WebNN 使用 GPU 或 NPU 执行，相比标准 CPU 执行实现了 5 至 60 倍的加速。

这些说法需要明确适用边界。Google 在受控的浏览器环境中，使用搭载 Apple M4 芯片的 2024 款 MacBook Pro 运行了所公布的基准测试。

Google 明确指出，结果可能受到 GPU 能力、温度降频以及浏览器驱动优化程度的影响。这一限定对于评估此次发布至关重要。

高端 M4 笔记本为本地推理提供了有利环境。但许多 Web 用户使用的是较旧的笔记本电脑、价格低廉的手机、受企业管理的设备，或加速支持不同的浏览器。

Web 的优势在于广泛分发，但这种广泛分发也带来了测试难题。与面向受控设备群部署的原生应用相比，开发者很难针对某一种已知硬件进行同等程度的优化。

WebGPU 的可用性已经有所提升，但不同浏览器和操作系统之间的支持仍不均衡。因此，特性检测不可或缺。当 GPU 初始化失败或某项操作缺乏加速支持时，应用也需要提供可用的回退方案。

WebNN 面临更大的成熟度考验。Google 将其在 Chrome 和 Edge 中标记为实验性功能。WebNN 的价值主张十分突出，因为它能够将神经网络图映射到专用平台加速器，包括 NPU。

然而，实验性可用性意味着开发者不能将 WebNN 视为面向大众应用的默认路径。实现状态面板跟踪了 Chromium 及各平台后端的算子支持情况，说明相关支持仍在逐个算子地发展。

算子覆盖范围可能决定整个模型能否持续运行在加速器上。如果不受支持的算子触发错误，或导致更慢的回退执行，那么 headline 级别的加速数据可能无法反映完整应用的实际表现。

模型下载时间也构成另一项限制。本地推理可以避免反复请求服务器，但浏览器必须先获取模型权重和运行时文件。大型资源可能会推迟用户首次获得有效交互的时间。

缓存能够帮助回访用户，但存储策略和浏览器清理机制可能使这项收益并不稳定。移动网络环境也让初始载荷大小变得更加重要。

内存使用带来了相关问题。一个模型在较新的笔记本电脑上可能运行自如，但当浏览器、页面和其他标签页占用可用资源后，它可能会让手机不堪重负。

开发者还必须考虑主线程的响应能力。即使模型本身执行正确，繁重的预处理、张量传输或 CPU 回退也可能导致界面卡顿。

GPU 数据传输尤其值得关注。将输入从 CPU 内存发送到 GPU，再把输出传回来，可能会消耗一部分加速推理节省下来的延迟。

让中间张量驻留在 GPU 上的应用可以减少这些传输。这种方案需要谨慎的内存管理，以及避免不必要地将数据下载到 JavaScript 数组中的设计。

ONNX Runtime 的 WebGPU 文档通过支持驻留 GPU 的张量以及输入输出绑定，强调了同一个问题。不同运行时中都出现类似机制，说明内核速度只是应用性能的一个组成部分。

隐私声明同样需要精确表述。本地推理可以让原始输入留在设备上，但使用本地模型并不会自动让整个应用具备隐私性。

页面仍可能传输分析数据、错误日志、标识符、提示词或派生输出。开发者必须检查完整的数据流，而不能仅根据运行位置来推断隐私保护程度。

模型暴露则带来了相反的担忧。客户端应用必须将模型交付到用户设备，这会让模型权重比托管在服务器上的模型更容易被获取。

对于开放模型和常见的感知任务而言，这种权衡可能可以接受。但对于专有模型来说，情况可能不同，因为模型权重中包含有价值的数据或产品逻辑。

安全边界同样重要。在本地运行推理能够减少部分数据传输，但不受信任的 Web 内容、遭入侵的依赖项以及恶意模型文件仍可能带来其他风险。

因此，对 Google 性能证据最稳妥的解读应当是有限的：LiteRT.js 能够在受支持的硬件上显著加速部分模型，其原生运行时基础值得认真评估。

现有证据尚不能证明它能在公共 Web 环境中持续带来稳定收益。独立测试需要覆盖多种浏览器、操作系统、设备类别、模型系列和持续运行的工作负载。

对于工程团队而言，正确的基准测试对象是自己的应用。测试应包括模型下载、初始化、预热、预处理、推理、后处理、内存使用、电量消耗以及回退行为。

本地浏览器推理最适合的场景

当本地执行能够改善原本会受到网络延迟或重复数据传输影响的交互时，LiteRT.js 最具说服力。

实时计算机视觉是一个重要类别。目标检测、背景处理、手势识别和深度估计都可能需要持续分析摄像头帧。

将这些画面上传到服务器会增加带宽消耗和延迟，还会形成一条部分用户或组织无法接受的敏感数据流。

本地音频处理也具备类似优势。关键词检测、声音分类和有限的转录任务可以处理麦克风输入，而无需持续将录音发送到其他地方。

文档工作流是另一个实用类别。浏览器应用可以为本地文本生成嵌入、对文档进行分类，或在调用云端模型之前对段落进行排序。

这种安排支持分层架构：小型、高频任务在本地运行，而大型语言模型则处理需要更广泛知识或更多计算资源的请求。

图像处理同样适合这一模式。Google 的 Real-ESRGAN 演示在本地处理图像块，并在浏览器中重建放大后的图像。

其价值不只是降低延迟。本地处理可以避免上传源图像、等待服务器队列处理，以及下载结果。

支持离线的应用也会从中受益。现场工作人员、旅行者或学生在失去网络连接后，仍可以保留部分 AI 功能。

渐进式 Web 应用可以将缓存模型与本地存储和 service worker 结合起来。最终效果或许无法匹敌原生应用的全部能力，但能够通过一个 URL 提供实用的推理功能。

这些场景具有几个共同特征：模型足够小，能够在客户端硬件上运行；快速、重复执行能够带来明显收益；同时不依赖持续更新的服务器端知识。

大型生成式模型则更难处理。随着参数规模增长，模型大小、内存压力、生成 token 的速度和电量消耗都会变得更加突出。

Google 提到 LiteRT-LM.js 将支持浏览器中的语言模型，并将优化端侧生成式 AI 列为路线图重点。这一方向很重要，但不应成为人们对 LiteRT.js 初始版本的预期。

早期版本似乎更适合感知、嵌入以及其他边界明确的推理任务。这些工作负载与浏览器资源和成熟的量化技术更加匹配。

在本地 AI 成为默认选项之前，企业还需要建立治理机制。团队必须决定发布哪个模型版本、如何更新、哪些设备符合要求，以及回退行为将如何影响用户预期。

当推理发生在多种客户端硬件上时，监控也会变得更加复杂。服务器端系统能够集中暴露延迟和错误指标，而浏览器执行则需要经过审慎设计的遥测机制，且不能损害隐私目标。

质量保证必须同时覆盖数值输出和用户体验。量化模型运行更快、占用空间更少，但团队必须确认其准确率对特定数据而言仍处于可接受范围。

无障碍性也应纳入测试。消耗过多 CPU 资源的 AI 功能可能会干扰辅助技术，或降低旧设备上的响应速度。

对于产品团队而言，LiteRT.js 并不会消除这些决策。它提供了另一层执行环境，并与 Google 的原生边缘计算技术栈建立了更紧密的联系。

最好的采用策略可能是有选择地推进：先从一个边界明确的功能开始，在具有代表性的设备上衡量完整体验，并为不受支持的环境保留回退方案。

如果本地路径达到质量和响应速度目标，团队可以逐步扩大应用范围；如果达不到，同一个应用也可以将高负载任务转交服务器处理。

这种灵活性比笼统宣称浏览器应取代云端推理更有价值。LiteRT.js 让混合式设计更值得考虑，而具体工作负载仍将决定合理的边界。

三个信号将决定 LiteRT.js 的采用情况

下一阶段取决于浏览器支持、独立性能测试结果，以及开发者能否将真实应用迁移到这套运行时的实际证据。

第一个信号是 WebNN 能否从实验性访问逐步走向浏览器的常规可用功能。专用 NPU 执行是 LiteRT.js 最有吸引力的承诺之一，因为它有望改善延迟和能效。

更广泛的 WebNN 支持将强化 Google 关于统一运行时的论点。如果仍然依赖标志位或受限平台，那么大多数生产工作负载仍将由 WebGPU 和 WebAssembly 承担。

第二个信号是独立基准测试。测试应在具有代表性的笔记本电脑、手机和浏览器上，针对不同模型类型，对比 LiteRT.js、ONNX Runtime Web 与 TensorFlow.js 的表现。

如果在 Google 的 M4 测试环境之外也能取得稳定优势，将进一步支持其高性能 Web AI 推理的定位。表现差异过大、不支持的算子过多，或初始化成本高昂，都会缩小适用场景范围。

第三个信号是从演示走向生产环境的实际采用情况。应关注是否有团队将 LiteRT.js 用于相机工具、媒体应用、私密搜索和离线工作流，并真正上线交付。

Ultralytics 导出支持是一个有价值的起点，因为它将广泛使用的视觉生态与 LiteRT 部署连接起来。更有力的验证将来自开发者对转换成功率、打包开销、设备覆盖范围以及可量化用户收益的记录。

Google 还必须明确 LiteRT.js 与 TensorFlow.js 随着时间推移如何划分职责。随着 Google 整合其边缘计算工具链，开发者需要确信，当前的架构未来仍将得到支持。

此次发布为 Google 带来了一个以原生边缘基础设施为核心、可信度较高的浏览器运行时。但这并未终结 Web 推理领域的竞争，因为 ONNX Runtime Web 已经支持类似的后端，同时服务于不同的模型生态。

对开发者而言，眼下最实际的做法是：选择一个具有代表性的模型，分别测试加速路径和 CPU 路径，然后衡量完整的用户体验链路。只有当 Google LiteRT.js 的高性能 Web AI 推理能力经受住真实设备、真实浏览器和真实应用约束的考验时，它才会真正产生重大影响。