浏览器原生 LLM 推理：你不知道自己需要的 WebGPU 工程化实践

大多数 AI 功能的架构都大同小异：用户输入发送到 API，云端 GPU 进行处理，然后响应返回。这种往返过程已经如此常态化，以至于工程师们很少对其产生质疑。但它带有一个隐藏的“税”：每次交互都有 200–800 ms 的网络延迟，API 密钥必须存放在某个可访问的地方（因此容易受到攻击），而且你无法控制系统运行时间的硬性依赖。

通过 WebGPU 实现的浏览器原生 LLM 推理打破了这三个假设。模型在用户的 GPU 上运行，位于浏览器沙箱内，没有网络往返。这并非未来的功能 —— 截至 2025 年末，WebGPU 已在 Chrome、Firefox、Edge 和 Safari 中默认出货，覆盖了全球约 82.7% 的浏览器流量。工程问题已从“我们能做到吗？”转向“它何时能击败云端，以及我们如何在两者之间进行智能路由？”

技术栈的真实面貌

标准实现由三个协同工作的组件组成：一个由机器学习优化内核编译而成的 WASM 库，首次下载后缓存到本地的量化模型权重，以及一个让推理脱离主线程的 Web Worker。

WASM 库负责底层计算编排。像 WebLLM 这样的框架使用 Apache TVM 的机器学习编译器来生成针对目标 GPU 优化的 WebGPU 着色器代码 (WGSL)。同样的 WGSL 内核可以运行在 Apple M 系列 GPU、NVIDIA 显卡和 AMD 上 —— WebGPU 抽象了硬件差异，就像 OpenGL 曾经尝试做的那样（但 WebGPU 拥有一个更现代的 API，能够真正正确地暴露 GPU 计算能力）。

模型权重只需下载一次并存储在浏览器缓存中。在后续加载时，权重不再需要网络往返 —— 只需进行着色器编译和上下文设置。WebLLM 在 WGSL 中实现了 PagedAttention 和 FlashAttention，这意味着即使在浏览器较严苛的内存预算内，也能高效处理 KV 缓存内存管理。

Web Worker 架构的重要性比看起来更高。LLM 推理的计算密集度足以让主线程冻结数秒。将任务分流到 Worker 可以在生成 Token 时保持 UI 响应 —— 但这也意味着你的应用程序需要通过消息传递与模型通信，这改变了你构建流式响应和取消逻辑的方式。

能力上限是客观存在的，你需要了解其边界

关于浏览器原生推理，最重要的一点是理解其硬性限制。这些不是你可以通过工程手段绕过的软约束，而是物理层面的。

模型大小：实际最大限制通常是 4-bit 量化下的 7B–8B 参数。跨设备可靠性能的最佳平衡点是 1B–3B 参数。任何更大的模型都会面临内存压力，导致在低端设备上运行失败。

VRAM 预算：浏览器施加的内存限制比原生应用更严格。Safari 的 Metal 后端对每个缓冲区 (per-buffer) 的限制范围从旧款 iPhone 的 256 MB 到 iPad Pro 的 993 MB 不等。Chrome 和 Edge 在桌面端更为宽松，但与原生运行的 llama.cpp 相比，它们在访问系统内存方面仍受到限制。

性能：在 Apple M3 Max 上，4-bit 量化的 Llama 3.1 8B 通过 WebLLM 每秒可生成约 41 个 Token —— 大约为相同模型通过 MLC-LLM 原生运行速度的 80%。Phi 3.5 Mini 的速度达到每秒 71 个 Token。Transformers.js v4 在性能卓越的硬件上针对 20B 参数模型可达到每秒约 60 个 Token。这些数字令人印象深刻，但它们代表了高端硬件上的最佳情况。使用集成显卡的用户看到的吞吐量会大幅下降。

