Partager des modèles dans des espaces de travail
Important
Databricks recommande d’utiliser des modèles dans Unity Catalog pour partager des modèles entre les espaces de travail. L'approche décrite dans cet article est obsolète.
Azure Databricks prend en charge le partage de modèles dans plusieurs espaces de travail. Par exemple, vous pouvez développer et journaliser un modèle dans un espace de travail de développement, puis y accéder et le comparer à des modèles situés dans un espace de travail de production distinct. Cela est utile lorsque plusieurs équipes partagent l'accès aux modèles ou lorsque votre organisation dispose de plusieurs espaces de travail pour gérer les différentes étapes du développement. Pour le développement et le déploiement de modèles entre espaces de travail, Databricks recommande l’approche « déploiement du code », où le code d’entraînement du modèle est déployé sur plusieurs environnements.
Dans les situations d’espaces de travail multiples, vous pouvez accéder aux modèles dans les espaces de travail Azure Databricks en utilisant un registre de modèles distant. Par exemple, les scientifiques des données peuvent accéder au registre de modèles de production en lecture seule pour comparer leurs modèles en développement aux modèles de production actuels. Vous trouverez ci-dessous l’illustration d’un exemple de configuration pour plusieurs espaces de travail.
L’accès à un registre distant est contrôlé par des jetons. Chaque utilisateur ou script nécessitant un accès crée un jeton d’accès personnel dans le registre distant, puis copie ce jeton dans le gestionnaire de secrets de son espace de travail local. Chaque requête d’API envoyée à l’espace de travail du registre distant doit inclure le jeton d’accès. MLflow fournit un mécanisme simple pour spécifier les secrets à utiliser au moment de l’exécution des opérations relatives au registre de modèles.
Notes
En guise de bonne pratique de sécurité, quand vous vous authentifiez avec des outils, systèmes, scripts et applications automatisés, Databricks recommande d’utiliser des jetons d’accès personnels appartenant à des principaux de service et non des utilisateurs de l’espace de travail. Pour créer des jetons d’accès pour des principaux de service, consultez la section Gérer les jetons pour un principal de service.
Toutes les méthodes d’API client et Fluent pour le registre de modèles sont prises en charge pour les espaces de travail distants.
Spécifications
L’utilisation d’un registre de modèles sur des espaces de travail requiert le client python MLflow, Release 1.11.0 ou version ultérieure.
Notes
Ce flux de travail est implémenté à partir de la logique dans le client MLflow. Vérifiez que l’environnement d’exécution du client dispose de l’accès nécessaire pour effectuer des requêtes réseau vers l’espace de travail Azure Databricks contenant le registre de modèles distant. Une restriction courante placée sur l’espace de travail du Registre est une liste verte d’IP, qui peut interdire les connexions à partir de clients MLflow s’exécutant dans un cluster d’un autre espace de travail.
Configurer le jeton d’API pour un registre distant
- Dans l'espace de travail du registre des modèles, créez un jeton d'accès.
- Dans l’espace de travail local, créez des secrets pour stocker le jeton d’accès et les informations de l’espace de travail distant :
- Créez une étendue de secrets :
databricks secrets create-scope <scope>. - Choisissez un nom unique pour l’espace de travail cible, illustré ici sous la forme
<prefix>. Puis créez trois secrets :databricks secrets put-secret <scope> <prefix>-host: Entrez le nom d’hôte de l’espace de travail du registre de modèles. Par exemple,https://westus.azuredatabricks.net/ouhttps://adb-5555555555555555.19.azuredatabricks.net/.databricks secrets put-secret <scope> <prefix>-token: Entrez le jeton d’accès de l’espace de travail modèle Registry.databricks secrets put-secret <scope> <prefix>-workspace-id: entrez l’ID de l’espace de travail du magasin de caractéristiques qui se trouve dans l’URL de n’importe quelle page.
- Créez une étendue de secrets :
Remarque
Vous pouvez partager l’étendue du secret avec d’autres utilisateurs, car il existe une limite quant au nombre d’étendues secrètes par espace de travail.
Spécifier un Registre distant
Sur la base de la portée secrète et du préfixe de nom que vous avez créés pour l'espace de travail du registre distant, vous pouvez construire une URI de registre sous la forme suivante :
registry_uri = f'databricks://<scope>:<prefix>'
Vous pouvez utiliser l’URI pour spécifier un Registre distant pour les méthodes de l' API Fluent en appelant d’abord :
mlflow.set_registry_uri(registry_uri)
Vous pouvez le spécifier explicitement quand vous instanciez un MlflowClient :
client = MlflowClient(registry_uri=registry_uri)
Les flux de travail suivants présentent des exemples des deux approches.
Inscrire un modèle dans le Registre distant
Une façon d’inscrire un modèle consiste à utiliser l' API mlflow.register_model :
mlflow.set_registry_uri(registry_uri)
mlflow.register_model(model_uri=f'runs:/<run-id>/<artifact-path>', name=model_name)
Vous trouverez des exemples pour d’autres méthodes d’inscription du modèle dans le bloc-notes à la fin de cette page.
Notes
L’inscription d’un modèle dans un espace de travail distant crée une copie temporaire des artefacts de modèle dans DBFS dans l’espace de travail distant. Vous souhaiterez peut-être supprimer cette copie une fois que la version du modèle est dans l’État READY. Les fichiers temporaires se trouvent dans le dossier /dbfs/databricks/mlflow/tmp-external-source/<run-id>.
Vous pouvez également spécifier une tracking_uri valeur pour pointer vers un service de suivi MLflow dans un autre espace de travail de la même manière registry_uri. Cela signifie que vous pouvez effectuer une exécution sur un espace de travail distant et inscrire son modèle dans l’espace de travail actuel ou dans un autre espace de travail distant.
Utiliser un modèle à partir du Registre distant
Vous pouvez charger et utiliser une version de modèle dans un Registre distant avec des méthodes mlflow.<flavor>.load_model en définissant d’abord l’URI de Registre :
mlflow.set_registry_uri(registry_uri)
model = mlflow.pyfunc.load_model(f'models:/<model-name>/Staging')
model.predict(...)
Ou vous pouvez spécifier explicitement le Registre distant dans l'URI models:/ :
model = mlflow.pyfunc.load_model(f'models://<scope>:<prefix>@databricks/<model-name>/Staging')
model.predict(...)
D’autres méthodes d’assistance pour accéder aux fichiers de modèle sont également prises en charge, telles que :
client.get_latest_versions(model_name)
client.get_model_version_download_uri(model_name, version)
Inscrire un modèle dans le Registre distant
Vous pouvez effectuer n’importe quelle action sur les modèles dans le Registre distant, à condition que vous disposiez des autorisations nécessaires. Par exemple, si vous disposez des autorisations PEUT GÉRER sur un modèle, vous pouvez effectuer la transition d’une étape de version de modèle ou supprimer le modèle à l’aide de méthodes MlflowClient :
client = MlflowClient(tracking_uri=None, registry_uri=registry_uri)
client.transition_model_version_stage(model_name, version, 'Archived')
client.delete_registered_model(model_name)
Exemple de notebook : registre de modèle distant
Le notebook suivant s’applique aux espaces de travail qui ne sont pas activés pour Unity Catalog. Il explique comment journaliser des modèles sur le serveur de suivi MLflow à partir de l’espace de travail actuel et inscrire les modèles dans le Registre de modèles dans un autre espace de travail. Databricks recommande d’utiliser des modèles dans Unity Catalog pour partager des modèles entre les espaces de travail.