第十章 番外篇：DDP

　　参考教程：

　　what is DDP

　　pytorch distributed overview

　　DDP的全称是DistributedDataParallel，它允许使用pytorch使用数据并行训练。

　　在非分布式训练中，你的模型被放在一个gpu上，你的模型接收来自一个dataloader的inputbatch，它对输入进行前向传播并且计算损失，然后进行反向传播并计算参数的梯度。优化器在这个过程中对模型的参数进行更新。

　　当我们现在多个gpu上进行训练时，DDP会在每个GPU上都启动一个进程，每个进程中都有一个模型的复制品replica(local copy)，每一个模型和优化器的复制品都是相同的。模型的参数初始化相同，优化器也使用一样的随机种子。DDP在训练过程中维持了这种一致性。

　　现在，每个gpu的模型都是一样的。我们仍然从dataloader中获取inputbatch，但是这个时候我们使用的是DistributedSampler。这个sampler保证了每个模型接收到的inputbatch是不同的，这就是“data parallel” in DDP。

　　在每个进程中，模型接收到一个不同的输入，并且locally的进行前向传播和后向传播。因为输入是不同的，所以梯度的累积也是不同的。使用optimizer.step()会产生不同的结果。比如说我们现在有4个gpu，在4个gpu上有4个模型的local copy，那么这四个模型就是不同的模型，而不是我们想要的一个分布式的模型。

　　DDP中的同步机制，会把来自四个replicas的梯度累加起来，其中使用了一个算法，在replicas间进行通信，它不会等待所有的梯度都计算完成，而是在计算过程中就保持着通信，这保证了你的gpu总是在工作的。

　　

　　综合来说，就是在n个gpu上的训练相当于同时进行n个模型的训练，这些模型是完全一样的，实时同步的，只不过传入的数据不一样。

　　在之前介绍数据集构建的时候曾经提到过sampler的概念。假如dataloader中的shuffle = True，你使用的就是一个randomsampler；假如dataloader中的shuffle = False，你使用的就是一个sequentialsampler。

　　DistributedSampler传入的第一个参数是dataset，它要求这个Dataset有一个constant的大小。iterable dataset也可以使用DDP，参考https://github.com/Lightning-AI/lightning/issues/15734。我先不看了，用的时候再说。

　　第二个参数是num_replicas，你想要复制的个数。第三个参数是rank，是当前的process的index。shuffle和seed主要是控制你的dataset是否要shuffle和随机种子。

　　DistributedSampler()一般和torch.nn.parallel.DistributedDataParallel组合使用。在这种情况下，每一个进程都会传递一个DistributedSampler实例，并且加载原始数据中彼此完全不同的子集。

　　在构造函数初始化阶段，会计算每个replica中分配到的samples数。

　　最终获得的dataset中数据的总数就是

　　在取数据的时候，会把不同的数据分配给不同的replicas。

　　在使用DistributedSampler时，在每个epoch都需要调用set_epoch(epoch)函数，这样每个epoch里数据都会按照不同的顺序获取，如果不调用的话，获取的顺序将始终保持一致。因为它随机种子的生成也和当前的epoch有关系。

　　下面给出了一个使用的例子。

　　DDP为了保证不同gpu上的模型能完成同步，需要进行较为繁琐的设置。

　　使用这个类要求你先对torch.distributed进行初始化，通过调用方法。

　　在DistributedDataParallel()中，第一个参数module是你想要并行话的module，在训练中也就是你的模型。

　　参数device_id和output_device代表你的moudle的CUDAdevice和你的output的CUDAdevice。

　　process_group如果为None，会默认使用你的torch.distributed.init_process_group。

　　给出一个简单的示例

　　为了让你的DDP能够在N个GPU上使用，你需要产生N个进程，并且保证每个进程独立的工作在一个GPU上。有两个方法可以完成这个设置。

　　第一个方法是：

　　在每个进程中，你需要进行以下的设置。

　　建议直接参考https://github.com/pytorch/examples/blob/main/distributed/ddp-tutorial-series/multigpu.py。给出了一个完整的模版，可以直接套用。

　　教程中给出了一个比较简单但完整的DDP示例。

　　在这个例子中，init_process_group被封装到一个setup函数里。

　　然后定义一个作为例子的小模型。使用torch.multiprocess产生多个进程，rank表示当前的进程数，或者说CUDA id。world_size代表了gpu的个数。在每个进程中，将你的model放到对应的device上。

　　这个例子中没有加入dataset的部分。只有DDP中模型的使用。

　　torch.multiprocessing基本上就是在python的multiprocessing上进行了一些改动。具体的不讲了【因为我也没有看】，我们只说一下spawn。

　　spawn的输入包括 fn:目标函数, args:函数的参数，nprocs:需要的进程数。

　　在使用这个方法后，multiprocessing会以‘spawn’的方法来创建新的进程。创建的数量由nprocs决定。

　　可以看到在下方代码的mp.Process中使用的target是一个名为_wrap的函数。这个函数把当前process对应的index和args组合在一起，作为输入传入到fn中去。所以理论上来讲，你定义的fn的传入参数数量至少为1个，也就是当前进程的index。而在使用torch中的mp.spawn()时，args里面你不能把这个参数写出来，而只需要写第二个以及以后的参数。

　　模型的保存和加载方法和之前的使用上区别不大。只是加了一点限制。

　　在下方的示例代码中，在DDP中保存state_dict()时用的是model.module.state_dict()。确认了一下发现在ddp(model)的示例化时，model会被赋值给self.module。

　　但是有的例子中并没有使用module.state_dict()来完成保存。

　　这里为了防止重复保存model，限制了只在gpu_id == 0 时才进行模型的保存。

　　一个优化方法是将模型的每次更新都保存在一个进程上然后被加载到所有进程中，这样可以防止多次写入。因为所有的进程都是从一样的参数开始的，并且bp中的梯度计算总是同步的，因此不同gpu上的optimizer也要保持同步。

　　make sure no process starts loading before the saving is finished。

　　在下面的例子中，在rank == 0的情况下才会进行model的保存。使用dist.barrier()限制了save期间的别的process对模型的加载。