说到模型压缩，最简单粗暴的方法当然是减少卷积层数。在使用Tensorflow的API之前，我训练过一个SSD模型，检测效果不错，但耗时接近1s。为了提高检测速度我果断开始减少卷积层数，并做了不同层数的对比试验。结果和原始的VGG16骨干相比，要么检测效果相近，耗时也没少多少，要么耗时大减，但漏检率飙升。也就是在这个情况下，我转投了mobilenet网络。
所以这次面临模型压缩时， 我没有再尝试这个选项（当然也有配置文件不支持删减层数，要删就要去改slim里的源码这个原因。我一个前同事是中科院计算机博士，他的格言就是觉得源码不好就别调用，自己写；要调用就尽量避免改源码，因为你肯定没有源码写得好）。这样看下来，就只能在配置文件的范围内自由发挥了。
首先，附上Tensorflow object detection API中支持的各大模型的配置文件地址：
models/research/object_detection/samples/configs at master · tensorflow/models · GitHub
这里面关于mobilenet_ssd_v2的有好几个：
我使用的是最经典的基于COCO数据集训练的配置文件，也就是第一个。图里的最后一个也是基于COCO数据集的，不过是有量化的模型，这个文件我在后面也有用到。
打开配置文件，里面主要分成model、train和eval三块。在调用API训练自己的数据时，train和eval的数据当然是要修改的：
回到model部分，在feature_extractor那里，有一个depth_multiplier，这个参数作为一个因子与网络中各层的channel数相乘，换言之，depth_multiplier越小，网络中陆罩feature map的channel数越少，模型参数自然也就少了很多。depth_multiplier默认为1，在我的实验里改成了0.25，试就试一把大的。
之前depth_multiplier为1时， 我训练是加载了预训练模型的，模型地址：
models/detection_model_zoo.md at master · tensorflow/models · GitHub
从图中可以看出，mobilenet_v1的预训练模型中有一种0.75_depth的版本，这就是depth_multiplier取0.75时在COCO数据集上训练出来的模型。对于mobilenet_v2，只提供了非量化版和量化版（个人觉得应该0.25、0.5、0.75这几个常用档都提供一个，难道是官方不建议压缩太多吗。。。）
由于没有对应的预训练模型，所以可以选择加载或者不加载模型。
加载模型的话，开始训练后命令行会打印一大堆XXX is available in checkpoint, but has an incompatible shape with model variable. This variable will not be initialized from the checkpoint. 不过这并不影响训练，忽略就可以了。
不加载的话扒桐，就将配置文件里fine_tune_checkpoint的那两行注释掉。
进入到object detection目录，运行python object_detection/model_main.py --pipeline_config_path=xxxxxxx/ssd_mobilenet_v2_coco.config --model_dir=xxxxxxxx即可
PS：训练过程中是不会打印训练信息的，看命令行会以为电脑卡住了。。。直到eval才会打印出信息
PPS：可以通过TensorBoard来监听训练过程，判断训练是在正常进行还是电脑真的卡住了（这种情况可能是因为batch size和输入图片大小太大。默认是24和300*300，但也都可以改）
训练完成之后，还是在object detection目录下，运行python export_inference_graph.py，必要的参数分别是输入的ckpt的文件地址，输出的pb文件的文件夹以及配置文件地址。
在深度压缩至0.25倍之后， 我的pb模型大小仅为2.2M，效果卓群。当然网络的缩减会带来精度的损失，我的AR和AP分别降了2个点和3个点。
Tensorflow object detection API训练出的模型，讲道理从ckpt转成tflite只需要两步：
第一步，将ckpt转成pb文件，这次使用的是python export_tflite_ssd_graph.py， *** 作难度不大，会得到tflite_graph.pb和tflite_graph.pbtxt两个文件；
第二步，将pb转为tflite文件，我搜到的方法大都是使用bazel编译tensorflow/contirb/lite/toco下面的toca文件，但我反复尝试，报了多种错误，依旧没有成功。。。最后我在stackoverflow上搜到了一位小哥的回复，进入tensorflow/contrib/lite/python目录，运行python tflite_convert.py，参数设置为
--graph_def_file=XXX/tflite_graph.pb 上一步生成的pb文件地址
--output_file=XXX/xxx.tflite 输出的tflite文件地址
--input_arrays=normalized_input_image_tensor 输入输出的数组名称对于mobilenet ssd是固定的，不用改
--output_arrays='TFLite_Detection_PostProcess','TFLite_Detection_PostProcess:1','TFLite_Detection_PostProcess:2','TFLite_Detection_PostProcess:3'
--input_shape=1,XXX,XXX,3 输入的图片大小，需要与配置文件中一致
--allow_custom_ops
在将tflite模型放进手机之前，我在python里加载tflite模型测试了一次，流程类似加载pb模型
第一步，导入模型
第二步，获得输入和输出的tensor
第三步，读取输入图像，feed给输入tensor
可以采用PIL或cv2将图像读入，转为numpy数组，然后赋值给input_data
第四步，运行模型
第五步， 获得输出
参考输入tensor的表示方法，目标检测的输出有4个，具体的值可以通过output_details[0]['index']、output_details[1]['index']、output_details[2]['index']、output_details[3]['index']获得
这里有一个我踩到的坑，验证tflite模型时，我采用了和加载pb模型完全相同的图片预处理步骤，输出的结果完全不同。几番检查之后，发现问题出在模型转换时。运行python tflite_convert.py时，输入数组的名称为normalized_input_image_tensor，而我训练时采用的是未经normalized的数组。所以在模型转换时，tensorflow内置了对input进行normalized的步骤。因此在调用tflite模型时，同样需要在图像预处理中加入这一步。 nomlized的方法为除以128.0再减去1，保证输入的值在[-1,1)范围内。
简介
如何将机器学习(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
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）