L'architecture de Microsoft Foundry

Microsoft Foundry organise les charges de travail IA via une architecture en couches : une ressource Foundry de niveau supérieur pour la gouvernance, les projets pour l’isolation du développement et les services Azure connectés pour le stockage, la recherche et la gestion des secrets.

Cet article fournit aux équipes informatiques et aux équipes de sécurité des informations détaillées sur la ressource Foundry et l’architecture de service Azure sous-jacente, ses composants et sa relation avec d’autres types de ressources Azure. Utilisez ces informations pour guider la personnalisation de votre déploiement Foundry en fonction des exigences de votre organisation. Pour plus d’informations sur le déploiement de Foundry dans votre organisation, consultez Foundry Rollout.

Quand utiliser cette architecture

Prenez en compte le modèle de ressource Foundry lorsque votre scénario implique :

• Configuration initiale : vous démarrez un nouveau projet IA et souhaitez une ressource unique qui regroupe l’accès aux modèles, l’hébergement d’agents et les outils d’évaluation.
• Accès à plusieurs équipes : plusieurs équipes ont besoin de projets isolés avec des déploiements de modèles partagés et une gouvernance centralisée.
• Conception basée sur la conformité : votre organisation nécessite une mise en réseau privée, un chiffrement géré par le client ou une étendue RBAC Azure au niveau des ressources et des projets.
• Migration d’Azure OpenAI : vous passez d’une ressource Azure OpenAI autonome et souhaitez conserver les stratégies existantes et RBAC tout en ajoutant des fonctionnalités d’agent et d’évaluation.

Pour l’exploration à développeur unique, une ressource Foundry avec un projet est la valeur par défaut recommandée. Si votre charge de travail nécessite uniquement des achèvements Azure OpenAI sans hébergement ou évaluation d’agent, une ressource Azure OpenAI autonome peut être suffisante.

Types et fournisseurs de ressources Azure AI

Dans la famille de produits Azure AI, vous pouvez utiliser ces fournisseurs de ressources Azure qui prennent en charge les besoins des utilisateurs dans différentes couches de la pile.

Pour la plupart des scénarios de développement d’IA, notamment la création d’agents, le déploiement de modèles et les flux de travail d’évaluation, la ressource Foundry est le point de départ recommandé. Les ressources Foundry partagent l’espace de noms du fournisseur Microsoft.CognitiveServices avec des services comme Azure OpenAI, Speech, Vision et Language. Cet espace de noms de fournisseur partagé permet d’aligner les API de gestion, les modèles de contrôle d’accès, la mise en réseau et le comportement de stratégie entre les ressources IA associées.

Utilisez le tableau suivant pour identifier le type de ressource correspondant à votre charge de travail. Il montre les types et fonctionnalités de ressources spécifiques au sein du fournisseur Microsoft.CognitiveServices :

Les types de ressources sous les mêmes espaces de noms de fournisseur partagent les mêmes API de gestion et utilisent des actions similaires de contrôle d’accès en fonction du rôle Azure (Azure RBAC), des configurations réseau et des alias pour la configuration d’Azure Policy. Si vous effectuez une mise à niveau d’Azure OpenAI vers Foundry, vos stratégies Azure personnalisées existantes et les actions RBAC Azure continuent d’être appliquées.

Hiérarchie des ressources Foundry

Le diagramme suivant illustre une ressource Foundry avec des déploiements de modèles, des paramètres de sécurité, des connexions et deux projets. Les services Azure connectés tels que le stockage, Le coffre de clés et Recherche Azure AI sont des ressources Azure distinctes dans leurs propres limites de gouvernance :

Utilisez ce modèle lors de la planification de l’architecture et des limites d’accès :

