WebAssembly AI 插件项目回顾：理想很丰满，浏览器兼容性很骨感的现实

WebAssembly AI 插件项目回顾理想很丰满浏览器兼容性很骨感的现实一、为什么选择 WASM Rust 做 AI 插件初始想法很简单用户在 Figma 或 VS Code Web 里选中一段文字按快捷键本地 AI 直接给出改写建议。全程离线不经过任何服务器隐私保护拉满。技术栈选型很自然Rust 写的推理引擎编译到 WebAssembly运行在浏览器里。理想中的架构第一步很顺利——用wasm-pack把一个 200 行的 Rust 示例编译成.wasm在浏览器里成功运行了。// // 第一个 WASM 测试文本处理功能编译成功 // use wasm_bindgen::prelude::*; /// 暴露给 JavaScript 的文本预处理函数 /// 在 WASM 中运行负责清洗和标准化用户输入的文本 #[wasm_bindgen] pub fn preprocess_text(input: str) - String { // 去掉多余空白字符统一换行符 input .lines() .map(|line| line.trim()) .filter(|line| !line.is_empty()) .collect::Vec_() .join(\n) } /// 简单的 token 计数用于评估文本长度是否超过模型限制 #[wasm_bindgen] pub fn count_tokens(text: str) - usize { // 简化版按空格分词实际应该用 tokenizer text.split_whitespace().count() }JS 调用端也很简洁import init, { preprocess_text, count_tokens } from ./pkg/my_wasm.js; await init(); const result preprocess_text( hello world \n rust ); console.log(result); // hello world\nrust到这里我甚至觉得WASM 项目真简单两周搞定。二、第一道墙WASM 内存限制真正的噩梦从加载模型文件开始。一个最轻量的 ONNX 推理模型比如 tiny-bert也要 15MB。在 WASM 里内存默认限制是 4GB——听起来很大但浏览器的限制远不止这个每个 tab 的内存预算通常在 200~500MB 之间取决于设备和浏览器。WASM 的线性内存不能动态扩展超过一定量。模型推理过程中的临时张量会额外占用大量内存。实际测试15MB 的模型加载后占用约 60MB WASM 堆内存推理一个 256 token 的文本时峰值内存跳到 180MB。在 Chrome 里还能接受但在移动端 Safari 上直接在 tab 崩溃。三、第二道墙浏览器兼容性地狱WASM 本身兼容性还可以但多线程和SIMD是两个巨大的坑特性ChromeFirefoxSafari我们的依赖WASM 基础✅✅✅全部WASM 线程✅✅⚠️ 需要 COOP/COEPwasm-bindgen-rayonWASM SIMD✅✅❌ 不支持推理加速SharedArrayBuffer✅✅⚠️ 需要特殊 header线程间共享模型最关键的问题是SharedArrayBuffer。要在 WASM 中启用多线程必须用到它但 Safari 要求服务端设置特定的 HTTP headerCross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp作为浏览器插件我们没有能力控制目标网站的 HTTP header。这意味着多线程 WASM 在 Safari 上直接无法使用只能退回到单线程模式推理速度慢了 3~4 倍。// // 条件编译根据平台决定使用多线程还是单线程 // #[cfg(all(target_feature atomics, feature threads))] mod inference { // 多线程推理实现利用 wasm-bindgen-rayon SharedArrayBuffer pub fn run_parallel(model: Model, input: [f32]) - Vecf32 { use rayon::prelude::*; // 并行计算各层的注意力分数 input.par_chunks(64).map(|chunk| { model.forward(chunk) }).flatten().collect() } } #[cfg(not(all(target_feature atomics, feature threads)))] mod inference { // 单线程回退方案虽然慢但兼容性更好 pub fn run_parallel(model: Model, input: [f32]) - Vecf32 { input.chunks(64).map(|chunk| { model.forward(chunk) }).flatten().collect() } }四、重新思考WASM AI 的正确打开方式经过两周的碰壁我重新审视了这个项目的可行性。结论是纯浏览器端的 AI 推理在现阶段还不成熟但有一些可行的折中方案WASM 做预处理推理交给服务端浏览器端只负责文本清洗、tokenization通过加密通道把 token 发给服务端做推理。隐私性有折中但可用性大幅提升。WebGPU 推理Chrome 113 支持 WebGPU可以用它来加速推理。但 Firefox 和 Safari 的支持还在路上。等 Rust WASM 生态再成熟一点candle/burn等 Rust 深度学习框架正在积极支持 WASM 目标可能半年后情况会好很多。我们最终选择了路径 1——WASM 预处理 服务端推理。用户文本在浏览器端完成清洗和 tokenization只把 token ID 发到服务端服务端不存原始文本。这是目前技术条件下最务实的方案。隔了半年再看这个折中方案确实是最稳的选择——最近 WebGPU 在 Firefox 上的支持已经 beta 了可能再等一年就能切到纯浏览器端。五、总结WASM AI 插件项目是一次理想照进现实的典型经历WASM 不是银弹。它在浏览器里有严重的内存和多线程限制做轻量功能可以跑 15MB 的模型就吃力了。浏览器兼容性是绕不过去的坎。Safari 对 SharedArrayBuffer 的限制直接杀死了多线程 WASM。混合架构是务实选择。WASM 做预处理 服务端做重计算兼顾了隐私和性能。这次项目的代码我没扔掉——WASM 文本预处理模块被复用到另一个项目中算是没白忙活。如果你也在考虑用 WASM 做 AI 推理希望我的经历能让你少走点弯路。