Stable Diffusion 3.5-FP8 模型是否支持 WebGPU 加速
在一台轻薄本上,用浏览器打开一个网页,输入'赛博朋克风格的机械猫,在雨夜城市中跳跃'——几秒后,一幅细节丰富、光影逼真的 4K 图像跃然屏上。整个过程无需安装任何软件,不上传数据,也不依赖云端服务器。
这听起来像科幻?其实离我们并不遥远。
随着 Stable Diffusion 3.5-FP8 这类高性能量化模型的推出,以及 WebGPU 等新一代 Web 计算标准的成熟,这样的场景正逐步成为现实。关键问题来了:FP8 模型能在 WebGPU 上跑起来吗?
答案是:目前还不行,但非常接近了。
为什么是 FP8?
先说清楚一件事:FP8 不是简单的'砍精度'。它不像早期的 INT8 量化那样容易导致生成质量断崖式下降。相反,FP8(尤其是 E4M3 和 E5M2 格式)通过精心设计的指数 - 尾数结构,在仅用 1 字节存储的情况下,依然保留了足够的动态范围来应对扩散模型中复杂的激活分布。
举个例子,原始 SD3.5 使用 FP16 时,显存占用大约 9GB,推理时间可能要十几秒;而 FP8 版本直接压缩到约 4.5GB,速度提升 40% 以上,画质肉眼几乎无差。这意味着什么?你家那台带核显的 MacBook Air,也能扛得住 1024×1024 的文生图任务了!
更妙的是,FP8 不只是省显存,它还大幅提升了计算密度。现代 GPU 的 Tensor Core 已经能原生处理 FP8 矩阵乘法(比如 NVIDIA H100),这让 GEMM 运算吞吐翻倍不再是梦。
可惜的是……这一切目前还主要停留在本地部署或云服务端。
WebGPU:浏览器里的'迷你 CUDA'
WebGPU 到底强在哪?
想象一下,以前你在浏览器里画画,只能靠 WebGL 这种'高级画笔',所有操作都要经过图形驱动层层翻译,效率低、控制弱。而现在,WebGPU 给了你一把螺丝刀,可以直接拧 GPU 的每一颗螺丝——包括执行通用计算任务。
它的优势非常明显:
- 支持计算着色器(Compute Shaders),可以跑神经网络;
- 提供细粒度内存管理,避免频繁拷贝;
- 跨平台统一接口,一套代码跑通 Windows、macOS、Linux 甚至手机;
- 延迟更低,适合多轮迭代的去噪过程。
已经有项目证明这条路走得通。比如 Diffusion.js 就成功在 WebGPU 上运行了 FP16 版的 Stable Diffusion,虽然速度还不够快,但至少说明架构可行。
那么问题又回来了:既然 FP16 都能跑,FP8 为啥不行?
现实瓶颈:硬件、API、生态三重关卡
别急,咱们拆开来看。
第一关:WGSL 不认识 FP8
WebGPU 的着色语言叫 WGSL(WebGPU Shading Language)。目前它压根没有 f8 这种数据类型。你想传个 FP8 权重进去?对不起,只能当 uint8 或 int8 款待。
但这不是死路一条。我们可以玩点'伪装术':
// 把两个 int8 权重相乘,再用缩放因子还原为 fp32
let a_f32 = f32(a_i8) * scale_a;
let b_f32 = f32(b_i8) * scale_b;
let result = a_f32 * b_f32;
只要提前在校准阶段记录好每层的缩放因子(scale),就能在计算时动态恢复数值。这其实就是量化推理的核心思想——用整数算浮点的事。
不过代价也很明显:额外的类型转换和乘法运算会吃掉一部分性能红利,相当于'绕远路回家'。
第二关:浏览器还没打通底层支持
目前主流浏览器对 FP8 的支持几乎为零。Chrome 和 Safari 的 WebGPU 实现仍聚焦于基础功能,连 FP16 的张量运算都还在优化中,更别说 FP8 了。
但风向已经在变。Intel、Google、Apple 都在参与 W3C 的 WebNN API 标准制定,目标就是让浏览器原生支持 AI 推理。一旦这个标准落地,FP8 很可能作为首批支持的低精度格式之一被纳入。
据部分开发者透露,Safari Technology Preview 已开始实验性支持某些低精度格式扩展,虽然尚未公开文档。

