網易易盾深度學習模型工程化實踐

深度學習大熱以後受到大量關注，大部分剛接觸深度學習的同窗，注意力大都集中在如何調整參數/數據/網絡結構，如何達到預期的精度/召回率/準確率等。

然而，深度學習模型應用的整個流程裏面還有一個重要的環節，就是模型部署上線。一個模型只有部署上線了，這個模型的價值才能獲得體現。

因此咱們今天不討論如何訓練模型，咱們關注一下如何將訓練好的模型部署上線。

模型生命週期

模型部署上線，就是將模型封裝成一個在線服務，並分配相應的資源，將在線服務運行在服務器上，實時接收請求，返回predict結果。封裝在線服務的方式有不少，能夠選擇一些成熟的框架好比http / thrift / gRPC等，選擇一款適合本身項目的便可，咱們重點關注怎麼部署。

模型部署 v0.1 - 裸機部署

顧名思義，就是直接在物理服務器上安裝配置好相應的環境，直接將工程代碼/模型文件部署到物理服務器上運行，看起來好像很簡單直接，可是實際操做起來問題不少。實際服務器可能會有2塊GPU甚至4塊GPU，因此一臺服務器一般須要部署多個模型應用，而在同一臺服務器上部署多個應用碰到的最多見的問題，就是環境問題。
環境問題的複雜性表如今如下幾個方面：

• 依賴管理複雜：因爲各類緣由，線上服務器的操做系統版本可能會不一致，好比系統有CentOS6/七、Debian8/9，甚至內核版本也會有一些差別，依賴包管理工做變得很是複雜；
• 容易產生依賴衝突：各個模型應用依賴的包版本很容易產生衝突，好比一個應用依賴了opencv2，另外一個應用依賴了opencv3，在沒有很好的隔離的狀況下，會出現各類兼容性問題；
• 配置/部署效率低下：某一臺服務器部署了A應用，某一天A應用下線了，想要部署B應用，可能會面臨遺留環境衝突問題，甚至須要重裝系統從零開始。碰上線上服務須要緊急擴容的狀況，這種環境問題更是容易讓人手忙腳亂。

模型部署複雜的環境/依賴

模型部署v0.2 - 容器技術

爲了將開發運維從複雜的環境管理工做中解放出來，咱們引入了容器技術。容器是一種輕量級、可移植、自包含的軟件打包技術，使應用程序能夠在幾乎任何地方以相同的方式運行。
簡單的說，容器包含兩部分：

• 程序
• 程序依賴的環境

每一個程序都自帶依賴環境，而且相互隔離，這很好的解決了裸機部署帶來的各個應用之間的依賴衝突問題，對宿主機的環境依賴很小，真正實現了 「Build Once, Run Anywhere」 的口號。藉助nvidia官方提供的 nvidia-docker 組件，將nvidia設備映射到容器內部，咱們能夠很容易的實現快速的模型應用部署上線。

容器化環境隔離

但容器技術並無解決全部問題，其中一個問題就是資源管理和調度問題，因爲一臺服務器須要部署多個應用，每一個應用都須要分配1塊GPU，這就要求咱們手動維護好分配記錄，例如：

• 應用 A 部署在 Server0 服務器上，分配了第0塊GPU
• 應用B部署在Server0 / Server1服務器上，分配了第1塊GPU
• ...

這種管理工做在集羣規模小的時候能夠手動管理，可是在集羣規模大了以後就很混亂、很複雜了，並且也容易錯——尤爲是當今天易盾日均請求量達到十億量級以上的時候，僅靠手動管理已沒法想象。

更爲嚴峻的是，由於沒有對應用的資源作隔離，經過這種方式部署的應用，相互之間會產生資源競爭問題。例如一臺服務器上運行了 A / B / C 應用，此時A應用因爲程序Bug將CPU資源耗盡，此時在同一臺服務器上的B / C應用也會受到牽連影響。

模型部署v0.3 - Kubernetes

爲了解決資源調度問題，咱們引入了Kubernetes。Kubernetes 是一個開源系統，用於容器化應用的自動部署、擴縮和管理。在Kubernetes裏有一個「資源」的概念，好比CPU和內存都是資源類型，咱們能夠經過Kubernetes對運行的容器進行資源管理，例如：

​apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:

• name: nginx

image: nginx
resources:
requests:
memory: "64Mi"
cpu: "1"
limits:
memory: "128Mi"
cpu: "2"

咱們對運行的nginx容器申請了64M內存和1核CPU，而且限制這個容器最多隻能使用128M內存和2核CPU，若是nginx程序嘗試申請超過128M內存，就會被kubernetes系統kill掉從新拉起來，確保不會影響其餘應用。藉助nvidia官方提供的 k8s-device-plugin 插件，nvidia GPU也被抽象成一種資源類型，這時候咱們就能夠像申請CPU/內存同樣申請GPU資源。

apiVersion: v1
kind: Pod
metadata:
name: model-app
spec:
containers:

• name: model-app

image: model-app:v0.3
resources: requests:
cpu: 4
memory: "8Gi"
nvidia.com/gpu: "1"
limits:
cpu: 4
memory: "10Gi"
nvidia.com/gpu: "1"

上述示例中咱們爲 model-app這個應用申請了4核CPU、8G內存、1塊GPU，申請提交以後，Kubernetes會分配好對應的資源，並自動調度。開發運維人員的視角從「某臺服務部署了xx應用」轉換爲「這個kubenetes集羣的資源使用狀況」，這極大的簡化了運維管理工做。

Kubernetes自帶了dashboard組件，監控方案能夠用prometheus+grafana，基本的運維和監控管理均可以實現，但畢竟是開源版本，部分功能還不能知足咱們的運維開發需求，通過一番定製開發，咱們基於Kubernetes開發出了適合本身的集開發運維於一體的一站式管理平臺。

易盾某項目的資源彙總信息

總結
因爲易盾業務發展迅猛，網易安所有商業化易盾僅僅三年多一點的時間，網易易盾就已擁有超過26萬的開發者，服務客戶達數千家。這也使得這塊技術，從最先的裸機手動部署，到半自動的容器部署，再到全自動的kubernetes部署。

每一次進步都伴隨着效率的提高，解放了大量的開發運維人員精力，讓開發運維人員能夠投入更多的精力到值得關注的產品功能上。與此同時，也使得易盾的機器學習模型，從訓練完成到上線應用，僅須要數分鐘就能夠實現落地，從而及時幫助某些有緊急需求的客戶。

參考資料

https://www.docker.com/
https://github.com/NVIDIA/nvi...
rhttps://github.com/NVIDIA/k8s...
https://kubernetes.io/zh/

點擊免費體驗網易易盾安全服務。