共计 5462 个字符，预计需要花费 14 分钟才能阅读完成。
背景介绍
当算法工程师在本地应用 TensorFlow 深度学习框架训练好模型后，会创立模型服务器供应用程序调用实现在线推理。因为部署自身存在肯定的复杂性，他们须要思考如何装置 TensorFlow Serving 相干的依赖，如何实现模型服务的高可用、申请负载平衡、A/ B 测试、主动伸缩机制等。Amazon SageMaker 能够帮忙用户疾速创立多台模型服务器进行负载平衡，利用云上多可用区的形式实现高可用，并且在申请量变动时能够依据用户配置的策略进行主动扩大或膨胀。本文会介绍如何将本地训练好的 TensorFlow 模型部署到 Amazon SageMaker 来疾速、灵便地创立 TensorFlow 模型服务器。
1. TensorFlow Serving 申请数据格式
在将模型部署到 Amazon SageMaker 之前，咱们首先要理解 TensorFlow Serving 的SignatureDefs，它标识了保留模型时所需的承受申请函数的输出与输入，不同 SignatureDefs 下的申请数据格式不同。TensorFlow Serving 反对 gRPC API 与 RESTful API 两种形式进行申请，本文以 RESTful API 的形式为例。
- SignatureDefs：
https://www.tensorflow.org/tf…
1.1 Classify 与 Regress API
Classify 与 Regress 的 SignatureDefs 别离反对分类与回归的 TersorFlow Serving 结构化调用形式。即当 Serving 的输出函数封装了 tf.Example（一种灵便的音讯类型，示意 {“string”: value} 的映射，罕用来进行训练过程中的数据流式传输或解析 feature_column 中的特色列），须要调用该 API 进行推理。
参考以下代码，在保留模型时指定 input_receiver_fn 作为承受申请函数，其中定义了将 feature_column 解析为 tf.Example 音讯类型的过程，而后输出给模型进行推理。
def 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>,
...
}
...
]
}1.2 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>
}左右滑动查看更多
1.3 在 Amazon SageMaker 中向 Serving 发送申请
在 Amazon SageMaker 的 SDK（https://sagemaker.readthedocs…）中，将上述三种不同的 API 封装成了三种办法，即创立好 Predictor 之后，根据上述不同 SignatureDefs 所能承受的数据格式结构申请，就能够抉择调用办法进行推理，Predict API、Classify 与 Regress API 的调用办法如下所示：
2. 将已训练好的 TensorFlow 模型部署到 Amazon SageMaker
将模型压缩打包上传到 Amazon S3 之后，有两种形式能够实现模型的部署。
2.1 办法一：不提供 inference.py 脚本
若不须要对申请中的数据进行前解决和后处理，就不须要提供 inference.py 脚本，实例化 TensorFlowModel 对象时只须要指定模型在 Amazon S3 中的地位，以及相干的 role，如下所示：
from sagemaker.tensorflow import TensorFlowModel
model = 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 办法，将推理数据作为参数传入，即可失去推理后果。
2.2 办法二：提供 inference.py 脚本
若须要对输出模型的数据进行前解决或对推理产生的后果进行后处理，则须要在实例化 TensorFlowModel 对象时提供 inference.py 脚本，通过 entry_point 参数指定，如下所示：
from sagemaker.tensorflow import TensorFlowModel
model = 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 前实现申请数据格式的定义，让前端传入的数据更加简洁灵便。
- JSONSerializer：
https://sagemaker.readthedocs…
同样，在失去推理后果后，能够把数据后处理过程写在 output_handler 函数中，通过 response_centent_type 指定序列化对象，将后果返回给前端。
3. 试验
本试验应用曾经训练好的 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 进行推理时只须要传入列表数据即可，如下所示：
4. 总结
本文介绍了 TensorFlow Serving 三种不同 SignatureDefs 的区别以及调用办法，展现了如何将本地训练的模型在 Amazon SageMaker 上进行部署与推理。通过应用 Amazon SageMaker，用户能够疾速地将模型进行部署上线，无需进行简单的配置便可实现高可用的、可扩大的模型服务器架构。
5. 参考资料
[1] https://www.tensorflow.org/tf…
[2] https://www.tensorflow.org/tf…
[3] https://sagemaker.readthedocs…
本篇作者
肖元君
亚马逊云科技解决方案架构师
负责基于亚马逊云科技云计算计划的架构征询和设计实现，同时致力于数据分析与人工智能的钻研与利用。
郭韧
亚马逊云科技人工智能和机器学习方向解决方案架构师
负责基于亚马逊云科技的机器学习计划架构征询和设计，致力于游戏、电商、互联网媒体等多个行业的机器学习计划施行和推广。在退出亚马逊云科技之前，从事数据智能化相干技术的开源及标准化工作，具备丰盛的设计与实践经验。
