WebLLM实战：浏览器端大模型推理与WebGPU加速全解析

WebLLM 是一个把大语言模型推理引擎完整放到浏览器里的开源项目，目标是让模型权重、推理逻辑和上下文管理全部在本地浏览器中运行，而不依赖服务器端的推理接口。它解决的核心问题是数据链路：传统聊天应用需要把用户输入发送到服务端，再由 GPU 集群完成推理后返回结果；而 WebLLM 通过 WebGPU 调用本机显卡资源，在浏览器内部完成预填充和解码，适合构建本地优先、隐私敏感或离线可用的人工智能应用。读完这篇文章，你会搭建一个最小可运行的浏览器端模型对话页面，并能理解模型为什么需要下载、prefill 和 decode 各在做什么、页面卡住时该从哪一层开始排查。

1. 先理解 WebLLM 到底是什么，以及它改变了什么

1.1 浏览器端推理与传统服务端推理的差异

传统的大模型接入方式，几乎都是“客户端发送文本到服务器，服务器调用推理服务，再把结果流式返回”。这种架构成熟，但存在几个难以回避的问题。

第一是数据隐私。用户输入、对话历史都要经过网络传输，即使做了加密，对于医疗、法律、企业内部资料等敏感场景仍然是一道门槛。第二是调用成本。服务端推理的 GPU 费用是持续性的，用户每发一条消息，都要消耗算力。第三是延迟链路。网络往返、排队等待、服务端流式推送等环节会拉高首 token 出现的时间。第四是可用性。一旦服务端故障、网络断开或接口配额耗尽，前端功能直接不可用。

WebLLM 走的是完全不同的路线：模型在浏览器启动时下载到本地，之后用户输入不再离开设备。推理所需的矩阵乘法和注意力计算通过 WebGPU 调用显卡完成，部分控制逻辑编译为 WebAssembly 在 CPU 上执行。两者结合，让浏览器成为一个真正的大模型推理运行时。

1.2 WebLLM 的定位不是一个聊天 Demo

WebLLM 可以被看作一个“浏览器版推理引擎”，它不只是把某个对话组件封装成前端插件，而是提供了一套模型编译、加载、推理、流式输出的完整链路。它建立在 MLC LLM 的编译能力之上：大模型会被提前编译成适配 WebGPU 的中间表示，再配合量化策略压缩到适合浏览器传输和加载的体量。

从使用者角度看，它的运行流程大致如下：前端通过配置指定一个模型标识；引擎从模型仓库下载权重和编译产物；下载完成后权重缓存到浏览器存储；之后的每一次对话，数据都在本地完成前向计算。整个过程对 JavaScript 应用暴露统一接口，应用层可以像调用普通聊天 API 一样调用 chat.completions.create，同时又能拿到实时的模型加载进度。

理解这一点很重要：WebLLM 不是“远程模型 API 的浏览器封装”，而是把模型“搬”到了浏览器里。后面所有调试思路，都应该围绕“本地执行”这条主线展开。

2. WebLLM 的核心工作方式：把大模型塞进浏览器需要解决什么

2.1 WebGPU 是推理的算力基础

大模型推理的本质是大量矩阵乘法，这种计算非常适合在 GPU 上并行执行。浏览器传统上只提供 WebGL 这样的图形 API，虽然能做通用计算，但针对计算着色器、存储缓冲区、工作组等特性的支持不够直接。WebGPU 是现代浏览器提供的底层图形与计算接口，允许 JavaScript 创建计算着色器、分配 GPU 缓冲区、提交计算任务，并且能够在 CPU 和 GPU 之间高效传递数据。

WebLLM 在推理过程中会创建大量 GPU 缓冲区，把每一层的权重、激活值、KV 缓存放到显存中。计算着色器按 tile 的方式切分矩阵乘法任务，充分利用显卡的并行度。可以这样理解：WebGL 是“为了画图顺便做计算”，WebGPU 则是“把计算作为一等公民”，所以 WebGPU 更适合承载大模型的逐层计算。

2.2 WebAssembly 承担 CPU 侧的控制逻辑

GPU 负责重计算，但模型加载、token 分词、采样策略、注意力缓存管理等逻辑仍然需要 CPU。WebLLM 使用 WebAssembly 把这些控制逻辑编译成浏览器可以执行的字节码，让 C++ 侧的推理运行时能够被 JavaScript 调用。

