Registre des modèles de Snowflake

Note

L’API de registre des modèles décrite dans cette rubrique est généralement disponible à partir de la version 1.5.0 du paquet.

Après l’entraînement d’un modèle, l’opérationnalisation du modèle et l’exécution de l’inférence dans Snowflake commencent par connecter le modèle dans le Snowflake Model Registry. Le registre de modèles vous permet de gérer en toute sécurité les modèles et leurs métadonnées dans Snowflake, quels que soient leur origine et leur type, et facilite l’exécution de l’inférence. Les avantages et capacités clés du Snowflake Model Registry sont les suivants :

  • Possibilité de stocker et de gérer les versions du modèle, les métriques du modèle et d’autres métadonnées du modèle

  • Possibilité de servir des modèles et d’exécuter une inférence distribuée à l’échelle en utilisant Python, SQL ou les points terminaison de l’API REST

  • Possibilité de gérer le cycle de vie des modèles avec des options de gouvernance flexibles et de travailler avec des modèles des environnements dev à prod

  • Possibilité de contrôler la performance et la migration du modèle à l’aide de Snowflake ML Observability

  • Possibilité de gérer en toute sécurité l’accès aux modèles grâce à un contrôle d’accès basé sur les rôles

Le registre des modèles stocke les modèles de machine learning en tant qu’objets de première classe au niveau du schéma dans Snowflake.

Après avoir connecté un modèle, vous pouvez invoquer ses méthodes (équivalentes à des fonctions ou des procédures stockées) pour effectuer des opérations sur le modèle, telles que l”inférence, dans un entrepôt virtuel Snowflake ou servir le modèle dans Snowpark Container Services pour l’inférence basée sur GPU.

Le Snowflake Model Registry dispose de prise en charge de types intégrés pour les types de modèles les plus courants, y compris scikit-learn, xgboost, LightGBM, PyTorch, TensorFlow, les pipelines Hugging Face et les modèles pyfuncMLFlow. Le registre de modèles est également suffisamment souple et puissant pour prendre en charge vos propres modèles préalablement formés, ainsi que tout code de traitement personnalisé.

Astuce

Vous trouverez des exemples de ces types de modèles avec des flux de travail de bout en bout sur Exemples et démarrages rapides.

Les principales classes de l’API Python du Snowflake Model Registry sont les suivantes :

Cette rubrique décrit comment effectuer des opérations de registre dans Python à l’aide de la bibliothèque snowflake-ml-python. Vous pouvez également effectuer de nombreuses opérations de registre dans SQL ; voir Registre de modèles SQL.

Privilèges requis

Pour créer un modèle, vous devez posséder le schéma dans lequel le modèle est créé ou avoir le privilège CREATE MODEL sur ce schéma. Pour utiliser un modèle, vous devez en être le propriétaire ou avoir le privilège USAGE sur ce modèle. Le privilège USAGE permet aux bénéficiaires d’utiliser le modèle à des fins d’inférence sans pouvoir en voir les éléments internes. Pour donner aux utilisateurs l’accès à tous les modèles existants dans un schéma, utilisez le rôle GRANT USAGE ON ALL MODELS IN SCHEMA <du schéma> TO ROLE <>; Vous pouvez également donner aux utilisateurs l’accès aux futurs modèles créés automatiquement dans un schéma via GRANT USAGE ON FUTURE MODELS IN SCHEMA <rôle> TO ROLE <du schéma>;. .

Si le rôle d’un utilisateur a USAGE sur un modèle, il apparaît dans la page de registre des modèles de Snowsight. Pour plus de détails sur le fonctionnement des privilèges dans Snowflake, voir Privilèges de contrôle d’accès.

Note

Par défaut, les modèles ne prennent pas en charge la réplication. Cette fonction fait partie du bundle BCR 2024_08, que vous pouvez activer si vous avez besoin de la réplication des modèles. La fonction sera bientôt activée par défaut.

