愛奇藝基於CPU的深度學習推理服務優化實踐
本文內容節選自由msup主辦的第七屆TOP100summit，時任愛奇藝技術產品中心計算雲團隊助理研究員張磊分享的《基於CPU的深度學習推理部署優化實踐》實錄。
分享者張磊，就職於愛奇藝技術產品中心計算雲團隊擔任助理研究員，負責雲平台上深度學習應用的優化落地方案。加入愛奇藝之前在英特爾亞太研發有限公司擔任圖形軟體工程師，負責底層軟體設計和實現，對CPU，GPU 上應用性能分析和優化有豐富的經驗。
編者按：2018年11月30日-12月3日，第七屆全球軟體案例研究峰會在北京國家會議中心盛大開幕，現場解讀2018年「壹佰案例榜單」。本文為愛奇藝技術產品中心計算雲團隊助理研究員張磊分享的《愛奇藝基於CPU的深度學習推理服務優化實踐》案例實錄。
提綱：
- 案例來源
- 深度學習推理服務及優化
- 基於CPU深度學習推理服務優化實踐
- 案例結果及分析
- 啟示與展望
01案例來源
愛奇藝與AI
愛奇藝是一家以在線視頻播放為主要業務的互聯網公司，內部有很多視頻應用的場景。為了給用戶提供更好的視頻播放體驗，我們已將AI技術深入到業務線每一個領域，通過深度學習或AI的技術，讓視頻生產和播放過程更加智能與高效。
加速視頻生產過程
典型的視頻生產過程，包括視頻拆分，視頻編目，內容的審核，以及視頻的發布，這些環節以前都是由人工去完成的，不僅花費了大量的人力成本，而且容易產生錯誤。我們希望利用深度學習的技術把這些環節自動化，不僅可以提高效率，而且可以節約大量的人力成本。
對基礎架構的挑戰
(1) 框架與模型的挑戰
典型的深度學習框架模型有許多種，例如tensorflow，caffe，pytoch，keras等，不同的框架有不同的模型，它們的格式、部署方式都不太一致。我們需要能夠支持不同的框架和模型，這對基礎架構提出了挑戰。
(2) 計算資源的挑戰
GPU計算資源的緊缺，難以滿足內部業務的快速增長。除此之外，GPU資源的利用率也是一個很大的問題，有些服務存在特殊的性能需求指標，沒有辦法把所有的服務整合在一個服務節點上以提高GPU資源的利用率。對於這類服務，我們通過遷移到CPU上來實現GPU資源的釋放。
(3) 低延時高吞吐量的挑戰
視頻類業務的數據量非常大，對服務的吞吐量要求非常高，而且很多在線類的服務，通常具有低延時的要求。許多服務的端到端響應，通常需要控制在毫秒以內，留給深度學習服務做推理的時間非常少。
(4) 演算法的快速迭代
演算法迭代非常快。服務化的部署也需要應對演算法的快速的部署和迭代。
02深度學習推理服務及優化
深度學習在線推理服務
一個深度學習Serving系統，可以響應外部的client基於gRPC或HTTP的請求。上圖是一個典型的在線推理服務系統，這樣的Serving系統內部實現了模型的載入、模型的版本管理、以及對Batch或Stream管理，最後向外提供一個gRPC或HTTP介面。
分類與指標
(1) 分類
推理服務有很多應用場景，對於不同類型的深度學習的服務，需要優化的點是不一樣的，因此需要對推理服務進行分類。我們可以基於系統資源和服務質量進行分類，比如說從系統資源角度，可以分為是I/O密集的深度學習服務或計算密集型的深度學習服務。I/O密集型通常數據的特徵維度都非常大，數據集也非常大，對I/O的要求非常高；計算密集型是基於CNN的視頻類的演算法，對於計算資源的需求非常大。計算密集通常需要基於平台做計算資源的加速。從服務質量深度學習又可以分為延時敏感類和大吞吐量類，其中延時敏感類，一般是在線類的服務，是需要跟用戶有交互的一類服務；大吞吐量則是後台的批處理業務。
(2) 指標
上圖展示了三類常用指標，延時、吞吐量和精度。前兩類的指標是做服務化比較關心的指標，直接影響服務的質量。關於吞吐量通常用QPS來定義一個平均的和一個峰值的指標。精度是演算法工程師比較關心的指標。只有精度達到了一定要求的演算法，才可以部署上線。
性能優化
這是一個進行性能優化的瀑布流程，性能優化之前，首先需要對服務的性能指標有一個定義， 第二步進行服務性能的基準測試，在一個標準的系統環境下，對這個演算法以及它的整個服務做性能基準測試，檢測這個服務是不是能滿足線上業務的需求。
CPU上的優化
若測試結果無法滿足需求、我們會針對不同的性能瓶頸進行演算法級、應用級、系統級的優化。系統級主要是針對硬體平台上做的一些性能優化的方法，應用級是跟特定應用相關的分析以及優化的方法，演算法級是針對演算法的優化，例如模型的裁剪，模型的量化。
03基於CPU深度學習推理服務優化實踐
系統級優化
在CPU 上的系統級的優化目前採用兩種方案，一種是基於MKL-DNN的數學庫優化，另一種是基於廠商發布的深度學習的優化套件，我們的CPU主要是Intel CPU，所以使用了Open VINO。如圖，針對於三個典型網路，藍色部分是使用MKL-DNN做完優化，它比原生的框架通常會有一到三倍的性能提升，橘色的部分是基於Open VINO SDK的優化方式，它的優化幅度會比MKL-DNN多1倍左右。
MKL-DNN使用方法比較簡單的，可以使用開源的官方鏡像，或者是源。另一種方式是在編譯時，指定相應的編譯選項， MKL-DNN是基於原生框架的，所以不需要對模型做任何的轉換，訓練好的模型可以直接去使用，部署上線。
另一類優化方法是基於Open VINO的SDK方法，它的優化力度更深，它的實現通常需要模型轉換，在通過通用框架訓練得到一個原始模型後，通過SDK的模型轉換工具，轉化成中間格式model，得到這個中間模型之後，調用SDK的相應的API來封裝整個深度學習的服務，進而進行服務化的部署。
這種優化方式模型轉換會帶來一些副作用，例如有某些深度學習層的操作不支持，整個模型轉換就會失敗，沒有辦法得到一個中間模型進行模型的轉化和部署。
為了解決這類不支持的問題，我們針對模型轉化工具做了一些優化，包括操作層的替換，自定義操作的實現等。
使用以上兩種優化方式，有一些影響性能的因素。第一個是OpenMP的設置。 OpenMP有三個比較重要的設置，包括 KMP-BLOCKTIME，KMP-AFFINITY， OMP-NUM-THREADS。OMP-NUM-THREAS 參數決定了起多少路的線程來做同步的加速，BLOCKTIME決定線程要等待多久的時間進入到休眠的狀態，AFFINITY，會決定OMP的線程如何分布到不同的CPU核上去，並通過CPU核數的堆疊，做到性能的成倍的提升。
右圖列出了OMP在不同的設置下對性能的影響。我們發現只有THREADS與CPU的核數設置相等時，服務的吞吐量可以達到最大。
第二個是CPU核數與性能的關係， CPU在伺服器端通常都是多核的，我們對核數與性能做了一個測試，可以看到，CPU的核數對性能的影響跟Batchsize相關，當 batchsize較小時，提高 CPU 核數到一定程度，性能已無法保持線性增長；當batchsize 較大時，即使 CPU 核數提升到比較高，例如24核，推理性能還是會隨著CPU核數有一個線性的增長。
第三個影響性能的因素是CPU的型號，我們線上目前主要是兩代 CPU類型，一類是Boardwell，一類是skylake。Skylake相比 broadwell，相同核數，性能提升在 2 倍左右。我們可以在線上服務時區分不同CPU集群，在進行服務部署時，選擇不同的CPU集群來部署不同類型的服務。
第四個影響性能的因素是輸入數據格式的影響，優化後的深度學習框架，推薦的輸入數據格式化是NCHW，這種格式在進行數學運算時可以做更好的向量化的操作，對性能會有更大的幫助。
最後一個是NUMA的影響，伺服器端的CPU與 PC上有些差異，它一般是多個CPU，每個CPU有自己內部獨立的Memory以及cache和Bus，兩個socket之間通過dsm的網路進行交互，代價比在單一的CPU上進行通信的代價要大，對性能的影響會比較多。
應用級優化
這是一個視頻質量打分的例子，下面這張圖是通過性能分析工具抓取的，我們可以看到，有8路OMPworker threads在做深度學習的推理，但是只有一路的opencv thread在做解碼和預處理，一直處於busy的狀態，它沒有辦法給推理部分提供足夠的數據。針對這種情況，我們把預處理的部分做了一個並發。用多路進程來做解碼，針對不同的視頻幀，同時並發的做預處理，會把預處理的結果，加一個統一的緩存隊列組成一個Batch，統一丟給後端的深度學習推理演算法來做一個統一的推理。
這張圖展示了並發整個的解碼時間，預處理的時間縮短了1倍以上。每個應用，它的性能瓶頸是不一樣的，我們需要通過分析工具去定位到它的瓶頸，做一些並發的Pipeline設計，從而達到性能的提升。
演算法級優化
第三類優化是演算法級的優化，通常我們拿到模型之後，需要結合硬體平台優化一下Batchsize的選擇，另外就是通過量化的方法來進行優化。
我們測試了不同的Batchsize對整個服務性能的影響，如果選定一個特定的CPU的核數，隨著Batchsize的增加，服務的吞吐量會有一個提升的過程，但如果Batchsize繼續增大，會導致吞吐量的下降。
Batchsize的選取不僅對吞吐量有影響，對服務的延時也有很大的影響，越大的Batchsize，服務延時也會越大。所以對Batchsize選取通常要結合服務的需求，來選擇不同的Batchsize。
模型量化有兩個好處，一是減小模型的大小，通常一個量化模型的size會縮小三分之一到四分之一。二是現在處理器對於低精度的乘加運算有很多加速的指令。經過量化後我們可以很好地利用加速指令來做性能提升，量化的方法有兩類，一類是post-Training 的量化，另一類Training-aware的量化，post-Training是拿到訓練好的模型之後直接去做量化，跟整個訓練過程沒有關係；Training-aware會在訓練過程中對量化做一些優化和抵消，可以很大程度上去避免對精度的影響。
性能方面，不同框架量化的方法也是不一樣的，我們使用TF-lite網路模型，在CPU性能上可以做到2到5倍的提升。在不影響模型精度的情況下，Caffe內部對特定演算法，使用量化的8 bit整型模型，性能也會有1到3倍的提升。
深度服務雲平台方案
我們在公司內部實現了一個統一的深度學習平台，來支持異構計算、支持不同類型的深度學習框架。這是一個基於容器的推理和訓練一站式平台。
這是深度學習服務雲平台的框架圖，從下往上分為四層，最底下是基礎架構層，往上是資源的管理和調度層，然後是框架和服務層，最上面各種視頻業務。
基礎架構方面，我們有CPU、GPU、FPGA，同時會支持公有雲，以及不同的網路和存儲的支持。
系統調度是用Mesos來做統一的資源管理和調度。所有的任務都是基於容器的方式，通過Mesos調度到統一的計算資源上面去。 框架和服務層，我們會提供統一的訓練和推理的服務介面，方便直接使用。
我們提供兩類服務化的方式，第一類是業務部門根據自己的業務制定的應用系統，我們已經把VINO 的SDK封裝成一個標準的一個docker的形式，來提供給業務部門服務化的同學直接使用。第二類是Tensorflow Serving，它是谷歌發布的基於Tensorflow 的一個系統，我們把它做了容器化，並使用了MKL-DNN的加速，模型訓練完之後，也可以通過Tensorflow Serving直接去進行線上部署。
這部分是對於推理服務部署的一個性能測試的方法，基於LOCUST，可以在單機上實現對深度學習服務更好的並發的壓測。
04案例結果及分析
以上是進行CPU優化後的結果，四個應用，經過優化之後，推理服務性能在 CPU 上分別得到了 4到20倍的提升。
這是伺服器端部署的規模，已經有數十個演算法完成CPU上的優化落地，部署的規模也達到了上千核CPU，等效100多個GPU的資源節省。
05啟示與展望
優化過程的一些啟示：
服務性能需求的定義是優化的第一步。
方法棧工具集能幫助有效分析和定位服務性能瓶頸。系統級優化幫助最大化CPU集群算力。
應用級優化幫助服務進行端到端的優化。
演算法級優化針對特定演算法實現性能優化。
深度學習部署平台幫助服務部署的自動化和性能對比。
優化無止境，按需求優化。
未來我們還可以進一步優化的方向：
當前的優化主要是深度學習計算部分的優化，未來還可以進一步加速預處理部分，例如解碼及圖像處理；
集群的角度我們需要進一步優化調度演算法，避免深度學習部署過程中產生的計算資源碎片化；
第三個是服務的彈性擴縮容，能根據線上業務量自動增加或減少服務節點；
最後一個是更多的異構資源計算加速。
以上內容來自張磊老師的分享。
推薦閱讀：