这样形成了一条混合执行链路：文本先被分词器转成 token id；token 序列进入模型后，各层矩阵运算提交到 WebGPU；每一层的中间结果在 GPU 与 CPU 之间协作；最后通过采样选择一个或多个候选 token。WebAssembly 的性能虽然不如原生 C++，但因为重计算在 GPU 上，CPU 侧只做编排，整体依然能保持可用的推理速度。

2.3 一次请求内部的两个阶段：prefill 和 decode

模型生成一个回复，内部可以分为两个阶段，这也是 WebLLM 性能表现最值得关注的地方。

第一阶段是 prefill，也叫预填充。用户输入的整段 prompt 会一次性输入到模型中，模型并行计算所有位置的 hidden state，并把历史 token 对应的 KV 信息写入缓存。这个阶段计算量大，但并行度高，通常表现为“长时间等待之后突然开始输出”。

第二阶段是 decode，也叫解码或自回归生成。模型逐 token 地预测下一个 token，每生成一个 token，就要把新的 KV 追加到缓存，并在所有历史位置上执行一次注意力计算。这个阶段每次计算量不大，但需要串行执行大量步数，所以输出速度决定整段回答的等待时间。

KV cache 的作用很大。模型在 prefill 阶段已经算过历史位置的 key 和 value，decode 阶段不需要重新计算，只需读取并更新缓存。这也是为什么同一段对话继续追问，会比重新发起完整对话更高效。

2.4 引擎对外暴露的是一组聊天接口

从应用开发者角度看，WebLLM 提供的是 OpenAI 风格的聊天接口。创建引擎后，传入模型 id 和配置，然后调用 engine.chat.completions.create 即可获得完整回复或流式回复。加载状态、错误信息和模型切换则通过事件或 Promise rejection 返回到主线程。

这种设计的主要好处是降低了接入成本：如果团队已经接通过 OpenAI 或类似服务端接口，改用 WebLLM 后请求和响应结构大致相似，真正需要改的是模型来源、加载流程和本机算力判断。

3. 跑起来之前：浏览器、开发环境和项目准备

3.1 浏览器与硬件前提

WebLLM 对浏览器版本有硬性要求，核心是 WebGPU 支持。Chrome 和 Edge 的支持时间较早，Firefox 与 Safari 的支持情况要按当前发布版本确认。进入开发前，先做一个快速检查，避免把时间浪费在环境不符合要求的问题上。

在目标浏览器地址栏访问一个空页面，打开开发者工具 Console，输入：

javascript复制navigator.gpu

如果返回 undefined，说明当前浏览器不支持 WebGPU，或者当前页面不是安全上下文。WebGPU 要求在 HTTPS 或 localhost 环境下运行，直接双击 HTML 文件、通过局域网 IP 访问、或者用非 HTTPS 域名部署，都可能导致 API 不可用。

3.2 初始化 Node 项目并安装依赖

推荐使用 Vite 作为开发服务器和构建工具。原因很直接：WebLLM 的 npm 包以模块方式导出，前端代码需要写 import { CreateEngine } from "@mlc-ai/web-llm"。裸模块导入不能直接由浏览器解析，必须由打包工具把依赖路径解析成浏览器可加载的产物。Vite 在开发时按需编译，启动快，适合这个场景。

先在空目录里初始化项目：

bash复制mkdir webllm-demo
cd webllm-demo
npm init -y
npm install @mlc-ai/web-llm
npm install -D vite

安装完成后，package.json 大致长这样：

json复制{
  "name": "webllm-demo",
  "private": true,
  "version": "0.1.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "@mlc-ai/web-llm": "latest"
  },
  "devDependencies": {
    "vite": "latest"
  }
}

这里统一使用 latest 只是为了演示安装流程。实际项目里，应当锁定 WebLLM 的具体版本，并在升级依赖后回归验证模型加载和流式输出，因为这类底层推理引擎的 API 变动可能比较频繁。

3.3 编写项目文件结构

项目最少需要三个文件：index.html 提供页面结构，main.js 负责引擎初始化和交互逻辑，package.json 管理依赖。为了让代码路径更清晰，建议在项目根目录直接创建：

text复制webllm-demo/
├── index.html
├── main.js
├── package.json
└── node_modules/