Limites actuelles

Les limites suivantes s’appliquent aux modèles et aux versions de modèles :

Modèles

  • Maximum de 1 000 versions

Versions du modèle

  • Maximum de 10 méthodes

  • Maximum de 10 importations

  • Maximum de 500 arguments par méthode

  • Maximum de métadonnées (y compris les métriques) de 100 KB

  • Taille maximale totale du modèle : 5 GB (pour les modèles déployés en entrepôt)

  • Taille maximale du fichier de configuration : 250 KB, y compris conda.yml et les autres fichiers manifestes que log_model génère en interne. (Si un modèle a de nombreuses fonctions et qu’elles ont toutes de nombreux arguments, par exemple, cette limite peut être dépassée.)

Ouverture du registre des modèles de Snowflake

Les modèles sont des objets Snowflake de première classe et peuvent être organisés au sein d’une base de données et d’un schéma avec d’autres objets Snowflake. Le registre des modèles de Snowflake fournit une classe Python pour la gestion des modèles au sein d’un schéma. Ainsi, tout schéma Snowflake peut être utilisé comme registre. Il n’est pas nécessaire d’initialiser ou de préparer un schéma à cette fin. Snowflake recommande de créer un ou plusieurs schémas dédiés à cet effet, comme ML.REGISTRY. Vous pouvez créer le schéma en utilisant CREATE SCHEMA.

Avant de pouvoir créer ou modifier des modèles dans le registre, vous devez ouvrir le registre. L’ouverture du registre renvoie une référence à celui-ci, que vous pouvez ensuite utiliser pour ajouter de nouveaux modèles et obtenir des références à des modèles existants.

from snowflake.ml.registry import Registry

reg = Registry(session=sp_session, database_name="ML", schema_name="REGISTRY")
Copy

Enregistrement des modèles et des versions

L’ajout d’un modèle au registre s’appelle la journalisation du modèle. Enregistrer un modèle en appelant la méthode log_model du registre. Cette méthode sérialise le modèle, un objet Python, et crée un objet modèle Snowflake à partir de celui-ci. Cette méthode ajoute des métadonnées, telles qu’une description, au modèle tel que spécifié dans l’appel log_model.

Chaque modèle peut avoir des versions illimitées. Pour enregistrer d’autres versions du modèle, appelez à nouveau log_model avec le même model_name mais un version_name différent.

Vous ne pouvez pas ajouter de balises à un modèle lorsqu’il est ajouté au registre, car les balises sont des attributs du modèle, et log_model ajoute une version spécifique du modèle, en créant uniquement un modèle lors de l’ajout de sa première version. Vous pouvez mettre à jour les balises du modèle après avoir journalisé la première version du modèle.

Dans l’exemple suivant, clf, abréviation de « classificateur », est l’objet modèle Python, qui a déjà été créé ailleurs dans votre code. Vous pouvez ajouter un commentaire au moment de l’enregistrement, comme indiqué ici. La combinaison du nom et de la version doit être unique dans le schéma. Vous pouvez spécifier des listes de conda_dependencies ; les paquets spécifiés seront déployés avec le modèle.

from snowflake.ml.model import type_hints
mv = reg.log_model(clf,
                   model_name="my_model",
                   version_name="v1",
                   conda_dependencies=["scikit-learn"],
                   comment="My awesome ML model",
                   metrics={"score": 96},
                   sample_input_data=train_features,
                   task=type_hints.Task.TABULAR_BINARY_CLASSIFICATION)
Copy

Les arguments de log_model sont décrits ici.

Arguments requis

Argument

Description

model

L’objet modèle Python d’un type de modèle pris en charge. Doit être sérialisable (« picklable »).

model_name

Le nom du modèle, utilisé avec version_name pour identifier le modèle dans le registre. Le nom ne peut pas être modifié une fois que le modèle a été journalisé. Il doit s’agir d’un identificateur Snowflake valide.

