【工程应用】深度学习推荐模型的上线部署

对于推荐模型的离线训练，无论是TensorFlow，PyTorch，还是传统一点的Spark MLlib都提供了比较成熟的离线并行训练环境。但推荐模型终究是要在线上环境进行inference的，如何将离线训练好的模型部署于线上的生产环境，进行线上实时的inference，其实一直是业界的一个难点。本篇文章是几种可行的推荐模型线上serving方法。

一、自研平台

无论是在数年前深度学习刚兴起的时代，还是TensorFlow，PyTorch已经大行其道的今天，自研机器学习训练与上线的平台仍然是很多大中型公司的重要选项。

为什么放着灵活且成熟的TensorFlow不用，而要从头到尾进行模型和平台自研呢？重要的原因是由于TensorFlow等通用平台为了灵活性和通用性支持大量冗余的功能，导致平台过重，难以修改和定制。而自研平台的好处是可以根据公司业务和需求进行定制化的实现，并兼顾模型serving的效率。

但自研平台的弊端也是显而易见的，由于实现模型的时间成本较高，自研一到两种模型是可行的，但往往无法做到数十种模型的实现、比较、和调优。而在模型结构层出不穷的今天，自研模型的迭代周期过长。因此自研平台和模型往往只在大公司采用，或者在已经确定模型结构的前提下，手动实现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等原生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？