这两年“AI 前端化”已经从一个概念词变成了实实在在能跑的东西。以前我们做个 AI 功能,基本就是前端接一个云端接口,把用户输入发给服务器,等结果回来再渲染;现在不一样了,只要浏览器环境够新,你完全可以在用户本机的 GPU 上加载一个几十亿参数的本地模型,推理过程不碰服务器、不传敏感数据、断网也能用。这条路现在有一个比较正式的说法,叫 Edge AI,而打通它的关键,就是本地模型加 WebGPU 推理。
这篇文章我就围绕“AI × 前端的下一站”这条主线来聊。我会从整体思路、模型部署、WebGPU 原理、实际代码、工程化落地和踩坑记录几个角度,把整套链路从零讲清楚。内容会比较偏实操,适合正在做 AI 应用的前端工程师、准备把模型能力搬进浏览器的全栈开发者,以及所有对本地推理感兴趣的同学。看完不说能直接写出生产级产品,至少能把技术选型、运行原理和常见报错都摸个门清。
1. 从“调接口”到“调 GPU”:为啥本地模型加 WebGPU 是前端的下一站
1.1 前端 AI 的演进路径
前端做 AI,其实经历了三个阶段。
第一个阶段是“AI 功能外包”,前端只负责把输入收集起来,传到后端接口,后端调大模型 API,返回结果给前端渲染。这种模式至今还是主流,因为实现最快、门槛最低,但问题也非常明显:每次请求都有网络延迟、有 API 成本、有数据出网的安全隐患。
第二个阶段是“端侧小模型打辅助”。比如用 TensorFlow.js 或 ONNX Runtime Web 在浏览器里跑一些轻量模型,做图像分类、姿态检测、OCR 这类任务。此时推理已经下沉到端侧了,但模型普遍很小,根本跑不动大语言模型,也做不了高质量的文本生成。
现在正在进入第三个阶段:本地模型加 WebGPU 推理。WebGPU 提供了浏览器访问 GPU 计算能力的统一接口,配合 quantize 后的 LLM 模型,浏览器里已经能运行 1.5B 到 8B 甚至更大参数的语言模型。这带来的变化是质变的——模型不再是一个远程黑盒,而是变成了浏览器应用里的一个可编程模块。
我自己第一次在浏览器里看到一个 3B 模型流式输出中文回答时,确实挺震撼的。那种感觉跟调 API 完全不同,因为整个推理链路都在本地,你的代码可以从底层控制 GPU 资源、显存分配、上下文窗口,这在前端开发历史上几乎是从未有过的能力。
1.2 本地推理解决的核心痛点
把模型搬到本地,最直接的价值有三个。
第一个是隐私。很多企业场景里,客户数据是不能出内网的。以前你要么接受在公有云 API 上过一遍数据,要么自己维护一套 GPU 服务集群。现在有了本地模型,用户文档、聊天记录、内部知识库都可以在浏览器里处理,数据不落盘、不出网,合规压力小很多。
第二个是成本。大模型 API 按 token 计费,对话一多、文档一长,钱就像流水一样走。本地推理是一次性把模型下载到设备,之后每次推理只消耗电费和硬件资源。对高频、高并发的内部工具来说,这能省下非常可观的费用。
第三个是延迟和可用性。端侧推理省掉了网络 RTT,首 token 响应可以做到几百毫秒甚至更快。而且断网也能用,适合弱网、离线环境,比如施工现场、野外作业、飞机舱内这些场景。
我记得有个做车间巡检系统的朋友提过,他们想在工控平板上做一个语音问答助手,但车间网络很差,云端 API 经常超时。后来换成本地部署一个量化后的模型,GPU 推理配合 WebGPU,哪怕完全没有外网也能正常工作。这种体验是云 API 永远给不了的。
1.3 选型边界:不是所有场景都要端侧跑
不过我得先说一句公道话:本地模型不是万能药,更不是要取代云端 API。它有自己的边界。
如果你要做的是高难度数学推理、复杂代码生成、超长文本理解,当前设备端能跑的模型规模和云端旗舰模型还是有差距的。这时候硬塞进浏览器,效果大概率会让你失望。
我的建议是走混合架构。轻量任务优先本地跑,比如文本摘要、实体抽取、意图识别、客服分类;重度任务再走云端 API,比如复杂推理、大规模检索增强生成。前端代码里做一次统一的模型抽象层,根据场景、设备能力、网络状态自动选择推理后端。这个思路既能吃到本地推理的红利,又不会牺牲最终效果。
还有一个现实问题:WebGPU 的兼容性。Chrome 系浏览器已经默认支持,Safari 18 也跟进了 WebGPU,但老设备、老浏览器、部分移动端 WebView 依然跑不了。所以工程上一定要做降级方案,比如 WebGPU 不可用时切换到 WebAssembly 推理,再不行退回云端 API。这些后面会展开讲。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地模型选型与部署:从 Ollama 到浏览器直接加载
2.1 模型参数量、量化格式与内存预算
本地模型能不能跑起来,第一道坎不是代码,而是显存和内存。