Note

La combinaison du nom du modèle et de la version doit être unique dans le schéma.

Arguments facultatifs

Argument

Description

version_name

Chaîne spécifiant la version du modèle, utilisée avec model_name pour identifier le modèle dans le registre. Il doit s’agir d’un identificateur Snowflake valide. S’il est absent, un nom de version lisible par l’homme est généré automatiquement.

code_paths

Répertorie des chemins d’accès aux répertoires de code à importer lors du chargement ou du déploiement du modèle.

comment

Commentaire, par exemple une description du modèle.

conda_dependencies

Liste des paquets Conda requis par votre modèle. Cet argument spécifie les noms des paquets et les versions optionnelles au format Conda, c’est-à-dire "[channel::]package [operator version]". Si vous ne spécifiez pas de canal, le canal Snowflake est pris en compte lorsque le modèle s’exécute sur un entrepôt. conda-forge est pris en compte pour les modèles s’exécutant sur Snowpark Container Services (SPCS).

ext_modules

Liste des modules externes à associer au modèle. Pris en charge par scikit-learn, Snowpark ML, PyTorch, TorchScript et les modèles personnalisés.

metrics

Dictionnaire contenant les métriques liées à la version du modèle.

options

Dictionnaire contenant des options pour la création de modèles. Les options suivantes sont disponibles pour tous les types de modèles :

  • embed_local_ml_library : intégrer ou non une copie de la bibliothèque locale de Snowpark ML dans le modèle. Par défaut : False.

  • relax_version : savoir s’il faut relâcher les contraintes de version des dépendances. Cela remplace les spécificateurs de version tels que ==x.y.z par des spécificateurs tels que <=x.y, <(x+1). Par défaut : True.

  • method_options : un dictionnaire d’options par méthode, où la clé est le nom d’une méthode et la valeur est un dictionnaire contenant une ou plusieurs des options décrites ici. Les options disponibles sont les suivantes :

    • case_sensitive : indique si la méthode et sa signature sont sensibles à la casse. Les méthodes sensibles à la casse doivent être mises entre guillemets lorsqu’elles sont utilisées en SQL. Cette option permet également d’utiliser des caractères non alphabétiques dans les noms de méthodes. Par défaut : False.

    • max_batch_size : taille maximale du lot que la méthode acceptera lorsqu’elle sera appelée dans l’entrepôt. Par défaut : None (la taille du lot est automatiquement déterminée).

Certains types de modèles peuvent proposer des options supplémentaires. Voir Utilisation des types de modèles intégrés.

pip_requirements

Liste des spécifications des paquets pour les paquets PyPI requis par votre modèle. Uniquement pris en charge pour les modèles s’exécutant dans Snowpark Container Services.

python_version

La version de Python sous laquelle le modèle sera exécuté. La valeur par défaut est None, qui désigne la dernière version disponible dans l’entrepôt.

sample_input_data

Un DataFrame qui contient des exemples de données d’entrée. Les noms des fonctions requises par le modèle, ainsi que leurs types, sont extraits de ce DataFrame. Cet argument ou signatures doit être fourni pour tous les modèles à l’exception des modèles Snowpark ML et MLFlow et des pipelines Hugging Face.

signatures

Signatures des méthodes du modèle en tant que mappage entre le nom de la méthode cible et les signatures d’entrée et de sortie. Cet argument ou sample_input_data doit être fourni pour tous les modèles à l’exception des modèles Snowpark ML et MLFlow et des pipelines Hugging Face.

task

La tâche définissant le problème que le modèle est censé résoudre. Si non spécifié, tous les efforts sont faits pour déduire la tâche du modèle à partir de la classe du modèle ou elle est définie sur type_hints.Task.UNKNOWN. Vérifiez snowflake.ml.model.type_hints pour toutes les options de tâches.

log_model renvoie un objet snowflake.ml.model.ModelVersion qui représente la version du modèle qui a été ajoutée au registre.

