【生成式AI】在多个Azure OpenAI部署或实例前使用网关

涉及Azure OpenAI服务的工作负载架构可以简单到一个或多个客户端应用程序直接消耗单个Azure OpenAI模型部署，但并非所有工作负载都可以如此简单地设计。更复杂的场景包括具有多个客户端的拓扑结构、多个Azure OpenAI部署或多个Azure Open AI实例。在这些情况下，在Azure OpenAI前面引入网关可能有利于工作负载的设计。

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

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

这些拓扑本身并不需要使用网关。网关的选择取决于工作负载是否从其包含在体系结构中获益。本文描述了四种拓扑中的每一种都要解决的挑战，以及在每个拓扑中包含网关的好处和成本。

提示

除非另有说明，以下指南适用于基于Azure API管理的网关或自定义代码网关。在大多数情况下，体系结构图通常表示网关组件来说明这一点。

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

客户端连接到Azure OpenAI中的多个模型部署的场景的架构图。

一张图显示了标记为A和B的两个客户端与名为rg aoai eastus的资源组中的Azure OpenAI实例直接接口。Azure OpenAI实例有四个模型部署。客户端A具有指向gpt-4型号和gpt-35-turbo型号的实心箭头。客户端B具有指向不同gpt-35-turbo模型的实线，并且具有指向另一个gpt-35-turbo部署的虚线箭头。

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

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

多个模型部署的拓扑用例

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

• 展示不同的型号功能，如gpt-35-turbo、gpt-4和自定义微调型号。
• 公开不同的模型版本，如0613、1106和自定义微调模型，以支持工作负载演变或蓝绿色部署。
• 公开分配的不同配额（30000个每分钟令牌（TPM）、60000个TPM），以支持跨多个客户端的消耗限制。

为多个模型部署引入网关

一个场景的架构图，显示客户端通过网关连接到Azure OpenAI中的多个模型部署。

显示标记为A和B的两个客户端直接与网关接口的示意图。网关有一个指向专用端点的箭头，该箭头有四个箭头，从专用端点指向名为rg aoai eastus的资源组中的Azure OpenAI实例。其中三个箭头是实心的，指向三种不同的型号部署，分别标记为gpt-4、gpt-35-turbo和gpt-35-turbo。其中一个箭头是虚线，指向另一个gpt-35-turbo部署。

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

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

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

提示

由于API密钥和Azure基于角色的访问控制（RBAC）应用于Azure OpenAI实例级别，而不是模型部署级别，因此在此场景中添加网关可以将安全性转移到网关。然后，网关在并行部署的模型之间提供额外的分段，否则无法通过Azure OpenAI的身份和访问管理（IAM）或IP防火墙进行控制。

在此拓扑中使用网关允许基于客户端的使用情况跟踪。除非客户端使用不同的Microsoft Entra服务主体，否则Azure OpenAI的访问日志将无法区分多个客户端。在部署之前有一个网关，使您的工作负载有机会跟踪各种可用模型部署中每个客户端的使用情况，以支持按存储容量使用计费或展示模型。

多模型部署拓扑的提示

• 
  虽然网关可以完全更改正在使用的型号，例如gpt-35-turbo到gpt-4，但这种更改可能会被视为对客户端的突破性更改。不要让网关的新功能分散对始终为此工作负载执行安全部署实践的注意力。
• 这种拓扑结构通常足够简单，可以通过Azure API管理策略而不是自定义代码解决方案来实现。
• 若要使用已发布的Azure OpenAI API规范支持本机SDK的使用，请保持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 Private Link专用端点的子网。将网络安全组（NSG）规则应用于该子网，以仅允许网关访问该专用端点。应禁止对Azure OpenAI实例的所有其他数据平面访问。

避免使用网关进行多个模型部署的原因

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

此外，一些工作负载场景可以从多模型部署方法迁移到多Azure OpenAI实例部署方法中受益。例如，如果你有多个客户端应该使用不同的RBAC或访问密钥来访问它们的模型，那么考虑多个Azure OpenAI实例。在单个Azure OpenAI实例中使用多个部署并在网关级别处理逻辑身份分割是可能的，但当通过使用不同的Azure OpenAI示例可以使用物理RBAC分割方法时，这可能会过多。

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

客户端连接到单个区域中多个Azure OpenAI实例的场景的架构图。

