过去想在浏览器里跑一个神经网络，基本只能靠服务端API转发，延迟高、带宽开销大、隐私也难保障。如今借助WebAssembly与WebGPU，浏览器已经能够直接执行模型推理，甚至可以在笔记本上流畅运行几亿参数的大模型。本文将从底层原理、框架封装、性能对比与选型建议四个角度，完整剖析Web端推理的两条加速路线，帮助你判断自己的模型适合走哪条路。
一、WebAssembly加速推理的底层原理
WebAssembly（简称Wasm）是一种可移植的字节码格式，它可以在浏览器中以接近原生的速度执行。之所以能做AI推理加速，核心在于大量成熟的C/C++推理库（如ONNX Runtime、XNNPACK、ncnn）可以被直接编译成Wasm模块，而不需要用JavaScript重写一遍算子。JavaScript引擎需要解析、即时编译源码，而Wasm模块加载后直接进入机器码执行阶段，省去了动态类型的开销，这是它性能优势的第一层来源。
第二层来源是SIMD（单指令多数据）指令集支持。现代浏览器已全面支持128位SIMD的Wasm提案，一条指令可以同时处理4个float32或者8个int16，这对卷积、矩阵乘这类天然并行的算子提升非常明显，实测能带来2到4倍的加速。第三层是线程与SharedArrayBuffer，开启跨域隔离头之后，Wasm可以创建Worker线程并行执行算子，充分利用多核CPU。
使用Emscripten把一个C++算子编译成Wasm的基本流程如下：
# 安装Emscripten后，将C++源码编译为带SIMD和线程支持的Wasm emcc matmul.cpp -o matmul.js \ -O3 \ -msimd128 \ -pthread \ -s WASM=1 \ -s "EXPORTED_FUNCTIONS=['_matmul','_malloc','_free']"
这段命令中，-msimd128开启SIMD指令，-pthread启用多线程（要求页面配置COOP/COEP响应头），EXPORTED_FUNCTIONS声明导出给JavaScript调用的函数。编译产物是JS胶水代码加Wasm字节码，浏览器加载后即可通过Module._matmul直接调用。
Wasm路线的优点是兼容性极佳，几乎所有现代浏览器都支持，包括移动端。缺点是它终究跑在CPU上，面对Transformer这类计算密集型模型，算力天花板明显，且Wasm的内存模型限制了可用内存规模。
二、WebGPU：把GPU算力带进浏览器
WebGPU是浏览器对现代图形API（Vulkan、Metal、DirectX 12）的标准化封装，它最大的价值不是画图，而是暴露了计算着色器（Compute Shader）能力。深度学习推理的本质是大规模矩阵运算，而GPU正是为这类并行计算设计的。通过WebGPU，可以把矩阵乘法写成WGSL（WebGPU Shading Language）着色器，由GPU数千个核心并行执行。
WebGPU加速的关键在于数据流转设计：模型权重一次性上传到GPU缓冲区后常驻显存，每帧推理只需传入激活值，避免CPU与GPU之间反复拷贝。此外WebGPU支持FP16半精度计算，在支持的显卡上吞吐量可以再翻一倍，显存占用也减半。一个简单的矩阵乘法着色器示意如下：
// WGSL计算着色器：C = A x B，采用分块计算策略
@group(0) @binding(0) var<storage, read> matrixA: array<f32>;
@group(0) @binding(1) var<storage, read> matrixB: array<f32>;
@group(0) @binding(2) var<storage, read_write> matrixC: array<f32>;
@compute @workgroup_size(8, 8)
fn main(@builtin(global_invocation_id) gid: vec3<u32>) {
let row = gid.x;
let col = gid.y;
let dim: u32 = 512u;
var sum: f32 = 0.0;
for (var k: u32 = 0u; k < dim; k = k + 1u) {
sum = sum + matrixA[row * dim + k] * matrixB[k * dim + col];
}
matrixC[row * dim + col] = sum;
}
每个工作项负责输出矩阵的一个元素，workgroup_size设为8x8可以充分利用GPU的局部缓存。实际生产中还会结合分块乘法、寄存器tiling等优化技巧，配合fp32-to-fp16量化，性能可以逼近原生CUDA实现的一半以上，这已经远超CPU方案一个数量级。
WebGPU目前的短板是兼容性：Safari、Firefox对它的支持尚在推进中，旧设备显卡驱动可能不满足要求。因此工程上必须实现降级策略——检测到WebGPU不可用时，自动回退到Wasm后端，保证功能可用。
三、主流框架的封装与工程落地
直接手写Wasm或WGSL做推理并不现实，实际项目通常借助成熟框架。onnxruntime-web是 目前最主流的选择，它同时提供WASM和WebGPU两个执行后端，只需切换一个配置项：
// 使用onnxruntime-web在浏览器中加载ONNX模型
import * as ort from 'onnxruntime-web';
async function createSession() {
// 优先尝试WebGPU后端，失败则自动降级为WASM
try {
return await ort.InferenceSession.create('./model.onnx', {
executionProviders: ['webgpu', 'wasm'],
graphOptimizationLevel: 'all'
});
} catch (e) {
console.warn('WebGPU不可用，使用WASM后端', e);
return await ort.InferenceSession.create('./model.onnx', {
executionProviders: ['wasm']
});
}
}
// 构造输入张量并执行推理
const tensor = new ort.Tensor('float32', new Float32Array(inputData), [1, 3, 224, 224]);
const results = await session.run({ input: tensor });
这段代码展示了典型的降级逻辑：executionProviders数组按优先级排列，框架会依次尝试。TensorFlow.js则提供了另一套封装，它的WebGPU backend同样基于计算着色器，且与模型训练流程结合得更好，适合需要在线微调的场景。
工程落地时还有几个容易踩的坑需要留意。首先是跨域隔离配置：多线程Wasm依赖SharedArrayBuffer，服务端必须返回Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp这两个响应头，否则线程数会被强制为1，性能直接打折。其次是模型体积：浏览器对单个Wasm内存有上限，建议把模型量化到int8或fp16再下发，配合HTTP缓存与CDN。最后是首次加载耗时：Wasm模块编译和权重加载可能需要数秒，务必做好加载进度提示，并考虑用Web Worker避免阻塞主线程渲染。
四、性能对比与选型建议
在同样的笔记本硬件上（独立显卡），对一个Vision Transformer模型做推理，Wasm后端单次推理大约在300到500毫秒，而WebGPU后端可以压到20到50毫秒，差距接近一个数量级。对于轻量的CNN分类模型（如MobileNet），两者差距缩小到3到5倍，Wasm单次10毫秒左右的延迟已经能满足实时场景。这个数据说明：模型越大、计算越密集，WebGPU的优势越明显。
选型时可以遵循这样的决策路径：如果目标是最大兼容性，比如需要覆盖老旧安卓机的WebView，直接用Wasm后端最稳妥；如果目标是极致性能，比如在浏览器里跑Stable Diffusion绘图或LLM对话，WebGPU是必选项，且要做好能力检测与降级；如果是中等规模模型加广泛兼容的折中需求，推荐webgpu优先、wasm兜底的组合方案。
还有一个容易忽视的维度是数据隐私。Web端推理意味着用户数据全程不出浏览器，这对医疗影像、企业内网分析等敏感场景价值巨大，很多时候即使性能略逊于服务端GPU，免上传带来的合规收益也值得选择浏览器端方案。随着WebGPU生态成熟和Wasm GC、宽SIMD等提案落地，Web端推理与原生应用的性能鸿沟还会继续缩小，把推理能力下沉到客户端正在成为一个值得提前布局的技术方向。
WebAssemblyWebGPUWeb端推理修改时间：2026-09-09 08:20:46