Architecture multilocataire et Azure OpenAI Service
Azure OpenAI vous donne accès aux puissants modèles de langage d’OpenAI. Cet article décrit les principales fonctionnalités d’Azure OpenAI qui sont bénéfiques pour les solutions multilocataires. Consultez les ressources recommandées pour vous aider à planifier votre approche et à utiliser Azure OpenAI.
Modèles d’isolation
Lorsque vous disposez d’un système mutualisé qui utilise le service Azure OpenAI, vous devez décider du niveau d’isolation requis par vos locataires. Vous devez déterminer votre modèle d’isolation en fonction des facteurs suivants :
- Combien de locataires prévoyez-vous d’avoir ?
- Vos locataires ont-ils des exigences de conformité qui nécessitent l’isolation du réseau ou de l’infrastructure ?
- Vos locataires nécessitent-ils des modèles affinés sur leurs propres données ?
- Vos locataires nécessitent-ils des versions de modèle ou des cycles de vie de modèle différents ?
Le tableau suivant récapitule les approches de déploiement que vous pouvez utiliser lors de l’utilisation d’Azure OpenAI Service dans un système multilocataire :
| Considération | Service Azure OpenAI dédié | Service Azure OpenAI partagé, déploiement de modèle dédié par locataire | Service Azure OpenAI partagé, déploiement de modèles partagés | Service Azure OpenAI fourni par le locataire |
|---|---|---|---|---|
| Isolation des données | Élevé | Moyenne | Faible | Élevé |
| Isolation des performances | Élevé | Élevée | Faible à moyenne, en fonction de l’utilisation de jeton par minute (TPM) pour chaque locataire. | Élevé |
| Complexité du déploiement | Faible à moyenne, en fonction du nombre de locataires. | Moyen, vous devez gérer les noms et quotas de déploiement. | Faible | Non applicable, géré par le client. |
| Complexité opérationnelle | Faible | Moyenne | Élevé | Faible pour le fournisseur, plus élevée pour le locataire. |
| Exemple de scénario | Déploiements à locataire unique nécessitant une isolation réseau à partir d’autres locataires. | Locataires avec un cycle de vie de modèle spécifique ou des exigences de réglage précis. | Des solutions multilocataires volumineuses avec une couche Application partagée. | Locataires avec des exigences de conformité ou de réglage spécifiques. |
Service Azure OpenAI dédié
Si vous êtes un fournisseur de services, envisagez de déployer une instance Azure OpenAI pour chaque locataire de votre abonnement Azure. Cette approche permet une isolation des données pour chaque locataire. Cela implique de déployer et gérer un nombre croissant de ressources Azure OpenAI à mesure que vous augmentez le nombre de locataires.
Utilisez cette approche si vous avez des déploiements d’applications distincts pour chaque locataire, ou si vous devez contourner les limitations, par exemple le quota ou la requête par minute. Si vous souhaitez obtenir plus d’informations, consultez Quotas et limites Azure OpenAI.
Le diagramme ci-après illustre le modèle d’Azure OpenAI pour chaque locataire dans l’abonnement du fournisseur.
Service Azure OpenAI partagé
Vous pouvez choisir de partager une instance d’Azure OpenAI entre plusieurs locataires. La ressource Azure OpenAI est déployée dans votre abonnement Azure (le fournisseur de services). Vous êtes responsable de sa gestion. Cette solution est la plus simple à implémenter, mais elle fournit le moins d’isolation des données et d’isolation des performances.
Le partage d’une ressource Azure OpenAI ne fournit pas de segmentation de sécurité pour chaque déploiement de modèle. Un locataire peut être en mesure d’utiliser un modèle qu’il n’est pas autorisé à utiliser. Pour cette raison, évitez de partager une instance Azure OpenAI lorsque vous utilisez des modèles affinés, car vous pouvez exposer des informations sensibles et autoriser l’accès non autorisé aux données ou ressources spécifiques au locataire.
Le partage d’une instance d’Azure OpenAI entre plusieurs locataires peut également entraîner un problème de voisin bruyant. Cela peut aussi causer une latence plus élevée pour certains locataires. Vous devez également rendre votre code d’application compatible avec l’architecture multilocataire. Par exemple, si vous souhaitez facturer à vos clients le coût de consommation d’une instance Azure OpenAI partagée, implémentez la logique pour compter le nombre total de jetons pour chaque locataire dans votre application.
Vous pouvez également déployer plusieurs instances Azure OpenAI partagées. Par exemple, si vous suivez le Modèle d’empreintes de déploiement, déployez une instance Azure OpenAI partagé dans chaque empreinte. Si vous déployez une solution multirégion, vous devez déployer Azure OpenAI dans chaque région pour :
- Évitez la latence du trafic interrégional ;
- Prendre en charge les exigences en matière de résidence des données ;
- Permettre l’utilisation d’Azure OpenAI régionaux au sein d’autres services qui nécessitent des déploiements de même région
Lorsque vous disposez d’une instance Azure OpenAI partagée, il est important de prendre en compte ses limites et de gérer votre quota.
Le diagramme suivant montre le modèle Azure OpenAI partagé.
Lorsque vous déployez un service Azure OpenAI partagé, vous pouvez décider si les déploiements de modèles au sein du service sont également partagés ou s’ils sont dédiés à des clients spécifiques.
Déploiement de modèles partagés entre locataires
Le partage d’un déploiement de modèle entre locataires simplifie votre charge opérationnelle, car vous avez moins de déploiements à gérer et les versions de modèle à suivre. Prévoyez d’utiliser un déploiement de modèle partagé si vous le pouvez et de créer uniquement des déploiements de modèles dédiés si vous avez besoin des fonctionnalités qu’ils offrent.
Déploiement de modèle dédié par locataire
Vous pouvez créer un déploiement de modèle pour chaque locataire ou pour les locataires qui ont des exigences particulières qui ne peuvent pas être remplies à l’aide d’un déploiement de modèle partagé. Les raisons courantes d’utiliser des déploiements de modèles dédiés pour un locataire sont les suivantes :
Gestion des quotas et des coûts : il facilite l’allocation TPM spécifique au locataire en suivant le nombre de jetons que chaque modèle utilise, ce qui vous permet d’allouer et de gérer précisément l’utilisation de chaque locataire. Si vous utilisez des unités de débit approvisionnées (PTU), vous pouvez affecter les unités de débit à des clients spécifiques et utiliser d’autres modèles de facturation pour d’autres clients.
Stratégies de filtrage de contenu : parfois, un locataire spécifique peut nécessiter une stratégie de filtrage de contenu unique, telle qu’une liste de blocs spécifique au locataire de mots non autorisés. Vous spécifiez la stratégie de filtrage de contenu au niveau de l’étendue d’un déploiement de modèle.
Types et versions de modèle : vous devrez peut-être utiliser différents modèles ou versions de modèle pour différents locataires. Un locataire peut également nécessiter son propre processus de gestion du cycle de vie du modèle.
Réglage précis spécifique au locataire : si vous créez des modèles affinés distincts pour chaque locataire, vous devez créer un déploiement de modèle distinct pour chaque modèle affiné.
N’oubliez pas que le réglage précis n’est pas nécessaire pour la plupart des cas d’usage. En règle générale, il est préférable de baser votre modèle à l’aide d’Azure OpenAI Sur vos données ou d’une autre approche de génération augmentée par récupération (RAG).
Résidence des données : cette approche prend en charge les exigences distinctes en matière de résidence des données. Par exemple, vous pouvez fournir un déploiement de modèle régional pour un locataire avec des besoins stricts en matière de résidence des données et utiliser un déploiement de modèle global pour d’autres locataires sans besoins stricts.
Chaque déploiement de modèle a sa propre URL distincte, mais il est important de se rappeler que les modèles sous-jacents sont partagés avec d’autres clients Azure. Ils utilisent également une infrastructure Azure partagée.
Azure OpenAI n’applique pas le contrôle d’accès pour chaque déploiement de modèle. Par conséquent, votre application doit contrôler quel locataire peut atteindre le déploiement du modèle.
Ressource Azure OpenAI fournie par le locataire
Dans certains cas, vos locataires peuvent créer l’instance Azure OpenAI dans leurs propres abonnements Azure et lui accorder l’accès à votre application. Cette approche peut être appropriée dans les situations suivantes :
- Les locataires disposent de quotas et d’autorisations spécifiques de Microsoft, tels que l’accès à différents modèles, des stratégies de filtrage de contenu spécifiques ou l’utilisation du débit approvisionné.
- Le locataire dispose d’un modèle affiné qu’il doit utiliser à partir de votre solution.
- Ils nécessitent un composant dans leur environnement pour traiter et envoyer des données via leur instance Azure OpenAI gérée par le client pour le traitement.
Pour accéder à une instance OpenAI dans l’abonnement de votre locataire, le locataire doit en fournir l’accès à votre application. Votre application doit s’authentifier via son instance Microsoft Entra. Une approche consiste à publier une application Microsoft Entra multilocataire. Le flux de travail suivant décrit les étapes de cette approche :
- Le locataire enregistre l’application Microsoft Entra multilocataire dans son propre locataire Microsoft Entra.
- Le locataire accorde à l’application Microsoft Entra multilocataire le niveau d’accès approprié à sa ressource Azure OpenAI. Par exemple, le locataire peut affecter l’application au rôle d’utilisateur des services Azure AI à l’aide du contrôle d’accès en fonction du rôle (RBAC).
- Le locataire fournit l’ID de ressource de la ressource Azure OpenAI qu’il crée.
- Votre code d’application peut utiliser un principal de service associé à l’application Microsoft Entra multilocataire dans votre propre instance Microsoft Entra, pour accéder à l’instance Azure OpenAI du locataire.
En guise d’alternative, vous pouvez demander à chaque locataire de créer un principal de service utilisable par votre service, et de vous fournir ses informations d’identification. Cette approche nécessite que vous stockiez et gériez de manière sécurisée les informations d’identification pour chaque locataire, ce qui constitue un risque potentiel en matière de sécurité.
Si vos locataires configurent des contrôles d’accès réseau sur leur instance Azure OpenAI, vérifiez que vous pouvez y accéder.
Le diagramme ci-après illustre le modèle d’Azure OpenAI pour chaque locataire dans l’abonnement du locataire.
Fonctionnalités d’Azure OpenAI Service qui prennent en charge l’architecture mutualisée
Assistants API
L’API Assistants ajoute des fonctionnalités à votre service Azure OpenAI qui lui permet de créer des assistants IA. Il inclut la possibilité d’appeler des outils et des API, ainsi que des fichiers de recherche pour mettre en place les réponses générées par le modèle. Il permet aux threads conversationnels persistants d’être gérés par le service, et il peut générer et exécuter du code dans un environnement bac à sable (sandbox). Pour prendre en charge ces fonctionnalités, l’API Assistants doit stocker certaines données.
Lorsque vous utilisez l’API Assistants dans une solution mutualisée, vous pouvez choisir de créer des assistants dédiés à un seul locataire ou de partager un assistant entre plusieurs locataires. Il est important que vous considériez l’isolation du locataire dans toutes les données stockées, en particulier pour les assistants partagés. Par exemple, vous devez vous assurer que les threads conversationnels sont stockés séparément pour chaque locataire.
L’API Assistants prend en charge l’appel de fonction, qui envoie vos instructions d’application sur les fonctions à appeler et à inclure des arguments. Vérifiez que les appels de fonctions que vous effectuez sont multilocataires, par exemple en incluant l’ID de locataire dans l’appel au système en aval. Vérifiez l’ID de locataire au sein de votre application et ne vous fiez pas au modèle de langage pour propager l’ID de locataire pour vous.
Azure OpenAI sur vos données
Azure OpenAI On Your Data permet au modèle de langage volumineux d’interroger directement des sources de connaissances, telles que des index et des bases de données, dans le cadre de la génération d’une réponse à partir du modèle de langage.
Lorsque vous effectuez une requête, vous pouvez spécifier les sources de données qui doivent être interrogées. Dans une solution mutualisée, assurez-vous que vos sources de données sont multilocataires et que vous pouvez spécifier des filtres de locataire sur vos demandes. Propagez l’ID de locataire de manière appropriée à la source de données. Par exemple, supposons que vous interrogez Recherche Azure AI. Si vous avez des données pour plusieurs locataires dans un seul index, spécifiez un filtre pour limiter les résultats récupérés à l’ID du locataire actuel. Ou, si vous avez créé un index pour chaque locataire, vérifiez que vous spécifiez l’index approprié pour le locataire actuel.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Sofia Ferreira | Software Engineer, ISV & DN CoE
Autres contributeurs :
- John Downs | Ingénieur logiciel principal
- Landon Pierce | Customer Engineer, ISV & DN CoE
- Paolo Salvatori | Principal Customer Engineer, ISV & DN CoE
- Daniel Scott-Raynsford | Architecte de solution partenaire
- Arsen Vladimirskiy | Principal Customer Engineer, ISV & DN CoE
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.