關於商業部署機器學習,這有一篇詳盡指南

大資料文摘發表於2018-07-13

有關深度學習機器學習方面的文章層出不窮,涵蓋了資料收集,資料整理,網路/演算法選擇,訓練,驗證和評估等主題。

但是,當今資料科學麵臨的一個具有挑戰性的難題是在專案的商業化中部署訓練模型,對於任何的以消費者為中心的公司或想要使自己的解決方案擁有更多受眾的個人來說都是如此。

關於商業部署機器學習,這有一篇詳盡指南

大多數時候,為達到預期結果,精力和資源會花在訓練模型上。因此,分配額外的時間和精力來處理計算資源以構建適當的基礎設施,再進行模型複製,以便在不同的實際環境中大規模地實現類似的結果,將會是一項艱鉅的任務。

這是一個漫長的過程,打從你決定使用深度學習來部署模型開始,可以輕易地佔用掉數月的時間。

本文試圖從頭開始全面介紹整個部署過程。此外,也歡迎大家討論評論,以免遺漏了什麼。

組成部分

關於商業部署機器學習,這有一篇詳盡指南

工作流程圖

上述圖片描述了整個API的工作流程,讓我們把它分解一下,並理解每個元件。

客戶端:架構中的客戶端可以是任何裝置或第三方應用程式,由它們向搭建有預測模型的伺服器發出請求。打個比方,Facebook試圖在新上傳的圖片上標記你的臉。

負載均衡器:負載均衡器嘗試在群集中的多個伺服器或例項之間分配工作負載(請求)。負載均衡器的目標是透過避免任何單個資源上的過載來最小化響應時間並最大化輸出。在上圖中,負載均衡面向大眾開放,並將來自客戶端的所有請求分發到群集中的多個Ubuntu伺服器。

Nginx:Nginx是一個開源的Web伺服器,但也可以用作負載均衡器。Nginx以其高效能和小記憶體佔用而聞名。它可以在繁重的工作負載下透過開啟一個個新的工作程式來達到目的,每個程式都可以處理數千個連線。

在上述架構圖中,nginx是一個伺服器或例項的本地處理器,用於處理來自公共負載均衡器的所有請求。Nginx的一個替代伺服器是Apache HTTP Server。

Gunicorn:它是一個Python WSGI HTTP Server,從Ruby的Unicorn專案移植而來。這是一個pre-fork worker模型,意味著一個主檔案建立多個被稱作workers的複製檔案來處理請求。

由於Python不是多執行緒的,因此我們嘗試建立多個gunicorn worker,其作為獨立程式擁有自己的記憶體分配,以此補償處理請求的並行性。Gunicorn適用於各種Python Web框架,還有一個眾所周知的替代方案是uWSGI。

Flask:這是一個用Python編寫的微型web框架。它可以幫助我們開發API或響應請求的Web應用。Flask的其他替代方案是Django,Pyramid和web2py。Flask-RESTful提供了Flask的一個擴充套件,以支援快速構建REST API。

Keras:這是一個用Python編寫的開源神經網路庫。它能夠在TensorFlow,CNTK,Theano或MXNet上執行。Keras也有很多替代品:TensorFlow,Caffe2(Caffe),CNTK,PyTorch,MXNet,Chainer和Theano(已停止更新)。

雲平臺:如果有一個與上述所有元件都關聯的平臺,那麼它就是雲。雲是人工智慧研究激增的主要催化劑之一,無論是在計算機視覺自然語言處理機器學習機器翻譯機器人,還是在醫學成像方面,雲以合理的成本為更廣泛的受眾提供了計算資源。

雲Web服務的提供商很少,較為知名的是Amazon Web Services(AWS),Google Cloud和Microsoft Azure。

架構設定

到目前為止,您應該熟悉上一節中提到的元件。在下一節中,我們將從API的角度來理解架構設定,因為它也構成了Web應用程式的基礎。

注意:這個架構設定將基於Python。

開發設定

訓練模型:第一步是基於用例訓練模型,可以使用Keras,TensorFlow或PyTorch。確保你在虛擬環境中執行此操作,因為這有助於隔離多個Python環境,並且還能將所有必要的依賴打包到單獨的資料夾中。

構建API:如果模型足夠好以至於可以開始構建API的話,你可以使用Flask 或是Django來根據需求構建它們。理想情況下,你必須構建Restful API,因為它有助於分離客戶端和伺服器,提高可視性、可靠性和可擴充套件性,並且它是平臺無關的。你可以執行一次徹底的測試,以確保模型根據API的正確預測做出響應。

Web伺服器:現在不妨測試一下你構建好了的API的Web伺服器。如果你是使用Flask構建的,Gunicorn會是一個不錯的選擇。執行gunicorn web伺服器的命令如下:

gunicorn --workers 1--timeout 300 --bind 0.0.0.0:8000 api:app

- workers(INT): The number of worker processes for handling requests.
- timeout (INT): Workers silent for more than this many seconds arekilled and restarted.
- bind (ADDRESS): The socket to bind. [['127.0.0.1:8000']]
- api: The main Python file containing the Flask application.
- app: An instance of the Flask class in the main Python file 'api.py'.

