本文是王喆在 AI 前線 開設的原創技術專欄“深度學習 CTR 預估模型實踐”第七篇文章（以下“深度學習 CTR 預估模型實踐”簡稱“深度 CTR 模型”）。回顧王喆老師過往精彩文章：《推薦系統工程師必看！Embedding 技術在深度學習 CTR 模型中的應用》、《谷歌、阿里等 10 大深度學習 CTR 模型最全演化圖譜》、《重讀 Youtube 深度學習推薦系統論文，字字珠璣，驚爲神文》、《YouTube 深度學習推薦系統的十大工程問題》。
這篇文章希望討論的問題是深度學習CTR模型的線上serving問題。對於CTR模型的離線訓練，很多同學已經非常熟悉，無論是TensorFlow，PyTorch，還是傳統一點的Spark MLlib都提供了比較成熟的離線並行訓練環境。但CTR模型終究是要在線上環境使用的，如何將離線訓練好的模型部署於線上的生產環境，進行線上實時的inference，其實一直是業界的一個難點。本篇文章希望跟大家討論一下幾種可行的CTR模型線上serving方法。
自研平臺
無論是在五六年前深度學習剛興起的時代，還是TensorFlow，PyTorch已經大行其道的今天，自研機器學習訓練與上線的平臺仍然是很多大中型公司的重要選項。爲什麼放着靈活且成熟的TensorFlow不用，而要從頭到尾進行模型和平臺自研呢？重要的原因是由於TensorFlow等通用平臺爲了靈活性和通用性支持大量冗餘的功能，導致平臺過重，難以修改和定製。而自研平臺的好處是可以根據公司業務和需求進行定製化的實現，併兼顧模型serving的效率。筆者在之前的工作中就曾經參與過FTRL和DNN的實現和線上serving平臺的開發。由於不依賴於任何第三方工具，線上serving過程可以根據生產環境進行實現，比如採用Java Server作爲線上服務器，那麼上線FTRL的過程就是從參數服務器或內存數據庫中得到模型參數，然後用Java實現模型inference的邏輯。
但自研平臺的弊端也是顯而易見的，由於實現模型的時間成本較高，自研一到兩種模型是可行的，但往往無法做到數十種模型的實現、比較、和調優。而在模型結構層出不窮的今天，自研模型的迭代週期過長。因此自研平臺和模型往往只在大公司採用，或者在已經確定模型結構的前提下，手動實現inference過程的時候採用。
預訓練embedding+輕量級模型
完全採用自研模型存在工作量大和靈活性差的問題，在各類複雜模型演化迅速的今天，自研模型的弊端更加明顯，那麼有沒有能夠結合通用平臺的靈活性、功能的多樣性，和自研模型線上inference高效性的方法呢？答案是肯定的。
現在業界的很多公司其實採用了“複雜網絡離線訓練，生成embedding存入內存數據庫，線上實現LR或淺層NN等輕量級模型擬合優化目標”的上線方式。百度曾經成功應用的“雙塔”模型是非常典型的例子（如圖1）。
百度的雙塔模型分別用複雜網絡對“用戶特徵”和“廣告特徵”進行了embedding化，在最後的交叉層之前，用戶特徵和廣告特徵之間沒有任何交互，這就形成了兩個獨立的“塔”，因此稱爲雙塔模型。
在完成雙塔模型的訓練後，可以把最終的用戶embedding和廣告embedding存入內存數據庫。而在線上inference時，也不用復現複雜網絡，只需要實現最後一層的邏輯，在從內存數據庫中取出用戶embedding和廣告embedding之後，通過簡單計算即可得到最終的預估結果。
同樣，在graph embedding技術已經非常強大的今天，利用embedding離線訓練的方法已經可以融入大量user和item信息。那麼利用預訓練的embedding就可以大大降低線上預估模型的複雜度，從而使得手動實現深度學習網絡的inference邏輯成爲可能。
PMML
Embedding+線上簡單模型的方法是實用卻高效的。但無論如何還是把模型進行了割裂。不完全是End2End訓練+End2End部署這種最“完美”的形式。有沒有能夠在離線訓練完模型之後，直接部署模型的方式呢？本小節介紹一種脫離於平臺的通用的模型部署方式PMML。
PMML的全稱是“預測模型標記語言”（Predictive Model Markup Language, PMML）。是一種通用的以XML的形式表示不同模型結構參數的標記語言。在模型上線的過程中，PMML經常作爲中間媒介連接離線訓練平臺和線上預測平臺。
這裏以Spark MLlib模型的訓練和上線過程爲例解釋PMML在整個機器學習模型訓練及上線流程中扮演的角色（如圖2）。
圖2中的例子使用了JPMML作爲序列化和解析PMML文件的library。JPMML項目分爲Spark和Java Server兩部分。Spark部分的library完成Spark MLlib模型的序列化，生成PMML文件並保存到線上服務器能夠觸達的數據庫或文件系統中；Java Server部分則完成PMML模型的解析，並生成預估模型，完成和業務邏輯的整合。
由於JPMML在Java Server部分只進行inference，不用考慮模型訓練、分佈式部署等一系列問題，因此library比較輕，能夠高效的完成預估過程。與JPMML相似的開源項目還有Mleap，同樣採用了PMML作爲模型轉換和上線的媒介。
事實上，JPMML和MLeap也具備sk-learn，TensorFlow簡單模型的轉換和上線能力。但針對TensorFlow的複雜模型，PMML語言的表達能力是不夠的，因此上線TensorFlow模型就需要TensorFlow的原生支持——TensorFlow Serving。
TensorFlow Serving
TensorFlow Serving 是TensorFlow推出的原生的模型serving服務器。本質上講TensorFlow Serving的工作流程和PMML類的工具的流程是一致的。不同之處在於TensorFlow定義了自己的模型序列化標準。利用TensorFlow自帶的模型序列化函數可將訓練好的模型參數和結構保存至某文件路徑。
TensorFlow Serving最普遍也是最便捷的serving方式是使用Docker建立模型Serving API。在準備好Docker環境後，僅需要pull image即可完成TensorFlow Serving環境的安裝和準備：
docker pull tensorflow/serving
在啓動該docker container後，也僅需一行命令就可啓動模型的serving api：
tensorflow_model_server --port=8500 --rest_api_port=8501 \
--model_name=${MODEL_NAME} --model_base_path=${MODEL_BASE_PATH}/${MODEL_NAME}
這裏僅需注意之前保存模型的路徑即可。
當然，要搭建一套完整的FensorFlow Serving服務並不是一件容易的事情，因爲其中涉及到模型更新，整個Docker容器集羣的維護和按需擴展等一系列工程問題；此外，TensorFlow Serving的性能問題也仍被業界詬病。但Tensorflow Serving的易用性和對複雜模型的支持仍使其是上線TensorFlow模型的第一選擇。
總結
深度學習CTR模型的線上serving問題是非常複雜的工程問題，因爲其與公司的線上服務器環境、硬件環境、離線訓練環境、數據庫/存儲系統都有非常緊密的聯繫。正因爲這樣，各家採取的方式也都各不相同。可以說在這個問題上，即使本文已經列出了4種主要的上線方法，但也無法囊括所有業界的CTR模型上線方式。甚至於在一個公司內部，針對不同的業務場景，模型的上線方式也都不盡相同。
因此，作爲一名算法工程師，除了應對主流的模型部署方式有所瞭解之外，還應該針對公司客觀的工程環境進行綜合權衡後，給出最適合的解決方案。
《深度學習 CTR 預估模型實踐》專欄內容回顧：
作者介紹：
王喆，畢業於清華大學計算機系，現在美國最大的smartTV公司Roku任 senior machine learning engineer，曾任hulu senior research SDE，7年計算廣告、推薦系統領域業界經驗，相關專利3項，論文7篇，《機器學習實踐指南》、《百面機器學習》作者之一。知乎專欄/微信公衆號：王喆的機器學習筆記。