WebGPU 入门：浏览器中的下一代图形与计算 API

如果你关注过 WebGL，你应该知道它让浏览器拥有了 3D 渲染的能力。但 WebGL 诞生于 2011 年，基于 OpenGL ES 2.0/3.0，其设计理念已经难以满足现代 GPU 编程的需求。WebGPU 就是来改变这一切的——它是一个全新的 Web 图形 API，设计上更贴近现代 GPU 架构（Vulkan、Metal、D3D12），不仅性能更强，还将 GPU 通用计算（GPGPU）带入了浏览器。

一、为什么我们需要 WebGPU？

WebGL 虽然推动了 Web 3D 的发展，但它有几个根本性的局限：

• 基于过时的 API 抽象：WebGL 1/2 基于十多年前的 OpenGL ES 规范，无法充分利用现代 GPU 的特性如计算着色器、间接绘制、绑定组等。
• 状态管理的负担：WebGL 采用全局状态机模型，开发者需要小心翼翼地设置和恢复状态，容易出错且效率低下。
• 没有原生计算能力：WebGL 只能做图形渲染，想用 GPU 做通用计算只能通过" Tricks "（如用纹理编码数据），既别扭又低效。
• 单线程瓶颈：所有 GPU 命令必须在主线程提交，难以利用多核 CPU 进行并行准备。

WebGPU 从设计之初就解决了这些问题。它的 API 映射到 Vulkan（Windows/Linux/Android）、Metal（macOS/iOS）和 D3D12（Windows），是真正面向现代硬件的图形 API。

二、核心概念与架构

WebGPU 的 API 设计和 WebGL 有很大的不同，理解以下几个核心概念是入门的关键。

1. Adapter 与 Device

navigator.gpu 是 WebGPU 的入口。通过 requestAdapter() 获取一个适配器（代表物理 GPU），再通过 adapter.requestDevice() 创建一个逻辑设备。Device 是你访问所有 GPU 资源的入口。

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

这种分层设计和 Vulkan 的 Instance/PhysicalDevice/LogicalDevice 非常相似，允许浏览器在背后做资源隔离和权限管理。

2. 管线（Pipeline）

WebGPU 中有两种核心管线：

• 渲染管线（RenderPipeline）：用于将图形绘制到屏幕或纹理上。
• 计算管线（ComputePipeline）：用于执行通用计算，不涉及图形输出。

每条管线都是预编译的，这意味着着色器在创建管线时就被编译为 GPU 机器码，运行时不需要 JIT 编译，性能更加可预测。

3. 着色器语言：WGSL

WebGPU 引入了新的着色器语言 WGSL（WebGPU Shading Language）。和 WebGL 用的 GLSL 不同，WGSL 是专为 Web 设计的，语法更接近 Rust，类型系统更严格，也更容易做静态分析。

@vertex
fn vs_main(@location(0) pos: vec2f) -> @builtin(position) vec4f {
  return vec4f(pos, 0.0, 1.0);
}

@fragment
fn fs_main() -> @location(0) vec4f {
  return vec4f(1.0, 0.0, 0.5, 1.0);
}

WGSL 的设计目标是可预测的性能和安全执行。它不支持递归，有严格的无整数溢出行为（debug 模式下会检查），这些约束都是为了确保在浏览器沙箱中安全运行。

4. 缓冲区（Buffer）与绑定组（BindGroup）

WebGPU 用缓冲区存储数据，通过绑定组将资源（缓冲区、纹理、采样器）绑定到管线上。这种设计避免了 WebGL 的全局状态问题——你不再需要设置当前绑定的缓冲区或纹理，而是在创建绑定组时一次性完成。

// 创建 buffer
const buffer = device.createBuffer({
  size: 12 * 4, // 12 个 float32
  usage: GPUBufferUsage.UNIFORM | GPUBufferUsage.COPY_DST,
});

// 创建 bind group
const bindGroup = device.createBindGroup({
  layout: pipeline.getBindGroupLayout(0),
  entries: [{ binding: 0, resource: { buffer } }],
});

5. 命令编码与提交

WebGPU 的命令模型是延迟执行的。你先创建一个命令编码器（CommandEncoder），在其中录制所有 GPU 命令，然后 finish 成一个命令缓冲区，最后提交到队列执行。这使得浏览器可以在 worker 线程中准备命令，然后提交到主线程的队列上。

三、用 WebGPU 做 GPU 通用计算

这可能是 WebGPU 最令人兴奋的功能之一。过去要在浏览器中用 GPU 做通用计算，只能用 hack 的方式（用 WebGL 渲染纹理来编码计算结果），现在 WebGPU 直接提供了计算管线。

下面是一个简单的矩阵乘法计算着色器示例：

@group(0) @binding(0) var<storage, read> a: array<f32>;
@group(0) @binding(1) var<storage, read> b: array<f32>;
@group(0) @binding(2) var<storage, read_write> result: array<f32>;

@compute @workgroup_size(8, 8)
fn cs_main(@builtin(global_invocation_id) gid: vec3u) {
  let row = gid.x;
  let col = gid.y;
  let N = 4u; // 矩阵维度
  if (row >= N || col >= N) { return; }

  var sum: f32 = 0.0;
  for (var k: u32 = 0; k < N; k++) {
    sum += a[row * N + k] * b[k * N + col];
  }
  result[row * N + col] = sum;
}

