深度學習分佈式模型

背景

隨着各大企業和研究機構在PyTorch、TensorFlow、Keras、MXNet等深度學習框架上面訓練模型愈來愈多，項目的數據和計算能力需求急劇增長。在大部分的狀況下，模型是能夠在單個或多個GPU平臺的服務器上運行的，但隨着數據集的增長和訓練時間的增加，有些訓練須要耗費數天甚至數週的時間，咱們拿COCO和Google最近Release出來的Open Image dataset v4來作比較，訓練一個resnet152的檢測模型，在COCO上大概須要40個小時，而在OIDV4上大概須要40天，這仍是在各類超參數正確的狀況下，若是加上調試的時間，可能一個模型調完就該過年了吧。單張CPU卡、或者單臺服務器上的多張GPU卡，已經遠遠不可以知足內部訓練任務的需求。所以，分佈式訓練的效率，即便用多臺服務器協同進行訓練，如今成爲了深度學習系統的核心競爭力。

1、分佈式訓練系統架構

分佈式訓練系統架構主要有兩種：

• Parameter Server Architecture（就是常見的PS架構，參數服務器）
• Ring-allreduce Architecture

   

1.1 Parameter Server架構

在Parameter Server架構（PS架構）中，集羣中的節點被分爲兩類：parameter server和worker。其中parameter server存放模型的參數，而worker負責計算參數的梯度。在每一個迭代過程，worker從parameter sever中得到參數，而後將計算的梯度返回給parameter server，parameter server聚合從worker傳回的梯度，而後更新參數，並將新的參數廣播給worker。見下圖的左邊部分。

1.2 Ring-allreduce架構

在Ring-allreduce架構中，各個設備都是worker，而且造成一個環，如上圖所示，沒有中心節點來聚合全部worker計算的梯度。在一個迭代過程，每一個worker完成本身的mini-batch訓練，計算出梯度，並將梯度傳遞給環中的下一個worker，同時它也接收從上一個worker的梯度。對於一個包含N個worker的環，各個worker須要收到其它N-1個worker的梯度後就能夠更新模型參數。其實這個過程須要兩個部分：scatter-reduce和allgather，百度開發了本身的allreduce框架，並將其用在了深度學習的分佈式訓練中。

相比PS架構，Ring-allreduce架構有以下優勢：

• 帶寬優化，由於集羣中每一個節點的帶寬都被充分利用。而PS架構，全部的worker計算節點都須要聚合給parameter server，這會形成一種通訊瓶頸。parameter server的帶寬瓶頸會影響整個系統性能，隨着worker數量的增長，其加速比會迅速的惡化。
• 此外，在深度學習訓練過程當中，計算梯度採用BP算法，其特色是後面層的梯度先被計算，而前面層的梯度慢於前面層，Ring-allreduce架構能夠充分利用這個特色，在前面層梯度計算的同時進行後面層梯度的傳遞，從而進一步減小訓練時間。在百度的實驗中，他們發現訓練速度基本上線性正比於GPUs數目（worker數）。

2、通用機器學習框架對分佈式模型的支持

2.1 Tensorflow原生PS架構

經過TensorFlow原生的PS-Worker架構能夠採用分佈式訓練進而提高咱們的訓練效果，可是實際應用起來並不輕鬆：

• 概念多，學習曲線陡峭：tensorflow的集羣採用的是parameter server架構，所以引入了比較多複雜概念
• 修改的代碼量大：若是想把單機單卡的模型，移植到多機多卡，涉及的代碼量是以天記的，慢的話甚至須要一週。
• 須要多臺機子跑不一樣的腳本：tensorflow集羣是採用parameter server架構的，要想跑多機多卡的集羣，每一個機子都要啓動一個client，即跑一個腳本，來啓動訓練，100個機子，人就要崩潰了。
• ps和worker的比例很差選取：tensorflow集羣要將服務器分爲ps和worker兩種job類型，ps設置多少性能最近並無肯定的計算公式。
• 性能損失較大：tensorflow的集羣性能並很差，當超過必定規模時，性能甚至會掉到理想性能的一半如下。

2.2 Pytorch分佈式簡介

PyTorch用1.0穩定版本開始，torch.distributed軟件包和torch.nn.parallel.DistributedDataParallel模塊由全新的、從新設計的分佈式庫提供支持。 新的庫的主要亮點有：

• 新的 torch.distributed 是性能驅動的，而且對全部後端 (Gloo，NCCL 和 MPI) 徹底異步操做
• 顯着的分佈式數據並行性能改進，尤爲適用於網絡較慢的主機，如基於以太網的主機
• 爲torch.distributed package中的全部分佈式集合操做添加異步支持
• 在Gloo後端添加如下CPU操做：send，recv，reduce，all_gather，gather，scatter
• 在NCCL後端添加barrier操做
• 爲NCCL後端添加new_group支持

1.0的多機多卡的計算模型並無採用主流的Parameter Server結構，而是直接用了Uber Horovod的形式，也是百度開源的RingAllReduce算法。

2.3 分佈式Horovod介紹

Horovod 是一套支持TensorFlow, Keras, PyTorch, and Apache MXNet 的分佈式訓練框架，由 Uber 構建並開源，Horovod 的主要主要有兩個優勢：

• 採用Ring-Allreduce算法，提升分佈式設備的效率；
• 代碼改動少，可以簡化分佈式深度學習項目的啓動與運行。

Horovod 是一個兼容主流計算框架的分佈式機器學習訓練框架，主要基於的算法是 AllReduce。 使用 horovod 有必定的侵入性，代碼須要必定的修改才能變成適配分佈式訓練，可是有一個好處就是適配的成本不高，而且 horovod 提供的各類框架的支持可讓 horovod 比較好的在各個框架的基礎上使用，他支持 tensorflow/keras/mxnet/pytorch，MPI 的實現也有不少，好比 OpenMPI 還有 Nvidia 的 NCCL，還有 facebook 的 gloo，他們都實現了一種並行計算的通訊和計算方式。並且 horovod 的自己的實現也很簡單。

 

參考文獻：
https://eng.uber.com/horovod/
https://www.aiuai.cn/aifarm740.html
https://zhuanlan.zhihu.com/p/40578792
https://ggaaooppeenngg.github.io/zh-CN/2019/08/30/horovod-實現分析/
https://blog.csdn.net/zwqjoy/article/details/89552432
https://www.jiqizhixin.com/articles/2019-04-11-21
https://zhuanlan.zhihu.com/p/50116885
https://zhuanlan.zhihu.com/p/70603273
http://www.javashuo.com/article/p-krardcgo-go.html
https://zhpmatrix.github.io/2019/07/18/speed-up-pytorch/
https://cloud.tencent.com/developer/article/1117910
https://www.infoq.cn/article/J-EckTKHH9lNYdc6QacH