想象一下，你是两家餐厅的厨房主管。A 餐厅用的是老式灶台：火力被预先设定，厨师只能按固定流程操作——蒸、煮、炸，每道菜都是一个模板套出来的，换个做法就得重新发明一套流程。B 餐厅用的是新一代智能厨房：火力、翻勺频率、下料顺序全都可以编程，还配了一位“备菜专员”，能在高峰期前把食材统一处理成标准半成品，正餐时直接下锅。 A 餐厅就是 WebGL，B 餐厅就是 WebGPU。它们都在浏览器里“做菜”——也就是用 GPU 完成图形与 AI 计算任务。WebGL 诞生于 2011 年，基于老旧的 OpenGL ES 2.0 架构，本质上是“图形渲染专用”的固定管线；而 WebGPU 是 W3C 在 2023 年才正式落地的新标准，它把 GPU 当成一台可编程的通用计算设备，让浏览器里的 AI 模型推理第一次有了“像原生程序一样”使用算力的方式。 本文就来对比这两个“厨房”的性能差异：谁的出菜速度（吞吐量）更快？谁的食材区（内存）更省？谁的菜谱（算子）更全？以及，如果你正在用 WebGL 跑 AI 模型，要不要把厨房翻新成 WebGPU——预算多少、坑在哪里、何时动手。

岗位关联

学完本知识，你将建立“浏览器端 AI 推理为什么需要 WebGPU”的清晰性能直觉，能独立评估从 WebGL 迁移到 WebGPU 的收益、成本与风险，为架构选型与面试答辩储备硬核论据。

目录
  1. 可视化演示
  2. 渲染原理差异
  3. 吞吐量加速比
  4. 内存占用对比
  5. 算子支持差异
  6. 迁移成本评估
  7. 迁移注意事项
  8. 选型建议指南
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

模拟WebGPU与WebGL吞吐量对比、内存占用与算子支持分析及迁移收益成本评估，展示浏览器GPU计算方案的性能差异。

本节配有交互动效（进入视口后自动加载，约 3KB）。

模式1：WebGPU与WebGL吞吐量对比 WebGPU计算着色器并行度更高 WebGL经纹理模拟GPGPU有开销 throughput = ops / time WebGPU在大规模计算时优势显著。

渲染原理差异

A 餐厅的“老式灶台”到底老在哪？WebGL 的管线是固定的：顶点着色器处理位置 → 片元着色器逐像素上色 → 合成输出，每一步只能按 OpenGL ES 2.0 设定的流程走。虽然工程师能写自定义 GLSL 着色器，但整个数据流还是“一次渲染、一个方向”，就像厨师只能在蒸锅上换蒸笼，没法把锅拆了改成炒勺。

WebGPU 的“智能厨房”完全不同。它把 GPU 抽象成两种执行单元：渲染管线（Render Pipeline）和计算管线（Compute Pipeline）。计算管线引入了 compute shader——一道菜可以提前被“备菜专员”切好、腌好、分装成半成品，再喂给渲染管线。对 AI 推理来说，矩阵乘、卷积这些非图形计算不再需要硬塞进渲染流程，而是原生地在 GPU 上并行执行。

为什么这个差异如此关键？因为 AI 推理的核心——矩阵乘法和卷积——本质上都是“大量可并行的小任务”。WebGL 把它们伪装成“画一个硕大的像素方块”来执行，所有计算都要编码进 RGBA 颜色通道里，读出来再解码；而 WebGPU 直接用计算着色器让每个线程组对一块数据做运算，数据结构、精度、并行度全部由开发者掌控。这就像同样做一道蒜蓉粉丝虾，老厨房只能把虾剁碎混进蒸蛋里“曲线救国”，新厨房则是直接开大火爆炒。

这种结构差异决定了后文所有性能对比的基调：WebGL 是“图形专用赛道上的改装车”，而 WebGPU 是“通用计算赛道上设计出来的原装车”。厨房布局变了，后面比出菜速度、比备菜区大小、比菜谱数量，才真正是公平的较量。

吞吐量加速比

