虽然 Web 上的大多数 AI 功能都依赖于服务器，但客户端 AI 直接在用户的浏览器中运行。这具有低延迟、降低服务器端成本、无需 API 密钥、提高用户隐私和离线访问等优点。您可以使用 JavaScript 库（如 TensorFlow.js、Transformers.js 和 MediaPipe GenAI）来实现跨浏览器的客户端 AI。
客户端 AI 也带来性能挑战：用户必须下载更多文件，并且他们的浏览器必须更加努力地工作。为了使其良好运行，请考虑
- 您的用例。客户端 AI 是您功能的正确选择吗？您的功能是否在关键用户旅程中？如果是，您是否有备用方案？
- 模型下载和使用的良好实践。请继续阅读以了解更多信息。
模型下载之前
注意库和模型大小
要实现客户端 AI，您需要一个模型，通常还需要一个库。在选择库时，请像评估任何其他工具一样评估其大小。
模型大小也很重要。对于 AI 模型来说，多大才算大取决于情况。5MB 可以作为一个有用的经验法则：它也是 网页大小中位数的第 75 百分位数。一个更宽松的数字是 10MB。
以下是关于模型大小的一些重要考虑因素
- 许多特定于任务的 AI 模型可以非常小。像 BudouX 这样的模型，用于在亚洲语言中进行准确的字符断开，压缩后仅为 9.4KB。MediaPipe 的 语言检测模型 为 315KB。
- 即使是视觉模型也可以具有合理的大小。Handpose 模型和所有相关资源总计 13.4MB。虽然这比大多数最小化的前端软件包大得多，但它与网页大小中位数相当，网页大小中位数为 2.2MB（桌面端为 2.6MB）。
- Gen AI 模型可能会超过 Web 资源的建议大小。DistilBERT 被认为是小型 LLM 或简单的 NLP 模型（观点各异），大小为 67MB。即使是小型 LLM，例如 Gemma 2B，也可能达到 1.3GB。这超过网页大小中位数的 100 倍。
您可以使用浏览器的开发者工具评估您计划使用的模型的准确下载大小。
优化模型大小
- 比较模型质量和下载大小。较小的模型可能具有满足您用例的足够精度，同时体积也小得多。微调和 模型缩小技术 可以显著减小模型的大小，同时保持足够的精度。
- 尽可能选择专用模型。针对特定任务量身定制的模型往往更小。例如，如果您希望执行情感或毒性分析等特定任务，请使用专门针对这些任务的模型，而不是通用的 LLM。
虽然所有这些模型都执行相同的任务，但精度各不相同，它们的大小差异很大：从 3MB 到 1.5GB。
检查模型是否可以运行
并非所有设备都可以运行 AI 模型。即使硬件规格足够的设备，如果在模型使用时运行或启动其他昂贵的进程，也可能会遇到困难。
在解决方案可用之前，您可以立即执行以下操作
- 检查 WebGPU 支持。包括 Transformers.js 版本 3 和 MediaPipe 在内的多个客户端 AI 库都使用 WebGPU。目前，如果不支持 WebGPU，其中一些库不会自动回退到 Wasm。如果您知道您的客户端 AI 库需要 WebGPU，您可以通过将您的 AI 相关代码封装在 WebGPU 功能检测检查 中来缓解这种情况。
- 排除性能不足的设备。使用 Navigator.hardwareConcurrency、Navigator.deviceMemory 和 Compute Pressure API 来评估设备性能和压力。这些 API 并非在所有浏览器中都受支持，并且有意 不精确 以防止指纹识别，但它们仍然可以帮助排除看起来性能非常不足的设备。
提示大型下载
对于大型模型，请在下载前警告用户。与移动用户相比，桌面用户更可能接受大型下载。要检测移动设备，请使用 User-Agent Client Hints API 中的 mobile（如果不支持 UA-CH，则使用 User-Agent 字符串）。
限制大型下载
- 仅下载必要的内容。特别是如果模型很大，则仅在合理确定将使用 AI 功能时才下载它。例如，如果您有类型提前建议 AI 功能，则仅在用户开始使用键入功能时才下载。
- 显式缓存模型 在设备上使用 Cache API，以避免每次访问都下载它。不要仅仅依赖隐式的 HTTP 浏览器缓存。
- 分块下载模型。fetch-in-chunks 将大型下载拆分为较小的块。
模型下载和准备
不要阻塞用户
优先考虑流畅的用户体验：即使 AI 模型尚未完全加载，也允许关键功能运行。
指示进度
在下载模型时，指示已完成的进度和剩余时间。
- 如果模型下载由您的客户端 AI 库处理，请使用下载进度状态向用户显示它。如果此功能不可用，请考虑打开问题以请求它（或贡献它！）。
- 如果您在自己的代码中处理模型下载，则可以使用库（例如 fetch-in-chunks）分块获取模型，并向用户显示下载进度。
- 有关更多建议，请参阅 动画进度指示器的最佳实践 和 为长时间等待和中断进行设计。
优雅地处理网络中断
模型下载可能需要不同的时间，具体取决于其大小。考虑如果 用户离线，如何处理网络中断。如果可能，请告知用户连接已断开，并在连接恢复后继续下载。
不稳定的连接是分块下载的另一个原因。
将昂贵的任务卸载到 Web Worker
昂贵的任务（例如下载后的模型准备步骤）可能会阻塞您的主线程，从而导致用户体验卡顿。将这些任务转移到 Web Worker 有助于解决此问题。
查找基于 Web Worker 的演示和完整实现
在推理期间
模型下载并准备就绪后，您可以运行推理。推理可能在计算上很昂贵。
将推理移至 Web Worker
如果推理通过 WebGL、WebGPU 或 WebNN 发生，则它依赖于 GPU。这意味着它发生在单独的进程中，不会阻塞 UI。
但是对于基于 CPU 的实现（例如 Wasm，它可以作为 WebGPU 的备用方案，如果不支持 WebGPU），将推理移至 Web Worker 可以保持您的页面响应迅速，就像在模型准备期间一样。
如果您的所有 AI 相关代码（模型获取、模型准备、推理）都位于同一位置，则您的实现可能会更简单。因此，无论是否使用 GPU，您都可以选择 Web Worker。
处理错误
即使您已检查模型应在设备上运行，用户也可能稍后启动另一个大量消耗资源的进程。为了缓解这种情况
- 处理推理错误。将推理包含在
try/catch块中，并处理相应的运行时错误。 - 处理 WebGPU 错误，包括 意外错误 和 GPUDevice.lost，后者在 GPU 实际因设备性能不足而重置时发生。
指示推理状态
如果推理花费的时间超过了 即时 感，请向用户发出信号，表明模型正在思考。使用动画来缓解等待，并确保用户应用程序按预期工作。
使推理可取消
允许用户即时优化他们的查询，而无需系统浪费资源生成用户永远不会看到的响应。