小码开了一家餐厅，生意红火，但有个烦恼：客人越来越多，后厨却只有一位大堂经理兼任大厨。经理记性好、手艺全，可一次只能做一道菜；遇到需要“AI定制菜”（比如根据客人表情推荐口味）的订单，他甚至要把客人的照片传到云端中央厨房，等结果传回来。客人等得烦躁，隐私也提心吊胆。 后来，装修师傅（浏览器厂商）给餐厅装了一套“工业后厨”：里面有一百位专职厨工（GPU核心）。他们每个人只会简单的切配动作，但一百人同时开工，几十秒就能备好几百份菜。更棒的是，整个备餐过程都在餐厅内部完成，不用再把食材（数据）送出去。这套后厨，就是 WebGPU。

岗位关联

对 AI 从业者来说，掌握 WebGPU 浏览器端推理，意味着能把模型直接部署到用户设备上——这是构建隐私友好、零部署延迟、低运营成本的端侧 AI 应用的核心技能。

目录
  1. 可视化演示
  2. 浏览器算力觉醒
  3. 计算管线调度
  4. WGSL着色语言
  5. 模型量化加载
  6. 推理性能优化
  7. 生态兼容展望
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示WebGPU计算管线、WGSL着色器工作组并行执行、模型量化(FP32→INT4)部署方案及WebGPU/WebGL/WASM/CPU性能对比，含星座网络背景和发光动画。

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

浏览器算力觉醒

小码最先发现的瓶颈，是那位大堂经理。CPU（中央处理器）像极了一位全能型人才：什么任务都能做，但一次只能专注做一件。让他在“收银、接待、传菜”之间来回切换，效率自然上不去。浏览器里的 JavaScript 也是这样单线程顺序干活，处理神经网络里的矩阵乘法这类海量重复运算时，CPU 非常吃力。

那能不能借用后厨的老灶台（WebGL）？WebGL 本来是专门用来“炒菜”（渲染图形）的。有人想让它做通用计算，只能把数字伪装成像素颜色的纹理，塞进片元着色器里炒一遍，再把像素读回来。这就像拿蒸锅去烙饼——能用，但别扭极了，还有精度损失和数据回传的额外开销。

WebGPU 正是为改变这一局面而生的新一代浏览器图形与计算接口。它包含一条完整的“计算管线”（compute pipeline），允许开发者把数据缓冲交给 GPU，用着色器语言 WGSL 编写并行内核，直接在 GPU 上做通用数值计算，无需经过图形渲染的伪装。这让浏览器端跑轻量 AI 推理（如人脸检测、文本分类、甚至小规模语言模型）成为现实，也带来了数据不出设备、延迟更低、成本更低三大优势。

所以，当小码决定给餐厅升级时，他没有继续修补旧灶台，而是选择重建一套工业厨房——把 AI 的“备菜”全程留在后厨完成。这条流水线，正是 WebGPU 的计算管线。

Cwebgl=C编码+C采样+C读回≫CwebgpuC_{\text{webgl}} = C_{\text{编码}} + C_{\text{采样}} + C_{\text{读回}} \gg C_{\text{webgpu}}
这个公式表示：WebGL 做通用计算的代价（把数据编码成纹理、采样、读回像素）远大于 WebGPU 直接计算的代价。
  1. 编码纹理把浮点数塞进 RGBA 像素通道，相当于把食材打包成“像素罐头”。
    C编码=O(N) 次通道打包C_{\text{编码}} = O(N) \text{ 次通道打包}
  2. 片元采样片元着色器逐像素处理，相当于厨工从罐头里挖菜，精度还会丢失。
    C采样=O(N) 次纹理读取C_{\text{采样}} = O(N) \text{ 次纹理读取}
  3. 像素读回计算结果要从 GPU 传回 CPU，相当于罐头再送回来回拆开。
    C读回=O(N) 次总线拷贝C_{\text{读回}} = O(N) \text{ 次总线拷贝}
  4. 直接计算WebGPU 的数据在显存就地处理，一步到位。
    Cwebgpu=O(N) 次并行计算C_{\text{webgpu}} = O(N) \text{ 次并行计算}

