Tensorflow Serving 初探
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Tensorflow Serving 初探相关的知识,希望对你有一定的参考价值。
参考技术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
以上是关于Tensorflow Serving 初探的主要内容,如果未能解决你的问题,请参考以下文章
Keras h5 到 2019 年服务于 Tensorflow?
如何使用 tensorflow-serving 发布自定义(非 tensorflow)模型?
tensorflow serving 中 No module named tensorflow_serving.apis,找不到predict_pb2问题