Minerva: 高效靈活的並行深度學習引擎

         不同於cxxnet追求極致速度和易用性，Minerva則提供了一個高效靈活的平臺讓開發者快速實現一個高度定製化的深度神經網路。

         Minerva在系統設計上使用分層的設計原則，將“算的快”這一對於系統底層的需求和“好用”這一對於系統介面的需求隔離開來，如圖3所示。在介面上，我們提供類似numpy的使用者介面，力圖做到友好並且能充分利用Python和numpy社群已有的演算法庫。在底層上，我們採用資料流(Dataflow)計算引擎。其天然的並行效能夠高效地同時地利用多GPU進行計算。Minerva通過惰性求值(Lazy Evaluation)，將類numpy介面和資料流引擎結合起來，使得Minerva能夠既“好用”又“算得快”。

圖 3 Minerva的分層設計

惰性求值

          Minerva通過自己實現的ndarray型別來支援常用的矩陣和多維向量操作。在命名和引數格式上都儘量和numpy保持一致。Minerva同時支援讀取Caffe的配置檔案並進行完整的訓練。Minerva提供了兩個函式與numpy進行對接。from_numpy函式和to_numpy函式能夠在numpy的ndarray與Minerva的型別之間互相轉換。因此，將Minerva和numpy混合使用將變得非常方便。

資料流引擎和多GPU計算

         從Mapreduce到Spark到Naiad，資料流引擎一直是分散式系統領域研究的熱點。資料流引擎的特點是記錄任務和任務之間的依賴關係，然後根據依賴關係對任務進行排程。沒有依賴的任務則可以並行執行，因此資料流引擎具有天然的並行性。在Minerva中，我們利用資料流的思想將深度學習演算法分佈到多GPU上進行計算。每一個ndarray運算在Minerva中就是一個任務，Minerva自身的排程器會根據依賴關係進行執行。使用者可以指定每個任務在哪塊卡上計算。因此如果兩個任務之間沒有依賴並且被分配到不同GPU上，那這兩個任務將能夠並行執行。同時，由於資料流排程是完全非同步的，多卡間的資料通訊也可以和其他任務並行執行。由於這樣的設計，Minerva在多卡上能夠做到接近線性加速比。此外，利用深盟的Parameter Server，Minerva可以輕鬆將資料流拓展到多機上，從而實現多卡多機的分散式訓練。

圖4  Minerva和Caffe在單卡和多卡上訓練GoogLeNet的比較

表1 Minerva在不同網路模型和不同GPU數目上的訓練速度

資料流引擎和多GPU計算

          Minerva採用惰性求值的方式將類numpy介面和資料流引擎結合起來。每次使用者呼叫Minerva的ndarray運算，系統並不立即執行這一運算，而是將這一運算作為任務，非同步地交給底層資料流排程器進行排程。之後，使用者的執行緒將繼續進行執行，並不會阻塞。這一做法帶來了許多好處：

• 在資料規模較大的機器學習任務中，檔案I/O總是比較繁重的。而惰性求值使得使用者執行緒進行I/O的同時，系統底層能同時進行計算。
• 由於使用者執行緒非常輕量，因此能將更多的任務交給系統底層。其中相互沒有依賴的任務則能並行運算。
• 使用者能夠在介面上非常輕鬆地指定每個GPU上的計算任務。Minerva提供了set_device介面，其作用是在下一次set_device呼叫前的運算都將會在指定的GPU上進行執行。由於所有的運算都是惰性求值的，因此兩次set_device後的運算可以幾乎同時進行排程，從而達到多卡的並行。

Parameter Server: 一小時訓練600T資料

         深盟的元件引數伺服器（Parameter Server）對前述的應用提供分散式的系統支援。在大規模機器學習應用裡，訓練資料和模型引數均可大到單臺機器無法處理。引數伺服器的概念正是為解決此類問題而提出的。如圖5所示，引數以分散式形式儲存在一組服務節點中，訓練資料則被劃分到不同的計算節點上。這兩組節點之間資料通訊可歸納為傳送（push）和獲取（pull）兩種。例如，一個計算節點既可以把自己計算得到的結果傳送到所有服務節點上，也可以從服務節點上獲取新模型引數。在實際部署時，通常有多組計算節點執行不同的任務，甚至是更新同樣一組模型引數。