质量：与 FP16 相比，4-bit 量化将模型权重压缩了约 75%，这种差距是显而易见的。分类和提取任务表现良好。复杂的推理任务则会出现明显的退化，尤其是在 INT4 与 INT8 的对比中。2026 年代的开源权重模型 —— Llama-4-70B 和 Mistral Large —— 在许多任务上通过 4–8 bit 量化后接近 GPT-4o 的质量，但复杂推理的前沿模型质量在浏览器内仍难以企及。

1-bit 量化前沿值得关注：最近的研究将 1.7B 参数的 FP16 模型从 3.4 GB 压缩到了 290 MB。这完全在浏览器缓存的可接受范围内，且推理质量正在提高。但在生产环境中，这仍处于实验阶段。

你还没准备好的架构转变

在浏览器中运行模型不仅改变了计算发生的位置，还改变了你的整个应用架构。

首次加载延迟是最明显的用户体验问题。即使是经过良好量化的 2B 参数模型也可能有 1–2 GB。用户第一次访问你的应用时，必须等待下载完成才能看到任何 AI 功能。你需要加载状态、进度指示器，以及为不愿等待的用户准备的回退路径。后续访问会触发缓存，但存储压力下的缓存清理 (cache eviction) 是真实存在的。

着色器编译增加了另一个冷启动成本。WebGPU 在第一次运行时会编译 WGSL 着色器代码，这需要几秒钟。虽然各种实现正在通过管道缓存 (pipeline caching) 进行改进，但在 2026 年，你仍需考虑到首次使用时 3–10 秒的初始化窗口。

无服务器端上下文意味着你的应用状态管理会发生变化。使用云端 API 时，你可以在服务器端维护对话历史，并控制每个请求可见的上下文。而在浏览器推理中，一切都存在于客户端。对话历史受限于模型的上下文窗口（浏览器端模型通常为 4K–32K Token），且没有服务器端的护栏。

模型更新需要用户操作。云端 API 的更新是透明的 —— 你更改一个端点，每个用户都能获得新模型。浏览器缓存的模型会一直存在，直到被显式失效。如果你推送了一个新的量化权重文件，缓存了旧版本的用户在缓存过期或你强制进行版本检查之前，是不会更新的。

2026 年的跨浏览器现状

WebGPU 在各大浏览器中的普及已成现实，但实现质量的差距依然显著。

Chrome 和 Edge 的实现最完整，工程投入也最大。Firefox 在 141 版本中为 Windows 提供了 WebGPU 支持，但 Linux 支持仍处于 Nightly 阶段，Android 计划于 2026 年支持。相比 Chrome 数量级规模的投入，Firefox 团队大约只有 3 名全职工程师负责 WebGPU。合规性差距约为规范的 10%。Safari 在 macOS Tahoe 26 和 iOS 26 中默认添加了 WebGPU，但其 Metal 后端的缓冲区大小限制为移动端部署带来了实际的约束。

GPU 厂商的 Bug 仍然是生产环境中的痛点。NVIDIA 572.xx 系列驱动在运行某些 WebGPU 工作负载时，会在 RTX 30/40 系列 GPU 上崩溃。AMD Radeon HD 7700 会产生视觉伪影。Intel 集成显卡则会间歇性挂起。这些并不是错误日志中的极端情况，而是你需要优雅处理的、可预见的故障模式。

Linux 在所有浏览器上的表现依然不一致。如果你的用户群体包含 Linux 开发者，请务必规划好优雅降级方案。

真正行之有效的混合路由模式

最具生产价值的架构既不是单纯的“浏览器推理”，也不是“云端推理”，而是一个根据任务特性将查询发送到合适计算节点的路由层。

决策框架非常直观：

• 路由至浏览器：短小的、对延迟敏感的交互。例如自动补全、单句改写、基于已知分类法的分类、实时 UI 反馈。这些场景需要低于 100 毫秒的响应时间，而云端 API 无法稳定提供这种体验。
• 路由至云端：复杂的多步推理、长文档分析、输出质量对业务至关重要的任务，以及任何需要超过 7B 参数模型的任务。
• 基于隐私进行路由：包含个人可识别信息 (PII)、机密文档或敏感业务数据的查询应尽可能在本地运行，即使质量上的权衡意味着需要使用较小的模型。