计算管线调度

工业后厨的核心，是一条被严格设计过的“备餐流水线”。食材（数据）先被码上传送带，厨工们按固定流程完成切、配、炒，最后把成品端到出餐口。WebGPU 的计算管线就像这条流水线，有五个固定环节。

第一步，把神经网络权重和输入数据放进 GPUBuffer（备餐传送带）；第二步，通过绑定组（bind group）把缓冲挂到指定的物料架上，告诉 GPU“从哪儿取菜、放到哪儿”；第三步，用 dispatchWorkgroups（调度）命令按组唤醒厨工；第四步，执行 WGSL 编写的计算着色器内核；第五步，把结果从存储缓冲读回，或用渲染管线直接展示。

调度模型是理解并行的关键。你可以声明一个三维网格的工作组数量，每个工作组（workgroup）内部又有固定数量的线程。总线程数等于这两者的乘积。GPU 会把这些线程尽可能均匀地分配给所有核心，这就是“一百个厨工同时切菜”的底层原理。

小码看完流水线设计恍然大悟：备餐快慢不取决于掌勺一个点，而取决于整条线的组织是否整齐。管线里的每种角色各司其职，才有可能在高峰期支撑几百份订单同时准备。

Nthreads=Gx×Gy×Gz⏟工作组网格×Wx×Wy×Wz⏟每组线程数N_{\text{threads}} = \underbrace{G_x \times G_y \times G_z}_{\text{工作组网格}} \times \underbrace{W_x \times W_y \times W_z}_{\text{每组线程数}}
总线程数 = 工作组网格大小 × 每组线程数。组内线程可以共享一块“台面”（显存），协作效率更高。
  1. 工作组网格 G三维网格，每个维度表示某方向有多少组厨工围台。
    G=Gx×Gy×GzG = G_x \times G_y \times G_z
  2. 组内线程 W每个组里坐多少厨工，常用 8×8=64 或 8×8×1。
    W=Wx×Wy×WzW = W_x \times W_y \times W_z
  3. 总线程两者相乘得到全体并行执行的“人手”总数。
    Nthreads=G×WN_{\text{threads}} = G \times W

WGSL着色语言

有了流水线，还得给每位厨工一套统一的操作手册，否则一百个人各切各的，菜品必然五花八门。WGSL（WebGPU Shading Language）就是这份手册，它是一种专门描述“每个线程要做什么”的语言。

WGSL 的计算着色器用 @compute 标注，@workgroup_size(8,8,1) 声明每组 64 个线程。入口函数可以读取内置变量 global_invocation_id（每个厨工胸前的编号），从而知道“我是谁、该处理哪一块数据”。因为每个线程执行同一份代码，但编号不同，操作的数据也就不同——这正是并行计算的核心思想，通常称为 SIMT（单指令多线程）。

以最简单的“矩阵乘向量”为例：模型的一层可以看作输入向量与权重矩阵相乘，矩阵的每一行对应一个输出神经元。可以让第 i 个线程负责第 i 行，做一次点积并写回结果。这样 M 行就由 M 个线程并行完成，比 CPU 上一行一行循环快了一个数量级。

小码把操作手册发给每位厨工后，发现大家虽然只做“切、配”这种小事，但配合起来，整条流水线跑得比任何单打独斗都快。WGSL 的优雅之处，就在于把“并行”这件复杂事简化成了“每个线程做好自己的编号对应的工作”。

out[i]=∑k=0K−1input[i⋅K+k]×weight[k]\text{out}[i] = \sum_{k=0}^{K-1} \text{input}[i \cdot K + k] \times \text{weight}[k]
每个线程计算输出向量的一个元素，对输入与权重的对应位置做加权求和。
  1. 全局编号 i由 global_invocation_id.x 拿到，决定该线程负责第几行。
    i=global_invocation_id.xi = \text{global\_invocation\_id}.x
  2. 点积求和一行权重与输入逐项相乘再累加。
    s=∑k=0K−1wi,k×xks = \sum_{k=0}^{K-1} w_{i,k} \times x_k
  3. 写回结果把累加结果存到输出缓冲的对应位置。
    out[i]=s\text{out}[i] = s

