每个进程维护自己的优化器，并在每次迭代中执行一个完整的优化步骤。虽然这可能看起来是多余的，但由于梯度已经聚合（gather）并跨进程平均，因此梯度对于每个进程都是相同的，这意味着不需要参数广播步骤，减少了在节点之间传输张量所花费的时间。
All-Reduce 操作是在后向传播之中完成的。
- 在 DDP 初始化时候会生成一个Reducer，其内部会注册 autograd_hook。
- autograd_hook 在反向传播时候进行梯度同步。

DDP 选择了在 PyTorch 内核角度修改，在 DistributedDataParallel 模型的初始化和前向操作中做了处理。

具体逻辑如下：

DDP 使用多进程并行加载数据，在 host 之上，每个worker进程都会把数据从硬盘加载到 page-locked memory。分布式 minibatch sampler 保证每个进程加载到的数据是彼此不重叠的。
不需要广播数据，而是并行把 minibatch 数据从 page-locked memory 加载到每个GPU，每个GPU都拥有模型的一个副本，所以也不需要拷贝模型。
在每个GPU之上运行前向传播，计算输出，每个GPU都执行同样的训练，不需要有主 GPU。
在每个GPU之上计算损失，运行后向传播来计算梯度，在计算梯度同时对梯度执行all-reduce操作。
更新模型参数。因为每个GPU都从完全相同的模型开始训练，并且梯度被all-reduced，因此每个GPU在反向传播结束时最终得到平均梯度的相同副本，所有GPU上的权重更新都相同，这样所有 worker 上的模型都一致，也就不需要模型同步了。

因为也是在模型的前向后向操作之中进行修改，所以优化器也不需要修改，每个worker分别在自己本地进程之中进行优化。

这里要留意的是，如何保证各个进程的优化器状态相同？

DDP 与优化器实际上没有关联，DDP不对此负责，所以需要用户协同操作来保证各进程之间的优化器状态相同。这就围绕着两个环节：

其示例如下：

图示如下：

Horovod 并没有对模型 fw/bw 进行修改（可能因为没有Facebook自己修改那么顺手），而是对优化器进行了修改，实现了一个 DistributedOptimizer。

我们以 horovod/torch/optimizer.py 为例。

DistributedOptimizer 包装了另一个torch.optim.optimizer，其作用是：

其具体实现是，而对于梯度的归并有两个途径，一个是通过 hook，一个是显性调用了 synchronize 函数，我们接下来逐一介绍。

hook 就是采用了 PyTorch 的 hook 方法，和 DDP 的思路非常类似，即在梯度计算函数之上注册了hook，其作用是在计算完梯度之后调用hook，这样all-reduce 就是在计算梯度过程中自动完成的，不需要等待 step 方法显式调用来完成（类似 DP 那样），具体来说就是：

在每个GPU之上计算损失，运行后向传播来计算梯度，在计算梯度同时对梯度执行all-reduce操作。
更新模型参数。因为每个GPU都从完全相同的模型开始训练，并且梯度被all-reduced，因此每个GPU在反向传播结束时最终得到平均梯度的相同副本，所有GPU上的权重更新都相同，也就不需要模型同步了。

注：代码主要分为两部分，处理 groups 相关和普通情况。

groups 是 PyTorch 的相关配置，作用是把梯度 allreduce 操作放在一起进行，因为代码比较复杂并且与本文主体逻辑不相关，所以我们略过这部分，只看普通非分组情况。