在多个 Azure OpenAI 部署或实例前使用网关

涉及 Azure OpenAI 服务的工作负荷体系结构可以简单到一个或多个客户端应用程序直接使用一个 Azure OpenAI 模型部署，但并非所有工作负荷都能设计得如此简单。 更复杂的方案包括具有多个客户端、多个 Azure OpenAI 部署或多个 Azure OpenAI 实例的拓扑结构。 在这种情况下，在 Azure OpenAI 前面引入网关可能有利于工作负荷的设计。

多个 Azure OpenAI 实例或模型部署可解决工作负荷体系结构中的特定需求。 它们可以分为四种关键拓扑。

• 单个 Azure OpenAI 实例的多个模型部署
• 单个区域和单个订阅中的多个 Azure OpenAI 实例
• 跨多个订阅的单个区域中的多个 Azure OpenAI 实例
• 跨多个区域的多个 Azure OpenAI 实例

这些拓扑结构本身并不需要使用网关。 网关的选择取决于工作负荷是否能从将其纳入体系结构中获益。 本文将介绍这四种拓扑结构各自所面临的挑战，以及在每种拓扑结构中包含网关的好处和成本。

在单个 Azure OpenAI 实例中部署多个模型

多个模型部署的拓扑详细信息

• Azure OpenAI 模型部署：多个
• Azure OpenAI 实例：一个
• 订阅：一个
• 区域：一个

多个模型部署的拓扑用例

包含单个 Azure OpenAI 实例但包含多个并发部署模型的拓扑支持以下用例：

• 公开不同的模型功能，例如 gpt-35-turbo、gpt-4 和自定义微调的模型。

• 公开不同的模型版本，例如 0613、1106 和自定义微调的模型，以支持工作负荷演变或蓝/绿部署。

• 公开分配的不同配额（每分钟 30,000 令牌 (TPM)、60,000 TPM），以支持跨多个客户端的消耗限制。

为多个模型部署引入一个网关

在该拓扑中引入网关主要是为了将客户端从实例上的可用部署中自行选择特定的模型实例中抽象出来。 网关允许服务器端控制将客户端请求定向到特定模型，而无需重新部署客户端代码或更改客户端配置。

当无法控制客户端代码时，网关尤其有用。 当部署客户端配置比部署对网关路由配置的更改更复杂或风险更大时也很有助益。 可以根据模型版本的蓝绿推出策略更改客户端指向的模型，例如推出新的微调模型，或从同一模型的版本 X 更改为 X+1。

网关还可以用作单个 API 入口点，使网关能够标识客户端。 然后，它可以根据该客户端的标识或 HTTP 请求中的其他信息来确定使用哪个模型部署来提供提示。 例如，在一个多租户解决方案中，租户可能被限制为特定的吞吐量，并且该体系结构的实现是具有特定配额的每个租户的模型部署。 在这种情况下，网关将根据 HTTP 请求中的信息负责路由到租户的模型。

在这种拓扑中使用网关，可以对客户端的使用情况进行跟踪。 除非客户端使用不同的 Microsoft Entra 服务原则，否则 Azure OpenAI 的访问日志将无法区分多个客户端。 在部署前设置一个网关，可使工作负荷有机会跨各种可用模型部署跟踪每个客户端的使用情况，以支持提供资源费用账单或提供资源使用账单模型。

关于多模型部署拓扑的提示

• 当网关处于完全更改正在使用的模型的位置时（例如，gpt-35-turbo 到 gpt-4），该更改可能被认为是对客户端的重大更改。 不要让网关的新功能分散对该工作负荷始终执行安全部署做法的注意力。

• 这种拓扑结构通常可以通过 Azure API 管理策略而不是自定义代码解决方案来直接实现。

• 要支持本机 SDK 使用已发布的 Azure OpenAI API 规范，请维护 API 与 Azure OpenAI API 的兼容性。 如果团队未编写所有工作负荷客户端的代码，这一情况就会更加严重。 在决定为网关设计 HTTP API 时，请考虑维护 Azure OpenAI HTTP API 兼容性的好处。