实现模式使用轻量级的门控模型来对输入的查询进行分类。在浏览器中运行的 TinyLlama 级别的模型可以可靠地确定查询复杂度，且延迟低于 20 毫秒——这种成本极低，足以添加到每一个请求中。简单的查询由本地处理；门控将复杂的查询路由到你的云端 API。

基于置信度的路由增加了另一个维度：如果本地模型对特定查询的输出置信度低于阈值，则自动切换到云端 API 重试。这需要从你的浏览器端模型中获取校准后的置信度分数，虽然并非所有框架都能清晰地暴露这些分数，但 WebLLM 的 API 提供了 token 的对数概率，使这变得可行。

成本计算在这里至关重要。从边际成本来看，浏览器推理几乎是免费的——使用的是用户的 GPU 和电费。而云端推理的成本随使用量线性增加。对于小型模型，本地部署在纯成本上胜过云端的转折点大约是每天 50 万个 token。但对于浏览器推理，你实际上是将这些计算完全卸载到了用户的设备上，因此在大规模应用时，其经济效益更加显著。关键在于你的用户是否拥有性能足够的硬件——你的路由层应该能够检测并适应这一点。

该用什么，以及何时选用

库的生态已经整合为几个清晰的选择：

WebLLM 是正确的选择，如果你正在构建以聊天为中心的应用，并希望拥有与 OpenAI 兼容的 API 接口。它处理 MLC 编译器流水线，提供流式聊天补全，并暴露了基于置信度路由所需的 token 对数概率。权衡之处在于它与 MLC 模型格式的紧密耦合。

Transformers.js v4 是正确的选择，如果你已经身处 Hugging Face 生态系统或需要多模态能力。v4 版本采用了 C++ WebGPU 运行时而非纯 JavaScript，这使其在大模型上的性能显著提升。它可以在浏览器、Node.js、Bun 和 Deno 中运行——同样的代码，多个运行时。

ONNX Runtime Web 是正确的选择，如果你需要框架无关的模型支持。PyTorch、TensorFlow 和 scikit-learn 模型都可以导出为 ONNX，而 ORT-Web 支持 WebGPU、WebGL、WebNN 和 WebAssembly 后端。它的配置更为复杂，但模型兼容性更广。

MediaPipe LLM 特别值得考虑用于 Gemma 系列模型，或者如果你需要在浏览器中支持 LoRA 微调（它目前以实验性方式提供支持）。Google 正在积极维护它，并支持以高速运行高达 7B 的模型。

未来走向

2025 年 11 月这一里程碑——所有主流浏览器默认启用 WebGPU——标志着浏览器原生推理从实验阶段跨越到了可部署阶段。2026 年的问题在于执行质量，而非可用性。

近期将改变局面的改进包括：更好的着色器编译缓存以消除冷启动延迟、改进的 2-bit 和 1-bit 量化以在浏览器内存预算内装下更强大的模型，以及更广泛的 Linux 支持以消除最后一个主要的平台差距。

到 2026 年底，10B–15B 参数范围的模型很可能在高端消费级硬件上运行。这将抹平大多数业务推理任务的质量差距。当一个本地缓存的 12B 模型在文档分析上能提供 GPT-4o 级别的质量时，对于任何关注延迟或隐私的 AI 应用，混合路由模式将成为理所当然的默认架构。

那些一直将“调用云端 LLM API”视为唯一推理原语的工程师们，即将拥有超出预期的更多选择。基础设施已就绪，能力天花板已明确，路由模式也已理顺。剩下的就是如何应用它们。

---

现在值得进行的工程押注是：在构建 AI 功能时，将推理接口与推理位置进行清晰的解耦。这种抽象在今天几乎不增加任何开发成本，但这正是能够优雅适配浏览器推理的功能与当用户开始期待本地化体验时需要完全重写的功能之间的区别。