WebGPU 端侧推理与部署

• WebGPU 的并行计算与 GPU 加速能力
• 相对 CPU/WebGL 的推理性能优势
• 端侧 Transformer 推理的适用场景

WebGPU 作为浏览器端 Transformer 推理的加速后端，核心优势在于 GPU 并行计算：Transformer 的矩阵乘法、注意力等算子天然并行，WebGPU 的 Compute Shader 与高带宽显存能显著加速这些运算，相比 CPU（WASM）推理吞吐与延迟大幅改善，相比 WebGL 具有更现代的编程模型、更灵活的缓冲与精度控制。

具体优势： 支持通用计算（Compute）与零拷贝缓冲，便于实现矩阵分块、共享内存等优化；显存管理（GPUBuffer）与异步管线支持大模型权重分块加载；精度可控（f16/f32）兼顾性能与质量。这让端侧可运行更大的 Transformer 模型、实现更快的生成，配合 WebNN 形成端侧加速体系，适合离线、隐私、低延迟推理场景。

本题考察 WebGPU 在推理加速中的定位。答题应突出 GPU 并行对 Transformer 的天然适配、相对 CPU/WebGL 的性能优势，以及通用计算与显存管理带来的优化空间，体现对端侧推理加速底层的理解。

• 矩阵乘法的 tiling 分块与共享内存（workgroup shared memory）
• 减少全局内存访问、提升带宽利用率
• 对 LLM/卷积推理算子的工程价值

矩阵乘法在 GPU 上主要瓶颈是全局内存带宽。tiling 优化把矩阵分块（tile），每个 workgroup 加载一块数据到共享内存（Workgroup Shared Memory），在块内复用，显著减少对全局内存的重复访问，提升带宽利用率与计算效率。配合循环分块、寄存器复用与向量化加载，可进一步加速。

工程价值： 矩阵乘法是 Transformer（attention 的 QK^T、PV）与卷积的核心算子，tiling/共享内存优化直接提升这些推理算子的性能，是端侧 LLM 推理框架的重要优化手段。分块大小需结合 workgroup 大小与共享内存容量调优，过大超出共享内存、过小复用不足，需针对具体硬件实测。

本题考察 WebGPU 计算优化的核心技巧。答题应说明 tiling 与共享内存减少全局访问的原理、对矩阵乘法的优化，并联系到 Transformer/卷积推理算子的工程价值，体现对 GPU 计算的深入理解。

• attention（QK^T、softmax、PV）的并行分解
• 分块与并行化策略（如 flash attention 思路）
• workgroup/线程映射与内存优化

attention 计算分三步：QK^T 得到注意力分数、softmax 归一化、再与 V 相乘。并行策略上，按 batch/head 维度并行（每个 head 独立计算），QK^T 与 PV 的矩阵乘法用 tiling 并行，softmax 按行/列并行并做数值稳定处理（减去最大值）。每个 head 的多个 query 可分配不同 workgroup/线程并行处理。

进阶策略： 借鉴 flash attention 思路，把 K、V 分块载入共享内存，在计算 PV 时在线做 softmax 重缩放，避免写出完整注意力矩阵，节省显存并提升缓存利用率；合理设计 workgroup 大小与共享内存以平衡并行度与占用。需根据 head 数、序列长度与硬件能力选择映射，过大并行度反而增加调度开销。

本题考察 attention 在 GPU 上的并行实现。答题应说明按 head/batch 并行、矩阵乘法的 tiling 并行与 softmax 并行，并引入 flash attention 式分块在线 softmax 的优化，体现对现代注意力实现的掌握。

• GPUBuffer 的创建、生命周期与释放
• 大模型权重分块加载与显存占用控制
• 显存爆掉的降级与复用策略

WebGPU 推理的显存管理围绕 GPUBuffer 展开：创建时指定用途（uniform/storage/copy 等）与大小，推理后需及时 destroy 释放，避免显存泄漏；大模型权重体积大，不宜一次性载入，采用分块加载——按层/权重块创建缓冲，按需上传与复用，控制瞬时显存峰值。

