Wasm 跑 AI：浏览器里能跑了，但别指望它替代 GPU 集群

2026 年，用 WebAssembly 跑 AI 推理这件事，终于从“极客实验”变成了有生产级工具支撑的可行方案。Google 在 7 月发布的 LiteRT.js 是一个标志性事件：它把原本服务于 Android 和桌面的推理运行时通过 Wasm 搬进浏览器，在 CPU 上比旧方案快最多 3 倍，配合 WebGPU 或 WebNN 还能再快 5 到 60 倍。但与此同时，边缘设备上的学术评测和 wasi-nn 生态的现状也提醒我们：Wasm 跑 AI 的边界，比宣传口径要清晰得多。

浏览器端：LiteRT.js 把“原生运行时”搬进了标签页

过去浏览器里跑 AI 的主流方案是 TensorFlow.js，它的计算内核用 JavaScript 实现，性能天花板明显。LiteRT.js 的做法完全不同：它把 Google 在移动端打磨多年的 LiteRT 运行时（TensorFlow Lite 的进化版）编译成 WebAssembly，让浏览器直接执行优化过的原生代码。

实际收益可以从 Google 公布的 benchmark 看出来。在 M4 MacBook Pro 上，LiteRT.js 在计算机视觉和音频处理模型上比现有 Web 运行时快最多 3 倍。更关键的是后端分化：纯 CPU（通过 XNNPACK）只是保底，走 WebGPU（通过 ML Drift）或 WebNN（调用 NPU）时，推理速度可以比 CPU 高出 5 到 60 倍。这意味着对象检测、语音转录、图像分割这类对延迟敏感的任务，在浏览器里真正变得可用了。

模型生态上，LiteRT.js 直接吃 .tflite 格式，PyTorch 模型通过 LiteRT Torch 可以一步转换，绕开了过去“PyTorch → ONNX → TensorFlow → TF.js”的冗长链路。量化也可以用 AI Edge Quantizer 逐层配置，在压缩体积和保持质量之间做精细调节。npm 包 @litertjs/core 已经可用，JavaScript 和 TypeScript 开发者不需要重建整个应用，可以把 TensorFlow.js 仅用于前处理和后处理，模型执行部分替换成 LiteRT.js。

边缘与沙箱：Wasm 的定位是“隔离层”，不是“加速器”

如果说浏览器端的价值是“让 AI 在用户设备上跑起来”，那么边缘和沙箱场景的价值则是“让 AI 在一个可控的盒子里跑”。IDC 在 2026 年第二季度的报告里把 Wasm 的 AI 用例归纳得很清楚：沙箱化的 AI 代理执行、边缘推理、安全隔离，是买家关注的核心，而 Wasm 的定位是容器的补充而非替代。

学术评测给出了更具体的数字，也揭示了局限。一篇 2026 年 IEEE 会议论文在 NVIDIA Jetson Orin 和 Thor 上系统对比了 Docker 容器与 WebAssembly 两种沙箱环境运行量化 LLM（8B 到 70B 参数，包括 Llama3.1、Gemma3 等）的表现，关注的是推理延迟、功耗和相对裸机的性能损耗。结论指向一个务实的判断：Wasm 的沙箱开销在可接受范围内，但它并不会让推理本身变快。如果你需要的是“在边缘设备上安全地跑一个第三方模型或不可信代码”，Wasm 的隔离模型有价值；如果目标是榨干 Jetson 的 GPU 算力，裸机或容器仍然是更直接的选择。

另一个值得注意的信号来自 wasi-nn。这个为 WASI 提供神经网络接口的提案已经推进了一段时间，但 2026 年欧洲软件架构会议的一篇论文明确指出：wasi-nn 生态仍然不成熟，实现依赖原生库，可移植性受限。换句话说，在服务端 Wasm 运行时里调用硬件加速推理，目前还不是一个“开箱即用”的能力。

浏览器里的 LLM：能跑，但别期待流畅

2026 年确实出现了在浏览器标签页里跑语言模型的工具。gopherllm-wasm 把 Go 写的推理引擎编译到 Wasm，在支持 WebGPU 的浏览器里把 Q4_K/Q6_K 矩阵向量乘法卸载到 GPU 计算后端，模型文件通过 FileReader 在客户端读取，数据不上传。Dart 生态的 jackdaw_web 则用 wllama（llama.cpp 编译到 Wasm）在浏览器里跑 GGUF 模型，支持结构化输出和流式取消。

但这些项目的 README 里藏着真实的约束。gopherllm-wasm 提到，多 GB 的模型在浏览器标签页里需要把文件至少完整持有两次（读取缓冲和引擎副本），2GB 以上的模型要特别注意内存问题。jackdaw_web 则指出多线程需要 COOP/COEP 响应头，超过 2GB 的模型文件必须切分。Google 虽然宣布了 LiteRT-LM.js 让大语言模型跑在浏览器里，但目前的公开 demo 集中在 YOLO 对象检测、深度估计和图像放大这类 CV 任务上，LLM 的浏览器体验还远未到“日常可用”的程度。

一个容易被忽略的风险：模型权重是公开的

在浏览器里跑 AI 有一个在服务端不存在的安全问题。SitePoint 的本地优先 AI 指南指出了一个简单的事实：任何人打开开发者工具或网络面板，都能提取出浏览器加载的模型权重。这意味着专有模型、微调过的商业模型，不应该以这种方式部署。开源模型或对保密性没有要求的场景，才适合走浏览器推理路线。此外，本地推理不等于安全——恶意输入仍然可以操纵模型输出，没有服务端护栏来拦截有害生成，过滤责任落在开发者身上。

怎么判断该不该用 Wasm 跑 AI

综合 2026 年的技术现状，判断标准可以收束为三条。

适合用的情况：推理任务需要在用户设备上完成且数据不能上云（隐私敏感、离线可用），模型规模可控（CV 或音频模型为主，LLM 仅限小参数尝试），或者你需要在边缘节点/插件环境里安全地运行第三方提供的模型代码，Wasm 的沙箱是现成的隔离方案。浏览器端的工具链已经足够成熟，LiteRT.js 提供了生产级的入口。

不适合用的情况：你需要跑大参数量的 LLM 并追求吞吐量，或者你的推理负载依赖复杂的硬件加速且无法通过 WebGPU/WebNN 表达。在这些场景下，Wasm 带来的隔离收益抵不过性能损耗和工具链摩擦，原生 GPU 服务或容器化部署仍然是更合理的选择。边缘沙箱里的 LLM 推理评测也印证了这一点：沙箱是安全需求，不是性能需求。

可以观望的情况：wasi-nn 如果能在以后走向成熟，服务端 Wasm 运行时直接调用推理加速器会成为可能，那时 Wasm 在 AI 基础设施里的角色会从“浏览器和边缘的轻量方案”扩展出去。但 2026 年的现实是，它还在路上。