在基于云的和本地 AI 模型之间进行选择

对于寻求集成 AI 功能的应用开发人员，Microsoft Windows 提供了一个全面的灵活平台，支持本地、设备处理和可缩放的基于云的解决方案。

在基于云的和本地 AI 模型之间进行选择取决于特定的需求和优先级。 许多生产应用使用混合策略：先尝试本地 Windows AI API 或本地模型，然后在未安装模型时回退到云终结点，不支持设备，用户不同意模型下载，或者任务需要更大的模型。

要考虑的因素包括：

  • 数据隐私、合规性和安全性
  • 资源可用性
  • 无障碍和协作
  • 成本
  • 维护和更新
  • 性能和延迟
  • 可伸缩性
  • 连接要求
  • 模型大小和复杂性
  • 工具和关联的生态系统
  • 自定义和控制

应用开发人员的关键决策因素

  • 数据隐私、合规性和安全性

    • 本地本地： 由于数据保留在设备上，因此在本地运行模型可以提供有关安全和隐私的好处，而数据安全由用户负责。 开发人员负责管理更新、确保兼容性和监视安全漏洞。

    • 云： 云提供商提供可靠的安全措施，但需要将数据传输到云，在某些情况下，这可能会引发业务或应用服务维护者的数据隐私问题。 将数据发送到云还必须符合数据保护法规，例如 GDPR 或 HIPAA，具体取决于数据的性质以及应用运行的区域。 云提供商通常处理安全更新和维护，但用户必须确保他们使用的是安全 API，并遵循数据处理的最佳做法。

  • 资源可用性

    • 本地：运行模型取决于正在使用设备的可用资源，包括 CPU、GPU、NPU、内存和存储容量。 如果设备没有较高的计算能力或足够的存储，则可以限制这种情况。 小型语言模型（SLM），例如 Phi，更适合在设备上本地使用。 Copilot+ PCs 提供内置模型，具有受 Microsoft Foundry on Windows 支持的即用型 AI 功能。

    • 云： 云平台（如 Azure AI Services）提供可缩放的资源。 可以根据需要使用尽可能多的计算能力或存储，并且只需为使用的内容付费。 大型语言模型（LLM），如 OpenAI 语言模型，需要更多的资源，但也更强大。

  • 辅助功能和协作

    • 本地和本地部署： 模型和数据只能在设备上访问，除非手动共享。 这有可能使对模型数据进行协作更具挑战性。

    • 云： 可以通过 Internet 连接从任何位置访问模型和数据。 这可能更适用于协作方案。

  • 成本

    • 本地，内部部署： 除了初始投资设备硬件之外，没有额外的成本。

    • 云： 虽然云平台在即用即付模式下运行，但成本可以根据使用的资源和使用情况持续时间累积。

  • 维护和更新

    • 本地，内部部署：用户负责维护系统并安装更新。

    • 云： 维护、系统更新和新功能更新由云服务提供商处理，从而减少用户的维护开销。

  • 性能和延迟

    • 本地本地： 在本地运行模型可以减少延迟，因为无需通过网络发送数据。 但是，性能受设备的硬件功能限制。

    • 云： 基于云的模型可以利用强大的硬件，但由于网络通信，它们可能会带来延迟。 性能可能因用户的 Internet 连接和云服务的响应时间而异。

  • 可伸缩性

    • 本地和内部部署： 在本地设备上扩展模型可能需要进行大量的硬件升级或添加更多设备，这可能会成本高昂且耗费时间。

    • 云： 云平台提供简单的可伸缩性，使你可以按需快速调整资源，而无需进行物理硬件更改。

  • 连接要求

    • 本地，本地部署： 本地设备不需要互联网连接即可运行模型，这在网络连接受限的环境中可能非常有用。

    • 云： 基于云的模型需要稳定的 Internet 连接才能进行访问，并可能受到网络问题的影响。

  • 运行时可用性和回退机制

    • 本地部署： 本地 AI 功能可能取决于硬件、Windows版本、Windows应用 SDK 版本、区域以及是否安装了可选模型。 在调用本地 AI 功能之前，请检查其就绪状态，并引导用户完成任何所需的模型下载或许可流。 对于 Windows AI API，请使用开始使用 Windows AI API 和各个 API 页中记录的特定于 API 的就绪模式。

    • 云： 当本地模型尚未就绪，或当前设备不支持时，云端端点可作为后备方案。 确定回退机制是自动进行、由用户控制，还是在隐私敏感场景下被禁用。 确保 UI 解释数据何时离开设备。

  • 模型大小和复杂性

    • 本地，内部部署： 本地设备可能由于硬件限制，对可运行模型的大小和复杂性有所限制。 较小的模型（例如 Phi）更适合本地执行。

    • 云： 由于 OpenAI 的可缩放基础结构，云平台可以处理更大、更复杂的模型，例如 OpenAI 提供的模型。

  • 工具和关联的生态系统

    • 本地，本地部署：本地 AI 解决方案，例如Microsoft FoundryMicrosoft Foundry on Windows、Windows ML 和Foundry Local，可与Windows 应用 SDK 和 ONNX 运行时集成，使开发人员能够将模型直接嵌入到桌面或边缘应用中，并且具有最少的外部依赖。

    • 云：云 AI 解决方案（如 Microsoft FoundryAzure AI 服务和 Azure OpenAI 服务）提供了一套全面的 API 和 SDK，用于构建 AI 应用程序。 这些服务旨在与 DevOps、GitHubAzure、语义内核 和其他Copilot服务无缝对接，实现大规模的端到端协调、模型部署和监控。

  • 自定义和控制

    • 本地，内置： 本地模型可以开箱即用，无需具备高水平的专业知识。 Microsoft Foundry on Windows 提供一些像 Phi Silica 这样的现成模型。 或者， Windows ML 允许开发人员直接在设备上运行自定义模型，例如使用 ONNX 运行时训练的 Windows 模型。 这提供了对模型及其行为的高级别控制，允许根据特定用例微调和优化。 Foundry Local 还允许开发人员在本地设备上 Windows 运行模型，从而提供对模型及其行为的高度控制。

    • 云： 基于云的模型还提供现成和可自定义的选项，使开发人员能够利用预先训练的功能，同时仍根据特定需求定制模型。 Microsoft Foundry 是一个统一的 Azure 平台即服务，适用于企业 AI 运维、模型构建者和应用程序开发。 此基础将生产级基础结构与友好的接口相结合，使开发人员能够专注于构建应用程序，而不是管理基础结构。

