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 已开始实验性支持某些低精度格式扩展，虽然尚未公开文档。