• 虽然这种拓扑在技术上支持 Azure OpenAI 实例的直通客户端凭据（访问令牌或 API 密钥），但仍应积极考虑实现凭据终止和重建。 这样，客户端在网关上获得授权，然后网关通过 Azure RBAC 来获得 Azure OpenAI 实例的授权。

• 如果网关被设计为使用直通凭证，则应确保客户端无法绕过网关或基于客户端的任何模型限制。

• 将网关部署在与 Azure OpenAI 实例相同的区域中。

• 将网关部署到订阅中独立于 Azure OpenAI 实例的专用资源组中。 将订阅与后端隔离有助于通过关注点分离来驱动 APIOps 方法。

• 将网关部署到包含 Azure OpenAI 实例 Azure 专用链接专用终结点的子网的虚拟网络中。 对该子网应用网络安全组 (NSG) 规则，只允许网关访问该专用终结点。 应禁止对 Azure OpenAI 实例的所有其他数据平面访问。

在多模型部署中避免使用网关的原因

如果控制客户端的配置与控制网关级别的路由一样简单或更容易，那么网关增加的可靠性、安全性、成本、维护和性能影响可能并不值得增加体系结构组件。

此外，一些工作负荷方案可以从多模型部署方法迁移到多 Azure OpenAI 实例部署方法中受益。 例如，如果有多个客户端，而这些客户端应使用不同的 RBAC 或访问密钥来访问其模型，则可考虑使用多个 Azure OpenAI 实例。 在单个 Azure OpenAI 实例中使用多个部署并在网关级别处理逻辑身份分段是可行的，但如果使用不同的 Azure OpenAI 实例来提供物理 RBAC 分段方法，则可能会过度。

单个区域和单个订阅中的多个 Azure OpenAI 实例

单个区域和单个订阅中多个实例的拓扑详细信息

• Azure OpenAI 模型部署：一个或多个
• Azure OpenAI 实例：多个
• 订阅：一个
• 区域：一个

单个区域和单个订阅中多个实例的拓扑用例

在单个区域和单个订阅中包括多个 Azure OpenAI 实例的拓扑支持以下用例：

• 启用安全分段边界，例如每个客户端的密钥或 RBAC

• 为不同的客户端启用简单退款模型

• 为 Azure OpenAI 可用性启用故障转移策略，例如影响特定实例的平台中断、网络配置错误或意外删除的部署

• 为 Azure OpenAI 配额可用性启用故障转移策略，例如将基于 PTU 的实例和基于消耗的实例配对以进行溢出

为单个区域和订阅中的多个实例引入网关

由于多种原因，客户端可能无法访问模型。 这些原因包括 Azure OpenAI 服务中断、Azure OpenAI 限制请求或与工作负荷操作相关的问题，例如网络配置错误或无意中删除模型部署。 要解决这些难题，应实现重试和断路逻辑。

该逻辑可以在网关的客户端或服务器端实现。 在网关中实现逻辑将逻辑从客户端抽象出来，从而避免了重复的代码，并且只有一个地方可以测试逻辑。 无论是否拥有客户端代码，这种转变都可以提高工作负荷的可靠性。

利用在单个区域和订阅中具有多个 Azure OpenAI 实例的网关，可以将所有后端视为主动-主动部署，而不仅仅是在主动-被动故障切换中使用它们。 可以跨多个 Azure OpenAI 实例部署相同的基于 PTU 的模型，并使用网关在它们之间进行负载均衡。

预配 Azure OpenAI 时，工作负荷团队的一个选择是确定计费和吞吐量模型是基于 PTU 还是基于消耗。 避免因未使用的 PTU 而造成浪费的成本优化策略是稍微低于 PTU 实例的预配，并同时部署一个基于消耗的实例。 此拓扑的目标是让客户端首先使用所有可用的 PTU，然后“突发”到基于消耗的部署中，以解决过剩问题。 这种形式的计划的故障转移的好处与本部分开头一段中提到的原因相同：将这种复杂性排除在客户端代码之外。

