[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fWc7yNBft0REKCtUzOPkfIZXo4q2gpq8uzeZuWNPepxI":3},{"item":4,"related":51},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":39,"sourceName":40,"sourceUrl":41,"status":42,"seoTitle":43,"seoDescription":44,"canonicalUrl":45,"isFeatured":46,"sno":47,"sortOrder":48,"publishedAt":49,"updatedAt":50,"createdAt":50},"71cf5ad9-a09c-4394-9d76-5f39fea0e4ef","article","WebNN：浏览器怎样把神经网络交给 NPU 和 GPU？","webnn-neural-network-inference-browser","WebGPU 提供通用 GPU 计算，WebNN 则试图让网页用统一方式描述神经网络，并交给浏览器和操作系统选择 CPU、GPU 或 NPU 后端。本文解释 WebNN 的计算图、硬件加速、隐私边界和渐进增强策略。","如果把 WebGPU 比作“浏览器里的通用 GPU 计算接口”，那么 WebNN 更像“浏览器里的神经网络执行接口”。前者给开发者更底层的自由，后者试图让网页用统一的方式描述神经网络图，再交给操作系统和硬件选择合适的后端。\n\n这件事重要，是因为端侧 AI 的瓶颈不只在模型大小，还在于网页怎样稳定地调用不同设备上的 GPU、NPU、CPU 和专用加速器。\n\n## 先给结论：WebNN 负责描述“要做什么推理”\n\nW3C 将 WebNN 定义为面向神经网络推理硬件加速的低层 API。当前规范仍是 Candidate Recommendation Draft，不能当成已经冻结的最终标准；但它已经围绕 Transformer 支持、张量缓冲区共享、设备选择和跨平台实现持续演进。[W3C WebNN 规范](https:\u002F\u002Fwww.w3.org\u002FTR\u002Fwebnn\u002F)\n\nWebNN 的核心分工可以这样理解：\n\n- 网页或上层运行时描述模型需要的算子和数据形状；\n- WebNN 把这些操作组织成计算图；\n- 浏览器和操作系统决定如何映射到可用硬件；\n- 硬件后端完成实际推理。\n\n网页代码不必针对每一台设备手写一套 NPU 指令，也不必把“如何调度 GPU”全部暴露给业务层。\n\n## 为什么不直接全部使用 WebGPU\n\nWebGPU 很强，但它给的是更通用、更底层的计算能力。开发者需要处理着色器、内存布局、同步、数据类型和算子拼接。对于游戏、图像处理或自定义张量运算，这种自由很有价值；对于标准模型推理，它也意味着更多工程负担。\n\nWebNN 试图提供更接近模型推理的抽象：开发者关心的是卷积、矩阵乘法、归一化、激活函数或注意力相关算子如何组合，而不是每个线程组怎样交换数据。\n\n两者的关系不是“谁淘汰谁”：\n\n| 需求 | 更适合的方向 |\n| --- | --- |\n| 自定义 GPU 算法、图像滤镜、粒子系统 | WebGPU |\n| 运行标准神经网络图 | WebNN |\n| 需要极致控制内存和算子实现 | WebGPU 或原生后端 |\n| 希望在多类设备上复用推理逻辑 | WebNN 更有吸引力 |\n\n## 一次 WebNN 推理发生了什么\n\n可以把典型流程简化成四步：\n\n```mermaid\nflowchart LR\n    A[模型文件] --> B[转换为可执行计算图]\n    B --> C[创建 MLContext]\n    C --> D[选择 CPU\u002FGPU\u002FNPU 后端]\n    D --> E[输入张量]\n    E --> F[执行推理]\n    F --> G[输出张量]\n```\n\n这里最容易被忽略的是“模型文件不是计算图本身”。ONNX、TensorFlow Lite 或其他格式只是模型的表达方式。网页还需要一个运行时或转换层，把模型算子映射为 WebNN 可以表达的图，并处理权重加载、输入归一化和输出后处理。\n\n如果模型包含 WebNN 尚未覆盖的算子，整个图可能无法直接执行。实践中常见的方案是：让 WebNN 负责大部分标准算子，把少数特殊操作交给 JavaScript、WebAssembly 或 WebGPU；也可以在模型转换阶段改写网络结构。\n\n## 硬件加速不是免费的魔法\n\n“交给 NPU”听起来一定更快，但真实速度取决于多个因素：\n\n1. 设备是否真的有可用的加速后端；\n2. 模型算子是否能完整落到该后端；\n3. 数据在 JavaScript、WebNN 和硬件之间搬运了几次；\n4. 模型加载和权重初始化的成本有多大；\n5. 单次推理是否足够大，能否摊薄调度开销。\n\n对于一个很小的文本分类模型，调用加速器的准备成本可能比计算本身还高。对于连续图像处理、语音特征提取或端侧视觉模型，硬件后端才更可能体现优势。\n\n## 安全与隐私边界也要一起设计\n\nWebNN 直接接触设备能力，因此规范需要考虑指纹识别、跨源访问和权限边界。当前规范明确讨论了跨源 frame 的 Permissions Policy，并默认限制某些跨源使用场景，以减少第三方内容未经授权调用能力的风险。[WebNN 安全相关章节](https:\u002F\u002Fwww.w3.org\u002FTR\u002Fwebnn\u002F#security-privacy-considerations)\n\n本地推理也不代表“网页看不到数据”。页面脚本仍然可以读取用户输入；模型推理的输出仍可能被上传；硬件加速器的执行时间也可能暴露侧信道信息。安全模型需要同时看浏览器权限、页面来源和应用自己的数据处理逻辑。\n\n## 现在适合用 WebNN 吗\n\n如果你的产品需要今天就覆盖大量浏览器，WebNN 仍然更适合作为渐进增强，而不是唯一后端。可以准备三条路径：WebNN、WebGPU\u002FWebAssembly，以及服务端推理。\n\n如果你的目标是研究端侧推理、设计跨设备运行时，或者希望提前理解浏览器如何连接 NPU，WebNN 值得关注。它真正解决的不是“让网页调用 AI”这一句话，而是把神经网络计算从某个浏览器实现，逐步变成可以讨论、测试和互操作的 Web 平台能力。\n\n一句话总结：**WebNN 试图让网页描述神经网络，而不是描述每一块 GPU 应该怎样工作。**\n\n## 来源\n\n- [W3C：Web Neural Network API](https:\u002F\u002Fwww.w3.org\u002FTR\u002Fwebnn\u002F)\n- [WebNN 规范历史与实现状态](https:\u002F\u002Fwww.w3.org\u002Fstandards\u002Fhistory\u002Fwebnn\u002F)","\u002Fuploads\u002F2026-09-08\u002F9bf93122-c216-4dd8-9381-11db89b7d08f.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31,35],{"id":24,"name":25,"slug":26},"88d2bc27-0e0f-468a-b907-2991cb97b87b","人工智能","ai",{"id":28,"name":29,"slug":30},"a202d639-99a6-488a-a712-4d4c6ffd7e15","开发","dev",{"id":32,"name":33,"slug":34},"8d35e42e-9f5b-4dd9-b30f-dc2c53d06096","硬件","hardware",{"id":36,"name":37,"slug":38},"82f427f8-6275-4cbb-bcac-cf1948488006","网页应用","web-app","W3C WebNN 官方规范","W3C：Web Neural Network API","https:\u002F\u002Fwww.w3.org\u002FTR\u002Fwebnn\u002F","published","WebNN 是什么：浏览器如何调用 NPU 和 GPU 做 AI 推理","从 WebGPU 与 WebNN 的区别出发，解释浏览器神经网络推理、计算图、硬件后端、跨源安全和端侧 AI 的落地边界。",null,false,59,0,"2026-09-08T00:00:00.000Z","2026-09-08T03:19:17.431Z",[52,60,68],{"id":53,"type":6,"title":54,"slug":55,"summary":56,"coverUrl":57,"authorName":14,"sno":58,"publishedAt":49,"createdAt":59},"7f7b281e-b9d6-406f-8d79-9dfb33145f5e","WebTransport：为什么实时 AI 应用不一定应该使用 WebSocket？","webtransport-realtime-ai-apps","WebSocket 适合通用双向消息，但复杂实时 AI 应用还可能需要可靠流、双向流和可以丢弃的临时数据。本文解释 WebTransport 的 session、stream 和 datagram，比较它与 SSE、WebSocket、WebRTC 的边界，并讨论鉴权与部署。","\u002Fuploads\u002F2026-09-08\u002F2247cab5-87b7-4b92-8871-e6adac14dc47.jpg",44,"2026-09-08T03:19:19.069Z",{"id":61,"type":6,"title":62,"slug":63,"summary":64,"coverUrl":65,"authorName":14,"sno":66,"publishedAt":49,"createdAt":67},"5c48f6e2-585c-425d-a16c-4fddbe52b592","浏览器自带 AI API：网页如何本地完成翻译、摘要和改写？","browser-built-in-ai-apis-explained","Chrome Built-in AI 把部分模型能力放进浏览器，由网页调用翻译、语言检测、摘要、写作和改写 API。本文解释本地推理的优势与限制、模型下载和兼容性问题，以及更现实的本地与云端混合架构。","\u002Fuploads\u002F2026-09-08\u002Fff6756e6-ef33-4d7a-bb3b-2b3d2394c8f5.jpg",47,"2026-09-08T03:19:16.095Z",{"id":69,"type":6,"title":70,"slug":71,"summary":72,"coverUrl":73,"authorName":14,"sno":74,"publishedAt":75,"createdAt":76},"0c00fd8d-379a-4c58-a542-460bb3575b72","MCP Apps：让 AI 对话里的工具带上交互界面","mcp-apps-interactive-tool-ui","MCP Apps 通过 ui:\u002F\u002F 资源、工具元数据和沙箱 iframe，让 MCP 服务器可以向宿主提供交互式 HTML 界面。本文解释工具与 UI 的关联、权限边界、文本回退和安全模型。","\u002Fuploads\u002F2026-09-12\u002F9e795ab0-aa98-480f-ad6d-a2013530b302.jpg",48,"2026-09-12T00:00:00.000Z","2026-09-12T03:56:44.551Z"]