云 AI 示例

如果基于云的解决方案适用于应用 Windows 方案，你可能对下面的一些教程感兴趣。

许多 API 可用于访问基于云的模型，以在应用中 Windows 为 AI 功能提供支持，无论这些模型是自定义的还是可供使用的。 使用基于云的模型，应用可以通过将资源密集型任务委派给云来保持简化。 一些有助于添加由 Microsoft 或 OpenAI 提供的基于云的 AI 支持的 API 的资源包括：

  • 将 OpenAI 聊天完成添加到 WinUI 3 / Windows 应用 SDK 桌面应用：有关如何将基于云的 OpenAI ChatGPT 完成功能集成到 WinUI 3/ Windows 应用 SDK 桌面应用中的教程。

  • 将 DALL-E 添加到 WinUI 3 / Windows 应用 SDK 桌面应用：有关如何将基于云的 OpenAI DALL-E 映像生成功能集成到 WinUI 3/ Windows 应用 SDK 桌面应用中的教程。

  • Azure OpenAI 服务：如果你希望应用 Windows 访问 OpenAI 模型，例如 GPT-4、GPT-4 Turbo 和 Vision、GPT-3.5-Turbo、DALLE-3 或 Embeddings 模型系列，并添加了安全性和企业功能 Azure，则可以在此 Azure OpenAI 文档中找到指导。

  • Azure AI 服务： Azure 通过 REST API 和客户端库 SDK 提供一套完整的 AI 服务，这些服务采用常用开发语言。 有关详细信息，请参阅各服务的相关文档。 这些基于云的服务可帮助开发人员和组织使用现成的、可自定义的 API 和模型快速创建智能、前沿、市场就绪和负责任的应用程序。 应用程序示例包括对话、搜索、监视、翻译、语音、视觉和决策的自然语言处理。

设计混合本地/云路径