当涉及网关时，它处于一个独特的位置，可以捕获有关客户端正在交互的所有模型部署的详细信息。 虽然 Azure OpenAI 的每个实例都可以捕获自己的遥测数据；但在网关内这样做允许工作负荷团队将所有消耗模型的遥测数据和错误响应发布到单个存储中，从而使统一的仪表板和警报更容易。

关于单个区域和订阅拓扑中的多个实例的提示

• 在网关支持故障转移方案时，确保网关使用 Azure OpenAI 的 HTTP 响应中提供的 Retry-After 信息。 使用该权威信息来控制断路器的实现。 不要连续命中返回 429 Too Many Requests 的终结点； 而是断开该模型实例的线路。

• 在网关中，可以通过跟踪先前请求的模型消耗，来尝试在节流事件发生之前预测节流事件，但存在边缘情况。 在大多数情况下，最好不要尝试预测，而是使用 HTTP 响应代码来推动未来的路由决策。

• 当轮询或故障转移到不同的端点（包括 PTU 溢出到消耗中）时，始终确保这些终结点在同一版本中使用相同的模型。 例如，不要从 gpt-4 故障转移到 gpt-35-turbo，或者从 X 版本故障转移到 X+1 版本，或者在它们之间实现负载均衡。 此版本更改可能会导致客户端出现意外行为。

• 负载均衡和故障转移逻辑可在 Azure API 管理策略中实现。 你可能能够使用基于代码的网关解决方案提供更复杂的方法，但是 API Management 对于这个用例已经足够了。

• 将网关部署在与 Azure OpenAI 实例相同的区域中。

• 将网关部署到订阅中的专用资源组，该资源组与 Azure OpenAI 实例分开。 将网关与后端隔离有助于通过关注点分离来驱动 APIOps 方法。

• 将所有 Azure OpenAI 实例专用链接专用终结点并置到网关虚拟网络上的单个子网中。 将 NSG 规则应用于该子网，以仅允许网关访问这些专用终结点。 应禁止对 Azure OpenAI 实例的所有其他数据平面访问。

• 要简化网关路由代码中的逻辑，请使用相同的模型部署名称来最大程度地减少 HTTP 路由之间的差异。 例如，无论模型名称 gpt4-v1 是基于消耗还是基于 PTU，都可以在所有负载均衡或溢出实例上使用。

避免为单个区域和订阅中的多个实例使用网关的原因

网关本身不会提高针对此特定拓扑的不同客户端的退款模型的能力。 在此拓扑中，可以向客户端授予对其自己的专用 Azure OpenAI 实例的访问权限，这将支持工作负荷团队提供资源费用账单或提供资源使用账单的能力。 该模型支持唯一标识和网络外围，因此不需要专门为分段引入网关。

如果在几个客户端中控制代码，并且客户端易于更新，那么必须构建到网关中的逻辑可以直接添加到代码中。 当没有客户端代码或太过复杂不适合客户端处理时，主要考虑使用网关方法进行故障切换或负载均衡。

跨多个订阅的单个区域中的多个 Azure OpenAI 实例

跨多个订阅的单个区域中多个 Azure OpenAI 实例的拓扑详细信息

• Azure OpenAI 模型部署：一个或多个
• Azure OpenAI 实例：多个
• 订阅：多个
• 区域：一个

跨多个订阅的单个区域中多个 Azure OpenAI 实例的拓扑用例

在多个订阅的单个区域中包括多个 Azure OpenAI 实例的拓扑支持以下用例：

• 包括在单个区域和单个订阅中为多个 Azure OpenAI 实例列出的所有用例。

• 使你能够获取更多基于消耗的配额，因为订阅边界是可用于消耗模型的一个因素。 可使用此附加配额支持高度并发消耗。

为单个区域和多个订阅中的多个实例引入网关

为单个区域和订阅中的多个实例引入网关所介绍的相同原因适用于此拓扑。

除了这些原因之外，在此拓扑中添加网关还支持核心团队为其组织提供“Azure OpenAI 即服务”模型。 由于基于消耗的配额是订阅绑定的，因此，提供使用基于消耗的模型的 Azure OpenAI 服务的核心团队必须跨多个订阅部署 Azure OpenAI 实例，以获取所需的配额。 网关逻辑在很大程度上仍然保持不变。