策略： 结合 pipeline 复用与权重缓存，避免重复创建缓冲；用 mapAsync/queue.writeBuffer 上传权重，配合分块降低峰值；显存不足时检测并降级（用更小量化、释放缓存、回退 CPU/WASM）。应建立显存预算，动态管理缓冲生命周期，避免长期占用导致其他应用或页面 OOM。

本题考察 GPU 显存与大模型部署。答题应说明 GPUBuffer 生命周期与释放、分块加载控制峰值，并落到复用、降级与显存预算的策略，体现对端侧大模型推理资源管理的实战能力。

• 二者定位：通用计算 vs 专用推理
• 架构差异与适用场景
• 标准演进与未来趋势

WebGPU 是通用图形与计算 API，定位为渲染与通用并行计算，提供 Compute Shader 与显存管理，灵活但需自行实现推理算子；WebNN 是面向神经网络推理的高层 API，抽象出图算子并映射到 NPU/GPU 等专用硬件，易用、高效、低功耗，但算子与灵活性受限。二者定位不同：WebGPU 偏底层通用，WebNN 偏高层专用推理。

未来走向： 两者互补而非替代：WebGPU 承担渲染与灵活计算，WebNN 承担标准化推理并利用 NPU；标准持续演进，WebNN 的 MLTensor 等新 API 让二者可结合（如张量数据在 GPU 内存流转）。未来会走向更统一、硬件加速更充分的端侧推理生态，开发者按设备与算子需求选择，或让运行时自动路由。

本题考察两个 API 的定位与趋势。答题应说明通用 vs 专用的定位差异、架构与场景区别，并展望互补融合与硬件加速的未来，体现对端侧 AI 技术栈演进方向的把握。

• WebGPU 适配器（adapter）与设备（device）的概念
• 集成显卡/独显的差异与选择依据
• 请求适配器的策略与降级

WebGPU 通过 requestAdapter() 获取适配器（表示物理 GPU），再 requestDevice() 创建逻辑设备。多设备环境下，浏览器可能暴露集成显卡与独显等多个适配器，各有特性：独显性能强但功耗发热高，集成显卡省电但性能弱。requestAdapter() 可传入 powerPreference（high-performance/low-power）让浏览器选择合适的适配器。

选择策略： 对推理任务，可按需选择：追求性能用 high-performance（倾向独显），追求省电与移动端用 low-power（倾向集显）；对功耗敏感场景优先 low-power。还可枚举适配器比较特性（显存、能力）后选择。需处理适配器获取失败，降级到默认适配器或回退 WebNN/CPU。结合设备类型与功耗需求动态选择，避免固定绑定。

本题考察多 GPU 环境的适配器选择。答题应说明 adapter/device 概念、powerPreference 的作用，并给出按性能与功耗选择及降级的策略，体现对端侧异构硬件适配的认识。

• BindGroup/BindGroupLayout 与着色器资源绑定
• 权重/输入/输出 Buffer 的 binding 分组策略
• 绑定复用与动态更新

WebGPU 通过 BindGroupLayout 定义资源绑定布局，BindGroup 提供具体资源（buffer、texture 等）绑定到着色器。推理管线中，模型权重、输入、输出分别用不同 buffer，应合理分组绑定：可把权重（只读、量大）与输入输出分开，或按更新频率分组，减少不必要的重绑定。

策略： 权重 buffer 常设为只读 storage，绑定后复用不变；输入/输出 buffer 按推理更新，可单独分组以便动态更新而不重建整个绑定组；对频繁变化的输入可复用 BindGroup 并重写 buffer 内容。合理设计绑定数量与布局（避免超限），并管理 buffer 生命周期，提升管线复用与推理效率。

本题考察 WebGPU 推理的资源绑定设计。答题应说明 BindGroup 机制、按权重/输入/输出分组与复用更新的策略，体现对 GPU 管线资源管理的深入理解。

