category
Azure OpenAI服务暴露HTTP API,让您的应用程序通过使用OpenAI的语言模型来执行嵌入或完成。智能应用程序直接从客户端或协调器调用这些HTTP API。客户端的示例包括聊天UI代码和自定义数据处理管道。编排器的示例包括LangChain、Semantic Kernel和Azure机器学习提示流。当您的工作负载连接到一个或多个Azure OpenAI实例时,您必须决定这些消费者是直接连接还是通过反向代理API网关连接。
使用本指南了解Azure架构良好的框架的五大支柱中的关键挑战,如果您的工作负载设计包括消费者对Azure OpenAI数据平面API的直接访问,则会遇到这些挑战。然后了解在您的体系结构中引入网关如何帮助解决这些直接访问挑战,同时引入新的挑战。本文描述了体系结构模式,但没有描述如何实现网关。
因为网关可以用于解决可能不存在于每个工作负载中的特定场景,请参阅确保参阅特定场景指南,该指南更深入地研究了网关的特定用例。
主要挑战
如果没有API网关或向Azure OpenAI HTTP API添加逻辑的能力,客户端必须处理API客户端逻辑,其中包括重试机制或断路器。在不直接控制客户端代码的情况下,或者当代码仅限于特定的SDK使用时,这种情况可能会很有挑战性。多个客户端或多个Azure OpenAI实例和部署带来了进一步的挑战,例如安全部署和可观察性的协调。
本节提供了如果您的体系结构仅支持消费者直接访问Azure OpenAI,您可能面临的特定关键体系结构挑战的示例。这些挑战是通过使用Azure架构良好的框架支柱来组织的。
可靠性挑战
工作负载的可靠性取决于几个因素,包括其自我保护和自我恢复的能力,这些能力通常通过复制和故障切换机制来实现。如果没有网关,所有可靠性问题都必须通过使用客户端逻辑和Azure OpenAI服务功能来专门解决。当这两个表面中的任何一个都没有足够的可靠性控制时,工作负载的可靠性就会受到影响。
- 冗余:基于服务可用性在多个Azure OpenAI实例之间进行故障切换是客户端的责任,您需要通过配置和自定义逻辑进行控制。
- 扩展以处理峰值:当被抑制时,故障转移到具有容量的Azure OpenAI实例是您需要通过配置和自定义逻辑控制的另一项客户端责任。为新的Azure OpenAI实例更新多个客户端配置会带来更大的风险,并存在及时性问题。更新客户端代码以实现逻辑更改也是如此,例如在高需求时段将低优先级请求定向到队列。
- 负载平衡或限制:Azure OpenAI API通过向超过现收现付模式中的每分钟令牌(TPM)或每分钟请求(RPM)的请求返回HTTP 429错误响应代码来限制请求。Azure OpenAI API还抑制超过预配置计费模型的配置吞吐量单位(PTU)容量的请求。处理适当的回退和重试逻辑只留给客户端实现。
安全挑战
安全控制必须有助于保护工作负载的机密性、完整性和可用性。如果没有网关,所有安全问题都必须在客户端逻辑和Azure OpenAI服务功能中专门解决。工作负载需求可能比用于直接通信的客户端细分、客户端控制或服务安全功能所需的更多。
- 身份管理-身份验证范围:Azure OpenAI公开的数据平面API可以通过以下两种方式之一进行安全保护:API密钥或Azure基于角色的访问控制(RBAC)。在这两种情况下,身份验证都发生在Azure OpenAI实例级别,而不是单个部署级别,这会为特定部署模型提供最低权限访问和身份分割带来复杂性。
- 身份管理-身份提供程序:无法使用位于支持Azure OpenAI实例的Microsoft Entra租户中的身份的客户端必须共享一个完全访问的API密钥。API密钥具有安全实用性限制,并且当涉及多个客户端并且所有客户端都共享同一标识时会出现问题。
- 网络安全:根据客户端相对于Azure OpenAI实例的位置,可能需要对语言模型进行公共互联网访问。
- 数据主权:Azure OpenAI中的数据主权是指与特定国家或地区地理边界内的数据存储和处理相关的法律和监管要求。您的工作量需要确保区域亲和力,以便客户能够遵守数据驻留和主权法律。此过程涉及多个Azure OpenAI部署。
成本优化挑战
当体系结构最大限度地减少浪费并最大限度地发挥效用时,工作负载会受益。强大的成本建模和监控是任何工作负载的重要要求。在没有网关的情况下,PTU的利用率或每个客户端的成本跟踪可以完全通过聚合Azure OpenAI实例使用遥测来权威地实现。
- 成本跟踪:能够提供Azure OpenAI使用情况的财务视角仅限于从Azure OpenAI实例使用遥测中聚合的数据。当需要进行按存储容量使用计费或显示时,您需要将这种使用遥测归因于不同部门的各种客户,甚至多租户场景的客户。
- 预置吞吐量利用率:您的工作负载希望通过充分利用您支付的预置吞吐量来避免浪费。这意味着,在转移到任何基于消耗的模型部署之前,必须信任并协调客户端使用基于PTU的模型部署。
卓越运营挑战
如果没有网关,可观察性、更改控制和开发过程仅限于直接客户端到服务器通信所提供的内容。
- 配额控制:当HTTP API被抑制时,客户端直接从Azure OpenAI接收429个响应代码。工作负载操作员负责确保有足够的配额可供合法使用,并且行为不端的客户端不会过度消耗。当您的工作负载由多个模型部署组成时,很难直观地了解配额使用情况和配额可用性。
- 监控和可观察性:Azure OpenAI默认指标可通过Azure Monitor获得。然而,数据的可用性存在延迟,并且不能提供实时监控。
- 安全部署实践:您的LLMOps流程需要客户端和Azure OpenAI中部署的模型之间的协调。对于高级部署方法,如蓝绿色或金丝雀,需要在客户端处理逻辑。
性能效率挑战
如果没有网关,您的工作负载将责任推给客户端,让它们在有限的容量下单独表现良好,并与其他客户端公平相处。
- 性能优化-优先级流量:对客户端请求进行优先级排序,以便高优先级客户端优先访问低优先级客户端,这将需要广泛且可能不合理的客户端间协调。当模型利用率较低时,让低优先级请求排队运行可能会使某些工作负载受益。
- 性能优化-客户端合规性:要共享容量,客户端需要表现良好。例如,客户端确保将max_tokens和best_of设置为批准的值。如果没有网关,您必须信任客户端,以维护Azure OpenAI实例的容量的最大利益。
- 最大限度地减少延迟:虽然网络延迟通常是整个提示和完成请求流的一个小部分,但确保客户端路由到靠近它们的网络端点和模型可能是有益的。如果没有网关,客户端将需要自行选择要使用的模型部署端点,以及特定Azure OpenAI数据平面API所需的凭据。
解决方案
图显示了在智能应用程序和Azure OpenAI之间注入网关的概念架构。
该图显示了一个智能应用程序图标,其中箭头指向标记为gateway的虚线框。箭头穿过一条标记为“联合身份验证”的线,指向“速率限制器”图标。“速率限制器”有一个指向“路由器”图标的箭头。“路由器”有四个指向不同图标的箭头。第一个箭头指向“负载均衡器”,它指向两个区域和本地的“OpenAI部署”或“LLM”图标。第二个箭头指向“监控”图标,随后指向“成本”和“使用”图标。第三个箭头指向“计算”图标。第四个指向“消息队列”图标,然后指向“负载均衡器”
图1:通过网关访问Azure OpenAI的概念架构
为了解决关键挑战中列出的许多挑战,您可以注入反向代理网关,将智能应用程序与Azure OpenAI解耦。这种网关卸载使您能够将责任、复杂性和可观察性从客户端转移开,并通过提供其他未内置的功能来增强Azure OpenAI。例如:
- 有可能实现联合身份验证。
- 通过速率限制控制模型压力的能力。
- 跨领域和跨模型监测。
- 将网关聚合和高级路由引入多个服务的能力,例如将低优先级消息路由到队列以进行基于队列的负载均衡或计算以执行任务。
- 负载平衡,使用运行状况端点监视,通过在不可用或过载的模型部署上断路,仅路由到运行状况端点。
一些特定场景提供了更多指导,直接针对API网关和Azure OpenAI实例。下面的步骤部分列出了这些场景。
注意事项
当您将一个新组件引入到您的体系结构中时,您需要评估新引入的权衡。当您在客户端和Azure OpenAI数据平面之间注入API网关以解决任何关键挑战时,您会在架构中引入新的考虑因素。仔细评估跨这些体系结构考虑因素的工作负载影响是否证明网关的附加值或实用性是合理的。
可靠性
可靠性可确保您的应用程序满足您对客户的承诺。有关更多信息,请参阅可靠性的设计审查检查表。
- 网关解决方案可能会引入单点故障。此故障可能源于网关平台的服务可用性、代码或配置部署导致的中断,甚至网关中配置错误的关键API端点。确保您的实施设计能够满足工作负载的可用性要求。通过将网关包括在工作负载的故障模式分析中,考虑实现中的恢复能力和容错能力。
- 如果您的体系结构需要多个地区的Azure OpenAI实例,则您的解决方案可能需要全局路由功能。这种情况会通过管理额外的完全限定域名、TLS证书和更多的全局路由组件,使拓扑结构进一步复杂化。
重要的
如果这样做会危及您的工作负载满足商定的服务级别目标(SLO)的能力,请不要实现网关。
安全
当考虑API网关如何为您的体系结构带来好处时,请使用安全性的设计审查检查表来评估您的设计。您需要解决安全问题,例如以下方面:
- 工作负载的表面积随着网关的添加而增加。该表面积带来了对Azure资源的额外身份和访问管理(IAM)考虑,增加了强化工作,等等。
- 网关可以充当客户端网络空间和私有Azure OpenAI网络空间之间的网络边界转换。尽管该网关通过使用Azure私有链接将以前面向互联网的Azure OpenAI端点私有化,但它现在成为了新的入口点,必须得到充分的保护。
- 网关处于一个独特的位置,可以查看来自语言模型的原始请求数据和公式化响应,其中可能包括来自任一来源的机密数据。数据合规性和管理范围现在扩展到了另一个组件。
- 网关可以将客户端授权和身份验证的范围扩展到Microsoft Entra ID和API密钥身份验证之外,并可能扩展到多个身份提供商(IdP)。
- 在多区域实现中,必须将数据主权考虑在内。确保网关计算和路由逻辑符合工作负载的主权要求。
重要的
如果这样做会使您的工作负载无法保护其自身或用户数据的机密性、完整性或可用性,请不要实施网关。
成本优化
成本优化是指寻找减少不必要费用和提高运营效率的方法。有关更多信息,请参阅成本优化的设计审查检查表。
所有实现的API网关都有运行时成本,需要进行预算和核算。这些成本通常会随着网关本身的可靠性、安全性和性能的增加而增加,同时随着APIOps管理的增加,运营成本也会增加。这些增加的成本需要根据网关系统提供的新价值来衡量。您希望通过使用网关引入的新功能超过实现和维护网关的成本。根据您的工作负载与其用户的关系,您可能能够按使用量计费。
卓越运营
当考虑API网关如何为您的架构带来好处时,请使用卓越运营的设计审查清单来评估您的设计。您需要解决卓越运营方面的注意事项,如以下事项:
- 网关本身需要由工作负载的监控解决方案进行监控,也可能由客户端进行监控。这意味着网关计算和操作需要包含在工作负载的运行状况建模中。
- 您的安全部署实践现在需要解决API网关基础设施的部署以及网关路由的代码或配置。您的基础设施自动化和基础设施即代码(IaC)解决方案需要考虑如何将网关视为工作负载中的长期资源。
- 您需要构建或扩展您的APIOps方法,以覆盖网关中公开的API。
性能效率
当考虑API网关如何为您的体系结构带来好处时,请使用性能效率的设计审查检查表来评估您的设计。您需要解决以下性能效率方面的注意事项:
- 网关服务可能会引入吞吐量瓶颈。确保网关具有足够的性能来处理全部并发负载,并且可以根据您的增长预期轻松扩展。确保解决方案的弹性,以便网关可以在需求较低时(如工作日使用量)减少供应或缩减规模。
- 网关服务具有每个请求必须执行的处理,并且每个API调用都会增加延迟。您应该优化路由逻辑以保持请求的良好性能。
- 在大多数情况下,网关应在地理位置上靠近用户和Azure OpenAI实例,以减少延迟。虽然在API对语言模型的总体调用中,网络延迟通常只占很小的一部分时间,但它可能是您工作负载的一个竞争因素。
- 评估网关对Azure OpenAI功能的影响,如流式响应或有状态交互的实例钉扎,如助理API。
重要的
如果这样做会导致无法实现协商的性能目标或在其他权衡上过于妥协,则不要实现网关。
实施选项
Azure不提供专门为代理Azure OpenAI的HTTP API或其他自定义语言模型推理API而设计的交钥匙解决方案。但您的工作负载团队仍有几个选项需要实现,例如Azure中的网关。
使用Azure API管理
Azure API管理是一项平台管理服务,旨在减轻基于HTTPAPI的交叉问题。它是配置驱动的,并通过其入站和出站请求处理策略系统支持自定义。它通过使用单个控制平面来支持高可用性、区域冗余甚至多区域复制。
大多数网关路由和请求处理逻辑必须在API管理的策略系统中实现。您可以组合内置策略,如限制Azure OpenAI API令牌使用或发出Azure OpenAI令牌消费指标,以及您自己的自定义策略。一些示例自定义策略和场景可以在API管理网关工具包社区GitHub存储库中找到。
在设计涉及Azure API管理的解决方案时,请使用API管理的Well-Archited Framework服务指南。
使用Azure API管理实现网关通常是构建和操作Azure OpenAI网关的首选方法。之所以选择它,是因为该服务是一种平台即服务(PaaS),具有丰富的内置功能、高可用性和网络选项。它还具有强大的APIOps方法来管理您的完成API。
使用自定义代码
自定义代码方法要求软件开发团队创建自定义编码的解决方案,并将该解决方案部署到他们选择的Azure应用程序平台。构建一个自管理的解决方案来处理网关逻辑非常适合精通管理网络和路由代码的工作负载团队。
工作负载通常可以使用他们熟悉的计算,例如在Azure应用程序服务、Azure容器应用程序或Azure Kubernetes服务上托管网关代码。
当API管理专门用于客户端和自定义代码之间的核心HTTP API网关功能时,也可以使用API管理进行自定义代码部署。通过这种方式,您的自定义代码基于必要的业务逻辑专门与Azure OpenAI HTTP API对接。
使用非Microsoft网关技术,这是一种非Azure本地提供的产品或服务,可以被视为这种方法的一部分。
示例架构
该图显示了在智能应用程序和Azure OpenAI之间注入网关的示例架构。
该图显示了一个智能应用程序图标,箭头指向两个Azure API管理图标,其中一个仅为网关。图标的箭头指向一个区域中的两个Azure OpenAI图标和另一个区域的一个图标。其中一个Azure API管理图标有一个标记为“批处理请求”的箭头,指向Azure事件中心。同一个图标有一个箭头,指向带有标记为计算服务的箭头的Azure功能。Azure函数有一个指向API管理的箭头,带有标签Replay批处理请求,还有一个指向Azure事件中心的箭头,标签batched请求。Microsoft Entra ID图标、Azure Traffic Manager图标以及Application Insights和Azure Monitor图标位于图的底部。
图2:通过基于Azure API管理的网关访问Azure OpenAI的示例架构
接下来的步骤
了解在智能应用程序和Azure OpenAI部署之间部署网关用于满足工作负载要求的特定场景:
- 多个后端实例之间的负载平衡或故障切换
- 客户端应用程序的自定义身份验证和授权
了解如何实现Azure OpenAI模型的日志记录和监控。
相关资源
- Azure OpenAI Service
- API gateway in Azure API Management
- API Management landing zone accelerator covering generative AI scenarios
- API Management gateway toolkit
- 登录 发表评论
- 12 次浏览
Tags
最新内容
- 1 week ago
- 1 week ago
- 1 week ago
- 1 week ago
- 1 week ago
- 1 week 6 days ago
- 1 week 6 days ago
- 2 weeks 2 days ago
- 2 weeks 2 days ago
- 2 weeks 2 days ago