WebNN 端侧推理

• InferenceSession.create() 初始化与执行提供者配置
• executionProvider 优先级与回退链原理
• 跨设备能力探测与降级策略

ONNX Runtime Web（ORT Web）通过 InferenceSession.create() 加载模型并创建推理会话，可在配置中指定 executionProviders 列表，按优先级尝试使用。各提供者用途不同：WebCPU 通用兜底、WebGL 兼容性好、WebGPU 性能高、WebNN 可访问 NPU/GPU 硬件加速。ORT 会按声明顺序尝试使用，若某提供者不可用或算子不支持则回退到下一个。

回退链设计： 工程上应遵循"性能优先、稳定兜底"顺序，如 [WebGPU, WebGL, WebCPU] 或 [WebNN, WebGPU, WebCPU]，并依据 navigator.gpu 与 WebNN 可用性动态构造列表；通过获取实际使用的 provider 或检查支持情况，做性能与兼容性的动态选择。回退链能保证高端设备用硬件加速、低端设备也能用 CPU 运行，兼顾性能与覆盖率。

本题考察 ORT Web 的执行提供者机制。答题需说明 create() 与 executionProviders 的优先级语义、各提供者定位，并给出"动态探测 + 性能优先 + CPU 兜底"的回退链设计，体现跨设备推理的工程健壮性。

• INT8 量化误差的来源与评估方法
• 与 CPU/FP32 基准对比的容差阈值设定
• 回归测试与精度监控

WebNN 推理可能因硬件与量化产生数值误差。INT8 量化把浮点权重/激活压缩到 8 位，损失精度，需评估误差：对比量化模型与 FP32 基准的输出，计算差异（如最大绝对误差、相对误差、余弦相似度）。容差阈值应结合任务敏感性设定，分类任务用 Top-1/Top-5 一致率，回归任务用数值误差上限，并考虑输入分布与硬件差异。

回归测试： 建立标准化测试集与基准输出，在每次模型/环境变更后运行对比，设定容差阈值检验是否通过；对边缘 case（极小值、极值、异常输入）单独校验。阈值过严会误报、过松会漏报，需结合真实误差分布校准。也可用感知指标（如任务精度）补充数值指标，综合评估量化对业务的影响。

本题考察精度验证的工程方法论。答题应说明量化误差来源、FP32 基准对比与容差阈值设定，并落到回归测试与多指标评估，体现对端侧推理质量保障的系统认识。

• createContext() 创建设备上下文与设备选择
• MLGraphBuilder 构建计算图与设备绑定
• 跨设备推理的性能与兼容性取舍

WebNN 通过 navigator.ml.createContext() 创建推理上下文，可指定设备偏好（cpu/npu/gpu）得到对应硬件上下文；MLGraphBuilder 用于构建模型计算图（添加算子、构建 graph），并编译/执行推理。上下文与设备绑定，直接影响推理在哪类硬件上执行。

工程取舍： 创建上下文时应按可用性与性能择优：检测设备支持（navigator.ml 与设备能力），优先 NPU/GPU 加速，回退到 CPU；不同设备算子支持与性能差异大，需结合可用性探测与实测选择。构建图时注意算子兼容性，对不支持的算子回退或拆分。跨设备推理需权衡性能峰值、兼容覆盖面与实现复杂度，避免为追求峰值而牺牲设备兼容。

本题考察 WebNN 的上下文与图构建机制。答题应说明 createContext() 的设备选择与 MLGraphBuilder 的构图流程，并落到"设备择优 + 算子兼容 + 回退"的跨设备工程取舍。

• 常见算子（matmul/concat/conv2d/gelu）在 WebNN 的支持
• ONNX 模型转 WebNN 时的算子映射与兼容性
• 算子不支持的排查与回退

WebNN 支持多种图算子，包括 matmul（矩阵乘）、concat（拼接）、conv2d（卷积）、gelu（激活）等，但具体算子覆盖随设备与实现而异。ONNX 模型转换为 WebNN 时，需把 ONNX 算子映射到 WebNN 算子，两者存在差异，部分算子可能不支持或需参数转换。

兼容性排查： 转换前应做算子清单比对：列出模型用到的 ONNX 算子，逐一核对 WebNN 支持情况，对不支持的算子寻找替代组合（如把 gelu 用近似算子组合）或回退到 WebGPU/CPU 执行该子图；使用 ORT 的算子支持检查与报错信息定位不兼容算子。应建立模型—算子—设备的映射表，作为兼容性排查与降级依据，并保留基准测试验证精度。

本题考察算子兼容性的工程排查。答题应说明常见算子的支持情况、ONNX 映射的差异，并给出算子清单比对、替代方案与回退的具体排查流程，体现对跨界模型部署的实战能力。