負載平衡器:你可以透過配置nginx來處理gunicorn workers的測試請求,每個worker都有自己的DL模型API。請參閱給出的資源瞭解nginx和gunicorn的相關配置。

資源連結:

https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-gunicorn-and-nginx-on-ubuntu-16-04

負載/效能測試:嘗試使用Apache Jmeter,這是一個旨在載入測試和測量效能的開源應用程式。它也有助於理解nginx的負載分配。另一個選擇是Locust。

生產設定

雲平臺:選擇好雲服務後,要從標準Ubuntu映像(最好是最新的LTS版本)中設定一種機器或例項,而CPU的選擇實際上取決於深度學習模型和用例。機器可以執行後,就可以設定nginx和Python虛擬環境,安裝所有的依賴項並複製API。最後就可以嘗試使用模型執行API了(這需要一定的時間,因為這個是根據為gunicorn定義的工作組數以及要載入所有模型來決定的)。

自定義API映像:確保API執行正常後,可以快照例項,建立一個包含API和模型的自定義影像,它將保留應用程式的所有設定。

參考資料:

AWS:

https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/tkv-create-ami-from-instance.html

Google:

https://cloud.google.com/compute/docs/images/create-delete-deprecate-private-images

Azure:

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-custom-images

負載均衡器:接下來從雲服務建立負載均衡器,可以根據需要設定為公共的或私有的。

參考資料:

AWS:

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-getting-started.html

Google:

https://cloud.google.com/load-balancing/

Azure:

https://docs.microsoft.com/en-us/azure/load-balancer/quickstart-create-basic-load-balancer-portal

一組例項:使用先前建立的自定義API映像來啟動一組例項。

參考資料:

AWS:

https://aws.amazon.com/premiumsupport/knowledge-center/launch-instance-custom-ami/

Google:

https://cloud.google.com/compute/docs/instances/creating-instance-with-custom-machine-type

Azure:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/create-vm-generalized-managed

叢集的負載均衡器:現在可以將例項叢集連結到負載均衡器,這將確保負載均衡器在所有例項之間平均分配工作。

參考資料:

AWS:

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-deregister-register-instances.html

Google:

https://cloud.google.com/compute/docs/load-balancing/http/backend-service

Azure:

https://docs.microsoft.com/en-us/azure/load-balancer/quickstart-create-basic-load-balancer-portal

負載/效能測試:就像開發中的負載/效能測試一樣,類似的過程在生產環境也可以進行,但因為現在有數百萬個請求,所以需要去嘗試打破架構,來檢查它的穩定性和可靠性(並不一定總是有用的)。

總結:現在,如果一切正常,你將能用你的第一個可以投入生產級別的深度學習架構來處理數百萬個請求。

其他設定(附加元件)

除了通用設定外,還有其他一些事項需要注意,以確保我們搭建的環境能夠在長時間內自我維護。

自動縮放:這是雲服務中的一項功能,它可以根據收到的請求數量來幫助擴充套件應用程式中的例項。我們可以在請求激增時進行橫向擴充套件,在請求減少時進行iLocustn擴充套件。

應用程式更新:更新應用程式中的深度學習模型或其他功能都是需要時間的,但是如何能在不影響生產環境執行的前提下,更新所有例項,這是個問題。雲服務就提供了一種可以用多種形式來執行此任務的方式,而且具體的雲服務提供商可以提供具體的定製服務。

參考資料:

AWS:

https://aws.amazon.com/premiumsupport/knowledge-center/auto-scaling-group-rolling-updates/

Google:

https://cloud.google.com/compute/docs/instance-groups/updating-managed-instance-groups

Azure:

https://azure.microsoft.com/en-in/updates/auto-os-upgrades/

持續整合:它指的是軟體釋出過程的構建和單元測試階段。每個提交的修訂都會觸發自動構建和測試過程,用它可以將最新版本的模型部署到生產環境中。
關於商業部署機器學習,這有一篇詳盡指南

其他平臺

還有一些其他的系統,可以提供一種結構化的方式在生產環境中部署和設定模型,以下是幾個其他型別系統的介紹:

TensorFlow服務:它是一個開源平臺軟體庫,服務於機器學習模型。基於機器學習的推測作用,它的主要目標是接收訓練後的模型,並管控模型的整個生命週期,它為TensorFlow模型提供了直接可以使用的支援。

官網連結:

https://www.tensorflow.org/serving/  

關於商業部署機器學習,這有一篇詳盡指南

來源: googleblog

Docker:它是一種容器虛擬化技術,其行為與輕量級虛擬機器類似。它提供了一種簡潔的方法來把應用程式從其依賴項中隔離,以便應用程式在不同作業系統中都可以使用。我們可以在不用共享資源的情況下,在同一個例項上執行多個不同應用程式的docker映象。

資料連結:

https://github.com/floydhub/dl-docker

關於商業部署機器學習,這有一篇詳盡指南

來源:

https://codingpackets.com/virtualization/docker/

Michelangelo:它是Uber的機器學習平臺,其包括在Uber所分析的資料的數量及範圍內建設、部署和運營機器學習解決方案。

關於商業部署機器學習,這有一篇詳盡指南

來源:

https://eng.uber.com/michelangelo/

相關文章