背景

深度學習作為AI時代的核心技術，已經被應用于多個場景。在系統設計層面，由于其具有計算密集型的特性，所以與傳統的機器學習算法在工程實踐過程中存在諸多的不同。本文將介紹美團平臺在應用深度學習技術的過程中，相關系統設計的一些經驗。

本文將首先列舉部分深度學習算法所需的計算量，然后再介紹為滿足這些計算量，目前業界比較常見的一些解決方案。最后，我們將介紹美團平臺在NLU和語音識別兩個領域中，設計相關系統的經驗。

深度學習的計算量

ModelInput SizeParam SizeFlops

AlexNet	227 x 227	233 MB	727 MFLOPs
CaffeNet	224 x 224	233 MB	724 MFLOPs
VGG-VD-16	224 x 224	528 MB	16 GFLOPs
VGG-VD-19	224 x 224	548 MB	20 GFLOPs
GoogleNet	224 x 224	51 MB	2 GFLOPs
ResNet-34	224 x 224	83 MB	4 GFLOPs
ResNet-152	224 x 224	230 MB	11 GFLOPs
SENet	224 x 224	440 MB	21 GFLOPs

數據來源

上表列舉了，ImageNet圖像識別中常見算法的模型大小以及單張圖片一次訓練（One Pass）所需要的計算量。

自2012年，Hinton的學生Alex Krizhevsky提出AlexNet，一舉摘下ILSVRC 2012的桂冠后，ILSVRC比賽冠軍的準確率越來越高。與此同時，其中使用到的深度學習算法也越來越復雜，所需要的計算量也越來越大。SENet與AlexNet相比，計算量多了近30倍。我們知道，ImageNet大概有120萬張圖片，以SENet為例，如果要完成100個epoch的完整訓練，將需要2.52 * 10^18的計算量。如此龐大的計算量，已經遠遠超出傳統的機器學習算法的范疇。更別說，Google在論文《Revisiting Unreasonable Effectiveness of Data in Deep Learning Era》中提及的、比ImageNet大300倍的數據集。

物理計算性能

面對如此龐大的計算量，那么，我們業界當前常用的計算單元的計算力是多少呢？

• CPU 物理核：一般浮點運算能力在10^10 FLOPS量級。一臺16 Cores的服務器，大致上有200 GFLOPS的運算能力。實際運行，CPU 大概能用到80%的性能，那就160 GFLOPS的運算能力。完成上述SENet運行，需要182天。
• NVIDIA GPGPU： 目前的V100，單精度浮點運算的峰值大概為14 TFLOPS， 實際運行中，我們假設能用到50%的峰值性能，那就是7 TFLOPS，需要4天。

根據以上數據結果可以看出：在深度學習領域，GPU訓練數據集所需要耗費的時間，遠遠少于CPU，這也是當前深度學習訓練都是采用GPU的重要原因。

業界的解決方案

從前面的計算可知，即使使用GPU來計算，訓練一次ImageNet 也需要4天的時間。但對于算法工程師做實驗、調參而言，這種耗時數天的等待是難以忍受的。為此，目前業界針對深度學習訓練的加速，提出了各種各樣的解決方案。

異構計算的并行方案

數據并行（Data Parallelism）

數據并行，即每個計算單元都保留一份完整的模型拷貝，分別訓練不同的數據，經過一個Iteration或若干個Iteration后，把各個計算單元的模型做一次同步。這是最常見的深度學習訓練方式，好處在于邏輯簡單、代碼實現方便。

模型并行（Model Parallelism）

模型并行，即各個計算單元存儲同一層模型數據的不同部分，訓練相同的數據。相對于數據并行，因為各個運算單元每訓練完一層神經網絡，就必須要同步一次，頻繁的同步通信導致系統不能充分地利用硬件的運算能力，所以更為少見。但是在一些業務場景下，Softmax層需要分類的類別可能會有很多，導致Softmax層太大，單個計算單元無法存儲，這個時候，需要把模型切割成若干部分，存儲在不同的運算單元。模型并行常見于NLU、推薦、金融等領域。

流式并行（Stream Parallelism）