一张图显示了标记为A和B的两个客户端直接与三个Azure OpenAI实例接口，每个实例都有一个标记为gpt-4的模型。所有Azure OpenAI实例都在一个名为rg aoai eastus的资源组中。客户端A有一个实心箭头，将其连接到客户端A实例中的gpt-4，该实例表示PTU。客户端A有一个虚线箭头，将其连接到客户端A实例中的gpt-4，该实例表示消费溢出。客户端B有一个实心箭头，将其连接到客户端B实例中的gpt-4，该实例表示PTU。

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

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

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

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

• 启用安全分段边界，例如每个客户端的密钥或RBAC
• 为不同的客户端实现简单的按存储容量使用计费模式
• 为Azure OpenAI可用性启用故障切换策略，例如影响特定实例的平台中断、网络错误配置或意外删除的部署
• 为Azure OpenAI配额可用性启用故障切换策略，例如将基于PTU的实例和基于消耗的实例配对以进行溢出

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

客户端通过网关连接到单个区域中多个Azure OpenAI实例的场景的架构图。

显示标记为A和B的两个客户端与网关直接接口的示意图。网关有三个箭头从它指向私有端点。两个箭头是实心的，一个是虚线。每个私有端点都连接到一个不同的Azure OpenAI实例，每个实例中都有一个gpt-4模型。实例标记为客户端A（PTU）、客户端A（消耗）、客户端B（PTU）。

由于以下几个原因，客户端可能无法访问模型。这些原因包括Azure OpenAI服务中断、Azure OpenAI节流请求，或与工作负载操作相关的问题，如网络配置错误或无意删除模型部署。为了解决这些挑战，您应该实现重试和断路逻辑。

该逻辑可以在网关的客户端或服务器端实现。在网关中实现逻辑将逻辑从客户端抽象出来，这样就没有重复的代码，也没有一个地方可以测试逻辑。无论您是否拥有客户端代码，这种转变都可以提高工作负载的可靠性。

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

笔记

基于消耗的配额是订阅级别，而不是Azure OpenAI实例级别。针对同一订阅中基于消耗的实例进行负载平衡并不能实现额外的吞吐量。

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

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

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

• 确保网关在支持网关故障转移场景时，使用Azure OpenAI的HTTP响应中可用的“重试之后”信息。使用这些权威信息来控制断路器的实施。不要连续命中返回429TooMany请求的端点。相反，断开该模型实例的电路。
• 在网关中，可以通过跟踪先前请求的模型消耗来尝试在节流事件发生之前预测节流事件，但这充满了边缘情况。在大多数情况下，最好不要尝试预测，而是使用HTTP响应代码来驱动未来的路由决策。
• 当轮询或故障转移到不同的端点时，包括PTU溢出到消耗中时，始终确保这些端点在同一版本中使用相同的型号。例如，不要从gpt-4故障切换到gpt-35-turbo，也不要从版本X故障切换到版本X+1，或者它们之间的负载平衡。此版本更改可能会导致客户端出现意外行为。
• 负载平衡和故障转移逻辑可在Azure API管理策略中实现。使用基于代码的网关解决方案，您可能能够提供更复杂的方法，但API管理足以满足此用例。
• 将您的网关部署在与Azure OpenAI实例相同的区域中。
• 将网关部署到订阅中独立于Azure OpenAI实例的专用资源组中。将网关与后端隔离有助于通过关注的分离来推动APIOps方法。
• 将所有Azure OpenAI实例私有链接私有端点合并到网关虚拟网络上的单个子网中。将NSG规则应用于该子网，以仅允许网关访问这些私有端点。应禁止对Azure OpenAI实例的所有其他数据平面访问。
• 为了简化网关路由代码中的逻辑，请使用相同的模型部署名称来最小化HTTP路由之间的差异。例如，型号名称gpt4-v1可以用于所有负载平衡或溢出实例，无论是基于消耗还是基于PTU。

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

网关本身并不能提高针对该特定拓扑的不同客户端按存储容量使用计费模型的能力。在这种拓扑结构中，客户端可以被授予访问其自己的专用Azure OpenAI实例的权限，这将支持您的工作负载团队执行按存储容量使用计费或显示的能力。该模型支持唯一的身份和网络周长，因此不需要专门为分段引入网关。

如果您在控制代码的区域中有几个客户端，并且这些客户端很容易更新，那么您必须在网关中构建的逻辑可以直接添加到代码中。当您不拥有客户端代码或复杂性太大，客户端无法处理时，请主要考虑使用网关方法进行故障切换或负载平衡。

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