index.html 中的脚本标签必须使用 type="module"，否则浏览器不会把 main.js 当作 ES 模块加载，import 语句会直接报语法错误。

4. 最小可运行案例：一个浏览器里的对话页面

4.1 页面结构设计

先写 index.html。页面包含四个核心控件：加载模型按钮、状态提示文字、问题输入框、发送和停止按钮，以及一个用于显示流式输出的 pre 区域。

html复制<!doctype html>
<html lang="zh-CN">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>WebLLM 浏览器端推理示例</title>
  </head>
  <body>
    <h1>浏览器内运行的大模型对话</h1>
    <div>
      <button id="load-btn">加载模型</button>
      <span id="model-status">未加载</span>
    </div>
    <div>
      <textarea id="prompt" rows="3" placeholder="输入你的问题"></textarea>
    </div>
    <div>
      <button id="send-btn" disabled>发送</button>
      <button id="stop-btn" disabled>停止</button>
    </div>
    <pre id="output"></pre>
    <script type="module" src="./main.js"></script>
  </body>
</html>

这个页面的职责很简单：用户点击加载模型后，进入模型下载和初始化阶段；初始化完成前，发送按钮保持禁用，防止用户提交无法处理的请求。pre 标签天然保留换行和空格，适合流式输出文本。

4.2 引擎初始化和模型加载

创建 main.js，从 @mlc-ai/web-llm 导入 CreateEngine。新版 WebLLM 推荐用 CreateEngine 创建引擎实例，地址不同的旧版本可能使用 ChatModule，如果项目引入的包没有导出 CreateEngine，先查看当前包内的类型定义。

javascript复制import { CreateEngine } from "@mlc-ai/web-llm";

const modelId = "Qwen2.5-1.5B-Instruct-q4f16_1-MLC";

const loadBtn = document.getElementById("load-btn");
const statusEl = document.getElementById("model-status");
const sendBtn = document.getElementById("send-btn");
const stopBtn = document.getElementById("stop-btn");
const promptEl = document.getElementById("prompt");
const outputEl = document.getElementById("output");

let engine = null;
let stopped = false;

loadBtn.addEventListener("click", async () => {
  loadBtn.disabled = true;
  statusEl.textContent = "正在创建引擎实例...";

  const engineConfig = {
    model: modelId,
    useWebWorker: true,
  };

  engine = await CreateEngine(engineConfig);

  engine.events.addEventListener("loadprogress", (event) => {
    const progress = event.progress;
    const percent = Math.round(progress * 100);
    statusEl.textContent = `模型加载中：${percent}%`;
  });

  engine.events.addEventListener("loadcomplete", () => {
    statusEl.textContent = "模型加载完成，可以开始对话";
    sendBtn.disabled = false;
    stopBtn.disabled = false;
  });
});

useWebWorker: true 的作用是把推理逻辑放到 Web Worker 中执行，避免主线程被 GPU 调度和计算任务阻塞，页面按钮和文本区域因此还能保持响应。这个参数在部分版本中也写作 useWorker，如果 TypeScript 报错，以当前包的声明文件为准。

4.3 流式生成回复

发送逻辑使用 OpenAI 兼容接口，并开启 stream: true 让模型按 token 流式返回：

javascript复制sendBtn.addEventListener("click", async () => {
  const prompt = promptEl.value.trim();
  if (!prompt || !engine) {
    return;
  }

  sendBtn.disabled = true;
  stopped = false;
  outputEl.textContent = "";

  const messages = [{ role: "user", content: prompt }];

  const reply = await engine.chat.completions.create({
    messages,
    temperature: 0.8,
    top_p: 0.9,
    max_tokens: 512,
    stream: true,
  });

  for await (const chunk of reply) {
    if (stopped) {
      await engine.interrupt();
      break;
    }
    const delta = chunk.choices[0]?.delta?.content ?? "";
    outputEl.textContent += delta;
  }

  sendBtn.disabled = false;
});

stopBtn.addEventListener("click", () => {
  stopped = true;
});

流式回复对象是一个异步可迭代对象，for await 每次拿到一个 chunk。每个 chunk 的 choices[0].delta.content 是当前新增的文本片段，把它们依次追加到输出区域，用户就会看到逐字流出的效果。

调用 engine.interrupt() 可以中断当前生成。由于生成过程本身在异步迭代中，停止按钮只是先设置标记，再在下一个 chunk 到来时执行中断。这种设计避免了直接打断异步循环导致的竞态问题。