这段代码在 GPU 上并行执行矩阵乘法，每个 workgroup 处理 8x8 的区块。相比 CPU 上的嵌套循环，这种并行计算在处理大规模数据时性能差距是数量级的。

四、实际应用场景

1. 高性能 3D 渲染

从游戏到数据可视化，WebGPU 的渲染能力远超 WebGL。Three.js 已经在开发 WebGPU 后端（WebGPURenderer），Babylon.js 也已有完整的 WebGPU 支持。随着浏览器支持普及，Web 上的 3D 体验将迎来质的飞跃。

2. 端侧 AI 推理

这是最热门的方向之一。通过计算管线，浏览器可以直接调用 GPU 进行神经网络推理。已经有项目如 transformers.js 在探索用 WebGPU 运行小型语言模型。想象一下：用户不需要安装任何软件，打开网页就能运行 AI 模型。

关键的技术路径包括：

• 用计算着色器实现矩阵乘法和卷积——这是神经网络的核心运算
• 利用 WebGPU 的存储缓冲区加载模型权重
• 通过共享内存（workgroup_shared）优化数据复用
• 用量化技术（INT8/INT4）减少模型大小和计算开销

3. 物理模拟与科学计算

流体模拟、粒子系统、N-body 仿真——这些计算密集型任务在 GPU 上运行效率极高。WebGPU 让这些场景可以直接在浏览器中实时运行，对于教育和科研可视化非常有价值。

4. 图像与视频处理

GPU 天生擅长并行图像处理。无论是实时滤镜、图像识别，还是视频特效，WebGPU 计算管线都能提供远超 CPU 的性能，且无需 WASM 这样的中间层。

五、浏览器支持现状

截至 2026 年中，WebGPU 的浏览器支持已经有了长足进展：

• Chrome/Edge：113+ 版本在 Windows、macOS、ChromeOS 上default 启用，Android 上从 121 版本开始支持。
• Safari：从 17.4 版本开始在 macOS 和 iOS 上支持。
• Firefox：仍在实验阶段，需通过 flag 开启。

总体来看，Chrome 系和 Safari 已经覆盖了绝大多数用户，WebGPU 进入实用阶段。但实际项目中仍建议检测支持并降级到 WebGL：

if (!navigator.gpu) {
  console.warn('WebGPU not supported, falling back to WebGL');
  // 降级逻辑
  return;
}

六、性能优化要点

1. 善用 Worker 线程

WebGPU 支持在 Web Worker 中创建 device 和编码命令。这意味着你可以将渲染或计算逻辑放到 worker 线程中，避免阻塞主线程的 UI 响应。唯一的限制是 canvas 的 swap chain 需要在主线程获取，但你可以通过 OffscreenCanvas 解决这个问题。

2. 批量资源更新

每次写缓冲区都要调用 device.queue.writeBuffer()，频繁的小写入效率低下。最佳实践是将多个更新合并到一个大缓冲区写入中，减少 CPU-GPU 通信开销。

3. 异步管线编译

管线创建涉及着色器编译，可能耗时几十到几百毫秒。虽然是同步 API，但你可以提前在加载阶段创建管线，用 Promise 包装或者在空闲时间创建，避免在渲染循环中卡顿。

4. 合理设置 workgroup_size

计算管线的 workgroup_size 直接影响 GPU 利用率。一般遵循以下原则：每个 workgroup 至少 64 个线程（对应一个 warp/wavefront 的倍数），但不超过设备限制（通常 1024）。根据具体 GPU 调优可以获得最佳性能。

七、与 WebAssembly 的关系

一个常见疑问是 WebGPU 和 WebAssembly 的关系。它们是互补而非竞争的关系：

• WASM 提供高效率的 CPU 计算，适合逻辑密集型任务
• WebGPU 提供高效率的 GPU 计算，适合数据并行型任务

实践中两者的组合非常强大：用 Rust/C++ 编写复杂的模拟逻辑编译为 WASM 运行在 CPU 上，将矩阵运算等 GPU 友好的部分通过 WebGPU 卸载到 GPU。这种 CPU+GPU 协同模式正是高性能 Web 应用的未来方向。

总结

WebGPU 不只是 WebGL 的升级版——它是一个重新设计的、面向现代 GPU 的图形与计算 API。它带来了：

• 更贴近底层硬件的 API 设计，性能可预测
• 原生的 GPU 通用计算能力，解锁端侧 AI 等场景
• 更好的多线程支持，避免阻塞主线程
• WGSL 着色器语言，专为 Web 设计的安全高效

对于前端开发者来说，现在是学习 WebGPU 的好时机。虽然 API 看起来有些底层和复杂，但社区已经在快速建设上层抽象库。理解底层原理将帮助你在未来几年更好地驾驭这些工具。

从图形渲染到 AI 推理，从科学可视化到游戏引擎——WebGPU 正在把浏览器的极限再次推远。Web 平台曾经被认为是"功能有限"的，而 WebGPU 是打破这一刻板印象的又一个里程碑。