AI 模型直接在浏览器中运行，终于好到可以用于生产环境了吗？让我们一探究竟！😉
我在布拉格 FrontKon 的演讲已经过去一周了。正如我之前提到的，那场演讲非常棒！我在下面附上几张照片，只为证明我确实会在会议上演讲，而不只是凭空编造这些事。😀
 |
 |
 |
 |
 |
 |
我的演讲标题是“你的浏览器是一个计算平台（而你却只拿它来填表单）”，我展示了如何利用 WebAssembly 和 WebGPU 在浏览器中直接执行高级计算。我有点担心地发现，全场观众中，大概只有三四个人听说过 WebGPU！这很可惜，因为与基于 CPU 的实现相比，WebGPU 可以将某些类型的并行计算加速数十倍。
不过没关系，至少 FrontKon 的人现在知道 WebGPU 是什么了。😁 如果你想在你的会议上安排一场关于这个的演讲，欢迎联系我！尤其是如果你的会议恰好在一个特别有吸引力的旅游目的地举办。😀
我为什么重新审视浏览器 AI
会议之后，我通常会写一篇与演讲相关的博客文章。不过，由于我已经写过很多次 WebAssembly 和 WebGPU，今天我想从另一个角度来探讨这个话题。也就是说，让我们来看看直接在浏览器中运行的 AI 模型的现状，当然，它们大量使用了这些技术。🙂
基于浏览器的 AI 模型是一个迷人的概念。没有推理 API 调用。没有到 AI 后端的网络往返。不用担心用户消耗太多 token，因为不是你付钱！但当然，本地推理仍然需要时间，而且一开始下载模型也可能要花上一阵子。
另一个优势是，一旦这些模型被下载并由浏览器缓存，它们就可以离线工作，前提是应用本身支持离线运行。
这也带来了显著的隐私优势：推理直接在用户设备上进行，因此他们的数据无需发送到外部 AI 服务。
不过，你可能也能想象到，这些模型相对较小。我们不会在普通的浏览器标签页里运行一个大规模的前沿模型。
所以问题是：这些较小的模型到底有多大用处？
你们中有些人可能还记得，大约一年前我尝试过基于浏览器的 AI 模型。那时候，我们大多只是觉得它们是个有趣的新奇玩意儿，仅此而已。
但我一直在 LinkedIn 上关注 Hugging Face 中从事 Transformers.js 工作的人，时不时地，他们的演示会出现在我的信息流里。乍一看，其中一些确实令人印象深刻。你知道的，简直就像在浏览器里运行的宇宙飞船。😉
所以在 FrontKon 之前，我决定再看看他们提供了什么。结果发现，在把 Transformers.js 升级到我用于这些实验的 4.3.1 版本，并尝试了一些更新的模型之后，结果确实令人印象深刻！
当然，Transformers.js 并不是在浏览器中运行 AI 模型的唯一选择。还有其他库和运行时，但我真的很喜欢 Transformers.js，而且我认为它是这项技术如今所能取得成就的一个相当有代表性的例子。
与此同时，我并不为 Hugging Face 工作，也没有人付钱让我向你推销浏览器里的宇宙飞船。所以我会告诉你基于浏览器的 AI 模型今天实际能做什么，哪些做得好，哪些还不行。
而且更棒的是，你可以探索代码并亲自尝试一切！
GitHub： https://github.com/sylwia-lask/practical-browser-ai
在线演示： https://sylwia-lask.github.io/practical-browser-ai
如果你喜欢这个项目，请在 GitHub 上给它点个 star。我正在收集它们！😀
我们真的能在生产环境中使用它吗？
对于这些演示，我想专注于实际应用。更具体地说，我想弄清楚我们今天、此时此刻，如何在真实的生产应用中使用基于浏览器的 AI。
那么这项技术值得关注吗？在我看来，绝对值得！
但是！
我大概不会构建一个完全依赖这些模型完美运行的关键任务系统。😉 相反，我会把它们视为对现有应用功能的有趣、可选的增强，尤其是在电商、无障碍和客户支持等领域。
顺便说一句，这个应用本身并没有什么特别新奇的地方。它是一个普通的用 TypeScript 编写的 React 应用，使用Web Workers来运行模型推理，而不会阻塞主 UI 线程。
模型是按需加载的，所以你不需要为了打开应用而下载全部五个模型。推理通过 Transformers.js 在本地运行，在支持的地方使用 WebGPU，在可回退的地方使用基于 WebAssembly 的 CPU 执行。
不涉及任何 AI 后端！
让我们看看我构建出了什么。最后，我会分享我对这些模型局限性的看法。
还有一点：这些还不是基于浏览器的 AI 智能体。它们只是使用本地 AI 模型执行特定任务的应用。但再给我几周时间，你也会在我的博客上看到在浏览器中运行的智能体！
1. 背景移除器
我特别欣赏基于浏览器的 AI 的一点是，它不局限于文本生成。我喜欢使用多模态 AI！
在这个演示中，一个名为RMBG-1.4的小模型，大约有 4400 万个参数，在将物体与背景分离方面做得非常出色。🙂 在我使用的配置下，模型本身下载大小只有约 170 MB。
如你所见，我们可以将结果保存为透明 PNG，而且效果出奇地好！
我可以很容易地想象这成为拍卖网站或电商平台上的一个附加功能。
想象一下，有人想出售一件商品，但只有像我示例中那样的照片。我们不必要求他们使用外部图像编辑服务，而是可以直接在应用中提供一个背景移除按钮。
而且照片甚至不需要离开他们的设备。挺酷的，对吧？
一个实用提示：RMBG-1.4 带有许可条件，在商业部署前应予以检查。因此，虽然这一技术概念对电商非常有前景，但在发布前你始终应核实模型的许可证。
2. Alt Text 生成器
我一直觉得，如果我们使用得当，AI 可以成为另一个有用的无障碍层。
这个演示使用了Florence-2-base-ft，一个拥有约 2.3 亿参数的视觉模型，来生成图像描述。
想象一下，比如你正在向 DEV 上传一张图片。你不必从零开始编写 alt text 描述，而是可以使用这样的模型自动生成一个建议。尤其是当你真的不想描述图片内容的时候！
当然，生成的描述仍应由人工审核和编辑。好的 alt text 不仅仅是识别图像中的物体。它还取决于该图像的上下文和用途。
模型不一定理解你为什么使用这张图片，它偶尔会遗漏或编造细节。不过，作为无障碍助手，我认为这是一个非常有前景的方法。
还有一个选项可以提供额外的上下文，但不要对它期望太高。在我的实现中，额外的文本只是被附加到生成的描述后面，而不是真正影响模型所看到或理解的内容。我稍后会在文章中解释为什么我对这种方法不满意。
供参考，模型下载大约为350–450 MB，具体取决于设备支持的精度。
3. 智能工单创建器
哦，这个是我梦寐以求的功能！我用完全自然、杂乱的语言描述出了什么问题，模型就把它转成一张结构化的工单，我可以发送给支持团队。😀
我最终使用的模型是Qwen2.5-0.5B-Instruct，一个小型语言模型，拥有约 5 亿参数。在我的配置中，其量化权重需要下载大约786 MB，再加上 tokenizer 文件。
我必须承认一件事。当我开始实现这个功能时，我以为它会是最简单的一个！说真的。让一个语言模型把投诉变成结构化的工单能有多难？
嗯……显然，相当难！我花了比预期多得多的时间去尝试不同的模型，并让它们产出我真正需要的输出。
主要的挑战不只是理解投诉内容。而是要产出一致、结构化的响应，字段正确，不编造信息，也不返回格式错误的 JSON。最终，我通过精心设计的提示词、输出解析以及使用 Zod 进行 schema 校验，让它跑通了。
生成的工单是可编辑的，所以用户可以在复制或提交之前检查所有内容。我认为这正是适合生产环境的那种做法：让 AI 做无聊的初步工作，但把控制权留给人类。
4. 语义搜索
现在，这正是小模型真正大放异彩的地方！在这个演示中，我在一组支持工单上实现了语义搜索。
它不是去寻找匹配的关键词，而是搜索含义相似的工单。当然，我也加入了传统的关键词搜索，这样你可以自己对比结果。
我使用的是all-MiniLM-L6-v2，一个大约有 2200 万参数的小型嵌入模型。根据后端不同，它的模型权重只有大约量化 CPU 版本为 23 MB或者WebGPU 版本为 90 MB。
而且它效果非常好！模型很快，结果也确实有用。
在底层，它会把工单和搜索查询转换成数值向量，然后用余弦相似度进行比较。这里不需要生成式 LLM。
事实上，这是这些实验中最有意思的教训之一：有时候，一个小型专用模型比通用语言模型是更好的选择。对于注重隐私、你不想把可能敏感的信息发送到外部服务器的应用来说，这尤其是个好消息。
对于一小部分文档来说，这种方法绝对值得一试。当然，对于更大的数据集，你需要考虑索引、存储和性能。在我的演示中，嵌入向量保存在内存中，对于这个示例来说完全够用。但基本思路的效果出奇地好。
5. 暂停并提问
好吧，这个可能稍微不那么实用，但绝对够炫！😀 而且我觉得它也有有趣的无障碍应用潜力。在这个演示中，我使用的是LFM2.5-VL-450M，一个拥有约 4.5 亿参数的视觉语言模型。下载大小大约是350–400 MB，具体取决于配置。
这里其实有两个功能。第一个是实时视觉描述。我打开摄像头，模型会定期描述它看到的内容。没错，那就是我：
但接下来更精彩！我可以把摄像头暂停在某一帧上，然后向模型提问它看到了什么。
这个例子说明模型并不那么完美。😅 不过，好吧，我确实受宠若惊！
我还不会把它当作可靠的无障碍工具，但作为本地视觉问答的一次实验，它确实很吸引人。
这就是全部五个演示了！
那么有什么问题呢？
现在，正如之前承诺的，我们来谈谈缺点。因为，当然，缺点还不少！
WebGPU 支持与硬件限制
首先，这些模型能有这样的表现，很大程度上要归功于 WebGPU。这个 API 允许应用直接在浏览器中使用 GPU 计算能力，这对机器学习推理来说可能带来巨大的差异。
问题在于WebGPU 的可用性和性能并非每台设备都一样。现代浏览器的支持已经有了显著改善，但可用性仍然取决于浏览器版本、操作系统、GPU、驱动等。而且即使支持 WebGPU，也不意味着每个人都有同样强大的电脑。
移动设备是一个特别有意思的问题。一些移动浏览器和设备在某些工作负载下仍然缺乏可用的 WebGPU 支持。在这种情况下，一些 Transformers.js 模型可以回退到基于 WebAssembly 的 CPU 推理，根据环境和配置，可能还会用到 SIMD 或多线程。
遗憾的是，这可能会慢得多。在我的手机上，我演示中的两个示例完全无法运行，因为它们超时了。而且我用的可不是什么博物馆里的古董手机！这是一台 Samsung Galaxy S24 FE。它不再是 newest flagship，但也绝对不是老掉牙的设备。
所以没错，WebGPU 支持正在改善，模型也在变得更好。但我想谈谈我们实际上能用的东西现在，而不是几年后可能实现的东西。
模型下载可不算小
还有另一个重要的限制：模型本身必须被下载。虽然有些相对较小，但另一些可能需要数百 MB。如你所见，我演示中的模型从量化语义搜索模型的大约 23 MB 到 Smart Ticket Creator 的近 800 MB 不等。如果你通过移动网络访问一个网站，这可就相当多了！
幸运的是，浏览器可以缓存下载的模型文件，因此后续访问通常不需要再次下载全部内容。但首次加载仍然很重要，而且浏览器存储并不能保证永远保留这些文件。
这也是为什么我会把这些功能视为可选的增强项，而不是每个用户在使用应用程序之前都必须加载的东西。
有些事情仍然不够好用
我也无法实现我最初想要的所有东西，尽管有些想法看起来完全合理。例如，我尝试添加从图像中进行文本识别。尽管尝试了不同的模型和配置，我还是无法获得足够可靠的结果来用于我的演示。我测试的方法没有给出我想要的质量，所以我决定不包含那个功能。
另一件我想改进的事情是 alt 文本生成器中的上下文信息。想象一下，上传一张狗的照片并添加一些额外的上下文，比如：“这只狗正在当地动物收容所等待领养。”理想情况下，模型会把这些信息考虑进去，生成一段优美、能感知上下文的描述。
我尝试为此使用一个额外的本地语言模型，希望它能把视觉描述和额外信息结合起来。但无论我怎么尝试，结果都非常不理想。所以我最终采用了前面提到的更简单的方案，即把上下文单独添加进去，而不是真正由图像描述模型来解读。
这也是另一个很好的例子，说明为什么我不会在生产环境中盲目信任这些模型。
那语音识别呢？
另一方面，我听说基于浏览器的小型模型在语音识别方面可以出奇地好。Transformers.js 也支持音频相关的任务，所以这绝对是另一个值得探索的有趣领域。
不过这次我没有测试它。主要是因为我都是在晚上构建这些演示，如果我花几个小时对着电脑说话，我的家人会杀了我的。😂 也许下次吧！
我的结论：浏览器 AI 是否已为生产环境做好准备？
所以，总结一下：基于浏览器的 AI 模型正在变得更好，我认为现在已经值得探索如何在生产应用中使用它们了。
不一定是要替代每一个 AI 后端。也绝对不应在没有回退方案的情况下作为关键依赖。但作为提升用户体验的可选功能呢？绝对可以。
你怎么看？你是否已经尝试过直接在浏览器中运行 AI 模型？
如果你喜欢读我的文章，欢迎在以下平台关注我LinkedIn！🙂