Editar

Compartilhar via

Acessar o OpenAI do Azure e outros modelos de linguagem por meio de um gateway

Serviços de IA do Azure
Serviço OpenAI do Azure
Gerenciamento de API do Azure

O Serviço OpenAI do Azure expõe APIs HTTP que permitem que seus aplicativos executem incorporações ou conclusões usando os modelos de linguagem do 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 conectar a uma ou mais instâncias do OpenAI do Azure, será necessário 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 envolvendo os cinco pilares da 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 OpenAI do Azure. Em seguida, aprenda 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, certifique-se de ler as Diretrizes específicas de cenários que examinam 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 OpenAI do Azure, o cliente precisa administrar a lógica de cliente de API, o que inclui mecanismos de repetição ou interrupção de circuito. Esta situação pode ser um desafio em cenários no qual você não está no controle direto do 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 OpenAI do Azure têm ainda mais desafios, como a coordenação de implantações seguras e a observabilidade.

Esta seção oferece exemplos de desafios arquitetônicos importantes específicos que você pode enfrentar se sua arquitetura oferecer suporte apenas ao acesso direto do OpenAI do Azure por parte dos consumidores. 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 preservação e recuperação automáticas, que são geralmente implementados por meio de mecanismos de replicação e failover. Sem um gateway, todas as questões de confiabilidade devem ser abordadas exclusivamente usando a lógica do cliente e nos recursos do Serviço OpenAI do Azure. A confiabilidade da carga de trabalho fica 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 OpenAI do Azure 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.

  • Expandir para lidar com picos: fazer failover para instâncias do OpenAI do Azure com capacidade quando houver limitação é outra responsabilidade do cliente que você precisa controlar por meio de configuração e lógica personalizada. Atualizar várias configurações de cliente para novas instâncias do OpenAI do Azure aprasenta maior risco e preocupações com relação à pontualidade. O mesmo também vale para atualizar o código do cliente e 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 TPM (Token por Minuto) ou as 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. O tratamento da lógica apropriada de back-off e repetição é deixado 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 questõ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 disponível para segmentação de cliente, controle de cliente ou recursos de segurança de serviço para comunicação direta.

  • Gerenciamento de identidades - escopo de autenticação: as APIs do plano de dados expostas pelo OpenAI do Azure podem ser protegidas de duas maneiras: chave de API ou controle de acesso baseado em função (RBAC) do Azure. Em ambos os casos, a autenticação acontece no nível da instância do Azure OpenAI, não no nível de implantação individual, o 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 encontradas no locatário do Microsoft Entra que dá suporte à instância do OpenAI do Azure 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 devido a todos os clientes compartilharem a mesma identidade.

  • Segurança de rede: dependendo do local do cliente em relação às suas instâncias do Azure OpenAI, o acesso público à Internet aos modelos de linguagem pode ser necessário.

  • Soberania de dados: soberania de dados no contexto do Azure OpenAI refere-se aos requisitos legais e regulamentares relacionados ao armazenamento e processamento de dados dentro dos limites geográficos de um país ou região específico. 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 OpenAI do Azure.

Desafios de otimização de custos

As cargas de trabalho se beneficiam quando as arquiteturas conseguem minimizar o desperdício e maximizar a utilidade. Forte modelagem e monitoramento de custos são um requisito importante para qualquer carga de trabalho. Sem um gateway, a utilização de PTU ou rastreamento de custo por cliente pode ser obtida de forma autoritária exclusivamente a partir da agregação da telemetria de uso da instância do OpenAI do Azure.

  • Acompanhamento de custos: o fornecimento de uma perspectiva financeira sobre o uso do OpenAI do Azure fica limitado aos dados agregados da telemetria de uso da instância do OpenAI do Azure. Quando for preciso fazer estorno ou apresentação de despesas, você precisará atribuir essa telemetria de uso com vários clientes em diferentes departamentos ou até mesmo clientes para cenários com vários locatários.

  • Utilização de produtividade provisionada: é melhor que sua carga de trabalho evite o desperdício utilizando totalmente a produtividade provisionada pela qual você pagou. Isso significa que os é preciso ter certeza e coordenação para que clientes usem implantações de modelo baseadas em PTU antes de começarem a adotar quaisquer implantações de modelos com base no consumo.

