Aceda ao Azure OpenAI e a outros modelos de linguagem através de um gateway

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 no Azure AI Foundry. 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.

• Balanceamento de carga ou redundância: 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.

  Global, padrão ou provisionado e zona de dados, padrão ou provisionada, não afetam a disponibilidade do serviço OpenAI do Azure de uma perspetiva de disponibilidade de ponto de extremidade regional. Você ainda tem a responsabilidade de implementar a lógica de failover por conta própria.

• 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.

• Limitação: as APIs OpenAI do Azure limitam as solicitações retornando um código de resposta de erro HTTP 429 para solicitações que excedem o Token-Per-Minute (TPM) ou Requests-Per-Minute (RPM) no modelo padrão. As APIs do Azure OpenAI também limitam as solicitações que excedem a capacidade provisionada 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.

  A maioria das cargas de trabalho deve resolver esse problema específico usando global e zona de dados implantações do Azure OpenAI. Essas implantações para usar a capacidade do modelo de data centers com a capacidade suficiente para cada solicitação. O uso de implantações globais e de zona de dados diminuirá significativamente a limitação de serviços sem complexidade adicional de gateways personalizados. As implantações globais e de zona de dados são, elas próprias, uma implementação de gateway.

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.

  Você deve estar ciente de que, quando estiver usando global ou zona de dados implantações do Azure OpenAI, os dados em repouso permanecem na geografia designada do Azure, mas os dados podem ser transmitidos e processados para inferência em qualquer local 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 do rastreamento de custos provisionados ou por cliente pode ser obtida 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 showback, 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 provisionado antes de se espalharem para qualquer implantação de modelo padrão.

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 ou várias zonas de dados, entender o uso e a disponibilidade da cota 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 GenAIOps 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_tokens e best_of sã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.

• O balanceamento de carga que usa o monitoramento de ponto de extremidade de integridade para rotear apenas para pontos de extremidade íntegros, de interrupção 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 para aumentar a disponibilidade de seus pontos de extremidade do Azure OpenAI, como a capacidade de continuar a atender solicitações no caso de uma interrupção regional. 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.

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.

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 fazer o estorno do uso.

Para ajudar a gerenciar custos ao desenvolver e testar um gateway, considere usar um ponto de extremidade simulado para o Azure OpenAI. Por exemplo, use a solução no repositório GitHub do simulador de API OpenAI do Azure.

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.

• Você duplica recursos que estão disponíveis por meio de soluções como o recurso do Serviço Azure AI ou a funcionalidade de distribuição de carga da zona de dados do Azure OpenAI.

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.

Opções de implementação

O Azure não oferece uma solução turn-key projetada especificamente para proxy da API HTTP do Azure OpenAI ou outras APIs de inferência de modelo de linguagem personalizado para cobrir todos esses cenários. 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 específicas do Azure OpenAI, como Limitar o uso de token da API do Azure OpenAI ou métricas de emissão de para consumo de tokens do Azure OpenAIe suas próprias políticas personalizadas. O repositório GitHub do kit de ferramentas de gateway GenAI contém várias políticas personalizadas de Gerenciamento de API, juntamente com uma configuração de teste de carga para testar o comportamento das políticas.

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. Se sua carga de trabalho existir como parte de uma zona de aterrissagem de aplicativo, revise as orientações disponíveis no Cloud Adoption Framework for Azure sobre a implementação de uma zona de aterrissagem do 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:

• Balanceamento de carga ou failover entre várias instâncias de back-end
• Autenticação e autorização personalizadas para aplicativos cliente

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
• Repositório GitHub da zona de aterrissagem do Gerenciamento de API cobrindo cenários de IA generativa
• Kit de ferramentas do gateway de gerenciamento de API
• Simulador de API OpenAI