流式并行，即每個計算單元都存儲不同層的模型數據，訓練相同的數據。如上圖所示，GPU1只負責第一層神經網絡的計算，GPU2只負責2~5層神經網絡的計算，GPU3只負責第6層的計算。流式并行的好處在于每個運算單元之間的通信和計算重疊（overlap），如果配置得當，可以非常充分地利用硬件資源。缺點在于，根據不同的模型，需要平衡好各個計算單元的計算量，如果配置不好，很容易形成“堰塞湖”。如上圖所示，很有可能出現GPU1 負責的運算量太少，而GPU2 負責的運算量太多，導致GPU1 和GPU2 之間堵塞住大量的Mini-batch，更常見于線上環境。

混合并行（Hybrid Parallelism）

混合并行，即上面提到的并行方式的混合。如對于一些圖像識別任務來說，可能前幾層使用數據并行，最后的Softmax層，使用模型并行。

異構計算的硬件解決方案

• 單機單卡：一個主機內安裝上一塊GPU運算卡。常見于個人計算機。
• 單機多卡：一個主機內安裝上多塊GPU運算卡。常見的有：1機4卡，1機8卡，甚至有1機10卡。一般公司都采取這種硬件方案。
• 多機多卡：多臺主機內安裝多塊GPU運算卡。常見于公司內部的計算集群，一般多機之間采取Infiniband 來實現網絡的快速通信。
• 定制化：即類似于Google的TPU解決方案。常見于“巨無霸”公司內部。

異構計算的通信解決方案

根據上面的硬件解決方案，我們以ResNet為例：模型的大小為230M，單張圖片運算量為11 GFLPOS，Mini-batch假設為128。可以計算出各個硬件模塊在深度學習訓練中的耗時比較：

• GPU：對于V100，假設有6 TFLOPS，一次Mini-batch 理論耗時：0.23s。
• PCI-E：常見PCI-E 3.0 * 16，速度為10 GB/s，傳輸一個模型的理論耗時為：0.023s。
• 網絡：假設為10 GB/s的高速網絡，傳輸一個模型的理論耗時：0.023s。
• Disk：普通的磁盤，我們假設200M/s的讀取速度，讀取一次Mini-batch所需要的圖片耗時：0.094s。

根據上面的數據結果，我們似乎可以得出一個結論：PCI-E和網絡的傳輸耗時，相對于GPU來說，整整少了一個數量級，所以網絡通信同步的時間可以忽略不計。然而問題并沒有那么簡單，上面例子中的耗時只是單個模型的耗時，但是對于8卡的集群來說，如果使用數據并行，每次同步就需要傳輸8份模型，這就導致數據傳輸的時間和GPU的計算時間“旗鼓相當”。這樣的話，GPU就得每訓練完一個Mini-batch，都得等候很久的一段時間（采取同步更新），這會浪費很多計算資源。因此，網絡通信也需要制定對應的解決方案。下面我們以Nvidia NCCL中單機多卡的通信解決方案為例介紹，而多機多卡的通信解決方案其實是類似的。

上圖是單機4卡機器，在硬件上，兩種不同的通信體系。左邊為普通的PCI-E通信，即4個GPU之間組成一個環狀。右邊為NVLink通信，即兩兩之間相互連接。

常見的通信類型如下圖所示：

對于深度學習訓練而言，關鍵的兩種通信類型為：Broadcast和Reduce。Broadcast用于Master分發最新的模型給各個GPU。Reduce 用于各個GPU計算完Mini-batch后，把模型更新值匯總到Master上。以Broadcast為例，最簡單的通信方式是Master往各個GPU上發送數據，這樣的耗時就是4次模型傳輸的時間，通信時間就會太長，一種簡單的優化方法如下圖所示：

即把所需要傳輸的數據分成若干塊，然后通過接力的方式逐個傳遞，每個GPU都把自己最新的一塊數據發送到下一個GPU卡上。這種傳輸方式能充分利用硬件層面的通信結構，使得需要的耗時大幅縮減。與此類似的，Reduce的通信優化也可以采取相同的方式進行提速。

美團的定制化深度學習系統

盡管目前在業界已經推出了很多著名的深度學習訓練平臺，通用的訓練平臺如TensorFlow、MxNet等等，還有領域專用的訓練平臺，如語音識別中的Kaldi，但是我們經過調研后，決定內部自主開發一套深度學習系統，理由如下：

