WebAssembly 适合在浏览器里跑 AI 推理吗？

WebAssembly 为什么会进入 AI 推理场景？

WebAssembly 更适合做“本地推理”而不是“本地训练”。它的价值不在于替代 CUDA 或云端训练集群，而是在浏览器、WebView、边缘节点里稳定运行小模型。对图像分类、OCR 前处理、语音降噪、向量相似度粗筛这类任务来说，少一次网络往返，体验差别很明显。

真正落地时要先看三个条件：模型体积是否能被用户接受，输入数据是否适合留在本地，设备 CPU 是否扛得住持续计算。如果模型动辄几百 MB，WebAssembly 再快也会输在下载和内存上。更稳的做法是端侧负责低延迟、隐私敏感或离线场景，复杂推理仍交给服务端。

怎么加载一个推理模型？

常见选择是 TensorFlow.js 的 WASM 后端、ONNX Runtime Web，或者用 Rust/C++ 写自定义算子。TensorFlow.js 上手快，适合已有 tfjs 模型；ONNX Runtime Web 更适合从 PyTorch、scikit-learn 等链路导出的模型。

javascript
import * as ort from 'onnxruntime-web';

ort.env.wasm.wasmPaths = '/wasm/';
ort.env.wasm.numThreads = Math.min(4, navigator.hardwareConcurrency || 1);

const session = await ort.InferenceSession.create('/models/mobilenet.onnx', {
  executionProviders: ['wasm']
});

const input = new ort.Tensor('float32', preprocessed, [1, 3, 224, 224]);
const output = await session.run({ input });
console.log(output.probabilities.data);

这里最容易踩坑的是 MIME 类型和路径。.wasm 文件最好由服务器返回 application/wasm，否则流式编译可能退化，首屏会慢一截。模型文件也要带 hash 做长期缓存，避免新旧模型混用。

性能优化该先做什么？

第一步不是上 SIMD，而是减少数据搬运。图片从 Canvas 转成 TypedArray、再传给 WASM、再拷回 JS，如果每帧都复制大块内存，边界调用成本会吃掉算法收益。把预处理、归一化、推理后的简单筛选尽量合并到同一侧，通常比微调一段矩阵代码更有效。

bash
# Rust 自定义算子示例：发布构建并压缩 wasm
wasm-pack build --target web --release
wasm-opt -Oz pkg/my_ops_bg.wasm -o pkg/my_ops_bg.opt.wasm
brotli -f pkg/my_ops_bg.opt.wasm

模型层面优先考虑 INT8/FP16 量化、剪枝和知识蒸馏。量化会带来精度损失，尤其是人脸、医疗图像、工业缺陷识别这类容错低的场景，必须拿真实样本回归验证。SIMD 和多线程能提速，但多线程依赖跨源隔离头，移动端浏览器支持也要单独测。

追问

WebAssembly AI 推理和 WebGPU 该怎么取舍？

WebGPU 更适合大规模并行计算，矩阵乘法、卷积这类任务理论上优势明显。WebAssembly 的优势是兼容面更稳，部署和降级更简单，很多普通 CPU 设备也能跑。实际项目里可以先用 WASM 做基线版本，再对支持 WebGPU 的设备启用 GPU 后端。踩坑点是 WebGPU 初始化、权限、驱动差异都可能影响稳定性，不能只看高端电脑上的 benchmark。

模型放在浏览器本地安全吗？

只能说更保护用户数据，不等于模型安全。模型文件下载到客户端后，就有被复制、反编译或做黑盒探测的风险。商业价值很高的模型不建议完整下发，可以下发轻量版本，核心能力仍放服务端。边界在于隐私和资产保护的取舍：用户数据越敏感，越适合端侧；模型越敏感，越要谨慎下发。

为什么推理第一次特别慢？

第一次慢通常由三部分组成：下载模型、编译 wasm、初始化推理 session。即使文件已缓存，session 创建也可能花几百毫秒到数秒。可以在用户进入关键流程前预加载，或者先加载小模型给出粗结果，再后台切换大模型。不要在首屏同步等待完整 AI 能力，否则页面会像卡死一样。

移动端能跑 WebAssembly AI 吗？

能跑，但要控制野心。移动端 CPU、内存、电量和散热都比桌面紧张，连续视频帧推理很容易发热降频。适合移动端的是低频触发、短时计算、小模型任务，例如拍照后识别、离线文本分类、简单滤镜。需要实时 30fps 的复杂检测时，要准备降采样、跳帧和服务端兜底。

离线 AI 应用怎么设计缓存？

Service Worker 可以缓存模型、wasm runtime 和权重文件，但版本管理必须严格。建议把模型版本写进 manifest，并在启动时校验 hash，发现不一致就整体更新。只缓存单个文件容易出现 JS 调新接口、模型还是旧格式的情况。离线能力的边界也要告诉用户：首次加载前没有缓存，离线模式就无法凭空工作。