浏览器端跑大模型可行吗：WebGPU 端侧推理实测与落地场景评估

把大模型跑在用户浏览器里，听起来像噱头，但有三类需求是真金白银的：一是隐私合规，医疗、法律、企业内部文档场景里「文本不出设备」本身就是卖点；二是成本，云端推理按 token 计费，日活一上来账单吓人，端侧跑小模型边际成本为零；三是离线与弱网可用。随着 Chrome、Edge 已默认启用 WebGPU，Safari 与 Firefox 也在跟进支持，浏览器终于有了接近原生 GPU 计算的能力，端侧推理从「技术演示」走向「可以评估」。

但「可以评估」不等于「无脑上」。本文把端侧推理的技术底座、可跑通的代码、真实的约束边界和适合的业务场景一次讲清，帮你在立项之前做出靠谱判断。

两条技术路径：WebGPU 与 WASM 的分工

浏览器里的推理引擎本质都是「把模型图编译成浏览器可执行的计算」，目前两条主流路径：

维度	WebGPU 路径	WASM 路径（SIMD + 多线程）
算力上限	高，GPU 并行计算	低，CPU 单机性能
兼容性	新浏览器为主，部分老设备缺失	几乎全平台可用
模型体量	可跑到数 B 参数的量化模型	通常局限在百 M 级小模型
典型框架	Transformers.js、WebLLM、MediaPipe LLM 推理	Transformers.js、ONNX Runtime Web

实践中的关系是「主备」而非「二选一」：优先尝试 WebGPU，检测不可用时回退 WASM。Hugging Face 的 Transformers.js 是最顺手的入口——它基于 ONNX Runtime Web，一套 API 同时支持 webgpu 与 wasm 两种执行后端，模型从 Hugging Face Hub 直接加载，社区维护了大量已转换好的开源模型。

实操：用 Transformers.js 跑通端侧生成模型

先装依赖，再写一个带后端探测与下载进度反馈的加载器。推理计算必须放进 Web Worker，否则主线程会被阻塞到页面失去响应：

// ai-worker.ts：端侧推理 Worker，避免阻塞主线程
import { pipeline, env } from "@huggingface/transformers";

// 检测 WebGPU：可用则走 GPU，不可用回退 WASM，全程不白屏
const device = navigator.gpu ? "webgpu" : "wasm";

// text-generation 任务 + 0.5B 级量化模型，q4 量化把下载体积压到最小
const generator = await pipeline(
  "text-generation",
  "onnx-community/Qwen2.5-0.5B-Instruct",
  {
    device,
    dtype: "q4",
    // 进度回调：把模型下载进度同步给 UI 层，缓解首包等待焦虑
    progress_callback: (p) => {
      if (p.status === "progress") {
        self.postMessage({ type: "download", file: p.file, percent: p.progress });
      }
    }
  }
);

// 主线程发来的消息格式：{ messages: [{ role, content }] }
self.onmessage = async (e) => {
  const output = await generator(e.data.messages, {
    max_new_tokens: 128,
    do_sample: false // 确定性输出，便于测试与对比
  });
  self.postMessage({ type: "result", text: output[0].generated_text.at(-1).content });
};

主线程侧只负责创建 Worker、透传对话历史、接收进度与结果事件。首次运行时模型权重会从 Hugging Face 的 CDN 下载并写入浏览器缓存（Cache Storage），之后离线也能加载，这个特性正是离线场景的地基。

几个参数选择直接影响体验：dtype: "q4" 四位量化是端侧的默认起点，下载体积约为全精度的四分之一；模型规模从 0.5B 起步验证链路，确认价值后再考虑 1B~3B 的质量升级——每上一个台阶，下载体积和显存占用都是数倍增长。

约束边界：显存、首包与性能的真实水位

评估立项前，三个硬约束必须心中有数：

显存与内存。模型权重要整体载入 GPU 显存（WebGPU 路径）或内存（WASM 路径）。0.5B 模型 q4 量化后是几百 MB 级，桌面独显毫无压力；3B 模型是数 GB 级，多数集显笔记本已到临界，移动端基本出局。加载多个大模型或反复加载容易触发设备丢失（device lost），页面直接黑屏。

首包体积。模型权重不走构建产物，但几百 MB 的首次下载依然要把用户预期管理好：进度条、CDN 长缓存、按需加载（先载入轻量功能模型，重模型延迟加载）都是必备动作。

生成速度。桌面独显跑 0.5B 量化模型通常能到几十 token 每秒的量级，流畅如本地打字机；老旧集显和移动设备会掉到个位数，体验从「可对话」劣化为「可等待」。这也是为什么端侧适合短平快的小任务，不适合长篇生成。

落地场景评估：哪些值得做，哪些别做

把上面的约束代入业务，结论就比较清晰了。

值得做：输入内容脱敏与本地敏感信息预筛（文本不出端，合规卖点直接成立）；离线场景的翻译、摘要、文本纠错（下载一次终身可用）；表单智能填充、输入联想这类高频低复杂度任务（小模型足够，响应快）；端侧向量化（embedding）做本地语义搜索，配合云端的复杂问答形成混合架构。

别做：需要最新知识的问答（端侧小模型没有联网能力，幻觉率显著更高）；长上下文、多轮 Agent 编排（上下文窗口与算力双双不足）；对生成质量敏感的 C 端主链路（小模型与旗舰云端模型的差距用户一用便知）。

成熟度最高的形态是混合架构：端侧负责「预筛、向量化、轻任务」，云端负责「重推理、兜底」，用一条规则路由——判断文本是否敏感、任务复杂度高低，各自走最适合的路径。既吃到端侧的隐私与成本红利，又不牺牲复杂场景的体验。

避坑总结

推理必须放 Web Worker。主线程跑推理会冻结页面交互，Worker 通信用结构化消息即可，不要为了「省事」在主线程 pipeline，上线后卡顿投诉必来。
dtype 从 q4 起步，别默认全精度。fp32 全精度让下载体积和显存占用翻倍以上，低端设备直接加载失败；q4 质量不达标再逐级升 fp16，每一步都实测对比。
显存预算要有上限控制。同一页面只保留一个推理实例，切换模型先释放再加载；多模型并发加载是设备丢失（device lost）黑屏的头号原因。
模型文件配长缓存与正确跨域头。权重文件走允许跨域的 CDN 并设置长有效期，否则每次刷新全量重下，几百 MB 的重复下载足以劝退用户。
优雅降级是上线底线。WebGPU 检测失败回退 WASM，WASM 也不达标时明确提示并回退云端 API，任何环节都不要让用户面对白屏或无限加载。

写在最后

端侧推理不是要替代云端，而是给前端工程师多了一件架构武器：隐私、离线、成本三座大山，以前只能绕着走，现在可以在端上拆掉一角。判断标准其实很朴素——任务是否短小高频、数据是否出不得端、用户设备是否可控，三问有两个答案是，就值得做一次 0.5B 模型的原型验证。剩下的，交给实测数据说话。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。

浏览器端跑大模型可行吗：WebGPU 端侧推理实测与落地场景评估 ​

两条技术路径：WebGPU 与 WASM 的分工 ​

实操：用 Transformers.js 跑通端侧生成模型 ​

约束边界：显存、首包与性能的真实水位 ​

落地场景评估：哪些值得做，哪些别做 ​

避坑总结 ​

写在最后 ​