Une fois enregistré, le modèle lui-même ne peut pas être modifié (bien que vous puissiez modifier ses métadonnées). Pour supprimer un modèle et toutes ses versions, utilisez la méthode delete_model du registre.

Utilisation d’artefacts de modèles

Une fois qu’un modèle a été enregistré, ses artefacts (les fichiers qui soutiennent le modèle, y compris ses objets Python sérialisés et divers fichiers de métadonnées tels que son manifeste) sont disponibles sur une zone de préparation interne. Les artefacts ne peuvent pas être modifiés, mais vous pouvez voir ou télécharger les artefacts des modèles que vous possédez.

Note

Le fait d’avoir le privilège USAGE sur un modèle ne vous permet pas d’accéder à ses artefacts ; il faut en être propriétaire.

Vous pouvez accéder aux artefacts de modèle à partir d’une zone de préparation en utilisant, par exemple, la commande GET ou son équivalent dans Snowpark Python, FileOperation. get.

Cependant, vous ne pouvez pas vous adresser aux artefacts de modèle en utilisant la syntaxe habituelle des zones de préparation. Utilisez plutôt une snow:// URL, une manière plus générale de spécifier l’emplacement des objets dans Snowflake. Par exemple, une version à l’intérieur d’un modèle peut être spécifiée par une URL de la forme snow://model/<nom_modèle>/versions/<nom_version>/.

Connaissant le nom du modèle et la version souhaitée, vous pouvez utiliser la commande LIST pour voir les artefacts du modèle comme suit :

LIST 'snow://model/my_model/versions/V3/';
Copy

Le résultat ressemble à ceci :

name                                      size                  md5                      last_modified
versions/V3/MANIFEST.yml           30639    2f6186fb8f7d06e737a4dfcdab8b1350        Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/functions/apply.py      2249    e9df6db11894026ee137589a9b92c95d        Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/functions/predict.py    2251    132699b4be39cc0863c6575b18127f26        Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/model.zip             721663    e92814d653cecf576f97befd6836a3c6        Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/model/env/conda.yml          332        1574be90b7673a8439711471d58ec746        Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/model/model.yaml       25718    33e3d9007f749bb2e98f19af2a57a80b        Thu, 18 Jan 2024 09:24:37 GMT

Pour récupérer l’un de ces artefacts, utilisez la commande SQL GET.

GET 'snow://model/model_my_model/versions/V3/MANIFEST.yml'
Copy

Ou l’équivalent avec Snowpark Python :

session.file.get('snow://model/my_model/versions/V3/MANIFEST.yml', 'model_artifacts')
Copy

Note

Les noms et l’organisation des artefacts d’un modèle peuvent varier en fonction du type de modèle et peuvent changer. La liste d’artefacts de l’exemple précédent est donnée à titre d’exemple et ne fait pas autorité.

Suppression de modèles

Utilisez la méthode delete_model du registre pour supprimer un modèle et toutes ses versions :

reg.delete_model("mymodel")
Copy

Astuce

Vous pouvez également supprimer des modèles dans SQL en utilisant DROP MODEL.

Obtention de modèles à partir du registre

Pour obtenir des informations sur chaque modèle, utilisez la méthode show_models :

model_df = reg.show_models()
Copy

Astuce

Dans SQL, utilisez SHOW MODELS pour obtenir une liste de modèles.

Le résultat de show_models est un DataFrame pandas. Les colonnes disponibles sont répertoriées ici :

Colonne

Description

created_on

Date et heure de création du modèle.

name

Nom du modèle.

database_name

Base de données dans laquelle le modèle est stocké.

schema_name

Schéma dans lequel le modèle est stocké.

owner

Rôle qui possède le modèle.

comment

Commentaire pour le rôle.

versions

Le tableau JSON qui répertorie les versions du modèle.

default_version_name

Version du modèle utilisée lorsqu’il est fait référence au modèle sans version.

