Tensorflow Serving 初探

Posted 2023-03-16

参考技术A

简介

如何将机器学习(ML)模型部署上线至生产环境已成为经常性的热门话题。为此许多公司和框架提出了各种不同的解决方案。

为解决这一问题，谷歌发布了TensorFlow (TF) Serving，希望能解决ML模型部署到生产的一系列问题。

本文将给出一篇动手教程，上线部署一个预训练的卷积语义分割网络。文中会讲解如何用TF Serving部署和调用基于TensorFlow的深度CNN模型。另外，我会概述TF Serving的主要组件，并讨论其API及其工作机制。

本文基于我们在Daitan Group做的一些工作。

TensorFlow Serving Libraries — 概述

我们首先花点时间了解TF Serving是如何为ML模型提供全生命周期服务的。在这里将会从宏观层面讲一下TF Serving的主要组件，为TF Serving API做一个大致的介绍。如需进一步了解，请参考TF Serving文档：https://www.tensorflow.org/serving/

TensorFlow Serving可抽象为一些组件构成，每个组件实现了不同的API任务，其中最重要的是Servable, Loader, Source, 和 Manager，我们看一下组件之间是如何交互的。

简单来说，当TF Serving发现磁盘上的模型文件，该模型服务的生命周期就开始了。Source组件负责发现模型文件，找出需要加载的新模型。实际上，该组件监控文件系统，当发现一个新的模型版本，就为该模型创建一个Loader。

总之，Loader需要知道模型的相关信息，包括如何加载模型如何估算模型需要的资源，包括需要请求的RAM、GPU内存。Loader带一个指针，连接到磁盘上存储的模型，其中包含加载模型需要的相关元数据。不过记住，Loader现在还不允许加载模型。

Loader创建完成后，Source组件将其发送至Manager，作为一个待加载的版本。

Manager收到待加载模型版本，开始模型服务流程。此处有两种可能性，第一种情况是模型首次推送部署，Manager先确保模型需要的资源可用，一旦获取相应的资源，Manager赋予Loader权限去加载模型。

第二种情况是为已上线模型部署一个新版本。Manager会先查询Version Policy插件，决定加载新模型的流程如何进行。

具体来说，当加载新模型时，可选择保持 (1) 可用性 或 (2) 资源。如果选(1)可用性，意味着我们倾向于确保系统对客户请求总能相应。Manager让Loader实例化新的计算图和新的权重。

此时模型的两个版本被都被加载，也就是说Manager先加载新版本模型确保其可以安全服务后，然后再卸载原版本模型。

如果选(2)资源，如果我们希望节省资源不为新版本模型申请额外的资源，可选择保持资源。对于重量级模型也许挺有用，模型切换间会有极短的可用性缺口，不过可以换取内存不足。

最后，当用户请求模型的句柄，Manager返回句柄给Servable。

前面是概述，接下来开始进入一个真实的应用。下一节，将描述如何用TF Serving为一个Convolutional Neural Network (CNN)模型建立服务。

为TF Serving导出模型

将TensorFlow构建的模型用作服务，首先需要确保导出为正确的格式，可以采用TensorFlow提供的SavedModel类。

SavedModel是TensorFlow模型的一种通用序列化格式。如果你熟悉TF，你会使用 TensorFlow Saver to persist保存模型变量。

TensorFlow Saver提供模型checkpoint磁盘文件的保存/恢复。事实上SavedModel封装了TensorFlow Saver，对于模型服务是一种标准的导出方法。

SavedModel对象有一些不错的特性。

首先，一个SavedModel对象中可存储一个或更多的meta-graph，换句话说，这个特性允许我们为不同的任务订制不同的计算图。

例如模型训练完成后，大多数情况下使用推理模式时，计算图中不需要一些用于训练的特殊操作，包括优化器、学习率调度变量、额外的预处理操作等等。

另外，有时候可能需要将计算图简化作移动端部署。

