Arquitetura Microsoft Foundry

A Microsoft Foundry organiza cargas de trabalho de IA através de uma arquitetura em camadas: um recurso Foundry de topo para governação, projetos para isolamento de desenvolvimento e serviços Azure ligados para armazenamento, pesquisa e gestão de segredos.

Este artigo fornece às equipas de operações de TI e segurança detalhes sobre o recurso Foundry e a arquitetura de serviços Azure subjacente, os seus componentes e a sua relação com outros tipos de recursos do Azure. Use esta informação para orientar como personalizar a sua implantação no Foundry de acordo com os requisitos da sua organização. Para mais informações sobre como implementar a Foundry na sua organização, consulte Foundry Rollout.

Quando usar esta arquitetura

Considere o modelo de recursos da Foundry quando o seu cenário envolve:

  • Primeira configuração: Está a iniciar um novo projeto de IA e quer um único recurso que inclua acesso ao modelo, alojamento de agentes e ferramentas de avaliação.
  • Acesso multi-equipa: Múltiplas equipas precisam de projetos isolados com implementações de modelos partilhados e governação centralizada.
  • Design orientado para a conformidade: A sua organização requer redes privadas, encriptação gerida pelo cliente ou definição de âmbito do Azure RBAC tanto a nível de recursos como a nível de projeto.
  • Migração do Azure OpenAI: Está a passar de um recurso autónomo do Azure OpenAI e quer manter as políticas existentes e o RBAC, enquanto adiciona capacidades de agente e avaliação.

Para exploração de um único programador, um recurso Foundry com um projeto é o padrão recomendado. Se a sua carga de trabalho só exigir completações do Azure OpenAI sem hospedagem ou avaliação de agentes, um recurso Azure OpenAI autónomo pode ser suficiente.

Tipos e fornecedores de recursos para IA Azure

Dentro da família de produtos de IA Azure, pode usar estes fornecedores de recursos Azure que suportam as necessidades dos utilizadores em diferentes camadas da pilha.

Fornecedor de recursos Finalidade Serviços apoiados
Microsoft. CognitiveServices Suporta o desenvolvimento de aplicações Agentic e GenAI, composição e personalização de modelos pré-construídos. Fundição; Azure OpenAI; Azure Speech nas Foundry Tools; Linguagem Azure em Foundry Tools; Azure Vision em Foundry Tools
Microsoft.Search Suporta a recuperação de conhecimento sobre os seus dados Pesquisa de IA do Azure

Para a maioria dos cenários de desenvolvimento de IA — incluindo construção de agentes, implementação de modelos e fluxos de trabalho de avaliação — o recurso Foundry é o ponto de partida recomendado. Os recursos da Foundry partilham o espaço de nomes do fornecedor Microsoft.CognitiveServices com serviços como Azure OpenAI, Speech, Vision e Language. Este espaço de nomes partilhado de fornecedores ajuda a alinhar APIs de gestão, padrões de controlo de acesso, rede e comportamento de políticas entre recursos de IA relacionados.

Use a tabela seguinte para identificar que tipo de recurso corresponde à sua carga de trabalho. Mostra os tipos específicos de recursos e capacidades dentro da Microsoft. Fornecedor de Serviços Cognitivos:

Tipo de recurso Fornecedor e tipo de recurso Variante Capacidades suportadas
Microsoft Foundry Microsoft.CognitiveServices/accounts AIServices Agentes, Avaliações, Azure OpenAI, Fala, Visão, Linguagem e Compreensão de Conteúdos
Projeto da fundição Microsoft.CognitiveServices/accounts/projects AIServices Sub-recurso associado ao acima mencionado
Azure Speech nas Ferramentas Foundry Microsoft.CognitiveServices/accounts Speech Voz
Azure Language in Foundry Tools Microsoft.CognitiveServices/accounts Language Linguagem
Azure Vision em Foundry Tools Microsoft.CognitiveServices/accounts Vision Visão

Tipos de recursos sob os mesmos namespaces de fornecedores partilham as mesmas APIs de gestão e utilizam ações semelhantes de controlo de acesso baseado em funções (Azure RBAC), configurações de rede e aliases para a configuração de Azure Policy. Se está a fazer um upgrade do Azure OpenAI para o Foundry, as suas políticas personalizadas do Azure e as ações RBAC do Azure continuam a aplicar-se.

