Skip to main content
This guide describes patterns for integrating W&B into a Python library, framework, or SDK. It covers dependency management, authentication, optional logging, run initialization, artifacts, hyperparameter tuning, and distributed execution. Use this guide when your integration spans reusable library code rather than a single training script or notebook. For an introduction to W&B, see Experiment Tracking.

Design the integration

Before adding W&B to your library, decide:
  • Whether wandb is a required or optional dependency.
  • Whether users can run your library without saving or uploading W&B data.
  • Which configuration values, metrics, and artifacts your library logs.
  • Whether to support hyperparameter tuning with W&B Sweeps.
  • Whether to share artifacts, such as models and datasets, through your organization’s W&B Registry.
  • How your library handles distributed training and multiple processes.
These decisions determine how your library imports W&B, manages run lifecycles, and behaves when W&B is unavailable.

Decide how to install W&B

Choose whether to install W&B automatically with your library or expose it as an optional feature.

Require W&B as a dependency

If W&B is central to your library, add wandb to its dependencies. For a requirements.txt file:
requirements.txt
For a pyproject.toml file:
pyproject.toml
Consider specifying a compatible version range based on the W&B features your integration uses.

Make W&B an optional dependency

If W&B is an optional feature, enable installation of your library without wandb. Declare W&B as an optional dependency in pyproject.toml:
pyproject.toml
Then install the integration with:

Authenticate users

W&B uses API keys to authenticate users and machines. Before you can log runs from your library, you must generate an API key and make it available to the wandb client. W&B supports authentication through the CLI, environment variables, and wandb.login().

Create an API key

For a more streamlined approach, go to User Settings and create an API key. Copy the API key immediately and save it in a secure location such as a password manager.

Authenticate from the command line

From your terminal, run:
W&B prompts you to enter an API key. Alternatively, set the WANDB_API_KEY environment variable:
For more information, see Environment variables.

Authenticate from Python

In an interactive Python environment or notebook, call:
Avoid calling wandb.login() automatically from reusable library code because it can interrupt noninteractive workflows.

Make W&B logging optional

Choose whether W&B saves or uploads run data. Use disabled when you do not want to save run data. Use offline when they want to save data locally for later upload.

Use disabled mode

Pass mode="disabled" to wandb.init():
Or set WANDB_MODE in the environment:
You can also set the mode with the W&B CLI:

Use offline mode

Pass mode="offline" to wandb.init():
Or set WANDB_MODE in the environment:
In Python, set the environment variable before calling wandb.init():
You can also set the mode with the W&B CLI:
Upload an offline run later with:

Initialize a run

After authenticating, initialize a run to log metrics, configuration values, and artifacts from your library. Call wandb.init() and specify the project and team entity. If you omit the project, W&B stores the run in the default "uncategorized" project. Use wandb.init() as a context manager around the training loop. When the block exits, W&B finishes the run and processes pending data before the process ends. For example, suppose your library contains the following training loop:
Python
To integrate W&B, initialize a run with a context manager, pass configuration values to wandb.init(), and log metrics with wandb.Run.log():
Python
When to call wandb.init()Call wandb.init() before the work you want W&B to monitor. Use it as a context manager around the entire training loop so the run captures relevant standard output, standard error, and error messages for debugging.
The next section describes in detail how to log configuration values and metrics from your library.

Log configuration and metrics

Log configuration values and metrics to W&B so you, and members of your team, can compare, filter, group, and reproduce experiments.

Log configuration values

Pass a configuration dictionary to wandb.init() to record hyperparameters and other metadata. Use descriptive keys and JSON-serializable values:
Pass the dictionary to wandb.init():
Some values might not be available when the run starts. Add them later with wandb.Run.config.update():
For more information, see Configure experiments.

Log metrics

Log metrics such as loss or accuracy during training. Create a dictionary where each key is the name of a metric and the value is the metric value. Pass this dictionary to wandb.Run.log(). The following code snippet logs training and validation metrics to W&B:
Python
Use prefixes such as train/ and val/ to group related metrics. For guidance on logging supported data types, automatically tracked data, and best practices, see Log metrics and data. To track models and datasets, see the Track models and datasets with artifacts section.

Define a custom log axis

By default, W&B plots logged metrics against an automatically incremented step. Each call to wandb.Run.log() advances the step. Use wandb.Run.define_metric() to plot a metric against another value, such as an epoch or global step. The following example defines x_axis_squared as the x-axis for validation_loss. For each loop iteration, x_axis_squared is the square of the index i, and validation_loss is a randomly generated value:
Python
For more information, see Define a custom log axis.

Track models and datasets with artifacts

In addition to metrics, you can persist the models and datasets your library produces or consumes so that you, and members of your team, can reproduce and compare runs. Use W&B Artifacts to version models, datasets, and other files that your library produces or consumes. Before adding artifact support, decide:
  • Which files to log.
  • Whether artifact logging is optional.
  • How frequently to log checkpoints.
  • How to name artifacts and aliases.
  • Which artifacts represent run inputs and outputs.

Log model checkpoints

Log model checkpoints as artifacts so you can recover, version, and share trained weights. Include the run ID in the artifact name to associate each checkpoint with its source run. The following example logs a checkpoint every 10 epochs. It creates an artifact whose name includes the run ID, adds model weights from a local directory, and logs the artifact with a custom alias.
Python

Track run inputs

Use wandb.Run.use_artifact() when a run consumes an artifact, such as a dataset or model checkpoint. W&B records the artifact as an input to the run. Specify the name of the artifact and an optional alias to reference a specific version of that artifact. The name of the artifact is in the format artifact_name:version or artifact_name:alias.
Python

Track run outputs

Use wandb.Run.log_artifact() to log an artifact as an output of a run.
  1. Create an artifact with wandb.Artifact().
  2. Add one or more files to the artifact.
  3. Log the artifact with wandb.Run.log_artifact().
For more information about creating, managing, and using artifacts, see Artifacts.

Download artifacts

Use the W&B Public API to download an artifact without creating a run or recording a run input relationship.
For information, see Download and use artifacts. Use W&B Registry to share and manage artifact versions across teams. Before you link an artifact version, decide:
  • Which artifact versions to share.
  • Which collections to link them to.
  • Which registry to publish them in.
The destination registry must already exist.
The following example logs an artifact and links it to a collection in a registry:
For more information, see Link an artifact version to a collection.

Tune hyperparameters

If your library supports hyperparameter tuning, integrate W&B Sweeps to run grid, random, or Bayesian searches.
W&B recommends that you keep the sweep configuration separate from the underlying training logic. The training function should read its parameters from wandb.Run.config rather than depending directly on sweep-specific logic.
For more information, see Sweeps.

Support distributed training

If your library supports multiple processes or machines, define which processes create runs and log data. Common approaches include:
  • Log only from the main process. This approach avoids duplicate metrics and artifacts.
  • Create one run for each process and group the runs with a shared group value.
For more information, see Log distributed training experiments.