在这些场景下SavedModel允许用户以不同的配置保存计算图。本例中文件中会有三个不同的计算图，分别标签为“training”, “inference”和“mobile”。这三个计算图共享同一组变量—— 意味着内存使用效率更高。

不久以前，在移动设备上部署TF模型，需要为模型指定输入输出张量的名称。这个需求逼着程序员在整张计算图中寻找相应的张量。这种情况下，如果之前在计算图中变量未正确命名，这个过程就变得很繁琐了。

SavedModel提供了SignatureDefs，简化了这一过程。SignatureDefs定义了一组TensorFlow支持的计算签名，便于在计算图中找到适合的输入输出张量。简单的说，使用这些计算签名，可以准确指定特定的输入输出节点。

TF Serving要求模型中包含一个或多个SignatureDefs，以使用内建服务API。

开始建立签名。我们需要为签名定义指定输入输出和方法名这些参数。这里输入输出表示一个从字符串到TensorInfo对象的映射(后面会详细介绍)，定义了计算图中默认接收和输出的张量。方法名 参数指向一个TF高级服务API。

目前有3个服务API: 分类、预测和回归。每个签名定义关联一个RPC API。分类SignatureDef用于分类RPC API，预测SignatureDef用于RPC API等等。

对于分类SignatureDef，需要一个输入张量(接收数据)以及可能的输出张量: 类别和/或得分。回归SignatureDef需要一个输入张量以及另一个输出张量。最后预测SignatureDef需要一个可变长度的输入输出张量。

此外，SavedModel支持在操作初始化依赖于外部文件的情况下存储资产。也包括在构建SavedModel之前清空设备。

我们看一下在实践中如何处理。

环境设置

开始前请先从github上cloneDeepLab-v3的实现。

DeepLab是谷歌最佳的语义分割卷积网络，该网络获取输入的图片，然后输出一张带有遮挡的图片，将特定对象与背景分割开。

该版本基于Pascal VOC分割数据集训练，可分割20类数据。如果你希望进一步了解语义分割和DeepLab-v3，可以看一下Diving into Deep Convolutional Semantic Segmentation Networks和Deeplab_V3。

构建服务的文件保存在 ./deeplab_v3/serving/ 目录里，其中有两个文件: deeplab_saved_model.py和 deeplab_client.ipynb。

在进行下一步之前，需先下载Deeplab-v3预训练模型。在GitHub库说明里有链接，点击checkpoints，下载16645/目录。

完成后，最终会有一个命名为 tboard_logs/ 目录，其中保存着下载的 16645/ 目录

然后我们建立2个Python虚拟环境，一个Python 3版本、一个Python 2版本环境，环境中安装相关的依赖包，依赖包信息可参考serving_requirements.txt 和 client_requirements.txt。

DeepLab-v3模型是在Python 3环境下开发的，但TensorFlow Serving Python API只发布了Python 2的版本，因此我们需要2个不同的Python环境。那么用Python 3环境导出并运行TF Serving。TF Serving API用于运行客户端代码，需要PIP安装(只支持Python 2环境)。

注如果从bazel运行Serving API，无需Python 2环境也可以运行。可参考TF Serving Installation。

完成这步后，开始真正的模型部署。

How to do it

TensorFlow提供了一个简单易用的高级工具类SavedModelBuilder，该类提供保存多组 meta graph、相关变量和资产等功能。

我们看一下如何导出Deep Segmentation CNN模型用作服务。

之前说过导出模型要用到SavedModelBuilder类，该类建立SavedModel的ProtoBuf文件，其中包含模型的变量和资产 (如果需要的话)。

剖析一下代码.

SavedModelBuilder以输入方式接收模型数据存储的目录。这里export_path 变量是由export_path_base变量和model_version变量连接而成。也就是说不同版本的模型将保存在export_path_base目录之下各版本对应的目录中。

