题干与适用场景
一个网页应用希望在浏览器本地运行图像分类模型，减少上传图片的隐私风险和网络延迟。团队考虑采用 2026 年 5 月的 W3C Web Neural Network API Candidate Recommendation Draft。该 API 以计算图为核心，支持 CPU、GPU 和 NPU 等执行设备；规范仍在演进，不能把候选推荐草案当作所有浏览器都已稳定支持的产品接口。
请从模型转换、图构建与编译、推理执行、设备选择、回退和上线验证完整回答。
面试官考察点
面试官观察候选人是否理解“图构建一次、执行多次”的生命周期，能否区分 MLGraphBuilder.build() 的异步编译与 MLContext.dispatch() 的异步执行；是否把 WebNN 当成硬件无关抽象，而不是保证所有算子在所有设备上性能一致的魔法层。
强回答会主动讨论模型算子覆盖、输入输出张量绑定、主线程阻塞、设备能力探测、隐私和指纹风险、浏览器兼容矩阵以及可撤销的灰度策略。
回答前需要澄清的问题
- 模型是固定输入尺寸，还是要支持动态形状和多种精度？
- 目标浏览器和操作系统是否提供同一组算子与后端？
- 推理必须离线完成，还是允许安全地回退到服务端？
- 目标是首屏速度、每帧延迟、吞吐、能耗还是隐私？
- 模型是否包含个人敏感图像，是否允许使用硬件能力作为指纹信号？
30 秒回答框架
“我会把 WebNN 当作候选执行后端，先验证模型算子和张量布局，再把图构建与编译从每次推理路径移出。编译和 dispatch 都是异步的，输入输出通过命名张量绑定。上线前按浏览器、设备和模型版本建立兼容矩阵；能力不足或编译失败时回退到 WebAssembly 或服务端，并保证用户知道数据边界。性能评估同时测首轮编译、稳态推理、内存、功耗和主线程响应，先小流量灰度并保留关闭开关。”
分步骤深入解答
先冻结模型契约
固定输入尺寸、数据类型、布局、归一化、输出标签和精度容差。把模型转换为 WebNN 支持的算子子图；不支持的算子要在构建阶段检测，而不是等到用户设备上执行到一半才失败。保存一份可由 WebAssembly 或服务端执行的参考实现，用于逐层结果对比。
构建并编译计算图
通过 navigator.ml 创建上下文和 MLGraphBuilder，用 input、常量和算子组合计算图。build() 编译图并返回 Promise；每个 builder 只应负责构建一个图。把编译放在预热阶段或 Worker 中，避免把首次编译时间混入每次点击的交互延迟。
const context = await navigator.ml.createContext({ deviceType: 'gpu' });
const builder = new MLGraphBuilder(context);
const input = builder.input('image', {
dataType: 'float32',
dimensions: [1, 224, 224, 3],
});
const weights = builder.constant(weightDescriptor, weightBuffer);
const logits = builder.conv2d(input, weights, convOptions);
const graph = await builder.build({ logits });示例中的设备选项只是候选策略，不能假设每个实现接受完全相同的设备值；实际代码应以目标浏览器实现和规范版本验证。
设计异步执行与内存路径
dispatch() 把图执行提交到执行时间线并立即返回。通过命名输入和输出张量绑定数据，执行结束后再读取结果。重复推理应复用编译后的图、上下文和可复用缓冲区，避免每帧重新创建对象。对相机流要设置背压：上一帧未完成时丢弃或合并新帧，不能无限排队。
处理设备选择与回退
先探测 API、算子和模型版本，再决定 CPU、GPU 或 NPU。设备可用不代表目标算子高效；应以端到端测量选择。回退链可以是 WebNN → WebAssembly → 服务端，但每一级都要复用相同的预处理和结果校验。服务端回退涉及图片上传，必须在 UI 和网络层明确告知，并遵守用户同意与数据保留策略。
保证主线程和交互体验
图构建、编译、预处理和结果后处理都可能影响交互。把重任务放入 Dedicated Worker，主线程只处理输入采集和 UI 状态；通过取消令牌或序列号丢弃过期结果。不能仅看平均推理时间，还要测长任务、输入突发和页面切后台后的恢复。
建立正确性与兼容矩阵
按浏览器版本、操作系统、设备类型、模型精度和算子集合建立矩阵。使用参考后端比较输出误差、分类准确率和边界输入；记录编译失败、未实现算子、设备丢失和上下文销毁。W3C 规范仍是 Candidate Recommendation Draft，发布策略必须允许版本变化和实现差异。
处理隐私、权限与指纹风险
本地执行可减少图片上传，但模型文件、缓存和遥测仍可能泄露信息。只缓存必要权重，限制日志中的输入特征，不把设备类型作为用户标识。规范提醒设备调度可能引入指纹信号；因此能力探测结果应最小化、短时使用，并提供服务端或软件后端替代路径。
灰度、观测与回滚
先对非敏感模型和少量浏览器版本开启，比较首轮编译、稳态 P50/P95、主线程长任务、内存、能耗、失败率和回退率。模型或浏览器升级时重新跑兼容矩阵。发现设备崩溃、准确率漂移、功耗过高或隐私边界不满足时，关闭 WebNN 开关并回退参考后端；保留版本、设备和模型哈希用于复盘。
高质量示范回答
“我会先冻结模型输入输出和误差契约，再验证算子是否能映射到 WebNN。图只构建和编译一次，build() 与 dispatch() 都按异步流程处理，推理循环复用上下文和缓冲区。上线按浏览器、设备和模型版本做能力矩阵，主线程只负责交互，Worker 承担编译和预处理。WebNN、WebAssembly、服务端形成可观测回退链；服务端回退前明确图片上传边界。灰度阶段测首轮与稳态延迟、长任务、内存、功耗、准确率和失败率，发现问题立即关闭开关并保留参考实现。”
常见错误
- 把 Candidate Recommendation 当成普遍可用 → 浏览器或算子不兼容 → 建立版本与能力矩阵。
- 每次请求重新编译图 → 首轮成本反复出现 → 预热并复用编译后的图。
- 只测 GPU 理想设备 → CPU 或 NPU 路径无法工作 → 对每个后端测端到端结果和成本。
- 把 dispatch 当成同步函数 → 主线程卡顿或结果顺序错乱 → 使用异步状态和序列号。
- 无限排队相机帧 → 延迟不断累积 → 设置背压，丢弃过期帧。
- 把设备能力上报为用户标识 → 增加指纹风险 → 最小化探测结果并提供软件回退。
追问及应对
追问一：为什么不直接用 WebGPU？
WebGPU 暴露更底层的资源和着色器控制，适合需要自定义算子或精细调度的团队；WebNN 提供更高层的神经网络图抽象，便于框架映射和跨硬件后端。选择取决于算子覆盖、团队维护能力、性能目标和隐私边界。
追问二：图编译十秒，如何避免用户等待？
把模型和编译放到 Worker，使用页面空闲时间预热并缓存经过完整性校验的权重。首轮仍不可用时显示清晰状态，并先走 WebAssembly 或服务端回退；不能用假结果掩盖编译失败。
追问三：GPU 结果偶尔与参考实现不同，怎么办？
先区分浮点舍入、精度转换、算子实现差异和真正的模型错误。用固定输入、逐层中间值和容差阈值复现；若误差超过产品阈值，降级到另一后端并记录浏览器、驱动和模型版本。
追问四：用户拒绝上传图片，WebNN 又不可用怎么办？
提供本地 WebAssembly 或明确的不可用状态，不绕过用户选择。产品可以降低模型复杂度或提供手动流程，但必须保持数据边界透明。