keras 分布式_分布式深度学习初探

最新推荐文章于 2024-09-03 09:56:25 发布

著名工具人

最新推荐文章于 2024-09-03 09:56:25 发布

阅读量455

点赞数 1

文章标签： keras 分布式

本文链接：https://blog.csdn.net/weixin_35462155/article/details/112206000

版权

本文介绍了分布式深度学习的现状，包括模型并行与数据并行、同步更新与异步更新的对比。重点讨论了Parameter Server和Ring Allreduce通信机制，提出Horovod作为高效解决方案。并探讨了Horovod的性能调优，包括网络带宽检查、GPU使用率监控以及学习率预热策略。总结了如何通过Horovod快速搭建和优化分布式训练架构。

摘要由CSDN通过智能技术生成

此系列文章为笔者学习工作中的阶段性总结，难免有纰漏，如有不正之处，欢迎指正，大家共同成长。

分布式深度学习现状

在深度学习中，随着模型和数据的不断增长，在很多情况下需要使用单机多卡或者多机多卡进行训练，即分布式训练。当前的分布式深度学习主要包含以下模块[1]。

数据与模型划分：模型并行 vs 数据并行
单机优化：优化算法(略)
通信机制：网络拓扑(Parameter Server vs Allreduce), 通信步调(同步更新 vs 异步更新)
模型聚合：对单机优化的模型参数/梯度进行汇总，更新新的参数(略)

分布式深度学习架构

模型并行vs数据并行

当模型过大无法在单机上存储时，会采用模型并行将模型分割到不通机器上，但多数情况下，一块常规显卡还是能承受住模型的存储开销的，目前训练数据量过大导致的模型训练速度慢才是分布式机器学习领域的主要矛盾。所以大多数情况下还是使用数据并行的方式，每个GPU平均分配一个batch的数据量。

同步更新 vs 异步更新

同步更新

异步更新

同步更新过程和原始的 mini batch sgd 是等价的，符合梯度下降的规则，训练收敛稳定，但是通信效率低，更新的速度取决于运算最慢的那台机器。

异步更新虽然不用等，但是会出现梯度延时的问题，导致往往收敛效果不佳。

Parameter Server vs Ring Allreduce

在分布式深度学习中，目前主流的通信拓扑结构是PS和Ring Allreduce。拿PS来说，至少经历了三次版本的迭代，这里不打算展开，主要介绍这两种结构的基本思想。

首先看到一个简化的PS的结构：

Parameter Server

对于数据并行的同步更新训练过程，所有GPU上开始都存有模型的副本，每一轮迭代所有的worker独立完成 forward 和 backward ，并将各自backward得到的参数梯度传递给server来做平均、更新，server更新好参数后再将其复制给所有的worker。

两次传递过程的通信量分别是全量的模型梯度。从上图可以明显看到，PS的瓶颈出现在server与其余worker之间的通信，单个GPU的带宽是很有限的，随着worker数目增加，通信的开销将会越大。

举例而言，假设需要训练的模型有300w参数，每个参数是4bytes，那么参数的memory就大约1.2G，最后再假设带宽是1G/s。那么当PS中只有两个node时，每次迭代大概需要1.2s。当PS中有9个worker一个server时，这个开销就至少是10.8s。

假设节点数为N，模型参数量为P，则其通信成本为：

说明随着worker的增加，通信的开销呈线性增长。

为了解决这个问题，百度研究院将HPC中的技术引入了进来，也就是Ring Allreduce。

Ring Allreduce

Ring Allreduce中每一个结点都有一个左结点和右结点，并且每一个结点只能从左节点recv，向右结点send。

Ring Allreduce包含两个步骤：先Scatter-Reduce后Allgather，最终目的是在每个结点上都得到参数梯度的平均。

Scatter Reduce 首先在每个结点上将模型参数梯度划分成N个一致的chunks，其中N为Ring上GPU的个数。这样所有结点上模型的参数梯度组合形成一个方阵。

同理，每个chunk都相应有自己的右节点和左节点，模型参数梯度划分成N个chunk会形成N个chunk ring。

然后从参数梯度方阵对角线上的chunk开始，每个chunk向其右chunk send一份自己的备份，同时右chunk需要recv这个备份并加和。之后经过N-1次迭代，矩阵的右-1对角线chunk和左下角chunk会得到各自所在的chunk ring上所有chunk之和。

All Gather 在Scatter Reduce的基础上，每个GPU上都有一个chunk是其所在chunk ring上的参数梯度之和。所以只需要将这份chunk在其所在的ring上传播N-1次，那么每个GPU上就得到了所有结点上参数梯度之和，这也是All Gather所做的工作。之后各结点对参数梯度求平均即得到整个batch的平均梯度。

假设节点数为N，模型参数量为P，则总的通信量为：

说明随着worker的增加，其通信成本是恒定的。

