wandb

Initializes a Run object via wandb.init() that represents a single training execution, managing the complete lifecycle from creation through metrics collection to finalization. The SDK creates a unique run ID, associates it with a project, and establishes bidirectional communication with the wandb-core Go service via inter-process communication (IPC) for asynchronous metric buffering and file uploads. The Run object provides methods like log(), save(), log_artifact(), and finish() that serialize user data and queue it for transmission to the W&B backend (cloud or self-hosted).

Records scalar metrics, media (images, audio, video), and structured data via wandb.log() or run.log(), which serializes diverse Python objects (NumPy arrays, PyTorch tensors, PIL images, pandas DataFrames) into JSON-compatible formats and queues them for transmission. Each log() call increments a step counter, creating a time-series history. The SDK maintains two separate data structures: history (step-indexed time-series) and summary (final/best values), allowing both granular temporal analysis and efficient aggregation. Serialization is handled by custom type handlers that convert framework-specific objects into W&B's internal media types (Image, Audio, Video, Table, Histogram, etc.).

Provides a command-line interface (wandb CLI) for managing runs, artifacts, and sweeps without Python code. The CLI includes commands like wandb login (authenticate), wandb sync (sync offline runs), wandb artifact (download/manage artifacts), wandb launch (submit training jobs), and wandb sweep (create/manage sweeps). The CLI also supports data export via wandb export (export run data to CSV/JSON) and wandb pull (download artifacts). The CLI is implemented in Python and uses the same SDK internals as the Python API, ensuring consistency. The CLI supports both cloud (wandb.ai) and self-hosted W&B instances via configuration.

Provides a Python API client (wandb.Api()) for programmatic access to run data, artifacts, and projects without instrumenting training code. The API client uses the W&B GraphQL API to query runs, metrics, and artifacts, and supports filtering, sorting, and pagination. Users can fetch run data (config, metrics, summary), download artifacts, and perform bulk operations (e.g., update tags, delete runs). The API client also supports creating and managing projects, teams, and service accounts. The client is rate-limited to prevent abuse, and supports both cloud (wandb.ai) and self-hosted W&B instances.

Provides immutable, versioned storage for datasets, models, and files via the Artifact class and run.log_artifact() / run.use_artifact() methods. Each artifact has a type (e.g., 'dataset', 'model'), semantic version, manifest of files with SHA256 checksums, and metadata/aliases. Artifacts are stored in W&B's artifact registry (cloud or self-hosted) and can be referenced across runs and projects via entity/project/artifact-name:version syntax. The SDK implements a manifest-based system where file additions/deletions are tracked, enabling incremental uploads and deduplication. Aliases (e.g., 'latest', 'production') allow dynamic references without hardcoding versions.

Orchestrates hyperparameter search via the sweep system, which defines a search space (grid, random, Bayesian) and spawns multiple runs with different hyperparameter combinations. The sweep controller (implemented in wandb-core) manages job scheduling, early stopping, and result aggregation. Users define sweeps via YAML configuration specifying the search space (parameters, bounds, distribution), optimization metric, and stopping criteria. The SDK provides wandb.agent() to connect training scripts to the sweep controller, which injects hyperparameters via wandb.config. Supports distributed sweeps across multiple machines via a central controller that tracks run results and decides next hyperparameter suggestions.

Provides native integrations with popular ML frameworks (PyTorch, TensorFlow, Keras, JAX, Hugging Face Transformers, LightGBM, XGBoost, scikit-learn) via callback classes and monkey-patching. For PyTorch, wandb provides a WandbCallback that hooks into the training loop to log gradients, weights, and loss automatically. For TensorFlow/Keras, a WandbCallback integrates with the fit() API. Hugging Face Transformers integration uses a custom Callback that logs training/validation metrics. The SDK also patches framework-specific functions (e.g., torch.nn.Module.backward()) to capture gradients and layer activations without explicit user code. This enables zero-configuration logging for common workflows while allowing fine-grained control via explicit log() calls.

Supports distributed training across multiple GPUs and machines by synchronizing metrics and artifacts across worker processes. The SDK detects distributed training environments (PyTorch DDP, TensorFlow distributed strategies, Horovod) and coordinates logging to avoid duplicate metrics from multiple workers. Only the rank-0 (primary) process logs metrics by default, while other ranks can optionally log rank-specific data. The wandb-core service handles file uploads asynchronously, preventing network I/O from blocking training on any rank. For multi-node training, the SDK uses a central W&B backend to aggregate metrics from all nodes, providing a unified view of distributed training progress.

Automatically monitors system resources (CPU, memory, disk I/O) and GPU metrics (utilization, memory, temperature, power) during training via a background monitoring thread and the gpu_stats Rust module. The monitoring thread samples system metrics at configurable intervals (default 30s) and logs them to the run's history. GPU monitoring uses NVIDIA's NVML library (via gpu_stats) to capture per-GPU metrics without requiring nvidia-smi subprocess calls, reducing overhead. The SDK also captures environment metadata (Python version, CUDA version, GPU model) at run initialization. Metrics are logged with a special 'system' namespace to avoid collision with user metrics.

Provides a web-based dashboard (wandb.ai or self-hosted) for visualizing and comparing runs across multiple dimensions. The dashboard displays metrics over time, compares hyperparameters and final metrics across runs, and provides interactive visualizations (parallel coordinates, scatter plots, histograms). The SDK logs all run data (config, metrics, artifacts, system info) to the W&B backend, which indexes and serves the data via a GraphQL API. The dashboard supports custom charts, filtering, and grouping by tags/metadata. The Python SDK also provides a local API (wandb.Api()) for programmatic access to run data, enabling custom analysis and automation.

Tracks and manages experiment configuration (hyperparameters, model architecture choices, data paths) via the wandb.config object, which is a special dictionary that logs all assignments to the run's metadata. Users set config values via wandb.config.key = value or wandb.config.update(dict), and the SDK automatically logs them to the run. Config is immutable after run initialization (to prevent accidental changes), and all config values are displayed in the dashboard alongside metrics. The SDK also provides a configuration system for sweep parameters, where the sweep controller injects hyperparameters into wandb.config before the training script runs. Config values are serialized as JSON and stored in the run metadata, enabling easy comparison across runs.

Supports offline mode for training environments without network connectivity, where metrics and artifacts are stored locally and synced to the W&B backend when connectivity is restored. In offline mode, wandb.init() creates a local run directory (.wandb/) with a SQLite database for metrics and a file tree for artifacts. The SDK queues all log() calls to the local database and defers uploads until sync() is called or network connectivity is detected. Offline mode is useful for training on air-gapped clusters or edge devices. The SDK also provides a 'disabled' mode where all wandb calls are no-ops, useful for development and testing.