美團深度學習系統的工程實踐

時間 2019-11-30

標籤深度學習系統工程實踐简体版

原文原文鏈接

背景

深度學習做爲AI時代的核心技術，已經被應用於多個場景。在系統設計層面，因爲其具備計算密集型的特性，因此與傳統的機器學習算法在工程實踐過程當中存在諸多的不一樣。本文將介紹美團平臺在應用深度學習技術的過程當中，相關係統設計的一些經驗。git

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

深度學習的計算量

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結束後，把舊的模型從內存中刪除（左下角），而後系統恢復到初始狀態。