Multilocação e Serviço Azure OpenAI
O Azure OpenAI fornece acesso aos poderosos modelos de linguagem da OpenAI. Este artigo descreve os principais recursos do Azure OpenAI que são benéficos para soluções multilocatário. Reveja os recursos recomendados para o ajudar a planear a sua abordagem e utilizar o Azure OpenAI.
Modelos de isolamento
Quando você tem um sistema multilocatário que usa o serviço Azure OpenAI, você precisa decidir o nível de isolamento que seus locatários exigem. Você deve determinar seu modelo de isolamento com base nos seguintes fatores:
- Quantos inquilinos pretende ter?
- Os seus inquilinos têm requisitos de conformidade que exigem isolamento de rede ou infraestrutura?
- Os seus inquilinos necessitam de modelos ajustados aos seus próprios dados?
- Os seus inquilinos necessitam de diferentes versões ou ciclos de vida de modelos?
A tabela a seguir resume as abordagens de implantação que você pode usar ao usar o Serviço OpenAI do Azure em um sistema multilocatário:
| Consideração | Serviço dedicado do Azure OpenAI | Serviço OpenAI do Azure compartilhado, implantação de modelo dedicado por locatário | Serviço OpenAI do Azure compartilhado, implantação de modelo compartilhado | Serviço Azure OpenAI fornecido pelo locatário |
|---|---|---|---|---|
| Isolamento de dados | Alto | Médio | Baixo | Alta |
| Isolamento de desempenho | Alto | Alto | Baixo-médio, dependendo do uso do token por minuto (TPM) para cada locatário. | Alto |
| Complexidade da implantação | Baixo-médio, dependendo do número de inquilinos. | Médio, precisa gerenciar nomes e cotas de implantação. | Baixo | Não aplicável, gerido pelo cliente. |
| Complexidade operacional | Baixo | Médio | Alto | Baixo para o provedor, maior para o locatário. |
| Cenário de exemplo | Implantações de locatário único que exigem isolamento de rede de outros locatários. | Locatários com ciclo de vida do modelo específico ou requisitos de ajuste fino. | Grandes soluções multilocatárias com uma camada de aplicativo compartilhada. | Inquilinos com requisitos específicos de conformidade ou ajuste fino. |
Serviço dedicado do Azure OpenAI
Se você for um provedor de serviços, considere implantar uma instância do Azure OpenAI para cada locatário em sua assinatura do Azure. Essa abordagem fornece isolamento de dados para cada locatário. Ele requer que você implante e gerencie um número crescente de recursos do Azure OpenAI à medida que aumenta o número de locatários.
Use essa abordagem se você tiver implantações de aplicativos separadas para cada locatário ou se precisar contornar limitações, como a cota ou solicitação por minuto. Para obter mais informações, consulte Cotas e limites do Azure OpenAI.
O diagrama a seguir ilustra o modelo do Azure OpenAI para cada locatário na assinatura do provedor.
Serviço compartilhado do Azure OpenAI
Você pode optar por compartilhar uma instância do Azure OpenAI entre vários locatários. O recurso Azure OpenAI é implantado em sua assinatura do Azure (do provedor de serviços). Você é responsável por gerenciá-lo. Esta solução é a mais fácil de implementar, mas fornece o menor isolamento de dados e isolamento de desempenho.
O compartilhamento de um recurso do Azure OpenAI não fornece segmentação de segurança para cada implantação de modelo. Um locatário pode usar um modelo que não está autorizado a usar. Por esse motivo, evite compartilhar uma instância do Azure OpenAI ao usar modelos ajustados, pois você pode expor informações confidenciais e permitir acesso não autorizado a dados ou recursos específicos do locatário.
Compartilhar uma instância do Azure OpenAI entre vários locatários também pode levar a um problema de vizinho barulhento. Pode causar maior latência para alguns inquilinos. Você também precisa fazer com que seu código de aplicativo conheça a multilocação. Por exemplo, se você quiser cobrar de seus clientes o custo de consumo de uma instância compartilhada do Azure OpenAI, implemente a lógica para acompanhar o número total de tokens para cada locatário em seu aplicativo.
Você também pode implantar várias instâncias compartilhadas do Azure OpenAI. Por exemplo, se você seguir o padrão Selos de Implantação, implante uma instância compartilhada do Azure OpenAI em cada carimbo. Se você implantar uma solução multirregião, deverá implantar o Azure OpenAI em cada região para:
- Evite a latência do tráfego entre regiões.
- Suporte a requisitos de residência de dados.
- Habilite o uso do Azure OpenAI regional em outros serviços que exigem implantações da mesma região.
Quando você tem uma instância compartilhada do Azure OpenAI, é importante considerar seus limites e gerenciar sua cota.
O diagrama a seguir ilustra o modelo compartilhado do Azure OpenAI.
Ao implantar um serviço compartilhado do Azure OpenAI, você pode decidir se as implantações de modelo dentro do serviço também são compartilhadas ou se são dedicadas a clientes específicos.
Implantação de modelo compartilhado entre locatários
Compartilhar uma implantação de modelo entre locatários simplifica sua carga operacional porque você tem menos implantações para gerenciar e versões de modelo para rastrear. Planeje usar uma implantação de modelo compartilhado, se puder, e crie implantações de modelo dedicadas somente se precisar dos recursos oferecidos.
Implantação de modelo dedicado por locatário
Você pode criar uma implantação de modelo para cada locatário ou para locatários que têm requisitos especiais que não podem ser atendidos usando uma implantação de modelo compartilhado. Os motivos comuns para usar implantações de modelo dedicado para um locatário incluem o seguinte:
Gerenciamento de cotas e custos: facilita a alocação de TPM específica do locatário rastreando o número de tokens que cada modelo usa, o que permite alocar e gerenciar com precisão o uso de cada locatário. Se você usar unidades de taxa de transferência provisionadas (PTUs), poderá atribuir as PTUs a clientes específicos e usar outros modelos de cobrança para outros clientes.
Políticas de filtragem de conteúdo: às vezes, um locatário específico pode exigir uma política de filtragem de conteúdo exclusiva, como uma lista de bloqueio específica do locatário de palavras não permitidas. Você especifica a política de filtragem de conteúdo no escopo de uma implantação de modelo.
Tipos e versões de modelo: talvez seja necessário usar modelos ou versões de modelo diferentes para locatários diferentes. Um locatário também pode exigir seu próprio processo de gerenciamento do ciclo de vida do modelo.
Ajuste fino específico do locatário: se você criar modelos ajustados distintos para cada locatário, precisará criar uma implantação de modelo separada para cada modelo ajustado.
Lembre-se de que o ajuste fino não é necessário para a maioria dos casos de uso. Normalmente, é melhor aterrar seu modelo usando o Azure OpenAI On Your Data ou outra abordagem de geração aumentada de recuperação (RAG).
Residência de dados: essa abordagem suporta requisitos distintos de residência de dados. Por exemplo, você pode fornecer uma implantação de modelo regional para um locatário com necessidades estritas de residência de dados e usar uma implantação de modelo global para outros locatários sem necessidades estritas.
Cada implantação de modelo tem sua própria URL distinta, mas é importante lembrar que os modelos subjacentes são compartilhados com outros clientes do Azure. Eles também usam a infraestrutura compartilhada do Azure.
O Azure OpenAI não impõe controle de acesso para cada implantação de modelo, portanto, seu aplicativo precisa controlar qual locatário pode alcançar qual implantação de modelo.
Recurso do Azure OpenAI fornecido pelo locatário
Em algumas situações, seus locatários podem criar a instância do Azure OpenAI em suas próprias assinaturas do Azure e conceder acesso a ela ao seu aplicativo. Esta abordagem pode ser adequada nas seguintes situações:
- Os locatários têm cotas e permissões específicas da Microsoft, como acesso a modelos diferentes, políticas específicas de filtragem de conteúdo ou o uso de taxa de transferência provisionada.
- O locatário tem um modelo ajustado que precisa usar da sua solução.
- Eles exigem um componente em seu ambiente para processar e enviar dados por meio de sua instância do Azure OpenAI gerenciada pelo cliente para processamento.
Para acessar uma instância do Azure OpenAI na assinatura do seu locatário, o locatário deve fornecer acesso ao seu aplicativo. Seu aplicativo deve se autenticar por meio de sua instância do Microsoft Entra. Uma abordagem é publicar um aplicativo Microsoft Entra multilocatário. O fluxo de trabalho a seguir descreve as etapas dessa abordagem:
- O locatário registra o aplicativo multilocatário Microsoft Entra em seu próprio locatário do Microsoft Entra.
- O locatário concede ao aplicativo multilocatário Microsoft Entra o nível apropriado de acesso ao recurso Azure OpenAI. Por exemplo, o locatário pode atribuir o aplicativo à função de usuário dos serviços de IA do Azure usando o RBAC (controle de acesso baseado em função).
- O locatário fornece a ID do recurso do Azure OpenAI que eles criam.
- Seu código de aplicativo pode usar uma entidade de serviço associada ao aplicativo multilocatário Microsoft Entra em sua própria instância do Microsoft Entra para acessar a instância do Azure OpenAI do locatário.
Como alternativa, você pode pedir a cada locatário para criar uma entidade de serviço para seu serviço usar e fornecer suas credenciais. Essa abordagem requer que você armazene e gerencie com segurança as credenciais de cada locatário, o que é uma responsabilidade de segurança em potencial.
Se seus locatários configurarem controles de acesso à rede em sua instância do Azure OpenAI, certifique-se de que você possa acessá-los.
O diagrama a seguir ilustra o modelo do Azure OpenAI para cada locatário na assinatura do locatário.
Recursos do Serviço OpenAI do Azure que dão suporte à multilocação
API de assistentes
A API de Assistentes adiciona funcionalidade ao seu serviço Azure OpenAI que o torna adequado para criar assistentes de IA. Ele inclui a capacidade de chamar ferramentas e APIs, bem como arquivos de pesquisa para fundamentar as respostas que o modelo gera. Ele permite que threads de conversação persistentes sejam gerenciados pelo serviço e pode gerar e executar código em um ambiente de área restrita. Para oferecer suporte a esses recursos, a API de assistentes precisa armazenar alguns dados.
Ao usar a API de assistentes em uma solução multilocatário, você pode optar por criar assistentes dedicados a um único locatário ou compartilhar um assistente entre vários locatários. É importante considerar o isolamento do locatário em todos os dados armazenados, especialmente para assistentes compartilhados. Por exemplo, você deve garantir que os threads de conversação sejam armazenados separadamente para cada locatário.
A API Assistants suporta a invocação de funções, que envia ao seu aplicativo instruções sobre funções a serem invocadas e argumentos a serem incluídos. Certifique-se de que todas as chamadas de funções feitas sejam compatíveis com multilocatário, por exemplo, incluindo o ID do locatário na chamada para o sistema downstream. Verifique o ID do locatário em seu aplicativo e não confie no modelo de idioma para propagar o ID do locatário para você.
Azure OpenAI em seus dados
O Azure OpenAI On Your Data permite que o modelo de linguagem grande consulte diretamente fontes de conhecimento, como índices e bancos de dados, como parte da geração de uma resposta do modelo de linguagem.
Ao fazer uma solicitação, você pode especificar as fontes de dados que devem ser consultadas. Em uma solução multilocatário, certifique-se de que suas fontes de dados reconheçam multilocação e que você possa especificar filtros de locatário em suas solicitações. Propagar o ID do locatário para a fonte de dados adequadamente. Por exemplo, suponha que você esteja consultando o Azure AI Search. Se você tiver dados para vários locatários em um único índice, especifique um filtro para limitar os resultados recuperados à ID do locatário atual. Ou, se tiver criado um índice para cada inquilino, certifique-se de que especifica o índice correto para o inquilino atual.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Sofia Ferreira - Portugal | Engenheiro de Software, ISV & DN CoE
Outros contribuidores:
- John Downs - Brasil | Engenheiro de Software Principal
- Landon Pierce - Brasil | Engenheiro de Clientes, ISV & DN CoE
- Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, ISV & DN CoE
- Daniel Scott-Raynsford - Brasil | Arquiteto de Soluções de Parceiros
- Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, ISV & DN CoE
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.