Horovod

对于一般场景，我们需要一个数据并行的高效通信的同步更新的深度学习分布式架构，Uber 开源的高效分布式训练通信框架horovod是个不错的选择。

Horovod 有如下主要特点[2]：

Horovod 可以实现接近 90% 的scaling efficiency
支持多个主流框架（ TensorFlow、Keras、PyTorch 和 MXNet），且分布式修改成本低。

架构搭建

horovod提供多种部署方式，这里讨论基于docker的部署方式。在horovod下使用多机多卡需要满足以下3个先决条件[3]：

不同机器可以访问相同的文件：nfs
不同机器使用相同的训练环境: Docker
不同机器可以ssh交互：ssh 免密登录

详情请参考我的另一篇文章：horovod多机多卡部署

Horovod 框架性能调优

当分布式架构部署成功并且demo可以顺利的跑起来，是否分布式训练就成功了呢，很显然不是，因为我们还没有验证过加速性能，而这也是我们的最终目的。那么如何理解分布式框架的并行性能？性能不达标如何调试？

Scaling Efficiency[4]

HPC中的一个常见任务是测量应用程序的scalability（可伸缩性）（也称为scaling efficiency伸缩效率）。这个度量表明当使用越来越多的并行处理元素（cpu/cores/processes/threads/etc）时，应用程序的效率有多高。

衡量给定应用程序的并行性能有两种基本方法，这取决于一种应用程序是否受cpu限制还是内存受限。它们分别称为Strong Scaling（强标度）和Weak Scaling（弱标度）。

Strong Scaling

在这种情况下，问题大小保持不变，但处理单元的数量增加了。

假设通过一个进程单元完成工作的时间是t1，使用N个单元完成同样工作量的时间花费是tN，则指标公式为：

Weak Scaling

在这种情况下，指定给某一个处理单元的问题量是一定的，另外的处理单元用于处理更多的问题（比如一个节点的内存容量无法容纳问题的情况）。

假设通过一个处理单元完成一份工作的时间是t1，用N个单元完成N份工作的时间是tN，则指标公式为：

综上，对于数据并行的分布式架构来说，有多少节点，就应该有大概多少倍的加速性能。比如单机跑完一个epoch需要10min，10个节点的分布式训练理论上需要1min（实际中会大于1min）

Horovod性能调优[5]

如果分布式架构的并行性能不满足上面提到的指标怎么办？可以参考一下方法：

1. 查看网络带宽

ethtool eth0

千兆带宽可以满足一般的分布式训练的需求，笔者遇到过百兆端口，分布式性能完全上不去。

2. 查看GPU显存占用及使用率

如果batchsize设置正常，各个GPU节点显存占用应该大体相同。如果datapipeline设置正常，GPU使用率应该在80-95%。data pipeline的设置，可查看官方代码。

3. 使用horovod timeline 性能分析

如果遇到GPU占用或使用率异常，可以通过horovod提供了的记录活动的时间轴工具，叫做horovod timeline分析，使用方法通过--timeline-filename开启并通过chrome://tracing查看。

horovod timeline

4. 使用mpirun代替horovodrun

horovodrun提供了一个基于openMPI封装的可以简便控制horovod脚本的方法。而在一些场景下我们需要更细粒度控制传递给openMPI的选项，horovod支持使用Open MPI的命令直接控制horovod训练脚本。

horovodrun -np 4 python train.py

等价于

mpirun -np 4 
    -bind-to none -map-by slot 
    -x NCCL_DEBUG=INFO -x LD_LIBRARY_PATH -x PATH 
    -mca pml ob1 -mca btl ^openib 
    python train.py

注：

MPI：英文全称是Message Passing Interface，信息传递接口，是独立于语言的通信协议（标准），是一个库。

openMPI：英文全称是open Message Passing Interface。openMPI是MPI的一种实现，一种库项目。

分布式训练参数调优

horovod搭建分布式需要对源代码进行相应的侵入式修改，以pytorch为例

1.初始化

# Horovod: initialize library.
hvd.init()

2.每个GPU分配一个进程

# Horovod: pin GPU to local rank.
if torch.cuda.is_available():
    torch.cuda.set_device(hvd.local_rank())

3.根据节点数线性缩放学习率

lr=arg.lr * hvd.size()

4.包装优化器

hvd.DistributedOptimizer()

5.把初始参数广播到各节点

hvd.broadcast_parameters(model.state_dict(), root_rank=0)
hvd.broadcast_optimizer_state(optimizer, root_rank=0)

6.定义分布式数据迭代器

train_sampler = torch.utils.data.distributed.DistributedSampler(trainset, num_replicas=hvd.size(), rank=hvd.rank())
dataloader = torch.utils.data.DataLoader(trainset, batch_size=arg.batch_size,num_workers=arg.workers, pin_memory=True, sampler=train_sampler)