Desafios da excelência operacional

Sem um gateway, a observabilidade, o controle de alterações e os processos de desenvolvimento ficam limitados ao que é fornecido pela comunicação direta entre cliente e servidor.

  • Controle de cota: os clientes recebem 429 códigos de resposta diretamente do OpenAI do Azure quando as APIs HTTP são limitadas. Os operadores de carga de trabalho são responsáveis por garantir que a disponibilidade de cota esteja disponível para uso legítimo e, ao mesmo tempo, fazer com que os clientes com comportamento inadequado não consumam em excesso os serviços. Quando sua carga de trabalho consiste em várias implantações de modelo, pode ser difícil visualizar o uso da cota e a disponibilidade da cota.

  • Monitoramento e observabilidade: as métricas padrão do OpenAI do Azure estão disponíveis por meio do Azure Monitor. No entanto, há latência com a disponibilidade dos dados e isso não fornece monitoramento em tempo real.

  • Práticas de implantação segura: seu processo de GenAIOps exige coordenação entre os clientes e os modelos implantados no OpenAI do Azure. Para abordagens de implantação avançadas, como azul-verde ou canário, essa lógica precisará ser trabalhada no lado do cliente.

Desafios de eficiência de desempenho

Sem um gateway, sua carga de trabalho coloca sobre os clientes a responsabilidade de serem individualmente bem comportados e justos com relação a outros clientes considerando a limitação de capacidade.

  • Otimização de desempenho - tráfego prioritário: priorizar solicitações de clientes para que clientes de alta prioridade tenham acesso preferencial em relação a clientes de baixa prioridade exigiria uma coordenação bem abrangente e provavelmente inviável de cliente para cliente. Algumas cargas de trabalho podem se beneficiar de ter solicitações de baixa prioridade na fila para execução quando a utilização do modelo é baixa.

  • Otimização de desempenho - conformidade do cliente: para compartilhar a capacidade, os clientes precisam se comportar bem. Um exemplo disso é quando os clientes garantem que max_tokens e best_of sejam definidos como valores aprovados. Sem um gateway, você deve confiar que os clientes agirão com as melhores intenções para preservar a capacidade de sua instância do OpenAI do Azure.

  • Minimizar a latência: embora a latência de rede seja geralmente um pequeno componente do fluxo geral de solicitações de prompt 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 vantajoso. Sem um gateway, os clientes precisariam selecionar eles mesmos qual ponto de extremidade de implantação de modelo usar e quais credenciais são necessárias para essa API de plano de dados específica do OpenAI do Azure.

Solução

Diagrama que mostra uma arquitetura conceitual de injeção de um gateway entre um aplicativo inteligente e o OpenAI do Azure.

Figura 1: arquitetura conceitual de acesso ao OpenAI do Azure por meio de um gateway

Para resolver os muitos desafios listados nos principais desafios, você pode injetar um gateway de proxy reverso para desacoplar o aplicativo inteligente do OpenAI do Azure. Esse descarregamento de gateway permite que você desloque a responsabilidade, a complexidade e a observabilidade dos clientes, além de oferecer a oportunidade de aumentar o serviço OpenAI do Azure fornecendo outros recursos que ainda não estão integrados. Alguns exemplos são:

Alguns cenários específicos têm mais orientações disponíveis que abordam diretamente um gateway de API e instâncias do OpenAI do Azure. 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 os pontos positivos e os negativos. Ao injetar um gateway de API entre seus clientes e o plano de dados do OpenAI do Azure para resolver qualquer um dos principais desafios, você introduz novas considerações à 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.

Confiabilidade

A confiabilidade garante que seu aplicativo cumpra os compromissos que você deve assumir 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 ponto único 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 má configuração de pontos de extremidade críticos de API em seu gateway. Certifique-se de projetar sua implementação para atender aos requisitos de disponibilidade da sua 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 precisar de instâncias do OpenAI do Azure em várias regiões. Essa situação pode complicar ainda mais a topologia por meio do gerenciamento de nomes de domínio totalmente qualificados extras, 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 atingir os objetivos de nível de serviço acordados (SLOs).

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 na hora de avaliar seu projeto. Você precisa abordar considerações de segurança, como as seguintes:

  • A área de superfície da carga de trabalho aumenta 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 OpenAI do Azure. Embora o gateway torne privado um ponto de extremidade do OpenAI do Azure anteriormente voltado para a Internet por meio do uso do Link privado do Azure, 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 dos dados deve ser levada em consideração na sua implementação em implementações multirregionais. Certifique-se de que a lógica de computação e roteamento do gateway esteja de acordo com os requisitos de soberania colocados na 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 seus dados ou de seus usuários.