出菜速度是衡量厨房的第一指标。在 512×512 矩阵乘法这个“家常菜”任务上，公开基准测试显示 WebGPU 的吞吐量普遍比 WebGL 快 3~8 倍，模型越大、矩阵越宽，差距越明显。为什么差距如此显著？Amdahl 定律提供了一个精准的量化视角。

并行加速比公式：

回到厨房：WebGL 的厨师每炒完一道菜都要刷锅、重新生火、把半成品从冰箱搬出来——这些“串行擦锅”时间省不掉。WebGPU 的备菜专员能一口气预处理几十份食材，让炒菜环节几乎不间断。所以不是 WebGPU 厨师手速更快，而是它把更多环节变成了“并行备菜”，把 WebGL 那套反复搬运和状态切换的串行损耗砍到了最低。

S=1(1−p)+pnS = \frac{1}{(1-p) + \frac{p}{n}}
这个公式告诉我们：整体加速比不是简单地“核心数翻倍、速度翻倍”，而是被程序中无法并行的部分死死卡住。一行串行代码，就能让无限多的并行核心干瞪眼。
  1. 串行比例$1-p$ 代表任务中无法并行的部分。WebGL 因固定管线的状态切换与纹理读写，串行开销占比远高于 WebGPU。
    1−p1-p
  2. 并行分摊$\frac{p}{n}$ 表示可并行部分被 $n$ 个并行单元分摊后的耗时。WebGPU 的 compute shader 能同时调度更多核心。
    pn\frac{p}{n}
  3. 加速后总耗时$(1-p) + \frac{p}{n}$ 是并行化后的总运行时间——串行部分原样保留，并行部分被压缩。
    (1−p)+pn(1-p) + \frac{p}{n}
  4. 加速比$S$ 是原始耗时（视为 1）与加速后耗时的比值。当 $p$ 越接近 1、$n$ 越大，$S$ 越大。
    1(1−p)+pn\frac{1}{(1-p) + \frac{p}{n}}

内存占用对比

第二个视角：食材区（显存）的占用。AI 模型推理时，显存里同时住着三类数据：权重参数、中间激活值、运行时缓冲。WebGL 没有专门的计算内存抽象，中间结果要写进纹理，下一次计算再读出来，一来一回就是两份拷贝——就像食材切完只能放在砧板上，做下一道菜之前砧板腾不出来，整个备菜区始终乱糟糟。

WebGPU 的内存模型先进得多：开发者用 Buffer 和 Bind Group 精确声明数据的存放位置、访问权限和生命周期，同一个 Buffer 可以在多次 dispatch 间复用。中间激活值可以被就地更新，不再需要反复纹理读写。这在长序列的 Transformer 推理中尤其关键，因为激活值随序列长度线性增长，还会被多个算子层接力引用。

显存占用估算公式：

在长序列 LLM 推理中，中间激活值往往超过权重本身。WebGPU 的 Buffer 复用机制能让这些激活值在同一个“备菜台”上反复使用，而 WebGL 的纹理读写则需要在砧板和冰箱之间来回搬食材，内存峰值轻松翻倍。对 8GB 显存的普通笔记本来说，这往往就是“跑得动”和“直接浏览器崩溃”的分界线。

M=W+B×L×H×FM = W + B \times L \times H \times F
总显存约等于权重参数加上中间激活张量，其中 $B$ 是批大小，$L$ 是序列长度，$H$ 是隐藏层维度，$F$ 是字节宽度。
  1. 权重参数$W$ 是模型权重体积，只要模型加载就必须占用显存。
    WW
  2. 激活张量元素数$B \times L \times H$ 是单个中间激活张量的元素总数，它随序列长度线性膨胀。
    B×L×HB \times L \times H
  3. 字节宽度$F$ 是每个元素占的字节数，fp32 为 4 字节，fp16 为 2 字节。
    FF
  4. 总占用权重与激活相加，得到推理时的显存上界。
    W+B×L×H×FW + B \times L \times H \times F

算子支持差异