针对单个区域和多个订阅拓扑中的多个实例的提示

• 理想情况下，所有订阅都应使用相同的 Microsoft Entra 租户提供支持，以支持 Azure RBAC 和 Azure Policy 中的一致性。

• 将网关部署在与 Azure OpenAI 实例相同的区域中。

• 将网关部署到独立于 Azure OpenAI 实例的专用订阅中。 这有助于在解决 Azure OpenAI 实例方面强制执行一致性，并在 Azure OpenAI 部署及其路由之间提供职责的逻辑分段。

• 跨订阅路由来自网关的请求时，需要确保可访问专用终结点。 可以通过集线器使用可传递路由到各自支路中的后端专用终结点。 可以使用跨订阅的专用链接连接，直接在网关订阅中公开 Azure OpenAI 服务的专用终结点。 如果体系结构和组织支持此方法，则首选跨订阅专用链接连接。

避免为单个区域和多个订阅中的多个实例使用网关的原因

避免为单个区域和订阅中的多个实例使用网关的原因都适用于此拓扑。

跨多个区域的多个 Azure OpenAI 实例

跨多个区域的多个 Azure OpenAI 实例的拓扑详细信息

• Azure OpenAI 模型部署：多个
• Azure OpenAI 实例：多个
• 订阅：一个或多个
• 区域：多个

跨多个区域的多个 Azure OpenAI 实例的拓扑用例

包含分布在两个或多个 Azure 区域的多个 Azure OpenAI 实例的拓扑支持以下用例：

• 包括跨多个订阅在单个区域中为多个 Azure OpenAI 实例列出的所有用例。

• 为服务可用性启用故障转移策略，例如使用跨区域对。

• 启用数据驻留和合规性设计。

• 启用混合模型可用性。 有些地区有不同的模型，模型的配额也不同。

虽然在技术上没有不同的 Azure 区域，但当在跨系统的情况下（如在本地或另一个云中）公开人工智能模型时，这种拓扑结构也适用。

为多个区域中的多个实例引入网关

对于必须经受完全区域中断的业务关键型体系结构，全局统一网关有助于消除客户端代码中的故障转移逻辑。 此实现要求网关不受区域性中断的影响。

跨区域负载均衡并不常见，但是可以策略性地使用它来组合跨区域基于消费的部署中的可用配额。 此方案不要求网关本身不受区域中断的影响，但建议确保最大工作负荷可靠性。

使用 Azure API 管理（单区域部署）

在此拓扑中，Azure API 管理专门用于网关技术。 此处，API 管理部署到单个区域。 从该网关实例，可以跨区域执行主动-主动负载均衡。 网关中的策略引用所有 Azure OpenAI 实例。 网关需要通过跨区域虚拟网络对等互连或专用终结点对每个后端建立网络线。 从此网关调用另一个区域中的 Azure OpenAI 实例会产生更高的网络延迟和出口费用。

网关必须遵循 Azure OpenAI 实例的限制和可用性信号，并从池中删除有故障的后端，直到可以安全地重新添加出现故障或节流的 Azure OpenAI 实例为止。 发生故障时，网关应针对池中的另一个后端实例重试当前请求，然后再回退以返回网关错误。 当没有可用的后端 Azure OpenAI 实例时，网关的运行状况检查应发出不正常信号。

由于此拓扑引入了单一故障点（即网关），因此这种特定体系结构的实用性相当有限。 当预测 PTU 分配可能过于具有挑战性时，该模型确实很适合 Azure OpenAI 中基于消费的计费。

主动-被动变型

该模型还可用于提供主动-被动方法，专门处理 Azure OpenAI 的区域故障。 在这种模式下，流量通常从网关流向与 API 管理服务位于同一区域的 Azure OpenAI 实例。 Azure OpenAI 实例将处理所有预期的流量流，而不会发生区域性故障。 它可以是基于 PTU 的，也可以是基于消耗的，具体取决于首选计费模型。 在仅 Azure OpenAI 出现区域故障的情况下，网关可以将流量重定向到另一个区域，其中 Azure OpenAI 已经部署在消耗模式中。