例如在生产环境下已部署了一个基线版本的模型，现在需要升级至一个新版本。新版本的模型提高了准确率，需要及时向客户提供该版本。

为了导出同一个计算图的不同版本，需将FLAGS.model_version 设置为一个更大的整数。然后在export_path_base 目录下建一个新的目录(放新版本模型文件) 。

用SignatureDefs指定模型的输入输出张量。签名了模型导出的类型，签名提供了从字符(张量的逻辑名)到TensorInfo 对象的映射。意思是，与其引用实际的输入输出张量名称，客户可以通过签名定义的逻辑名来引用张量。

对于构建Semantic Segmentation CNN服务，需要调用build_signature_def() 函数建一个PredictSignature，此处需传入输入输出名对应的张量以及需要的API。

写一个SignatureDef需要指定:输入, 输出 和方法名。 注意模型期望获得3个值作为输入输入 —— 分别是图像和两个额外的维度张量(高度和宽度)。输出只需要定义一个结果——图像分割结果遮挡。

注意到字符串 ‘image’, ‘height’, ‘width’ 和 ‘segmentation_map’ 不是张量，而是指向实际张量 input_tensor, image_height_tensor 和 image_width_tensor的逻辑名。因此这些名称可以是任何全局唯一的名称。

此外SignatureDef中的映射与TensorInfo protobuf形式的对象关联，而不是实际的张量。可以使用以下功能函数: tf.saved_model.utils.build_tensor_info(tensor)，构建TensorInfo对象。

此后调用 add_meta_graph_and_variables() 函数，构建SavedModel的protobuf对象。执行save() 方法，将模型的快照保存到包含模型变量和资产的磁盘上。

接下来运行deeplab_saved_model.py 保存模型。

如果一切正常，就可以看到./serving/versions/1 目录了，此处 ‘1’ 代表当前模型版本，此目录包含一些子目录和文件，其结构如下:

saved_model.pb 或 saved_model.pbtxt。SavedModel的序列化文件，存储一个或多个计算图定义以及签名定义信息。

Variables，目录中包含序列化后的计算图对应的变量

现在可以启动模型服务了，执行以下命令:

model_base_path 指的是导出模型存储的位置，其中不需要指定版本，其版本控制由TF Serving控制。

生成客户端请求

客户端代码相当简单，可参考这个笔记本: deeplab_client.ipynb.

首先读取将要发送给服务器的图片，将其处理转换成适当的格式。

然后，建立一个gRPC stub，用以调用远程服务器上的方法。需要实例化prediction_service_pb2 模块中的beta_create_PredictionService_stub类。 这样stub就得到了远程调用所必须的逻辑，这一切就好像在本地执行一样。

此后，创建并设置请求对象。由于服务器实现TensorFlow预测API，需要解析预测请求。发送预测请求，首先需要从predict_pb2模块实例化一个PredictRequest类，还需要指定model_spec.name 以及 model_spec.signature_name 两个参数。这里name参数就是启动服务时候传入的 ‘model_name’ 参数，signature_name 指的是调用 add_meta_graph()时传入的 signature_def_map中的逻辑名。

然后，需要以预先定义的签名形式给服务器输入数据。记得么，在服务端之前定义的预测API，期望获得图像以及两个标量(图像的高度和宽度)。TensorFlow提供tf.make_tensor_proto()函数，用于装载输入数据到请求对象，该方法可从numpy或python对象处创建TensorProto对象。好了我们就用该方法构建请求对象，并填入图像和相关维度信息。

看起来，现在我们已经准备好，可以调用服务器了。执行stub中Predict()方法传入请求对象作为参数。

对于那些返回单一结果的请求，gRPC支持: 同步和异步两种调用。一般使用Predict()，如果希望请求被服务端处理时，本地仍然能处理一些工作，可以调用Predict.future() 。

好了，现在我们可以获取并查看结果

参考文章：https://zhuanlan.zhihu.com/p/60685482