不用装任何软件，浏览器里就能跑大模型
本地跑开源模型，一般路径是装 Ollama，下载几个 GB 的权重，占一块 GPU。这条路已经有人写过教程了。但还有一条更省事的路：打开网页，模型直接在浏览器里跑，不装任何东西，数据也不出你的电脑。
干这件事的工具叫 WebLLM，MLC 团队的开源项目，GitHub 上接近两万星。它用 WebGPU 调用你浏览器的 GPU 加速能力，把 LLM 推理塞进了网页标签页。今天这篇带你跑通第一条消息，并算清楚显存这笔账。
它是怎么做到的
浏览器自己没有 CUDA。WebLLM 走的是 WebGPU：一套现代浏览器标准图形接口，能直接调用显卡做通用计算。模型权重的矩阵乘法、注意力计算，全部通过 WebGPU shader 在本地 GPU 上执行。
模型本身也不是原始权重。WebLLM 用 MLC LLM 编译器把开源模型（Llama、Qwen、Phi、Gemma、Mistral 等）预编译成适配浏览器的格式，配套的运行库是 WebAssembly。论文里的测试结果是：同一台设备上，浏览器里能跑到原生性能的 80% 左右。
这个数字值得琢磨一下。你损失两成性能，换来的是零安装、零部署、数据全程不出浏览器。对隐私敏感的场景（病历、合同、公司内部文档），这个交换比很划算。
先检查你的浏览器行不行
WebGPU 需要 Chrome 113 以上版本，Edge 113+ 也可以。打开 webgpureport.org，页面会告诉你当前浏览器的 WebGPU 支持状态。显示 Fall back 之类的字样就要先升级浏览器。
苹果设备上 Safari 18 及以上也支持 WebGPU，不过生态还是 Chrome 最稳。Linux 桌面用户注意：部分发行版的 Chrome 默认没开硬件加速，要在设置里手动打开。
三行代码跑通第一条对话
最快的方式是 CDN 直接引入，连 npm install 都不用。新建一个 HTML 文件，放进一个 type="module" 的 script 标签里：
import { CreateMLCEngine } from "https://esm.run/@mlc-ai/web-llm";
const engine = await CreateMLCEngine(
"Llama-3.2-1B-Instruct-q4f16_1-MLC",
{ initProgressCallback: (p) => console.log(p.text) }
);
const reply = await engine.chat.completions.create({
messages: [{ role: "user", content: "用一句话介绍你自己" }],
});
console.log(reply.choices[0].message.content);用 Chrome 打开这个页面，控制台会先输出下载进度。模型权重首次运行时从 HuggingFace 拉取，Llama-3.2-1B 这个量化版本大约 880MB。下载一次后会存进浏览器的 Cache API，第二次打开秒加载。
然后你就能在控制台看到模型的回答了。整个过程没经过任何服务器。
显存账：你的机器能跑多大的模型
WebLLM 的模型列表里每个模型都标注了 vram_required_MB，我拉了官方配置文件里的几个典型值：
- Llama-3.2-1B（q4f16）：879MB
- SmolLM2-1.7B（q4f16）：1774MB
- Phi-4-mini（q4f16）：3438MB
- Llama-3.2-3B（q4f32）：约 4GB 级别
挑模型的规则很简单：留足余量。浏览器本身要占一部分显存，系统也在用，8GB 显存的机器跑 1.7B 模型是舒适区，3B 就要看情况。核显（集成显卡）共享内存，能跑但速度打折，1B 是稳妥起点。
量化格式里 q4f16 是显存最省的选择（4bit 权重 + 16bit 激活），q4f32 兼容性更好但吃显存，q0 系列（不量化）基本只适合显存富裕的机器。命名规则和 GGUF 那套逻辑相通，之前写过一篇拆解 GGUF 文件名的文章，可以对照着看。
正经项目里怎么用
控制台玩具和生产应用之间隔着一个东西：计算阻塞。推理在主线程上跑，界面会卡。所以正式项目要把引擎放进 Web Worker，官方 README 有现成的 Worker 模板，两文件结构：
// worker.js
import { WebWorkerMLCEngineHandler } from "@mlc-ai/web-llm";
const handler = new WebWorkerMLCEngineHandler();
// onmessage 由引擎自动接管// main.js
import { CreateWebWorkerMLCEngine } from "@mlc-ai/web-llm";
const engine = await CreateWebWorkerMLCEngine(
new Worker("worker.js", { type: "module" }),
"Llama-3.2-1B-Instruct-q4f16_1-MLC"
);界面操作和模型计算分属两个线程，打字不会卡。API 是 OpenAI 兼容的，stream: true 流式输出、JSON mode、种子复现这些你在 OpenAI SDK 里用惯的参数都认。已有的前端代码把 baseURL 换掉，改动不大。
边界在哪：什么场景别用它
平心而论，浏览器推理有明确的适用边界：
长上下文任务不合适。浏览器版模型的上下文窗口普遍压在 4096 token（官方配置里的默认值），喂长文档不现实，这种活还是交给服务端 API。
追求极致速度不合适。80% 的原生性能对聊天、草稿、摘要够用，但你要跑批量任务或者 70B 大模型，浏览器这条路目前到不了。
反过来，客户数据敏感的工具（合同初筛、本地日志脱敏）、离线可用的 PWA 应用、给产品加一个「无需注册就能试」的 demo，这些场景 WebLLM 是目前最省事的方案之一。
延伸阅读
- GGUF 文件名里的 Q4_K_M 是什么意思？下载本地模型前 2 分钟看懂量化：q4f16 这类命名的亲戚，量化逻辑相通
- 什么是 KV 缓存？为什么 AI 聊得越久越吃显存：浏览器跑模型同样要为 KV 缓存付显存
- KV 缓存也要量化？从 f16 到 q4_0，本地省显存的另一半账：显存不够时的第二刀
- vLLM 是什么？为什么高并发推理都用它：服务端推理的主流方案，和浏览器路线对照
- 录音转文字不想传云端？本地 Whisper 完整教程：另一个「数据不出本地」的实战