场景的架构图一个客户端连接到两个Azure OpenAI实例，每个区域一个。

一张图显示了一个客户端，其实心箭头指向标记为Primary的Azure OpenAI实例中的gpt-35-turbo（消耗）部署。此主要实例位于标记为Workload subscription a的框中。客户端还有一个虚线箭头，指向标记为Secondary的Azure OpenAI实例中的gpt-35-turbo（消耗）部署。此辅助实例位于标记为Workload subscription B的框中。在这两个订阅中，包含Azure OpenAI实例的资源组都称为rg aoai eastus。

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

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

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

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

• 包括为单个区域和单个订阅中的多个Azure OpenAI实例列出的所有用例。
• 使您能够获得更多基于消耗的配额，因为订阅边界是消耗模型的一个可用因素。您可以使用此额外配额来支持高并发消耗。

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

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

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

一个场景的架构图，其中一个客户端通过网关间接连接到两个Azure OpenAI实例，每个区域一个。

显示客户端的图，其中有一个指向网关的实心箭头。名为rg gateway eastus的资源组中的网关，包含在标记为Workload gateway subscription的框中。网关连接到与网关位于同一资源组中的两个专用端点。一个私有端点指向标记为Primary的Azure OpenAI实例中的gpt-35-turbo（消耗）部署。此主要实例位于标记为Workload subscription a的框中。第二个专用端点是一个虚线箭头，指向标记为Secondary的Azure OpenAI实例中的gpt-35-turbo（消耗）部署。此辅助实例位于标记为Workload subscription B的框中。在这两种情况下，包含Azure OpenAI实例的资源组都称为rg aoai eastus。

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

• 
  理想情况下，所有订阅都应该由相同的Microsoft Entra租户支持，以支持Azure RBAC和Azure策略的一致性。
• 将您的网关部署在与Azure OpenAI实例相同的区域中。
• 将网关部署到独立于Azure OpenAI实例的专用订阅中。这有助于在解决Azure OpenAI实例方面加强一致性，并在Azure OpenAI部署及其路由之间提供职责的逻辑分割。
• 在订阅之间路由来自网关的请求时，请确保专用端点是可访问的。您可以使用通过集线器到各自轮辐中后端的专用端点的可传递路由。您可以通过使用订阅之间的私有链接连接，直接在网关订阅中公开Azure OpenAI服务的私有端点。如果您的体系结构和组织支持这种方法，则首选交叉订阅专用链接连接。

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

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

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

 

三个架构图客户端连接到不同地区的Azure OpenAI实例。

一张图中有三个体系结构图。在左上角，它显示了一个客户端连接到美国西部的Azure OpenAI实例和一个美国东部的客户端，这意味着一种主动-主动负载平衡的情况。这两个实例都有gpt-4（消耗）部署。在右上角，情况也是如此，只是这意味着美国西部的例子是被动的。美国东部的gpt-4实例具有标签PTU，而美国西部的gpt-3实例具有标签Consumption。在中间的底部有两个地区，美国东部和德国中西部。图中显示的是一个美国客户连接到美国东部的PTU gpt-4型号。图中显示了一个德国客户连接到德国中西部的PTU gpt型号。

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

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

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

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

• 包括在多个订阅的单个区域中为多个Azure OpenAI实例列出的所有用例。
• 为服务可用性启用故障切换策略，例如使用跨区域对。
• 实现数据驻留和法规遵从性设计。
• 实现混合型号可用性。有些地区有不同的型号和不同的型号配额。

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

为多个地区的多个实例引入网关

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

跨区域的负载平衡并不常见，但可以战略性地用于跨区域基于消耗的部署中的可用配额组合。这种情况不要求网关不受区域中断的影响，但为了最大限度地提高工作负载可靠性，我们建议您这样做。

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

连接到美国西部和东部Azure OpenAI实例的客户端的架构图。

显示客户端连接到API管理实例的体系结构图。该API管理实例位于一个名为rg-gateway的资源组中，该资源组被标识为位于美国西部。该API管理实例连接到两个私有端点。一个私有端点位于美国西部地区一个名为rg aoai westus的资源组中。另一个私有端点位于美国东部地区一个名为rg aoai eastus的资源组中。rg aoai westus和rg aoai east资源组也包含自己的Azure OpenAI实例，均标记为Active，每个实例都有gpt-4消耗部署。

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