圖5 引數伺服器架構

          在技術上，引數伺服器主要解決如下兩個分散式系統的技術難點。

降低網路通訊開銷

         在分散式系統中，機器通過網路通訊來共同完成任務。但不論是按照延時還是按照頻寬，網路通訊速度都是本地記憶體讀寫的數十或數百分之一。解決網路通訊瓶頸是設計分散式系統的關鍵。

非同步執行

         在一般的機器學習演算法中，計算節點的每一輪迭代可以劃分成CPU繁忙和網路繁忙這兩個階段。前者通常是在計算梯度部分，後者則是在傳輸梯度資料和模型引數部分。序列執行這兩個階段將導致CPU和網路總有一個處於空閒狀態。我們可以通過非同步執行來提升資源利用率。例如，當前一輪迭代的CPU繁忙階段完成時，可直接開始進行下一輪的CPU繁忙階段，而不是等到前一輪的網路繁忙階段完成。這裡我們隱藏了網路通訊開銷，從而將CPU的使用率最大化。但由於沒有等待前一輪更新的模型被取回，會導致這個計算節點的模型引數與服務節點處最新的引數不一致，由此可能會影響演算法效率。

靈活的資料一致性模型

         資料不一致性需要考慮提高演算法效率和發揮系統性能之間的平衡。最好的平衡點取決於很多因素，例如CPU計算能力、網路頻寬和演算法的特性。我們發現很難有某個一致性模型能適合所有的機器學習問題。為此，引數伺服器提供了一個靈活的方式用於表達一致性模型。

        首先執行程式被劃分為多個任務。一個任務類似於一個遠端過程呼叫（Remote Procedure Call, RPC），可以是一個傳送或一個獲取，或者任意一個使用者定義的函式，例如一輪迭代。任務之間可以並行執行，也可以加入依賴關係的控制邏輯，來序列執行，以確保資料的一致性。所有這些任務和依賴關係組成一個有向無環圖，從而定義一個數據一致性模型，如圖6所示。

圖6 使用有向無環圖來定義資料一致性模型

          如圖7所示，我們可以在相鄰任務之間加入依賴關係的控制邏輯，得到順序一致性模型，或者不引入任何依賴關係的邏輯控制，得到最終一致性模型。在這兩個極端模型之間是受限延時模型。這裡一個任務可以和最近的數個任務並行執行，但必須等待超過最大延時的未完成任務的完成。我們通過使用最大允許的延時來控制機器在此之前的資料不一致性。

圖7 不同資料一致性下執行時間

 圖8展示了在廣告點選預測中（細節描述見後文），不同的一致性模型下得到同樣精度引數模型所花費的時間。當使用順序一致性模型時（0延時），一半的執行時間花費在等待上。當我們逐漸放鬆資料一致性要求，可以看到計算時間隨著最大允許的延時緩慢上升，這是由於資料一致性減慢了演算法的收斂速度，但由於能有效地隱藏網路通訊開銷，從而明顯降低了等待時間。在這個實驗裡，最佳平衡點是最大延時為8。

選擇性通訊

        任務之間的依賴關係可以控制任務間的資料一致性。而在一個任務內，我們可以通過自定義過濾器來細粒度地控制資料一致性。這是因為一個節點通常在一個任務內有數百或者更多對的關鍵字和值(key, value)需要通訊傳輸，過濾器對這些關鍵字和值進行選擇性的通訊。例如我們可以將較上次同步改變值小於某個特定閾值的關鍵字和值過濾掉。再如，我們設計了一個基於演算法最優條件的KKT過濾器，它可過濾掉對引數影響弱的梯度。我們在實際中使用了這個過濾器，可以過濾掉至少95%的梯度值，從而節約了大量頻寬。