模型量化加载

餐厅要在高峰时段快速出餐，总不能每次都从活鱼活鸡开始处理。聪明的做法是提前把食材做成真空半成品：体积小、耐储存、拆包就能下锅，口味虽然略逊于现杀现做，但客人基本分辨不出来。模型量化就是这个思路：把神经网络权重的 FP32 浮点数“包装”成 INT8 整数。

一个 FP32 参数占 4 字节，INT8 只占 1 字节，模型体积直接缩小 4 倍，显存占用和传输带宽也随之大幅下降。量化的核心是找到缩放因子 scale 和零点 zero_point，把浮点范围的数值映射到 [-128, 127] 的整数区间。推理时 GPU 用整数做乘法累加（通常以 INT32 累加避免溢出），最后再乘回 scale 恢复近似结果。

加载流程在浏览器中也变得清晰：用 fetch 下载量化后的模型文件，解析权重为 ArrayBuffer，再以 GPUBuffer 上传到显存。由于数据已是 INT8，省去了运行时格式转换的开销。虽然量化会带来一点精度损失，但对 8bit 量化来说，通常模型精度下降不足 1%，换来的却是 4 倍体积缩减和更快的访存速度。

小码把厨房里那些“现杀食材”全部换成了真空半成品后，出餐速度肉眼可见地快起来，而客人几乎尝不出差别。量化让模型得以塞进浏览器这块“小备餐台”，是端侧推理真正落地的关键一步。