使用 Azure API 管理（多区域部署）

为了提高先前基于 Azure API 管理的体系结构的可靠性，API 管理支持将实例部署到多个 Azure 区域。 此部署选项通过单个 API 管理实例提供单个控制平面，但在你选择的区域中提供复制网关。 在此拓扑中，将网关组件部署到包含提供主动-主动网关体系结构的 Azure OpenAI 实例的每个区域。

策略（如路由和请求处理逻辑）被复制到每个单独的网关。 所有策略逻辑都必须在策略中具有条件逻辑，以确保你在与当前网关相同的区域中调用 Azure OpenAI 实例。 有关详细信息，请参阅将 API 调用路由到区域后端服务。 然后，网关组件通常通过专用终结点，只需要其所在区域的 Azure OpenAI 实例的网络线。

API 管理提供基于最低延迟的现成可用的全局完全限定域名 (FQDN) 路由。 将此基于性能的内置功能用于主动-主动网关部署。 此内置功能有助于解决性能问题，并处理区域网关中断。 内置全局路由器还支持灾难恢复测试，因为可以通过禁用单个网关来模拟区域。 确保客户端遵循 FQDN 上的生存时间 (TTL)，并具有适当的重试逻辑来处理最近的 DNS 故障转移。

如果需要在此体系结构中引入 Web 应用程序防火墙，则仍可使用内置的 FQDN 路由解决方案作为实现 Web 应用程序防火墙的全局路由器的后端源。 全局路由器将故障转移责任委托给 API 管理。 或者，可以使用区域网关 FQDN 作为后端池成员。 在此后一种体系结构中，在每个区域网关或其他自定义运行状况 API 终结点上使用内置 /status-0123456789abcdef 终结点来支持区域故障转移。 如果不确定，请从单个源后端 FQDN 方法开始。

如果可以将区域视为完全可用或完全不可用，则此体系结构效果最佳。 这意味着，如果 API 管理网关或 Azure OpenAI 实例不可用，则希望客户端流量不再路由到该区域中的 API 管理网关。 除非另有规定，否则如果区域网关在 Azure OpenAI 不可用时仍然接受流量，则必须将错误传播到客户端。 要避免客户端错误，请参阅主动-主动网关 + 主动-被动 Azure OpenAI 变型中的改进方法。

如果某个区域遇到 API 管理网关中断或标记为不正常，则剩余的可用区域需要吸收来自其他区域的 100% 流量。 这意味着需要过度预配基于 PTU 的 Azure OpenAI 实例来处理新的流量激增，或使用主动-被动方法进行故障转移。 使用 Azure OpenAI 容量计算器进行容量规划。

确保包含 Azure API 管理的资源组与 API 管理实例本身位于同一位置，以减少相关区域中断影响访问网关资源提供程序能力的爆炸半径。

主动-主动网关 + 主动-被动 Azure OpenAI 变型

上一节通过提供主动-主动网关拓扑来说明网关的可用性。 此拓扑将主动-主动网关与经济高效的主动-被动 Azure OpenAI 拓扑相结合。 向网关添加主动-被动逻辑，将故障从基于 PTU 的部署转移到基于消耗的 Azure OpenAI 部署，可以显著提高工作负荷的可靠性。 此模型仍允许客户端使用 API 管理的内置 FQDN 路由解决方案进行基于性能的路由。

使用自定义编码网关

如果每个网关路由规则太复杂，团队无法将其视为合理的 API 管理策略，则需要部署和管理自己的解决方案。 此体系结构必须是网关的多区域部署，每个区域都有一个高度可用的缩放单元。 需要使用 Azure Front Door (Anycast) 或流量管理器 (DNS) 进行这些部署，通常使用基于延迟的路由和网关可用性的相应运行状况检查。

如果需要 Web 应用程序防火墙和公共 Internet 访问，请使用 Azure Front Door。 如果不需要 Web 应用程序防火墙，并且 DNS TTL 已足够，则使用流量管理器。 使用 Azure Front Door（或任何反向代理）将网关实例置于前面时，请确保网关不会被绕过。 在使用 Azure Front Door 时，使网关实例仅通过专用终结点可用，并在网关实现中添加对 X_AZURE_FDID HTTP 标头的验证。

