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 de 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 axée sur la conformité : votre organisation nécessite un réseau privé, un chiffrement géré par le client ou une portée RBAC Azure aux niveaux des ressources et des projets.
• Migration Azure OpenAI : vous passez d'une ressource Azure OpenAI autonome et souhaitez conserver les stratégies existantes ainsi que le 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 complétions Azure OpenAI sans hébergement d'agent ni évaluation, une ressource Azure OpenAI autonome pourrait être suffisante.

Azure types de ressources et fournisseurs d’IA

Dans la famille de produits IA Azure, 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 de fonderie partagent l'espace de noms du fournisseur Microsoft.CognitiveServices avec des services tels qu'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 affiche les types de ressources et les fonctionnalités spécifiques 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 de contrôle d’accès en fonction du rôle Azure (Azure RBAC), des configurations réseau et des alias similaires pour la configuration d'Azure Policy. Si vous effectuez une mise à niveau de Azure OpenAI vers Foundry, vos stratégies de Azure personnalisées existantes et Azure actions RBAC continuent à s'appliquer.

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 Key Vault et les Recherche Azure AI sont des ressources Azure distinctes sous leurs propres limites de gouvernance :

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

• RessourceFoundry : ressource de Azure de niveau supérieur où 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.
• Project : 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 de 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 auxquels la ressource Foundry fait référence par des 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 d'Azure reflètent cette séparation des responsabilités. 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 le contrôle d’accès basé sur les rôles pour Microsoft Foundry.

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

• Utilisateur Azure AI pour chaque principal d’utilisateur développeur au niveau de la ressource Foundry.
• Utilisateur Azure AI pour chaque identité managée de projet au niveau de la ressource Foundry.

Pour obtenir des instructions de planification des rôles et des étendues, consultez Contrôle d’accès en fonction du rôle pour Microsoft Foundry.

Surveillance et observabilité

Azure Monitor segmente les métriques par domaine. 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.
• Project-level metrics : résultats des exécutions d'évaluation, comptages d'invocations d'agents et activité des opérations sur les fichiers.
• Journalisation diagnostique : activez les paramètres de diagnostic pour acheminer les journaux vers Log Analytics, Stockage ou Event Hubs pour l’analyse et le stockage.

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

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 à des systèmes externes, vous pouvez isoler le trafic réseau à l’aide de l’injection de container, 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 (entrée utilisateur, sortie, appels d’outils (préversion) et réponses aux outils (préversion)) et les actions de réponse lorsqu’un risque est détecté. 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 Azure région. 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 les cas d’usage sélectionnés, 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 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 basic, le service Agent stocke les threads, les messages et les fichiers dans le stockage multilocataire géré par Microsoft, avec séparation logique.
• Avec la configuration de l’agent standard, vous apportez vos propres ressources de Azure pour toutes les données client, notamment 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 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 ont besoin d’autorisations de clé, telles que le rôle utilisateur Key Vault Crypto lors de l’utilisation de Azure RBAC.

Apportez votre propre 'Key Vault'

Par défaut, Foundry stocke tous les secrets de connexion basés sur une clé API dans un Azure Key Vault 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 how pour 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 désignée Azure. Les données d'inférence (invites et complétions) sont traitées en fonction du type de déploiement : les déploiements globaux peuvent être routés vers n’importe quelle région Azure, les déploiements de zones de données restent dans la zone des États-Unis ou de l'UE, et les déploiements standard ou régionaux sont traités dans leur propre région de déploiement. 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 Azure documentation de conformité.

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 basé sur des rôles 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 de 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 quotas et limites Azure OpenAI et limites, quotas et régions du service d'agent.

Contenu connexe

• Déploiement de Foundry dans mon organisation
• contrôle d’accès basé sur les rôles 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 Azure Monitor
• Quotas et limites d'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