Pour obtenir une liste des modèles dans le registre, chacun en tant qu’instance Model utilisez la méthode models :

model_list = reg.models()
Copy

Pour obtenir une référence à un modèle spécifique du registre par son nom, utilisez la méthode get_model du registre :

m = reg.get_model("MyModel")
Copy

Note

Les instances Model ne sont pas des copies de l’objet de modèle Python d’origine enregistré, mais des références à l’objet modèle sous-jacent dans le registre.

Une fois que vous avez une référence à un modèle, soit dans la liste renvoyée par la méthode models soit en utilisant get_model, vous pouvez travailler avec ses métadonnées et ses versions.

Visualisation et mise à jour des métadonnées d’un modèle

Vous pouvez consulter et mettre à jour les attributs de métadonnées d’un modèle dans le registre, y compris son nom, son commentaire, ses balises et ses métriques.

Récupération et mise à jour des commentaires

Utilisez l’attribut comment du modèle pour récupérer et mettre à jour le commentaire du modèle :

print(m.comment)
m.comment = "A better description than the one I provided originally"
Copy

Note

L’attribut description et un synonyme de comment. Le code précédent peut également être écrit de cette façon :

print(m.description)
m.description = "A better description than the one I provided originally"
Copy

Astuce

Vous pouvez également définir le commentaire d’un modèle en SQL en utilisant ALTER MODEL.

Récupération et mise à jour des balises

Les balises sont des métadonnées utilisées pour enregistrer l’objectif, l’algorithme, l’ensemble de données d’entraînement, l’étape du cycle de vie d’un modèle ou toute autre information que vous choisissez. Vous pouvez définir des balises lors de l’enregistrement du modèle ou à tout moment par la suite. Vous pouvez également mettre à jour les valeurs des balises existantes ou les supprimer complètement.

Note

Vous devez d’abord définir les noms de toutes les balises (et potentiellement leurs valeurs possibles) en utilisant CREATE TAG. Voir Balisage d’objets.

Pour obtenir toutes les balises d’un modèle sous la forme d’un dictionnaire Python, utilisez show_tags :

print(m.show_tags())
Copy

Pour ajouter une nouvelle balise ou modifier la valeur d’une balise existante, utilisez set_tag :

m.set_tag("live_version", "v1")
Copy

Pour récupérer la valeur d’une balise, utilisez get_tag :

m.get_tag("live_version")
Copy

Pour supprimer une balise, utilisez unset_tag :

m.unset_tag("live_version")
Copy

Astuce

Vous pouvez également définir le commentaire d’un modèle en SQL en utilisant ALTER MODEL.

Changement du nom d’un modèle

Utilisez la méthode rename pour renommer ou déplacer un modèle. Spécifiez un nom entièrement qualifié comme nouveau nom pour déplacer le modèle vers une base de données ou un schéma différent.

m.rename("MY_MODEL_TOO")
Copy

Astuce

Vous pouvez également renommer un modèle dans SQL en utilisant ALTER MODEL.

Utilisation de versions de modèles

Un modèle peut avoir un nombre illimité de versions, chacune identifiée par une chaîne. Vous pouvez utiliser n’importe quelle convention de dénomination de version. L’enregistrement d’un modèle enregistre en fait une version spécifique du modèle. Pour enregistrer d’autres versions d’un modèle, appelez à nouveau log_model avec le même model_name mais un version_name différent.

Astuce

Dans SQL, utilisez SHOW VERSIONS IN MODEL pour voir les versions d’un modèle.

Une version d’un modèle est représentée par une instance de la classe snowflake.ml.model.ModelVersion.

Pour obtenir la liste de toutes les versions d’un modèle, appelez la méthode versions de l’objet du modèle. Le résultat est une liste d’instances ModelVersion :

version_list = m.versions()
Copy

Pour obtenir des informations sur chaque modèle sous la forme d’un DataFrame, appelez la méthode show_versions du modèle :

version_df = m.show_versions()
Copy

Le DataFrame résultant contient les colonnes suivantes :

Colonne

Description

created_on

Date et heure de création de la version du modèle.

name

Nom de la version.

database_name

Base de données dans laquelle la version est stockée.

schema_name

Schéma dans lequel la version est stockée.

model_name

Nom du modèle auquel cette version appartient.

is_default_version

Valeur booléenne indiquant si cette version est la version par défaut du modèle.

functions

Tableau JSON des noms des fonctions disponibles dans cette version.

metadata

Objet JSON contenant des métadonnées sous forme de paires clé-valeur ({} si aucune métadonnée n’est spécifiée).

user_data

Objet JSON de la section user_data du manifeste de définition du modèle ({} si aucune donnée utilisateur n’est spécifiée).

Suppression des versions du modèle

Vous pouvez supprimer une version de modèle en utilisant la méthode delete_version du modèle :

m.delete_version("rc1")
Copy

Astuce

Vous pouvez également supprimer une version de modèle en SQL à l’aide de ALTER MODEL … DROP VERSION.

Version par défaut

Une version d’un modèle peut être désignée comme modèle par défaut. Récupérez ou définissez l’attribut default du modèle pour obtenir la version actuelle par défaut (sous la forme d’un objet ModelVersion) ou pour la modifier (à l’aide d’une chaîne) :

default_version = m.default
m.default = "v2"
Copy

Astuce

Dans SQL, utilisez ALTER MODEL pour définir la version par défaut.

Alias de la version du modèle

Vous pouvez attribuer un alias à une version de modèle à l’aide de la commande SQL ALTER MODEL. Vous pouvez utiliser un alias chaque fois qu’un nom de version est nécessaire, par exemple pour obtenir une référence à une version de modèle, en Python ou en SQL. Un alias donné ne peut être attribué qu’à une seule version de modèle à la fois.

Outre les alias que vous créez, les alias système suivants sont disponibles dans tous les modèles :

  • DEFAULT fait référence à la version par défaut du modèle.

  • FIRST fait référence à la version la plus ancienne du modèle en fonction du moment de la création.

  • LAST fait référence à la version la plus récente du modèle en fonction du moment de la création.

Les noms d’alias que vous créez doivent être différents de tout nom de version ou alias existant dans le modèle, y compris les alias système.

Obtention d’une référence à une version de modèle

Pour obtenir une référence à une version spécifique d’un modèle en tant qu’instance ModelVersion , utilisez la méthode version du modèle. Utilisez l’attribut default du modèle pour obtenir la version par défaut du modèle :

m = reg.get_model("MyModel")

mv = m.version("v1")
mv = m.default
Copy

Une fois que vous avez une référence à une version spécifique d’un modèle (comme la variable mv dans cet exemple), vous pouvez récupérer ou mettre à jour ses commentaires ou ses métriques et appeler les méthodes (ou fonctions) du modèle comme indiqué dans les sections suivantes.

Récupération et mise à jour des commentaires

Comme pour les modèles, les versions de modèle peuvent avoir des commentaires, qui peuvent être consultés et définis via l’attribut comment ou description de la version de modèle :

print(mv.comment)
print(mv.description)

mv.comment = "A model version comment"
mv.description = "Same as setting the comment"
Copy

Astuce

Vous pouvez également modifier le commentaire d’une version de modèle en SQL en utilisant ALTER MODEL … MODIFY VERSION.

Récupération et mise à jour des métriques

Les métriques sont des paires clé-valeur utilisées pour suivre la précision de la prédiction et d’autres caractéristiques de la version du modèle. Vous pouvez définir des métriques lors de la création d’une version de modèle ou en utilisant la méthode set_metric. Une valeur métrique peut être n’importe quel objet Python qui peut être sérialisé en JSON, y compris les nombres, les chaînes, les listes et les dictionnaires. Contrairement aux balises, les noms des métriques et les valeurs possibles ne doivent pas être définis à l’avance.

Une mesure de la précision du test peut être générée à l’aide de accuracy_score de sklearn :

from sklearn import metrics

test_accuracy = metrics.accuracy_score(test_labels, prediction)
Copy

La matrice de confusion peut être générée de la même manière à l’aide de sklearn :

test_confusion_matrix = metrics.confusion_matrix(test_labels, prediction)
Copy

Vous pouvez ensuite définir ces valeurs comme métriques :

# scalar metric
mv.set_metric("test_accuracy", test_accuracy)

# hierarchical (dictionary) metric
mv.set_metric("evaluation_info", {"dataset_used": "my_dataset", "accuracy": test_accuracy, "f1_score": f1_score})

# multivalent (matrix) metric
mv.set_metric("confusion_matrix", test_confusion_matrix)
Copy

Pour récupérer les métriques d’une version de modèle sous la forme d’un dictionnaire Python, utilisez show_metrics.

metrics = mv.show_metrics()
Copy

Pour supprimer une métrique, appelez delete_metric.

mv.delete_metric("test_accuracy")
Copy

Astuce

Vous pouvez également modifier les métriques d’une version de modèle (qui sont stockées sous forme de métadonnées) en SQL à l’aide de ALTER MODEL … MODIFY VERSION.

Récupération des explications du modèle

Le registre de modèles peut expliquer les résultats d’un modèle, en vous indiquant quelles fonctionnalités d’entrée contribuent le plus aux prédictions, en calculant les valeurs de Shapley. Cette fonctionnalité en avant-première est disponible par défaut dans toutes les vues de modèle créées dans Snowflake 8.31 et versions ultérieures via le modèle explain sous-jacent. Vous pouvez appeler explain depuis SQL ou via une méthode run de vue de modèle en Python.

Pour plus de détails sur cette fonctionnalité, voir Explicabilité des modèles.

Exportation d’une version du modèle

Utilisez mv.export pour exporter les fichiers d’un modèle vers un répertoire local ; le répertoire est créé s’il n’existe pas :

mv.export("~/mymodel/")
Copy

Par défaut, les fichiers exportés comprennent le code, l’environnement de chargement du modèle et les poids du modèle. Pour exporter également les fichiers nécessaires à l’exécution du modèle dans un entrepôt, indiquez export_mode = ExportMode.FULL :

mv.export("~/mymodel/", export_mode=ExportMode.FULL)
Copy

Chargement d’une version de modèle

Utilisez mv.load pour charger l’objet du modèle Python d’origine qui a été ajouté au registre. Vous pouvez alors utiliser le modèle pour l’inférence comme si vous l’aviez défini dans votre code Python.

clf = mv.load()
Copy

Pour garantir le bon fonctionnement d’un modèle à partir du registre, l’environnement Python cible (c’est-à-dire les versions de l’interpréteur Python et de toutes les bibliothèques) doit être identique à l’environnement à partir duquel le modèle a été enregistré. Spécifiez force=True dans l’appel load pour forcer le chargement du modèle même si l’environnement est différent.

Astuce

Pour vous assurer que votre environnement est le même que celui dans lequel le modèle est hébergé, téléchargez une copie de l’environnement conda à partir du registre de modèles :

conda_env = session.file.get("snow://model/<modelName>/versions/<versionName>/runtimes/python_runtime/env/conda.yml", ".")
open("~/conda.yml", "w").write(conda_env)
Copy

Créez ensuite un nouvel environnement conda à partir de ce fichier :

conda env create --name newenv --file=~/conda.yml
conda activate newenv
Copy

L’argument facultatif options est un dictionnaire d’options pour le chargement du modèle. Actuellement, l’argument ne prend en charge que l’option use_gpu.

Option

Type

Description

Par défaut

use_gpu

bool

Active la logique de chargement propre à GPU.

False

L’exemple suivant illustre l’utilisation de l’argument options :

clf = mv.load(options={"use_gpu": True})
Copy

Appel de méthodes de modèle

Les versions de modèle peuvent avoir des méthodes, qui sont des fonctions associées pouvant être exécutées pour effectuer une inférence ou d’autres opérations sur le modèle. Les versions d’un modèle peuvent avoir des méthodes différentes, et les signatures de ces méthodes peuvent également différer.

Pour appeler une méthode d’une version de modèle, utilisez mv.run, où mv est un objet ModelVersion. Spécifiez le nom de la fonction à appeler et transmettez un DataFrame Snowpark ou pandas qui contient les données d’inférence, ainsi que tous les paramètres requis. La méthode est exécutée dans un entrepôt Snowflake.

La valeur de retour de la méthode est un DataFrame Snowpark ou pandas, correspondant au type de DataFrame transmis. Les DataFrames Snowpark sont évalués paresseusement, de sorte que la méthode n’est exécutée que lorsque la méthode collect, show ou to_pandas du DataFrame est appelée.

Note

L’invocation d’une méthode l’exécute dans l’entrepôt spécifié dans la session que vous utilisez pour vous connecter au registre. Voir Spécification d’un entrepôt..

L’exemple suivant illustre l’exécution de la méthode predict d’un modèle. La méthode predict de ce modèle ne nécessite aucun paramètre en dehors des données d’inférence (test_features ici). Si c’était le cas, ils seraient transmis en tant qu’arguments supplémentaires après les données d’inférence.

remote_prediction = mv.run(test_features, function_name="predict")
remote_prediction.show()   # assuming test_features is Snowpark DataFrame
Copy

Pour voir quelles méthodes peuvent être appelées sur un modèle donné, appelez mv.show_functions. La valeur de retour de cette méthode est une liste d’objets ModelFunctionInfo. Chacun de ces objets comprend les attributs suivants :

  • name : Le nom de la fonction qui peut être appelée depuis Python ou SQL.

  • target_method : le nom de la méthode Python dans le modèle original enregistré.

Astuce

Vous pouvez également appeler des méthodes de modèle dans SQL. Voir Commandes du modèle.

Partage de modèles

Le registre de modèles peut stocker deux types de modèles. Vous pouvez les distinguer en utilisant la colonne MODEL_TYPEdans la sortie de SHOW MODELS.

  • CORTEX_FINETUNED : modèles générés avec Cortex Fine-tuning, qui ne contiennent pas de code utilisateur. Pour partager ce type de modèle, utilisez le Partage de données.

  • USER_MODEL : modèles contenant du code utilisateur, tels que les modèles développés à l’aide des classes de modélisation Snowpark ML. Ces modèles ne peuvent actuellement pas être partagés. La possibilité de partager des modèles contenant du code utilisateur sera disponible dans une future version.

Considérations relatives aux clients

L’utilisation du registre des modèles de Snowflake engendre des coûts standard basés sur la consommation Snowflake. Il s’agit notamment des éléments suivants :

  • Coût du stockage des artefacts, des métadonnées et des fonctions du modèle. Pour des informations générales sur les coûts de stockage, voir Exploration des coûts de stockage.

  • Coût de la copie des fichiers entre les zones de préparation et Snowflake. Voir COPY FILES.

  • Coût des opérations sur les objets de modèle sans serveur via l’interface Snowsight UI ou SQL ou Python, telles que l’affichage des modèles et des versions de modèle, et la modification des commentaires, des balises et des métriques du modèle.

  • Les coûts de calcul d’entrepôts varient en fonction du type de modèle et de la quantité de données utilisées pour l’inférence. Pour obtenir des informations générales sur les coûts de calcul de Snowflake, consultez Comprendre le coût du calcul. Les coûts de calcul de l’entrepôt sont encourus pour :

    • Opérations de création de modèles et de versions

    • Invocation de méthodes d’un modèle