這里是「王喆的機器學習筆記」的第二十三篇文章，這篇文章希望討論的問題是深度推薦模型的線上serving問題踱蛀。
對于推薦模型的離線訓練窿给，很多同學已經(jīng)非常熟悉，無論是TensorFlow率拒，PyTorch崩泡，還是傳統(tǒng)一點的Spark MLlib都提供了比較成熟的離線并行訓練環(huán)境。但推薦模型終究是要在線上環(huán)境進行inference的猬膨，如何將離線訓練好的模型部署于線上的生產(chǎn)環(huán)境角撞，進行線上實時的inference，其實一直是業(yè)界的一個難點。本篇文章希望跟大家討論一下幾種可行的推薦模型線上serving方法谒所。
一热康、自研平臺
無論是在五六年前深度學習剛興起的時代，還是TensorFlow劣领，PyTorch已經(jīng)大行其道的今天姐军，自研機器學習訓練與上線的平臺仍然是很多大中型公司的重要選項。
為什么放著靈活且成熟的TensorFlow不用尖淘，而要從頭到尾進行模型和平臺自研呢奕锌？重要的原因是由于TensorFlow等通用平臺為了靈活性和通用性支持大量冗余的功能，導致平臺過重村生，難以修改和定制惊暴。而自研平臺的好處是可以根據(jù)公司業(yè)務和需求進行定制化的實現(xiàn)，并兼顧模型serving的效率趁桃。筆者在之前的工作中就曾經(jīng)參與過FTRL和DNN的實現(xiàn)和線上serving平臺的開發(fā)缴守。由于不依賴于任何第三方工具，線上serving過程可以根據(jù)生產(chǎn)環(huán)境進行實現(xiàn)镇辉，比如采用Java Server作為線上服務器屡穗，那么上線FTRL的過程就是從參數(shù)服務器或內(nèi)存數(shù)據(jù)庫中得到模型參數(shù)，然后用Java實現(xiàn)模型inference的邏輯忽肛。
但自研平臺的弊端也是顯而易見的村砂，由于實現(xiàn)模型的時間成本較高，自研一到兩種模型是可行的屹逛，但往往無法做到數(shù)十種模型的實現(xiàn)础废、比較、和調(diào)優(yōu)罕模。而在模型結構層出不窮的今天评腺，自研模型的迭代周期過長。因此自研平臺和模型往往只在大公司采用淑掌，或者在已經(jīng)確定模型結構的前提下蒿讥，手動實現(xiàn)inference過程的時候采用。
二抛腕、預訓練embedding+輕量級模型
完全采用自研模型存在工作量大和靈活性差的問題芋绸，在各類復雜模型演化迅速的今天，自研模型的弊端更加明顯担敌，那么有沒有能夠結合通用平臺的靈活性摔敛、功能的多樣性，和自研模型線上inference高效性的方法呢全封？答案是肯定的马昙。
現(xiàn)在業(yè)界的很多公司其實采用了“復雜網(wǎng)絡離線訓練桃犬，生成embedding存入內(nèi)存數(shù)據(jù)庫，線上實現(xiàn)LR或淺層NN等輕量級模型擬合優(yōu)化目標”的上線方式行楞。百度曾經(jīng)成功應用的“雙塔”模型是非常典型的例子（如圖1）攒暇。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖1 百度的“雙塔”模型
百度的雙塔模型分別用復雜網(wǎng)絡對“用戶特征”和“廣告特征”進行了embedding化，在最后的交叉層之前敢伸，用戶特征和廣告特征之間沒有任何交互扯饶，這就形成了兩個獨立的“塔”，因此稱為雙塔模型池颈。
在完成雙塔模型的訓練后尾序，可以把最終的用戶embedding和廣告embedding存入內(nèi)存數(shù)據(jù)庫。而在線上inference時躯砰，也不用復現(xiàn)復雜網(wǎng)絡每币，只需要實現(xiàn)最后一層的邏輯，在從內(nèi)存數(shù)據(jù)庫中取出用戶embedding和廣告embedding之后琢歇，通過簡單計算即可得到最終的預估結果兰怠。
同樣，在graph embedding技術已經(jīng)非常強大的今天李茫，利用embedding離線訓練的方法已經(jīng)可以融入大量user和item信息揭保。那么利用預訓練的embedding就可以大大降低線上預估模型的復雜度，從而使得手動實現(xiàn)深度學習網(wǎng)絡的inference邏輯成為可能魄宏。
三秸侣、PMML
Embedding+線上簡單模型的方法是實用卻高效的。但無論如何還是把模型進行了割裂宠互。不完全是End2End訓練+End2End部署這種最“完美”的形式味榛。有沒有能夠在離線訓練完模型之后，直接部署模型的方式呢予跌？本小節(jié)介紹一種脫離于平臺的通用的模型部署方式PMML搏色。
PMML的全稱是“預測模型標記語言”(Predictive Model Markup Language, PMML)。是一種通用的以XML的形式表示不同模型結構參數(shù)的標記語言券册。在模型上線的過程中频轿，PMML經(jīng)常作為中間媒介連接離線訓練平臺和線上預測平臺。
這里以Spark mllib模型的訓練和上線過程為例解釋PMML在整個機器學習模型訓練及上線流程中扮演的角色（如圖2）汁掠。
? ? ? ? ? ? ? ? ? ? 圖2 Spark模型利用PMML的上線過程
圖2中的例子使用了JPMML作為序列化和解析PMML文件的library略吨。JPMML項目分為Spark和Java Server兩部分。Spark部分的library完成Spark MLlib模型的序列化考阱，生成PMML文件并保存到線上服務器能夠觸達的數(shù)據(jù)庫或文件系統(tǒng)中；Java Server部分則完成PMML模型的解析鞠苟，并生成預估模型乞榨，完成和業(yè)務邏輯的整合秽之。
由于JPMML在Java Server部分只進行inference，不用考慮模型訓練吃既、分布式部署等一系列問題考榨，因此library比較輕，能夠高效的完成預估過程鹦倚。與JPMML相似的開源項目還有Mleap河质，同樣采用了PMML作為模型轉(zhuǎn)換和上線的媒介。
事實上震叙，JPMML和MLeap也具備sk-learn掀鹅，TensorFlow簡單模型的轉(zhuǎn)換和上線能力。但針對TensorFlow的復雜模型媒楼，PMML語言的表達能力是不夠的乐尊，因此上線TensorFlow模型就需要TensorFlow的原生支持——TensorFlow Serving。
四划址、TensorFlow Serving等原生serving平臺
TensorFlow Serving 是TensorFlow推出的原生的模型serving服務器扔嵌。本質(zhì)上講TensorFlow Serving的工作流程和PMML類的工具的流程是一致的。不同之處在于TensorFlow定義了自己的模型序列化標準夺颤。利用TensorFlow自帶的模型序列化函數(shù)可將訓練好的模型參數(shù)和結構保存至某文件路徑痢缎。
TensorFlow Serving最普遍也是最便捷的serving方式是使用Docker建立模型Serving API。在準備好Docker環(huán)境后世澜，僅需要pull image即可完成TensorFlow Serving環(huán)境的安裝和準備：
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}
這里僅需注意之前保存模型的路徑即可。
當然宜狐，要搭建一套完整的TensorFlow Serving服務并不是一件容易的事情势告，因為其中涉及到模型更新，整個docker container集群的維護和按需擴展等一系例工程問題抚恒；此外咱台，TensorFlow Serving的性能問題也仍被業(yè)界詬病。但Tensorflow Serving的易用性和對復雜模型的支持仍使其是上線TensorFlow模型的第一選擇俭驮。
除了TensorFlow Serving之外回溺，Amazon的Sagemaker，H2O.ai的H2O平臺都是類似的專業(yè)用于模型serving的服務混萝。平臺的易用性和效率都有保證遗遵，但都需要與離線訓練平臺進行綁定，無法做到跨平臺的模型遷移部署逸嘀。
總結
深度學習推薦模型的線上serving問題是非常復雜的工程問題车要，因為其與公司的線上服務器環(huán)境、硬件環(huán)境崭倘、離線訓練環(huán)境翼岁、數(shù)據(jù)庫/存儲系統(tǒng)都有非常緊密的聯(lián)系类垫。正因為這樣，各家采取的方式也都各不相同琅坡∠せ迹可以說在這個問題上，即使本文已經(jīng)列出了4種主要的上線方法榆俺，但也無法囊括所有業(yè)界的推薦模型上線方式售躁。甚至于在一個公司內(nèi)部，針對不同的業(yè)務場景茴晋，模型的上線方式也都不盡相同陪捷。
因此，作為一名算法工程師晃跺，除了應對主流的模型部署方式有所了解之外揩局，還應該針對公司客觀的工程環(huán)境進行綜合權衡后，給出最適合的解決方案掀虎。
按慣例提出兩個討論題凌盯，歡迎大家積極分享自己的見解：
1、在應用TensorFlow Serving的過程中烹玉，你有哪些實踐經(jīng)驗驰怎？需要把所有流量都發(fā)給TensorFlow Serving進行inference嗎？有哪些減輕TensorFlow Serving負擔從而加快inference速度的經(jīng)驗嗎二打？
2县忌、作為一個工程性極強的工程問題，你是如何在模型serving這個問題上進行取舍的继效？結合多種serving方式症杏，改進現(xiàn)有平臺，還是自研serving過程瑞信？
最后歡迎大家關注我的微信公眾號：王喆的機器學習筆記（wangzhenotes）厉颤，跟蹤計算廣告、推薦系統(tǒng)等機器學習領域前沿凡简。
想進一步交流的同學也可以通過公眾號加我的微信一同探討技術問題逼友，謝謝。
—END—
每周關注計算廣告秤涩、推薦系統(tǒng)和其他機器學習前沿文章帜乞，歡迎關注王喆的機器學習筆記