• INT4/INT8 量化对显存与精度的作用
• GGUF/ONNX 到 WebGPU 可加载格式的转换
• 显存与精度的权衡与验证

量化（INT4/INT8）可显著压缩模型权重、降低显存占用与加载带宽，使更大模型能在端侧运行，但会引入精度损失。INT4 比 INT8 更省显存但精度损失更大，需按任务敏感性选择。权重格式转换把 GGUF/ONNX 等格式转成 WebGPU 可加载的格式（如按 GPU 布局的权重文件），保证在 GPU 上高效加载。

权衡： 显存与精度需综合权衡：追求显存低用 INT4，追求精度用 INT8/FP16 或混合精度；转换时优化权重布局（分块、对齐）以适配 WebGPU 缓冲。应通过校准集评估量化误差，对比不同量化位宽的显存占用与精度指标，选择满足显存预算且精度可接受的最优组合，并以回归测试固化。

本题考察量化与格式转换的工程权衡。答题应说明量化位宽对显存/精度的作用、格式转换的适配，并给出显存预算与精度验证的权衡方法，体现端侧大模型部署的核心决策能力。

• 低功耗设备推理的发热与功耗特征
• thermal throttling（热节流）对推理的影响
• 负载控制与降频策略

低功耗设备（手机、平板）GPU 算力与散热能力有限，持续 WebGPU 推理会快速升温，触发 thermal throttling：GPU 降频、性能下降，导致推理变慢、延迟波动。推理时间越长、负载越高，发热越明显，用户体验与稳定性受冲击。

应对： 应控制推理负载，避免长时间满负荷：批量/限频调度、任务间降载、实时性不高的任务降低频率；监控性能与温度，检测到节流时动态降级（减小模型、降低帧率/批大小、回退到 CPU/WASM 或 WebNN 低功耗路径）。同时选择低功耗适配器或 f16 精度降低功耗，平衡性能与温升，保证持续可用。

本题考察低功耗设备的推理稳定性。答题应说明热节流机制与影响，并给出负载控制、动态降级与低功耗策略，体现端侧推理在有限硬件下的可持续性设计。

• WebGPU 与 WebGL 推理的性能差异
• 对比实测的方法与指标
• 差异的底层原因与选型

WebGPU 与 WebGL 都能做 GPU 推理，但 WebGPU 性能通常更优：WebGPU 提供 Compute Shader、更灵活的缓冲与精度控制、更强的并行与显存管理，而 WebGL 面向渲染，用纹理模拟计算，精度与通用性受限。对矩阵乘法等深度学习算子，WebGPU 的吞吐与延迟通常明显优于 WebGL。

实测方法： 对比应控制变量，用相同模型、相同输入、相同设备，分别测量推理耗时、吞吐、稳定性与首帧延迟，多次运行取中位数/均值以排除波动；结合不同设备（独显/集显/移动）与不同模型规模对比，观察差异趋势。差异根源在 API 抽象与计算模型，WebGPU 更贴近现代 GPU 计算，工程上按需求选型：追求性能用 WebGPU，兼容性兜底用 WebGL。

本题考察实测对比的工程方法。答题应说明 WebGPU 与 WebGL 的计算模型差异、性能差异原因，并给出控制变量的实测方法与选型依据，体现以数据驱动技术选型的能力。

• WGSL 与 GLSL 的语法与类型差异
• 推理算子（矩阵乘等）编写差异
• Tint 与 GLSLang 的定位与调试路径

WGSL 是 WebGPU 的着色器语言，GLSL 是 WebGL/OpenGL 的着色器语言。WGSL 采用更现代、更安全的语法（明确类型、内存布局、地址空间 annotation），GLSL 语法更接近 C、围绕渲染习惯设计。编写推理算子时，WGSL 提供显式的 shared 内存、workgroup 尺寸与 buffer 布局控制，更便于实现矩阵分块等优化。

