先说结论在浏览器里跑大模型不是把模型文件丢给前端页面那么简单。它真正的价值是把 AI 推理从“服务端集中计算”变成“端侧分布式计算”而 WebGPU 就是这个转变里最关键的地基。对前端开发者来说这不是一门无关技术而是未来 AI 应用的基础设施之一。很多人第一次看到 “Running an LLM in the Browser” 这种标题时第一反应是浏览器装得下几十 GB 的模型吗就算装下了CPU 跑一个大模型不得等到天荒地老这个疑问放在三年前成立但今天已经不一样了。模型量化把权重压到原来的十分之一甚至二十分之一WebGPU 让浏览器可以直接调用 GPU 做通用计算1.5B、3B 甚至 7B 的量化模型已经可以在普通笔记本的浏览器里跑出可用速度而且输入的数据完全不出本机。这篇文章会带你完成一次完整的浏览器本地推理实践先讲清楚 WebGPU 到底是什么、它怎么支撑大模型推理然后给出 WebGPU 支持检测的具体代码接着对 WebLLM、Transformers.js 等主流方案做选型对比再用一个 WebLLM 的完整示例把“模型下载、WebGPU 推理、流式输出”跑通最后把常见问题和工程建议一次性列清楚。如果你正在做隐私敏感的工具、离线应用或者单纯想省掉推理服务器成本这篇文章值得收藏。1. 这篇文章真正要解决的问题在展开技术细节之前先回答一个问题为什么要在浏览器里跑 LLM服务端有 A100、H100有成熟的推理框架为什么非要让浏览器做这件事因为不是所有场景都负担得起也不是所有数据都适合上传。1.1 服务端推理的三座大山第一座山是成本。一个可用的生成式 AI 功能背后通常是一台 GPU 服务器或者按 Token 计费的 API。个人开发者做个小工具每个月可能没有收入却要先付服务器账单。企业内部做文档助手一次对话动辄几百上千 Token量大了之后费用会非常可观。第二座山是隐私。把文档、聊天记录、代码片段发给外部 API在很多场景下是合规红线。金融、医疗、法律、企业内部管理系统数据出境或者离开本地网络都是大问题。即使供应商承诺“数据不用于训练”业务方也很难过自己内部的合规审查。第三座山是延迟。用户点一下发送请求要到服务器排队再由模型一条条生成 Token 再传回来。网络好时还好网络一抖交互体验就很差。还有限流、鉴权、服务可用性这类问题每个都要单独处理。1.2 浏览器本地推理改变了什么浏览器本地推理把“推理”这一层从云上挪到了每个用户的设备上。模型权重在浏览器里加载输入经过 Tokenizer 编码之后直接走 GPU 计算整个过程没有网络请求数据不离开设备。它的优势非常直接维度服务端推理浏览器本地推理单次调用成本按 Token 或按实例计费几乎为零用用户设备的算力数据隐私需要上云有合规风险数据不出设备网络依赖强依赖断网不可用模型加载后可离线使用并发能力取决于服务器容量每个用户各自承担算力模型能力可跑超大模型受设备内存和算力限制适合小模型部署维护需要维护 GPU 集群纯静态资源无需维护推理服务当然它的代价也很明显模型规模有限首屏需要下载几百 MB 到几个 GB 的权重推理速度取决于用户设备的 GPU。所以它不是一个“替代服务端推理”的方案而是一个“补充服务端推理”的方案。1.3 谁最应该读这篇文章如果你正在做下面这几类事情这篇文章对你的帮助最大想做端侧 AI 应用但不确定浏览器方案是否可行接了 OpenAI 之类的 API但担心成本和数据隐私想用大模型做文档助手、聊天机器人、代码补全但不想为每个用户都准备 GPU 服务器已经听过 WebGPU但不知道它和普通网页开发有什么关系想给自己的项目加 AI 功能但希望跑通最小示例再判断值不值得。2. WebGPU 是什么为什么它能跑大模型WebGPU 不是一个新的 JavaScript 库而是一个浏览器图形与计算 API 标准。它由 W3C 的 GPU for the Web 工作组制定目标是让网页程序能够高效地使用 GPU 进行渲染和通用计算。2.1 从 WebGL 到 WebGPU在 WebGPU 之前浏览器里调用 GPU 主要靠 WebGL。WebGL 脱胎于 OpenGL ES设计上主要是为了图形渲染。它能做 GPU 计算但方式非常别扭要把计算任务伪装成绘制过程用 Fragment Shader 来算限制很多性能也不是为通用计算设计的。WebGPU 则直接面向现代 GPU 架构。它提供了独立的 Compute Shader计算着色器能力可以像科学计算程序一样在 GPU 上执行大规模并行计算。这个概念上的差异很关键大模型推理本质上是海量矩阵乘法是典型的通用计算任务不是图形任务。WebGL 时代没法高效跑 LLM不是浏览器不努力而是 API 的设计目标就不在这里。2.2 WebGPU 的核心计算流程WebGPU 的编程模型和原生图形 API 类似几个核心概念值得先记住Adapter代表底层 GPU 硬件类似于显卡驱动的入口。Device从 Adapter 上创建出来的逻辑设备所有计算都要通过 Device 提交。Shader Module用 WGSLWebGPU Shading Language写的 GPU 程序。Compute Pipeline把 Shader 编译成 GPU 可以执行的管线。Bind Group把输入输出数据绑定到 Shader 的通道。LLM 推理时模型的每个算子矩阵乘法、LayerNorm、Attention都会被编译成不同的 compute shader。前向传播就是一次次 GPU kernel 调度的过程。WebGPU 暴露了这种底层能力浏览器里的 AI 推理才有了性能基础。2.3 浏览器跑 LLM 的三层原理把一个大模型塞进浏览器从技术栈上至少需要三层配合第一层是模型编译层。PyTorch 模型不能在浏览器里直接跑需要先编译成浏览器可执行的 GPU 程序。WebLLM 背后的 MLC LLM 项目就是用编译器把模型从 PyTorch 编译成针对 WebGPU 调优的 shader。Transformers.js 走的路径不同它把 PyTorch 模型转成 ONNX 格式然后用 ONNX Runtime Web 在浏览器里执行。第二层是推理调度层。模型跑起来之后还要管理 KV Cache注意力缓存、生成掩码、batch 解码、采样逻辑。这些在浏览器里没有现成的框架而是由推理库WebLLM / Transformers.js 等内置实现。第三层是运行时层。WebGPU 的 Adapter/Device 管理、显存分配、Web Worker 多线程、WASM SIMD 加速都在这一层。很多性能差异其实不是模型本身的问题而是这一层优化得好不好。2.4 WebGPU 与 WASM、WebNN 的边界很多文章把 WebGPU、WASM、WebNN 混在一起说容易造成误解。它们解决的是不同层面的问题技术能力适合场景WebGL图形渲染为主通用计算受限3D 渲染、简单图像后处理WebGPU通用 GPU 计算支持 compute shaderLLM 推理、图像处理、科学计算WASMCPU 执行可编译 C/C/Rust 代码无 GPU 场景、兼容性兜底WebNN面向神经网络的硬件加速 API仍在演进未来可能统一 CPU/GPU/NPU 加速简单说WASM 是 CPU 上的方案WebGPU 是 GPU 上的方案WebNN 是为深度学习专门设计的更高层 API。现在浏览器里跑 LLM最主流的加速路径就是 WebGPU。3. 环境准备先验证 WebGPU在写推理代码之前先确认你的环境到底支不支持 WebGPU。这一步做不好后面所有代码都可能白写。3.1 浏览器版本与系统要求WebGPU 已经从实验室走进稳定版浏览器。Chrome 和 Edge 从 113 版本开始默认支持 WebGPU覆盖 Windows、macOS、ChromeOS后续逐步扩展到 Linux。Firefox 和 Safari 也在最近一年里迈出了默认支持这一步但主流生产环境还是建议优先考虑 Chromium 内核的浏览器。不过要注意浏览器支持 WebGPU不代表你的设备一定能用。如果电脑没有独立显卡或者显卡驱动过旧、被系统屏蔽GPU 适配器可能拿不到。所以检测逻辑不能只看 API 是否存在还要真正尝试获取 Adapter 和 Device。3.2 用 navigator.gpu 检测 WebGPU 支持WebGPU 的 API 入口是navigator.gpu。检测的第一步是确认这个对象存在第二步是调用requestAdapter()获取 GPU 适配器第三步是调用adapter.requestDevice()创建逻辑设备。只有这三步都成功才说明 WebGPU 真正可用。下面是一段可以直接运行的检测代码// check-webgpu.js async function checkWebGPU() { const result document.getElementById(result); // 第一步确认 API 是否存在 if (!(gpu in navigator)) { result.textContent 不支持当前浏览器没有 WebGPU API请升级到 Chrome/Edge 113; return; } try { // 第二步获取 GPU 适配器 const adapter await navigator.gpu.requestAdapter(); if (!adapter) { result.textContent 不支持浏览器存在 WebGPU API但无法获取 GPU 适配器; return; } // 第三步创建逻辑设备 const device await adapter.requestDevice(); const info adapter.info || {}; result.innerHTML [ 支持 WebGPU, GPU 厂商: (info.vendor || 未知), GPU 架构: (info.architecture || 未知), 设备说明: (info.description || 未知) ].join(br/); device.destroy(); } catch (e) { result.textContent 检测异常: e.message; } } checkWebGPU();这段代码的关键点在于navigator.gpu存在只是第一步很多老版本浏览器或 Linux 环境可能已经暴露了 API但requestAdapter()返回null或者requestDevice()直接抛错。只有三步全部成功才能放心地进入后面的推理环节。3.3 完整的 HTML 检测页面把上面的脚本放进一个 HTML 页面再配上一个简单的样式就能在浏览器里直接验证!-- check-webgpu.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / titleWebGPU 支持检测/title /head body h2WebGPU 支持检测/h2 div idresult检测中.../div script src./check-webgpu.js/script /body /html用浏览器打开这个页面如果显示“支持 WebGPU”并列出 GPU 厂商和架构说明环境已经满足条件。如果提示不支持优先检查三件事浏览器版本是否足够新、操作系统是否能正常使用 GPU、浏览器设置里是否启用了硬件加速。3.4 其他验证手段chrome://gpu 与 WebGPU Inspector除了写代码还可以用浏览器内置工具验证。在 Chrome 地址栏输入chrome://gpu搜索 “WebGPU” 关键字如果状态显示 “Enabled”说明浏览器层面已经开启。Edge 对应的地址是edge://gpu。如果你要做更细致的调试推荐安装 Chrome 扩展 WebGPU Inspector。它能记录 WebGPU 的 API 调用、查看每一帧的 compute shader 执行情况、检查 buffer 内容、统计 GPU 内存使用。在排查推理性能问题时这个工具比 console.log 好用得多。3.5 一个容易忽略的前提安全上下文与跨域隔离WebGPU 本身要求安全上下文HTTPS 或 localhost这基本不会有问题。真正容易踩坑的是跨域隔离配置。部分推理库为了多线程加速会使用SharedArrayBuffer而浏览器要求页面必须设置两个响应头才允许使用它Cross-Origin-Opener-Policy: same-originCross-Origin-Embedder-Policy: require-corp如果你是本地开发用 Vite 的话可以在配置文件里加上// vite.config.js import { defineConfig } from vite; export default defineConfig({ server: { headers: { Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp, }, }, });如果是生产部署可以在 Nginx 或云服务的响应头配置里加同样的两个 Header。注意开启require-corp之后页面加载的所有跨域资源都需要带Cross-Origin-Resource-Policy头或正确的Access-Control-Allow-Origin否则会被浏览器拦截。这也是开发环境下容易突然白屏的原因。4. 本地推理方案选型环境确认没问题之后下一步是选推理方案。目前浏览器里跑 LLM 的主流方案主要有三个它们的定位和适用场景差别不小。4.1 主流方案盘点第一个是 WebLLM包名mlc-ai/web-llm由 MLC AI 团队开源。它基于 MLC LLM 编译器把模型直接编译成针对 WebGPU 调优的 shader性能在浏览器方案里是第一梯队。API 设计也贴近 OpenAIchat.completions.create这种写法对开发者很友好。第二个是 Transformers.js由 Xenova 开发现在属于 Hugging Face 生态。它把 PyTorch 模型转成 ONNX 格式通过 ONNX Runtime Web 在浏览器里运行。它的生态庞大Hugging Face 上有大量onnx-community模型可以直接用同时也支持 WASM 作为降级方案。第三个是 llama.cpp 的 WASM 版本。llama.cpp 主线就支持编译成 WebAssembly可以把 GGUF 模型直接在浏览器里跑。它的优势是模型格式统一和本地服务端用的模型一致劣势是纯 WASM 默认走 CPU速度很难和 WebGPU 方案相比适合作为无 GPU 场景的兜底。4.2 选型对比方案内核实现模型格式GPU 加速上手难度典型用途WebLLMMLC LLM 编译MLC 编译产物WebGPU中聊天、代码生成、端侧 AgentTransformers.jsONNX Runtime WebONNX / GGUFWebGPU / WASM低文本分类、摘要、小模型推理llama.cpp WASMllama.cppGGUF无WASM中高CPU 兜底、模型验证如果目标是快速跑通一个聊天机器人WebLLM 是最顺手的选择因为模型编译、KV Cache、采样逻辑都已经封装好了。如果目标是做文本分类、情感分析、小规模生成且希望模型选择空间大Transformers.js 更合适。如果项目原本就在服务端用 llama.cpp 跑 GGUF想原样搬到浏览器试试可以研究 llama.cpp 的 WASM 构建。4.3 模型和量化怎么选浏览器推理受设备内存和算力约束模型参数量不能拍脑袋定。经验上说可以按这个量级做参考参数量量化格式模型文件大小约适合设备0.5Bq4f16400MB 左右手机、老电脑1.5Bq4f161GB 左右8GB 内存以上的普通笔记本3Bq4f161.8GB 左右Apple Silicon、中端独显7Bq4f164GB 左右6GB 显存以上的独立显卡以上大小为数量级参考实际以模型仓库标注为准。q4f16 表示 4-bit 量化的权重加 fp16 计算累加是目前浏览器推理里兼顾速度和质量的主流格式。它的含义是权重压缩到 4 bit但计算过程中用 fp16 做中间运算质量损失在可接受范围内。q4f32 精度更高但更慢q0f32 是原始 fp32 权重体积大、速度慢不建议在浏览器里用。对新手来说最稳妥的起步方式是选 1.5B 的 q4f16 量化模型。它能在绝大多数现代电脑上流畅运行模型能力也足够演示和开发。5. 完整示例用 WebLLM 跑通浏览器本地推理下面进入核心实操。我们创建一个最小项目用 WebLLM 在浏览器里跑通“下载模型 - WebGPU 推理 - 输出回复”的完整流程。5.1 初始化项目mkdir browser-llm-demo cd browser-llm-demo npm init -y npm install mlc-ai/web-llm npm install -D vite安装时以 npm 实际发布的最新版本为准本文使用 0.2.x 系列的 API 编写。项目结构如下browser-llm-demo/ ├── index.html ├── main.js └── package.json5.2 创建 HTML 推理页面!-- index.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / title浏览器本地 LLM 推理 Demo/title /head body h2浏览器本地 LLM 推理WebGPU/h2 select idmodel-select option valueQwen2.5-1.5B-Instruct-q4f16_1-MLCQwen2.5-1.5B (q4f16)/option option valueQwen2.5-3B-Instruct-q4f16_1-MLCQwen2.5-3B (q4f16)/option /select div idprogress准备初始化.../div input idmessage-input typetext placeholder输入你的问题... / button idsend-button发送/button pre idoutput/pre script typemodule src./main.js/script /body /html页面里有三个关键元素模型选择下拉框、加载进度展示区、输入区和输出区。这只是最小演示实际产品里还会加上加载动画、错误提示和流式输出。5.3 编写 WebLLM 推理逻辑// main.js import * as webllm from mlc-ai/web-llm; const modelSelect document.getElementById(model-select); const messageInput document.getElementById(message-input); const sendButton document.getElementById(send-button); const progress document.getElementById(progress); const output document.getElementById(output); let engine null; // 加载进度回调WebLLM 会周期性调用这个函数 const initProgressCallback (report) { progress.textContent 加载模型${Math.round(report.progress * 100)}%${report.text}; console.log(report); }; async function initEngine() { const selectedModel modelSelect.value; progress.textContent 开始加载模型请保持页面打开...; engine await webllm.CreateMLCEngine(selectedModel, { initProgressCallback, }); progress.textContent 模型已就绪可以开始对话。; } modelSelect.addEventListener(change, () { output.textContent ; initEngine(); }); sendButton.addEventListener(click, async () { if (!engine) { output.textContent 模型尚未初始化完成请稍等。; return; } const userMessage messageInput.value.trim(); if (!userMessage) return; output.textContent 思考中...; const start performance.now(); const reply await engine.chat.completions.create({ messages: [{ role: user, content: userMessage }], }); const cost performance.now() - start; output.textContent reply.choices[0].message.content; console.log(推理耗时${cost.toFixed(0)} ms); }); initEngine();这段代码的核心逻辑并不复杂CreateMLCEngine负责加载模型、编译 shader、初始化推理环境加载完成后通过engine.chat.completions.create()发消息performance.now()用来粗略统计一次完整推理的耗时。这里有个容易踩坑的点CreateMLCEngine首次调用会下载模型权重到浏览器并在 WebGPU 上编译 shader这个过程可能持续几十秒甚至几分钟页面看起来像卡住了。因此必须在初始化回调里给用户明确的进度反馈这也是上面代码里保留initProgressCallback的原因。5.4 流式输出与中断控制上面的代码是一次性等完整回复。实际产品里用户更希望看到像 ChatGPT 那样一个字一个字蹦出来的效果。WebLLM 支持流式输出只需给create传入stream: true// main.js 中的流式版本 async function sendWithStream() { const userMessage messageInput.value.trim(); if (!engine || !userMessage) return; output.textContent ; const start performance.now(); const chunks await engine.chat.completions.create({ messages: [{ role: user, content: userMessage }], stream: true, }); for await (const chunk of chunks) { const delta chunk.choices[0]?.delta?.content; if (delta) { output.textContent delta; } } console.log(流式推理耗时${(performance.now() - start).toFixed(0)} ms); }5.5 启动并验证在项目根目录执行npx vite --host终端会输出一个本地地址通常是http://localhost:5173。用 Chrome 或 Edge 打开这个地址如果前面 WebGPU 检测已经通过页面会在控制台打印模型加载进度。模型下载完成并初始化后就能在输入框里提问了。6. 运行结果与效果验证跑通之后怎么判断推理是否正常、性能是否达标可以从下面几个维度验证。6.1 预期运行过程第一次打开页面时控制台会输出类似这样的进度日志Downloading model: ... Fetching param cache: 0% ... 50% ... 100% Compiling shaders... Loading model... Model loaded, ready to chat.模型下载完成后受 IndexedDB 缓存的影响第二次打开页面加载速度会明显提升。之后在输入框输入“你好请介绍一下你自己”页面会输出模型生成的一段文本同时控制台打印本次推理耗时。6.2 如何判断推理确实发生在本机打开操作系统的任务管理器Windows或活动监视器macOS观察 GPU 使用率。在模型生成回复的几秒内你通常能看到对应浏览器的 GPU 占用明显升高。如果 GPU 占用始终为零说明推理实际跑在 CPU 上或者浏览器没有启用硬件加速。另一个判断方式是断网测试。模型加载完成之后把电脑网络断开再发一条消息。如果模型仍然能正常生成回复证明推理完全发生在本地。6.3 性能基线怎么测不要凭感觉判断“快”还是“慢”建议固定几个标准问题做基线测试。比如“请用一句话介绍你自己。”“把下面这句话翻译成英文今天天气很好。”“用 Python 写一个斐波那契数列函数。”每次用performance.now()记录从发送到完整输出的耗时同时统计输出 Token 数就能算出每秒生成 Token 数token/s。这个指标才是跨设备、跨模型对比的有效基准。不同设备的差异非常大集成显卡、独立显卡、Apple Silicon 之间的 token/s 可能差好几倍。6.4 失败时先看哪里最常见的情况是页面一直停留在“加载模型”状态。这时按下面顺序排查打开 DevTools Console看 WebLLM 是否输出了报错信息在 Network 面板确认模型权重是否在下载如果一直卡在下载可能是网络问题确认浏览器版本是否支持 WebGPU确认页面是否在 localhost 或 HTTPS 环境下打开查看chrome://gpu里 WebGPU 是否 Enabled。7. 常见问题与排查思路以下是浏览器本地推理实践中最高频的问题整理成一张排查表建议遇到问题时先对照问题现象可能原因排查方式解决方案navigator.gpu为 undefined浏览器版本过旧或硬件不支持打开chrome://gpu查看 WebGPU 状态升级 Chrome/Edge 到 113确认硬件加速开启能获取 Adapter 但requestDevice失败显卡驱动异常或资源被占用查看 Console 报错信息更新驱动重启浏览器关闭占用 GPU 的应用模型一直不下载网络问题或 CORS 配置错误查看 Network 面板请求状态检查模型 URL 可达性配置跨域头加载进度到 100% 后没反应shader 编译时间长或内存不足等待查看任务管理器内存占用换更小的模型关闭其他标签页生成速度很慢设备无独立 GPU或模型偏大检查 GPU 占用率看 token/s换 0.5B/1.5B 模型降低量化精度报错GPU has been lost显卡崩溃或资源耗尽查看浏览器崩溃日志重启浏览器调小模型减少并发任务页面提示缺少SharedArrayBuffer未配置跨域隔离头检查 Network 面板响应头添加 COOP/COEP 响应头切换模型后内存暴涨多个 engine 实例共存查看任务管理器内存刷新页面重新初始化或主动释放旧 engine一个经常被忽略的点是WebLLM 初始化了一个 engine 之后切换模型并不会自动释放旧模型占用的内存。最好的办法是引导用户刷新页面或者把模型切换设计成整页重新初始化避免内存叠加。8. 最佳实践与工程建议跑通 Demo 只是开始真正把浏览器 LLM 推理接入生产环境下面这些经验值得提前了解。8.1 建立降级策略不是所有用户的浏览器都支持 WebGPU。生产环境必须做能力检测和降级设计支持 WebGPU走 GPU 推理不支持 WebGPU 但支持 WASM可以尝试 CPU 推理模型要选更小的两者都不支持提示用户升级浏览器或者引导去使用服务端 API。这里真正容易踩坑的地方是不要因为一次requestAdapter()失败就直接放弃。有些环境是暂时性资源不足重试一次可能就成功了。建议在检测逻辑里加一次重试间隔 2 到 3 秒再决定走哪条降级路径。8.2 缓存策略决定二次加载体验WebLLM 会自动把模型权重写入 IndexedDB二次加载会快很多。但你要在 UI 上明确告诉用户“首次加载需要下载模型之后会缓存”。如果完全不加提示用户看到长时间进度条会直接关掉页面。生产环境中更推荐在模型加载前先检查 IndexedDB 是否已有对应模型的缓存记录有的话可以显示“本地已缓存模型正在加载”而不是“正在下载”减少焦虑感。8.3 推理进度的透明化长文本生成通常需要几秒到几十秒用户最容易在这段时间流失或重复点击。流式输出是第一优先级其次是提供中止按钮让用户可以停止生成最后是明确展示当前状态比如“正在生成第 120 个 Token”。8.4 标签页与显存管理GPU 显存是共享资源。一个标签页跑 7B 模型已经占掉几个 GB用户再打开另一个标签页也做推理很可能导致显存不足甚至浏览器崩溃。生产环境可以建议用户关闭其他推理页面在页面里检测 GPU 可用内存模型初始化前给出资源占用提示。8.5 安全与隐私边界虽然数据不出浏览器但不要声称“绝对安全”。浏览器扩展程序、恶意脚本、操作系统层面的日志仍然可能接触数据。更准确的说法是“数据不会发送到外部服务器降低了数据外传和中央存储风险”。在合规文案里建议用“本地处理”而不是“完全保密”。8.6 依赖版本锁定WebGPU API 还在演进WebLLM 的版本更新也比较快。生产环境里请锁死依赖版本避免一次升级后 shader 编译行为变化导致线上故障。同时记录浏览器版本要求在团队内部文档里写清楚“当前应用在 Chrome 120 上通过验证”。8.7 模型合规与成本平衡浏览器里跑的模型也需要留意开源许可证。从 Hugging Face 或 ModelScope 下载权重时确认模型是否允许商用尤其是企业项目。另一个容易被忽视的问题是虽然推理在本地执行但模型权重仍要从你的 CDN 分发流量成本并不为零。一个 1.5B 模型约 1GB如果用户量很大CDN 费用也需要计算。8.8 开发调试技巧调试时不要只盯着业务代码。用 Performance 面板录制一次完整推理能看到 Tokenize、模型加载、shader 编译、推理执行分别占了多少时间。第一次加载慢不一定说明推理慢很多时候瓶颈在 shader 编译和模型下载而不是 GPU 计算本身。建议把下面的调试信息固化到应用的诊断页面里浏览器版本WebGPU Adapter 信息模型名称和量化格式一次基准问答的耗时和 token/sIndexedDB 缓存占用情况。这些信息对远程排查用户问题非常有用。9. 总结与后续学习方向浏览器端 LLM 推理还处在“能用但不够省心”的阶段。真正适合接入的是数据敏感、低并发、强调端侧体验的应用。它的技术门槛不在于“调用 API”而在于理解 WebGPU 的检测与降级、模型量化与缓存、资源占用与用户体验这几层工程链路。建议你从本文的最小示例出发先用 1.5B 的 q4f16 模型跑通全流程再逐步验证三件事换更大的模型试试性能拐点在哪里给页面加上流式输出和降级提示把模型选择做成配置项而不是写死在代码里。这三件事做完你对浏览器本地推理的理解就算真正建立了。继续深入的方向包括WebLLM 底层的 MLC 编译原理、ONNX Runtime Web 的算子执行流程、WebGPU compute shader 的 WGSL 编写、以及与 WebNN 这类新兴 API 的衔接。等 WebGPU 在移动端浏览器普及之后端侧 AI 的低成本优势才会真正释放出来那时候这些基础能力会变得更加重要。如果你在跑通示例的过程中遇到问题优先回到第 7 章的排查表把浏览器版本、GPU 状态、模型缓存这三项检查一遍绝大多数问题都能定位。