• 通用的訓練平臺，缺乏了領域特色的功能。如語音識別中的特征提取模塊和算法。
• 通用的訓練平臺，通常是基于Data-flow Graph，來對計算圖中的每個operator進行建模，所以顆粒度很小，需要調度的單元多，導任務調度復雜。
• 領域特色的訓練平臺，如Kaldi，在神經網絡訓練的時候，性能不足。
• 線上業務存在很多特殊性，如果使用TensorFlow之類作為訓練平臺，不太適合線上業務的情景。

NLU線上系統

線上系統的業務特點

我們在設計NLU線上系統時，考慮了NLU業務的一些特性。發現其具備如下的一些特點： * 隨著業務和技術的變化，算法流程也經常發生變化。 * 算法流程是多個算法串聯組成的，不單純的只有深度學習算法。如分詞等算法就不是DL算法。 * 為了能夠快速響應一些緊急問題，需要經常對模型進行熱更新。 * 更重要的是，我們希望構建一個能以“數據驅動”的自動迭代閉環。

業務多變

NLU任務的算法流程是多層級的，并且業務經常發生變化。如下圖所示：

即隨著業務要求的變化，NLU系統一開始的算法流程，只需要把一個Query分為兩個類，但是到后面，極有可能會變成需要分為三個類別。

熱更新

根據業務需求，或者為了緊急處理一些特殊問題，NLU線上系統經常需要做出快速響應，熱更新算法模型。如最近的熱點詞“skr”，幾乎是一夜之間，突然火爆起來。如下圖所示的微博，如果不能正確理解“skr”的正確語義，可能就不能準確理解這條微博想要表達的意思。

為了避免影響用戶體驗，我們可能會對NLU系統，馬上進行熱更新，把新模型緊急進行上線。

數據驅動的自動迭代閉環

對于線上系統而言，構建如上圖所示的自動迭代閉環，能更好地利用業務數據來提升服務質量。

NLU線上系統的核心設計

算法流程的抽象

為了適應線上系統串聯、多變的算法流程，我們把線上系統的算法進行抽象，如下圖所示：

即每一個算法，都依賴于若干個槽位（Slot）和資源（Resource），一旦槽位和資源就位，就會觸發對應的算法執行。算法的執行先通過算法適配器，來適配槽位和資源中的數據，轉換成算子的輸入格式。然后算子執行算法本身，執行完算子后，再經過算法解析器。算法解析器主要用于解析算法執行的結果，觸發對應的槽位。如根據算法的結果，觸發Top 3的結果。

多個算法串聯起來，就構建成如下結果：

熱更新流程的設計

如上圖所示，我們把算法的熱更新流程設計如上。初試狀態為左上角，即多個Query使用同一份模型數據。當遇到模型更新的請求后，系統將會block住新的query（右上角狀態）。然后更新模型完后，新的query使用新的模型，舊query依然使用舊模型（右下角狀態）。最后，當使用舊模型的query結束后，把舊的模型從內存中刪除（左下角），然后系統恢復到初始狀態。

聲學模型訓練系統

因為TensorFlow等通用深度學習訓練平臺，缺乏了特征提取等業務相關的領域功能，而Kaldi的聲學模型訓練過程又太慢。所以美團開發了一個聲學模型訓練系統——Mimir，其具備如下特性：

• 使用比TensorFlow更粗顆粒度的建模單元，使得任務調度、優化更簡單方便易行。
• 使用數據并行的并行方案，單機多卡可達到近線性加速。（采取同步更新策略下，4卡加速比達到3.8）
• 移植了Kaldi的一些特有的訓練算法。
• 速度上為Kaldi的6~7倍。（800個小時的訓練數據，單機單卡的條件下，Kaldi需要6~7天， Mimir只需20個小時）
• 業務上，移植了Kaldi的特征提取等領域的相關模塊。

參考資料

• NCCL: ACCELERATED MULTI-GPU COLLECTIVE COMMUNICATIONS
• 【深度學習】老師木講架構：深度學習平臺技術演進

作者簡介

• 劍鵬，美團點評算法專家。2017年加入美團，目前作為語音識別團隊的聲學模型負責人，負責聲學模型相關的算法和系統設計與開發。

總結

以上是生活随笔為你收集整理的美团深度学习系统的工程实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。