• Ressource Foundry : ressource Azure de niveau supérieur dans laquelle vous gérez les paramètres de gouvernance tels que la mise en réseau, la sécurité et les déploiements de modèles.
• Projet : Limite de développement à l’intérieur de la ressource Foundry où les équipes créent et évaluent les cas d’usage. Les projets permettent aux équipes de prototyper dans un environnement préconfiguré, de réutiliser les déploiements et connexions de modèles existants sans configuration informatique répétée.
• Ressources du projet : fichiers, agents, évaluations et artefacts associés délimités à un projet.
• Ressources connectées : services Azure tels que Stockage, Key Vault et Recherche Azure AI référencées par les ressources Foundry par le biais de connexions. Ces ressources ont des limites de gouvernance distinctes. Vous gérez donc indépendamment leurs stratégies de mise en réseau et d’accès.

Cette séparation permet aux équipes informatiques d’appliquer des contrôles centralisés au niveau des ressources pendant que les équipes de développement travaillent dans des limites au niveau du projet.

Séparation des préoccupations motivée par la sécurité

Foundry applique une séparation claire entre les opérations de gestion et de développement pour garantir des charges de travail IA sécurisées et évolutives.

Gouvernance des ressources de niveau supérieur

La gestion des ressources Foundry de premier niveau inclut des opérations telles que la configuration de la sécurité, l'établissement d'une connectivité avec d'autres services Azure, et la gestion des déploiements. Les conteneurs de projets dédiés isolent les activités de développement et fournissent des limites pour le contrôle d’accès, les fichiers, les agents et les évaluations.

Contrôle d’accès en fonction du rôle

Les actions RBAC Azure reflètent cette séparation des préoccupations. Les actions de plan de contrôle, telles que la création de déploiements et de projets, sont distinctes des actions de plan de données, telles que la création d’agents, l’exécution d’évaluations et le chargement de fichiers. Vous pouvez définir la portée des affectations RBAC à la fois au niveau des ressources de niveau supérieur et au niveau des projets individuels. Attribuez des identités managées à l'un des niveaux disponibles pour prendre en charge l'automatisation sécurisée et l'accès aux services. Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle pour Microsoft Foundry.

Les tâches initiales courantes pour l’intégration avec le moins de privilèges sont les suivantes :

• Utilisateur Foundry pour chaque principal utilisateur du développeur dans le cadre de la ressource Foundry.

  Important

  Les rôles Foundry RBAC ont été récemment renommés. Foundry User, Foundry Owner, Propriétaire du compteFoundry et Foundry Project Manager ont été précédemment nommés Azure utilisateur IA, Azure propriétaire d’IA, propriétaire Azure compte IA et Azure gestionnaire Project IA. Il se peut que vous voyiez encore les anciens noms à certains endroits pendant le déploiement de ce changement de nom. Les ID de rôle et les autorisations de base ne sont pas modifiés par ce changement de nom.

• Foundry User pour chaque identité managée du projet au niveau de la ressource Foundry.

Pour obtenir des instructions relatives à la planification des rôles et de l’étendue, consultez le contrôle d’accès en fonction du rôle pour Microsoft Foundry.

Surveillance et observabilité

Azure Monitor segmente les métriques par étendue. Vous pouvez afficher les métriques de gestion et d’utilisation au niveau de la ressource de niveau supérieur, tandis que les métriques spécifiques au projet, telles que les performances d’évaluation ou l’activité de l’agent, sont étendues aux conteneurs de projet individuels.

Les principales fonctionnalités de supervision sont les suivantes :

• Métriques au niveau des ressources : consommation de jetons, latence du modèle, nombre de demandes et taux d’erreur dans tous les projets.
• Métriques au niveau du projet : résultats de l’exécution d’évaluation, nombre d’invocations d’agent et activité des opérations de fichier.
• Journalisation diagnostique : Activez les paramètres de diagnostic pour router les journaux vers Log Analytics, Azure Storage ou Event Hubs afin de permettre leur analyse et leur conservation.

Pour plus d’informations, consultez la vue d’ensemble d’Azure Monitor.

Infrastructure informatique

Foundry gère l’infrastructure de calcul pour l’hébergement de modèles, l’exécution de l’agent et le traitement par lots. Cette section traite des types de déploiement, de l’infrastructure d’agent et d’évaluation, de l’intégration de réseau virtuel, de l’isolation du locataire, des contrôles de sécurité du contenu et de la disponibilité régionale.

