LiteRT.js:在浏览器里跑本地 AI,并给出明确的备选路径
LiteRT.js 通过 WebAssembly 和可用的加速把推理带进浏览器。可靠的设计会检测能力、实测设备,并声明一条备选路径。

简短回答
LiteRT.js 让兼容模型可以通过 WebAssembly 和 WebGPU 等路径在浏览器里运行。本地推理可以避免把输入发往服务器,但它并不保证隐私,也不保证性能;请检测能力、在真实设备上测量,并提供一条能被理解的备选路径。
可靠本地推理的四个决定
体验并不是从模型开始运行才开始。先检测,再加载,测量执行过程,并在需要时启用备选路径。
检测
在下载模型之前检查接口、内存和必要条件。
加载
选择与当前设备兼容的模型和执行路径。
运行
用有代表性的输入测量耗时、内存和质量。
备选
说明限制并提供另一条路径,不隐瞒任何数据传输。
LiteRT.js 是 Google 用于在浏览器中运行人工智能(AI)推理的接口。它可以在中央处理器(CPU)上使用 WebAssembly,并在存在兼容加速时使用 WebGPU。设计从一开始就必须考虑那些覆盖不了首选路径的设备。
我们的案例是在上传之前评估一张照片的质量。本地模型会检测模糊或曝光不足,并给出一条建议。如果浏览器无法运行这个模型,应用会说明限制并提供另一条路径。
LiteRT.js 把模型带到设备上
截至 2026 年 7 月 15 日,Google 把 LiteRT.js 记录为一个用于加载并运行兼容模型的网页运行时。入门指南展示了加载与编译接口,以及一条由 WebGPU 加速的路径。实际兼容性取决于浏览器、硬件和模型。
在设备上运行,可以减少推理过程中的网络往返。当应用和模型都已就位时,它也能在连接不稳定的情况下给出结果。但这并不能消除下载、编译和内存上的开销。
在选用之前,先想清楚它给照片这个场景带来了什么。上传前的一条即时提醒,可以省下一次无用的上传,并把图片留在服务器之外。只有当页面的其他部分同样不传输这张照片时,这个优势才成立。
检测先于下载
在下载一个大模型之前先检查能力。 检测所需接口,在可行时读取可用内存,并考虑设备类型。在决定路径的这段时间里,界面必须保持可用。
对于照片场景,先显示选择器和一段简短说明。如果浏览器满足条件,就带着可见进度开始加载模型。如果不满足,就提供一次可选的远程评估,或者允许直接跳过分析继续。
不要只靠浏览器名称来做检测。 同一个系列内部,版本、驱动和策略都可能不同。请执行一次能力探测,并捕获初始化错误。
加载需要清晰的状态和上限
模型会给整条流程增加体积、启动时间和内存占用。请告知用户本地分析正在准备,并在下载缓慢时允许取消。只有当产品策略和可用存储都允许时才做缓存。
进度条走满并不代表模型已经就绪。 请区分下载、编译和第一次推理。在这个案例里,只有确认本地路径能对一次测试输入作出响应之后,才启用「分析照片」。
设定一个最长等待时间和一条恢复路径。如果编译失败,就释放资源并启用备选路径。一个静默的重试循环会耗电,也会让用户始终得不到一个决定。
质量要用有代表性的照片来衡量
准备一批测试图片:清晰的、模糊的、光线不足的,以及不同尺寸的。把模型输出与人工复核过的分类做对比,并记录重要的错误。只用一张照片做演示,无法评估行为。
同时测量首个结果的耗时、后续延迟、内存,以及长时间使用中的机身发热。要包含中端手机、一台没有 WebGPU 的设备和几款有代表性的浏览器。厂商的基准可以作为参照,但不能当作你产品的验收标准。
如果分析判定一张照片模糊,就说明可以怎么做:稳住设备、改善光线或重拍。一个没有上下文的分数没有帮助。提示词指南遵循的是同一条「结果可验证」的原则。
隐私取决于整条流程
本地推理说明的是模型在哪里运行,而不是应用做的全部事情。分析统计、错误日志、存储、缩略图或备份服务都可能发送数据。 在声称图片留在设备上之前,先记录每一次网络外发。
在选择、分析和放弃这三个阶段检查网络请求。用远程备选路径再测一遍,并在上传前展示一次同意请求。文案必须把两条路径清楚区分开。
避免记录图片本身、从中提取的内容,或不必要的标识符。 如果确实需要埋点,就只测量耗时和状态码,不要附带个人数据。用户拒绝备选路径之后,必须仍然能继续使用。
备选路径也是产品的一部分
备选路径不是需要藏起来的丢人错误。请说明本地分析在这台设备上不可用,并给出具体选项:不做评估继续、在同意后使用服务器,或者换一张图片。只要安全,就保住主要功能。
远程备选路径需要自己的保留、访问和删除规则。不要在后台悄悄启用它。 负责任的 vibe coding 方式要求主路径和降级路径都要测试。
记录有多少会话走了哪条路径,以及本地路径失败的原因。这些证据能帮你判断是该换模型、缩小模型,还是撤掉这个功能。不要在没有日期和代表性样本的情况下,把一个百分比变成承诺。
限制体现在下载、内存和兼容性上
一个模型可能对移动网络来说太大,或者在多次推理后耗尽内存。WebGPU 可能存在,却仍在编译某个算子时失败。请把这两种情况都捕获,并把界面恢复到可用状态。
质量也可能在评估集之外的图片群体上出现波动。请复核不同光照、设备和场景。一个错误的本地结果,依然是一个错误的结果。
最后,浏览器要和页面其余部分共享资源。避免同时跑多次推理,并释放不再使用的张量或会话。 一个流畅的界面,和单次推理的数字同样重要。
发布前检查这段体验
在多台设备上走一遍下面这些勾选项。每个回答都必须基于一次测量、一次网络检查或一个可见行为。
- 应用在下载模型之前检测了能力。
- 加载、编译、运行和错误都有可理解的状态。
- 测试照片覆盖了不同质量、尺寸和设备。
- 完整的数据流向(含埋点)都已记录。
- 远程备选路径需要明确的告知和同意。
- 一次失败会释放资源,并让用户安全地继续。
LiteRT.js 为本地 AI 打开了一条有用的路径,但可靠的架构同样要照顾那台用不了它的设备。检测、加载、运行、测量,并启用一条声明清楚的备选路径。 这个顺序把一次演示,变成一个可维护的功能。
小测验
设计完整的本地流程
选出那个让数据、能力和限制都保持可见的选项。
1 / 3
显示答案
1. 设备无法加载模型时,应用应该怎么做?
正确答案: 说明限制,并提供一条经用户同意的备选路径。
声明清楚的备选路径保住了对数据流向的控制,也避免了一次无从理解的失败。
2. 你如何为一句隐私声明提供依据?
正确答案: 记录推理、分析统计、日志和外部调用。
隐私取决于整条数据流,而不只是模型在哪里运行。
3. 哪种验证最有助于判断能否上线?
正确答案: 用真实测试照片测量有代表性的设备。
一张设备矩阵能揭示下载量、内存、质量和备选路径的触发频率。
来源
- LiteRT.js: Google's high-performance web AI inference runtimeGoogle for Developers · 访问于 2026-07-15
- Get started with LiteRT.jsGoogle AI for Developers · 访问于 2026-07-15
常见问题
LiteRT.js 可以离线工作吗?
当应用、模型和资源已经在本地可用时,推理可以在没有网络的情况下运行。具体行为取决于缓存策略,以及页面使用的其他服务。
本地 AI 能保证隐私吗?
不能。它可以避免把输入发给推理服务器,但分析统计、日志、图片上传或辅助接口仍可能传输数据。
WebGPU 在所有设备上都能用吗?
不能。兼容性和性能各不相同。请检测能力,并准备一条 CPU 路径或一条已告知用户的远程备选路径。
发布前应该测量什么?
下载体积、启动时间、每次推理的延迟、内存、结果质量、耗电,以及备选路径的使用比例。

