### 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](https://docs.dagster.io/guides/build/external-resources) 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](https://docs.dagster.io/guides/build/io-managers) 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](https://docs.dagster.io/guides/build/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.
```python theme={null}
@asset(
name="my_artifact",
metadata={
"wandb_artifact_arguments": {
"type": "dataset",
}
},
io_manager_key="wandb_artifacts_manager",
)
def create_dataset():
return [1, 2, 3] # ceci sera stocké dans un Artifact
```
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](/fr/models/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`) :
### 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](https://docs.dagster.io/_apidocs/ops#dagster.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](https://docs.dagster.io/_apidocs/assets#dagster.AssetOut).
Les exemples de code ci-dessous montrent comment configurer un dictionnaire pour des calculs `@op`, `@asset` et `@multi_asset` :
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.
### Utiliser les partitions
L’intégration prend directement en charge les [partitions Dagster](https://docs.dagster.io/guides/build/partitions-and-backfills).
Voici un exemple de partitionnement avec `DailyPartitionsDefinition` :
```python theme={null}
@asset(
partitions_def=DailyPartitionsDefinition(start_date="2023-01-01", end_date="2023-02-01"),
name="my_daily_partitioned_asset",
compute_kind="wandb",
metadata={
"wandb_artifact_configuration": {
"type": "dataset",
}
},
)
def create_my_daily_partitioned_asset(context):
partition_key = context.asset_partition_key_for_output()
context.log.info(f"Creating partitioned asset for {partition_key}")
return random.randint(0, 100)
```
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`.
#### Utilisation avancée
Pour une utilisation avancée, voir les exemples suivants :
* [job partitionné](https://github.com/dagster-io/dagster/blob/master/examples/with_wandb/with_wandb/ops/partitioned_job.py)
* [asset partitionné simple](https://github.com/wandb/dagster/blob/master/examples/with_wandb/with_wandb/assets/simple_partitions_example.py)
* [asset partitionné multi-dimensionnel](https://github.com/wandb/dagster/blob/master/examples/with_wandb/with_wandb/assets/multi_partitions_example.py)
* [Utilisation avancée du partitionnement](https://github.com/wandb/dagster/blob/master/examples/with_wandb/with_wandb/assets/advanced_partitions_example.py)
## 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](https://docs.dagster.io/_apidocs/ops#dagster.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](https://docs.dagster.io/_apidocs/assets#dagster.AssetIn) 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](https://docs.dagster.io/_apidocs/assets#dagster.SourceAsset). Il lira toujours la dernière version de cet asset.
Les exemples suivants montrent comment lire un Artifact à partir de différents ops.
### 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` :
```python theme={null}
@asset(
ins={
"table": AssetIn(
key="my_artifact_with_table",
metadata={
"wandb_artifact_configuration": {
"get": "my_table",
}
},
input_manager_key="wandb_artifacts_manager",
)
}
)
def get_table(context, table):
context.log.info(table.get_column("a"))
```
* Pour obtenir le chemin local d’un fichier téléchargé présent dans un Artifact, utilisez `get_path` :
```python theme={null}
@asset(
ins={
"path": AssetIn(
key="my_artifact_with_file",
metadata={
"wandb_artifact_configuration": {
"get_path": "name_of_file",
}
},
input_manager_key="wandb_artifacts_manager",
)
}
)
def get_path(context, path):
context.log.info(path)
```
* Pour obtenir l’objet Artifact dans son intégralité (avec le contenu téléchargé localement) :
```python theme={null}
@asset(
ins={
"artifact": AssetIn(
key="my_artifact",
input_manager_key="wandb_artifacts_manager",
)
},
)
def get_artifact(context, artifact):
context.log.info(artifact.name)
```
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](https://docs.python.org/3/library/pickle.html), 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](https://github.com/uqfoundation/dill), [cloudpickle](https://github.com/cloudpipe/cloudpickle), [joblib](https://github.com/joblib/joblib)). Vous pouvez aussi utiliser des méthodes de sérialisation plus avancées comme [ONNX](https://onnx.ai/) ou [PMML](https://en.wikipedia.org/wiki/Predictive_Model_Markup_Language), 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
### 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.
```python theme={null}
import numpy
import onnxruntime as rt
from skl2onnx import convert_sklearn
from skl2onnx.common.data_types import FloatTensorType
from sklearn.datasets import load_iris
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from dagster import AssetIn, AssetOut, asset, multi_asset
@multi_asset(
compute_kind="Python",
outs={
"my_onnx_model": AssetOut(
metadata={
"wandb_artifact_configuration": {
"type": "model",
}
},
io_manager_key="wandb_artifacts_manager",
),
"my_test_set": AssetOut(
metadata={
"wandb_artifact_configuration": {
"type": "test_set",
}
},
io_manager_key="wandb_artifacts_manager",
),
},
group_name="onnx_example",
)
def create_onnx_model():
# Inspiré de https://onnx.ai/sklearn-onnx/
# Entraîner un modèle.
iris = load_iris()
X, y = iris.data, iris.target
X_train, X_test, y_train, y_test = train_test_split(X, y)
clr = RandomForestClassifier()
clr.fit(X_train, y_train)
# Convertir au format ONNX
initial_type = [("float_input", FloatTensorType([None, 4]))]
onx = convert_sklearn(clr, initial_types=initial_type)
# Écrire les Artifacts (modèle + test_set)
return onx.SerializeToString(), {"X_test": X_test, "y_test": y_test}
@asset(
name="experiment_results",
compute_kind="Python",
ins={
"my_onnx_model": AssetIn(
input_manager_key="wandb_artifacts_manager",
),
"my_test_set": AssetIn(
input_manager_key="wandb_artifacts_manager",
),
},
group_name="onnx_example",
)
def use_onnx_model(context, my_onnx_model, my_test_set):
# Inspiré de https://onnx.ai/sklearn-onnx/
# Calculer la prédiction avec ONNX Runtime
sess = rt.InferenceSession(my_onnx_model)
input_name = sess.get_inputs()[0].name
label_name = sess.get_outputs()[0].name
pred_onx = sess.run(
[label_name], {input_name: my_test_set["X_test"].astype(numpy.float32)}
)[0]
context.log.info(pred_onx)
return pred_onx
```
### Utiliser des partitions
L’intégration prend directement en charge les [partitions Dagster](https://docs.dagster.io/guides/build/partitions-and-backfills).
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.
#### 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 :
```python theme={null}
"*": {
"get": "default_table_name",
},
```
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 :
```python theme={null}
"yellow": {
"get": "custom_table_name",
},
```
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 :
```python theme={null}
"orange": {
"version": "v0",
},
```
Cette configuration récupérera les données de la partition de l’Artifact `orange` en version `v0`.
Pour les alias :
```python theme={null}
"blue": {
"alias": "special_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 :
* [Exemple d’utilisation avancée pour les assets](https://github.com/dagster-io/dagster/blob/master/examples/with_wandb/with_wandb/assets/advanced_example.py)
* [Exemple de job partitionné](https://github.com/dagster-io/dagster/blob/master/examples/with_wandb/with_wandb/ops/partitioned_job.py)
* [Associer un modèle au registre de modèles](https://github.com/dagster-io/dagster/blob/master/examples/with_wandb/with_wandb/assets/model_registry_example.py)
## 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.
### 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](/fr/platform/launch).
Vous pouvez également consulter les descriptions de toutes les propriétés dans Launchpad.
Exemple :
```python theme={null}
# ajoutez ceci à votre config.yaml
# vous pouvez également définir la configuration dans le Launchpad de Dagit ou dans JobDefinition.execute_in_process
# Référence : https://docs.dagster.io/concepts/configuration/config-schema#specifying-runtime-configuration
resources:
wandb_config:
config:
entity: my_entity # remplacez par votre entité W&B
project: my_project # remplacez par votre projet W&B
ops:
run_launch_agent:
config:
max_jobs: -1
queues:
- my_dagster_queue
from dagster_wandb.launch.ops import run_launch_agent
from dagster_wandb.resources import wandb_resource
from dagster import job, make_values_resource
@job(
resource_defs={
"wandb_config": make_values_resource(
entity=str,
project=str,
),
"wandb_resource": wandb_resource.configured(
{"api_key": {"env": "WANDB_API_KEY"}}
),
},
)
def run_launch_agent_example():
run_launch_agent()
```
### 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](/fr/platform/launch).
Vous pouvez également consulter dans Launchpad des descriptions pour toutes les propriétés.
Exemple :
```python theme={null}
# ajoutez ceci à votre config.yaml
# vous pouvez également définir la configuration dans le Launchpad de Dagit ou via JobDefinition.execute_in_process
# Référence : https://docs.dagster.io/concepts/configuration/config-schema#specifying-runtime-configuration
resources:
wandb_config:
config:
entity: my_entity # remplacez par votre entité W&B
project: my_project # remplacez par votre projet W&B
ops:
my_launched_job:
config:
entry_point:
- python
- train.py
queue: my_dagster_queue
uri: https://github.com/wandb/example-dagster-integration-with-launch
from dagster_wandb.launch.ops import run_launch_job
from dagster_wandb.resources import wandb_resource
from dagster import job, make_values_resource
@job(resource_defs={
"wandb_config": make_values_resource(
entity=str,
project=str,
),
"wandb_resource": wandb_resource.configured(
{"api_key": {"env": "WANDB_API_KEY"}}
),
},
)
def run_launch_job_example():
run_launch_job.alias("my_launched_job")() # on renomme le job avec un alias
```
## 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()`](/fr/models/ref/python/experiments/artifact#download) ou [`Run.log_artifact()`](/fr/models/ref/python/experiments/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](#configuration-1) 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](/fr/models/runs/resuming) 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 :
```python theme={null}
wandb.init(
id=context.run_id,
resume="allow",
...
)
```
Ou choisissez votre propre ID de run W\&B et renseignez-le dans la configuration de l’IO Manager :
```python theme={null}
wandb.init(
id="my_resumable_run_id",
resume="allow",
...
)
@job(
resource_defs={
"io_manager": wandb_artifacts_io_manager.configured(
{"wandb_run_id": "my_resumable_run_id"}
),
}
)
```
### 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](https://docs.python.org/3/library/pickle.html). 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](https://github.com/uqfoundation/dill), [cloudpickle](https://github.com/cloudpipe/cloudpickle), [joblib](https://github.com/joblib/joblib)).
Vous pouvez également utiliser des formats de sérialisation plus avancés comme [ONNX](https://onnx.ai/) ou [PMML](https://en.wikipedia.org/wiki/Predictive_Model_Markup_Language) 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.