将自定义网关中使用的每个区域的资源放在每个区域资源组中。 这样做可以缩小相关区域中断的爆炸半径，从而避免影响访问该区域网关资源提供程序的能力。

还可以考虑将网关逻辑实现与 API 管理本身配合使用，以获取 TLS、身份验证、运行状况检查或轮循机制负载均衡等 API 管理的其他优势。 这样做将把常见的“API 关注点”从网关中的自定义代码中转移出来，使网关专门处理 Azure OpenAI 实例和模型部署路由。

对于数据驻留符合性，请确保每个地缘政治边界都有自己独立的该体系结构部署，并且客户端只能访问其授权终结点。

避免为多个区域中的多个实例使用网关的原因

在需要数据驻留和合规的情况下，不要跨地缘政治区域实现统一的网关。 这样做会违反数据驻留要求。 在每个区域使用可单独寻址的网关，并按照前面章节中的指导进行操作。

如果不期望客户端在区域之间进行故障转移，并且你有能力为客户端提供一个特定的网关来使用，那么可以使用多个网关，每个区域一个网关，并按照前面章节中的指导进行操作。 不要将其他区域的可用性与包含网关的区域绑定为单一故障点。

如果模型和版本不是在网关公开的所有区域都可用，则不要实现统一网关。 客户端需要路由到同一模型和相同的模型版本。 对于多区域负载均衡和故障转移网关，需要选择一个在所有相关区域都可用的通用模型和模型版本。 有关详细信息，请参阅模型可用性。 如果无法对模型和模型版本进行标准化，网关的优势会受到限制。

一般建议

无论工作负荷需要哪种拓扑，在构建网关解决方案时，都需要考虑一些跨领域的建议。

有状态交互

当客户端使用 Azure OpenAI 的有状态功能（如助手 API）时，需要配置网关，以便在交互期间将客户端固定到特定后端。 这样做可以通过将实例数据存储在 Cookie 中来实现。 在这些方案中，请考虑将 Azure OpenAI API 响应（如 429）返回到固定客户端，而不是将其重定向到不同的 Azure OpenAI 实例。 这样做允许客户端显式地处理突然的不可用，而不是隐藏它并路由到没有历史记录的模型实例。

网关运行状况检查

无论拓扑如何，都需要考虑两个运行状况检查透视图。

如果网关是围绕轮询或严格执行服务可用性故障切换构建的，那么将需要一种使 Azure OpenAI 实例（或模型）脱离可用性状态的方法。 Azure OpenAI 不提供任何类型的运行状况检查终结点，因此无法预先知道它是否可以处理请求。 可以通过发送合成转换，但这会消耗模型容量。 除非有 Azure OpenAI 实例和模型可用性的另一个可靠信号源，否则网关可能假定 Azure OpenAI 实例已启动，然后在一段时间内处理 429、500、503 HTTP 状态代码，作为该实例或模型上未来请求的断路信号。 对于限制情况，请始终遵循在 Azure OpenAI API 响应中为断路逻辑中的 429 响应代码找到的 Retry-After 标头中的数据。 如果使用的是 Azure API 管理，请使用内置断路器功能进行评估。

客户端或工作负荷运营团队可能希望出于自己的路由或内省目的，在网关上公开运行状况检查。 如果使用 API 管理，则默认值 /status-0123456789abcdef 可能不够详细，因为它主要针对 API 管理网关实例，而不是后端。 请考虑添加专用运行状况检查 API，该 API可以向客户端或可观测性系统返回关于网关或网关中特定路由的可用性的有意义数据。

安全部署实践

可以使用网关实现来协调已更新模型的蓝/绿部署。 Azure OpenAI 模型更新为新模型版本和新模型，你可能有新的微调模型。

在测试预生产变更的影响后，评估生产客户端是应“切换”到新的模型版本，还是应该转移流量。 前面所述的网关模式允许后端同时部署这两个模型。 同时部署模型使网关能够根据工作负载团队的增量部署安全部署实践重定向流量。

