浏览器端AI模型实测：五个可用场景

浏览器里跑AI模型这件事，过去常被当成技术演示。模型小、速度慢、效果勉强，离生产环境很远。但最近一两年，随着WebGPU逐步可用以及Transformers.js等运行时库的成熟，情况有了明显变化。一个典型的浏览器端模型现在能做到不需要调用任何推理API、不需要网络往返、不产生按token计费的成本，推理全程在用户设备上完成。下载模型确实需要时间，但一旦缓存下来，后续可以离线运行，数据也不必离开设备。

当然，代价是模型规模有限。你不可能在普通标签页里运行前沿大模型。可用的通常是几千万到几亿参数的小模型，它们在某些专门任务上表现相当不错，在另一些任务上则勉强及格。下面这五个功能来自一个实际搭建的React加TypeScript项目，模型按需加载，推理放在Web Worker里避免阻塞界面，优先使用WebGPU，不支持时回退到基于WebAssembly的CPU执行。

背景移除是效果最直观的一个。使用RMBG-1.4，大约4400万参数，下载体积约170MB。上传一张照片，模型能把主体和背景分开，导出带透明通道的PNG。对电商或拍卖类应用来说，这个功能的想象空间很直接：卖家只有一张随手拍的照片，平台可以在应用内提供一键去背景，不必让用户去用外部修图工具，照片也不用上传到任何服务器。需要留意的是，这个模型有特定的许可证条件，商用之前必须核实。

替代文本生成用的是Florence-2-base-ft，一个约2.3亿参数的视觉模型，下载体积在350到450MB之间，取决于设备支持的精度。上传图片后，模型会生成一段描述，可以作为alt文本的初稿。这对无障碍访问有帮助，但生成结果必须经过人工审核。好的替代文本不只是说出图片里有什么，还要考虑图片在页面中的用途和上下文。模型不知道你为什么放这张图，偶尔会漏掉细节或编造内容。项目里还提供了一个附加说明的输入框，但实际实现只是把额外文字拼接到生成结果后面，并没有真正影响模型看到或理解的内容，所以不要对这部分期待过高。

智能工单创建是最让人意外的一个。原本以为让语言模型把一段口语化的报修描述转成结构化表单会很简单，实际花的时间远超预期。使用的模型是Qwen2.5-0.5B-Instruct，约5亿参数，量化权重下载约786MB，另加分词器文件。难点不在于理解抱怨内容，而在于稳定输出结构正确的字段，不编造信息，不返回格式错误的JSON。最终靠精心设计的提示词、输出解析和Zod模式校验才跑通。生成的工单可以编辑，用户确认后再复制或提交。这种思路适合生产环境：让AI做枯燥的初稿，人保留控制权。

语义搜索是小模型真正发光的地方。演示中对一批支持工单做语义检索，同时保留传统关键词搜索方便对比。使用all-MiniLM-L6-v2，约2200万参数的嵌入模型，量化CPU版本权重只有约23MB，WebGPU版本约90MB。模型把工单和查询都转成向量，用余弦相似度比较，不需要生成式大模型。速度快，结果确实有用。对于文档量不大的场景，这种做法很值得试。数据量大了之后就要考虑索引、存储和性能问题。演示里嵌入向量放在内存中，对示例来说足够，但基本思路本身是成立的。

暂停并提问这个功能实用性稍弱，但展示了一种可能性。使用LFM2.5-VL-450M，约4.5亿参数的视觉语言模型，下载约350到400MB。开启摄像头后模型会周期性描述画面，也可以暂停某一帧，针对画面提问。它还不适合当作可靠的无障碍工具，识别结果有时会出错，但作为本地视觉问答的实验，它说明浏览器端多模态推理已经能跑起来。

说完能做的，也要说限制。这些模型的表现很大程度上依赖WebGPU。这个API让浏览器直接调用GPU算力，对机器学习推理的提升可能是数量级的。但WebGPU的可用性和性能在不同设备上差异很大。现代浏览器支持已经好很多，但并不是所有用户都能用上，回退到CPU后速度会明显下降。

模型下载体积是另一个现实问题。从几十MB到接近800MB不等，首次加载的等待时间不能忽略。按需加载可以缓解，但用户点开功能后还是要等模型下载完。

许可证问题容易被忽视。不是所有模型都允许商用，有些有额外条款。在把模型放进产品之前，必须逐个确认。

输出稳定性也需要设计兜底。语言模型可能返回格式错误的JSON或编造字段，模式校验和输出解析不是可选项，而是必需项。

综合来看，浏览器端AI模型目前适合作为现有功能的增强，而不是关键任务系统的唯一依赖。在电商、无障碍和客户支持这些领域，把它们当作可选的辅助层是合理的。隐私敏感的场景尤其值得考虑，因为推理在本地完成，数据不外发。选型时不要默认用通用语言模型，像语义搜索这种任务，一个小而专的嵌入模型比大模型更合适。