4.4 运行流程与预期输出

启动开发服务器：

bash复制npm run dev

在浏览器打开 Vite 输出的地址，通常是 http://localhost:5173。这个过程不涉及本地 HTTP 服务问题。

操作顺序和预期现象如下：

1. 点击“加载模型”，状态栏先显示“正在创建引擎实例”。
2. 浏览器开始从模型仓库下载权重，状态栏的百分比持续推进。
3. 加载完成变成 100% 后，状态栏显示完成文案，发送按钮可用。
4. 输入问题，点击发送，输出区域开始逐字显示模型回复。
5. 生成过程中点击“停止”，输出中断，回复保留已生成部分。

如果页面停在 0% 且没有报错，优先看 Network 面板中是否有模型文件请求失败；如果发送后长时间无输出，优先检查 WebGPU 是否可用。

5. 关键 API 和配置参数详解

5.1 引擎配置与模型标识

CreateEngine 接收一个配置对象，最核心的字段是 model 或 model_list。单个模型时直接指定 model，多模型或自定义模型仓库时，可以通过 model_list 传入完整的模型描述数组。

一个自定义模型条目大致包含以下信息：

json复制{
  "model": "https://example.com/models/my-model/",
  "model_id": "My-Model-q4f16_1-MLC",
  "model_lib": "https://example.com/models/my-model/my-model.wasm"
}

其中 model_id 是应用层引用模型的名称，model 是权重资源地址，model_lib 是编译后的 WebAssembly 库文件地址。生产环境中，这些资源应放到全球 CDN 或可控的静态文件服务上，因为模型文件通常达到数百兆，直接放在业务服务器会占用大量出口带宽。

5.2 推理参数如何影响输出质量

engine.chat.completions.create 的请求参数与服务端接口风格接近。常用参数如下：

这些参数不改变模型本身的能力，只改变采样过程的选择偏好。误调并不会报错，但会直接影响流式输出质量和中断时间。

5.3 加载进度事件与生命周期

引擎实例通过 engine.events 对外发送事件。loadprogress 事件携带 progress 字段，范围是 0 到 1，表示模型加载进度。加载完成后会触发 loadcomplete。在事件回调里更新 UI，是 WebLLM 应用最自然的做进度展示的方式。

需要注意，模型下载不一定一次成功。如果用户中途刷新页面，浏览器缓存可能保存了部分资源，再次加载时会从缓存续读。此时进度条从 0 重新开始是一种常见表现，不代表白下载。生产环境可以记录模型大小和缓存状态，向用户展示更明确的信息。

5.4 清除对话与上下文管理

引擎内部会维护对话历史相关的 KV 缓存和消息列表。如果用户点击“新对话”，调用：

javascript复制await engine.resetChat();

resetChat 会清空当前对话的缓存状态，后续请求从新的会话开始。如果不调用该接口而继续发送消息，模型会沿用之前的上下文中止断言，表现为回答越来越“记得”前面说过的话。Serving 端 API 会要求客户端传入完整 messages 列表，但 WebLLM 的引擎内部自己记住了历史，所以两边机制略有不同。这个差异在接入旧习惯时容易踩坑。

6. 运行验证：从“能聊天”到“能确认性能”

6.1 在开发者工具里确认 WebGPU 和加载状态

模型能聊天不代表 WebGPU 一定参与了计算。为了确认推理确实发生在 GPU 上，可以打开 Chrome 开发者工具，在地址栏输入：

text复制chrome://gpu

查看 WebGPU 一节的状态，正常时它会显示可用或类似信息。也可以在 Console 执行：

javascript复制navigator.gpu

如果返回对象，说明当前页面具备 WebGPU 入口。再调用：

javascript复制navigator.gpu.requestAdapter()

获得 GPUAdapter 后可以查看 adapter.limits。这些字段用于理解当前设备能分配的最大缓冲区宽度、最大存储缓冲区范围等约束。WebLLM 对设备限制有兜底逻辑，但部分旧驱动仍可能因限制过小而加载失败。

6.2 用日志定位 prefill 和 decode 的耗时

WebLLM 的日志开关和打印方式会随版本变化。一种可行的方法是在代码里围绕调用点自己计时。

