2025年11月，WebGPU在所有主流浏览器中正式落地。Chrome、Firefox、Safari、Edge——四个浏览器引擎全部默认启用这项技术。这不是一次常规的API迭代，而是Web图形能力的根本性重构。

证据来自一个具体的数字：在M2 MacBook Air上运行Phi-3-mini模型，WebGL后端的token生成延迟约为320毫秒，切换到WebGPU后降至85毫秒。3.8倍的加速不是来自算法优化或硬件升级，仅仅是因为换了API。

这个差距的根源，要从WebGL的设计遗产说起。

WebGL的OpenGL包袱

WebGL诞生于2011年3月，由Khronos Group标准化。它的设计极其直接：将OpenGL ES 2.0的C API映射为JavaScript绑定。当时的选择完全合理——OpenGL ES已经是移动图形的事实标准，浏览器厂商只需做一层薄封装。

但OpenGL本身是一个古老的设计，其核心编程模型是全局状态机。

在OpenGL/WebGL中，GPU被视为一个拥有大量内部状态的对象。调用gl.bindTexture()绑定纹理，调用gl.bindBuffer()绑定缓冲区，调用gl.useProgram()激活着色器程序——所有这些操作都在修改全局状态。后续的绘制调用会读取这些状态，而状态的值会一直保持，直到下一次修改。

这种设计的初衷是减少数据传输：如果GPU已经"记住"了当前的纹理绑定，下一次绘制就不需要再传递这个信息。但它带来了严重的工程问题。Web开发者Surma在分析WebGL时指出，这种模型使得构建可组合的抽象变得极其困难——每个函数都必须小心翼翼地保存和恢复全局状态，否则就会产生难以调试的副作用。一个典型的场景是：屏幕上什么都没有显示，而你需要猜测是哪个状态指针指向了错误的位置。

OpenGL全局状态机模型

图片来源: surma.dev - WebGPU — All of the cores, none of the canvas

更深层的问题在于，OpenGL的状态机模型与2010年代后期GPU硬件的实际架构已经脱节。现代GPU（NVIDIA Ampere、AMD RDNA、Apple M系列）采用分层的并行执行架构：多个执行单元（Execution Units）组成子切片（SubSlice），多个子切片组成切片（Slice），最终形成完整的GPU。每个子切片拥有独立的共享本地内存（Shared Local Memory，约64KB），同一子切片内的执行单元可以通过同步屏障进行协调。

Intel GPU架构层级示意图

图片来源: surma.dev - WebGPU — All of the cores, none of the canvas

OpenGL的设计无法直接映射到这种硬件架构。它是一个更高层次的抽象，需要驱动程序在运行时做大量的状态验证和转换工作。这在桌面应用中尚可接受，但在Web环境中，安全验证的要求更加严格，额外的开销被进一步放大。

GPGPU的hack之路

OpenGL原本为图形渲染而设计。当开发者开始在GPU上做通用计算（GPGPU）时，只能用一种曲折的方式：将数据编码为纹理，用片段着色器（Fragment Shader）模拟计算，再通过readPixels读回结果。

这种"hack"在WebGL中尤为痛苦。WebGL 2.0根本没有计算着色器（Compute Shader），所有GPU计算都必须伪装成渲染操作。以矩阵乘法为例，你需要将两个矩阵编码为浮点纹理，每个片段着色器调用计算输出矩阵的一个元素，执行一次点积运算。问题在于：

  • 没有共享内存：每个片段着色器调用都是独立的，无法复用已加载的数据。矩阵乘法中，每个输出元素需要访问一行和一列的数据，而这些数据会被多次重复加载。
  • 纹理采样开销：数据访问必须通过纹理采样单元，无法直接读写缓冲区。
  • 渲染管线开销：即使是纯计算任务，也必须走完整个渲染管线的固定功能阶段。

2026年2月，SitePoint发布的基准测试量化了这个差距。在RTX 3060上执行4096×4096的FP32矩阵乘法（GEMM），WebGL需要720毫秒，WebGPU只需89毫秒——8.1倍的差距。核心原因就是WebGPU能够使用共享内存的分块算法（Tiling），而WebGL只能反复从全局内存读取数据。

WebGPU的架构重构

WebGPU的设计从一开始就瞄准了现代GPU架构。W3C规范开宗明义：“WebGPU is an API that exposes the capabilities of GPU hardware for the Web. The API is designed from the ground up to efficiently map to (post-2014) native GPU APIs.”

这里的"post-2014 native GPU APIs"指的是Vulkan、Metal和DirectX 12。这三者代表了图形API的范式转变：从隐式状态管理转向显式资源控制，从同步调用转向异步命令队列，从驱动主导转向应用主导。

无状态API

WebGPU消除了全局状态。所有渲染或计算状态都被封装在不可变的管线对象（Pipeline）中。想改变混合模式？创建一个新的渲染管线。想换一个着色器？创建一个新的管线。管线一旦创建就无法修改，这消除了状态意外泄漏的可能性。

命令的提交也发生了根本变化。WebGPU引入了命令编码器（CommandEncoder），开发者将所有GPU操作记录到一个命令缓冲区中，然后一次性提交。这种设计使得多线程录制命令成为可能——不同线程可以并行编码不同的命令缓冲区，最后由主线程统一提交。

Chrome团队的WebGPU迁移指南强调：“WebGPU helps drastically reduce the amount of state developers have to track while sending commands to the GPU.”

