前言
最近前端圈越来越多人尝试在浏览器里跑 AI：有的想做一个“小而快”的本地工具，有的想做离线智能补全，有的想让页面自带一点 AI 感知能力。可真到落地时才发现：本地推理没你想的快，云端推理没你想的稳，两者怎么结合、怎么取舍、怎么不拖垮前端体验。这段时间我也尝试做了一个小工具，本来只是想让它支持一些轻量的大模型能力，比如自动摘要、关键词抽取、简单问答之类的功能。按照常规思路，最简单的就是让前端发到后端，再由后端调大模型。但考虑到项目本身是纯前端部署（静态资源托管在 CDN 上），没有额外的后端服务，我就动了个念头：有没有可能让部分任务在浏览器本地直接推理？
想法听上去很“黑科技”，但当我实际尝试后，发现并没有想象中那么复杂，甚至还挺有意思的。
一、为什么我会想用“本地推理”？
最早的动机其实很实际：一些用户输入不适合发到云端，做工具的人应该都懂，有些场景涉及隐私或业务敏感信息，用户并不希望这些数据被发往第三方。
其次是小任务没必要都走云端——比如做 embedding、提取关键词这种事，一个轻量模型就能搞定，不必为每一次操作去付云端费用。
避免“网络波动导致体验稀碎”，有时候不是模型慢，是用户网络慢。本地推理能极大提升体验一致性。
所以我就尝试做一个混合方案：能本地跑就本地跑，跑不了再走云端。
二、本地推理到底能做到什么？我的实践如下
我先做了一个范围测试，选了几种目前浏览器能跑的技术：
WebAssembly（WASM） + ONNX Runtime Web：适合跑轻量 NLP 模型。
WebGPU + WebLLM / transformers.js：如果用户设备支持 WebGPU，可以跑大一点的 LLM。
量化模型（int4 / int8）：在模型准确率和加载速度之间做平衡。
实际使用下来，我总结了几个可落地的做法：
- 10MB~80MB 的模型最合适
超过 100MB 的模型，加载时间太长，普通用户真的不会等。 - 文本任务比想象中更适合本地
比如以下任务，本地基本都可以跑：embedding、分词、关键词抽取、文本相似度等待 - WebGPU 对体验影响巨大
在支持 WebGPU 的电脑上，本地推理速度快到让人惊讶；不支持的设备上，则必须自动降级。
这让我开始意识到：纯前端其实并不是“跑不起模型”，只是要选合适的任务和模型。
三、什么时候切换到云端？我用“三角判断法”
纯本地推理肯定不够，尤其是回答长文、生成内容、图像任务之类。我最终做了一个简单的决策逻辑：
-
根据任务类型判断（复杂度）
纯提取类：本地；需要推理或生成：云端；多轮对话、长上下文：云端 -
根据设备性能判断
支持 WebGPU → 尽量本地；不支持 → 自动换云端；内存不足 → 自动换云端 -
根据模型加载耗时判断
如果本地模型加载超过 2 秒，我默认走云端，让体验更稳定。这种“前端自动决策”的方式让我避免了写一堆 if-else，在实际体验上更像是一个“无缝切换”的系统。
四、我的混合方案架构（供参考）
启动加载轻量本地模型（可缓存到 IndexedDB）——运行前检查浏览器特性（WebGPU/线程/内存）——由任务分发器决定：本地？云端？——统一接口输出结果
这样做有两个好处：UI 不需要关心结果来源；本地推理失败也不会影响整体功能；换句话说，本地推理变成“锦上添花”，不是“必须条件”。
五、踩过的坑和一些经验
-
模型加载缓存必须做
我一开始没做 IndexedDB 缓存，结果每次打开页面都重新下载几十 MB，用户肯定受不了。 -
WebGPU 的坑比想象中多
不同浏览器的实现程度不同，尤其是移动端，兼容性测试一定要提前做。 -
模型风格差异要统一
轻量模型和云端模型输出风格不同，我加了一层“格式化器”统一输出 Markdown 结构，否则用户会觉得前后不一致。 -
模型切换时要保证 UI 连贯
不要让用户感知“突然变慢”或“突然变快”，可以加点“推理中”提示缓冲。这几个坑我都踩过，尤其是缓存和 WebGPU，建议大家一定从一开始就考虑进去。
一些最后的感受
做完这个混合方案，我最大的感受是：前端能力的边界其实比我们想象得更宽。
本地推理让很多“以前必须上后端”的需求有了新可能性，而云端推理仍然提供了最强的性能和质量。两者结合，反而更灵活。当然，我在云端部分还是得依赖一些模型 API 服务，像我用过的 GPT Proto 这种整合市面上大部分主流模型的平台，除了kling2.5这些图文生成模型还有Claude这些强逻辑文本类的模型等等，在混合方案里算是挺方便的，具体的大家可以自己去体验一下不同的平台。
希望这篇经验分享能给你一点参考。