工具链： Tint 是 WebGPU 的 WGSL 编译器（负责 WGSL→底层中间表示），GLSLang 是 GLSL 编译器。调试时用 WGSL 需注意 Tint 的报错与验证，用 GLSL 需经过 GLSLang 编译。WebGPU 对 WGSL 提供更完整的校验与错误报告，调试体验更好；GLSL 转算需额外工具链。选型上，新项目推理算子优先 WGSL，既有 GLSL 资产可迁移或经转换。

本题考察着色器语言与工具链。答题应说明 WGSL 与 GLSL 在类型、内存与并行控制上的差异，并对比 Tint/GLSLang 的调试路径，体现对端侧推理底层实现工具的选择判断。

• dispatchWorkgroupSize 与 workgroup 尺寸的含义
• GPU occupancy（占用率）与并行度
• 端侧推理的调优实践

WebGPU Compute Pipeline 执行时通过 dispatchWorkgroup 指定 workgroup 数量，每个 workgroup 有固定 size（workgroupSize），决定线程布局与共享内存使用。GPU occupancy 指 GPU 上可同时驻留的 workgroup 数量，受 workgroup 尺寸、共享内存与寄存器限制影响，适度增大 occupancy 可提升并行度与吞吐。

调优实践： workgroup 尺寸过小则并行度不足、隐藏不了延迟，过大则共享内存/寄存器超限、occupancy 下降。端点推理中应结合算子特性与硬件，测试不同 workgroup 尺寸与 dispatch 组合，找到吞吐与占用最佳平衡；合理控制共享内存与寄存器以提升 occupancy，同时避免过度调度。用性能剖析工具对比不同配置，做端到端实测选优。

本题考察 Compute Pipeline 的性能调优。答题应说明 workgroup 尺寸与 dispatch 的关系、occupancy 的影响因素，并给出针对端侧推理的实测调优方法，体现对 GPU 并行效率的精细控制。

• llama.cpp WebGPU、WebLLM、Transformer.js 的架构差异
• 三者定位与后端差异
• 不同场景的选型依据

三个框架定位不同：llama.cpp WebGPU 是 llama.cpp 的 WebGPU 移植，专注 LLM 底层推理，用 WASM 与 WebGPU 后端，支持 GGUF 模型，性能与可控性强；WebLLM 是面向 LLM 的浏览器推理框架，基于 WebGPU 与 MLC LLM（机器学习编译）框架，提供聊天/流式 API 与模型管理，易用；Transformer.js 是面向 Transformers 模型（含非 LLM 的各类模型）的框架，基于 ONNX Runtime Web，支持 WebGPU/WebGL/WebCPU，模型广、使用门槛低。

选型： 追求 LLM 底层性能与可控用 llama.cpp WebGPU；需要开箱即用的 LLM 推理与流式交互用 WebLLM；需要通用 Transformer 模型（NLP CV 等）用 Transformer.js。需结合模型格式、后端需求、性能与易用性权衡，并考虑量化、显存与设备兼容。

本题考察推理框架选型。答题应说明三者的架构差异（底层 LLM vs 易用 LLM vs 通用 Transformer）与后端，并给出按场景选型依据，体现对端侧推理生态的整体把握。

• 首 token 延迟（TTFT）的来源
• 权重分片加载与 pipeline 复用优化
• 静态/动态优化组合

端侧大模型（7B/13B）首 token 延迟（TTFT）主要来自权重加载、量化解码、图编译与首次前向。权重分片加载按需/流式加载权重，配合 KV cache 与预编译，可避免一次性加载全部权重；pipeline 复用指复用已编译的管线与缓冲，避免重复创建，显著降低每轮推理的初始化开销。

优化组合： 首 token 延迟可通过组合手段优化：预热与预下载（后台提前加载权重）、pipeline 复用（复用已编译 Compute Pipeline 与绑定组）、分片加载与流水线重叠（加载与推理并行）、量化与紧凑格式降带宽、负载均衡。结合分片 + 复用 + 预热，能显著压缩从调用到首个 token 的时间，提升交互体验。