q=round⁡ ⁣(xscale)+z,x^=(q−z)×scaleq = \operatorname{round}\!\left(\frac{x}{\text{scale}}\right) + z, \qquad \hat{x} = (q - z) \times \text{scale}
量化公式：先按缩放因子把浮点压缩到整数区间并取整，推理后再按公式还原近似浮点值。
  1. 缩放因子 scale把浮点数的动态范围按比例缩到 255 格内，类似给每份菜规定“小碗份量”。
    scale=max⁡∣x∣27−1\text{scale} = \frac{\max|x|}{2^{7} - 1}
  2. 取整 round压缩后的值是小数，四舍五入成整数。
    q′=xscale,q=round(q′)q' = \frac{x}{\text{scale}}, \quad q = \text{round}(q')
  3. 零点偏置 z让整数区间能表达正负浮点，相当于调整坐标原点。
    z=round(−min⁡q′)z = \text{round}(-\min q')
  4. 反量化推理结果从整数还原成浮点近似值。
    x^=(q−z)×scale\hat{x} = (q - z) \times \text{scale}

推理性能优化

周末晚高峰，订单像雪片一样飞来。只靠加人（加线程）还不够，聪明的后厨有三板斧：一次烹制多份相同的菜（批处理）、循环利用备餐台和锅具（内存复用）、边蒸边切让各环节并行（流水线重叠）。

批处理（batch）把多张输入图片打包成一批同时推理，摊薄每次调度的固定开销，提升 GPU 利用率。内存复用则是预分配一组显存缓冲池，推理过程中反复使用，避免频繁创建和释放，同时用 ping-pong 缓冲让本次计算与下次上传重叠。流水线重叠利用 queue.submit 与 mapAsync 的异步特性，在 GPU 计算的同时完成下一批数据的 CPU→GPU 拷贝。

性能能提升多少，有一条著名的经验法则——Amdahl 定律。程序里可并行部分占比为 p，串行部分占比固定为 (1-p)，当核心数为 N 时，加速比 S 的极限是 1/(1-p)。即使并行核心无限多，串行的部分（如数据加载、启动调度）依然决定性能天花板。所以优化既要扩大并行比例，也要把串行瓶颈（比如模型加载、格式化）提前缓存好。

小码用这三板斧重新排班后，晚高峰的出餐速度几乎翻倍，而他也清楚，真正的瓶颈其实是那台唯一的烤箱（串行部分）。优化，就是一边扩并行，一边啃掉串行硬骨头。

S=1(1−p)+pNS = \frac{1}{(1-p) + \dfrac{p}{N}}
加速比极限：当 N 趋向无穷大，加速比最多是 1/(1-p)。并行救不了串行瓶颈。
  1. 可并行比例 p整条流水线能交给百人团同时干的工序占比。
    p=TparallelTtotalp = \frac{T_{\text{parallel}}}{T_{\text{total}}}
  2. 串行部分必须一个人排队完成的比例，决定性能天花板。
    1−p1 - p
  3. 核心数 N厨工越多，并行时间越短，p/N 趋向 0。
    pN→0\frac{p}{N} \to 0
  4. 总加速比并行节省的时间折算成整体加速。
    S=ToldTnew=1(1−p)+p/NS = \frac{T_{\text{old}}}{T_{\text{new}}} = \frac{1}{(1-p) + p/N}

生态兼容展望

工业厨房设备虽好，但得看餐厅所在的楼房通没通燃气。WebGPU 的浏览器兼容性也是如此：Chrome、Edge、Firefox 已基本支持，Safari 也宣布了支持路线图。前端工程师首先要做的，是检查后厨有没有“接通燃气”——用 navigator.gpu 是否存在做特性检测。

与 WebGL 相比，WebGPU 不只是“新版本的图形库”，而是把图形和计算统一到同一套底层硬件抽象层上。WebGL 只擅长渲染，通用计算要靠纹理伪装；WebGPU 的计算管线天生适合 AI 算子，能直接映射到 GPU 的并行架构，性能与可控性都更优。

生态方面，推理框架正迅速跟上：Transformers.js 已支持通过 WebGPU 后端运行 BERT、CLIP 等模型；WebLLM 可以在浏览器中用 WebGPU 跑小规模 LLM（如 1B 参数的 Qwen）；ONNX Runtime Web 也提供 WebGPU 加速的算子实现。开发者可以在浏览器里以接近原生 GPU 的速度运行轻量模型，且无需安装任何依赖。对于实时交互应用，单帧耗时需控制在 16.7ms 内，端侧推理配合 WebGPU 已能覆盖大部分场景。

小码的餐厅已经装好了新厨房，但他没有急着扔掉旧灶台——遇到“没通燃气”的客人订外卖，他依然用外卖平台（CPU/WASM 回退方案）接单。兼容性处理，是工程师走向生产环境的必修课。

Tframe=1000 msFPS≤16.7 msT_{\text{frame}} = \frac{1000\,\text{ms}}{\text{FPS}} \le 16.7\,\text{ms}
60 FPS 的交互体验要求每帧计算不超过约 16.7 毫秒，这是端侧推理的实时性目标。
  1. 帧预算一秒 60 帧，每帧的时间预算只有 16.7ms。
    Tframe=1000/60≈16.7 msT_{\text{frame}} = 1000 / 60 \approx 16.7\,\text{ms}
  2. 推理耗时单次前向推理必须小于帧预算，否则界面卡顿。
    Tinfer<TframeT_{\text{infer}} < T_{\text{frame}}
  3. 特性检测环境不支持时优雅降级到 CPU/WASM 方案。
    gpu=navigator.gpu ? WebGPU:WebGL\text{gpu} = \text{navigator.gpu} \,\text{?}\, \text{WebGPU} : \text{WebGL}

AI 应用场景

实时美颜与虚拟试妆

阶段：端侧推理部署

解决的问题：传统美颜要把视频帧上传到云端做人脸关键点检测，延迟高、带宽贵、隐私风险大。WebGPU 让人脸检测模型在浏览器本地 GPU 上实时运行，帧延迟可控制在 16.7ms 以内。

具体案例：某视频会议产品在浏览器端用 MediaPipe 人脸网格模型 + WebGPU 后端，在用户本地完成 468 点人脸关键点检测，再叠加 AR 美妆滤镜，视频数据全程不出设备。

浏览器本地 OCR 与文档翻译

阶段：模型量化加载 + 推理

解决的问题：在线文档工具处理敏感合同、病历等资料时，过去必须上传服务器识别，合规风险大。量化后的 OCR 小模型（约 20MB）可在浏览器加载，配合 WebGPU 加速文本检测与识别，敏感数据永不离开终端。

具体案例：某在线网盘工具用 Transformers.js 的 OCR pipeline 走 WebGPU 后端，在浏览器端直接提取扫描件文字，用户可离线完成识别与翻译，云端只存脱敏后的文本结果。

浏览器端 AI 代码补全助手

阶段：推理性能优化 + 端侧部署

解决的问题：云端代码补全延迟高、网络不稳定，且公司代码不能外传。WebLLM 可在浏览器内加载 1B 级代码模型，配合 INT8 量化在 WebGPU 上以流式方式生成补全建议，敏感代码完全留在本地。

具体案例：某 IDE 插件将量化小模型打包进离线包，启动时用 fetch 流式加载权重，在浏览器扩展的 offscreen document 中通过 WebGPU 跑推理，补全延迟低于 100ms。

Python 演示

python54 行
import numpy as np  def quantize(x, bits=8):    """FP32 -> INT8 对称量化：为矩阵找到缩放因子并取整。"""    amax = np.abs(x).max() + 1e-12    scale = amax / (2 ** (bits - 1) - 1)    q = np.round(x / scale).astype(np.int8)    return q, scale  def quantized_matmul(A, B, bits=8):    """用 INT8 乘法 + INT32 累加模拟 GPU 上的量化矩阵乘法。"""    qa, sa = quantize(A, bits)    qb, sb = quantize(B, bits)    acc = qa.astype(np.int32) @ qb.astype(np.int32)    return acc * sa * sb, qa, sa  def simulate_gpu_latency(params_mb, bandwidth_gbps=200.0):    """按显存带宽估算一次全量参数读取的用时（毫秒）。"""    bytes_total = params_mb * 1024 * 1024    time_ms = bytes_total / (bandwidth_gbps * 1e9 / 1e3)    return time_ms  def simulate_batch_speedup(batch, per_item_ms=8.0, fixed_overhead_ms=4.0):    """模拟批处理摊薄固定开销后的单均耗时。"""    return (fixed_overhead_ms + per_item_ms * batch) / batch  def main():    np.random.seed(42)    A = np.random.randn(128, 64).astype(np.float32)    B = np.random.randn(64, 128).astype(np.float32)     ref = A @ B    out, qa, sa = quantized_matmul(A, B)    err = np.abs(out - ref).mean() / np.abs(ref).mean()    print("平均相对误差: {:.4f}".format(err))    print("FP32 矩阵体积: {:.0f} KB".format(A.nbytes / 1024))    print("INT8 矩阵体积: {:.0f} KB".format(qa.nbytes / 1024))    print("体积比: {:.1f}x".format(A.nbytes / qa.nbytes))     latency = simulate_gpu_latency(128, 200.0)    print("128MB 模型参数全量加载估算: {:.1f} ms".format(latency))     for batch in (1, 4, 16, 64):        avg = simulate_batch_speedup(batch)        print("batch={:2d} 时单均耗时: {:.2f} ms".format(batch, avg))  if __name__ == "__main__":    main()
目的：用 Python 模拟 WebGPU 端侧推理的量化与批处理收益，帮助理解“为什么模型要瘦身、为什么一次处理多张图更快”。
  1. amax = np.abs(x).max() + 1e-12求矩阵最大绝对值作为动态范围，加极小值防止除零。
  2. scale = amax / (2 ** (bits - 1) - 1)把浮点范围压缩到 ±127，得到缩放因子。
  3. q = np.round(x / scale).astype(np.int8)量化取整，对应 GPU 上的 INT8 张量。
  4. acc = qa.astype(np.int32) @ qb.astype(np.int32)模仿 GPU 的 INT8 乘 INT32 累加，避免溢出。
  5. simulate_gpu_latency(128, 200.0)估算 128MB 模型在 200GB/s 带宽下的读取耗时。
  6. (fixed_overhead_ms + per_item_ms * batch) / batch批处理摊薄固定开销，batch 越大单均耗时越低。

常见误区

误区网上教程多是 3D 渲染示例，让我觉得 WebGPU 就是“更炫的 WebGL”，主要用来做游戏和特效，和 AI 推理没什么关系。

正解WebGPU 真正革命性的是新增了计算管线（compute pipeline），让通用并行计算不再绕道图形渲染。回到餐厅比喻：WebGL 是只能炒菜的旧灶台，WebGPU 则是一套能切、配、炒、蒸的全能后厨。浏览器里的 AI 推理正是靠这条计算管线跑起来的，渲染只是它的一部分能力。

为何常见：因为 WebGPU 的入门教程通常以 3D 渲染为切入点，导致初学者先入为主地把它归类为“图形库”。

误区INT8 只有 256 个取值，把模型权重压进去精度肯定断崖式下跌，宁可让模型大一点也不量化。

正解对大部分下游任务，8bit 量化后的精度损失通常不到 1%。好比真空半成品食材：现杀活鱼和超市冷冻鱼排，做熟后端上桌，多数客人吃不出区别。反过来，模型体积缩小 4 倍能让更多设备跑得动，换来的是真实可用性。真正需要警惕的是 4bit 以下的激进量化，而不是 8bit 这一档。

为何常见：网络上流传的“量化翻车”案例往往是 2bit 极端量化，初学者把所有量化一棍子打死。

误区浏览器不是会自动管理内存吗？那我把大模型直接加载进网页，WebGPU 应该能搞定一切。

正解GPU 显存是稀缺资源，浏览器标签页能用的显存通常只有几百 MB 到几 GB。一个 7B 参数的 FP32 模型需要 28GB 显存，浏览器标签页直接崩溃；量化到 INT8 也要约 7GB。所以必须做模型量化、分层加载、峰值显存控制——后厨再大，备餐台也有限。

为何常见：chrome://gpu 里显示的显存数值很大，让人误以为整个显存都能随意使用。

误区Chrome 里跑得挺顺，Safari 应该也差不多，可以放心只写 WebGPU 代码。

正解WebGPU 在 Chromium 系浏览器和 Firefox 已可用，但 Safari 的支持目前仍不完整或默认关闭。上线前要像检查后厨有没有通燃气一样做特性检测：if (navigator.gpu) { ... }，并为不支持的浏览器准备 WebGL 或 CPU/WASM 回退推理后端。

为何常见：开发者日常用 Chrome 调试，容易忽略真实用户环境的浏览器多样性。

误区workgroup_size 设得越大、dispatch 数量越多，并行度越高，推理就一定越快。

正解GPU 核心数量是物理上限，超过后多出来的线程只是在排队等空位；工作组太大还会导致共享内存溢出或调度器无法充分利用。就像后厨只有 100 个工位，安排 1000 个厨工并不会切得更快，反而挤在一起。正确做法是结合目标硬件做基准测试，找到最佳配置。

为何常见：“并行 = 更快”的直觉忽略了硬件资源上限，Amdahl 定律也提醒我们串行部分会拖后腿。

面试题

Q1. WebGPU 相比 WebGL 最核心的突破是什么？

单选题 · easy

  • A.支持更炫的 3D 光影特效
  • B.提供可编程计算管线用于通用计算← 正确答案
  • C.网页可以加载更大的图片
  • D.浏览器不再依赖显卡驱动

答案：B。WebGPU 的革命性在于计算管线，让通用并行计算不再靠纹理伪装。渲染只是它的能力之一，选项 B 正确。A 是表象，C 与主题无关，D 不符合事实——WebGPU 仍依赖显卡驱动。

Q2. 如何检测浏览器是否支持 WebGPU？

单选题 · easy

  • A.检查 window.WebGLRenderingContext 是否存在
  • B.检查 navigator.gpu 是否存在← 正确答案
  • C.检查 GPU 显存是否足够大
  • D.尝试运行一段 WebGL 着色器

答案：B。标准做法是判断 navigator.gpu 是否存在，就像检查后厨是否通燃气。A 和 D 检查的是 WebGL，与 WebGPU 无关；C 无法判断接口支持情况。

Q3. WebGPU 中 workgroup_size 的含义是什么？

单选题 · mid

  • A.上传数据缓冲区的总字节数
  • B.每个工作组内包含的线程数量← 正确答案
  • C.GPU 全局可运行的最大线程数
  • D.开发者编写代码的代码行数

答案：B。@workgroup_size(8,8,1) 声明每个工作组里有 64 个线程，相当于每张备餐台围坐的厨工数。A 是缓冲大小，C 是调度总量而非组内大小，D 是玩笑项。

Q4. 下列哪些是浏览器端侧 AI 推理的优势？

多选题 · mid

  • A.用户数据不出设备更加安全← 正确答案
  • B.无需网络传输延迟更低← 正确答案
  • C.推理成本不随服务器计费← 正确答案
  • D.不需要做任何模型优化

答案：ABC。端侧推理让数据留在本地、省去传输往返、也免去服务器开销，对应 A、B、C。但端侧资源有限，恰恰需要量化剪枝等优化，D 错误。

Q5. INT8 量化中 scale（缩放因子）的作用是什么？

单选题 · mid

  • A.改变神经网络的网络层数
  • B.把浮点范围映射到整数范围← 正确答案
  • C.加密传输时使用的缩放密钥
  • D.调整浏览器的渲染分辨率

答案：B。scale 决定浮点数值如何压缩到 ±127 的整数区间，相当于规定“小碗份量”。A 与网络结构无关，C、D 与量化毫无关系。

Q6. 根据 Amdahl 定律，当可并行比例为 p 时，加速比的理论极限是？

单选题 · hard

  • A.随核心数增加可以无限增大
  • B.最多达到 1/(1-p)← 正确答案
  • C.与核心数量 N 严格成正比
  • D.完全取决于内存带宽大小

答案：B。Amdahl 定律指出加速比极限是 1/(1-p)，串行部分永远限制天花板。就像那台唯一烤箱，再多人切菜也要等它烘焙，B 正确。A、C 忽略了串行部分，D 与定律无关。

Q7. 下列哪些是可行的 WebGPU 推理性能优化手段？

多选题 · hard

  • A.一次处理多张输入图片← 正确答案
  • B.复用已分配的显存缓冲区← 正确答案
  • C.计算与数据上传重叠执行← 正确答案
  • D.把模型复制到每个 CPU 核心

答案：ABC。批处理摊薄固定开销、内存池复用减少分配、异步提交让上传与计算重叠，都是经典优化手段。D 把模型复制到 CPU 核心不提升 GPU 推理能力，反而浪费内存。

Q8. WebGL 做通用计算不自然的主要原因是什么？

单选题 · easy

  • A.依赖片元着色器把数据伪装成纹理← 正确答案
  • B.片元着色器执行速度太慢了
  • C.没有提供顶点缓冲相关接口
  • D.只能使用 NVIDIA 显卡加速

答案：A。WebGL 是为图形渲染设计的，通用计算要把数据编码进纹理、经片元着色器处理再读回，像拿蒸锅烙饼一样别扭。B 提的是速度而非本质，C 不准确，D 与硬件厂商无关。

Q9. 一个 7B 参数模型从 FP32 量化到 INT8 后，显存占用约变化多大？

单选题 · hard

  • A.从 28GB 降到约 7GB← 正确答案
  • B.从 28GB 降到约 14GB
  • C.从 7GB 降到约 1.75GB
  • D.显存占用完全不改变

答案：A。7B × 4 字节 ≈ 28GB，INT8 每参数 1 字节，约 7GB，体积缩小 4 倍。这就像把现杀食材换成真空半成品，A 正确，其余选项计算或逻辑错误。

Q10. 关于 WebGPU 与 WebGL 的说法，哪些是正确的？

多选题 · mid

  • A.WebGPU 提供通用计算管线← 正确答案
  • B.WebGL 是面向渲染的旧接口← 正确答案
  • C.WebGPU 设计上同时面向计算← 正确答案
  • D.两者的着色器语言完全相同

答案：ABC。WebGPU 的出现把计算管线纳入标准，既渲染也计算，A、C 正确。WebGL 是老的图形渲染接口，B 正确。WebGL 用 GLSL，WebGPU 用 WGSL，D 错误。