零后端在浏览器跑大模型：WebGPU + WebLLM 端侧…

每个月被云端大模型 API 账单刺痛的团队，2026 年多了一个反直觉的选项：把模型直接塞进浏览器，让用户自己的显卡干活。不调云端 API、不需要 API Key、一行后端都不用写——从权重加载到每个 token 的生成，全部在用户设备本地的 GPU 上完成。你的 prompt 和模型回答，从未离开过这台机器。

这不是玩具。随着 WebGPU 在 Chrome、Edge、Firefox、Safari 全面落地，加上 4-bit 量化技术成熟，1.5B 到 8B 参数的开源模型在浏览器里已经能做到可交互的生成速度。本文讲清楚这套"零后端 AI"方案的原理、选型和落地要点。

为什么端侧推理突然可行了

浏览器跑大模型有三个绕不开的坎：算力、内存、模型体积。2026 年这三道坎都有了答案：

算力：WebGPU 暴露了现代 GPU 的计算着色器（compute shader）和显存缓冲，Transformer 所需的大规模矩阵运算可以真正并行映射到 GPU 核心上。相比为图形渲染设计的 WebGL，WebGPU 才是"正经算数"的接口；相比纯 JavaScript/WASM 在 CPU 上跑，吞吐量有数量级差距。
模型体积：4-bit 量化把 1.5B 模型压到数百 MB 量级，DeepSeek-R1-Distill-Qwen、Qwen、Llama 3.2 等端侧友好模型都有官方或社区量化版。
加载体验：模型通过 Cache API / IndexedDB 缓存在浏览器，首次加载后再次打开秒开，甚至断网可用。

端侧推理的收益同样直接：零服务器成本（不用租 GPU 实例）、隐私合规（数据不出设备，天然满足数据不出域要求）、无网络延迟（本地推理毫秒级响应）。它特别适合内网工具、文案改写、摘要、分类这类中小模型足够胜任的场景。

三条技术路线怎么选

浏览器端 LLM 推理目前有三条主流路线：

方案	定位	适合场景
`@mlc-ai/web-llm`	开箱即用的 LLM 运行时，内置 OpenAI 风格 `chat.completions` 接口	想最快跑通对话，模型量化与 WebGPU 编译全部打包好
`@huggingface/transformers`（Transformers.js）	Hugging Face 官方 JS 库，模型生态最全	除了对话还要跑语音、视觉等非 LLM 模型
`onnxruntime-web`	ONNX 模型的底层运行时	需要极致控制、愿意自己转模型

对"从零跑通一个本地对话助手"的目标，WebLLM 是最省心的选择：它把模型量化、WebGPU shader 编译、对话模板和 KV cache 全部封装好，调用方式和 OpenAI SDK 几乎一模一样，却完全运行在本地。

第一步：检测 WebGPU 能力

WebGPU 并非所有环境都可用，检测要分两层。主线程粗筛：

const supported = !!navigator.gpu
if (!supported) {
  // 降级：提示用户使用新版 Chrome/Edge，或回退到云端接口
}

但 navigator.gpu 存在不代表真有可用 GPU，细筛放在 Web Worker 里异步完成，避免阻塞 UI：

// worker.js
async function checkGPU() {
  try {
    const adapter = await navigator.gpu.requestAdapter()
    if (!adapter) throw new Error('no adapter')
    self.postMessage({ status: 'ready' })
  } catch (e) {
    self.postMessage({ status: 'error', message: String(e) })
  }
}
checkGPU()

TypeScript 项目记得安装类型声明：npm i -D @webgpu/types，并在 tsconfig 的 types 里加入 "@webgpu/types"。

第二步：Web Worker + 单例加载引擎

模型加载可能耗时几十秒，推理过程持续占用 GPU，这两件事都绝不能卡主线程。标准架构是主线程负责 UI，Worker 负责模型：

// worker.js —— 单例模式，防止用户重复点击触发多次加载
let enginePromise = null

async function getEngine() {
  if (!enginePromise) {
    const { CreateMLCEngine } = await import('@mlc-ai/web-llm')
    enginePromise = CreateMLCEngine('Qwen3-1.7B-q4f16_1-MLC', {
      initProgressCallback: (p) => {
        self.postMessage({ type: 'progress', value: p.progress, text: p.text })
      }
    })
  }
  return enginePromise
}

self.onmessage = async (e) => {
  if (e.data.type === 'load') {
    await getEngine()
    self.postMessage({ type: 'ready' })
  }
  if (e.data.type === 'chat') {
    const engine = await getEngine()
    const chunks = await engine.chat.completions.create({
      messages: e.data.messages,
      stream: true
    })
    for await (const chunk of chunks) {
      const delta = chunk.choices[0]?.delta?.content || ''
      if (delta) self.postMessage({ type: 'delta', text: delta })
    }
  }
}

几个工程要点：加载进度通过 initProgressCallback 回传，做真实进度条而不是转圈；用 Promise 单例保证重复调用只加载一次；流式输出逐 chunk 推给主线程，体验和云端对话一致。

第三步：选模型与量化格式

WebLLM 使用 MLC 编译的模型（模型 ID 通常带 -MLC 后缀，如 Llama-3.2-1B-Instruct-q4f32_1-MLC、Qwen3-1.7B-q4f16_1-MLC）；Transformers.js 则使用 ONNX 社区量化版，如 onnx-community/DeepSeek-R1-Distill-Qwen-1.5B-ONNX。选型经验：

1B~1.5B：集显/8GB 内存设备流畅，适合分类、改写、短问答；
3B 左右：体验甜点，摘要和一般写作质量明显提升，需要约 2~3GB 显存/内存余量；
7B~8B：q4 量化后内存占用约 4GB 上下，独显设备体验好，建议作为"高性能档位"可选加载；
始终提供降级路径：检测不到 WebGPU 或内存不足时，回退到小模型或云端 API。

生产环境的坑

内存硬上限：浏览器对单个标签页有内存上限，动态分配显存的旧方案容易跑着跑着崩溃。2026 年的研究框架（如 llama.cpp 的 WebGPU 后端 LlamaWeb）通过静态内存规划把峰值内存降低约 30%，选库时优先选持续更新、内存策略明确的。
首次下载要交代清楚：几百 MB 的模型下载必须有进度提示和"下载后可离线使用"的预期管理，否则用户会以为页面卡死。
端侧推理 ≠ 端侧训练：浏览器里只做前向生成，权重是预先量化好的，不要被"在浏览器跑大模型"误解成要在浏览器训练。
内容安全仍需设计：本地模型不经过你的服务器，意味着输出过滤也要在端侧或业务层考虑。

小结

2026 年的端侧推理已经跨过"Demo 可用"的门槛：WebGPU 提供算力，量化控制体积，WebLLM/Transformers.js 抹平工程复杂度。它不会取代云端大模型——复杂推理和多模态仍需数据中心——但在隐私敏感、成本敏感、内网离线的场景里，"让用户的显卡替你干活"是最务实的架构之一。

相关阅读：想了解浏览器原生能力的另一波进化，可以看《2026 年了，页面切换动画还在用 JS 库？》和《2026 CSS 新特性盘点》。

零后端在浏览器跑大模型：WebGPU + WebLLM 端侧推理实战 2026