本题考察大模型首 token 延迟优化。答题应说明 TTFT 来源，重点讲权重分片加载与 pipeline 复用，并组合预热、重叠、量化等手段，体现对端侧大模型性能优化的系统认识。

• f16 与 f32 精度差异
• 精度对推理结果的影响
• 精度选择与性能权衡

WebGPU 计算着色器可用 f16 与 f32 精度。f16（半精度）内存减半、带宽占用低、部分硬件计算更快，但表示范围与精度有限，可能引入数值误差；f32（单精度）精度高、更稳定，但占用与带宽更高。对推理算子，精度直接影响中间结果与最终输出。

影响与权衡： 对数值敏感算子（如 softmax 的累加、attention 的分数），f16 可能放大误差导致结果漂移，需适度使用或混合精度；对不敏感算子（如大矩阵乘的权重）用 f16 可显著提速省显存。端到端应对比 f16 与 f32 的输出与精度指标，在可接受误差内用 f16 换取性能，必要时对关键算子保留 f32。

本题考察精度对推理的影响。答题应说明 f16 与 f32 的差异、对推理结果的影响，并给出混合精度与验证的权衡，体现端侧推理精度控制的工程能力。

• 推理进度与状态反馈
• 取消推理的实现（线程/管线控制）
• 长任务下的用户体验

WebGPU 推理通常是异步任务，进度反馈需把推理过程拆分为可观测阶段：模型加载、图编译、逐层/逐 token 推理，在关键节点上报进度（加载百分比、已生成 token 数）。取消机制可用 WebGPU 的 destroy 或丢弃结果、结合 AbortController/信号中断请求，避免无用计算继续占用 GPU。

工程实现： 长推理（如 LLM 生成）中，用户可随时取消，取消后应释放 GPU 资源并停止后续 dispatch；进度反馈用流式（逐 token）提升感知。取消与控制逻辑需与 pipeline 生命周期管理衔接，避免资源泄漏与竞态。整体设计要兼顾响应性（及时反馈与停止）与资源安全。

本题考察长推理任务的交互与资源管理。答题应说明进度分阶段反馈、取消机制（AbortController 与资源释放）与流式体验，体现对可用性与资源安全的兼顾。

• queue.writeBuffer、mapAsync、staging buffer 的差异
• 数据搬运的带宽瓶颈
• 不同场景的搬运路径选择

WebGPU 的 CPU-GPU 数据搬运有不同路径：queue.writeBuffer 直接把数据写入 GPU 缓冲（适合小批量、频繁上传）；mapAsync 把缓冲映射到 CPU 内存读写（适合读取结果或大块数据，但需同步等待）；staging buffer 是中间缓冲，先在 staging 中写入再拷到 GPU（适合大块、需要复用与异步的场景）。不同路径性能与用法各异。

带宽瓶颈： CPU-GPU 数据搬运受 PCIe/总线带宽限制，是常见瓶颈，尤其大模型权重上传与结果回读。为缓解瓶颈，应减少搬运次数与数据量：用零拷贝（GPU 张量）、复用缓冲、压缩/量化数据、批量上传；避免频繁 mapAsync 与不必要的拷贝。选择路径要结合数据量、频率与是否需要读回：小数据用 writeBuffer，大块读回用 mapAsync，复用大块上传用 staging buffer。

本题考察数据搬运路径的选型。答题应说明 writeBuffer/mapAsync/staging buffer 的差异与适用场景，并分析带宽瓶颈与缓解手段，体现对端侧推理性能瓶颈的深入理解。

• Cache API 与 IndexedDB 存储模型权重的差异
• 离线可用与增量更新策略
• 版本管理与缓存失效

模型权重可持久化缓存以支持离线可用与快速二次加载。Cache API 适合缓存响应式资源（配合 fetch），IndexedDB 适合存大二进制对象（权重 buffer）并支持版本化与结构化存储。两者都能持久化，选择取决于使用方式：URL 资源用 Cache API，直接存 blob/buffer 用 IndexedDB。

