通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Well-Architected 框架透视 Azure OpenAI 服务

  • 项目

Azure OpenAI 服务提供对 OpenAI 大型语言模型的 REST API 访问 (LLM) ，并添加了 Azure 网络和安全功能。 本文提供体系结构建议，帮助你在将 Azure OpenAI 用作工作负载体系结构的一部分时做出明智的决策。 本指南基于 Azure Well-Architected Framework 支柱。

重要

如何使用本指南

每个部分都有一个 设计清单 ，其中介绍了关注的体系结构领域以及本地化到技术范围的设计策略。

还包括有关有助于实现这些策略的技术功能 的建议 。 这些建议并不表示可用于 Azure OpenAI 及其依赖项的所有配置的详尽列表。 而是列出映射到设计视角的关键建议。 使用建议生成概念证明或优化现有环境。

演示关键建议的基础体系结构： 基线 OpenAI 端到端聊天参考体系结构。

技术范围

此评论仅重点介绍 Azure OpenAI。

可靠性

可靠性支柱的目的是通过 构建足够的复原能力和从故障中快速恢复的能力来提供持续的功能。

可靠性设计原则提供适用于单个组件、系统流和整个系统的高级设计策略。

设计清单

基于 可靠性设计评审清单启动设计策略。 确定它与业务需求的相关性。 根据需要扩展策略以包含更多方法。

  • 复原能力：根据用例选择适当的部署选项，即即付即 用或预配吞吐量 。 由于预留容量可提高复原能力，因此请为生产解决方案选择预配的吞吐量。 即用即付方法非常适合开发/测试环境。

  • 冗余：在 Azure OpenAI 部署前添加相应的网关。 网关必须能够承受暂时性故障（如限制）并路由到多个 Azure OpenAI 实例。 请考虑路由到不同区域中的实例，以构建区域冗余。

  • 复原能力：如果使用 预配的吞吐量，请考虑同时部署即用即付实例来处理溢出。 当预配的吞吐量模型受到限制时，可以通过网关将调用路由到即用即付实例。 还可以使用监视来预测模型何时受到限制，并抢先地将调用路由到即用即付实例。

  • 复原能力：监视容量使用情况，确保不超过吞吐量限制。 定期查看容量使用情况，以实现更准确的预测，并帮助防止由于容量限制而导致的服务中断。

  • 复原能力：遵循 有关大型数据文件的指导 ，并从 Azure Blob 存储导入数据。 通过多部分表单上传的大型文件（100 MB 或更大）可能会变得不稳定，因为请求是原子请求，无法重试或恢复。

  • 恢复：定义一个恢复策略，其中包含针对经过微调的模型和上传到 Azure OpenAI 的训练数据的恢复计划。 由于 Azure OpenAI 没有自动故障转移，因此必须设计一个包含整个服务和所有依赖项的策略，例如包含训练数据的存储。

建议

建议 好处
监视即用即付的速率限制：如果使用即用即付方法，请管理模型部署的 速率限制 ，并 监视 (TPM) 和每分钟请求 (RPM) 的令牌使用情况。 此重要的吞吐量信息提供所需的信息，以确保从配额中分配足够的 TPM 以满足部署需求。

分配足够的配额可防止限制对已部署模型的调用。
监视预配的吞吐量的预配管理利用率：如果使用 预配的吞吐量 支付模型，请监视 预配管理的利用率。 请务必监视预配管理的利用率，以确保其不超过 100%，以防止对已部署模型的调用受到限制。
启用动态配额功能：如果工作负荷预算支持此功能，请通过在模型部署上启用动态配额来执行过度预配。 动态配额允许部署消耗比通常配额更多的容量，只要从 Azure 的角度来看有可用的容量。 额外的配额容量可能会阻止意外限制。
优化内容筛选器：优化内容筛选器，以最大程度地减少过度激进的筛选器的误报。 内容筛选器基于不透明的风险分析阻止提示或完成。 确保对内容筛选器进行优化，以允许工作负载的预期使用情况。

安全性

