`Introduction <../beginner/ddp_series_intro.html>`__ \|\| `What is DDP <../beginner/ddp_series_theory.html>`__ \|\| `Single-Node Multi-GPU Training <../beginner/ddp_series_multigpu.html>`__ \|\| `Fault Tolerance <../beginner/ddp_series_fault_tolerance.html>`__ \|\| `Multi-Node training `__ \|\| **minGPT Training** Training “real-world” models with DDP ===================================== Authors: `Suraj Subramanian `__ .. grid:: 2 .. grid-item-card:: :octicon:`mortar-board;1em;` What you will learn - Best practices when writing a distributed training script - Increased flexibility with saving/loading artifacts in the cloud - When DDP is NOT suitable .. grid:: 1 .. grid-item:: :octicon:`code-square;1.0em;` View the code used in this tutorial on `GitHub `__ .. grid-item-card:: :octicon:`list-unordered;1em;` Prerequisites - Familiarity with `multi-GPU training <../beginner/ddp_series_multigpu.html>`__ and `torchrun <../beginner/ddp_series_fault_tolerance.html>`__ - [Optional] Familiarity with `multinode training `__ - 2 or more TCP-reachable GPU machines (this tutorial uses AWS p3.2xlarge instances) - PyTorch `installed `__ with CUDA on all machines Follow along with the video below or on `youtube `__. .. raw:: html
In this video, we will review the process of training a GPT model in multinode DDP. We first clone the `minGPT repo `__ and refactor the Trainer to resemble the structure we have used in this series. Watch the video for details on these changes. We use `hydra `__ to centrally manage all the configurations for our training run. Once the code has been refactored, we run it first on a single-node with 4 GPUs, and then on a slurm cluster. Files used for training ~~~~~~~~~~~~~~~~~~~~~~~~ - `trainer.py `__ includes the Trainer class that runs the distributed training iterations on the model with the provided dataset. - `model.py `__ defines the model architecture. - `char_dataset.py `__ contains the ``Dataset`` class for a character-level dataset. - `gpt2_train_cfg.yaml `__ contains the configurations for data, model, optimizer, and training run. - `main.py `__ is the entry point to the training job. It sets up the DDP process group, reads all the configurations and runs the training job. Saving and Loading from the cloud ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the video above, we save training snapshots directly to the cloud. This gives us the flexibility to continue training from any node that has access to the cloud bucket. Using Mixed Precision ~~~~~~~~~~~~~~~~~~~~~~~~ To speed things up, you might be able to use `Mixed Precision `__ to train your models. In Mixed Precision, some parts of the training process are carried out in reduced precision, while other steps that are more sensitive to precision drops are maintained in FP32 precision. When is DDP not enough? ~~~~~~~~~~~~~~~~~~~~~~~~ A typical training run's memory footprint consists of model weights, activations, gradients, the input batch, and the optimizer state. Since DDP replicates the model on each GPU, it only works when GPUs have sufficient capacity to accomodate the full footprint. When models grow larger, more aggressive techniques might be useful: - `activation checkpointing `__: Instead of saving intermediate activations during the forward pass, the activations are recomputed during the backward pass. In this approach, we run more compute but save on memory footprint. - `Fully-Sharded Data Parallel `__: Here the model is not replicated but "sharded" across all the GPUs, and computation is overlapped with communication in the forward and backward passes. Read our `blog `__ to learn how we trained a 1 Trillion parameter model with FSDP. Further Reading --------------- - `Multi-Node training with DDP `__ (previous tutorial in this series) - `Mixed Precision training `__ - `Fully-Sharded Data Parallel `__ - `Training a 1T parameter model with FSDP `__ - `FSDP Video Tutorial Series `__