緩衝與壓縮

         我們為引數伺服器設計了基於區段的傳送和獲取通訊介面，既能靈活地滿足機器學習演算法的通訊需求，又儘可能地進行批量通訊。在訓練過程中，通常是值發生變化，而關鍵字不變。因此可以讓傳送和接收雙方緩衝關鍵字，避免重複傳送。此外，考慮到演算法或者自定義過濾器的特性，這些通訊所傳輸的數值裡可能存在大量“0”，因此可以利用資料壓縮有效減少通訊量。

容災

        大規模機器學習任務通常需要大量機器且耗時長，執行過程中容易發生機器故障或被其他優先順序高的任務搶佔資源。為此，我們收集了一個數據中心中3個月內所有的機器學習任務。根據“機器數×用時”的值，我們將任務分成大中小三類，並發現小任務（100機器時）的平均失敗率是6.5%；中任務（1000機器時）的失敗率超過了13%；而對於大任務（1萬機器時），每4箇中至少有1個會執行失敗。因此機器學習系統必須具備容災功能。

        引數伺服器中服務節點和計算節點採用不同的容災策略。對於計算節點，可以採用重啟任務，丟棄失敗節點，或者其他與演算法相關的策略。而服務節點維護的是全域性引數，若資料丟失和下線會嚴重影響應用的執行，因此對其資料一致性和恢復時效性要求更高。

        引數伺服器中服務節點的容災採用的是一致性雜湊和鏈備份。服務節點在儲存模型引數時，通過一致性雜湊協議維護一段或者數段引數。這個協議用於確保當有服務節點發生變化時，只有維護相鄰引數段的服務節點會受到影響。每個服務節點維護的引數同時會在數個其他服務節點上備份。當一個服務節點收到來自計算節點的資料時，它會先將此資料備份到其備份節點上，然後再通知計算節點操作完成。中間的任何失敗都會導致這次傳送失敗，但不會造成資料的不一致。

        鏈備份適用於任何機器學習演算法，但會使網路通訊量成倍增長，從而可能形成效能瓶頸。對於某些演算法，我們可以採用先聚合再備份的策略來減少通訊。例如，在梯度下降演算法裡，每個服務節點先聚合來自所有計算節點的梯度，之後再更新模型引數，因此可以只備份聚合後的梯度而非來自每個計算節點的梯度。聚合可以有效減少備份所需通訊量，但聚合會使得通訊的延遲增加。不過這可以通過前面描述的非同步執行來有效地隱藏。

       在實現聚合鏈備份時，我們可以使用向量鍾(vector clock)來記錄收到了哪些節點的資料。向量鍾允許我們準確定位未完成的節點，從而對節點變更帶來的影響進行最小化。由於引數伺服器的通訊介面是基於區段傳送的，所有區段內的關鍵字可以共享同一個向量鍾來壓縮其儲存開銷。

圖8 三個系統在訓練得到同樣精度的模型時所各花費的時間

        引數伺服器不僅為深盟其他元件提供分散式支援，也可以直接在上面開發應用。例如，我們實現了一個分塊的Proximal Gradient演算法來解決稀疏的Logistic Regression，這是最常用的一個線性模型，被大量的使用在點選預測等分類問題中。

       為了測試演算法效能，我們採集了636TB真實廣告點選資料，其中含有1700億樣本和650億特徵，並使用1000臺機器共1.6萬核來進行訓練。我們使用兩個服務產品的私有系統（均基於引數伺服器架構）作為基線。圖8展示的是這3個系統為了達到同樣精度的模型所花費的時間。系統A使用了類梯度下降的演算法（L-BFGS），但由於使用連續一致性模型，有30%的時間花費在等待上。系統B則使用了分塊座標下降演算法，由於比系統A使用的演算法更加有效，因此用時比系統A少。但系統B也使用連續一致性模型，並且所需全域性同步次數要比系統A更多，所以系統B的等待時間增加到了50%以上。我們在引數伺服器實現了與系統B同樣的演算法，但將一致性模型放鬆至受限延時一致性模型並應用了KKT過濾。與系統B相比，引數伺服器需要略多的計算時間，但其等待時間大幅降低。由於網路開銷是這個演算法的主要瓶頸，放鬆的一致性模型使得引數伺服器的總體用時只是系統B的一半。