安全支柱的目的是为工作负荷提供 保密性、完整性和可用性 保证。

安全设计原则提供了一个高级设计策略，用于通过将方法应用于围绕 Azure OpenAI 的技术设计来实现这些目标。

设计清单

根据 安全设计评审清单 启动设计策略，并识别漏洞和控制，以改善安全状况。 然后，查看 Azure OpenAI 的 Azure 安全基线。 最后，扩展策略以根据需要包含更多方法。

  • 保护机密性：如果将训练数据上传到 Azure OpenAI，请使用 客户管理的密钥 进行数据加密，实现密钥轮换策略，并 删除训练、验证和训练结果数据。 如果使用外部数据存储来训练数据，请遵循该存储的安全最佳做法。 例如，对于Azure Blob 存储，请使用客户管理的密钥进行加密，并实施密钥轮换策略。 使用基于标识的托管访问，使用专用终结点实现网络外围，并启用访问日志。

  • 保护机密性：通过限制 Azure OpenAI 资源可以访问的出站 URL 来防止数据外泄。

  • 保护完整性：实现访问控制，以使用最低特权原则以及使用单个标识（而不是密钥）对用户访问系统进行身份验证和授权。

  • 保护完整性：实现 越狱风险检测 ，以保护语言模型部署免受提示注入攻击。

  • 保护可用性：使用安全控制来防止可能耗尽模型使用配额的攻击。 可以配置控件以隔离网络上的服务。 如果服务必须可从 Internet 访问，请考虑使用网关通过路由或限制来阻止可疑的滥用行为。

建议

建议 好处
安全密钥：如果体系结构需要基于 Azure OpenAI 密钥的身份验证，请将这些密钥存储在 Azure 密钥保管库中，而不是存储在应用程序代码中。 通过将机密存储在 密钥保管库 中来将机密与代码分开，可以减少泄露机密的可能性。 分离还有助于集中管理机密，减轻密钥轮换等责任。
限制访问：除非工作负载需要，否则禁用对 Azure OpenAI 的公共访问 。 如果要从 Azure 虚拟网络中的使用者进行连接，请创建 专用终结点 。 控制对 Azure OpenAI 的访问有助于防止未经授权的用户发动攻击。 使用专用终结点可确保网络流量在应用程序和平台之间保持私密。
Microsoft Entra ID：使用 Microsoft Entra ID 进行身份验证，并使用基于角色的访问控制 (RBAC) 授权访问 Azure OpenAI。 在 Azure AI Services 中禁用本地身份验证 ，并将其设置为 disableLocalAuthtrue。 为执行完成或映像生成的标识授予 认知服务 OpenAI 用户 角色。 向模型自动化管道和即席数据科学访问权限授予 认知服务 OpenAI 参与者等角色。 使用 Microsoft Entra ID可集中标识管理组件，并消除 API 密钥的使用。 将 RBAC 与 Microsoft Entra ID 结合使用可确保用户或组完全拥有完成工作所需的权限。 Azure OpenAI API 密钥无法实现这种细化访问控制。
使用客户管理的密钥： 使用客户管理的密钥 对上传到 Azure OpenAI 的微调模型和训练数据。 使用客户管理的密钥可以更灵活地创建、轮换、禁用和撤销访问控制。
防范越狱攻击：使用 Azure AI 内容安全 Studio 检测越狱风险。 检测越狱尝试识别并阻止尝试绕过 Azure OpenAI 部署的安全机制的提示。

成本优化

成本优化侧重于 检测支出模式、确定关键领域的投资优先级，以及优化其他 领域以满足组织预算，同时满足业务需求。

阅读 成本优化设计原则 ，了解实现这些目标的方法，以及与 Azure OpenAI 相关的技术设计选择中所需的权衡。

设计清单

