這里是「王喆的機器學習筆記」的第二十三篇文章，這篇文章希望討論的問題是深度推薦模型的線上serving問題。

對于推薦模型的離線訓練，很多同學已經非常熟悉，無論是TensorFlow，PyTorch，還是傳統一點的Spark MLlib都提供了比較成熟的離線并行訓練環境。但推薦模型終究是要在線上環境進行inference的，如何將離線訓練好的模型部署于線上的生產環境，進行線上實時的inference，其實一直是業界的一個難點。本篇文章希望跟大家討論一下幾種可行的推薦模型線上serving方法。

一、自研平臺

無論是在五六年前深度學習剛興起的時代，還是TensorFlow，PyTorch已經大行其道的今天，自研機器學習訓練與上線的平臺仍然是很多大中型公司的重要選項。

為什么放著靈活且成熟的TensorFlow不用，而要從頭到尾進行模型和平臺自研呢？重要的原因是由于TensorFlow等通用平臺為了靈活性和通用性支持大量冗余的功能，導致平臺過重，難以修改和定制。而自研平臺的好處是可以根據公司業務和需求進行定制化的實現，并兼顧模型serving的效率。筆者在之前的工作中就曾經參與過FTRL和DNN的實現和線上serving平臺的開發。由于不依賴于任何第三方工具，線上serving過程可以根據生產環境進行實現，比如采用Java Server作為線上服務器，那么上線FTRL的過程就是從參數服務器或內存數據庫中得到模型參數，然后用Java實現模型inference的邏輯。

但自研平臺的弊端也是顯而易見的，由于實現模型的時間成本較高，自研一到兩種模型是可行的，但往往無法做到數十種模型的實現、比較、和調優。而在模型結構層出不窮的今天，自研模型的迭代周期過長。因此自研平臺和模型往往只在大公司采用，或者在已經確定模型結構的前提下，手動實現inference過程的時候采用。

二、預訓練embedding+輕量級模型

完全采用自研模型存在工作量大和靈活性差的問題，在各類復雜模型演化迅速的今天，自研模型的弊端更加明顯，那么有沒有能夠結合通用平臺的靈活性、功能的多樣性，和自研模型線上inference高效性的方法呢？答案是肯定的。

現在業界的很多公司其實采用了“復雜網絡離線訓練，生成embedding存入內存數據庫，線上實現LR或淺層NN等輕量級模型擬合優化目標”的上線方式。百度曾經成功應用的“雙塔”模型是非常典型的例子（如圖1）。

圖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 Spark模型利用PMML的上線過程

圖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等原生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}

這里僅需注意之前保存模型的路徑即可。

當然，要搭建一套完整的TensorFlow Serving服務并不是一件容易的事情，因為其中涉及到模型更新，整個docker container集群的維護和按需擴展等一系例工程問題；此外，TensorFlow Serving的性能問題也仍被業界詬病。但Tensorflow Serving的易用性和對復雜模型的支持仍使其是上線TensorFlow模型的第一選擇。

除了TensorFlow Serving之外，Amazon的Sagemaker，H2O.ai的H2O平臺都是類似的專業用于模型serving的服務。平臺的易用性和效率都有保證，但都需要與離線訓練平臺進行綁定，無法做到跨平臺的模型遷移部署。

總結

深度學習推薦模型的線上serving問題是非常復雜的工程問題，因為其與公司的線上服務器環境、硬件環境、離線訓練環境、數據庫/存儲系統都有非常緊密的聯系。正因為這樣，各家采取的方式也都各不相同。可以說在這個問題上，即使本文已經列出了4種主要的上線方法，但也無法囊括所有業界的推薦模型上線方式。甚至于在一個公司內部，針對不同的業務場景，模型的上線方式也都不盡相同。

因此，作為一名算法工程師，除了應對主流的模型部署方式有所了解之外，還應該針對公司客觀的工程環境進行綜合權衡后，給出最適合的解決方案。

---

按慣例提出兩個討論題，歡迎大家積極分享自己的見解：

1、在應用TensorFlow Serving的過程中，你有哪些實踐經驗？需要把所有流量都發給TensorFlow Serving進行inference嗎？有哪些減輕TensorFlow Serving負擔從而加快inference速度的經驗嗎？

2、作為一個工程性極強的工程問題，你是如何在模型serving這個問題上進行取舍的？結合多種serving方式，改進現有平臺，還是自研serving過程？

最后歡迎大家關注我的微信公眾號：王喆的機器學習筆記（wangzhenotes），跟蹤計算廣告、推薦系統等機器學習領域前沿。

想進一步交流的同學也可以通過公眾號加我的微信一同探討技術問題，謝謝。

---

本文亦收錄在我的新書「深度學習推薦系統」中，這本書系統性地整理、介紹了專欄中所有的重點內容，如果您曾在「王喆的機器學習筆記」中受益，歡迎訂閱，謝謝知友們的支持！

總結

以上是生活随笔為你收集整理的保存模型后无法训练_如何解决推荐系统工程难题——深度学习推荐模型线上serving？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。