即使不使用蓝/绿部署，也需要定义工作负荷的 APIOps 方法，并使其充分自动化，以配合后端实例和模型部署的变化速度。

实现就够了

本文中介绍的许多方案都是通过降低客户端复杂性和实现可靠的自我保护技术来帮助提高工作负荷的潜在服务级别目标 (SLO)。 其他方法通过将访问控制从 Azure OpenAI 转移到特定模型来提高工作负荷的安全性。 确保网关的引入不会最终与这些目标背道而驰。 了解通过网关中的服务故障或人为配置问题、复杂的路由逻辑添加新的单点故障的风险，或者向未经授权的客户端公开更多模型的风险。

数据主权

需要从工作负荷的数据驻留合规性角度来评估各种主动-主动和主动-被动方法。 如果所涉及的区域始终处于地缘政治边界内，那么其中许多模式将适用于工作负荷体系结构。 为了支持这一方案，需要将地缘政治边界视为独立印花，并在该印花中独占地应用主动-主动或主动-被动处理。

特别是，任何基于性能的路由都需要严格审核数据主权合规性。 在数据主权方案中，无法为具有其他地理位置的客户端提供服务并保持合规性。 涉及数据驻留的所有网关体系结构都必须强制客户端仅在其地缘政治区域中使用终结点。 必须阻止客户端使用其他网关终结点，并且网关本身不会通过发出跨地缘政治请求来违反客户端的信任。 实现此分段的最可靠方法是围绕每个地缘政治区域的一个完全独立、高度可用的网关构建体系结构。

Azure OpenAI 授权

网关需要与它所连接的所有 Azure OpenAI 实例进行身份验证。 除非将网关设计为进行直通身份验证（这种情况很少见），否则网关应该为其凭据使用托管标识。 因此，每个 Azure OpenAI 实例都需要为网关的托管标识配置最低特权 RBAC。 对于主动-主动和故障转移体系结构，请确保网关的标识在涉及的所有 Azure OpenAI 实例上都获得同等许可。

Azure Policy

在主动-主动或主动-被动的情况下，模型部署和 Azure OpenAI 实例之间的一致性很重要。 使用 Azure Policy 有助于在各种 Azure OpenAI 实例或模型部署之间强制实施一致性。 如果 Azure OpenAI 的内置策略不足以确保它们之间的一致性，请考虑创建或使用社区创建的自定义策略。

网关冗余

虽然并非特定于多个后端，但每个区域的网关实现应始终使用冗余生成，并在缩放单元中高度可用。 选择具有可用性区域的区域，并确保网关分布在这些区域。 部署网关的多个实例，以便单一故障点仅限于完全的区域中断，而不是由于网关中单个计算实例的故障。 对于 API 管理，在两个或多个区域部署两个或更多单元。 对于自定义代码实现，请至少部署三个实例，并尽最大努力跨可用性区域分布。

网关实现

Azure 既不提供统包解决方案，也不提供构建此类网关的参考体系结构。 如简介文章中所述，工作负荷团队必须生成和操作此网关。 下面是社区支持示例实现的一些示例，涵盖了前面提到的一些用例。 生成自己的概念证明时，请考虑参考这些 GitHub 示例。

实现	示例
Azure API 管理	使用 Azure API 管理实现 Azure OpenAI 的智能负载均衡 - 此 GitHub 存储库包含部署到订阅的示例策略代码和说明。 使用 Azure API 管理缩放 Azure OpenAI - 此 GitHub 存储库包含 PTU 和消耗溢出的示例策略代码和说明。 GenAI 网关工具包库中还有一些社区支持的 API 管理策略。
自定义代码	使用 Azure 容器应用实现 Azure OpenAI 的智能负载均衡 此 GitHub 存储库包含用于生成容器并部署到订阅中的示例 C# 代码和说明。

后续步骤

为工作负荷实现网关提供的好处，超出了本文中所述的战术性多个后端路由的好处。 了解网关可以解决的其他关键挑战。

相关资源

• Azure OpenAI 服务
• Azure API 管理中的 API 网关