1 介绍 

• PyTorch 的分布式模块通过在系统中所有GPU之间进行来回通信来操作。
  • 这种通信需要时间，并且确保所有进程了解彼此的状态
  • 在使用ddp模块时会在特定的触发点发生
    • 这些触发点被添加到PyTorch模型中，特别是它们的 forward() 和 backward() 方法中
• 当通过 optimizer.step() 更新模型参数时。如果不进行梯度累积，所有模型实例需要更新它们计算、汇总和更新的梯度，然后才能继续到下一批数据。
  • 这种无谓的进程间通信可能会导致显著的减速
• 进行梯度累积时，会累积 n 个损失梯度并跳过 optimizer.step()，直到达到 n 批次
• 如果不注意梯度同步和GPU通信，当这些GPU在不必要的时期相互通信时，可能会浪费大量时间。

1.1直观感受一下速度的差异

先直观看一下不进行任何改进的话，每个batch都进行通信，会是什么样的速度：

考虑以下设置：

• 两个单GPU节点、一个有两个GPU的节点
• 每个GPU都是T4，并托管在GCP上
• 每个GPU的批次大小为16，梯度每4步累积一次

比较的内容：

• 基线：没有使用任何同步实践【同步实践后面会说】
• no_sync使用不当：只在backward调用时使用no_sync，而不是在forward
• 正确使用no_sync：正确使用no_sync模式
• 使用accumulate：正确使用accumulate()

以下是每种设置在单节点和双节点设置上迭代29批数据的平均秒数：

2 解决方法1：no_sync

• 通过 no_sync 上下文管理器
• 在此上下文管理器下，PyTorch 将跳过在调用 .backward() 时同步梯度
• 此上下文管理器外的第一次调用 .backward() 将触发同步

另一种写法是：

3 解决方法2：accumulate 梯度累计