Hierarquia de recursos da fundição

O diagrama seguinte mostra um recurso Foundry com implementações de modelos, definições de segurança, ligações e dois projetos. Serviços Azure conectados como Storage, Key Vault e Pesquisa de IA do Azure são recursos Azure separados sob os seus próprios limites de governação:

Diagrama mostrando a hierarquia de recursos do Foundry com uma fronteira de governação contendo implementações de modelos, definições de segurança, ligações e dois projetos. Recursos ligados como Armazenamento, Key Vault e Pesquisa de IA do Azure são mostrados como limites de governação separados.

Importante

Recursos ligados como Storage, Key Vault e Pesquisa de IA do Azure são recursos independentes do Azure com os seus próprios limites de governação. Geres as redes, políticas de acesso e definições de conformidade para estes recursos separadamente do recurso da Foundry.

Use este modelo ao planear a arquitetura e os limites de acesso:

  • Foundry resource: Recurso de Azure de topo onde gere definições de governação como redes, segurança e implementações de modelos.
  • Project: Fronteira de desenvolvimento dentro do recurso Foundry onde as equipas constroem e avaliam casos de uso. Os projetos permitem que as equipas prototipem dentro de um ambiente pré-configurado, reutilizando implementações e ligações de modelos existentes sem configurações repetidas de TI.
  • Ativos do projeto: Ficheiros, agentes, avaliações e artefactos relacionados com o âmbito de um projeto.
  • Recursos conectados: serviços Azure como Armazenamento, Key Vault e Pesquisa do Azure AI que o recurso da Foundry referencia através de conexões. Estes recursos têm fronteiras de governação separadas, por isso geres as suas políticas de rede e acesso de forma independente.

Esta separação permite que as equipas de TI apliquem controlos centralizados ao nível dos recursos, enquanto as equipas de desenvolvimento trabalham dentro dos limites ao nível do projeto.

Nota

A maioria das novas APIs está disponível no âmbito do projeto. No entanto, algumas funcionalidades originalmente suportadas ao nível da conta através do Azure OpenAI, Speech, Vision e serviços de Linguagem estão disponíveis apenas ao nível dos recursos da Foundry, não no âmbito do projeto. Por exemplo, a API do Tradutor está disponível apenas ao nível dos recursos da Foundry. Planeie a sua estrutura de implementação com base nas APIs que os seus workloads necessitam.

Separação de preocupações baseada na segurança

A Foundry impõe uma separação clara entre operações de gestão e desenvolvimento para garantir cargas de trabalho de IA seguras e escaláveis.

Governação de recursos de topo

O recurso de topo do Foundry abrange operações de gestão, como a configuração da segurança, o estabelecimento de conectividade com outros serviços do Azure e a gestão de implementações. Contentores dedicados ao projeto isolam as atividades de desenvolvimento e fornecem limites para controlo de acessos, ficheiros, agentes e avaliações.

Controlo de acesso baseado em funções

As ações do Azure RBAC refletem esta separação de preocupações. As ações no plano de controlo, como a criação de implementações e projetos, são distintas das ações do plano de dados, como construir agentes, executar avaliações e carregar ficheiros. Podes definir as atribuições do RBAC tanto ao nível de recursos de topo como ao nível do projeto individual. Atribuir identidades geridas em qualquer um dos escopos para suportar automação segura e acesso a serviços. Para mais informações, consulte Controlo de acesso baseado em funções para Microsoft Foundry.

Atribuições comuns para integração de novos utilizadores com privilégios mínimos incluem:

  • Azure AI User para cada utilizador principal desenvolvedor no âmbito do recurso Foundry.
  • Azure AI User para cada identidade gerida de projeto no contexto do recurso Foundry.

Para definições de funções e orientações para planeamento de âmbito, veja Controlo de acesso baseado em funções para Microsoft Foundry.

Monitorização e observabilidade

Azure Monitor segmenta métricas por âmbito. Pode visualizar métricas de gestão e utilização no recurso de topo, enquanto métricas específicas do projeto, como desempenho de avaliação ou atividade do agente, são atribuídas aos contentores individuais do projeto.