Compute Shader与工作组模型

WebGPU的原生Compute Shader是它与WebGL最大的功能差异。Compute Shader是一种在GPU上执行的通用计算程序，与图形渲染管线完全解耦。

在WGSL（WebGPU Shading Language）中，一个计算着色器的入口如下：

@compute @workgroup_size(16, 16)
fn main(@builtin(global_invocation_id) gid: vec3<u32>,
        @builtin(local_invocation_id) lid: vec3<u32>) {
    // 计算逻辑
}

@workgroup_size(16, 16)定义了工作组的尺寸：16×16=256个调用构成一个工作组。这个数字不是随意的——GPU硬件以工作组为单位调度执行，同一工作组内的调用可以访问共享的工作组内存，并通过屏障同步。

WebGPU工作组模型

图片来源: surma.dev - WebGPU — All of the cores, none of the canvas

分块矩阵乘法展示了工作组内存的价值。假设计算$C = A \times B$，其中$A$是$M \times K$矩阵，$B$是$K \times N$矩阵。朴素算法对每个输出元素$C_{i,j}$都要读取$K$个元素，总读取次数为$O(M \times N \times K)$。使用分块算法，将矩阵划分为$T \times T$的块：

$$\text{全局内存读取次数} \approx \frac{M \times N \times K}{T}$$

当$T=16$时，全局内存访问减少16倍。这就是WebGPU实现3-8倍GEMM加速的数学基础。而WebGL的片段着色器无法实现这种优化——它没有工作组内存，每个片段调用都是孤立的。

异步架构

WebGPU的另一个关键设计是全面异步化。在WebGL中，gl.getError()需要同步等待GPU进程响应，这在多进程浏览器架构中会导致显著的IPC延迟。WebGPU的设计则避免了所有同步等待：资源创建、错误反馈、数据映射全部通过Promise或回调异步完成。

Chrome的迁移指南解释了这个决策的动机：“WebGPU is designed to be fully asynchronous to avoid these bubbles. The error model and other operations all happen asynchronously.”

这种设计使得浏览器能够更高效地调度CPU和GPU之间的交互，避免阻塞主线程。

浏览器支持的时间线

WebGPU的标准化和落地经历了漫长过程：

  • 2017年1月：Apple WebKit团队发布WebGPU API提案，向W3C GPU for the Web社区组提交
  • 2020年：W3C成立WebGPU工作组
  • 2023年4月：Chrome 113首个稳定版默认启用WebGPU
  • 2025年6月：Safari 26 beta在WWDC25上启用WebGPU
  • 2025年7月：Firefox 141稳定版启用WebGPU（Windows平台）
  • 2025年11月：所有主流浏览器默认支持

2025年11月的里程碑意味着WebGPU已经成为Web平台的稳定基础设施。对于开发者而言，这标志着从"渐进增强"到"主推WebGPU"的策略转变时机已经成熟。

不是升级，是重定义

回到标题的论点：WebGPU不是WebGL的升级版。两者的差异不是增量式的改进，而是架构范式的根本转变。

WebGL的本质是"OpenGL ES的Web绑定"，它继承了OpenGL的所有设计遗产——全局状态机、同步错误处理、图形中心的计算模型。这些设计在1990年代的固定功能GPU上是合理的，但在2020年代的并行可编程GPU上已经成为性能瓶颈。

WebGPU则是一次"从零开始"的设计。它不绑定任何现有的图形API，而是在Vulkan、Metal、DirectX 12这三个现代API之上定义了一套统一的抽象层。这套抽象直接映射到现代GPU硬件的工作组模型、命令队列架构、共享内存机制。

性能数据验证了这个架构决策的价值：在矩阵乘法、LLM推理、物理模拟等计算密集型任务中，WebGPU相比WebGL实现了3-8倍的加速。这不是魔法，而是正确的架构带来的必然结果。

对于Web开发者，这意味着一个新时代的开始：浏览器不再仅仅是图形渲染的"轻量级终端"，而是真正的GPU计算平台。而在浏览器端运行机器学习模型、物理模拟、科学计算——这些过去需要本地应用的场景——正在成为Web的常规能力。

参考文献

  1. W3C. “WebGPU Specification.” https://www.w3.org/TR/webgpu/
  2. Chrome for Developers. “From WebGL to WebGPU.” https://developer.chrome.com/docs/web-platform/webgpu/from-webgl-to-webgpu
  3. SitePoint. “WebGPU vs. WebGL: Performance Benchmarks for Client-Side Inference.” https://www.sitepoint.com/webgpu-vs-webgl-inference-benchmarks/
  4. Surma. “WebGPU — All of the cores, none of the canvas.” https://surma.dev/things/webgpu/
  5. Khronos Group. “WebGL Specification 1.0.” https://www.khronos.org/news/press/khronos-releases-final-webgl-1.0-specification
  6. WebGPU.com. “WebGPU Hits Critical Mass: All Major Browsers Now Ship It.” https://www.webgpu.com/news/webgpu-hits-critical-mass-all-major-browsers/
  7. WebKit. “WebGPU API Proposal.” https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
  8. Mozilla Gfx Team. “Shipping WebGPU on Windows in Firefox 141.” https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-on-windows-in-firefox-141/
  9. WebGPU Fundamentals. “WebGPU Compute Shader Basics.” https://webgpufundamentals.org/webgpu/lessons/webgpu-compute-shaders.html