Types de déploiement de modèle

Foundry prend en charge plusieurs types de déploiement pour l’hébergement de modèle, regroupés par étendue de traitement des données : global (interrégion), zone de données (dans une limite définie) et régionale (région unique). Chaque type équilibre la latence, le débit et l’emplacement de traitement des données différemment :

Pour plus d’informations sur la façon de choisir le type de déploiement approprié, consultez Types de déploiement pour les modèles Foundry.

Agents, évaluations et traitement par lots

Les agents, les évaluations et les travaux par lots sont entièrement gérés par Microsoft. Les workloads des agents s’exécutent à l’intérieur de l’infrastructure de conteneurs de la plateforme, qui prend en charge l’intégration du réseau virtuel pour les scénarios isolés par le réseau. Les évaluations invoquent des points de terminaison du modèle, comparent les résultats aux critères de notation et stockent les résultats dans l’étendue du projet. Les demandes d'inférence sont traitées par lots pour une exécution asynchrone à un coût réduit par jeton. Les résultats des trois types de charge de travail sont accessibles via le portail ou le Kit de développement logiciel (SDK).

Intégration de réseau virtuel

Lorsque vos agents se connectent avec des systèmes externes, vous pouvez isoler le trafic réseau à l’aide de l’injection de conteneurs, où la plateforme injecte un sous-réseau dans votre réseau virtuel, ce qui permet une communication locale avec vos ressources Azure au sein du même réseau virtuel.

Foundry prend en charge deux modèles de mise en réseau pour l’isolation sortante :

Isolation des clients

Les charges de travail fonctionnent dans des environnements logiquement isolés pour chaque ressource Foundry. Le code client ne partage pas de conteneurs d’exécution avec d’autres locataires.

Sécurité du contenu et garde-fous

Foundry intègre les contrôles de sécurité du contenu dans le pipeline d’inférence du modèle et de l’agent. Les garde-fous définissent les risques pour détecter, les points d’intervention à analyser et les actions de réponse lorsqu’un risque est détecté. Les points d’intervention incluent la saisie utilisateur, la sortie, les appels d’outils (aperçu) et les réponses des outils (aperçu). Les filtres de contenu s’exécutent en ligne avec des demandes de modèle et peuvent être configurés par déploiement. Pour plus d’informations, consultez la vue d’ensemble des garde-fous et des contrôles et les niveaux de gravité du filtrage du contenu.

Disponibilité régionale

Les fonctionnalités de calcul varient selon la région Azure. La disponibilité des modèles, les options de type de déploiement et la prise en charge des fonctionnalités telles que les agents ou les évaluations peuvent différer entre les régions. Vérifiez que votre région cible prend en charge les fonctionnalités requises avant l’approvisionnement. Pour connaître la disponibilité actuelle, consultez La disponibilité des fonctionnalités dans les régions cloud.

Stockage de données

Foundry fournit des options de stockage de données flexibles et sécurisées pour prendre en charge un large éventail de charges de travail IA.

Stockage managé pour le chargement de fichiers

Dans la configuration par défaut, Foundry utilise des comptes de stockage gérés par Microsoft qui sont séparés logiquement et prennent en charge les chargements directs de fichiers pour certains cas d’usage, tels que les modèles OpenAI et les agents, sans nécessiter de compte de stockage fourni par le client.

Apportez votre propre stockage

Vous pouvez éventuellement connecter vos propres comptes de stockage Azure. Les outils de fonderie tels que les évaluations et le traitement par lots peuvent lire les entrées et générer des résultats vers ces comptes. Pour plus d’informations sur les scénarios pris en charge, consultez Apportez vos propres ressources avec le service Agent.

Stockage de l’état de l’agent

• Avec la configuration de l’agent de base, le service Agent stocke les threads, les messages et les fichiers dans le stockage multilocataire géré par Microsoft, avec une séparation logique.
• Avec la configuration de l’agent standard, vous apportez vos propres ressources Azure pour toutes les données client, y compris les fichiers, les conversations et les magasins vectoriels. Dans cette configuration, les données sont isolées par projet au sein de vos comptes de stockage.