• ort.env.wasm 各配置项（numThreads/simd/proxy）的含义
• 线程数与 SIMD 对推理性能的影响
• WASM 环境配置与浏览器限制的权衡

ORT Web 的 ort.env.wasm 用于配置 WASM 后端运行时：numThreads 控制线程数（配合 SharedArrayBuffer 与 COOP/COEP 使用），simd 控制是否启用 SIMD 指令加速，proxy 控制是否在 Worker 中运行 WASM 以避免阻塞主线程。合理配置可显著提升推理吞吐与响应。

工程实践： 启用多线程需跨源隔离（COOP/COEP）与 SharedArrayBuffer，需在响应头设置；numThreads 按设备核数设置，过多线程反而增加开销，应实测调优；SIMD 在支持的浏览器上默认开启，能提升向量运算性能；proxy 把 WASM 放 Worker 中，避免长推理阻塞 UI，但增加通信开销。应对主流设备做组合实测，选择最优参数，无法启用多线程时退化为单线程 SIMD。

本题考察 WASM 运行时的性能调优。答题应说明 numThreads/simd/proxy 的含义与依赖（COOP/COEP、SharedArrayBuffer），并给出实测调优、Worker 隔离与降级策略，体现端侧推理的性能工程能力。

• MLTensor 与 MLOperand 的差异与演进动机
• 实验性 API 的版本不稳定风险
• 跨版本适配与逐步迁移

早期 WebNN 使用 MLOperand 表示张量，作为图构建的输入输出占位；现代 WebNN 演进出 MLTensor（实验性 API），直接管理实际张量数据与设备内存，支持更清晰的数据绑定与零拷贝，贴近现代推理 API 设计。MLTensor 替代 MLOperand 简化了图构建与数据搬运，但仍是实验性接口，规范可能变化。

跨版本适配： 因实验性 API 可能变更，需抽象一层封装，将 MLTensor 的创建/读写/释放封装为内部实现，业务代码不直接依赖具体 API；通过特性检测区分新旧接口，编写兼容分支；在规范变更时只需更新适配层，避免全量改动。同时关注可用性（navigator.ml 与 API 存在性）并设计降级，保证跨浏览器版本的一致性。

本题考察 API 演进与适配。答题应说明 MLTensor 相对 MLOperand 的改进与动机，并强调用适配层、特性检测与降级应对实验性 API 的不稳定，体现对规范演进的前瞻性工程处理。

• 模型分片加载与渐进式资源加载
• INT8/INT4 量化对体积与精度的影响
• 首次推理冷启动的优化手段

端侧模型体积大，加载需渐进式策略：把 ONNX 模型分片（分片推理），按需加载权重，避免一次性加载全部；结合量化（INT8/INT4）大幅压缩模型体积、加快加载，但会带来精度损失，需在体积与精度间权衡。分片与量化可结合，先加载关键部分快速可用。

冷启动优化： 首次推理冷启动涉及模型下载、解码、权重初始化与图编译，可用以下手段优化：预热（预下载/预编译）、懒加载与流式加载、量化与权重格式优化、复用已编译图/进度缓存。通过分片加载实现"边加载边推理"，降低首 token 延迟；同时展示加载进度，避免用户感知卡顿。

本题考察模型加载的工程优化。答题应说明分片、量化对体积与精度的作用，并落到冷启动优化（预热、预编译、流式加载）的具体手段，体现对端侧模型部署性能的完整认知。

• IO Binding 的作用与原理
• WebGPU 零拷贝（零拷贝传输）与 GPU 张量
• 图像/视频连续推理场景的性能收益

IO Binding 让 ORT 预先绑定输入输出张量所在的内存/设备地址，避免每次推理重复分配与拷贝。当使用 WebGPU 后端时，可配合 GPU 张量（零拷贝）实现数据在 GPU 内存中直接流转，避免 CPU-GPU 反复搬运，显著降低开销，尤其适合图像/视频这类大张量、连续推理的场景。

性能收益： 在图像/视频模型（如目标检测、视频帧处理）中，输入帧常是连续大张量，IO Binding + 零拷贝能避免每次推理的分配与拷贝，稳定提升吞吐、降低延迟；结合 GPU 内存存储中间结果，减少主存占用。应在初始化时绑定、推理时复用，并注意 GPU 张量生命周期与内存释放，避免泄漏。

本题考察端侧推理的数据搬运优化。答题应说明 IO Binding 的原理与 WebGPU 零拷贝的组合效果，并落到图像/视频连续推理场景的吞吐与延迟收益，体现对端侧推理性能优化的深入理解。

• WebNN 与 WebGPU Compute 的功耗差异来源
• 热节流（thermal throttling）对推理性能的影响
• 端侧功耗与性能的权衡选择