javascript复制const start = performance.now();
const reply = await engine.chat.completions.create({ messages, stream: true, max_tokens: 512 });

let firstTokenTime = null;
for await (const chunk of reply) {
  const text = chunk.choices[0]?.delta?.content ?? "";
  if (text && firstTokenTime === null) {
    firstTokenTime = performance.now();
    console.log("first token delay:", (firstTokenTime - start).toFixed(1), "ms");
  }
}

首 token 延迟基本对应 prefill 阶段和首次调度开销，之后逐字输出的速度对应 decode 阶段。通过在关键位置打印性能指标，可以对比不同模型、不同 prompt 长度和不同量化配置的实际表现。

6.3 验证取消生成没有留下后台任务

点击停止之后，还需要确认模型真的停止了。一个简单验证是在停止后再发一条消息，观察新回复是否正常开始。如果第二条消息迟迟不返回，可能是 interrupt 没有生效，旧生成仍占用引擎。此时应检查是否在 for await 的每一轮都响应了中止标记，并保证中断后重新启用发送按钮。

生产环境的验证还应增加异常分支：断网时加载模型的提示、模型下载失败时的重试按钮、生成失败后消息输入框的恢复逻辑。只验证“正常能聊天”远远不够。

7. 常见问题排查：把失败拆成几类

7.1 第一类：WebGPU 不可用

现象：Console 提示 navigator.gpu is undefined，或者 CreateEngine 直接拒绝执行。

常见原因：页面不是 localhost 或 HTTPS；浏览器版本过低；硬件加速被关闭；GPU 驱动不支持。

处理顺序：

1. 先确认页面地址是 http://localhost:端口 而不是双击 HTML 文件。
2. 打开 chrome://gpu，确认 WebGPU 是否可用。
3. 打开浏览器设置，确认“使用硬件加速”已开启，并重启浏览器。
4. 更换为较新的 Chrome 或 Edge 再试。

注意：通过手机或局域网 IP 访问本地页面时，http://192.168.x.x 通常不满足安全上下文要求，WebGPU 很可能不可用。开发阶段尽量统一使用 localhost。

7.2 第二类：模型加载失败或 404

现象：进度条卡在某个百分比，Network 面板出现大量红色请求，或者控制台出现模型资源加载失败。

常见原因：modelId 写错；自建模型仓库路径不对；CDN 或静态服务器缺少 CORS 响应头。

处理方式：先从项目官方模型列表中复制完整模型 id，不要凭记忆手写。若使用自定义地址，用 curl 验证资源地址可访问且 Content-Type 正确；自建模型仓库要允许跨域访问，需要配置 Access-Control-Allow-Origin。静态服务器的最小 CORS 配置如下：

text复制Access-Control-Allow-Origin: *

生产环境应根据来源域名缩小白名单，不要无条件放开跨域。

7.3 第三类：内存不足或浏览器崩溃

现象：模型加载一段时间后标签页白屏，浏览器弹出“页面无响应”提示，或者移动端直接闪退。

常见原因：模型规模超过本机内存和显存容量；同时打开了多个大模型页面；量化精度配置过高。

处理方式：优先选择更小的模型或更高压缩的量化版本，例如从 3B 降到 1B，从非量化版换到 q4f16。加载前检查 navigator.deviceMemory，在低内存设备上直接降级到更小模型或给出明确提示。还要提醒用户关闭其他占用 GPU 的标签页，比如视频会议页面和在线 3D 预览应用。

7.4 第四类：有输出但速度极慢

现象：模型加载成功，发送后要等很久才出现第一个字，后续逐字输出也很慢。

常见原因：GPU 未被启用，计算落到了 CPU；模型过大，显存带宽耗尽；没有使用 Web Worker，主线程被阻塞；模型量化不合适。

排查顺序：先确认 WebGPU 确实可用，再对比不同 prompt 长度的首 token 延迟。若首 token 延迟随输入长度线性上升，说明 prefill 计算正常但设备算力有限。若输出速度极慢且 GPU 占用不高，检查驱动和 GPU 后端是否真正生效。最后尝试 useWebWorker: false 与 true 两种模式，观察页面阻塞情况和输出速度，定位瓶颈是计算还是线程调度。

排查时遵循这条链路：先检查是否 localhost 或 HTTPS，再检查浏览器 WebGPU 支持，然后检查依赖版本和模型 id，最后看网络请求、磁盘空间与显存余量。不要一上来就怀疑框架，多数问题发生在环境层。