根据投资 成本优化的设计评审清单启动设计 策略。 微调设计，使工作负荷与其分配的预算保持一致。 你的设计应使用适当的 Azure 功能，监视投资，并找到随时间推移进行优化的机会。

  • 成本管理：开发成本模型，考虑提示大小。 了解提示输入和响应大小以及文本如何转换为令牌有助于创建可行的成本模型。

  • 使用情况优化：从 Azure OpenAI 的即用即付定价 开始，直到令牌使用情况可预测。

  • 速率优化：如果令牌使用量足够高且在一段时间内可预测，请使用 预配的吞吐量 定价模型来更好地优化成本。

  • 使用情况优化：选择 模型 时，请考虑模型定价和功能。 从成本较低的模型开始，用于不太复杂的任务，如文本生成或完成任务。 对于更复杂的任务（如语言翻译或内容理解），请考虑使用更高级的模型。 选择适用于文本嵌入、图像生成或听录等用例的模型时，请考虑不同的模型 功能和 最大令牌使用限制。 通过仔细选择最适合需求的模型，可以优化成本，同时仍能达到所需的应用程序性能。

  • 使用优化：使用 API 调用提供的令牌限制约束，例如 max_tokens 和 n，它们指示要生成的完成次数。

  • 使用情况优化：最大化 Azure OpenAI 价格断点，例如微调和模型断点（如映像生成）。 由于微调按小时收费，因此请使用每小时可用时间来改善微调结果，同时避免滑入下一个计费周期。 同样，生成 100 个图像的成本与生成 1 个图像的成本相同。 最大化价格断点，以利于你。

  • 使用情况优化：在不再使用未使用的微调模型时删除这些模型，以避免产生持续的托管费用。

  • 调整使用情况：优化提示输入和响应长度。 较长的提示会通过消耗更多令牌来增加成本。 但是，缺少足够上下文的提示并无助于模型产生良好的结果。 创建简洁的提示，为模型提供足够的上下文来生成有用的响应。 此外，请确保优化响应长度的限制。

  • 成本效益：尽可能批处理请求，以最大程度地减少每次调用的开销，从而降低总体成本。 确保优化批大小。

  • 成本效益：由于模型具有不同的微调成本，因此，如果解决方案需要微调，请考虑这些成本。

  • 监视和优化：设置监视模型使用情况的成本跟踪系统。 使用该信息来帮助通知模型选择和提示大小。

建议

建议 好处
设计客户端代码以设置限制：自定义客户端应使用 Azure OpenAI 完成 API 的限制功能，例如每个模型 (max_tokens) 令牌数的最大限制，或生成 (n) 完成次数。 设置限制可确保服务器生成的量不会超过客户端需求。 使用 API 功能限制使用情况，使服务消耗与客户端需求保持一致。 这样可确保模型不会生成占用超过所需令牌的过长响应，从而节省资金。
监视即用即付使用情况：如果使用即用即付方法， 请监视 TPM 和 RPM 的使用情况。 使用该信息为体系结构设计决策（例如要使用的模型）提供信息，并优化提示大小。 持续监视 TPM 和 RPM 可提供相关指标，以优化 Azure OpenAI 模型的成本。 可以将此监视与模型功能和 模型定价 相结合，以优化模型使用情况。 还可以使用此监视来优化提示大小。
监视预配的吞吐量使用情况：如果使用 预配的吞吐量，请监视 预配管理的利用率 ，以确保不会充分利用购买的预配吞吐量。 持续监视预配管理的利用率可为你提供在未充分利用预配吞吐量时需要了解的信息。
成本管理： 通过 OpenAI 使用成本管理功能 来监视成本，设置预算来管理成本，并创建警报以将风险或异常情况通知利益干系人。 成本监视、设置预算和设置警报为治理提供了适当的责任流程。

卓越运营

卓越运营主要侧重于开发实践、可观测性和发布管理的过程。

卓越运营设计原则提供了一个高级设计策略，用于实现这些目标，以满足工作负载的运营要求。

设计清单

