Using experiment trackers
Tracking
There are a large number of experiment tracking APIโs available, however getting them all to work with in a multi-processing environment can oftentimes be complex. ๐ Accelerate provides a general tracking API that can be used to log useful items during your script through Accelerator.log()
Integrated Trackers
Currently Accelerate
supports four trackers out-of-the-box:
TensorBoard
WandB
CometML
MLFlow
To use any of them, pass in the selected type(s) to the log_with
parameter in Accelerate
:
Copied
At the start of your experiment Accelerator.init_trackers()
should be used to setup your project, and potentially add any experiment hyperparameters to be logged:
Copied
When you are ready to log any data, Accelerator.log()
should be used. A step
can also be passed in to correlate the data with a particular step in the training loop.
Copied
Once youโve finished training, make sure to run Accelerator.end_training()
so that all the trackers can run their finish functionalities if they have any.
Copied
A full example is below:
Copied
If a tracker requires a directory to save data to, such as TensorBoard
, then pass the directory path to project_dir
. The project_dir
parameter is useful when there are other configurations to be combined with in the ProjectConfiguration data class. For example, you can save the TensorBoard data to project_dir
and everything else can be logged in the logging_dir
parameter of [~utils.ProjectConfiguration
:
Copied
Implementing Custom Trackers
To implement a new tracker to be used in Accelerator
, a new one can be made through implementing the GeneralTracker
class. Every tracker must implement three functions and have three properties:
__init__
:Should store a
run_name
and initialize the tracker API of the integrated library.If a tracker stores their data locally (such as TensorBoard), a
logging_dir
parameter can be added.
store_init_configuration
:Should take in a
values
dictionary and store them as a one-time experiment configuration
log
:Should take in a
values
dictionary and astep
, and should log them to the run
name
(str
):A unique string name for the tracker, such as
"wandb"
for the wandb tracker.This will be used for interacting with this tracker specifically
requires_logging_directory
(bool
):Whether a
logging_dir
is needed for this particular tracker and if it uses one.
tracker
:This should be implemented as a
@property
functionShould return the internal tracking mechanism the library uses, such as the
run
object forwandb
.
Each method should also utilize the state.PartialState class if the logger should only be executed on the main process for instance.
A brief example can be seen below with an integration with Weights and Biases, containing only the relevant information and logging just on the main process:
Copied
When you are ready to build your Accelerator
object, pass in an instance of your tracker to Accelerator.log_with
to have it automatically be used with the API:
Copied
These also can be mixed with existing trackers, including with "all"
:
Copied
Accessing the internal tracker
If some custom interactions with a tracker might be wanted directly, you can quickly access one using the Accelerator.get_tracker() method. Just pass in the string corresponding to a trackerโs .name
attribute and it will return that tracker on the main process.
This example shows doing so with wandb:
Copied
From there you can interact with wandb
โs run
object like normal:
Copied
Trackers built in Accelerate will automatically execute on the correct process, so if a tracker is only meant to be ran on the main process it will do so automatically.
If you want to truly remove Accelerateโs wrapping entirely, you can achieve the same outcome with:
Copied
When a wrapper cannot work
If a library has an API that does not follow a strict .log
with an overall dictionary such as Neptune.AI, logging can be done manually under an if accelerator.is_main_process
statement:
Copied
Last updated