兩屆黑客馬拉松冠軍：K8S深度學習平台實踐經驗分享

內容來源：2017年11月19日，餓了么資深後端工程師江駿在「11.19上海 | K8S Sail！系列技術沙龍」進行《餓了么Docker&K8S實踐經驗分享》演講分享。IT 大咖說（微信id：itdakashuo）作為獨家視頻合作方，經主辦方和講者審閱授權發布。

閱讀字數：2566 | 7分鐘閱讀

摘要

從TensorFlow這樣一個深度學習框架開始，到把它在實際項目中完整運作起來，這中間需要一套懂深度學習的雲平台。 此次演講將與大家分享團隊結合Kubernetes與TensorFlow搭建深度學習平台elearn的經驗與心路歷程，以及在深度學習如此火熱的今天，工程師應該如何藉助Cloud(Kubernetes)來將深度學習踏實落地。

嘉賓演講視頻及PPT回顧：http://t.cn/Rmf3FkK

深度學習平台的誤區

深度學習平台&跑任務平台

很多人都有這樣的疑問——深度學習平台是否就是一個跑任務的平台。其實對比以前通過虛擬機跑一個進程，現在通過K8S等技術來實現成本要低很多，所以目前來說啟進程已經不是深度學習關注的全部了。

大數據平台&深度學習平台

從總體來看深度學習和機器學習分為兩大類，一類是基於Apache系列，通過原有的Apache生態去做機器學習。另一類的深度學習，是基於TensorFlow、PyTorch、MXNet等的深度學習框架， 它跟Apache其實沒有怎麼大的關係，很多功能也是Apache無法實現的。

深度學習平台和大數據平台其實是不衝突的，耦合關係也並不是很強。它需要的是機器學習對數據的預處理部分，然後將處理好的數據通過Cloud的分散式存儲作為中間的媒介，接著提供給TensorFlow進行分散式的Tranining,最後平台進行模型的管理和上線的serving。從這張圖中我們就可以看到elearn的位置，以及它與大數據平台是怎樣相處的。

深度學習代碼開發VS通常代碼開發

演算法工程師在進行深度學習開發的時候其實和通常的代碼開發是不一樣的。

開發環境

先來看開發環境，通常的代碼開發既可以在虛擬機上進行也能在自己的機器上開發，而對於深度學習來說則需要一個即能看到真實的數據又能夠做代碼開發，同時具有強大運算能力的環境。

版本管理

目前不管是開發什麼樣的代碼，都需要通過版本管理工具進行管理，而現在深度學習領域在Model版本管理還是一片空白。

發布

通常的代碼有著各種的灰度發布的策略，深度學習的Model版本發布在這方面同樣也是空白。

Distributed Storage

深度學習的任務和通常的業務開發一個很大的不同就在於對分散式存儲有很強的依賴。深度學習有非常多的圖像、音頻的數據，這些數據是不可能向MySQL等資料庫中存儲的，同時這麼大量的數據也不方便去拷貝給每一個演算法工程師的。所以需要用到分散式存儲系統管理。

餓了么Titan+elearn

餓了么在這塊跟內部的大數據平台的海量存儲系統進行了打通，這個存儲系統就是Titan。Titan在sync好數據後，會自動向elearn註冊Datastore,數據最後仍以表名在elearn展示，用戶無需使用特定sdk。

GUP in container

在K8S中能做到對GPU資源的隔離，每一個GPU對於特定container是獨享的，不存在類似CPU的分時共享的狀況，但是目前在對GPU使用資源的上報還是不夠優秀。

Kubernetes中Deep Learning任務和普通任務的不同

Deep Learning和Kubernetes結合後首先面臨的一點就是前面講到的更加需要分散式存儲。另外你會發現Reatart Policy和Kubernetes Quota機制往往無法直接滿足需求。比如，Gang Scheduling 就需要自己去實現。最後就是任務本身的資源需求偏大。

Model management + Serving

用戶可以通過不停的提交任務來訓練眾多的模型，但是只有在選擇保存某一個Model版本之後，elearn才會保證該Model不會丟失。當存儲了多個版本後可以選擇兩種方式將Model放到線上進行服務。

一種就是通過TensorFlow或者elearn提供的服務將Model文件轉換成GRPC服務。這樣的話線上的業務就相當於有演算法工程師開發的微服務，且不需要去關心服務底層的信息，做到一個解耦，後續的Model版本升級就不用去再次發布業務代碼。

第二種就是傳統的將Model文件從分散式存儲系統Download下來，然後打進架包放到業務代碼中使用。不過這樣的缺陷在於每更新一次Moel都要重新發布業務。

Cloud Jupyter Notebook

如果是單獨登錄到機器上操作GPU，那麼就是一人佔用一台機器，GPU型任務變成了串列，需要排隊等資源，導致GPU卡的使用效率降低。並且任務缺乏管理，工程師的開發環境搭建也是非常的麻煩。

基於以上原因我們提供了Cloud Jupyter Notebook,它和分散式存儲以及GPU管理進行了整合。這樣就可以直接瀏覽到分散式存儲內的數據，開發的時候也能用到GPU的資源，包括環境的搭建同樣可以在這裡進行。

Hypertuning in elearn

在elearn拿到整合的數據之後會共享給多個訓練的任務去用，而Hypertuning任務會通過多種演算法、結合之前訓練的結果，選擇下一批參數，啟動眾多的任務，最後會挑取其中效果最好的進行線上的Serving。

Thinking of elearn with Kubernetes

elearn盡量發揮了Kubernetes的特色功能和編排能力，到目前為止讓elearn支持其他Cloud太容易了，只要寫interface夠通用，然後寫drive就可以了。Interface 的設計方面，如果只以容器維度，就會失去Kubrenetes本身的意義，所以elearn cloud interface的設計是面向功能的，面向一個個深度學習功能。這樣的定位，充分體現深度學習平台在 Kubernetes 之上的附加價值。

今天的分享就到這裡，喜歡本次分享請給我點贊~謝謝大家！有什麼問題可以在評論區討論。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！