Azure OpenAI 服务公开 HTTP API，允许应用程序使用 OpenAI 的大型语言模型执行嵌入或完成。 智能应用程序直接从客户端或业务流程协调程序调用这些 HTTP API。 客户端示例包括聊天 UI 代码和自定义数据处理管道； 业务流程协调程序的示例包括 Azure AI Foundry 中的 LangChain、语义内核和提示流。 当工作负载连接到一个或多个 Azure OpenAI 实例时，必须确定这些使用者是直接连接还是通过反向代理 API 网关进行连接。
阅读本指南，了解如果工作负荷设计包括从消费者直接访问 Azure OpenAI 数据平面 API，将遇到的 Azure Well-Architected Framework 五大支柱的关键挑战。 然后，了解如何在体系结构中引入网关来帮助解决这些直接访问挑战，以及了解需要进一步解决的新挑战。 本文介绍体系结构模式，但不介绍如何实现网关。
由于网关可用于解决并非存在于每个工作负荷中的特定方案；因此请务必参阅特定方案指南，该指南更深入地研究了网关的特定用例。
主要挑战
如果没有 API 网关或向 Azure OpenAI HTTP API 中添加逻辑的能力，客户端必须处理包括重试机制或断路器的 API 客户端逻辑。 在未直接控制客户端代码或代码仅限于特定 SDK 使用的情况下，这种情况可能具有挑战性。 多个客户端或多个 Azure OpenAI 实例和部署带来了进一步的挑战，例如协调安全部署和可观测性。
本节介绍如果体系结构仅支持消费者直接访问 Azure OpenAI，可能面临的特定关键体系结构挑战的一些示例。 挑战按照 Azure Well-Architected Framework 支柱列出。
可靠性挑战
工作负荷的可靠性取决于几个因素，包括其自我保存和自我恢复的能力，通常通过复制和故障转移机制实现。 如果没有网关，则所有可靠性问题都必须使用客户端逻辑和 Azure OpenAI 服务功能专门解决。 当这两个图面中的任何一个都没有足够的可靠性控制时，工作负荷的可靠性就会受到影响。
负载均衡或冗余： 基于服务可用性的多个 Azure OpenAI 实例之间故障转移是需要通过配置和自定义逻辑控制的客户端责任。
全局、标准或预配，以及 数据区域（标准或预配）不会影响 Azure OpenAI 服务的可用性，从区域终结点可用性的角度来看。 你仍有责任自行实现故障转移逻辑。
横向扩展以处理峰值：当容量受限时，故障转移到具有容量的 Azure OpenAI 实例是另一个客户端责任，需要通过配置和自定义逻辑进行控制。 为新的 Azure OpenAI 实例更新多个客户端配置存在更大的风险，而且会影响及时性。 更新客户端代码以实现逻辑变化也是同样的道理，例如在高需求时段将低优先级请求定向至队列。
限制： Azure OpenAI API 通过返回 HTTP 429 错误响应代码来限制标准模型中超过令牌Per-Minute（TPM）或请求Per-Minute（RPM）的请求。 Azure OpenAI API 还会限制超出预配计费模型的预配容量的请求。 处理适当的回退和重试逻辑专门限定于客户端实现。
大多数工作负荷应通过使用 azure OpenAI 的 全局 和 数据区域 部署来解决此特定问题。 这些部署用于将数据中心的模型容量用于每个请求的足够容量。 使用全局和数据区域部署会显著减少服务限制，而不会增加自定义网关的复杂性。 全局和数据区域部署本身是网关实现。
安全性挑战
安全性控制措施必须能帮助保护工作负荷的机密性、完整性和可用性。 如果没有网关，则所有安全性问题都必须在客户端逻辑和 Azure OpenAI 服务功能中专门解决。 工作负荷需求可能比用于直接通信的客户端分段、客户端控制或服务安全功能所需的更多。
标识管理 - 身份验证范围：Azure OpenAI 公开的数据平面 API 可以通过以下两种方式之一进行保护：API 密钥或 Azure 基于角色的访问控制 (RBAC)。 在这两种情况下，身份验证发生在 Azure OpenAI 实例级别，而不是单个部署级别，这为特定部署模型提供最低特权访问和标识分段带来了复杂性。
标识管理 - 标识提供者：对于不能使用位于支持 Azure OpenAI 实例的 Microsoft Entra 租户中的标识的客户端，必须共享一个完全访问权限的 API 密钥。 API 密钥具有安全性有用性限制，并且当涉及多个客户端并且所有客户端都共享同一标识时会出现问题。
网络安全：根据客户端相对于 Azure OpenAI 实例的位置，可能需要对语言模型进行公共 Internet 访问。
数据主权：Azure OpenAI 上下文中的数据主权是指与特定国家或地区的地理边界内的数据存储和处理相关的法律和监管要求。 工作负荷需要确保区域相关性，以便客户端可以遵守数据驻留和主权法律。 此过程涉及多个 Azure OpenAI 部署。
应注意的是，使用 全局 或 数据区域 Azure OpenAI 部署时，静态数据将保留在指定的 Azure 地理位置中，但数据可能会传输和处理，以便在任何 Azure OpenAI 位置进行推理。
成本优化挑战
当体系结构最大限度地减少浪费并最大限度地发挥效用时，工作负荷会受益。 强大的成本建模和监控是任何工作负荷的一项重要要求。 如果没有网关，可以通过聚合 Azure OpenAI 实例使用情况遥测，以权威方式实现预配或按客户端成本跟踪的利用率。
成本跟踪：能够提供有关 Azure OpenAI 使用情况的财务角度仅限于从 Azure OpenAI 实例使用情况遥测聚合的数据。 如果需要执行退款或显示余量，需要将使用情况遥测与不同部门的各种客户端甚至多租户场景的客户端联系起来。
预配吞吐量利用率：工作负荷希望充分利用所支付的预配吞吐量，从而避免浪费。 这意味着，在溢出到任何标准模型部署之前，必须信任和协调客户端才能使用预配的模型部署。
卓越运营挑战
如果没有网关，可观测性、更改控制和开发过程仅限于通过直接客户端到服务器通信提供的内容。
配额控制：当 HTTP API 受到限制时，客户端直接从 Azure OpenAI 接收 429 个响应代码。 工作负荷操作员负责确保有足够的配额可供合法使用，同时也要确保行为异常的客户端不会过度使用。 当工作负荷由多个模型部署或多个数据区域组成时，难以直观地了解配额使用情况和配额可用性。
监视和可观测性：Azure OpenAI 默认指标可通过 Azure Monitor 获得。 然而，数据的可用性存在延迟，并且不能提供实时监视。
安全部署做法：GenAIOps 过程需要在客户端与 Azure OpenAI 中部署的模型之间进行协调。 对于蓝绿或金丝雀等高级部署方法，需要在客户端处理该逻辑。
性能效率挑战
如果没有网关，工作负荷将把责任推给客户端，使其在有限的容量下，既要单独表现良好，又要与其他客户端公平相处。
性能优化 - 确定流量优先级：对客户端请求进行优先级排序，使高优先级客户端比需要大量且不合理的客户端到客户端协调的低优先级客户端具有优先访问权。 当模型利用率较低时，让低优先级请求排队运行会使一些工作负荷受益。
性能优化 - 客户端合规性：要共享容量，客户端需要表现良好。 例如，当客户端确保
max_tokens和best_of设置为已批准的值时。 如果没有网关，则必须信任客户端，以最大程度地保护 Azure OpenAI 实例的容量。最大程度地减少延迟：虽然网络延迟通常只占整个提示和完成请求流的一小部分，但确保将客户端路由到网络终结点和靠近它们的模型可能带来益处。 如果没有网关，客户端将需要自行选择要使用哪一个模型部署终结点，以及特定 Azure OpenAI 数据平面 API 需要哪些凭据。
解决方案
图 1：通过网关访问 Azure OpenAI 的概念体系结构
为了应对关键挑战中列出的许多挑战，可以注入一个反向代理网关，以便将智能应用程序与 Azure OpenAI 分离。 通过此网关卸载，可以将责任、复杂性和可观测性从客户端转移出去，并有机会通过提供其他未内置功能来增强 Azure OpenAI。 一些示例如：
实现联合身份验证的可能性。
通过速率限制控制模型所受压力的能力。
跨领域和跨模型监控。
使用 运行状况终结点监视 的负载均衡，通过 在不可用或过载的模型部署上中断 来路由到正常的终结点。
某些特定方案提供了直接针对 API 网关和 Azure OpenAI 实例的更多指导。 后续步骤部分列出了这些方案。
注意事项
在 Azure Well-Architected 框架的 Azure AI 工作负载指南中介绍的 应用程序设计 中，决定添加网关以及要使用的技术。 作为架构师，你需要做出包括或排除此组件的决定。
当在体系结构中引入新组件时，需要评估新引入的利弊。 当在客户端和 Azure OpenAI 数据平面之间注入 API 网关，以解决任何关键挑战时，就会为体系结构引入新的考虑因素。 仔细评估跨这些体系结构考虑因素的工作负荷影响是否证明网关的附加价值或实用性是合理的。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。
网关解决方案可能会引入单一故障点。 此故障的根源可能是网关平台的服务可用性、由于代码或配置部署而导致的中断，甚至是网关中关键 API 终结点的错误配置。 确保设计的实现满足工作负荷的可用性需求。 通过在工作负荷的故障模式分析中包含网关，考虑实现中的复原能力和容错能力。
如果体系结构要求多个区域中的 Azure OpenAI 实例提高 Azure OpenAI 终结点的可用性，例如，在发生区域性中断时继续处理请求的能力，解决方案可能需要全局路由功能。 这种情况会通过管理额外的完全限定域名 (FQDN)、TLS 证书和更多的全局路由组件，使拓扑结构进一步复杂化。
重要
如果这样做会危及工作负荷达到商定的服务级别目标 (SLO) 的能力，请不要实现网关。
安全性
当考虑 API 网关如何使体系结构受益时，请使用安全性设计评审核对清单来评估设计。 需要解决安全性方面的问题，例如以下方面：
随着网关的增加，工作负荷的外围应用也会增加。 该外围应用带来了 Azure 资源的额外标识和访问管理 (IAM) 注意事项、增加了强化工作等等。
网关可以充当客户端网络空间与专用 Azure OpenAI 网络空间之间的网络边界转换。 尽管网关使用 Azure 专用链接将以前面向 Internet 的 Azure OpenAI 终结点专用化，但它现在已成为新的入口点，必须得到充分的保护。
网关处于一个独特的位置，可以查看来自语言模型的原始请求数据和公式化响应，其中可能包括来自任何一个源的机密数据。 数据符合性和法规范围现已扩展到此其他组件。
网关可以将客户端授权和身份验证的范围扩展到 Microsoft Entra ID 和 API 密钥身份验证之外，并可能跨多个标识提供者 (IdP)。
在多区域实现中，必须将数据主权考虑在内。 确保网关计算和路由逻辑符合工作负荷的主权要求。
重要
如果实现网关会使工作负荷无法保护其本身或其用户数据的机密性、完整性或可用性，则不要实现网关。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。
所有实现的 API 网关都有运行时成本，需要进行预算和核算。 这些成本通常会随着解决网关本身的可靠性、安全性和性能问题的新增功能以及添加 APIOps 管理带来的运营成本而增加。 这些增加的成本需要根据网关系统提供的新价值来衡量。 你希望达到通过网关引入的新功能大大超过实现和维护网关的成本的程度。 根据工作负荷与其用户的关系，或许能够根据使用率进行收费。
为了在开发和测试网关时帮助管理成本，可以考虑为 Azure OpenAI 使用模拟终结点。 例如，使用 Azure OpenAI API simulator GitHub 存储库中的解决方案。
卓越运营
当考虑 API 网关如何使体系结构受益时，请使用卓越运营设计评审核对清单来评估设计。 需要解决卓越运营方面的问题，例如以下方面：
网关本身需要受到工作负荷监控解决方案的监控，也可能受到客户端的监控。 这意味着网关计算和操作需要包含在工作负荷的运行状况建模中。
安全部署做法现在需要解决 API 网关基础结构的部署以及网关路由的代码或配置问题。 基础结构自动化和基础结构即代码 (IaC) 解决方案需要考虑如何将网关视为工作负荷中的长期资源。
需要生成或扩展 APIOps 方法，以涵盖网关中公开的 API。
重复通过 Azure AI 服务资源或 Azure OpenAI 数据区域负载分发功能等解决方案提供的功能。
性能效率
当考虑 API 网关如何使体系结构受益时，请使用性能效率设计评审核对清单来评估设计。 需要解决性能效率方面的问题，例如以下方面：
网关服务可能会造成吞吐量瓶颈。 请确保网关有足够的性能来处理全部并发负载，并且可以根据增长预期轻松扩展。 确保解决方案的弹性，以便网关能够在需求较低时减少供应或缩减规模，例如工作日使用量。
网关服务对每个请求都有必须执行的处理，并且每个 API 调用都会增加延迟。 应优化路由逻辑，以保持请求的良好运行。
在大多数情况下，网关应该在地理位置上靠近用户和 Azure OpenAI 实例，以减少延迟。 虽然网络延迟通常只占对语言模型的整个 API 调用的一小部分时间，但对于工作负荷来说，它可能是一个竞争因素。
评估网关对 Azure OpenAI 功能（如流式处理响应）的影响，或对助手 API 等有状态交互进行实例固定。
重要
如果实现网关不可能实现商定的性能目标，或者在其他权衡方面过于妥协，请不要实现网关。
实现选项
Azure 不提供专门用于代理 Azure OpenAI 的 HTTP API 或其他自定义语言模型推理 API 的交钥匙解决方案，以涵盖所有这些方案。 但是工作负荷团队仍然有几个选项可以实现，例如 Azure 中的网关。
使用 Azure API 管理
Azure API 管理是平台托管服务，设计用于减轻基于 HTTP 的 API 的跨领域问题。 它由配置驱动，支持通过其入站和出站请求处理策略系统进行自定义。 它通过使用单个控制平面支持高可用性、区域冗余甚至多区域复制。
大多数网关路由和请求处理逻辑必须在 API 管理的策略系统中实现。 可以 结合特定于 Azure OpenAI 的内置策略，例如 限制 Azure OpenAI API 令牌使用 或 发出指标来消耗 Azure OpenAI 令牌，以及你自己的自定义策略。 GenAI 网关工具包 GitHub 存储库包含许多自定义 API 管理策略，以及用于测试策略行为的负荷测试设置。
在设计涉及 Azure API 管理的解决方案时，请使用适用于 API 管理的 Well-Architected Framework 服务指南。 如果工作负荷作为应用程序登陆区域的一部分存在，请查看 Azure 云采用框架中提供的有关实现 Azure API 管理登陆区域的指南。
在网关实现中使用 Azure API 管理通常是生成和操作 Azure OpenAI 网关的首选方法。 之所以首选它，是因为该服务是一种平台即服务 (PaaS) 产品，具有丰富的内置功能、高可用性和网络选项。 同时也具有管理完成 API 的可靠的 APIOps 方法。
使用自定义代码
自定义代码方法要求软件开发团队创建自定义编码解决方案，并将该解决方案部署到他们选择的 Azure 应用程序平台。 构建一个自托管解决方案来处理网关逻辑，对于精通管理网络和路由代码的工作负荷团队来说是一个很好的选择。
工作负荷通常可以使用他们熟悉的计算，例如在 Azure 应用程序服务、Azure 容器应用或 Azure Kubernetes 服务上托管网关代码。
当 API 管理专门用于客户端和自定义代码之间的核心 HTTP API 网关功能时，自定义代码部署也可以由 API 管理进行。 这样，自定义代码就可以基于必要的业务逻辑专门与 Azure OpenAI HTTP API 进行交互。
使用非 Microsoft 网关技术（不是 Azure 原生提供的产品或服务）也可以被视为此方法的一部分。
示例体系结构
图 2：通过基于 Azure API 管理的网关访问 Azure OpenAI 的示例体系结构
后续步骤
了解在智能应用程序和 Azure OpenAI 部署之间部署网关用于满足工作负荷要求的特定方案：
了解为 Azure OpenAI 模型实现日志记录和监视的方法。
相关资源
- Azure OpenAI 服务
- Azure API 管理中的 API 网关
- 涵盖生成式 AI 方案的 API 管理登陆区域 GitHub 存储库
- API 管理网关工具包
- OpenAI API Simulator