WebNN 走到哪了？—— 2026 年中一份个人观察

去年跟朋友聊浏览器里的 AI 推理，十个人有九个会说"WebGPU 勉强跑跑小模型"。WebNN？那是个什么，W3C 社区组的玩具罢了。

今年情况变了。

2026 年 1 月 22 日，W3C 发布了 Web Neural Network API 的更新版 Candidate Recommendation Snapshot。CR 阶段是什么意思？标准的核心设计已经冻结，不会再大改。剩下的工作不是"做什么"，而是"谁能证明自己做得到"。

W3C 要求两个独立的、可互操作的浏览器实现，加上公开可验证的测试套件，然后才能进入 Proposed Recommendation。换言之，WebNN 现在进入了出题人让考生交卷的阶段。

从"玩具"到"真的能用"：2025-2026 加了什么

我翻了一遍 Changelog，真正让我觉得 WebNN 不再是个 placeholder 的，是下面这 6 项。

Transformer 算子支持。 这是最大的变化。以前 WebNN 的算子集基本停留在 2019 年之前的 CV 模型视野——卷积、池化、全连接，够用但不够有趣。现在加了 attention、quantizeLinear/dequantizeLinear，意味着你可以在浏览器里跑量化后的 Transformer 模型了。不是玩具 Demo，是真的能跑出有意义结果的推理。

MLTensor API。 WebNN 和 WebGPU 之间现在可以共享缓冲区，不用来回拷贝数据。这件事的意义比听起来大——浏览器里跑模型最大的开销不是计算，是内存搬运。一张 7B 模型的中间张量在 JS heap 和 GPU buffer 之间倒腾几轮，性能就崩了。MLTensor 把这条路打通了。

加速器选择。 你现在可以显式指定后端：GPU、NPU、CPU。不再依赖平台的"最佳猜测"。这对调试和性能调优来说，就是从一个黑盒变成了一个可配置的引擎。

Worker 支持。 Shared Worker 和 Service Worker 里也能跑推理了。以前 WebNN（以及 WebGPU）的上下文绑定在主页面，页面一切换就丢。现在可以放后台线程跑，意味着你可以在一个 Tab 里做推理，另一个 Tab 正常浏览，不影响。

上下文丢失处理。 GPU/NPU 崩溃后的恢复行为有了明确定义。这不是性能特性，是工程成熟度的标志——一个 API 只有到了"我们得考虑出错了怎么办"的阶段，才算正经东西。

算子标签。 给算子加诊断标签，方便调试。小功能，但说明 API 的设计者开始考虑开发体验了。

浏览器这边：Chrome 跑在前面，其他人还在热身

现实层面，WebNN 的落地情况是这样的：

Chrome / Edge：实现最完整，通过了大量 WPT（Web Platform Tests）测试。 Chromium 团队在 WebNN 上的投入是认真的——这跟他们在 WebGPU 上的策略一致，先把标准吃透，把测试跑通，再推给用户。

后端覆盖也还行：Windows 上走 DirectML，macOS/iOS 用 CoreML，Android 调 NNAPI，Intel 平台还能走 OpenVINO。基本覆盖了主流硬件。

Safari / Firefox：跟进慢。 这不是新闻。Apple 对 Web 标准的投入节奏一向保守，WebGPU 也拖了很久。Firefox 团队资源有限，优先级排不过来。坦白说，短时间内别指望跨浏览器一致性。

这对实际使用意味着什么？如果你的目标用户是 Chrome 用户（在国内，很多人确实只用 Chrome 或 Chromium 内核浏览器），现在就可以开始试。如果要做跨浏览器的产品，还得等。

现在能做什么

WebNN 目前的实际能力已经超过了"概念验证"阶段：

• 浏览器内跑 Stable Diffusion。 不是慢得不能用的那种，是真的可以生成像样图片的。
• 本地 Transformer 推理。 DistilBERT、小型 LLM 都没问题。我试过几个 Demo，延迟在可接受范围内。
• 实时视频分析、语音转文字。 这些本来就需要硬件加速，WebNN 提供了比 WebGPU 更专门的路径。
• WebGPU 作为后备。 当 WebNN 不可用时自动降级到 WebGPU，对开发者来说是个低风险的渐进增强策略。

想上手的话，Chrome Canary 或 Edge 已经支持了大部分 API，可以从 webnn.io 的示例开始。

什么时候"真正能用"？

这个问题得分两层看。

标准层面，已经成熟。 核心设计冻结了，不会有大改。厂商实现和互操作测试是目前的主线剧情。

生态层面，还得等等。 模型转换工具链（ONNX → WebNN）还在完善。你想把一个 PyTorch 模型跑在浏览器里，中间要经过 ONNX 导出 → 算子兼容性检查 → WebNN 格式转换，每一步都可能踩坑。大模型（7B+）在浏览器内的内存和性能瓶颈也还没解决——这不是 API 的问题，是浏览器沙箱本身的内存限制。

Safari 和 Firefox 的滞后意味着，如果你想做一个需要跨浏览器一致性的产品，现在还不是时候。

我的判断：2026 年底到 2027 年初，WebNN 会达到"生产可用"的水位。 前提是 Chrome 继续当前的投入节奏，至少再来一个浏览器厂商（大概率是 Firefox，Safari 我不抱太大期望）跟上。

一个更有趣的问题

整件事最让我觉得有意思的，不是 WebNN 本身，而是 Transformer 算子的加入让它第一次真正对 LLM 推理有用。

这意味着浏览器正在从一个"渲染引擎"变成一个"AI 运行时"。以前我们说"浏览器是新的操作系统"，更多是比喻。现在 WebGPU + WebAssembly + WebNN 的组合，让这个比喻越来越不像是比喻了。

如果这个趋势成立，一两年后，前端工程师要关心的不只是 DOM 和 CSS，还有量化精度、KV Cache 和上下文窗口。这个转型会不会发生，我不知道。但这个方向，值得盯着看。

步子哥，2026.06. 上海