根据 卓越运营的设计评审清单启动设计策略。 此清单定义了与 Azure OpenAI 相关的可观测性、测试和部署过程。

  • Azure DevOps 区域性：确保在开发、测试和生产等各种环境中部署 Azure OpenAI 实例。 确保你拥有在整个开发周期中支持持续学习和试验的环境。

  • 可观测性：监视、聚合和可视化适当的指标。

  • 可观测性：如果 Azure OpenAI 诊断不足以满足你的需求，请考虑在 Azure OpenAI 前面使用 Azure API 管理 等网关来记录传入提示和传出响应（如果允许）。 此信息可帮助你了解模型对传入提示的有效性。

  • 放心部署：使用基础结构即代码 (IaC) 来部署 Azure OpenAI、模型部署以及微调模型所需的其他基础结构。

  • 放心部署：遵循 大型语言模型操作 (LLMOps) 做法，操作 Azure OpenAI LLM 的管理，包括部署、微调和提示工程。

  • 自动化以提高效率：如果使用基于密钥的身份验证，请实施自动密钥轮换策略。

建议

建议 好处
启用和配置 Azure 诊断：为 Azure OpenAI 服务启用和配置诊断。 诊断收集并分析指标和日志，帮助你监视 Azure OpenAI 的可用性、性能和操作。

性能效率

性能效率与维护用户体验有关，即使通过管理容量 增加负载 也是如此。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。

性能效率设计原则提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。

设计清单

根据 性能效率设计评审清单 启动设计策略，以便根据 Azure OpenAI 工作负载的关键绩效指标定义基线。

  • 容量：估计使用者的弹性需求。 确定需要同步响应的高优先级流量，以及可以异步和批处理的低优先级流量。

  • 容量：基于使用者的估计需求对令牌使用要求进行基准测试。 如果使用预配的吞吐量单位 (PTU) 部署，请考虑使用 Azure OpenAI 基准测试工具来 验证吞吐量。

  • 容量：为生产工作负荷使用预配的吞吐量。 预配的吞吐量为指定的模型版本提供专用内存和计算、预留容量和一致的最大延迟。 即用即付产品可能会受到邻近 干扰 问题的影响，例如，在大量使用的区域，延迟增加和限制。 此外，即用即付方法不提供有保证的容量。

  • 容量：在 Azure OpenAI 部署前面添加适当的网关。 确保网关可以路由到相同或不同区域中的多个实例。

  • 容量：分配 PTU 以涵盖预测的使用量，并使用 TPM 部署补充这些 PTU，以处理超过该限制的弹性。 此方法将基本吞吐量与弹性吞吐量相结合，以提高效率。 与其他注意事项一样，此方法需要自定义网关实现，以在达到 PTU 限制时将请求路由到 TPM 部署。

  • 容量：同步发送高优先级请求。 将低优先级请求排队，并在需求较低时分批发送这些请求。

  • 容量：选择符合性能要求的模型，考虑速度和输出复杂性之间的权衡。 根据所选模型类型，模型性能可能会有很大差异。 专为速度设计的模型提供更快的响应时间，这对于需要快速交互的应用程序非常有用。 相反，更复杂的模型可能会以增加响应时间为代价来提供更高质量的输出。

  • 实现性能：对于聊天机器人或聊天接口等应用程序，请考虑实现流式处理。 流式处理可以通过以增量方式向用户提供响应来增强 Azure OpenAI 应用程序的感知性能，从而改善用户体验。

  • 实现性能： 在提交微调之前，确定何时使用 微调。 尽管有很好的微调用例，例如当引导模型所需的信息太长或太复杂而无法适应提示时，请确保提示工程和检索增强生成 (RAG) 方法不起作用或成本明显更高。

  • 实现性能：考虑使用每个使用者组的专用模型部署来提供每模型使用隔离，以帮助防止使用者组之间的相邻干扰。

建议

对于 Azure OpenAI，没有建议的性能效率配置。

Azure Policy

Azure 提供了一组与 Azure OpenAI 及其依赖项相关的大量内置策略。 上述某些建议可以通过Azure Policy进行审核。 请考虑以下策略定义：

这些Azure Policy定义也是针对 Azure OpenAI 的 Azure 顾问安全最佳做法建议。

后续步骤

请考虑以下文章作为演示本文中突出显示的建议的资源。