Otimização de custos

A otimização de custos é a análise de maneiras de reduzir as 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 tem custos de runtime que precisam ser orçados e contabilizados. Esses custos geralmente aumentam com recursos adicionados para abordar a confiabilidade, a segurança e o 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 pelo uso de um gateway superem o custo de implementação e manutenção do gateway. Dependendo do relacionamento da sua carga de trabalho com os usuários, talvez você conseguirá estornar o uso.

Para ajudar a gerenciar os custos ao desenvolver e testar um gateway, considere usar um ponto de extremidade simulado para o OpenAI do Azure. Por exemplo, use a solução no repositório GitHub do simulador de API do 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 na hora de 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 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 segura 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 excelência de desempenho na hora de 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 produtividade. O gateway deve ter um desempenho adequado para lidar com a carga concorrente total e pode facilmente ser dimensionado em linha com o crescimento das expectativas. Garanta a elasticidade na solução para que o gateway possa reduzir a oferta, ou reduzir a escala, quando a demanda for baixa, como é normal 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 as solicitações funcionando bem.

  • Na maioria dos casos, o gateway deve estar geograficamente perto dos usuários e das instâncias do OpenAI do Azure para reduzir a latência. Embora a latência de rede seja geralmente uma pequena porcentagem de tempo em chamadas gerais de API para modelos de linguagem, ela pode ser um fator competitivo para sua carga de trabalho.

  • Avalie o impacto do gateway nos recursos do OpenAI do Azure, 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 impossibilita o alcance das metas de desempenho negociadas ou comprometer demais outras vantagens.

Opções de implementação

O Azure não oferece uma solução pronta para uso exclusivo projetada especificamente para proxy da API HTTP do OpenAI do Azure ou 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.

Usar gerenciamento de API do Azure

A API Management do Azure é um serviço gerenciado por plataforma projetado pensando no descarregamento de preocupações transversais para APIs baseadas em HTTP. Ele é orientado à configuração e oferece suporte à personalização por meio de seu sistema de políticas de processamento de solicitações de entrada e saída. Ele oferece suporte a réplicas altamente disponíveis, com redundância de zona e até mesmo em várias regiões usando um único plano de controle.

A maior parte do roteamento do gateway e da lógica de manipulação de solicitações 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 Emitir métricas para consumo de tokens do Azure OpenAI, e suas próprias políticas personalizadas. O repositório do GitHub do kit de ferramentas do gateway da 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 API Management ao projetar uma solução que envolve o API Management 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 do OpenAI do Azure. Isso é preferido 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 para implantar essa solução em uma plataforma de aplicativo no Azure de sua escolha. Criar uma solução autogerenciada para lidar com a lógica do gateway pode ser uma boa opção para equipes de carga de trabalho proficientes no gerenciamento de 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 de Kubernetes do Azure.

As implantações de código personalizado também podem ser tratadas com a API Management quando o API Management é 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 comunica-se exclusivamente com suas APIs HTTP do OpenAI do Azure com base na lógica de negócios necessária.

O uso de tecnologia de gateway que não seja Microsoft, que é um produto ou serviço que não é fornecido nativamente pelo Azure, também pode ser considerado como parte dessa abordagem.

Arquitetura de exemplo

Diagrama que mostra uma arquitetura de exemplo de injeção de um gateway entre um aplicativo inteligente e o OpenAI do Azure.

Figura 2: arquitetura de exemplo de acesso ao OpenAI do Azure por meio de um gateway baseado em API Management do Azure

Próximas etapas

Saiba mais sobre um cenário específico em que a implantação de um gateway entre um aplicativo inteligente e implantações do OpenAI do Azure é usada para atender aos requisitos da carga de trabalho:

Aprenda formas de Implemente o registro em log e o monitoramento para os modelos do OpenAI do Azure.