你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure OpenAI 服务提供对 OpenAI 大型语言模型（LLM）的 REST API 访问，并添加了 Azure 网络和安全功能。 本文提供体系结构建议，帮助你在将 Azure OpenAI 用作工作负荷体系结构的一部分时做出明智的决策。 本指南基于 Azure 架构良好的框架支柱。
重要
如何使用本指南
每个部分都有一个 设计清单，该清单 提供关注的体系结构区域以及本地化为技术范围的设计策略。
还包括有关有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于 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：通过使用基于角色的访问控制 (RBAC) 来使用 Microsoft Entra ID 进行身份验证和授权访问 Azure OpenAI。 在 Azure AI 服务中禁用本地身份验证，并将 disableLocalAuth 设置为 true。 向执行补全或图像生成的标识授予认知服务 OpenAI 用户角色。 授予模型自动化管道和临时数据科学访问认知服务 OpenAI 参与者等角色。 |
使用 Microsoft Entra ID 可集中标识管理组件，并消除 API 密钥的使用。 将 RBAC 与 Microsoft Entra ID 一起使用可确保用户或组恰好具有执行其作业所需的权限。 Azure OpenAI API 密钥无法实现这种精细的访问控制。 |
| 使用客户管理的密钥：将客户管理的密钥用于优化的模型和上传到 Azure OpenAI 的训练数据。 | 使用客户管理的密钥，可以更加灵活地创建、轮换、禁用和撤销访问控制。 |
| 防范越狱攻击：使用 Azure AI 内容安全工作室检测越狱风险。 | 检测越狱尝试，以识别和阻止尝试绕过 Azure OpenAI 部署安全机制的提示。 |
成本优化
成本优化侧重于 检测支出模式、优先考虑关键领域的投资，并优化其他 领域以满足组织预算，同时满足业务需求。
阅读成本优化设计原则，了解实现这些目标的方法，以及与 Azure OpenAI 相关的技术设计选择所需的权衡。
设计清单
根据 投资成本优化 的设计评审清单启动设计策略。 微调设计，使工作负荷与其分配的预算保持一致。 设计应使用适当的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。
成本管理：根据提示大小开发成本模型。 了解提示输入和响应大小以及文本如何转换为令牌有助于创建可行的成本模型。
使用优化：从 Azure OpenAI 即用即付定价开始，直到令牌使用情况可预测。
速率优化：当令牌使用量足够高且可预测一段时间内时，请使用 预配的吞吐量 定价模型进行更好的成本优化。
使用优化：选择模型时，请考虑 模型定价 和功能。 从成本较低的模型开始，用于不太复杂的任务，例如文本生成或完成任务。 对于更复杂的任务，如语言翻译或内容理解，请考虑使用更高级的模型。 选择适合文本嵌入、图像生成或听录方案等用例的模型时，请考虑不同的 模型功能和 最大令牌使用限制。 通过仔细选择最符合需求的模型，可以优化成本，同时仍可实现所需的应用程序性能。
使用优化：使用 API 调用提供的令牌限制约束，例如
max_tokens，并n指示要生成的完成次数。使用优化：最大化 Azure OpenAI 价格断点，例如微调和模型断点，例如图像生成。 由于微调按小时收费，因此使用每小时可用的时间来提高微调结果，同时避免滑入下一个计费周期。 同样，生成 100 个映像的成本与 1 个图像的成本相同。 最大限度地利用价格断点。
使用优化：不再使用未使用的微调模型，以避免产生持续托管费用。
调整使用情况：优化提示输入和响应长度。 更长的提示通过消耗更多令牌来增加成本。 但是，缺少足够上下文的提示有助于模型产生良好的结果。 创建简洁的提示，为模型提供足够的上下文来生成有用的响应。 此外，请确保优化响应长度的限制。
成本效益：尽可能减少每个调用开销的 Batch 请求，从而降低总体成本。 确保优化批大小。
成本效益：由于模型具有不同的微调成本，因此如果你的解决方案需要微调，请考虑这些成本。
监视和优化：设置用于监视模型使用情况的成本跟踪系统。 使用该信息来帮助通知模型选择和提示大小。
建议
| 建议 | 好处 |
|---|---|
设计客户端代码来设置限制：自定义客户端应使用 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 工作负载的关键绩效指标定义基线，启动设计策略。
容量：估计使用者的弹性需求。 确定需要同步响应的高优先级流量和可异步和批处理的低优先级流量。
容量：根据使用者的估计需求对令牌消耗需求进行基准测试。 请考虑使用 Azure OpenAI 基准测试工具来 帮助你验证预配的吞吐量单位（PTU）部署。
容量：对生产工作负荷使用预配的吞吐量。 预配的吞吐量为指定的模型版本提供专用内存和计算、预留容量和一致的最大延迟。 即用即付产品可能会遇到 干扰性邻居 问题，例如，在大量使用的区域延迟增加和限制。 此外，即用即付方法不提供有保证的容量。
容量：在 Azure OpenAI 部署前添加相应的网关。 确保网关可以路由到相同或不同区域中的多个实例。
容量：分配 PTU 以涵盖预测使用情况，并通过 TPM 部署对这些 PTU 进行补充，以处理超出该限制的弹性。 此方法将基本吞吐量与弹性吞吐量相结合，提高效率。 与其他注意事项一样，此方法要求自定义网关实现在达到 PTU 限制时将请求路由到 TPM 部署。
容量：同步发送高优先级请求。 将低优先级请求排入队列，并在需求不足时分批发送请求。
容量：选择符合性能要求的模型，考虑速度和输出复杂性之间的权衡。 模型性能可能会因所选模型类型而显著变化。 专为速度设计的模型提供更快的响应时间，这对于需要快速交互的应用程序非常有用。 相反，更复杂的模型可能会以牺牲响应时间增加为代价提供更高质量的输出。
实现性能：对于聊天机器人或聊天接口等应用程序，请考虑实现流式处理。 流式处理可以通过以增量方式向用户提供响应，从而提高用户体验，从而增强 Azure OpenAI 应用程序的感知性能。
实现性能： 确定在提交微调之前何时使用微调 。 尽管微调有很好的用例，例如，当引导模型的信息太长或复杂而无法适应提示时，请确保提示工程和检索扩充生成（RAG）方法不起作用或成本明显更高。
实现性能：请考虑使用每个使用者组的专用模型部署来提供每模型使用隔离，以帮助防止使用者组之间的干扰性邻居。
建议
Azure OpenAI 的性能效率没有建议的配置。
Azure Policy
Azure 提供了一组与 Azure OpenAI 及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 请考虑以下策略定义：
这些 Azure Policy 定义也是 针对 Azure OpenAI 的 Azure 顾问 安全最佳做法建议。
后续步骤
将以下文章视为演示本文中突出显示的建议的资源。
- 将此参考体系结构用作如何将本文指南应用于工作负荷的示例： 基线 OpenAI 端到端聊天参考体系结构。
- 使用Azure 机器学习产品文档构建实施专业知识。