浏览器端设备上 AI 的现状

在浏览器中直接运行 AI 听起来很简单,但当你真正尝试部署时就会发现并非如此。API 碎片化严重,硬件要求差异巨大,在一台设备上正常工作的功能在另一台设备上可能会悄无声息地失败。在你接入第一个推理调用之前,了解实际可用的技术、各层如何协同工作,以及 2026 年初真正存在的差距,会对你有所帮助。

三个不同的层次,而非单一事物

浏览器端设备上 AI 最大的混淆来源是将所有方法视为可互换的。事实并非如此。存在三个不同的层次,为你的用例选择错误的层次会造成实际问题。

第一层:浏览器提供的 AI API

Chrome 提供内置 AI API,由其直接在浏览器中提供和管理的模型(包括 Gemini Nano)支持。如 Chrome 内置 AI 文档所述,这些模型由 Chrome 自身下载和处理。Chrome 已在稳定版本中提供了 Summarizer、Translator 和 Language Detector 等 API,而其他 API 仍较为受限。Prompt API 在 Chrome 扩展中是稳定的,但网页使用仍处于实验阶段或基于 origin-trial。Writer 和 Rewriter 也不应被视为普遍可用于生产环境的功能。

Microsoft Edge 采用类似方法,使用 Phi-4-mini 并公开自己的 API 接口。该模型直接内置于浏览器中,可通过 Prompt API 等 API 访问,该 API 目前在 Edge Canary 和 Dev 版本中以开发者预览形式提供。然而,这些 API 仍处于实验阶段,尚未在生产环境中广泛可用。Firefox 具有聊天机器人集成和 Smart Window 实验等 AI 功能,但目前没有为 Web 开发者公开类似 Chrome 风格的内置 AI API 接口。

吸引力显而易见:无需托管模型,无打包体积成本,设置最少。缺点同样明显:你被绑定到特定的浏览器实现,模型是固定的,你无法控制运行的版本。这些 API 还要求首先下载模型,模型可能很大且异步下载。你需要妥善处理这一点。

// 使用内置浏览器 AI API 前进行特性检测
if ('Summarizer' in self) {
  const availability = await Summarizer.availability();

  if (availability !== 'unavailable') {
    const summarizer = await Summarizer.create();
    const summary = await summarizer.summarize(articleText);
  }
} else {
  // 回退到云端或跳过该功能
}

第二层:使用 Transformers.js 和 ONNX Runtime Web 进行基于 JavaScript 的推理

如果你需要更广泛的浏览器支持或想选择自己的模型,Transformers.js 是目前最实用的选项之一。它使用 ONNX 格式直接在浏览器中运行 Hugging Face 模型,在可用时可以使用 WebGPU 加速,在支持的地方回退到 WebAssembly。

ONNX Runtime Web 为你提供类似的覆盖范围,并对执行提供者有更多控制。两者都是分类、翻译、情感分析、嵌入和轻量级文本生成任务的合理选择。

请注意,Transformers.js v3 迁移到了 @huggingface/transformers 包。下面显示的 @xenova/transformers 导入适用于 v2,该版本在现有项目中仍然常见:

// Transformers.js v2
import { pipeline } from '@xenova/transformers';

// Transformers.js v3+
// import { pipeline } from '@huggingface/transformers';

const classifier = await pipeline('sentiment-analysis');
const result = await classifier('This article is genuinely useful.');

模型大小是主要限制因素。适合浏览器推理的量化模型可能从几十兆字节到几百兆字节不等,具体取决于任务。如果没有通过 IndexedDB 或 Cache API 进行仔细的缓存,较大的模型会变得不切实际。

第三层:WebGPU 和 WebAssembly 作为加速原语

WebGPU 和 WebAssembly 不是 AI API。它们是低级原语,Transformers.js、ONNX Runtime Web 和 TensorFlow.js 等框架可以在内部使用它们来更快地运行推理。除非你正在构建框架或进行自定义计算工作,否则很少直接与它们交互。

WebGPU 特别为矩阵运算解锁了有意义的 GPU 加速,这对于超出微型模型的任何任务都很重要。支持比以前广泛得多,但仍需要特性检测,因为浏览器、操作系统、设备、驱动程序和移动支持各不相同。

WebNN 为整体图景增添了什么

WebNN(Web Neural Network API)是一个 W3C API,旨在通过一致的浏览器接口公开硬件加速的神经网络操作,包括在支持的设备上访问 NPU。它位于你的框架和硬件之间,很像 WebGPU,但专门为机器学习工作负载设计。

2026 年初的浏览器支持有限。Chrome 有部分实现,其他浏览器的更广泛支持仍在进行中。ONNX Runtime Web 等框架已经将 WebNN 添加为执行后端,因此你可能会在直接使用它之前间接受益。

真实的权衡

隐私优势是真实的,但有条件。本地推理意味着输入数据在处理期间不会离开设备,但网站仍然可以在数据到达模型之前记录用户输入的内容。“本地”并不自动意味着端到端私密。

离线能力同样有条件。一旦模型被缓存,推理可以在没有连接的情况下工作。但初始下载需要连接,模型更新也需要重新连接。

混合模式是现实的默认选择

大多数生产应用不会完全采用设备上推理。实际模式是尝试本地推理,检查 API 可用性和硬件能力,然后在任一缺失时回退到云端点。这为有能力的设备提供更快、更私密的体验,而不会破坏其他人的功能。

结论

浏览器端设备上 AI 对于特定的、有界的任务确实有用:总结文档、检测语言、分类短文本、生成嵌入或运行轻量级助手。浏览器中的完整 LLM 级别体验仍然不一致且依赖硬件。为现实的中间地带构建,你就能交付真正可用的东西。

常见问题

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.