当应用应在可用时利用本地推理，但仍需在不受支持的设备上或在本地模型准备就绪之前提供可用体验时，请使用混合方案。

  1. 首先选择本地功能。 先从适合您的场景的 Windows AI API 开始，如果需要运行特定模型，则使用 Windows ML / Foundry Local。
  2. 使用前检查就绪情况。 在启动时或显示该功能之前，查询本地功能的就绪状态。 如果 API 报告该功能不受支持、未安装或需要下载，请不要盲目调用该功能。
  3. 必须下载本地模型时请求同意。 某些本地模型为可选项，大小可达数 GB。 说明下载大小、为什么需要模型，以及应用是否可以在没有下载的情况下继续。
  4. 定义云回退。 如果本地模型尚未准备就绪，则仅在用户和组织允许数据离开设备时调用云终结点。 将本地和云路径保留在同一应用级抽象后面，以便应用的其余部分不依赖于推理运行的位置。
  5. 保持可观察行为。 记录使用的路径、就绪情况失败、模型下载结果和云回退错误，而无需记录提示、令牌或敏感内容，除非组织已批准该数据处理。

混合回退决策流

将此流用作起点：

  1. 当用户启动 AI 功能时，请检查本地 AI 功能是否符合任务。
  2. 如果没有本地功能适合该任务，请使用云 AI 或其他服务。
  3. 如果本地功能符合任务，请检查该功能是否在当前设备上准备就绪。
  4. 如果本地功能准备就绪，请运行本地推理。
  5. 如果本地功能需要模型下载，请在开始下载之前请求用户同意。
  6. 如果用户同意，请下载或准备模型，然后重试本地推理。
  7. 如果用户不同意，或者本地功能不受支持，请检查是否允许云回退方案。
  8. 如果允许云端回退，请使用云端路径。
  9. 如果不允许云回退，请解释设备、模型或策略要求，并禁用或隐藏该功能。

按任务复杂性路由

除了仅在本地模型不可用时才回退到云端之外，许多应用通过将每个请求路由到最适合它的模型来获得更好的成本、延迟和质量：对于轻量且范围明确的任务，使用小型端侧模型，如 Phi Silica；对于需要更深层次推理、更广泛知识或更大上下文窗口的任务，使用基于云的大型模型。

优先使用本地模型处理以下任务：

  • 短、单轮分类或意向检测（例如，将支持消息路由到类别）
  • 重写、汇总或重新格式化短、结构良好的文本，这些文本适合本地模型的上下文窗口
  • 从简短干净输入中提取结构化数据（例如表或键字段）
  • 用户可以轻松验证或更正答案的低风险对话响应
  • 任何任务必须离线运行的场景，或者将数据保留在设备上是硬性要求而不仅仅是偏好的场景

对于如下任务，建议优先采用基于云的模型：

  • 将多个工具调用链接在一起的多步骤推理、规划或任务
  • 超过本地模型上下文窗口的长文档或多轮次场景
  • 需要本地模型能力之外的广泛通用知识的任务，或需要从提供检索或其他最新数据源的云服务获取最新信息的任务
  • 对准确性门槛较高的场景，需要最强大的可用模型，并且可以容忍网络延迟和成本
  • 复杂的代码生成、图像生成或其他输出更好地由更大的专用模型提供

实现指南：

  1. 在选取模型之前对任务进行分类。 使用简单、明确且由你控制的信号（功能或 UI 入口点、输入长度或轻量级本地分类步骤），而不是试图在事后从模型输出中推断任务难度。
  2. 适合时，使用决策模型进行云连接的路由。 决策模型（如 Microsoft-Decision-1）可帮助对请求进行分类，并根据质量、延迟、成本和置信度要求将其路由到本地模型、云模型、工具或人工评审路径。
  3. 对于已归类为简单的任务，先使用本地模型，并在调用之前检查其就绪情况（请参阅 混合回退决策流程），这与任何其他本地 AI 功能相同。
  4. 将已归类为高级类型的任务直接路由到云端路径，而不是先尝试本地推理并放弃低质量结果，这样就可以避免将本地计算和延迟花在从未适合本地模型的请求上。
  5. 允许用户升级处理。 如果本地响应未完全应答请求，请提供一种针对云模型重试同一请求的明确方法，而不是静默失败。
  6. 随着本地模型改进，重新审视路由规则。 在模型更新后，如今需要云端处理的任务可能就可以轻松适配较小的端侧模型——将分类逻辑集中在一处，以便于调整。

有关本地化就绪情况的详细信息，请参阅 Windows AI API、开始使用 Windows AI APIFoundry Local以及 Windows ML。

  • 上次更新时间为