浏览器原生 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 在各大浏览器中的普及已成现实，但实现质量的差距依然显著。

加载中…