背景介绍

当算法工程师在本地应用Amazon TensorFlow深度学习框架训练好模型后，会创立模型服务器供应用程序调用实现在线推理。因为部署自身存在肯定的复杂性，他们须要思考如何装置TensorFlow Serving相干的依赖，如何实现模型服务的高可用、申请负载平衡、A/B测试、主动伸缩机制等。Amazon SageMaker能够帮忙用户疾速创立多台模型服务器进行负载平衡，利用云上多可用区的形式实现高可用，并且在申请量变动时能够依据用户配置的策略进行主动扩大或膨胀。本文会介绍如何将本地训练好的TensorFlow模型部署到Amazon SageMaker来疾速、灵便地创立Amazon TensorFlow模型服务器。

TensorFlow Serving申请数据格式

在将模型部署到Amazon SageMaker之前，咱们首先要理解TensorFlow Serving的SignatureDefs，它标识了保留模型时所需的承受申请函数的输出与输入，不同SignatureDefs下的申请数据格式不同。TensorFlow Serving反对gRPC API与RESTful API两种形式进行申请，本文以RESTful API的形式为例。

[01] Classify与Regress API

Classify与Regress 的SignatureDefs别离反对分类与回归的TersorFlow Serving结构化调用形式。即当Serving的输出函数封装了tf.Example（一种灵便的音讯类型，示意{“string”: value}的映射，罕用来进行训练过程中的数据流式传输或解析feature_column中的特色列），须要调用该API进行推理。

参考以下代码，在保留模型时指定input_receiver_fn作为承受申请函数，其中定义了将feature_column解析为tf.Example音讯类型的过程，而后输出给模型进行推理。

Pythondef input_receiver_fn(features):    example_spec = tf.feature_column.make_parse_example_spec(features)    return tf.estimator.export.build_parsing_serving_input_receiver_fn(        example_spec, default_batch_size=5)model.export_savedmodel(export_dir, input_receiver_fn(features))

*左滑查看更多

在创立模型服务器后，若想对服务器进行申请失去推理后果，就须要将数据结构成Classify与Regress API所能承受的格局，如下所示：

