浏览器中直接运行的 AI 模型终于好到可以在生产环境使用了吗？让我们来看看！😉
自我在布拉格的 FrontKon 演讲以来已经过去一周了。如前所述，演讲非常精彩！我下面会加几张照片，只是为了证明我确实在会议上演讲，而不是随便编造这些内容。😀
 |
 |
 |
 |
 |
 |
我的演讲题目是 "浏览器就是一个计算平台（而你正在用它来处理表单）"，我展示了如何使用 WebAssembly 和 WebGPU 在浏览器中直接执行高级计算。我有点担心地发现，在场的观众中也许只有三四人甚至听说过 WebGPU！这真是件遗憾，因为 WebGPU 相比基于 CPU 的实现，能够将某些并行计算的速度提升数十倍。
不过没关系，至少 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 上给它点个星标。我在收集它们！😀
我们真的能在生产环境中使用这项技术吗？
对于这些演示，我想专注于实际应用。更具体地说，我想弄清楚我们今天、现在就能在真实的生产应用中如何使用基于浏览器的 AI。
那么这项技术值得关注吗？在我看来，绝对值得！
不过！
我可能不会构建一个完全依赖这些模型完美运作的任务关键型系统。😉 相反，我会把它们视为现有应用功能的有趣、可选的增强，尤其是在电子商务、无障碍和客户支持等领域。
顺便说一下，这个应用本身并没有什么特别奇特之处。它是一个 使用 TypeScript 编写的 React 应用，通过 Web Workers 来运行模型推理，而不会阻塞主 UI 线程。
模型按需加载，打开应用时无需一次性下载全部五个模型。推理在本地通过 Transformers.js 运行，在支持的情况下使用 WebGPU，在有回退方案时使用基于 WebAssembly 的 CPU 执行。
未涉及任何 AI 后端！
让我们看看我到底构建了什么。最后，我会分享这些模型局限性的看法。
再说一点：目前这些还不是基于浏览器的 AI Agent。它们只是使用本地 AI 模型完成特定任务的应用。再给我几周时间，你就会在我的博客里看到能在浏览器中运行的 Agent 了！
1. 背景移除
我尤其欣赏基于浏览器的 AI 这一点——它不只局限于文本生成。我喜欢处理多模态 AI！
在此演示中，一个名为 RMBG-1.4 的小型模型（约 4400 万参数）在将对象与背景分离方面表现出色 🙂。该模型在我使用的配置下仅约 170 MB 需要下载。
正如你所见，我们可以将结果保存为透明 PNG，效果出乎意料地好！
我可以轻松想象将此作为拍卖网站或电商平台的额外功能。
想象有人想售卖产品，但只有类似我示例的照片。与其让他们使用外部图像编辑服务，不如直接在应用中提供一个背景移除按钮。
而且照片甚至不需要离开他们的设备。很酷，对吧？
实际提醒：RMBG-1.4 附带许可条件，商业部署前应予以检查。虽然该技术概念对电商非常有前景，但你应始终在交付前验证模型许可证。
2. ALT 文本生成器
我一直认为，如果使用得当，AI 可以成为无障碍访问的另一层有用补充。
此演示使用 Florence-2-base-ft ——一个约 2.3 亿参数的视觉模型——来生成图像描述。
比如，当你在 DEV 上传一张图片时，不必从零开始写 alt 文本描述，可以直接使用类似的模型自动生成建议。特别是当你真的不想描述图片内容的时候！
当然，生成的描述仍需要人工审阅和编辑。好的 alt 文本不仅仅是识别图片中的对象，还取决于该图片的上下文和用途。
该模型不一定明白你为什么使用这张图片，有时会遗漏或杜撰细节。不过，作为无障碍助手，我认为这是一种非常有前景的方法。
此外，还可以提供额外的上下文，但不要抱有太大期望。在我实现的版本中，额外文本只是简单地追加到生成的描述后，而并未真正影响模型所看到或理解的内容。我会在后文解释为何对这种方式不满意。
供参考，该模型的下载大小大约为350–450 MB，具体取决于设备支持的精度。
3. 智能工单创建者
哦，这是我梦寐以求的功能！我用完全自然、杂乱的语言描述问题所在，模型会把它转换成我可以发送给支持团队的结构化工单。😀
我最终使用的模型是 Qwen2.5-0.5B-Instruct，这是一个参数约为 5 亿的小型语言模型。在我的配置下，其量化权重需要下载约 786 MB，外加分词器文件。
我不得不承认一点。当我开始实现这个功能时，我曾以为这是最简单的一个！认真的说，语言模型把投诉转化为结构化工单有多难呢？
嗯……结果相当困难！我花费的时间远超预期，尝试了各种模型，才让它们产出我真正需要的输出。
主要挑战不仅仅是理解投诉。要生成一致且结构化的响应，包含正确的字段。既不能编造信息，也不能返回格式错误的 JSON。最终，我通过精心设计的提示词、输出解析以及使用 Zod 进行 schema 验证，使其正常工作。
生成的工单是可编辑的，用户在复制或提交之前可以先检查全部内容。我认为这正是生产环境中合适的做法：让 AI 处理枯燥的初始工作，但让人类保持控制权。
4. 语义搜索
正是小模型大显身手的时候！在此次演示中，我在一组支持工单上实现了语义搜索。
应用不是寻找匹配的关键词，而是搜索含义相似的工单。当然，我也加入了传统的关键词搜索，以便你自行比较结果。
我使用 all-MiniLM-L6-v2，这是一个参数约 2200 万的小型嵌入模型。根据后端不同，其模型权重大约为 23 MB（量化 CPU 版） 或 90 MB（WebGPU 版）。
而且效果非常好！模型速度快，结果确实有用。
在内部，它会将工单和搜索查询转换为数值向量，然后使用余弦相似度进行比较。这里不需要生成式大模型。
事实上，这是这些实验中最有趣的教训之一：有时一个小型专用模型比通用语言模型更合适。这对隐私要求高且不愿将潜在敏感信息发送到外部服务器的应用来说，是个好消息。
对于小规模文档集合，这种方法绝对值得尝试。当然，面对更大的数据集时，你需要考虑索引、存储和性能。在我的演示中，嵌入向量保存在内存中，这已经足以支持该示例。但基本思想竟然效果出乎意料地好。
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。虽然不再是最新旗舰，但绝对不是恐龙。
所以是的，WebGPU 支持正在改善，模型也在变得更好。但我想谈谈我们实际上能够现在就使用的东西，而不是几年后可能实现的东西。
模型下载并不算小
还有另一个重要限制：模型本身必须下载。虽然有些模型相对较小，但有些可能需要几百兆字节。正如你所看到的，我在演示中使用的模型从量化语义搜索模型大约 23 MB 到智能票据创建器近 800 MB 不等。如果你在移动网络上访问网站，这确实是个不小的开销。
幸运的是，浏览器可以缓存下载的模型文件，因此后续访问通常不需要重新下载全部内容。但首次加载仍然很重要，且浏览器存储无法保证永久保留这些文件。
这就是我把这些功能视为可选增强而非每位用户必须在使用应用前加载的另一个原因。
有些功能仍然表现不够好
我也没法实现最初想要的所有功能，尽管有些想法看起来完全合理。例如，我尝试添加基于图像的文本识别。尽管我试验了不同的模型和配置，但得到的结果仍不够可靠，无法用于演示。我测试的方法未能达到我想要的质量，于是我决定不加入该功能。
我想改进的另一点是 alt 文本生成器中的上下文信息。想象上传一张狗的照片，并添加一些额外信息，例如：“这只狗可以在当地动物收容所领养。”理想情况下，模型应考虑这些信息并生成一段美观且感知上下文的描述。
我尝试使用额外的本地语言模型来实现这一点，希望它能将视觉描述与额外信息结合起来。但无论我怎么尝试，结果都非常不尽人意。于是我采用了之前提到的更简单的做法：将上下文单独添加，而不是让图像描述模型真正理解它。
这也是我不愿在生产环境中盲目信任这些模型的又一个很好的例子。
语音识别怎么样？
另一方面，我听说小型基于浏览器的模型在语音识别方面竟然表现不错。Transformers.js 也支持音频相关任务，因此这绝对是另一个值得探索的有趣领域。
不过这次我没有测试。主要是因为我晚上在做这些演示，如果我花几个小时对着电脑说话，我的家人肯定会把我宰了 😂 下次再说吧！
我的评价：浏览器 AI 已经可以用于生产环境吗？
总而言之：浏览器端的 AI 模型在不断改进，我认为已经值得探索如何在生产应用中使用它们。
不一定要作为每个 AI 后端的替代品。而且绝对不能在没有后备方案的情况下作为关键依赖。但作为可选功能来提升用户体验？当然可以。
你怎么看？你已经在浏览器中直接运行 AI 模型进行实验了吗？
如果你喜欢阅读我的文章，欢迎在 LinkedIn 上关注我！ 🙂