8. 最佳实践：从 Demo 走向可交付页面

8.1 学习环境与生产环境的差异

学习环境跑通 demo 只需要一台支持 WebGPU 的桌面浏览器和一个小模型。生产环境要额外考虑模型托管、HTTPS、缓存、重试、资源占用监控和降级方案。

8.2 UI 交互规律

使用 useWebWorker: true 时，推理不阻塞主线程，但仍可能出现首 token 等待。页面应该给用户明确反馈：加载中显示进度，生成中禁用发送按钮并显示停止按钮，生成完成后把输入框恢复可用。

不要在每一个 delta 都直接执行重渲染。示例中直接拼接字符串在 Demo 阶段足够，但生产环境如果回答有几千字，频繁修改 DOM 会造成不必要的压力。建议每积累一段文本后再刷新输出区域，或者使用虚拟滚动区域展示长文本。

8.3 模型选型和量化建议

模型选择要基于“用户机器能跑多少算力”来做决定，而不是盲目追求大模型。浏览器端推理受本机内存、显存、驱动和浏览器限制，模型越大量化等级越高，内存占用越高，输出速度也可能明显下降。

建议在小模型上先跑通产品流程，再根据实际机型测试结果升级。量化格式中，q4f16 是常见均衡选择，它把权重压缩到 4 bit 左右同时保留 FP16 精度的部分计算路径，适合模型分发。具体选型要以 WebLLM 当前模型库和 MLC 编译工具支持为准，不要照搬旧文档里的固定结论。

8.4 隐私边界和数据声明

WebLLM 最大的产品价值就是本地推理，但它不是绝对的隐私保险箱。模型文件本身来自远程仓库，加载过程仍然会访问外部域名；浏览器扩展、开发者工具和本机恶意软件都可能读取页面内数据。如果要向用户承诺隐私保护，还需要配合关闭网络上报、静态资源只读、代码审计等完整措施。

产品文案应准确描述为“推理发生在本地浏览器中”，而不是笼统的“绝对安全”。这种差异是需要写进技术方案评审里的。

9. 扩展方向：WebLLM 还能往哪里走

9.1 与浏览器缓存配合的离线应用

WebLLM 模型下载完成后会存放在浏览器缓存中。结合 Service Worker 和服务端静态资源预缓存，可以让页面在断网后依然完成模型加载和本地推理。这种能力适合离线顾问、离线翻译、内部知识问答等场景。

需要特别注意的是，模型文件体积较大，缓存策略要设计清楚：首次访问下载，后续命中缓存；版本更新时通过资源指纹替换旧模型。常规 HTTP 缓存头在这里仍然适用，但需要在发布模型版本时做好文件名或 URL 变化管理。

9.2 在 Web Worker 中做后台推理

useWebWorker: true 只是基础用法。更复杂的场景可以把整个推理引擎封装到独立 Worker 中，通过消息协议接收待处理文本、返回进度和流式结果。这样即使用户切换到其他标签页，Worker 仍可继续运行，适合批量文本摘要、本地内容审核等异步任务。

9.3 多模型切换与自建模型库

一个生产级页面通常需要多个模型：轻量模型处理通用对话，更大模型处理长文本，甚至需要针对特定领域微调后的模型。应用层可以维护模型列表，在切换时销毁旧引擎并加载新模型。资源地址统一放在配置中心，避免把模型 URL 散落在业务代码里。

9.4 值得继续研究的方向

浏览器端推理还在快速变化中。值得持续跟踪的方向包括：更小参数量但效果更好的端侧模型；WebGPU 计算能力的进一步释放；KV cache 的页面级复用；多模态模型在浏览器内的输入输出处理；以及端侧推理与服务端推理的混合调度，让用户设备算力不足时自动切换远端候选。

实际项目里，最值得先做的一件事是跑通本文的最小案例，然后换一个不同规模的模型，记录加载时间、首 token 延迟和输出速度的差异。只有亲手对比过这些数据，才能真正理解 WebLLM 为什么把精力投入在模型编译、量化和 WebGPU 调度上，也才能在方案选型时提出站得住脚的建议。浏览器端大模型推理不会是所有场景的答案，但它在隐私、离线、成本与延迟之间提供了一条完全不同的路径。