Weights & Biases — Experiment Tracking for ML Research

What Weights & Biases is

Weights & Biases is an experiment tracking platform for machine learning. A few lines added to a training script log every metric, hyperparameter, system statistic, and output artefact to a web dashboard where runs can be compared, filtered, grouped, and shared.

The problem it addresses is one every ML researcher recognises and few solve well. A serious project involves hundreds of training runs differing in ways that seemed obvious at the time, and six months later the question “what produced the number in Table 2” has no answer — the notebook has been edited, the config was a command-line flag nobody recorded, and the checkpoint filename is model_final_v2.pt. W&B makes recording the default: the config, the code state, the metrics, and the artefact are captured because the run happened, not because you remembered.

Why researchers use it

Everything is captured automatically — hyperparameters, metrics, gradients, GPU utilisation, and the code state, without you deciding in advance what to keep.
Run comparison that scales — parallel-coordinate plots and filters across hundreds of experiments, which is how you actually find which hyperparameter mattered.
Sweeps — hyperparameter search defined declaratively and distributed across machines, replacing hand-edited loops.
Artefact versioning — datasets and model checkpoints tracked with lineage, so a model traces back to the data and code that produced it.
Free academic tier — team workspaces for research groups at no cost, which is the reason it is near-ubiquitous in ML labs.

Where it fits in a research workflow

W&B sits inside the training loop, recording. Upstream is your data and code; downstream is a paper, and the dashboard is what you consult while writing it.

It divides responsibility with neighbouring tools along reasonably clear lines. DVC versions the datasets; W&B records what happened when you trained on them. Hugging Face hosts the model you eventually publish; W&B holds the two hundred runs that did not make it. GitHub holds the code, and W&B records which commit produced which run. That last link is the underrated one — a dashboard entry pointing at a Git SHA is the connection that makes an experiment reconstructible rather than merely documented.

Getting started

An hour, and instrument one real training run.

pip install wandb and log in with a free academic account, requested with your institutional email.
Add two lines to a training script: wandb.init(project=..., config=...) at the start and wandb.log({...}) in the loop. Run it and open the dashboard.
Put your hyperparameters in the config object rather than in the script. This is what makes runs comparable and filterable later, and it is the habit that determines whether the tool helps.
The step people skip: log the Git commit and the dataset version alongside the metrics. Metrics without provenance tell you what happened but not what to change or how to reproduce it — and reproducing it is the point.

Weights & Biases vs the alternatives

Alternative	Does it better	Pick it if
MLflow	Self-hosting for free, with no vendor in the data path	Institutional policy rules out a hosted service
TensorBoard	Simplicity, and it is already installed	You want loss curves and nothing else
DVC	Versioning the data and models themselves	Your problem is data provenance, not run comparison
A results CSV in Git	Honesty, transparency, and zero dependencies	You have twenty runs, not two thousand

That last row is a serious option. For a modest number of runs, a committed CSV is more transparent than a dashboard and considerably easier for a reviewer to check.

Cost, licensing, and your data

Free for personal use and free academic team workspaces for research groups, with paid tiers for commercial teams. Self-hosting exists but is priced for enterprises, which is the practical constraint on the governance question below.

That governance question is the real consideration. Your experiment metadata — configs, metrics, code state, and any artefacts you log — lives on W&B’s cloud. For most academic ML that is unremarkable. It becomes a genuine issue in two cases: unpublished work under a competitive or commercial constraint, where hyperparameters and architecture details are informative to a reader; and training on sensitive data, where logged sample images, text examples, or per-example metrics can leak the data itself. The second is the one people get wrong — logging a batch of examples for debugging is a normal thing to do and a bad idea when the batch contains patient records.

The honest review

Strengths. W&B is the reproducibility ledger an ML paper needs and rarely has. Six months after a result, the exact configuration behind a table is one search away instead of one archaeology project, and that changes what you can honestly claim. The comparison views genuinely help — parallel coordinates across two hundred runs reveal which hyperparameter is doing the work in a way that scrolling through logs does not. Reports turn a set of runs into shareable supplementary material with almost no additional effort.

Limitations. Your experiment record lives on a company’s servers, and the self-hosted option is priced out of reach for an individual lab, so the governance answer is effectively “accept it or use MLflow”. Logging adds overhead — usually small, occasionally not, and always another network dependency in a training loop that may run on a cluster with restricted egress. The dashboard invites metric-staring: watching curves update is engaging and is not thinking. And there is real lock-in — two years of experimental history in one platform is not casually portable.

Verdict. Adopt it if you run deep-learning experiments at any scale and your data has no confidentiality constraint — the free academic tier makes the decision easy. Skip it for classical statistics, for a handful of runs, and for anything where training data must not leave your infrastructure, where MLflow self-hosted is the answer. The condition that flips the answer is run count: below a few dozen, a CSV in Git is more honest and easier to review.

When NOT to use this Do not log examples from sensitive data. Logging a batch of images or text for debugging is a normal habit and a serious disclosure when the batch contains patient records, participant responses, or anything under a data agreement — the samples end up on a third-party dashboard, indefinitely, and usually nobody notices. Log aggregate metrics only for restricted data, and if the training data itself cannot leave your infrastructure, self-host MLflow instead of accepting a hosted service.

Common questions

Is Weights & Biases free for academics?

Yes — free personal use and free team workspaces for academic research groups, requested with an institutional email. Paid tiers apply to commercial teams, and self-hosting is enterprise-priced.

Can I use W&B without sending data to their cloud?

Not practically at academic scale — self-hosting exists but is priced for enterprises. If your institution’s policy or your data’s sensitivity rules out a hosted service, MLflow is the self-hostable alternative and is free.

Do I need experiment tracking for a small project?

Below a few dozen runs, a results CSV committed to Git is more transparent, easier for a reviewer to check, and has no dependencies. Experiment tracking starts paying off at the scale where you cannot hold the run history in your head — typically tens to hundreds of runs, or any project with multiple collaborators.