Distributed Pytorch碰到的一个问题
这两天仔细看了下分布式pytorch的文档…起因是跑分布式pytorch的时候,在training的最后一个epoch挂掉了
首先在最后一个epoch/batch挂掉的原因,肯定不会是模型的问题,因为前面几个epoch很稳定。仔细排查了下,发现是有的worker还在训练,有的worker却结束退出了,所以还在训练的worker一直等不到其他worker的回应,所以出错了。
非常简单粗暴地,用DP+all_reduce,手动地把梯度聚合的方式从同步改成了异步,就好了。
但是仔细想了想,又觉得不太对,这不应该是会出错的地方。分布式的pytorch也算是比较成熟的方案了,分布式的环境也是一个成熟的应用了,要么是pytorch+分布式出错了,要么就是我的用法不对……
分布式机器学习的训练方式
- 模型并行
- 数据并行
顾名思义,模型并行,是模型拆分成多个模块,并行的去计算各自的梯度。用的是同一份数据,模型模型各自算各自的。数据并行则是把数据拆成多份,不同的机器上用同一份模型去计算不同的数据,每次计算之后,机器们就同步一下各自的梯度。
Distribution In Pytorch
在pytorch中,关于分布式计算,主要有三个大的组件
- Distributed Data Parallel(DDP)
- RPC-Based Distributed Training(RPC)
- Collective Communication(c10d)
一般常用的分布式训练都是选择数据并行,如果模型太大放到gpu里面装不下,就只能考虑模型并行了。所以在pytorch中,常用的分布式训练,都是使用DDP这一套就够了。RPC和c10d就逐渐底层,主要是为了满足一些定制化的需要,比如pytorch里面默认的分布式架构是ring型的,但是你想要用parameter server的训练框架,那就可以用后面两种组件搭配DDP去完成模型的分布式训练。可以看出来DDP确实是非常精妙的,可以参考pytorch这边发表的关于DDP的论文(PyTorch Distributed: Experiences on Accelerating Data Parallel Training)。我只用了最普适的DDP方法,所以接下来对DDP的使用方法做一些归纳。
DDP的使用方法
最开始,pytorch数据并行这块,用的模块是DataParallel(DP),这个方法有几个缺点:
- just 1 processing and multi-thread。进程线程和cpu的关系我有点忘了,但是反正就是效率会低一些(doge,and 回头补充)并且python原生存在的问题是python有CIL锁,所以很难真正意义上实现多processing。
- 并且在分布式的环境中,DP包裹的模型,需要手动地去调用all_reduce来更新模型参数。(顺便pytorch中有几种梯度聚合的方式,详情可以参见文档)
- 且由于DP的1 processing模式,在多GPU的时候,会存在各个GPU负载不均衡的问题。
出于这几点原因,pytorch做了相应的优化,于是有了DDP。DDP和DP有很大的不同:
- DDP是multi processing的,解决了python中CIL锁争抢的问题。并且做了许多优化处理,来解决之前DP中存在的负载不均衡的问题。
- DDP不需要手动去update 参数梯度了,DDP内部做了相应的广播处理(是同步更新参数的)
- DDP可以搭配RPC或者c10d的一些方法去完成更定制化的分布式训练
DDP的使用也比较简单:(详情参考:https://pytorch.org/docs/master/generated/torch.nn.parallel.DistributedDataParallel.html)
1. torch.distributed.init_process_group(backend='nccl', world_size=N, init_method='...')
#做init操作,初始化分布式的环境,告知一共有多少的机器并行训练,用的啥后端框架做消息传递
2. model = DistributedDataParallel(model, device_ids=[i], output_device=i)
#把模型裹上DDP
一些相关不相关的distrbutedxxx
一个是DistributedSampler。可以说这个是直接解决我最初的bug…导致部分worker提前training结束的原因就是每个机器上的batch数量不相同,我用的分布式环境是sagemaker,它能够支持一种方式就是把输入根据机器数量,切成近似均匀的N等份输入,这样每个机器就不需要下载全量的数据做训练了,只要拿到1/N总数的数据,可以大大减少机器负载和download时间。但是这直接导致的就是job failed…
于是认命还是用回DistributedSampler(DS)(可以说没有特殊情况的输入,都应该用DistributedSampler)它可以根据init时指定的world_size,对dataset做shuffle和split,保证每个机器上拿到的数据是不重复的,并且是均匀的,每个机器上的batch数量一定是一样的。
顺便提一嘴,如果在sagemaker已经等分过数据的情况下,再调用DS,就会让每个机器拿到的数据是 1/(N*N)的大小了…
还有一个是DistributedOptimizer(DO)。这个数据并行的时候实际应该用不到,DO在初始化的时候,是要指定reff格式的输入参数。直白一点就是你可以指定模型的某些个参数,然后变成reff格式,指定给DO,这样优化器就会只更新分布式环境里的这几个参数了。所以一般DO是在模型并行的时候需要用的,因为数据并行的时候,每个环境下是独立拥有优化器的。
最后鸣谢pytorch document,写得真好,不愧大佬:https://pytorch.org/tutorials/beginner/dist_overview.html