您的网关必须遵守来自Azure OpenAI实例的节流和可用性信号，并从池中删除出现故障的后端，直到可以安全读取出现故障或节流的Azure OpenAI示例为止。发生故障时，网关应针对池中的另一个后端实例重试当前请求，然后返回网关错误。当没有可用的后端Azure OpenAI实例时，网关的健康检查应该是不健康的信号。

笔记

此网关在您的体系结构中引入了全局单点区域故障，因为网关实例上的任何服务中断都会导致所有区域无法访问。不要将此拓扑用于业务关键型工作负载或基于客户端的负载平衡足够的情况。

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

警告

如果Azure OpenAI区域跨越地缘政治边界，则这种方法不能用于涉及数据主权合规的场景。

主动-被动变体

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

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

客户端通过位于每个地区的网关连接到美国西部和东部的Azure OpenAI实例的架构图。

一个体系结构图，显示了一个客户端连接到两个API管理网关，并带有一个注释“内置API管理FQDN（使用基于性能的路由）”。API管理实例位于名为rg-gateway-westus的资源组中，但在美国西部和东部都有一个网关，处于活动拓扑中。每个网关都有一个指向单个专用端点的箭头。每个私有端点都指向同一区域中的单个Azure OpenAI实例。每个Azure OpenAI实例都部署了一个gpt-4（PTU）模型。

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

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

笔记

从流量处理的角度来看，该拓扑结构没有全局故障点，但由于Azure API管理控制平面仅位于单个区域，因此该架构部分存在单个故障点。评估控制平面限制是否可能违反您的业务或关键任务标准。

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

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

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

如果某个区域正在经历API管理网关中断或被标记为不健康，则剩余的可用区域需要吸收来自其他区域的100%流量。这意味着您需要过度调配基于PTU的Azure OpenAI实例来处理新的流量爆发，或者使用主动-被动方法进行故障切换。使用Azure OpenAI容量计算器进行容量规划。

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

警告

如果任一网关区域跨越地缘政治边界，则这种方法不能用于涉及数据驻留合规性的场景。

主动-主动网关加上主动-被动Azure OpenAI变体

客户端通过位于每个地区的网关连接到美国西部和东部的Azure OpenAI实例的架构图，这些网关可以与其他地区的实例进行对话。

一个体系结构图显示了一个客户端连接到两个API管理网关，并带有一个注释，上面写着“内置API管理FQDN（使用基于性能的路由）”。API管理实例位于一个名为rg-gateway-westus的资源组中，但在美国西部和东部都有一个网关，处于活动拓扑中。每个网关都有一个指向同一区域中的主动专用端点的箭头和一个指向另一区域中被动专用端点的虚线箭头。只有两个专用端点，因此主动端点是另一个网关的被动端点。私有端点每个都指向其自己区域中Azure OpenAI实例中的活动gpt-4（PTU）模型。Private Endpoint还指向其所在地区的被动gpt-4（消费）模型。

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

警告

如果任何一个地区跨越地缘政治边界，这种主动-主动+主动-被动的方法都不能用于涉及数据驻留合规的场景。

使用自定义编码网关

客户端通过位于每个地区的全局负载均衡器和自定义网关连接到美国西部和东部的Azure OpenAI实例的架构图，这些网关可以与其他地区的实例进行对话。

一个架构图，显示客户端通过Azure Container Apps图标连接到两个网关计算实例，但通过Azure Front Door或DNS和Traffic Manager。这两个网关实例分别位于各自的资源组中，分别在美国西部和东部地区称为rg gateway westus和rg gateway eastus。每个网关都有一个指向同一区域中的主动专用端点的箭头和一个指向另一区域中被动专用端点的虚线箭头。只有两个专用端点，因此主动端点是另一个网关的被动端点。每个专用端点都指向其所在区域中Azure OpenAI实例中的活动gpt-4（PTU）模型。Private Endpoint还指向其所在地区的被动gpt-4（消费）模型。

如果您的通道路由规则过于复杂，您的团队无法将其视为合理的API管理策略，则需要部署和管理您自己的解决方案。此体系结构必须是网关的多区域部署，每个区域有一个高可用的扩展单元。您需要使用Azure front Door（Anycast）或Azure Traffic Manager（DNS）来引导这些部署，通常是通过使用基于延迟的路由和适当的网关可用性健康检查。