Chiffrement de clé gérée par le client

Par défaut, les services Azure chiffrent les données au repos et en transit à l’aide de clés gérées par Microsoft avec le chiffrement AES conforme à FIPS 140-2 256 bits. Aucune modification du code n’est requise.

Pour utiliser vos propres clés à la place, confirmez ces prérequis avant d’activer les clés gérées par le client pour Foundry :

• Key Vault est déployé dans la même région Azure que votre ressource Foundry.
• La suppression douce et la protection contre la purge sont activées sur Key Vault.
• Les identités managées disposent d’autorisations de clé requises, telles que le rôle utilisateur de chiffrement Key Vault lors de l’utilisation d’Azure RBAC.

Apportez votre propre coffre de clés

Par défaut, Foundry stocke tous les secrets de connexion basés sur une clé API dans un coffre de clés Azure managé. Si vous préférez gérer vous-même les secrets, connectez votre coffre de clés à la ressource Foundry. Une connexion Azure Key Vault gère tous les secrets de connexion au niveau du projet et des ressources. Pour plus d’informations, consultez comment configurer une connexion Azure Key Vault à Foundry.

Pour en savoir plus sur le chiffrement des données, consultez les clés gérées par le client pour le chiffrement avec Foundry.

Résidence et conformité des données

Foundry stocke toutes les données au repos dans la zone géographique Azure désignée. Les données d’inférence (invites et achèvements) sont traitées en fonction du type de déploiement : les déploiements globaux peuvent être acheminés vers n’importe quelle région Azure, les déploiements de zone de données restent au sein de la zone États-Unis ou de l’UE, tandis que les déploiements standards ou régionaux sont traités dans leur région de déploiement respective. Pour plus d’informations, consultez Types de déploiement. Foundry ne prend pas en charge le basculement interrégion automatique. Si votre organisation nécessite une disponibilité multirégion, déployez des ressources Foundry distinctes dans chaque région cible et gérez la synchronisation et le routage des données au niveau de la couche Application. Pour plus d’informations sur la certification de conformité, consultez la documentation relative à la conformité Azure.

Valider les décisions d’architecture

Avant le déploiement, validez les éléments suivants pour votre environnement cible :

• Vérifiez que les modèles et fonctionnalités requis sont disponibles dans vos régions de déploiement. Pour plus d’informations, consultez La disponibilité des fonctionnalités dans les régions cloud.
• Vérifiez que les attributions de rôles sont limitées correctement aux niveaux de ressource Foundry et de projet. Pour plus d’informations, consultez contrôle d’accès en fonction du rôle pour Microsoft Foundry.
• Valider les exigences d’isolation réseau et les chemins d’accès privés. Pour plus d’informations, consultez Comment configurer une liaison privée pour Foundry.
• Vérifiez les exigences de chiffrement et de gestion des secrets, notamment les clés gérées par le client et l’intégration d’Azure Key Vault. Pour plus d’informations, consultez les clés gérées par le client pour le chiffrement avec Foundry et comment configurer une connexion Azure Key Vault à Foundry.
• Passez en revue les quotas et les limites de vos ressources cibles, y compris les limites de déploiement de modèle et les limites de débit. Pour plus d’informations, consultez les quotas et limites d’Azure OpenAI et les limites du service d’agent, les quotas et les régions.

Contenu connexe

• Déploiement de Foundry dans mon organisation
• Contrôle d’accès en fonction du rôle pour Microsoft Foundry
• Clés gérées par le client pour le chiffrement avec Foundry
• Comment configurer une liaison privée pour Foundry
• Apportez vos propres ressources avec le service Agent
• Vue d’ensemble d’Azure Monitor
• Quotas et limites Azure OpenAI
• Types de déploiement pour les modèles Foundry
• Vue d’ensemble des garde-fous et des contrôles
• Disponibilité des fonctionnalités dans les régions cloud