菜谱数量决定菜品上限。ONNX Runtime Web 等推理框架对不同后端的算子支持做过详细统计：WebGPU 后端原生支持 150+ 个算子，包括 MatMul、Softmax、LayerNorm 等神经网络核心算子；而 WebGL 后端因缺乏计算管线，大量算子要用片元着色器以“画像素”的方式模拟，原生支持的算子屈指可数，其余全靠 workaround 拼凑。

算子覆盖率公式：

想象一下：WebGL 厨房的菜谱上只有 20 道菜，想做第 21 道“蒜蓉粉丝蒸大虾”，只能把虾剁碎混进蒸蛋里凑合；WebGPU 厨房的菜谱有 150 道，绝大多数菜都能直接照谱做。对开发者而言，算子覆盖率直接决定你能在浏览器里跑多大的模型——很多 WebGL 上跑不动的 Transformer 模型，WebGPU 开箱即食，这就是为什么 Transformers.js 等框架把 WebGPU 作为首选的浏览器推理后端。

C=SmaxSmax+SmissC = \frac{S_{max}}{S_{max} + S_{miss}}
分子是后端原生支持的算子数量，分母是推理模型实际需要的算子总量。覆盖率越高，“绞尽脑汁做替代菜”的环节就越少。
  1. 已支持算子数$S_{max}$ 是后端正向支持的算子数量，WebGPU 覆盖了绝大多数神经网络算子。
    SmaxS_{max}
  2. 缺失算子数$S_{miss}$ 是需要用模拟方案补齐的算子数量。
    SmissS_{miss}
  3. 覆盖率$C$ 越接近 1，说明后端越“省心”；$C$ 低则意味着大量算子要绕路实现，性能与数值稳定性都打折扣。
    SmaxSmax+Smiss\frac{S_{max}}{S_{max} + S_{miss}}

迁移成本评估

想从 WebGL 翻新成 WebGPU？先算预算。这不是换个水龙头，而是把整个厨房敲掉重来：

  • API 层面：WebGL 的 gl.drawArrays、gl.bindTexture 等上百个 API 全部废弃，换成 WebGPU 的 device.createBuffer、renderPassEncoder.draw 等全新的对象模型。
  • 着色器层面：GLSL 换成 WGSL，语法、线程模型和内存模型完全不同，所有 shader 代码需要逐行重写。
  • 内存管理层面：WebGL 的纹理与缓冲是隐式管理，WebGPU 需要显式分配、绑定、释放，开发心智负担更大。

迁移成本估算公式：

不过好消息是：如果你的项目用了 ONNX Runtime Web 这类跨后端推理引擎，前端业务代码完全不用动，只需要把执行提供器从 webgl 换成 webgpu——相当于厨房没动，只是换了个更懂行的厨务总监。这也是“框架层抽象”对前端 AI 工程最大的价值：它把翻新厨房的预算，压缩成了一张新菜谱的价格。

Ctotal=Llines×Rrate+TtestC_{total} = L_{lines} \times R_{rate} + T_{test}
$L_{lines}$ 是要重写的代码行数，$R_{rate}$ 是每行代码的平均改写成本，$T_{test}$ 是跨浏览器兼容性测试的固定成本。
  1. 改写代码行数$L_{lines}$ 是现有 WebGL 代码中需要重写的行数。直接调用 WebGL API 的项目几乎等于全部重写。
    LlinesL_{lines}
  2. 单位改写成本$R_{rate}$ 是每行代码的改写人工成本。WGSL 的内存模型比 GLSL 复杂，单位成本也更高。
    RrateR_{rate}
  3. 测试固定成本$T_{test}$ 是跨浏览器回归测试的固定支出。WebGPU 在不同厂商驱动上的行为差异需要专门适配。
    TtestT_{test}
  4. 总成本三项相加得到迁移总预算。
    Llines×Rrate+TtestL_{lines} \times R_{rate} + T_{test}

迁移注意事项

翻新过程有几个“工艺陷阱”，踩进去轻则算错，重则页面崩溃。

陷阱一：FP16 精度陷阱。 WebGL 在移动端大概率让片元着色器使用 fp16 运算，精度损失不可控；WebGPU 允许你显式声明使用 fp32 还是 fp16。精度误差公式：