如果您需要web应用程序防火墙和公共互联网访问，请使用Azure Front Door。如果您不需要web应用程序防火墙并且DNS TTL就足够了，请使用流量管理器。使用Azure Front Door（或任何反向代理）引导网关实例时，请确保网关不会被绕过。当您使用Azure Front Door时，使网关实例仅通过专用端点可用，并在网关实现中添加X_Azure_FDID HTTP标头的验证。

将自定义网关中使用的按地区资源放在按地区资源组中。这样做可以减少相关区域中断的爆炸半径，从而影响您访问该区域网关资源的资源提供商的能力。

您还可以考虑使用API管理来实现网关逻辑，以获得API管理的其他好处，如TLS、身份验证、健康检查或round-robin负载平衡。这样做可以将常见的API问题从网关中的自定义代码中转移出来，并让网关专门处理Azure OpenAI实例和模型部署路由。

对于数据驻留合规性，请确保每个地缘政治边界都有自己的独立部署，并且客户端只能到达其授权的端点。

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

当需要数据驻留和合规性时，不要跨地缘政治区域实施统一网关。这样做将违反数据驻留要求。每个区域使用可单独寻址的网关，并遵循前一节中的指导。

如果客户端不希望在区域之间进行故障切换，并且您能够为客户端提供一个特定的网关供其使用，那么请使用多个网关，每个区域一个，并遵循前面部分中的指导。不要将其他区域的可用性与包含网关的区域绑定为单一故障点。

如果您的模型和版本不是在网关公开的所有区域都可用，则不要实现统一网关。客户端需要路由到相同的型号和相同的型号版本。对于多区域负载平衡和故障切换网关，您需要选择在所有相关区域都可用的通用模型和模型版本。有关详细信息，请参见型号可用性。如果不能对模型和模型版本进行标准化，那么网关的好处是有限的。

一般性建议

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

有状态的交互

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

网关运行状况检查

无论拓扑结构如何，都有两个健康检查视角需要考虑。

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

您的客户或您的工作负载操作团队可能希望在您的网关上进行健康检查，以用于他们自己的路由或自省目的。如果使用API管理，则默认的/status-0123456789abdef可能不够详细，因为它主要针对API管理网关实例，而不是后端。考虑添加一个专门的健康检查API，该API可以向客户端或观察性系统返回关于网关或网关中特定路由的可用性的有意义的数据。

安全部署实践

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

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

即使您不使用蓝绿色部署，也需要定义工作负载的APIOps方法，并根据后端实例和模型部署的变化率进行充分自动化。

实施就足够了

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

数据主权

需要从工作负载的数据驻留合规性角度来评估各种主动-主动和主动-被动方法。如果所涉及的区域仍在地缘政治边界内，其中许多模式将适用于您的工作负载架构。为了支持这种情况，您需要将地缘政治边界视为孤立的印记，并仅在该印记内应用主动-主动或主动-被动处理。

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

Azure OpenAI授权

网关需要通过与其接口的所有Azure OpenAI实例进行身份验证。除非您将网关设计为进行直通身份验证，否则网关应使用托管标识作为其凭据。因此，每个Azure OpenAI实例都需要为网关的托管身份配置权限最低的RBAC。对于主动-主动和故障切换架构，请确保网关的标识在所有涉及的Azure OpenAI实例中具有同等权限。

Azure策略

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

网关冗余

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

网关实施

Azure没有为构建这样的网关提供交钥匙解决方案或参考体系结构。正如介绍文章中所提到的，您的工作负载团队必须构建和操作此网关。以下是一些社区支持的示例实现，涵盖了前面提到的一些用例。在构建自己的概念验证时，请考虑参考这些GitHub示例。

Implementation	Example
Azure API Management	Smart load balancing for Azure OpenAI using Azure API Management - This GitHub repo contains sample policy code and instructions to deploy into your subscription. Scaling Azure OpenAI using Azure API Management - This GitHub repo contains sample policy code and instructions for PTU and consumption spillover. There are also some community supported API Management policies in the GenAI gateway toolkit repository.
Custom code	Smart load balancing for Azure OpenAI using Azure Container Apps This GitHub repo contains sample C# code and instructions to build the container and deploy into your subscription.

接下来的步骤

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

相关资源

• Azure OpenAI Service
• API gateway in Azure API Management
• Azure OpenAI API Management policies