As principais capacidades de monitorização incluem:

  • Métricas ao nível dos recursos: Consumo de tokens, latência do modelo, contagem de pedidos e taxas de erro em todos os projetos.
  • Métricas de nível de projeto: Resultados da execução de avaliação, contagem de invocações de agentes e atividade de operações de ficheiro.
  • Registo de diagnóstico: Ative as definições de diagnóstico para encaminhar registos para Log Analytics, Armazenamento ou Centros de Eventos para análise e retenção.

Para mais informações, consulte Azure Monitor visão geral.

Infraestrutura informática

A Foundry gere a infraestrutura de computação para alojamento de modelos, execução de agentes e processamento em lote. Esta secção abrange tipos de implementação, infraestrutura de agentes e avaliação, integração de redes virtuais, isolamento de locatários, controlos de segurança de conteúdos e disponibilidade regional.

Tipos de implementação de modelos

O Foundry suporta múltiplos tipos de implementação para alojamento de modelos, agrupados por âmbito de processamento de dados: global (entre regiões), zona de dados (dentro de um limite definido) e regional (região única). Cada tipo equilibra a latência, a largura de banda e a localização do processamento de dados de forma diferente.

Tipo de implantação Processamento de dados Faturamento
Padrão Global Entre-regiões, gerido pelo Azure Pagamento por token
Global Provisionado Entre-regiões, gerido pelo Azure Capacidade reservada por hora
Global Batch Entre-regiões, gerido pelo Azure Precificação de tokens por lote
Padrão de Zonas de Dados Dentro do limite da zona de dados Pagamento por token
Zona de Dados Provisionada Dentro do limite da zona de dados Capacidade reservada por hora
Zona de Dados Lote Dentro do limite da zona de dados Precificação de tokens por lote
Standard Região única Pagamento por token
Provisionamento Regional Região única Capacidade reservada por hora
Desenvolvedor Qualquer região Azure (sem garantia de residência de dados) Pay-per-token (apenas avaliação do modelo ajustado; duração de 24 horas; sem SLA)

Para obter detalhes sobre como escolher o tipo de implementação correto, veja Tipos de implantação para Modelos de Foundry.

Agentes, avaliações e processamento em lote

Agentes, avaliações e trabalhos em lote são totalmente geridos pela Microsoft. As cargas de trabalho dos agentes correm dentro da infraestrutura de contentores da plataforma, que suporta a integração de redes virtuais para cenários isolados da rede. As avaliações invocam os pontos finais do modelo, comparam os resultados com critérios de avaliação e armazenam resultados dentro do âmbito do projeto. O processamento em lote coloca pedidos de inferência em fila para execução de forma assíncrona a um custo reduzido por token. Os resultados para os três tipos de carga de trabalho estão acessíveis através do portal ou SDK.

Integração com redes virtuais

Quando os seus agentes se ligam a sistemas externos, pode isolar o tráfego de rede usando injeção de containers, onde a plataforma injeta uma sub-rede na sua rede virtual, permitindo a comunicação local com os seus recursos Azure dentro da mesma rede virtual.

O Foundry suporta dois modelos de rede para isolamento de saída:

Modelo Como funciona Compromisso
VNet gerido pelo cliente (BYO) Forneces o VNet e uma sub-rede dedicada delegada a Microsoft.App/environments. A plataforma integra-se na sua sub-rede, permitindo a comunicação local com os seus recursos privados da Azure. Controlo total sobre a configuração da rede; Requer a tua própria gestão de rede.
Managed VNet (pré-visualização) A Foundry gere o VNet em teu nome. Configuração mais simples; Limita as opções de personalização. Para mais detalhes, consulte Configurar rede virtual gerida.

Nota

Alguns cenários isolados da rede requerem o SDK ou CLI em vez do portal. Por exemplo, implementações com endpoints privados que bloqueiam todo o acesso público não são configuráveis através da interface do portal. Para mais detalhes, veja Como configurar um link privado para o Foundry.

Isolamento do inquilino

As cargas de trabalho são executadas em ambientes logicamente isolados segundo os recursos da Foundry. O código do cliente não partilha contentores em tempo de execução com outros inquilinos.

Segurança de conteúdos e barreiras de proteção

