- Keeping a single “primary” run active throughout a script while spinning up short-lived “secondary” runs for evaluations or sub-tasks.
- Orchestrating sub-experiments in a single file.
- Logging from one “main” process to several runs that represent different tasks or time periods.
wandb.init()
. If you call wandb.init()
again, W&B will either return the same run or finish the old run before starting a new one, depending on the configuration. The content in this guide explains how to use reinit
to modify the wandb.init()
behavior to enable multiple runs in a single Python process.
RequirementsTo manage multiple runs in a single Python process, you must have W&B Python SDK version
v0.19.10
or newer.reinit
options
Use the reinit
parameter to configure how W&B handles multiple calls to wandb.init()
. The following table describes valid arguments and their effects:
Description | Creates a run? | Example use case | |
---|---|---|---|
create_new | Create a new run with wandb.init() without finishing existing, active runs. W&B does not automatically switch the global wandb.Run to new runs. You must hold onto each run object yourself. See the multiple runs in one process example below for details. | Yes | Ideal for creating and managing concurrent processes. For example, a “primary” run that remains active while you start or end “secondary” runs. |
finish_previous | Finish all active runs with run.finish() before creating a new one run with wandb.init() . Default behavior for non notebook environments. | Yes | Ideal when you want to break sequential sub-processes into separate individual runs. |
return_previous | Return the most recent, unfinished run. Default behavior for notebook environments. | No |
W&B does not support
create_new
mode for W&B Integrations that assume a single global run, such as Hugging Face Trainer, Keras callbacks, and PyTorch Lightning. If you use these integrations, you should run each sub-experiment in a separate process.Specifying reinit
-
Use
wandb.init()
with thereinit
argument directly: -
Use
wandb.init()
and pass awandb.Settings
object to thesettings
parameter. Specifyreinit
in theSettings
object: -
Use
wandb.setup()
to set thereinit
option globally for all runs in the current process. This is useful if you want to configure the behavior once and have it apply to all subsequentwandb.init()
calls in that process. -
Specify the desired value for
reinit
in the environment variableWANDB_REINIT
. Defining an environment variable applies thereinit
option towandb.init()
calls.
wandb.init()
:
Example: Concurrent processes
Suppose you want to create a primary process that remains open for the script’s entire lifespan, while periodically spawning short-lived secondary processes without finishing the primary process. For example, this pattern can be useful if you want to train a model in the primary run, but compute evaluations or do other work in separate runs. To achieve this, usereinit="create_new"
and initialize multiple runs. For this example, suppose “Run A” is the primary process that remains open throughout the script, while “Run B1”, “Run B2”, are short-lived secondary runs for tasks like evaluation.
The high level workflow might look like this:
- Initialize the primary process Run A with
wandb.init()
and log training metrics. - Initialize Run B1 (with
wandb.init()
), log data, then finish it. - Log more data to Run A.
- Initialize Run B2, log data, then finish it.
- Continue logging to Run A.
- Finally finish Run A at the end.
reinit="create_new"
creates a new run each time you callwandb.init()
.- You keep references of each run.
wandb.run
does not automatically point to the new run created withreinit="create_new"
. Store new runs in variables likerun_a
,run_b1
, etc., and call.log()
or.finish()
on those objects as needed. - You can finish sub-runs whenever you want while keeping the primary run open until.
- Finish your runs with
run.finish()
when you are done logging to them. This ensures that all data is uploaded and the run is properly closed.