MLSys提前看：機器學習的分散式最佳化方法
wujiy發表於2020-02-21
隨著機器學習演算法和模型的不斷髮展，傳統的軟硬體平臺、部署環境等無法支撐機器學習的應用，這也成為了目前機器學習方法落地及大規模推廣應用的主要困難之一。目前，有關於 MLSys 的研究方向包括硬體領域、軟體領域和對機器學習演算法的改進三個方面，以 MLSys 2020 為例，本屆大會的議題包括：Distributed and parallel learning algorithms（5 篇論文）、Efficient model training（8 篇論文）、Efficient inference and model serving（8 篇論文）、Model/Data Quality and Privacy（4 篇論文）、ML programming models and abstractions & ML applied to systems（5 篇論文）以及 Quantization of deep neural networks（4 篇論文）。整個會議一共錄用 34 篇論文。在本篇提前看中，我們選擇了三篇文章進行詳細分析，以瞭解機器學習與系統（Machine Learning and Systems）領域最新的研究成果。其中，前兩篇文章屬於經典的機器學習分散式最佳化方法（通訊方式、記憶體分配方法），第三篇文章則是關於一種新的用於機器學習的具有高度系統性和裝置（統計、資料）異質性的分散式方法--聯邦學習。Blink: Fast and Generic Collectives for Distributed MLEfficient model training topichttps://arxiv.org/pdf/1910.04940.pdf隨著高質量資料庫、大規模資料集的不斷髮展，深度學習模型不斷改進，在影像分類、目標檢測、機器翻譯、語音處理等領域都獲得了很好的效果。與之同時，漫長的訓練時間卻成為了另一個讓人頭疼的問題。在處理一些影像分類任務時，在單個 GPU 中的訓練時間甚至需要幾天！基於多個 GPU 的資料並行訓練（Data-Parallel Training）的引入，大大緩解了大規模深度學習模型訓練耗時長的問題。在資料並行訓練中，每個 GPU 都有一個完整的模型引數副本，同時也會與其他參與訓練的 GPU 交換引數。這篇文章介紹的是 MLSys 領域中基於 GPU 的模型引數同步問題。跨 GPU 的引數同步在大規模訓練時產生了較大開銷，對於常見 ML 模型，通訊開銷可以從 50% 到 90% 不等。解決這一問題的手段主要有兩種：硬體手段—先進的多 GPU 伺服器，例如 NVIDIA』s DGX-1、DGX-2 等；軟體手段，利用了 Wait-free 反向傳播技術的現代通訊原語，例如 NVIDIA『s Collective Communications Library (NCCL)、百度的 Ring AllReduce 等。本文研究的是軟體手段，提出了 Blink—一個透過包裝生成樹動態生成最佳通訊原語的集合通訊庫。為了處理硬體生成中的拓撲異質性問題或叢集排程程式中的分配問題，Blink 能夠動態生成給定拓撲的最佳通訊原語。即使在 NVIDIA DGX-1 這樣的快速多 GPU 伺服器上執行資料並行訓練時，深度學習工作負載也會帶來很高的通訊開銷。更重要的是，作者發現，即使在像 DGX-1 這樣的高效能伺服器內，現有通訊原語如 NCCL 或 Horovod 也會放大通訊開銷，作者認為，這主要是因為它們無法處理拓撲異質性問題。DGX-1 中既有諸如 NVLink（20-25GB/s）的 GPU 點對點（P2P）互連，也有諸如 PCIe（8-12GB/s）的共享互連。PCIe 透過 PCIe 交換機層次結構將多個 GPU 相互連線到一臺計算機內，並連線到 CPU 和 I/O 裝置。NCCL、Horovod 等通訊原語基於環的模式（Ring-based Protocols）進行資料傳輸，然而，基於環的協議有結構上的限制：對於每個環，每個節點只能有一個輸入和一個輸出。基於環的模式將所有的通訊節點透過首尾連線形成一個單向環，資料在環上依次傳輸。假設有 3 個 GPU，GPU0 為資訊的傳送者，將資訊傳送給剩下的 GPU，基於環的通訊原語按照環的方式將資訊傳輸，即 GPU0-->GPU1-->GPU2。這種限制使得環無法適應由於排程程式分配而導致的不規則拓撲，如圖 1 所示。環的吞吐量受到頻寬最低的鏈路的限制，因此這些協議要麼將自己限制在高頻寬、同質鏈路上，要麼將吞吐量限制在環中頻寬最低的鏈路上。以 NCCL 為例，對於一臺機器內的多 GPU 通訊，NCCL 將優先使用 NVLink，而當在 NVLink 環中時，PCIe 將成為瓶頸。
圖 1. 群集上每個 8-GPU 伺服器中分配給 Cloud-X 上 40000 個多 GPU 作業的 GPU 數此外，這些限制還會導致連結使用不足，如圖 2 所示。
圖 2. DGX-1P 中 NCCL 與本文提出的 Blink 在 6-GPUs 上的廣播比較透過將 GPU 之間的連結建模為圖，前期的研究結果表明，包裝生成樹 (Packing Spanning Trees) 能夠生成從有選擇的根頂點到有向圖中的所有其他頂點的最大流。基於此研究，作者認為一對多協議（如使用根節點的生成樹進行廣播）是克服鏈路利用率不足的一個潛在有效選擇。當然，除了像廣播這樣只轉發資料的操作之外，還需要實現像 AllReduce 這樣的通訊原語，即可以被建模為在一個方向上減少並前進（面向根的方向），然後在另一個方向廣播。