背景
深度學習作為AI時代的核心技術,已經被應用於多個場景。在系統設計層面,由於其具有計算密集型的特性,所以與傳統的機器學習演算法在工程實踐過程中存在諸多的不同。本文將介紹美團平臺在應用深度學習技術的過程中,相關係統設計的一些經驗。
本文將首先列舉部分深度學習演算法所需的計算量,然後再介紹為滿足這些計算量,目前業界比較常見的一些解決方案。最後,我們將介紹美團平臺在NLU和語音識別兩個領域中,設計相關係統的經驗。
深度學習的計算量
Model | Input Size | Param Size | Flops |
---|---|---|---|
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的特徵提取等領域的相關模組。
參考資料
作者簡介
劍鵬,美團點評演算法專家。2017年加入美團,目前作為語音識別團隊的聲學模型負責人,負責聲學模型相關的演算法和系統設計與開發。