WebNN 面向推理场景，可调用 NPU/GPU 的专用硬件加速，通常能以更低功耗、更高效完成推理；WebGPU Compute 是通用计算 API，可灵活写计算着色器，但功耗与效率取决于实现与硬件。在持续推理任务下，WebNN 倾向更省电、发热更小，而 WebGPU Compute 的通用性可能带来更高功耗与发热。

热节流影响： 端侧设备长时间高负载推理会升温，触发 thermal throttling 导致频率下降、推理变慢，功耗与吞吐率波动。工程上应对比两种方案的功耗与温升曲线，选择功耗更低、节流更晚的方案（如移动端优先 WebNN/NPU）；同时控制推理负载（限频、批处理、任务节流）避免过热，并监控性能下降做动态调度。

本题考察端侧推理的功耗与散热。答题应说明 WebNN 与 WebGPU Compute 在功耗与硬件加速上的差异，并分析热节流对持续推理的影响，落到"低功耗优先 + 负载控制 + 动态调度"的权衡策略。

• NPU/GPU 硬件加速的原理与差异
• 算子到硬件的映射与调度
• 算子不支持时的回退与适配

WebNN 通过后端把高层计算图算子映射到底层硬件执行：NPU（神经网络处理单元）针对推理算子做了专门优化，映射效率高、功耗低；GPU 通过通用计算映射算子，带宽与并行度好但通用性开销略高。浏览器/运行时根据设备能力把算子分配到 NPU 或 GPU 执行。

映射与回退： 算子映射依赖硬件驱动与运行时：支持硬件加速的算子直接映射，不支持的算子回退到 CPU 或 GPU 通用实现，保证功能可用。工程上应通过可用性探测与性能实测了解目标设备的算子映射与加速情况，对关键算子做针对性优化，必要时调整模型结构以落入硬件擅长算子，并保留回退路径。

本题考察 WebNN 的硬件加速机制。答题应说明 NPU 与 GPU 的算子映射差异、调度方式，并落到算子不支持的回退与模型适配，体现对端侧硬件加速落地的理解。

• 模型 buffer 的 hash 校验原理
• 防篡改与一致性保障
• 校验失败的处理与安全边界

端侧模型在下载或加载时应对 model buffer 做完整性校验：计算模型数据（buffer）的哈希（如 SHA-256），与可信的期望哈希比对，确保模型未被篡改或损坏。哈希校验能发现传输损坏、存储错误与恶意篡改，保障模型一致性。

防篡改机制： 使用可信的期望哈希来源（如与模型一起签发的清单、构建产物），校验时在可信环境比对；结合来源校验（稳妥的下载通道）形成纵深防御。校验失败时应拒绝加载并提示重新下载，避免使用损坏/被篡改模型导致错误结果或安全风险。注意哈希校验本身不能防"合法但被替换"的模型，需配合来源信任与签名。

本题考察端侧模型的安全保障。答题应说明 hash 校验 model buffer 的原理与用途，并讨论防篡改机制（可信哈希来源、纵深防御）与校验失败处理，体现对模型供应链安全的意识。

• ONNX 格式在端侧推理中的作用
• 量化（INT8/INT4）对模型体积与精度的影响
• 格式选择与转换的工程考量

ONNX 是端侧推理的通用模型格式，将模型定义为计算图，支持多种运行时（ORT Web、WebNN 等）加载执行，便于跨框架转换与部署。量化是把模型权重/激活从 FP32 压缩到 INT8/INT4 等低精度格式，显著减小体积与加载开销、加速推理，但会引入精度损失。

权衡： ONNX 模型本身是 FP32 全精度，量化后体积可缩小数倍，端侧加载更快、占用更小，适合内存与带宽受限场景；但需用校准集评估量化误差，敏感任务可能需保留高精度或混合精度。工程上按设备内存、精度要求与性能目标选择：轻量任务用 INT8/INT4 量化，高精度任务用 FP32 或混合精度，并验证量化前后指标。

本题考察模型格式与量化的工程选择。答题应说明 ONNX 的通用性与量化对体积/精度的权衡，并落到按场景选择精度格式与验证指标，体现对端侧模型部署的务实判断。

• WebNN 面向推理、WebGPU 面向通用计算/渲染的定位
• 二者在端侧推理中的适用边界
• 选择依据与协同

WebGPU 是面向渲染与通用计算的底层 API，可做计算着色器（Compute Shader）实现任意并行计算，包括推理，但需自行实现算子与优化，灵活性高、通用性强；WebNN 是面向机器学习推理的高层 API，NNEF 风格算子经浏览器映射到 NPU/GPU 等专用硬件，推理更高效、更省电，但算子与灵活性受限。