A Foundry integra os controlos de segurança de conteúdo na linha de processo de inferência de modelos e agentes. As guardas definem riscos a detetar, pontos de intervenção a analisar (entrada e saída do utilizador, chamadas de ferramenta (pré-visualização) e respostas de ferramenta (pré-visualização)) e ações de resposta quando um risco é detetado. Os filtros de conteúdo funcionam em linha com os pedidos de modelo e podem ser configurados por implementação. Para mais informações, consulte Visão geral de guardrails e controlos e Níveis de severidade da filtragem de conteúdo.

Disponibilidade regional

As capacidades de computação variam consoante a região do Azure. A disponibilidade do modelo, as opções de tipo de implementação e o suporte a funcionalidades, como Agentes ou avaliações, podem diferir entre regiões. Confirme que a sua região de destino suporta as capacidades necessárias antes de provisionar. Para a disponibilidade atual, consulte Disponibilidade de funcionalidades entre regiões cloud.

Armazenamento de dados

A Foundry oferece opções flexíveis e seguras de armazenamento de dados para suportar uma vasta gama de cargas de trabalho em IA.

Armazenamento gerido para upload de ficheiros

Na configuração padrão, o Foundry utiliza contas de armazenamento geridas pela Microsoft que são logicamente separadas e suportam carregamento direto de ficheiros para casos de uso selecionados, como modelos OpenAI e Agentes, sem necessidade de uma conta de armazenamento fornecida pelo cliente.

Traga o seu próprio armazém de armazenamento

Pode, opcionalmente, ligar as suas próprias contas no Armazenamento do Azure. Ferramentas de fundição, como avaliações e processamento em lote, podem ler entradas e escrever saídas nestas contas. Para detalhes sobre cenários suportados, consulte Trazer os seus próprios recursos com o serviço de Agente.

Armazenamento do estado do agente

  • Com o basic agent setup, o serviço Agent armazena threads, mensagens e ficheiros em armazenamento multitenant gerido por Microsoft, com separação lógica.
  • Com a configuração de agente standard, traz os seus próprios recursos da Azure para todos os dados de clientes — incluindo ficheiros, conversas e armazenamentos em vetor. Nesta configuração, os dados são isolados por projeto dentro das suas contas de armazenamento.

Encriptação de chaves gerida pelo cliente

Por padrão, os serviços do Azure criptografam os dados em repouso e em trânsito usando chaves geridas pela Microsoft com criptografia AES de 256 bits compatível com FIPS 140-2. Não são necessárias alterações de código.

Para usar as suas próprias chaves para o Foundry, confirme estes pré-requisitos antes de ativar as chaves geridas pelo cliente:

  • O Key Vault está implementado na mesma região do Azure que o seu recurso Foundry.
  • A proteção contra eliminação suave e purga está ativada no Key Vault.
  • As identidades geridas requerem permissões de chave, como o papel Key Vault Crypto User ao usar Azure RBAC.

Traga o seu próprio Key Vault

Por defeito, o Foundry armazena todos os segredos de ligação baseados em chaves API num Azure Key Vault gerido. Se preferires gerir segredos por ti próprio, liga o teu cofre de chaves ao recurso Foundry. Uma ligação ao Azure Key Vault gere todos os segredos de ligação ao nível do projeto e dos recursos. Para mais informações, consulte como estabelecer uma ligação Azure Key Vault à Foundry.

Para saber mais sobre encriptação de dados, consulte chaves geridas pelo cliente para encriptação com a Foundry.

Residência de dados e conformidade

O Foundry armazena todos os dados em repouso na geografia designada do Azure. Os dados de inferência (prompts e completões) são processados de acordo com o tipo de implementação: as implementações globais podem ser encaminhadas para qualquer região de Azure, as implementações em zonas de dados mantêm-se dentro da zona dos EUA ou UE, e as implementações padrão ou regionais são processadas na região de implementação. Para mais detalhes, veja Tipos de implantação. A Foundry não suporta failover automático entre regiões. Se a sua organização necessitar de disponibilidade multi-região, implemente recursos Foundry separados em cada região-alvo e gere a sincronização e o encaminhamento de dados na camada de aplicação. Para obter detalhes sobre a certificação de conformidade, consulte documentação de conformidade do Azure.

Validar decisões de arquitetura

Antes de implementar, valide o seguinte para o seu ambiente alvo: