Skip to main content
Utilisez Dagster et W&B ensemble pour orchestrer vos pipelines MLOps et gérer vos assets ML. Dans vos flux de travail Dagster existants, vous pouvez suivre les expériences, gérer les données et exécuter des tâches d’entraînement. L’intégration W&B prend en charge les tâches suivantes :
  • Créer et utiliser un artefact W&B.
  • Utiliser et créer des Registered Models dans W&B Registry.
  • Exécuter des tâches d’entraînement sur une infrastructure dédiée à l’aide de W&B Launch.
  • Utiliser le client wandb dans les ops et les assets.
L’intégration W&B pour Dagster fournit une ressource Dagster spécifique à W&B et un IO Manager :
  • wandb_resource : une ressource Dagster utilisée pour s’authentifier auprès de l’API W&B et communiquer avec elle.
  • wandb_artifacts_io_manager : un IO Manager Dagster utilisé pour consommer des artefacts W&B.
Ce guide s’adresse aux praticiens du ML et aux ingénieurs plateforme qui utilisent déjà Dagster et souhaitent ajouter le suivi W&B et la gestion des artefacts. Vous apprendrez à configurer Dagster, à créer et utiliser des artefacts W&B dans les ops et les assets, à utiliser W&B Launch et à appliquer les bonnes pratiques.

Avant de commencer

Vous aurez besoin des ressources suivantes pour utiliser Dagster dans W&B :
  • Clé API W&B.
  • entité W&B : le nom de votre équipe W&B.
  • projet W&B : le nom du projet dans lequel les W&B Runs sont stockés.
Pour trouver votre entité W&B, consultez la page de profil de votre équipe dans W&B. Vous pouvez utiliser un projet W&B existant ou en créer un nouveau. Vous pouvez créer de nouveaux projets sur la page d’accueil de W&B ou sur la page de profil de votre équipe. Si un projet n’existe pas, W&B le crée automatiquement lorsque vous l’utilisez pour la première fois.

Configurer votre clé API

L’intégration s’authentifie auprès de W&B à l’aide d’une clé API, que vous devez rendre disponible pour Dagster sous forme de variable d’environnement.
  1. Connectez-vous à W&B. Si vous utilisez W&B Server, demandez à votre administrateur le nom d’hôte de l’instance.
  2. Créez une clé API dans les Paramètres utilisateur. Pour un environnement de production, utilisez un compte de service comme propriétaire de cette clé.
  3. Définissez une variable d’environnement pour cette clé API : export WANDB_API_KEY=<your_api_key>.
Après avoir effectué ces étapes, Dagster peut lire votre clé API depuis l’environnement lorsqu’il charge wandb_resource. Les exemples suivants montrent où spécifier votre clé API dans votre code Dagster. Renseignez votre entité et le nom de votre projet dans le dictionnaire imbriqué wandb_config. Vous pouvez transmettre des valeurs wandb_config différentes à différentes ops ou assets si vous souhaitez utiliser un autre projet W&B. Pour plus d’informations sur les clés possibles que vous pouvez transmettre, voir la section Configuration.
Exemple de configuration pour @job :

Configuration

L’intégration fournit une ressource Dagster spécifique à W&B ainsi qu’un IO Manager avec les options de configuration suivantes.
  • wandb_resource : ressource Dagster utilisée pour communiquer avec l’API W&B. Elle s’authentifie automatiquement à l’aide de la clé API fournie. Propriétés :
    • api_key : (str, requis) : une clé API W&B nécessaire pour communiquer avec l’API W&B.
    • host : (str, facultatif) : le serveur hôte de l’API que vous souhaitez utiliser. Requis uniquement si vous utilisez W&B Server. Par défaut, l’hôte Public Cloud https://api.wandb.ai est utilisé.
  • wandb_artifacts_io_manager : IO Manager Dagster permettant d’utiliser des artefacts W&B. Propriétés :
    • base_dir : (int, facultatif) Répertoire de base utilisé pour le stockage local et la mise en cache. Les artefacts W&B et les journaux des W&B Run sont écrits et lus dans ce répertoire. Par défaut, il utilise le répertoire DAGSTER_HOME.
    • cache_duration_in_minutes : (int, facultatif) Définit la durée de conservation des artefacts W&B et des journaux des W&B Run dans le stockage local. Le cache supprime uniquement les fichiers et répertoires qui n’ont pas été ouverts pendant cette durée. La purge du cache a lieu à la fin de l’exécution d’un IO Manager. Définissez cette valeur sur 0 pour désactiver complètement la mise en cache. La mise en cache améliore les performances lorsqu’un artefact est réutilisé entre des jobs exécutés sur la même machine. La valeur par défaut est de 30 jours.
    • run_id : (str, facultatif) : un ID unique pour ce run, utilisé pour la reprise. Il doit être unique dans le projet, et si vous supprimez un run, vous ne pouvez pas réutiliser cet ID. Utilisez le champ name pour un nom descriptif court, ou config pour enregistrer des hyperparamètres à comparer entre les runs. L’ID ne peut pas contenir les caractères spéciaux suivants : /\#?%:.. Définissez le Run ID lorsque vous effectuez le suivi des expériences dans Dagster afin de permettre à l’IO Manager de reprendre le run. Par défaut, il est défini sur le Dagster Run ID, par exemple 7e4df022-1bf2-44b5-a383-bb852df4077e.
    • run_name : (str, facultatif) Nom d’affichage court pour ce run afin de vous aider à l’identifier dans l’interface utilisateur. Par défaut, il s’agit d’une chaîne au format suivant : dagster-run-[8 premiers caractères du Dagster Run ID]. Par exemple, dagster-run-7e4df022.
    • run_tags : (list[str], facultatif) : liste de chaînes qui alimente la liste des tags de ce run dans l’interface utilisateur. Les tags sont utiles pour regrouper des runs ou appliquer des libellés temporaires comme baseline ou production. Vous pouvez ajouter et supprimer des tags dans l’interface utilisateur, ou filtrer les runs pour n’afficher que ceux ayant un tag spécifique. Tout W&B Run utilisé par l’intégration possède le tag dagster_wandb.

Utiliser les artefacts W&B

Cette section explique comment l’intégration utilise un Dagster IO Manager pour faire le lien entre les artefacts W&B et les ops et assets Dagster. L’intégration avec un artefact W&B repose sur un Dagster IO Manager. Les IO Managers sont des objets fournis par l’utilisateur, chargés de stocker la sortie d’un asset ou d’une op, puis de la charger comme entrée pour les assets ou ops en aval. Par exemple, un IO Manager peut stocker et charger des objets à partir de fichiers sur un système de fichiers. L’intégration fournit un IO Manager pour les artefacts W&B. Cela permet à n’importe quel @op ou @asset Dagster de créer et de consommer directement des artefacts W&B. L’exemple suivant montre un @asset qui produit un artefact W&B de type jeu de données contenant une liste Python.
Vous pouvez annoter vos @op, @asset et @multi_asset avec une configuration de métadonnées pour écrire des Artifacts. De même, vous pouvez également consommer des artefacts W&B même s’ils ont été créés en dehors de Dagster.

Écrire des artefacts W&B

Les sections suivantes décrivent comment produire des artefacts W&B à partir d’opérations et d’assets Dagster, y compris les types de retour pris en charge et la manière de configurer l’Artifact résultant. Avant de continuer, assurez-vous de bien comprendre comment utiliser les artefacts W&B. Voir le Guide sur les Artifacts. Pour écrire un artefact W&B, renvoyez un objet depuis une fonction Python. W&B prend en charge les objets suivants :
  • Objets Python (int, dict, list, etc.)
  • Objets W&B (Table, Image, Graph, etc.)
  • Objets artefact W&B
Les exemples suivants montrent comment écrire des artefacts W&B avec des assets Dagster (@asset) :
Tout ce qui peut être sérialisé avec le module pickle est sérialisé avec pickle et ajouté à un Artifact créé par l’intégration. Le contenu est désérialisé lorsque vous lisez cet Artifact dans Dagster (voir Lire les artifacts pour plus de détails).
W&B prend en charge plusieurs modules de sérialisation basés sur Pickle (pickle, dill, cloudpickle, joblib). Vous pouvez également utiliser des formats de sérialisation plus avancés comme ONNX ou PMML. Pour en savoir plus, consultez la section Serialization.

Configuration

Vous pouvez définir un dictionnaire de configuration appelé wandb_artifact_configuration pour @op, @asset et @multi_asset. Transmettez ce dictionnaire dans les arguments du décorateur en tant que métadonnées. Cette configuration est requise pour contrôler les lectures et écritures de l’IO Manager des artefacts W&B. Pour @op, il se trouve dans les métadonnées de sortie via l’argument de métadonnées Out. Pour @asset, il se trouve dans l’argument metadata de l’asset. Pour @multi_asset, il se trouve dans les métadonnées de chaque sortie via les arguments de métadonnées AssetOut. Les exemples de code ci-dessous montrent comment configurer un dictionnaire pour des calculs @op, @asset et @multi_asset :
Exemple pour @op :
Les propriétés suivantes sont prises en charge :
  • name: (str) nom lisible par l’humain pour cet artifact, que vous pouvez utiliser pour l’identifier dans l’UI ou y faire référence dans les appels use_artifact. Les noms peuvent contenir des lettres, des chiffres, des underscores, des traits d’union et des points. Le nom doit être unique à l’échelle d’un projet. Requis pour @op.
  • type: (str) type de l’artifact, utilisé pour organiser et différencier les artifacts. Les types courants incluent les jeux de données ou les modèles, mais vous pouvez utiliser n’importe quelle chaîne contenant des lettres, des chiffres, des underscores, des traits d’union et des points. Requis lorsque la sortie n’est pas déjà un Artifact.
  • description: (str) Texte libre qui décrit l’artifact. La description est interprétée en markdown dans l’UI, c’est donc un bon endroit pour les tableaux, les liens, etc.
  • aliases: (list[str]) Un tableau contenant un ou plusieurs alias que vous souhaitez appliquer à l’artefact W&B. L’intégration ajoute également le tag “latest” à cette liste, qu’il soit défini ou non. Utilisez les alias pour gérer les versions des modèles et des jeux de données.
  • add_dirs: (list[dict[str, Any]]): Un tableau contenant la configuration de chaque répertoire local à inclure dans l’artefact W&B.
  • add_files: (list[dict[str, Any]]): Un tableau contenant la configuration de chaque fichier local à inclure dans l’artefact W&B.
  • add_references: (list[dict[str, Any]]): Un tableau contenant la configuration de chaque référence externe à inclure dans l’artefact W&B.
  • serialization_module: (dict) Configuration du module de sérialisation à utiliser. Se référer à la section Serialization pour plus d’informations.
    • name: (str) Nom du module de sérialisation. Valeurs acceptées : pickle, dill, cloudpickle, joblib. Le module doit être disponible localement.
    • parameters: (dict[str, Any]) Arguments facultatifs transmis à la fonction de sérialisation. Elle accepte les mêmes paramètres que la méthode dump de ce module. Par exemple, {"compress": 3, "protocol": 4}.
Exemple avancé :
L’asset est matérialisé avec des métadonnées de part et d’autre de l’intégration :
  • Côté W&B : le nom et la version de l’intégration source, la version de Python utilisée, la version du protocole pickle, entre autres.
  • Côté Dagster :
    • ID du run Dagster
    • W&B Run : ID, nom, chemin, URL
    • artefact W&B : ID, nom, type, version, taille, URL
    • Entité W&B
    • Projet W&B
L’image suivante montre les métadonnées issues de W&B que l’intégration ajoute à l’asset Dagster. L’intégration transmet ces informations à Dagster.
UI de Dagster avec une vue détaillée d'un asset et des métadonnées W&B associées, y compris des références à un projet et à un run W&B
L’image suivante montre comment la configuration fournie est enrichie avec des métadonnées dans l’artefact W&B. Ces informations facilitent la reproductibilité et la maintenance. Elles ne sont pas disponibles sans l’intégration.
Page de l’artefact W&B avec des métadonnées de configuration enrichies provenant de Dagster
Panneau de métadonnées de l’artefact W&B avec des détails de configuration supplémentaires provenant de Dagster
Vue de l’artefact W&B avec des champs de métadonnées de configuration supplémentaires enrichis depuis Dagster
Si vous utilisez un vérificateur de types statique comme mypy, importez l’objet de définition du type de configuration comme suit :

Utiliser les partitions

L’intégration prend directement en charge les partitions Dagster. Voici un exemple de partitionnement avec DailyPartitionsDefinition :
Ce code produit un artefact W&B pour chaque partition. Consultez les Artifacts dans le panneau Artifact (UI), sous le nom de l’asset, avec la clé de partition ajoutée. Par exemple, my_daily_partitioned_asset.2023-01-01, my_daily_partitioned_asset.2023-01-02 ou my_daily_partitioned_asset.2023-01-03. Les assets partitionnés sur plusieurs dimensions affichent chaque dimension dans un format délimité par des points. Par exemple, my_asset.car.blue.
L’intégration ne permet pas de matérialiser plusieurs partitions au sein d’un même run. Vous devez effectuer plusieurs runs pour matérialiser vos assets. Vous pouvez le faire dans Dagit lorsque vous matérialisez vos assets.
Interface Dagster avec plusieurs runs pour des assets partitionnés, chaque partition correspondant à un run distinct

Utilisation avancée

Pour une utilisation avancée, voir les exemples suivants :

Lire Artifacts W&B

Maintenant que vous pouvez écrire des Artifacts depuis Dagster, les sections suivantes décrivent comment les utiliser comme entrées pour des ops et assets en aval. La lecture des Artifacts W&B est similaire à leur écriture. Un dictionnaire de configuration appelé wandb_artifact_configuration peut être défini sur un @op ou un @asset. La seule différence est que la configuration doit être définie sur l’entrée plutôt que sur la sortie. Pour @op, elle se trouve dans les métadonnées d’entrée via l’argument de métadonnées In. Vous devez indiquer explicitement le nom de l’artefact W&B. Pour @asset, elle se trouve dans les métadonnées d’entrée via l’argument de métadonnées Asset In. Vous ne devez pas transmettre de nom d’artefact W&B, car le nom de l’asset parent doit correspondre. Si vous souhaitez créer une dépendance sur un Artifact créé en dehors de l’intégration, vous devrez utiliser SourceAsset. Il lira toujours la dernière version de cet asset. Les exemples suivants montrent comment lire un Artifact à partir de différents ops.
Lecture d’un artifact à partir d’un @op

Configuration

La configuration suivante indique ce que l’IO Manager doit collecter et fournir en entrée aux fonctions décorées. Les modes de lecture suivants sont pris en charge :
  • Pour obtenir un objet nommé contenu dans un Artifact, utilisez get :
  • Pour obtenir le chemin local d’un fichier téléchargé présent dans un Artifact, utilisez get_path :
  • Pour obtenir l’objet Artifact dans son intégralité (avec le contenu téléchargé localement) :
Les propriétés suivantes sont prises en charge :
  • get: (str) Obtient l’objet W&B correspondant au nom relatif de l’artifact.
  • get_path: (str) Obtient le chemin du fichier correspondant au nom relatif de l’artifact.

Configuration de la sérialisation

Par défaut, l’intégration utilise le module standard pickle, mais certains objets ne sont pas compatibles avec celui-ci. Par exemple, les fonctions contenant yield génèrent une erreur si vous essayez de les sérialiser avec pickle. W&B prend également en charge d’autres modules de sérialisation basés sur Pickle (dill, cloudpickle, joblib). Vous pouvez aussi utiliser des méthodes de sérialisation plus avancées comme ONNX ou PMML, en renvoyant une chaîne sérialisée ou en créant directement un Artifact. Le choix le plus adapté dépend de votre cas d’usage. Veuillez vous référer à la documentation disponible sur ce sujet.

Modules de sérialisation basés sur pickle

Le pickling est réputé non sécurisé. Si la sécurité est un enjeu, utilisez uniquement des objets W&B. Signez vos données et stockez les clés de hachage dans vos propres systèmes. Pour des cas d’usage plus complexes, contactez l’assistance W&B.
Vous pouvez configurer la sérialisation utilisée via le dictionnaire serialization_module dans wandb_artifact_configuration. Assurez-vous que le module est disponible sur la machine exécutant Dagster. L’intégration détecte automatiquement quel module de sérialisation utiliser lorsque vous lirez cet Artifact. Les modules pris en charge sont pickle, dill, cloudpickle et joblib. Voici un exemple simplifié qui crée un « modèle » sérialisé avec joblib, puis l’utilise pour l’inférence.

Formats de sérialisation avancés (ONNX, PMML)

Les formats de fichier d’échange comme ONNX et PMML sont courants. L’intégration prend en charge ces formats, mais cela demande un peu plus de travail qu’une sérialisation basée sur Pickle. Vous pouvez utiliser ces formats avec l’une des méthodes suivantes :
  • Convertissez votre modèle dans le format sélectionné, puis renvoyez sa représentation sous forme de chaîne comme s’il s’agissait d’un objet Python ordinaire. L’intégration sérialise cette chaîne avec pickle. Vous pourrez ensuite reconstruire votre modèle à partir de cette chaîne.
  • Créez un nouveau fichier local contenant votre modèle sérialisé, puis créez un Artifact personnalisé avec ce fichier à l’aide de la configuration add_file.
Voici un exemple de modèle Scikit-learn sérialisé avec ONNX.

Utiliser des partitions

L’intégration prend directement en charge les partitions Dagster. Vous pouvez lire une, plusieurs ou toutes les partitions d’un asset de manière sélective. Toutes les partitions sont fournies dans un dictionnaire, où la clé et la valeur représentent respectivement la clé de partition et le contenu de l’Artifact.
Cet exemple lit toutes les partitions de l’@asset amont, fournies sous forme de dictionnaire. Dans ce dictionnaire, la clé et la valeur correspondent respectivement à la clé de partition et au contenu de l’Artifact.
L’objet de configuration metadata détermine comment W&B interagit avec les différentes partitions d’artefact W&B dans votre projet. L’objet metadata contient une clé nommée wandb_artifact_configuration, qui contient elle-même un objet imbriqué partitions. L’objet partitions associe le nom de chaque partition à sa configuration. La configuration de chaque partition peut préciser comment récupérer ses données. Ces configurations peuvent contenir différentes clés, à savoir get, version et alias, selon les exigences de chaque partition.

Clés de configuration

Les clés de configuration suivantes sont prises en charge :
  • get : La clé get spécifie le nom de l’objet W&B (Table, Image, etc.) à partir duquel récupérer les données.
  • version : Utilisez la clé version lorsque vous souhaitez récupérer une version spécifique de l’Artifact.
  • alias : La clé alias vous permet d’obtenir l’Artifact à l’aide de son alias.

Configuration générique

Le caractère générique "*" désigne toutes les partitions non configurées. Il fournit une configuration par défaut pour les partitions qui ne sont pas explicitement mentionnées dans l’objet partitions. Par exemple :
Cette configuration signifie que, pour toutes les partitions non configurées explicitement, les données sont récupérées depuis le tableau nommé default_table_name.

Configuration spécifique de partition

Vous pouvez remplacer la configuration générique pour certaines partitions en fournissant leur propre configuration à l’aide de leur clé. Par exemple :
Cette configuration signifie que, pour la partition nommée yellow, les données sont récupérées depuis le tableau nommé custom_table_name, ce qui remplace la configuration générique.

Gestion des versions et des alias

À des fins de gestion des versions et des alias, vous pouvez spécifier des clés version et alias spécifiques dans votre configuration. Pour les versions :
Cette configuration récupérera les données de la partition de l’Artifact orange en version v0. Pour les alias :
Cette configuration récupère des données depuis le tableau default_table_name de la partition Artifact avec l’alias special_alias (désigné par blue dans la configuration).

Utilisation avancée

Pour consulter des cas d’utilisation avancée de l’intégration, se référer aux exemples de code complets suivants :

Utiliser W&B Launch

Les sections suivantes décrivent comment combiner l’intégration Dagster avec W&B Launch pour exécuter des tâches d’entraînement sur du calcul dédié, localement ou à distance.
Produit bêta en cours de développement actif. Launch vous intéresse ? Contactez l’équipe en charge de votre compte pour discuter de votre participation au programme pilote client de W&B Launch. Les clients pilotes doivent utiliser AWS EKS ou SageMaker pour être éligibles au programme bêta. D’autres plateformes sont prévues.
Avant de continuer, assurez-vous de bien comprendre comment utiliser W&B Launch. Voir le Guide de Launch. L’intégration Dagster permet de :
  • Exécuter un ou plusieurs agents Launch dans votre instance Dagster.
  • Exécuter des jobs Launch locaux dans votre instance Dagster.
  • Exécuter des jobs Launch à distance, sur site ou dans le cloud.

agent Launch

L’intégration fournit un @op importable appelé run_launch_agent. Il démarre un agent Launch et l’exécute comme un processus de longue durée jusqu’à ce qu’il soit arrêté manuellement. Les agents sont des processus qui interrogent les files d’attente de Launch et exécutent les jobs dans l’ordre (ou les transmettent à des services externes pour exécution). Référez-vous à la page Launch. Vous pouvez également consulter les descriptions de toutes les propriétés dans Launchpad.
Interface W&B Launchpad avec les options de configuration de l’agent et les descriptions pour l’intégration Dagster
Exemple :

Jobs Launch

L’intégration fournit un @op importable appelé run_launch_job. Il exécute votre job Launch. Pour être exécuté, un job Launch doit être assigné à une file d’attente. Vous pouvez créer une file d’attente ou utiliser celle par défaut. Assurez-vous qu’un agent actif écoute cette file d’attente. Vous pouvez exécuter un agent dans votre instance Dagster, ou envisager d’utiliser un agent déployable sur Kubernetes. Consultez la page Launch. Vous pouvez également consulter dans Launchpad des descriptions pour toutes les propriétés.
Interface W&B Launchpad avec des options de configuration de job et des descriptions pour l’intégration Dagster
Exemple :

Bonnes pratiques

Les recommandations suivantes vous aident à tirer le meilleur parti de l’intégration une fois qu’elle est opérationnelle de bout en bout.

Utilisez l’IO Manager pour lire et écrire des Artifacts

Évitez d’utiliser directement Artifact.download() ou Run.log_artifact(). Ces méthodes sont prises en charge par l’intégration. Renvoyez plutôt les données que vous souhaitez stocker dans l’Artifact et laissez l’intégration faire le reste. Cette approche offre une meilleure traçabilité pour l’Artifact.

Ne créez vous-même un objet Artifact que pour des cas d’usage complexes

Renvoyez des objets Python et des objets W&B depuis vos ops et assets. L’intégration se charge d’assembler l’Artifact. Pour les cas d’usage complexes, vous pouvez créer un Artifact directement dans un job Dagster. Transmettez un objet Artifact à l’intégration pour enrichir les métadonnées, par exemple avec le nom et la version de l’intégration source, la version de Python utilisée, la version du protocole pickle, etc.

Ajoutez des fichiers, des répertoires et des références externes à vos Artifacts via les métadonnées

Utilisez l’objet d’intégration wandb_artifact_configuration pour ajouter des fichiers, des répertoires ou des références externes (Amazon S3, GCS, HTTP, etc.). Voir l’exemple avancé dans la section de configuration de l’Artifact pour plus d’informations.

Utilisez un @asset plutôt qu’un @op lorsqu’un Artifact est produit

Les Artifacts sont des assets. Utilisez un asset lorsque Dagster gère cet asset. Cela offre une meilleure observabilité dans le catalogue d’assets de Dagit.

Utilisez un SourceAsset pour consommer un Artifact créé en dehors de Dagster

Cela vous permet de tirer parti de l’intégration pour lire des Artifacts créés en dehors de Dagster. Sinon, vous ne pouvez utiliser que les Artifacts créés par l’intégration.

Utilisez W&B Launch pour orchestrer l’entraînement sur des ressources de calcul dédiées pour les grands modèles

Vous pouvez entraîner de petits modèles dans votre cluster Dagster et exécuter Dagster dans un cluster Kubernetes avec des nœuds GPU. Utilisez W&B Launch pour l’entraînement de grands modèles. Cela évite de surcharger votre instance et donne accès à des ressources de calcul plus adaptées.

Lors du suivi des expériences dans Dagster, définissez votre ID de run W&B sur la valeur de votre ID de run Dagster

Rendez le Run reprenable et définissez l’ID de run W&B sur l’ID de run Dagster ou sur la chaîne de votre choix. En suivant cette recommandation, vous vous assurez que vos métriques W&B et vos Artifacts W&B sont stockés dans le même Run W&B lorsque vous entraînez des modèles dans Dagster. Définissez soit l’ID de run W&B sur l’ID de run Dagster :
Ou choisissez votre propre ID de run W&B et renseignez-le dans la configuration de l’IO Manager :

Ne collectez que les données dont vous avez besoin avec get ou get_path pour les W&B Artifacts volumineux

Par défaut, l’intégration télécharge l’intégralité d’un Artifact. Si vous utilisez des artifacts volumineux, vous pouvez ne collecter que les fichiers ou objets spécifiques dont vous avez besoin. Cela améliorera la vitesse et l’utilisation des ressources.

Pour les objets Python, adaptez le module de pickling à votre cas d’utilisation.

Par défaut, l’intégration W&B utilise le module standard pickle. Mais certains objets ne sont pas compatibles avec celui-ci. Par exemple, les fonctions qui utilisent yield génèrent une erreur si vous essayez de les sérialiser avec pickle. W&B prend en charge d’autres modules de sérialisation basés sur Pickle (dill, cloudpickle, joblib). Vous pouvez également utiliser des formats de sérialisation plus avancés comme ONNX ou PMML en renvoyant une chaîne sérialisée ou en créant directement un Artifact. Le bon choix dépend de votre cas d’utilisation ; reportez-vous à la littérature disponible sur ce sujet.