浏览器直接跑大模型：WebGPU实测41 tokens/s，WebLLM与Transformers.js v4前端推理实战

9 月 16, 2026

—

由

一台MacBook，打开Chrome，不装软件，不连API。Llama 3.1 8B以4-bit量化加载进显存，生成速度41 tokens/s。Phi 3.5 Mini更快，冲到71 tokens/s。这组数据来自WebLLM在Apple M3 Max上的实测，与原生MLC-LLM的推理性能只差约20%。

大模型推理从服务器搬进浏览器，底层功臣是WebGPU。W3C推的这项标准从Chrome 113开始落地。它原生支持Compute Shader，矩阵乘法、向量运算这些LLM推理的核心操作可以直接调用GPU并行算力。WebGL时代做通用计算要绕着走，WebGPU把它变成了正经能力。

两大框架，两条路线

WebLLM出自MLC AI团队。思路是用TVM编译器把模型编译成WebGPU可执行格式，浏览器加载后完全本地推理。框架对WebGPU做了深度算子优化，支持Llama 3、Qwen、Gemma等主流开源模型，速度比CPU推理快5-8倍。短板也明确：Intel的开发者指南指出，WebLLM目前调不动NPU。

Transformers.js v4是Hugging Face的官方前端框架。模型经ONNX转换后加载，走WebGPU加速，支持4-bit/2-bit量化与流式输出。20B参数模型在合格硬件上约60 tokens/s。Reddit上有开发者用它给Obsidian插件做语义搜索，跑embedding模型，稳定运行数月。

第三条路是微软的ONNX Runtime Web，WASM与WebGPU双后端，适合需要统一推理层的团队。Chrome内置的Prompt API也能调用系统模型，胜在零配置，模型选择和可控性都受限。

30行代码，本地推理跑起来

WebLLM加载一个4-bit量化Qwen模型，核心代码不到30行：

“`javascript

import * as webllm from “@mlc-ai/web-llm”;

const engine = await webllm.CreateMLCEngine(

“Qwen2.5-1.5B-Instruct-q4f16_1-MLC”,

{ initProgressCallback: (p) => console.log(p.text) }

);

const chunks = await engine.chat.completions.create({

messages: [{ role: “user”, content: “用一句话解释WebGPU” }],

stream: true,

});

for await (const chunk of chunks) {

document.body.innerHTML += chunk.choices[0]?.delta?.content ?? “”;

}

“`

模型权重通过Cache API持久化，第二次访问免下载。API设计与OpenAI SDK对齐，后端迁移成本极低。

想跑自定义模型？Python工具链两条命令搞定编译：

“`bash

mlc_llm convert_weight ./my-model –quantization q4f16_1 -o ./dist

mlc_llm compile ./dist –device webgpu -o ./model.wasm

“`

为什么值得把推理搬进浏览器

隐私是第一驱动力。用户输入不出本机，医疗、法律、财务类应用省下整套合规审查流程。成本是第二驱动力。日均1万次轻量调用的应用，API账单每月数百美元起步；浏览器端推理把这部分开支压到零，服务器只保留静态资源托管。离线场景同样受益：断网状态下AI功能照常工作。

三个必须提前算的坑

首次加载重。4-bit量化的8B模型约4.5GB，1.5B模型约1GB。首屏体验必须做加载进度条与模型分包，或提供3B以下的轻量档。
设备门槛。手机端跑8B模型容易内存溢出，1.5B到3B是安全区。上线前做好设备检测与降级策略。
量化有代价。4-bit相对FP16有精度损失，涉及数值敏感的任务先跑评测集验证再上线。

选型结论

纯LLM对话与生成场景，选WebLLM，性能与模型支持都是第一梯队。需要embedding、视觉、语音多模态模型混跑，选Transformers.js v4，Hugging Face生态的模型转换链路最顺。已有ONNX Runtime技术栈的团队，直接上ONNX Runtime Web。前端AI推理这条路已经跨过能不能跑的阶段，接下来拼的是工程细节。