Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Une plateforme IA est l’endroit où votre organisation exécute et exploite des modèles IA. Il fournit le périmètre réseau, le modèle d’identité, le plan de données et l’allocation de quota qui entourent vos modèles, déploiements, index, évaluations et ressources associées. Microsoft Foundry et Azure Machine Learning sont deux plateformes IA Azure. Chaque déploiement d’un service crée une nouvelle instance.
Votre organisation doit décider comment placer des environnements de charge de travail IA dans des instances de plateforme IA. Vous pouvez isoler chaque environnement tel que le développement, le test ou la production dans sa propre instance de plateforme. Vous pouvez également autoriser plusieurs charges de travail ou environnements à partager la même instance. Cette décision, souvent appelée colocation, détermine l’étendue des répercussions d’incidents opérationnels ou de sécurité. Elle affecte également les limites de conformité et le coût de la plateforme.
Recommandation: Établissez une stratégie à l’échelle de l’organisation qui définit les exigences d’isolation par défaut, les limites de partage approuvées, les critères d’exception et les attentes distinctes pour les environnements de plateforme IA de production et de préproduction.
Conseils de décision :
1. Définir des limites de partage de plateforme IA
Chaque organisation a besoin de limites sur lesquelles les charges de travail ne doivent jamais partager une instance de plateforme IA. Cette limite s’applique à chaque environnement, y compris les environnements de production et de préproduction. Les charges de travail à l’intérieur de la même limite peuvent potentiellement partager une instance de plateforme. Les charges de travail situées dans des périmètres différents ne le peuvent pas.
Pourquoi dessiner des limites de partage ? Sans limites clairement définies et partagées, les équipes responsables des charges de travail adoptent par défaut l’approche la plus pratique sur le moment, et la plateforme d’IA accumule des exigences contradictoires au fil du temps. Au fil du temps, il crée des modèles de propriété incohérents, des exigences de conformité en conflit, une allocation de coûts peu claire et un risque opérationnel partagé entre les charges de travail non liées. Par exemple, les zones métier non liées peuvent partager un quota sur la même instance de plateforme pour réduire les coûts. Le résultat est une plateforme IA avec des limites de gouvernance incohérentes qui deviennent difficiles à comprendre et à auditer.
Limites communes. Choisissez un modèle de limite qui s’aligne sur la façon dont votre organisation attribue déjà des responsabilités et régit les décisions technologiques. Les modèles courants sont les suivants :
Une limite d’unité commerciale optimise la propriété opérationnelle et le financement communs
Une limite de domaine de données optimise les exigences de conformité et de gestion des données courantes
Un périmètre Product Owner est conçu pour optimiser un cycle de vie d’ingénierie commun et les opérations de la plateforme
À l’intérieur de la limite, les équipes peuvent toujours choisir des instances de plateforme dédiées lorsque l’isolation est logique. En dehors de la limite, le partage n’est pas autorisé.
Trouvez ce qui fonctionne le mieux. Aucun modèle unique n’est universel. La cohérence importe plus que le modèle que vous sélectionnez, car un modèle de limite clairement appliqué conserve la gouvernance compréhensible à mesure que la plateforme IA augmente.
2. Définir une stratégie de partage de plateforme IA de production
Le partage de plateformes d’IA en production consiste à exécuter plusieurs environnements de charges de travail d’IA en production sur la même ressource Microsoft Foundry ou dans le même espace de travail Azure Machine Learning. Dans Azure, l’instance de plateforme IA définit la limite réseau, la limite d’identité et la limite de quota pour les environnements de charge de travail qui l’utilisent. Pour cette raison, les organisations doivent définir une stratégie spécifique pour le partage de plateforme IA de production.
2.1 Valeur par défaut d’une instance de plateforme IA unique par charge de travail de production
Les environnements IA de production doivent par défaut être isolés de l’environnement de production. Ne colocalisez pas plusieurs charges de travail de production sur la même ressource Microsoft Foundry ou Azure Machine Learning espace de travail, sauf si une exception documentée existe. Une instance de plateforme IA dédiée pour chaque environnement de charge de travail de production doit être l’approche standard. Traitez le partage de plateforme IA comme une exception, et non comme une pratique par défaut.
Pourquoi l’isolation par défaut ? Les plateformes IA partagées créent également un risque opérationnel partagé. Un problème de sécurité, une mauvaise configuration, une panne de service ou un événement d’épuisement de quota peut affecter chaque environnement de charge de travail colocalisé. L’isolation réduit également le risque d’exposition accidentelle à des accès entre charges de travail et empêche une charge de travail de monopoliser la capacité ou le quota GPU nécessaires à une autre charge de travail. Les environnements de production ont généralement l’impact commercial le plus élevé et l’exposition réglementaire. La plupart des organisations nécessitent des limites de propriété claires et une isolation opérationnelle forte pour ces environnements.
Compromis: L’isolation augmente les coûts et la surcharge de gestion. Chaque instance de plateforme effectue sa propre surcharge opérationnelle pour la mise en réseau, l’identité, la supervision et les opérations. Les organisations doivent équilibrer ces coûts par rapport aux avantages opérationnels et de sécurité de l’endiguement plus fort.
2.2 Autoriser la colocalisation de production par le biais d’une exception documentée
La colocalisation réduit la surcharge et consolide les opérations de plateforme. Par exemple, si des cas d’utilisation partagent les mêmes sources de données que les entrées, la colocalisation évite de devoir configurer la connectivité et l’authentification de la plateforme IA vers ces ressources pour chaque cas d’usage. Compromis : le partage d’instances de plateforme d’IA en production entraîne également la fusion du périmètre d’impact, du périmètre d’identité et du pool de quotas de chaque charge de travail qui partage l’instance.
Caractéristiques de la colocalisation : Autoriser uniquement les charges de travail de production à partager les instances de Microsoft Foundry ou d’Azure Machine Learning uniquement lorsque chacune des conditions suivantes est remplie :
Toutes les charges de travail colocalisées partagent la même étendue réglementaire, la classification des données, les exigences de résidence et les normes de gestion des données.
Toutes les charges de travail fonctionnent à l’intérieur de la même limite réseau, du même espace de noms DNS et de la même limite d’identité.
L’organisation accepte le risque de panne partagée et le risque d’épuisement de quota partagé introduit par la colocalisation.
Le coût ou la surcharge opérationnelle des instances distinctes l’emportent matériellement sur l’avantage d’isolation. La seule pression sur les coûts ne constitue pas une justification suffisante.
L’équipe accepte que le fractionnement des charges de travail par la suite est coûteux. L’état de la plateforme d’IA ne se transfère pas proprement entre les instances et nécessite souvent une recréation ou une reconfiguration.
Compromis: Chaque instance de plateforme IA partagée nécessite un propriétaire de plateforme clairement identifié responsable de la gestion des quotas, de la configuration réseau, des révisions d’accès, des opérations de cycle de vie et de la coordination des incidents.
2.3 Segmenter les cas d’usage de production au sein de l’instance de plateforme IA
Qu’une instance de plateforme soit isolée ou colocalisée, utilisez des fonctionnalités de segmentation dans le produit pour isoler les cas d’usage. Traitez chaque cas d’usage distinct, comme les expériences utilisateur entièrement distinctes au sein d’une seule charge de travail, comme son propre déploiement logique à l’intérieur de l’instance de plateforme. Par exemple:
Dans Microsoft Foundry, provisionnez un project par cas d’usage dans la ressource Foundry.
Dans Azure Machine Learning, utilisez un espace de travail hub avec des espaces de travail de projet pour segmenter les cas d’usage.
Ces constructions donnent à chaque cas d’usage ses propres ressources et attributions de rôles. Ils partagent un ensemble commun de composants d’infrastructure pour la sécurité et la connectivité. Vous n’avez pas besoin de provisionner une nouvelle instance pour chaque scénario.
Lorsque la colocalisation est autorisée dans le cadre du processus d’exception, faites passer cette séparation au sein du produit d’une recommandation à une exigence obligatoire imposée par la politique.
Si une charge de travail nécessite une segmentation complexe entre plusieurs projets Foundry ou Azure Machine Learning espaces de travail, réévaluez si le modèle de partage actuel offre toujours une simplicité opérationnelle et une isolation acceptables.
Pour en savoir plus sur les éléments sur lesquels reposent ces décisions, consultez les ressources Microsoft Foundry et les espaces de travail Azure Machine Learning.
3. Définir une stratégie de partage de plateforme IA de préproduction
Les environnements de préproduction inversent la valeur par défaut de production. Les environnements de préproduction incluent le développement, le test et la phase. Ces environnements prennent en charge l’expérimentation et la validation préliminaire. Les instances dédiées des ressources de la plateforme d’IA justifient rarement leur coût à ces niveaux. Valeur par défaut d’une instance partagée par niveau d’environnement.
Pourquoi opter pour la colocation en préproduction ? Une instance de plateforme IA de préproduction partagée permet aux équipes de réutiliser Azure infrastructure IA au lieu de provisionner des instances distinctes pour chaque nouveau cas d’usage. Les équipes de charge de travail peuvent réutiliser des modèles déployés, une connectivité réseau approuvée, des intégrations de données existantes et des configurations de sécurité établies. Cette approche accélère l’expérimentation et réduit le travail de configuration répété. Il est très utile lorsque les équipes commerciales évaluent la faisabilité de nouveaux scénarios d’IA ou la validation de solutions de première étape.
Quand ne pas colocaliser en préproduction. Utilisez une instance de préproduction dédiée par charge de travail lorsqu’une charge de travail traite les données réglementées dans un test ou doit mettre en miroir sa topologie de production pour la validation des performances. Traitez cette exigence comme une exception et exigez une approbation explicite avant l’approvisionnement.
Compromis : La colocalisation en préproduction réduit le coût des capacités inutilisées et permet de maintenir un inventaire de plateforme plus réduit. Toutefois, il expose chaque charge de travail aux interférences des expériences d’une autre équipe. Une tâche de réglage fin mal configurée ou une exécution d’évaluation incontrôlée peut épuiser un quota partagé et ralentir d’autres équipes. Les résultats des tests capturés sur une instance partagée ne prédisent pas toujours le comportement de production. Les charges de travail avec des besoins stricts en matière de validation des performances ou de conformité nécessitent un environnement dédié malgré le coût plus élevé.