論文題目：MLModelCI: An Automatic Cloud Platform for Efficient MLaaS
開原始碼：https://github.com/cap-ntu/ML-Model-CI
深度學習正在改變生活中的方方面面。手中的APP，快遞倉儲物流的優化，蛋白質的預測，遊戲的AI敵人等等，所謂「見面不談人工智慧，遍讀詩書也枉然」。
可是將深度學習模型部署為線上服務，並不是一件簡單的事情，君不見無數的報刊和博客都在吐槽人工智慧落地的困難。一方面由於線上服務的低延遲等需求，模型需要進行大量的優化，一方面各種各樣的硬體加速器，訓練軟體格式，讓每個工程師在對接已有服務的時候，都無比頭疼。將訓練出來新模型到部署成一個線上服務，可謂路漫漫其修遠兮。
我們將整體的流程抽象化為下面幾個節點，後面我們一一解釋。
圖1 模型部署流程抽象
總的來說，這是一個不斷優化，不斷探究性能極限，不斷進行測試，不斷去追求在自己的場景下，找到一個最優（速度最優or吞吐最優or花費最優，等等）解的過程。下面簡要介紹各個階段。
1. 模型及其各種運行組件管理
與傳統的軟體開發不同，模型的開發代碼（訓練）與上線代碼（推理），完全不一樣。要保證訓練出來的模型可用，用戶需要將模型以及對應的預處理，後處理，甚至運行環境全部進行考慮，然後重新編寫推理測試代碼，以求上線。
2. 模型優化，量化
為了降低服務的存儲消耗，縮短延遲，一般都會儘可能的將模型進行優化。大量的剪枝和量化paper，不再多提，始終是機器學習的熱門個方向。
3. 模型轉換 （重編譯）
而為了適配不同的硬體設施或者進一步的提高模型性能，可以優化模型的計算圖，從底層算子進行考慮，編譯轉換模型。這其中的佼佼者自然是TVM。其它的TensorRT和ONNX （配合ONNX Runtime）也非常優秀。最近OSDI 2020有一篇Microsoft的工作，驚為天人。
4. 模型服務系統綁定
當面對用戶時，考慮的便不再只是時延這些事情了，吞吐量，長尾延遲，AB test等等，都是非常現實的問題。為了提高模型的服務能力，便需要將其與服務系統綁定，使其在新的硬體集群上高效運行。tensorflow-serving是早期的入局者，clipper是學術圈的代表。如今的trion inference serving還有一些seldon，都越來越出色了。
5. 模型調試及上線
最後就是一系列的模型參數調試了，多大的batch size更合適？部署在哪個硬體更經濟？AB test怎麼控制，等等。全部搞定才能獲得一個高質量的服務。
小總結
可以看出來，完整跑完部署的整套流程是極其惱人的，在任何一步都可能出現問題。例如，訓練環境和生產環境打包不一致，模型不支持轉換導致長時間在debug，如何選擇出一套最優參數配置等等。
MLOps應運而生，越來越多的工作，投入到解決上述問題。
一點微小的工作
最近我們剛開源了一個很初期的的小工作，叫做MLModelCI，期望自動化這個流程。
整體來說，我們通過一個模型管家來讓用戶發布，管理模型，然後系統自動利用集群閒置資源，將模型進行優化，轉化和性能解析，最終自動將其綁定到服務系統上。用戶很快便能拿到可用的服務以及在不同情況下的各種性能信息（latency，cost等等），然後對應進行配置、部署和上線。