对 Transformer 推理而言，LayerNorm 这类对数值精度敏感的算子如果被悄悄压成 fp16，轻则输出漂移，重则概率分布完全错乱。迁移到 WebGPU 时，务必对精度敏感算子显式声明 fp32，避免“看似在跑、实则乱算”。

陷阱二：异步缓冲映射。 WebGPU 的 buffer 映射（把 GPU 计算结果读回 CPU）是异步的，需要 await buffer.mapAsync()，不能像 WebGL 那样同步 gl.readPixels。这意味着推理代码从“顺序执行命令”变成“处理 Promise 回调”，控制流复杂度明显上升。如果忘记 await，拿到的就是空数据。

陷阱三：浏览器兼容性。 WebGPU 在 Chrome 113+、Edge 113+、Safari 26+ 已默认启用，但 Firefox 目前仍只支持实验性实现。如果用户群体还有相当比例用 Firefox 或旧版本系统浏览器，盲目全量切换会导致这些用户完全无法使用服务。生产环境必须做能力检测，并准备降级到 WebGL 或 WASM 后端的备用路径。

ϵ=∣xfp16−xfp32∣∣xfp32∣\epsilon = \frac{|x_{fp16} - x_{fp32}|}{|x_{fp32}|}
该公式表示 fp16 相对 fp32 的相对误差。fp16 的尾数只有 10 位，最大相对误差约 $2^{-11} \approx 4.88 \times 10^{-4}$。
  1. 绝对误差$|x_{fp16} - x_{fp32}|$ 是 fp16 四舍五入后的值与原始 fp32 值之间的差值。
    ∣xfp16−xfp32∣|x_{fp16} - x_{fp32}|
  2. 相对化除以 $|x_{fp32}|$，把绝对误差归一化成不依赖数值量纲的比例。
    ∣xfp16−xfp32∣∣xfp32∣\frac{|x_{fp16} - x_{fp32}|}{|x_{fp32}|}
  3. 误差上界标准 fp16 的相对误差最大约 $2^{-11}$，即小数点后第 4 位开始失真。
    2−112^{-11}

选型建议指南

知道了差距、成本、坑位，最后落到一句话：什么菜用什么锅。

  • 模型参数量百万以下、批处理场景单一：WebGL 完全够用，迁移收益不明显，维持现状更划算。
  • 参数量千万级以上、序列长度长、或需要低延迟交互：WebGPU 的吞吐优势成倍放大，值得迁移。
  • 用户浏览器环境不确定：采用渐进式部署，优先加载 WebGPU 后端，检测失败时自动降级到 WebGL。

性能需求的估算公式：

选型本质是对需求量级做预算：当模型总 FLOPs 远低于 GPU 峰值算力时，WebGL 的瓶颈暴露不出来；一旦接近，WebGPU 的并行优势就会从“略有盈余”变成“天壤之别”。一个务实的建议是：在项目初期就抽象出统一的“算子执行器”接口，让 WebGL 与 WebGPU 都实现它——这样翻新厨房的预算，已经提前摊进了装修图纸里。

F=Ccores×fclock×IF = C_{cores} \times f_{clock} \times I
这是 GPU 单精度峰值算力的简化公式：核心数 × 时钟频率 × 每周期指令数，单位是 FLOPS（每秒浮点运算次数）。
  1. 并行核心数$C_{cores}$ 是 GPU 可调用的逻辑执行单元数量。WebGPU 能触及更完整的计算单元。
    CcoresC_{cores}
  2. 时钟频率$f_{clock}$ 是核心运行频率，由硬件决定，浏览器只能通过节能策略间接影响。
    fclockf_{clock}
  3. 每周期指令数$I$ 是每个时钟周期每个核心能执行的浮点运算次数。
    II
  4. 峰值算力三者相乘得到 GPU 的 FLOPS 上界。模型总计算量除以峰值，就是理论最低耗时。
    Ccores×fclock×IC_{cores} \times f_{clock} \times I

