WebNN：浏览器怎样把神经网络交给 NPU 和 GPU？

如果把 WebGPU 比作“浏览器里的通用 GPU 计算接口”，那么 WebNN 更像“浏览器里的神经网络执行接口”。前者给开发者更底层的自由，后者试图让网页用统一的方式描述神经网络图，再交给操作系统和硬件选择合适的后端。

这件事重要，是因为端侧 AI 的瓶颈不只在模型大小，还在于网页怎样稳定地调用不同设备上的 GPU、NPU、CPU 和专用加速器。

先给结论：WebNN 负责描述“要做什么推理”

W3C 将 WebNN 定义为面向神经网络推理硬件加速的低层 API。当前规范仍是 Candidate Recommendation Draft，不能当成已经冻结的最终标准；但它已经围绕 Transformer 支持、张量缓冲区共享、设备选择和跨平台实现持续演进。W3C WebNN 规范

WebNN 的核心分工可以这样理解：

• 网页或上层运行时描述模型需要的算子和数据形状；
• WebNN 把这些操作组织成计算图；
• 浏览器和操作系统决定如何映射到可用硬件；
• 硬件后端完成实际推理。

网页代码不必针对每一台设备手写一套 NPU 指令，也不必把“如何调度 GPU”全部暴露给业务层。

为什么不直接全部使用 WebGPU

WebGPU 很强，但它给的是更通用、更底层的计算能力。开发者需要处理着色器、内存布局、同步、数据类型和算子拼接。对于游戏、图像处理或自定义张量运算，这种自由很有价值；对于标准模型推理，它也意味着更多工程负担。

WebNN 试图提供更接近模型推理的抽象：开发者关心的是卷积、矩阵乘法、归一化、激活函数或注意力相关算子如何组合，而不是每个线程组怎样交换数据。

两者的关系不是“谁淘汰谁”：

一次 WebNN 推理发生了什么

可以把典型流程简化成四步：

这里最容易被忽略的是“模型文件不是计算图本身”。ONNX、TensorFlow Lite 或其他格式只是模型的表达方式。网页还需要一个运行时或转换层，把模型算子映射为 WebNN 可以表达的图，并处理权重加载、输入归一化和输出后处理。

如果模型包含 WebNN 尚未覆盖的算子，整个图可能无法直接执行。实践中常见的方案是：让 WebNN 负责大部分标准算子，把少数特殊操作交给 JavaScript、WebAssembly 或 WebGPU；也可以在模型转换阶段改写网络结构。

硬件加速不是免费的魔法

“交给 NPU”听起来一定更快，但真实速度取决于多个因素：

1. 设备是否真的有可用的加速后端；
2. 模型算子是否能完整落到该后端；
3. 数据在 JavaScript、WebNN 和硬件之间搬运了几次；
4. 模型加载和权重初始化的成本有多大；
5. 单次推理是否足够大，能否摊薄调度开销。

对于一个很小的文本分类模型，调用加速器的准备成本可能比计算本身还高。对于连续图像处理、语音特征提取或端侧视觉模型，硬件后端才更可能体现优势。

安全与隐私边界也要一起设计

WebNN 直接接触设备能力，因此规范需要考虑指纹识别、跨源访问和权限边界。当前规范明确讨论了跨源 frame 的 Permissions Policy，并默认限制某些跨源使用场景，以减少第三方内容未经授权调用能力的风险。WebNN 安全相关章节

本地推理也不代表“网页看不到数据”。页面脚本仍然可以读取用户输入；模型推理的输出仍可能被上传；硬件加速器的执行时间也可能暴露侧信道信息。安全模型需要同时看浏览器权限、页面来源和应用自己的数据处理逻辑。

现在适合用 WebNN 吗

如果你的产品需要今天就覆盖大量浏览器，WebNN 仍然更适合作为渐进增强，而不是唯一后端。可以准备三条路径：WebNN、WebGPU/WebAssembly，以及服务端推理。

如果你的目标是研究端侧推理、设计跨设备运行时，或者希望提前理解浏览器如何连接 NPU，WebNN 值得关注。它真正解决的不是“让网页调用 AI”这一句话，而是把神经网络计算从某个浏览器实现，逐步变成可以讨论、测试和互操作的 Web 平台能力。

一句话总结：WebNN 试图让网页描述神经网络，而不是描述每一块 GPU 应该怎样工作。

来源

• W3C：Web Neural Network API
• WebNN 规范历史与实现状态