每当有人谈论在浏览器中运行人工智能时，话题很快就会转向一个非常具体的工程问题：在带有 GPU 的服务器上用 Python 训练的模型如何最终进入 Chrome 选项卡并运行得足够快以发挥作用？答案不是单一产品。它是由三部分组合在一起组成的堆栈，了解它们如何组合在一起是将可靠的架构决策与在原型中夭折的实验区分开来的关键。
这三部分是形状、引擎和加速层。格式为 ONNX。该引擎是 ONNX Runtime Web。加速层是WebNN。每个人都解决不同的问题，有趣的是它们如何组合在一起。
格式：ONNX 作为公分母
模型诞生于不同的框架中。一个团队使用 PyTorch 进行训练，另一个团队使用 TensorFlow 进行训练，另一个团队则使用自己的工具进行训练。每个框架都以自己的方式存储模型，当您想要将模型移出其创建的环境时，这会变得很痛苦。
ONNX 代表开放神经网络交换，是一种旨在成为这一共同点的开放格式。您可以在任何地方进行训练并导出到 ONNX。该模型现在以标准化方式描述，独立于源框架，任何兼容工具都可以读取。
对于那些决定架构的人来说，ONNX 的价值在于解耦。您对培训框架的选择不再与您对执行环境的选择联系在一起。在一个地方训练，在另一个地方跑步，两者之间的格式确保了桥梁的存在。从最好的意义上来说，这是无聊的基础设施：当它工作时你不会想到它。
引擎：ONNX Runtime Web 在浏览器中运行
在 ONNX 中拥有模型还不够。有人需要加载这个文件，解释它描述的操作序列，并实际进行数学计算。这就是推理运行时的工作。
ONNX Runtime Web 是该运行时在浏览器中运行的版本。它采用 ONNX 模型并使用 Web 平台提供的资源在客户端上运行。从历史上看，这意味着两条路线：[WebAssembly0，它在 CPU 上运行，具有不错的性能；WebGL，它通过浏览器的图形 API 利用 GPU。
这些路线有效，但也有局限性。 [CPU 上的 WebAssembly1 便携且可靠，但不是大型模型的最快方法。 WebGL 使用 GPU，但是间接使用 GPU，因为它是用来渲染图形的，而不是运行神经网络的。这就是堆栈的第三部分发挥作用的地方，即改变性能上限的部分。
加速：WebNN 和访问正确的硬件
WebNN，即Web神经网络API，是一种让浏览器可以直接访问设备的AI加速硬件的API。它不使用图形 API 作为中介，而是与设备上最合适的设备进行交互：CPU、GPU 或 NPU（如果可用）。
NPU值得关注。它是神经处理单元，是一块专门用于神经网络操作的硅块，经常出现在现代手机和笔记本电脑中。与通用 CPU 或 GPU 相比，它执行推理时功耗更低、效率更高。问题是，在 WebNN 出现之前，浏览器根本没有办法与之对话。 NPU 就在那里，闲置着，对网络来说是不可见的。
ONNX Runtime Web 可以使用 WebNN 作为其执行路径之一。当这种情况发生时，引擎会将繁重的工作委托给知道如何驱动可用的最佳硬件的层。 ONNX 模型保持不变。改变的是它在下面运行的位置和方式，在性能和能源效率上实现了旧路线无法实现的飞跃。在实践中，这种增益使得[浏览器中的本地推理2]对于以前只在服务器上有意义的模型来说是可行的。
整个堆栈，从一端到另一端
将各个部分组合成一个单一的思维流程是值得的。模型可以在服务器上的任何框架中使用整个训练基础设施进行训练。然后将其导出到 ONNX，获得标准化和可移植的表示形式。该文件将传送到浏览器，ONNX Runtime Web 会在浏览器中加载并运行该文件。并且，当环境允许时，运行时会触发 WebNN，以便帐户在用户设备的 CPU、GPU 或 NPU 上运行。
该链的结果是完全在客户端上发生的推理。数据不需要传输到服务器，这对于隐私很重要。没有请求会产生云计算成本，这对月底的账单很重要。用户的操作和模型的响应之间不存在网络延迟，这对于体验很重要。
将其添加到模型量化中，从而将 ONNX 缩小到合理的下载大小，最终使浏览器内的 AI 在产品中（而不仅仅是演示）中具有防御性。
你需要遵守的限制
这是区分热情和责任的部分。 WebNN 还不是一个成熟稳定的技术。在W3C，它处于候选推荐阶段，也就是说，它是一个高级规范，但尚未最终确定为统一标准。这意味着细节可能会改变。
实际支持参差不齐。 WebNN 的 GPU 和 NPU 在大多数浏览器中加速执行都处于预览阶段或处于实验阶段。它在受控环境中以特定版本和特定配置运行。您不能在真实用户的设备和浏览器上统一依赖它。
因此，建议是直接且不浪漫的：暂时不要将 WebNN 作为关键的生产依赖项。用于原型、概念验证以及在加速不可用时优雅降级的可选功能。当无法触发硬件加速时，始终有一个后备路径，通常是 [CPU 上的 WebAssembly4]。将候选推荐中的规范视为稳定的基础设施是一种经不起考验的赌注。
如何考虑这个决定
对于架构设计人员来说，ONNX 堆栈加上 ONNX Runtime Web 加上 WebNN 是明智的中期选择，而不是今天的基础。 ONNX 格式和 ONNX Runtime Web 已经足够坚固，适合实际使用，包括传统的 CPU 和 GPU 路线。 WebNN 层是性能的未来，但这个未来仍在到来。
诚实的阅读意味着将已经准备好的东西与尚未成熟的东西分开。采用 ONNX 作为一种格式，无需担心，它为您提供当今的可移植性。在客户端推理有意义的情况下使用 ONNX Runtime Web，依靠 WebAssembly 作为可信基础。并将 WebNN 视为渐进式优化：当它可用且稳定时，它会加速；当它可用且稳定时，它会加速；当它可用时，它会加速。如果没有，您的产品将继续工作。这种立场非常符合[2026 年网络开发5] 的成熟预期，尖端资源建立在从不依赖它们的基础之上。
如果您正在构建客户端 AI 策略，谨慎的做法是现在构建在 ONNX 和 ONNX Runtime Web 之上，并提供可靠的后备，并跟踪 WebNN 的演变，以便在其成熟时开启加速。从稳定的事情开始，为即将发生的事情留出空间。
另请阅读
- [WebNN：为浏览器带来硬件加速的 API6
- [浏览器中的人工智能：为什么要在用户设备上运行推理7?
- [量化模型：在浏览器中运行人工智能的关键8
- [端侧AI：服务器与端侧的战略决策9
- [软件开发中的人工智能代理：采用治理10
- [反AI Slop：为什么人类内容的需求不断增长11