{  // Optional: serving signature to use.  // If unspecifed default serving signature is used.  "signature_name": <string>,  // Optional: Common context shared by all examples.  // Features that appear here MUST NOT appear in examples (below).  "context": {    "<feature_name3>": <value>|<list>    "<feature_name4>": <value>|<list>  },  // List of Example objects  "examples": [    {      // Example 1      "<feature_name1>": <value>|<list>,      "<feature_name2>": <value>|<list>,      ...    },    {      // Example 2      "<feature_name1>": <value>|<list>,      "<feature_name2>": <value>|<list>,      ...    }    ...  ]}

*左滑查看更多

[02] Predict API

Predict SignatureDefs反对将tensor作为输出和输入，可通用于分类与回归的推理问题类型。参考以下代码，在input_receiver_fn函数中，读取到数据后结构成tensor，作为模型的输出。

def input_receiver_fn ():    feature_map = {}    for i in range(len(iris_data.CSV_COLUMN_NAMES) -1):        feature_map[iris_data.CSV_COLUMN_NAMES[i]] = tf.placeholder(            tf.float32,shape=[3],name='{}'.format(iris_data.CSV_COLUMN_NAMES[i]))    return tf.estimator.export.build_raw_serving_input_receiver_fn(feature_map)model.export_savedmodel(export_dir_base=export_dir,serving_input_receiver_fn=input_receiver_fn ())

*左滑查看更多

该状况下对模型服务器发动申请就须要应用Predict API，其所能承受的数据格式如下所示：

{  // (Optional) Serving signature to use.  // If unspecifed default serving signature is used.  "signature_name": <string>,  // Input Tensors in row ("instances") or columnar ("inputs") format.  // A request can have either of them but NOT both.  "instances": <value>|<(nested)list>|<list-of-objects>  "inputs": <value>|<(nested)list>|<object>}

*左滑查看更多

[03] 在Amazon SageMaker中向Serving发送申请

在Amazon SageMaker的SDK（https://sagemaker.readthedocs...）中，将上述三种不同的API封装成了三种办法，即创立好Predictor之后，根据上述不同SignatureDefs所能承受的数据格式结构申请，就能够抉择调用办法进行推理，Predict API、Classify与Regress API的调用办法如下所示：

将已训练好的Amazon TensorFlow模型部署到Amazon SageMaker

将模型压缩打包上传到Amazon S3之后，有两种形式能够实现模型的部署。

[01] 不提供inference.py脚本

若不须要对申请中的数据进行前解决和后处理，就不须要提供inference.py脚本，实例化TensorFlowModel对象时只须要指定模型在Amazon S3中的地位，以及相干的role，如下所示：

from sagemaker.tensorflow import TensorFlowModelmodel = TensorFlowModel(model_data='s3://mybucket/model.tar.gz', role='MySageMakerRole')predictor = model.deploy(initial_instance_count=1, instance_type='ml.c5.xlarge')

*左滑查看更多

部署实现之后，在推理时须要依据Serving所应用的SignatureDefs，将数据结构成SignatureDefs能够承受的格局，再调用相干的API进行推理。比方，若应用Classify API进行推理，则须要先将数据结构成1.1节中提到的申请格局，而后调用Predictor的classify办法，将推理数据作为参数传入，即可失去推理后果。

[02] 提供inference.py脚本

若须要对输出模型的数据进行前解决或对推理产生的后果进行后处理，则须要在实例化TensorFlowModel对象时提供inference.py脚本，通过entry_point参数指定，如下所示：

from sagemaker.tensorflow import TensorFlowModelmodel = Model(entry_point='inference.py',              model_data='s3://mybucket/model.tar.gz',              role='MySageMakerRole')

*左滑查看更多

在inference.py的代码中须要定义两个函数，别离是input_handler与output_handler。其中input_handler首先须要对传递进来的序列化对象进行解析。比方TensorFlow Serving Predictor默认的serializer为JSONSerializer，那么在input_handler中就须要对json序列化对象解析，之后就能够对数据进行前解决操作。相似地，在推理前须要把解决好的数据转化为SignatureDefs所能承受的格局。留神，结构SignatureDefs数据格式这个过程是在input_handler中定义的，这么做的益处就是用户无需在申请Serving前实现申请数据格式的定义，让前端传入的数据更加简洁灵便。

同样，在失去推理后果后，能够把数据后处理过程写在output_handler函数中，通过response_centent_type指定序列化对象，将后果返回给前端。

试验

本试验应用曾经训练好的iris模型，展现带有inference.py和不带inference.py在Amazon SageMaker上进行模型部署的过程，并调用Classify API进行推理。

实验所需环境

  • 应用cn-northwest-1区域；
  • 在Amazon SageMaker中创立一台Jupyter Notebook实例，创立过程可参考官网文档：https://docs.aws.amazon.com/s...
  • 下载实验所需的资料：git clone https://github.com/micxyj/aws...，进入文件夹，将tf-byom.zip文件，上传至Notebook环境。

试验步骤如下

  • 关上Notebook命令行，执行以下命令解压zip包；
  • cd SageMaker/
    unzip tf-byom.zip
  • 双击关上tf_byom.ipynb笔记本文件，逐渐执行notebook中的步骤；
  • 能够看到若不提供inference.py，在进行推理前须要结构好Classify SignatureDefs所能承受的数据格式，如下图key为examples的字典：

Amazon SageMaker SDK会把推理数据进行序列化传递给Serving，推理实现之后会将后果反序化回前端。

  • 在提供了inference.py的场景中，因为在input_handler函数中定义了加载列表生成Classify SignatureDefs数据格式，在调用classify进行推理时只须要传入列表数据即可，如下所示：

总结

本文介绍了TensorFlow Serving三种不同SignatureDefs的区别以及调用办法，展现了如何将本地训练的模型在Amazon SageMaker上进行部署与推理。通过应用Amazon SageMaker，用户能够疾速地将模型进行部署上线，无需进行简单的配置便可实现高可用的、可扩大的模型服务器架构。

参考资料

[1] https://www.tensorflow.org/tf...

[2] https://www.tensorflow.org/tf...

[3] https://sagemaker.readthedocs...

本篇作者


肖元君
亚马逊云科技解决方案架构师
负责基于亚马逊云科技云计算计划的架构征询和设计实现，同时致力于数据分析与AI的钻研与利用。


郭韧
亚马逊云科技人工智能和机器学习方向解决方案架构师
负责基于亚马逊云科技的机器学习计划架构征询和设计，致力于游戏、电商、互联网媒体等多个行业的机器学习计划施行和推广。在退出亚马逊云科技之前，从事数据智能化相干技术的开源及标准化工作，具备丰盛的设计与实践经验。