WebGPU浏览器端GPU推理

可视化演示

通过交互式滑块调节检验统计量与显著性水平，实时观察p值变化与拒绝域判定，理解假设检验的决策逻辑。

前世今生

想象你在网页餐厅后厨工作。WebGL 时代，浏览器只给了一台“固定小灶台”：它擅长给三角形上色、做纹理贴图，但你没办法让它自由地做通用计算。AI 推理需要的矩阵乘法、卷积，都得伪装成图形绘制指令，像硬把中餐菜谱塞进西餐烤箱，别扭又低效。

WebGPU 改变了这一切。它由 W3C 的“浏览器 GPU”工作组推动，参考了 Vulkan、Metal、DirectX 12 这些现代图形 API 的设计，把渲染管线和计算管线统一在同一套抽象下。对 AI 推理来说，最大的变化是：网页终于可以直接把数据交给 GPU 的成百上千个计算核心，让它们同时干活。

WebGL 基于 OpenGL ES 2.0，本质是为图形渲染设计的“半开放 API”；WebGPU 则是面向现代 GPU 的“全开放 API”。你可以把它理解为：过去只能点套餐，现在能进中央厨房自己写菜谱。这个“能写菜谱”的能力，正是浏览器端 GPU 推理的技术地基。

并行计算基础

中央厨房之所以出菜快，不是某一位厨师手速惊人，而是配菜、切墩、掌勺、装盘同时开工。GPU 也是这样：它不是用一个大核心硬算，而是用大量小核心同时处理不同数据。这种思路叫“数据并行”。

WebGPU 把这种并行抽象成两层概念：线程（thread）和工作组（workgroup）。一个线程就是一位厨师，负责处理一小块数据；一组线程组成一个工作组，类似一个料理台。工作组内的线程可以共享一部分显存，方便协作完成更大的任务。多个工作组再组合起来，铺满整个 GPU。

这里有一个最简单的数学关系：

除了线程，还要理解显存。GPU 不能直接读取 JavaScript 对象，所有数据都要先放进“缓冲区（Buffer）”，像食材先搬到备料区。CPU 和 GPU 之间搬运数据是有成本的，所以做 AI 推理时要尽量减少来回搬运。理解了分组和缓冲区，就走进了中央厨房的核心区域。

计算着色器

有了中央厨房，还需要一张菜谱。这张菜谱就是“计算着色器（Compute Shader）”。它不是 JavaScript 代码，而是写给 GPU 上每个工人看的批量操作说明：每个线程拿到自己的编号，对某块数据执行同样的运算。

WebGPU 的着色语言叫 WGSL（WebGPU Shading Language）。它运行在 GPU 上，语法风格接近 Rust，但职责非常单一——算数、取值、写回。JavaScript 负责“调度”，WGSL 负责“干活”，两者像老板和厨师的分工。

写计算着色器时，最常遇到的问题是：数据有 1000 个元素，但每个工作组只有 64 个线程，要派发几次？答案用向上取整：

WGSL 还支持工作组内共享内存。工作组内的线程可以把中间结果放进一块快速共享区域，像几个厨师共用一个操作台传菜。“内存模型”决定了哪些数据在显存里、哪些数据在共享内存里，这对矩阵乘法这类算子的性能影响很大。

AI模型推理

在餐厅里，预训练好的 AI 模型就像一份预制菜料包。它不能直接倒进锅里，要先解冻、分装、按自家灶台重新摆盘。把 PyTorch 或 TensorFlow 模型变成浏览器能用的格式，就是“模型转换”。

WebGPU 推理的典型流程是：先把模型导出为 ONNX 或 GGUF 这类开放格式，再把权重二进制文件加载进 GPUBuffer，最后用 WGSL 把卷积、矩阵乘法、激活函数写成计算着色器。浏览器没有默认的 conv2d 函数，这些算子都要靠着色器自己实现。

整个推理过程可以拆成三段：

实际工程中，还会把相邻算子融合：比如“卷积 + ReLU”写进同一个着色器，像把“切菜 + 焯水”合并成一道工序，减少读显存和写显存的次数。权重加载时也常用量化，把 float32 变成 int8，像把食材提前切小块冷冻，省空间、省带宽。

WASM协作

中央厨房再强，也需要一个账房先生管理菜单、记账、处理复杂的订单格式。在浏览器端，这个角色就是 WebAssembly（WASM）。它运行在 CPU 上，不是 GPU 的替代品，而是 WebGPU 的最佳搭档。

WASM 擅长做“杂活”：解析 ONNX 文件、做分词、跑 JSON 配置、处理量化/反量化、写复杂的 if-else 逻辑。这些任务不仅并行度低，还可能充满分支，放到 GPU 上反而浪费。WebGPU 则适合做“大活”：矩阵乘法、卷积、逐元素激活，数据规整、计算密集。