边界划分： 追求极致控制与通用性（自定义算子、同时做渲染与计算）用 WebGPU；追求推理效率、低功耗与易用性（用现成算子、利用 NPU）用 WebNN。二者可协同：WebGPU 负责渲染与灵活计算，WebNN 负责标准化推理；或按算子/设备动态选择。选择依据是设备支持、算子需求、性能与功耗目标。

本题考察两个 API 的定位差异。答题应说明 WebGPU 的通用计算 vs WebNN 的专用推理定位，并给出边界划分与协同使用、选择依据，体现对端侧推理技术栈的清晰认识。

• 端侧推理的隐私优势与性能限制
• 端云协同下的隐私/性能权衡
• 数据敏感度与性能要求的平衡

端侧推理在设备本地处理数据，数据不出设备，隐私保护强，且无网络往返延迟、可离线运行；但受限于设备算力、内存与功耗，模型规模与推理速度、质量上限低于云端。云端模型能力强、质量高，但需上传数据、有网络延迟与成本。

权衡： 应根据数据敏感度与性能要求选择：隐私敏感数据（个人信息、文本内容）优先端侧，保证不出设备；对高质量、复杂任务可端侧处理后再由云端增强，或对脱敏数据用云端。隐私与性能可分层：端侧做基础/兜底（离线、隐私），云端做增强，通过混合架构在两者间取得平衡，并逐步降低对云端的依赖。

本题考察隐私与性能的辩证权衡。答题应说明端侧隐私优势与性能限制、云端能力与风险，并给出基于敏感度与质量要求的混合策略，体现工程上的平衡思考。

• WebNN 算子支持与硬件差异
• 算子不支持的回退路径
• WebGL 模拟推理算子的作用与局限

WebNN 的算子支持因设备与浏览器实现而异，部分算子可能不被底层硬件支持。当算子不支持时，需回退到其他执行路径保证功能可用：回退到 CPU 通用实现、WebGPU 通用计算，或 WebGL 模拟。WebGL 模拟指用 WebGL 的着色器/纹理机制模拟矩阵运算，作为兼容性回退，能在无 WebNN/WebGPU 或算子缺失时提供推理能力。

回退权衡： WebGL 模拟兼容性好（老浏览器广泛支持），但精度（浮点纹理）与性能、灵活性有限，适合兜底而非主力。工程上应建立多级回退链（WebNN → WebGPU → WebGL → CPU），按算子与设备动态选择，并评估各路径精度与性能，保证功能覆盖同时优化体验。

本题考察 WebNN 算子回退机制。答题应说明算子支持差异、多级回退路径，并重点分析 WebGL 模拟的作用与局限，体现端侧推理兼容性兜底的工程认识。

• 大模型端侧部署的内存约束
• 模型分片/流水线推理策略
• WebNN 与分片结合的实现

大模型（如 LLM）权重庞大，端侧内存受限，无法整模型常驻。模型分片把模型按层/权重切分为多个片段，按需加载或流水线推理，配合 WebNN 的算子级加速，实现大模型在端侧部署。分片可减少瞬时内存占用，但增加调度与加载开销。

工程实现： 可用"权重分片 + 按需加载"：推理时仅加载当前需要的层/权重，配合 WebNN 上下文执行；或用 KV cache 复用与流水线重叠隐藏加载延迟。需结合量化进一步压缩体积，并权衡分片粒度（内存占用 vs 加载开销）。WebNN 提供算子级硬件加速，分片解决内存，二者结合支撑大模型端侧运行，但仍受限于算力，需以模型裁剪与量化辅助。

本题考察大模型端侧部署的内存与性能方案。答题应说明分片解决内存约束、WebNN 提供算子加速，并落到分片粒度、量化与流水线的工程权衡，体现对大模型端侧化的整体理解。

• batch 维度与固定/动态 shape 的算子支持
• 批大小对吞吐与延迟的影响
• 批处理策略的工程权衡

WebNN 推理的 shape 处理支持固定 shape 与动态 shape，但动态 shape 的算子支持与性能因设备而异，通常固定 shape 更利于优化、分配与性能。batch 维度是批处理的关键：批大小增大时，单次推理可并行处理多个样本，提升吞吐（throughput），但单样本延迟与内存、显存占用也会上升。

工程权衡： 批大小对端侧吞吐的影响要在"吞吐、延迟、内存"间权衡：增大 batch 提升吞吐但增加延迟与内存，减小 batch 降低延迟但吞吐下降。应根据实时性要求选择：交互式场景用小 batch 保低延迟，批处理场景用大 batch 提吞吐。动态 shape 需在首次推理时确定形状，频繁改 shape 会带来重建开销，固定 shape 更高效，需评估模型实际 shape 需求。

本题考察批处理推理的 shape 与吞吐。答题应说明固定/动态 shape 的算子支持差异、batch 对吞吐与延迟的影响，并给出按场景调 batch 的权衡策略，体现端侧推理性能调优的认识。