AI 应用场景

浏览器端大模型推理引擎

阶段：推理部署

解决的问题：传统方式把大模型推理放在云端 GPU，延迟高、有隐私暴露风险、还要承担服务器成本。使用 Transformers.js 结合 WebGPU 后端，可以直接在浏览器本地运行十亿参数级别的量化模型，用户数据不出设备。

具体案例：某在线文档平台需要做“文档总结”功能。以往每次总结都请求云端 GPT 服务，单次成本约 0.5 元。改用 WebGPU 本地推理后，延迟从 3 秒降到 800 毫秒，且总结过程完全本地化；对不支持 WebGPU 的浏览器自动降级到 WebGL 的小模型版本。

ONNX Runtime Web 多后端协同

阶段：模型部署与后端选型

解决的问题：ONNX 模型要在浏览器中同时保证性能和兼容性。ONNX Runtime Web 通过统一的算子层抽象，把 MatMul、Conv 等算子分派到 WebGPU EP（执行提供器），对不支持的算子自动回退到 CPU/WASM 实现。

具体案例：一个 YOLOv8 目标检测的 Web 应用，原本用 WebGL 后端推理 640×640 输入需要 90ms；切换到 WebGPU EP 后同样输入只需 28ms，达到了实时视频检测的帧率要求。团队只改了执行提供器的枚举值，业务层代码零改动。

实时音视频 AI 特效处理

阶段：预处理与后处理

解决的问题：音视频会议中的背景分割、噪声抑制等 AI 任务要求极低延迟。WebGL 的数据结构只面向光栅化，难以高效处理像素级的 AI 计算；WebGPU 的 compute shader 可以直接对视频帧缓冲做并行卷积。

具体案例：某在线教育产品在 WebRTC 视频流上叠加“虚拟板书跟随”效果，用 WebGPU 对每一帧做轻量级人体关键点检测与背景差分，整体管线延迟控制在 16ms 以内，在旧笔记本上也能稳定输出 30fps。

Python 演示

python28 行
# 模拟 WebGL 与 WebGPU 在矩阵乘法上的吞吐量差异# 用并行单元数量作为两者的主要性能分水岭  def matmul_flops(n):    """矩阵乘法计算量约 2 * n^3 FLOPs"""    return 2 * n ** 3  def estimate_ms(flops, parallel_units, unit_speed=1e9):    """估算耗时毫秒: FLOPs / (并行单元数 * 单单元算力)"""    return flops / (parallel_units * unit_speed) * 1000  def benchmark():    sizes = [128, 256, 512, 1024]    print("矩阵规模  |  WebGL(ms)  WebGPU(ms)  加速比")    print("-" * 48)    for n in sizes:        flops = matmul_flops(n)        webgl_time = estimate_ms(flops, parallel_units=24)        webgpu_time = estimate_ms(flops, parallel_units=96)        speedup = webgl_time / webgpu_time        print(f"{n:>6}x{n:<6} | {webgl_time:8.2f}   {webgpu_time:8.2f}   {speedup:4.2f}x")  if __name__ == "__main__":    benchmark()
目的：用最简单的算力模型演示 WebGPU 因并行单元数更多，在矩阵乘任务中获得的稳定加速比。
  1. matmul_flops(n)用 $2n^3$ 估算矩阵乘的总浮点运算量，对应正文“模型总计算量决定理论最低耗时”的逻辑。
  2. estimate_ms(flops, parallel_units, unit_speed=1e9)除以并行单元数和单单元算力，再换算成毫秒，模拟并行部分被多个核心分摊的效果。
  3. benchmark()对四组矩阵规模逐一测算两种“后端”耗时并打印加速比。可以看到加速比接近 4 而非整数倍，因为矩阵规模较小时串行开销占比更高，直观呼应正文的 Amdahl 分析。
  4. __name__ == "__main__"保证脚本被 import 时不会立即执行，符合工程化习惯。

常见误区

误区WebGPU 名字里带 Web，前面又有 WebGL 打底，直觉上觉得它只是 WebGL 的 API 升级，调用方式类似，改改参数就能用。