两者通过 JavaScript 调度协作。JS 负责创建 GPU 设备、管理缓冲区、提交命令；WASM 负责把模型数据整理成 GPU 能吃的格式；WebGPU 只专注批量并行计算。数据共享的关键是 ArrayBuffer：GPU 计算完的结果映射回 CPU 内存，WASM 可以直接读取，再交给 JS 更新页面。

这种分工很像真正的餐饮公司：账房（WASM）精确处理琐碎事务，厨房（WebGPU）批量生产硬菜，老板（JavaScript）居中调度。对 AI 推理来说，WASM 负责“理解模型”，WebGPU 负责“计算模型”，才是一个完整的前端推理引擎。

性能兼容性

中央厨房虽然快，但不是每家餐厅都有条件安装。WebGPU 的性能再漂亮，也要看浏览器支不支持、用户设备强不强。

从性能上看，WebGPU 计算着色器执行矩阵乘法、卷积时，通常远快于 WebGL 的图形伪装方案，也比纯 WASM/CPU 快一个数量级。但性能上限往往不是算力，而是带宽：数据上传、结果回读、纹理拷贝都会拖慢整体。所以最佳实践是“尽量少搬数据，尽量多融合算子”。

从兼容性看，WebGPU 已逐步在各大浏览器中推出，但版本差异和平台差异依然存在。上线前必须用 navigator.gpu 做特性检测，不支持时降级到 WebGL2 模拟计算，或者直接用 WASM + CPU 推理。这个降级策略很像保留一套传统灶台，万一新厨房不能用，餐厅今天也不能停业。

评估并行收益时，Amdahl 定律是最常用的公式：

所以，做浏览器端 AI 推理时，先看瓶颈在哪：如果模型又大又依赖矩阵乘，GPU 收益明显；如果只是读 JSON、做字符串处理，WASM 可能就足够了。

落地案例

现在，已经有不少“餐厅”真的用上了中央厨房。最常见的是图像超分：用户上传一张模糊照片，浏览器把图片送进 WebGPU，计算着色器并行处理每个像素块，几秒钟就得到高清版本，全程不需要把照片传到服务器。

另一个典型场景是实时人像分割。摄像头画面进入网页后，一个只有几 MB 的轻量模型在浏览器内完成推理，GPU 把每一帧的前景和背景分开，就能实现直播间背景虚化、虚拟背景替换。数据不上传，不仅省了服务器成本，也保护了用户隐私。

端侧小模型也在兴起。像 WebLLM 这类开源项目，已经能用 WebGPU 在浏览器中跑几亿参数的小型语言模型。虽然还比不上服务器端千亿大模型，但对于文档摘要、邮件润色、本地翻译等场景，已经足够实用，而且完全离线。

未来，随着 WebGPU 兼容性越来越广、量化工具越来越成熟，“打开网页就拥有一个本地 GPU 推理引擎”会成为标配。前端 AI 工程师的岗位，也会像当年移动端工程师一样，从“页面切图”升级为“端侧推理优化”。

AI 应用场景

Python 演示

import math  class GPUSim:    """用 Python 模拟 WebGPU 计算着色器的一次 dispatch。"""     def __init__(self, data, group_size=4):        self.data = data        self.group_size = group_size        self.group_count = math.ceil(len(data) / group_size)        self._output = [0.0] * len(data)        self.task_count = 0     def fused_relu_bias(self, bias):        """每个线程处理一个元素: y = max(0, x + bias)。"""        for g in range(self.group_count):            start = g * self.group_size            end = min(start + self.group_size, len(self.data))            for idx in range(start, end):                self._output[idx] = max(0.0, self.data[idx] + bias)                self.task_count += 1        return self._output  if __name__ == '__main__':    x = [-2, -1, 0, 1, 2, 3, 4, 5, 6]    sim = GPUSim(x, group_size=4)    y = sim.fused_relu_bias(0.5)    print("group_count =", sim.group_count)    print("output =", y)    print("task_count =", sim.task_count)

1. self.group_count = math.ceil(len(data) / group_size)计算需要派发多少个工作组，对应 WebGPU 的 dispatchWorkgroups 次数。
2. def fused_relu_bias(self, bias):定义一个融合算子：偏置加法与 ReLU 在同一个 kernel 中完成。
3. for g in range(self.group_count):外层循环模拟分组派发，每个工作组处理一段连续数据。
4. end = min(start + self.group_size, len(self.data))防止最后一组越界，对应 WGSL 中的边界检查。
5. self._output[idx] = max(0.0, self.data[idx] + bias)线程核心计算，等价于 compute shader 里的 y = max(0, x + bias)。
6. self.task_count += 1统计实际处理了多少元素，方便验证并行任务是否覆盖完整。

常见误区

面试题