O Serviço OpenAI do Azure expõe APIs HTTP que permitem que seus aplicativos executem incorporações ou completações usando os modelos de linguagem da OpenAI. Aplicativos inteligentes chamam essas APIs HTTP diretamente de clientes ou orquestradores. Exemplos de clientes incluem código de interface do usuário de chat e pipelines de processamento de dados personalizados. Exemplos de orquestradores incluem LangChain, Kernel Semântico e fluxo de prompt do Azure Machine Learning. Quando sua carga de trabalho se conecta a uma ou mais instâncias do Azure OpenAI, você deve decidir se esses consumidores se conectam diretamente ou por meio de um gateway de API de proxy reverso.
Use este guia para saber mais sobre os principais desafios nos cinco pilares do Azure Well-Architected Framework que você encontrará se seu design de carga de trabalho incluir acesso direto de seus consumidores às APIs do plano de dados do Azure OpenAI. Em seguida, saiba como a introdução de um gateway em sua arquitetura pode ajudar a resolver esses desafios de acesso direto, ao mesmo tempo em que introduz novos desafios. Este artigo descreve o padrão de arquitetura, mas não como implementar o gateway.
Como um gateway pode ser usado para resolver cenários específicos que podem não estar presentes em todas as cargas de trabalho, consulte Certifique-se de ver Orientação de cenário específico, que analisa esse caso de uso específico de um gateway com mais profundidade.
Principais desafios
Sem um gateway de API ou a capacidade de adicionar lógica às APIs HTTP do Azure OpenAI, o cliente precisa lidar com a lógica do cliente de API, que inclui mecanismos de repetição ou disjuntores. Essa situação pode ser desafiadora em cenários nos quais você não controla diretamente o código do cliente ou quando o código é restrito ao uso específico do SDK. Vários clientes ou várias instâncias e implantações do Azure OpenAI apresentam desafios adicionais, como a coordenação de implantações seguras e a observabilidade.
Esta seção fornece exemplos dos principais desafios de arquitetura específicos que você pode enfrentar se sua arquitetura oferecer suporte apenas ao acesso direto dos consumidores ao Azure OpenAI. Os desafios são organizados usando os pilares do Azure Well-Architected Framework.
Desafios de confiabilidade
A confiabilidade da carga de trabalho depende de vários fatores, incluindo sua capacidade de autopreservação e autorecuperação, que geralmente são implementados por meio de mecanismos de replicação e failover. Sem um gateway, todas as preocupações de confiabilidade devem ser resolvidas exclusivamente usando a lógica do cliente e os recursos do Serviço OpenAI do Azure. A confiabilidade da carga de trabalho é comprometida quando não há controle de confiabilidade suficiente disponível em qualquer uma dessas duas superfícies.
Redundância: o failover entre várias instâncias do Azure OpenAI com base na disponibilidade do serviço é uma responsabilidade do cliente que você precisa controlar por meio da configuração e da lógica personalizada.
Dimensionar para lidar com picos: fazer failover para instâncias do Azure OpenAI com capacidade quando limitado é outra responsabilidade do cliente que você precisa controlar por meio de configuração e lógica personalizada. A atualização de várias configurações de cliente para novas instâncias do Azure OpenAI apresenta maior risco e tem preocupações de pontualidade. O mesmo vale para atualizar o código do cliente para implementar alterações na lógica, como direcionar solicitações de baixa prioridade para uma fila durante períodos de alta demanda.
Balanceamento de carga ou limitação: as APIs do Azure OpenAI limitam as solicitações retornando um código de resposta de erro HTTP 429 para solicitações que excedem o Token por Minuto (TPM) ou Solicitações por Minuto (RPM) no modelo de pagamento conforme o uso. As APIs do Azure OpenAI também limitam as solicitações que excedem a capacidade de unidades de taxa de transferência provisionadas (PTU) para o modelo de cobrança pré-provisionado. A manipulação da lógica de back-off e repetição apropriada é deixada exclusivamente para as implementações do cliente.
Desafios de segurança
Os controles de segurança devem ajudar a proteger a confidencialidade, a integridade e a disponibilidade da carga de trabalho. Sem um gateway, todas as preocupações de segurança devem ser abordadas exclusivamente na lógica do cliente e nos recursos do Serviço OpenAI do Azure. Os requisitos de carga de trabalho podem exigir mais do que o que está disponível para segmentação de clientes, controle de clientes ou recursos de segurança de serviço para comunicação direta.
Gerenciamento de identidade - escopo de autenticação: as APIs do plano de dados expostas pelo Azure OpenAI podem ser protegidas de duas maneiras: chave de API ou RBAC (controle de acesso baseado em função) do Azure. Em ambos os casos, a autenticação acontece no nível de instância do Azure OpenAI, não no nível de implantação individual, que introduz complexidade para fornecer acesso menos privilegiado e segmentação de identidade para modelos de implantação específicos.
Gerenciamento de identidades - provedores de identidade: os clientes que não podem usar identidades localizadas no locatário do Microsoft Entra que está dando suporte à instância do Azure OpenAI devem compartilhar uma única chave de API de acesso total. As chaves de API têm limitações de utilidade de segurança e são problemáticas quando vários clientes estão envolvidos e todos compartilham a mesma identidade.
Segurança de rede: Dependendo da localização do cliente em relação às suas instâncias do Azure OpenAI, o acesso público à Internet para modelos de linguagem pode ser necessário.
Soberania de dados: a soberania de dados no contexto do Azure OpenAI refere-se aos requisitos legais e regulamentares relacionados com o armazenamento e processamento de dados dentro dos limites geográficos de um país ou região específicos. Sua carga de trabalho precisa garantir afinidade regional para que os clientes possam cumprir as leis de residência e soberania de dados. Esse processo envolve várias implantações do Azure OpenAI.
Desafios de otimização de custos
As cargas de trabalho se beneficiam quando as arquiteturas minimizam o desperdício e maximizam a utilidade. Forte modelagem e monitoramento de custos são um requisito importante para qualquer carga de trabalho. Sem um gateway, a utilização da PTU ou o rastreamento de custos por cliente pode ser obtido de forma autoritária exclusivamente a partir da agregação da telemetria de uso da instância do Azure OpenAI.
Acompanhamento de custos: ser capaz de fornecer uma perspetiva financeira sobre o uso do Azure OpenAI é limitado aos dados agregados da telemetria de uso da instância do Azure OpenAI. Quando necessário para fazer estorno ou show-back, você precisa atribuir essa telemetria de uso com vários clientes em diferentes departamentos ou até mesmo clientes para cenários multilocatário.
Utilização da taxa de transferência provisionada: sua carga de trabalho deseja evitar desperdício utilizando totalmente a taxa de transferência provisionada pela qual você pagou. Isso significa que os clientes devem ser confiáveis e coordenados para usar implantações de modelo baseadas em PTU antes de se espalharem para qualquer implantação de modelo baseado em consumo.
Desafios da excelência operacional
Sem um gateway, a observabilidade, o controle de alterações e os processos de desenvolvimento são limitados ao que é fornecido pela comunicação direta cliente-servidor.
Controle de cota: os clientes recebem 429 códigos de resposta diretamente do Azure OpenAI quando as APIs HTTP são limitadas. Os operadores de carga de trabalho são responsáveis por garantir que uma cota suficiente esteja disponível para uso legítimo e que os clientes que se comportam mal não consumam em excesso. Quando sua carga de trabalho consiste em várias implantações de modelo, entender o uso e a disponibilidade de cotas pode ser difícil de visualizar.
Monitorização e observabilidade: as métricas predefinidas do Azure OpenAI estão disponíveis através do Azure Monitor. No entanto, há latência com a disponibilidade dos dados e não fornece monitoramento em tempo real.
Práticas de implantação seguras: seu processo LLMOps requer coordenação entre os clientes e os modelos implantados no Azure OpenAI. Para abordagens avançadas de implantação, como azul-verde ou canário, a lógica precisa ser manipulada no lado do cliente.
Desafios da eficiência de desempenho
Sem um gateway, sua carga de trabalho coloca a responsabilidade sobre os clientes para serem individualmente bem comportados e se comportarem de forma justa com outros clientes contra a capacidade limitada.
Otimização de desempenho - tráfego prioritário: priorizar solicitações de clientes para que clientes de alta prioridade tenham acesso preferencial sobre clientes de baixa prioridade exigiria uma coordenação extensa, e provavelmente irrazoável, cliente a cliente. Algumas cargas de trabalho podem se beneficiar de ter solicitações de baixa prioridade enfileiradas para execução quando a utilização do modelo é baixa.
Otimização de desempenho - conformidade com o cliente: Para compartilhar capacidade, os clientes precisam ser bem comportados. Um exemplo disso é quando os clientes garantem que
max_tokensebest_ofsão definidos como valores aprovados. Sem um gateway, você deve confiar nos clientes para agir no melhor interesse de preservar a capacidade de sua instância do Azure OpenAI.Minimizar a latência: Embora a latência da rede seja geralmente um pequeno componente do fluxo geral de solicitações de solicitação e conclusão, garantir que os clientes sejam roteados para um ponto de extremidade de rede e um modelo próximo a eles pode ser benéfico. Sem um gateway, os clientes precisariam selecionar automaticamente quais pontos de extremidade de implantação de modelo usar e quais credenciais são necessárias para essa API específica do plano de dados OpenAI do Azure.
Solução
Figura 1: Arquitetura conceitual de acesso ao Azure OpenAI por meio de um gateway
Para enfrentar os muitos desafios listados em Principais desafios, você pode injetar um gateway de proxy reverso para dissociar o aplicativo inteligente do Azure OpenAI. Este descarregamento de gateway permite-lhe deslocar a responsabilidade, a complexidade e a observabilidade para longe dos clientes e dá-lhe a oportunidade de aumentar o Azure OpenAI fornecendo outras capacidades que não estão incorporadas. Alguns exemplos são:
Potencial para implementar autenticação federada.
Capacidade de controlar a pressão sobre os modelos através da limitação da taxa.
Monitorização transversal e transversal a modelos.
Capacidade de introduzir agregação de gateway e roteamento avançado para vários serviços, como roteamento de mensagens de baixa prioridade para uma fila para nivelamento de carga baseado em fila ou para computação para executar tarefas.
Balanceamento de carga que usa o monitoramento de ponto de extremidade de integridade para rotear apenas para pontos de extremidade de integridade por quebra de circuito em implantações de modelo indisponíveis ou sobrecarregadas.
Alguns cenários específicos têm mais orientações disponíveis que abordam diretamente um gateway de API e instâncias do Azure OpenAI. Esses cenários estão listados na seção Próximas etapas .
Considerações
Ao introduzir um novo componente em sua arquitetura, você precisa avaliar as compensações recém-introduzidas. Ao injetar um gateway de API entre seus clientes e o plano de dados do Azure OpenAI para enfrentar qualquer um dos principais desafios, você introduz novas considerações em sua arquitetura. Avalie cuidadosamente se o impacto da carga de trabalho nessas considerações arquitetônicas justifica o valor agregado ou a utilidade do gateway.
Fiabilidade
A confiabilidade garante que seu aplicativo atenda aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.
A solução de gateway pode introduzir um único ponto de falha. Essa falha pode ter sua origem na disponibilidade de serviço da plataforma de gateway, interrupções devido a implantações de código ou configuração ou até mesmo pontos de extremidade críticos de API mal configurados em seu gateway. Certifique-se de projetar sua implementação para atender aos requisitos de disponibilidade da carga de trabalho. Considere os recursos de resiliência e tolerância a falhas na implementação, incluindo o gateway na análise do modo de falha da carga de trabalho.
Sua solução pode exigir recursos de roteamento global se sua arquitetura exigir instâncias do Azure OpenAI em várias regiões. Essa situação pode complicar ainda mais a topologia por meio do gerenciamento de nomes de domínio extra totalmente qualificados, certificados TLS e mais componentes de roteamento global.
Importante
Não implemente um gateway se isso comprometer a capacidade da sua carga de trabalho de atender aos SLOs (objetivos de nível de serviço) acordados.
Segurança
Ao considerar como um gateway de API beneficia sua arquitetura, use a lista de verificação de revisão de design para Segurança para avaliar seu design. Você precisa abordar considerações de segurança, como as seguintes:
A área de superfície da carga de trabalho é aumentada com a adição do gateway. Essa área de superfície traz considerações extras de gerenciamento de identidade e acesso (IAM) dos recursos do Azure, maiores esforços de proteção e muito mais.
O gateway pode atuar como uma transição de limite de rede entre o espaço de rede do cliente e o espaço de rede privado do Azure OpenAI. Embora o gateway torne privado um ponto de extremidade do Azure OpenAI anteriormente voltado para a Internet por meio do uso do Azure Private Link, ele agora se torna o novo ponto de entrada e deve ser adequadamente protegido.
Um gateway está em uma posição única para ver dados brutos de solicitação e respostas formuladas do modelo de linguagem, que podem incluir dados confidenciais de qualquer fonte. A conformidade de dados e o escopo regulatório agora são estendidos a esse outro componente.
Um gateway pode estender o escopo de autorização e autenticação de cliente além da ID do Microsoft Entra e da autenticação de chave de API e, potencialmente, em vários provedores de identidade (IdP).
A soberania de dados deve ser levada em conta em sua implementação em implementações de várias regiões. Certifique-se de que a computação do gateway e a lógica de roteamento estejam de acordo com os requisitos de soberania colocados em sua carga de trabalho.
Importante
Não implemente um gateway se isso deixar sua carga de trabalho incapaz de proteger a confidencialidade, integridade ou disponibilidade de si mesmo ou dos dados de seus usuários.
Otimização de Custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.
Todos os gateways de API implementados têm custos de tempo de execução que precisam ser orçados e contabilizados. Esses custos geralmente aumentam com recursos adicionais para lidar com a confiabilidade, segurança e desempenho do próprio gateway, juntamente com os custos operacionais introduzidos com o gerenciamento adicional de APIOps. Esses custos adicionais precisam ser medidos em relação ao novo valor fornecido pelo sistema com o gateway. Você deseja chegar a um ponto em que os novos recursos introduzidos usando um gateway superem o custo de implementação e manutenção do gateway. Dependendo da relação da sua carga de trabalho com os usuários, talvez seja possível cobrar o uso de volta.
Excelência Operacional
Ao considerar como um gateway de API beneficia sua arquitetura, use a lista de verificação de revisão de design para Excelência Operacional para avaliar seu projeto. Você precisa abordar considerações de excelência operacional, como as seguintes:
O gateway em si precisa ser monitorado pela solução de monitoramento da sua carga de trabalho e, potencialmente, pelos clientes. Isso significa que a computação e as operações do gateway precisam ser incluídas na modelagem de integridade da carga de trabalho.
Suas práticas de implantação seguras agora precisam abordar a implantação da infraestrutura do gateway de API e o código ou a configuração do roteamento do gateway. Sua solução de automação de infraestrutura e infraestrutura como código (IaC) precisa considerar como tratar seu gateway como um recurso de longa duração na carga de trabalho.
Você precisa criar ou estender sua abordagem APIOps para cobrir as APIs expostas no gateway.
Eficiência de Desempenho
Ao considerar como um gateway de API beneficia sua arquitetura, use a lista de verificação de revisão de design para Eficiência de desempenho para avaliar seu projeto. Você precisa abordar considerações de eficiência de desempenho, como as seguintes:
O serviço de gateway pode introduzir um gargalo de taxa de transferência. Certifique-se de que o gateway tenha desempenho adequado para lidar com carga simultânea total e possa ser facilmente dimensionado de acordo com suas expectativas de crescimento. Garanta elasticidade na solução para que o gateway possa reduzir a oferta ou reduzir a escala quando a demanda estiver baixa, como no uso do dia útil.
O serviço de gateway tem processamento que deve executar por solicitação e introduz latência adicional por chamada de API. Você deve otimizar sua lógica de roteamento para manter o bom desempenho das solicitações.
Na maioria dos casos, o gateway deve estar geograficamente perto dos usuários e das instâncias do Azure OpenAI para reduzir a latência. Embora a latência da rede seja geralmente uma pequena porcentagem de tempo em chamadas de API gerais para modelos de linguagem, isso pode ser um fator competitivo para sua carga de trabalho.
Avalie o impacto do gateway nos recursos do Azure OpenAI, como respostas de streaming ou fixação de instância para interações com monitoração de estado, como a API de Assistentes.
Importante
Não implemente um gateway se isso impossibilitar o cumprimento de metas de desempenho negociadas ou comprometer demais outras compensações.
Opções de implementação
O Azure não oferece uma solução chave-na-mão concebida especificamente para proxy da API HTTP do Azure OpenAI ou de outras APIs de inferência de modelo de linguagem personalizadas. Mas ainda há várias opções para sua equipe de carga de trabalho implementar, como um gateway no Azure.
Utilizar a Gestão de API do Azure
O Gerenciamento de API do Azure é um serviço gerenciado por plataforma projetado para descarregar preocupações transversais para APIs baseadas em HTTP. Ele é orientado por configuração e suporta personalização por meio de seu sistema de política de processamento de solicitações de entrada e saída. Ele suporta réplicas altamente disponíveis, redundantes de zona e até mesmo de várias regiões usando um único plano de controle.
A maior parte da lógica de roteamento e tratamento de solicitações do gateway deve ser implementada no sistema de políticas do Gerenciamento de API. Você pode combinar políticas internas, como Limitar o uso de token da API OpenAI do Azure ou métricas de emissão para consumo de tokens do Azure OpenAI, e suas próprias políticas personalizadas. Alguns exemplos de políticas e cenários personalizados podem ser encontrados no repositório GitHub da comunidade do kit de ferramentas do gateway de Gerenciamento de API.
Use o guia de serviço do Well-Architected Framework para Gerenciamento de API ao projetar uma solução que envolva o Gerenciamento de API do Azure.
Usar o Gerenciamento de API do Azure para sua implementação de gateway geralmente é a abordagem preferida para criar e operar um gateway OpenAI do Azure. É preferível porque o serviço é uma oferta de plataforma como serviço (PaaS) com recursos internos avançados, alta disponibilidade e opções de rede. Ele também tem abordagens APIOps robustas para gerenciar suas APIs de conclusão.
Usar código personalizado
A abordagem de código personalizado requer que uma equipe de desenvolvimento de software crie uma solução codificada personalizada e implante essa solução em uma plataforma de aplicativo do Azure de sua escolha. Criar uma solução autogerenciada para lidar com a lógica de gateway pode ser uma boa opção para equipes de carga de trabalho proficientes em gerenciar código de rede e roteamento.
A carga de trabalho geralmente pode usar computação com a qual eles estão familiarizados, como hospedar o código do gateway no Serviço de Aplicativo do Azure, nos Aplicativos de Contêiner do Azure ou no Serviço Kubernetes do Azure.
As implantações de código personalizado também podem ser feitas com o Gerenciamento de API quando o Gerenciamento de API é usado exclusivamente para seus principais recursos de gateway de API HTTP entre seus clientes e seu código personalizado. Dessa forma, seu código personalizado interage exclusivamente com suas APIs HTTP do Azure OpenAI com base na lógica de negócios necessária.
O uso da tecnologia de gateway que não é da Microsoft, que é um produto ou serviço que não é fornecido nativamente pelo Azure, pode ser considerado como parte dessa abordagem.
Exemplo de arquitetura
Figura 2: Exemplo de arquitetura de acesso ao Azure OpenAI por meio de um gateway baseado em Gerenciamento de API do Azure
Próximos passos
Saiba mais sobre um cenário específico em que a implantação de um gateway entre um aplicativo inteligente e implantações do Azure OpenAI é usada para atender aos requisitos de carga de trabalho:
Aprenda maneiras de implementar o registro em log e o monitoramento para modelos do Azure OpenAI.
Recursos relacionados
- Azure OpenAI Service
- Gateway de API no Gerenciamento de API do Azure
- Acelerador de zona de aterrissagem de gerenciamento de API cobrindo cenários de IA generativa
- Kit de ferramentas do gateway de gerenciamento de API