正解两者的设计哲学完全不同。WebGL 源自 OpenGL ES 渲染管线，核心是“画三角形”；WebGPU 源自 Direct3D 12 和 Metal 的通用计算模型，核心是“调度 GPU 算力”。API 对象、着色器语言（GLSL vs WGSL）、内存模型全部重新设计。它更像是从“升级蒸锅”变成了“整个厨房重建”，而非换个锅盖。

为何常见：名称相似加上两者都在浏览器图形场景出现，用户很容易把“新的 Web 图形 API”归入“旧 API 的后续版本”这一认知框架。

误区既然基准测试说 WebGPU 快 3~8 倍，那把 ONNX Runtime 的执行提供器从 webgl 改成 webgpu，所有模型都会自动获得同样的提升。

正解加速效果高度依赖算子类型和模型结构。compute shader 对矩阵乘、卷积这类规则并行任务提升显著；但对含大量 if-else 分支的稀疏算子、或小 batch 的逐元素操作，提升可能很小甚至因为调度开销反而变慢。而且如果自定义 shader 没按 WGSL 的线程组模型优化，性能可能还不如 WebGL。

为何常见：性能对比通常展示最优场景的加速比，读者容易把“代表性数字”外推成“所有场景的保证”。

误区Chrome 都默认支持了，那主流浏览器应该都差不多了，上线 WebGPU 功能没有兼容性风险。

正解Firefox 的 WebGPU 至今仍是实验性实现；Safari 到 26 版本才默认启用；移动端浏览器的 WebGPU 行为与桌面端存在差异。真实项目必须做能力检测与降级方案，WebGL 依然是兜底选择。

为何常见：开发者往往以自己使用的 Chrome 为准，忽略了企业用户环境中大量存在的旧版浏览器和 Firefox。

误区WebGL 用 GLSL 写 float 就是标准的 IEEE 754 单精度，跟桌面 OpenGL 完全一致，精度不会有问题。

正解WebGL 规范允许实现把片元着色器中的 float 降为 fp16 存储，移动端 GPU 为了省电与带宽几乎都会这么做。也就是说，同一段着色器在桌面端是 fp32、在移动端悄悄变成 fp16，结果不可复现。WebGPU 的可编程管线允许显式约束精度，反而是精度更可控的一方。

为何常见：PC 端开发调试时永远看不到精度差异，Bug 只在真机用户设备上暴露，于是被归因为“玄学问题”。

误区WebGL 缺算子就自己写个 shader 模拟，顶多多花半天时间，本质上不影响项目进度。

正解用片元着色器模拟 MatMul 或 LayerNorm 不是“多写几行”，而是把计算逻辑硬塞进光栅化框架：要控制像素坐标与计算坐标的映射、处理纹理读写边界、忍受精度损失和数据搬运开销。每模拟一个算子都可能引入 2~5 倍的性能回退，多个模拟算子叠加，最终推理延迟甚至比不用 GPU 还差。这也是很多 Transformer 模型在 WebGL 上根本无法落地的重要原因。

为何常见：单个算子的 workaround 看起来简单，容易低估它在完整模型链路中的累积代价。

面试题

Q1. WebGPU 相比 WebGL 最本质的能力变化是什么？

单选题 · easy

  • A.更快的 CSS 渲染引擎
  • B.引入通用计算管线← 正确答案
  • C.支持所有 HTML 标签
  • D.自动优化 JavaScript 代码

答案：B。WebGPU 的核心突破是引入 compute pipeline，让 GPU 可以执行与图形无关的通用计算任务。A 是浏览器渲染引擎职责，C 和 D 与 GPU 抽象无关。

Q2. WebGPU 使用的着色器语言是？

单选题 · easy

  • A.GLSL
  • B.HLSL
  • C.WGSL← 正确答案
  • D.MetalSL

答案：C。WGSL（WebGPU Shading Language）是 WebGPU 官方着色器语言。GLSL 属于 WebGL，HLSL 属于 Direct3D，MetalSL 属于 Apple Metal。