增量更新： 模型版本更新时，用增量更新（只下载变化部分）减少流量；用版本号/清单管理缓存，检测到新版本时再更新，避免每次都全量重下。离线可用通过先缓存后离线加载实现；需处理缓存失效与清理（配额、过期），并保证更新后缓存与运行时一致。

本题考察模型权重的持久化与更新。答题应说明 Cache API/IndexedDB 的差异与适用、离线可用与增量更新、版本管理，体现对端侧模型资源缓存与更新的工程理解。

• 不同平台 WebGPU 的可用性与实验性支持
• 兼容性差异与能力探测
• 降级到 WebNN/WebGL 的策略

WebGPU 在不同平台可用性不同：WebGPU 在 Chrome 等主流浏览器已稳定，但在 iOS Safari 等仍为实验性支持，需开启 flag 或版本差异，导致跨平台兼容性不一致。Android Chrome 与桌面 Chrome 的 WebGPU 支持与能力也可能因版本、硬件而异。推理前必须做能力探测，识别 WebGPU 是否可用。

降级策略： 建立多级回退链：WebGPU 不可用时降级到 WebNN（若可用且算子支持）或 WebGL、WASM/CPU。按平台配置：iOS 等实验性平台优先探测 WebGPU 能力，不可用则用 WebGL/CPU 兜底；Android 上若 WebNN 可用且算子覆盖，可优先 WebNN 加速。通过运行时探测与性能/兼容性权衡，保证各平台功能可用且尽量用硬件加速。

本题考察跨平台推理兼容性。答题应说明 WebGPU 在 iOS Safari 与 Android Chrome 的可用性差异、能力探测，并给出 WebNN/WebGL/CPU 的多级降级策略，体现跨平台部署的工程健壮性。

• 与 CPU/WebGL 输出一致性校验
• 数值回归测试与容差
• 性能基线的建立与监控

端侧推理（WebGPU/WebNN）需与基准（CPU/WebGL）做输出一致性校验：用相同输入分别推理，比较输出数值，设定容差阈值，检验端侧推理结果是否与基准一致，防止硬件加速引入的错误。容差需结合量化与精度差异设定，关注数值分布与关键指标。

基准建立： 建立性能基线：在固定设备与条件上测量推理耗时、吞吐、稳定性，作为后续优化与回归的参照；基准测多次取稳定值，排除波动。数值回归测试与性能基线配合，在模型/环境变更时自动化运行，及时发现精度或性能退化，保证端侧推理质量与性能可控。

本题考察端侧推理的质量保障。答题应说明与 CPU/WebGL 的一致性校验、容差设定，以及性能基线的建立与监控，体现对端侧推理精度与性能长期稳定的工程把控。

• device lost 事件成因与处理
• 管线重建与恢复
• 降级到 CPU/WASM 推理的切换策略

WebGPU 设备可能因 GPU 重置、驱动问题、显存不足等触发 device lost，导致 device 失效、后续操作失败。处理 device lost 需监听 device.lost 事件，捕获状态后停止未完成操作、释放资源，并根据情况重建 device 与管线（重新 requestDevice、重建 buffer 与 pipeline），恢复推理。

切换策略： 若重建失败或设备持续异常，应降级到 CPU/WASM 推理（如 ORT Web 的 WebCPU 后端）保证功能可用。切换策略包括：检测 device lost 后优先尝试重建，同时准备 CPU/WASM 兜底；降级时保留状态与上下文，平滑切换并提示用户性能变化；监控重建/降级过程，避免静默失败。整体设计要保证推理链路在 GPU 异常时仍可用。

本题考察 WebGPU 异常恢复。答题应说明 device lost 的成因与监听处理、管线重建，以及降级到 CPU/WASM 的切换策略，体现对端侧推理健壮性的工程保障。