Q3. 在 WebGL 中模拟非图形计算通常依赖哪种着色器？

单选题 · mid

  • A.顶点着色器
  • B.片元着色器← 正确答案
  • C.几何着色器
  • D.计算着色器

答案：B。WebGL 没有计算着色器，开发者只好用片元着色器逐像素执行计算，再把结果编码进纹理。这就是“用画像素的方式做计算”的 workaround。

Q4. 已知可并行比例 p=0.8、核心数 n=4，Amdahl 加速比是多少？

单选题 · mid

  • A.2.0
  • B.2.5← 正确答案
  • C.3.2
  • D.4.0

答案：B。S = 1 / ((1-0.8) + 0.8/4) = 1 / (0.2 + 0.2) = 2.5。串行 20% 的时间被固定保留，即使核心无限多加速比也上不了 5，这正是 WebGL 高串行开销的瓶颈注脚。

Q5. 同等模型条件下，WebGPU 内存占用通常低于 WebGL 的主要原因是？

单选题 · mid

  • A.自动压缩权重参数
  • B.显式 buffer 复用中间激活← 正确答案
  • C.显存容量上限更高
  • D.使用整数代替浮点数

答案：B。WebGPU 的 Buffer 与 Bind Group 机制让中间结果能在多次 dispatch 间复用，避免 WebGL 纹理读写产生的双重拷贝。权重压缩、显存上限和整数替换都不是规范层面的内存优化手段。

Q6. 关于 WebGPU 缓冲映射（buffer mapping）的正确描述是？

单选题 · hard

  • A.同步阻塞操作
  • B.必须等待 Promise 完成← 正确答案
  • C.只能映射一次
  • D.映射期间 GPU 照常运行

答案：B。WebGPU 的 mapAsync 是异步 API，必须 await 其结果以避免阻塞主线程。映射期间 GPU 不能访问该 buffer，但主线程可继续其他工作。这与 WebGL 的同步 readPixels 截然不同。

Q7. 以下哪个浏览器最早默认启用 WebGPU？

单选题 · easy

  • A.Chrome 113← 正确答案
  • B.Firefox 126
  • C.Safari 17
  • D.Edge 90

答案：A。Chrome 113（2023 年 4 月）最早在桌面版默认启用 WebGPU。Firefox 至今仍是实验性实现，Safari 在 26 版本才默认开启，Edge 90 时代 WebGPU 尚未成熟。

Q8. 从 WebGL 迁移到 WebGPU 的主要改造成本包括哪些？

多选题 · mid

  • A.渲染 API 全部重写← 正确答案
  • B.GLSL 迁移到 WGSL← 正确答案
  • C.内存管理模型重构← 正确答案
  • D.HTML 结构重新设计

答案：ABC。迁移涉及 API、着色器语言和内存管理三层重构，但 HTML/CSS 是平台层内容，与 GPU 后端无关，不需要改动。

Q9. WebGPU 相对 WebGL 性能提升的根源有哪些？

多选题 · hard

  • A.更低的 API 调用开销← 正确答案
  • B.compute shader 原生并行计算← 正确答案
  • C.显式内存复用减少拷贝← 正确答案
  • D.浏览器自动生成高质量 JS 代码

答案：ABC。WebGPU 的对象模型和命令编码器降低了 CPU 侧调用成本；compute shader 让算法直接映射到硬件的并行结构；显式 buffer 复用减少中间数据搬运。浏览器不会修改用户的 JS 代码。

Q10. 关于 WebGL 与 WebGPU 精度问题，哪些说法正确？

多选题 · extreme

  • A.桌面 WebGL 多数为 fp32 运算← 正确答案
  • B.移动端 WebGL 可能降为 fp16← 正确答案
  • C.WebGPU 强制全部使用 fp32
  • D.WebGPU 可显式选择 fp32 或 fp16← 正确答案

答案：ABD。WebGL 的实现可自行决定片元精度，移动端普遍降为 fp16，桌面端多数保持 fp32。WebGPU 让开发者在管线中显式声明精度，但不强制只用 fp32，fp16 是可选的优化特性。