TensorFlow 篇 | TensorFlow 2.x 模型 Serving 服务





「导语」在模型训练完成后，我们需要使用保存后的模型进行线上预测，即模型 Serving 服务。 TensorFlow 团队提供了专门用于模型预测的服务系统 TensorFlow Serving，它专为生产环境设计，具备高性能且具有很强大的灵活性，本文将从服务搭建，服务配置，远程访问等多个方面对 TensorFlow Serving 进行详细地介绍。



Serving 服务搭建



官方推荐使用 Docker 来完成 TensorFlow Serving 服务的搭建，这是最容易也是最直接的搭建方式。为便于操作，本文也采取了这种搭建方式。



在搭建 Serving 服务时，首先要确保系统已经安装了 Docker 程序，然后通过命令 docker pull tensorflow/serving:version 来获取指定版本的 TensorFlow Serving 镜像，接着就可以使用该镜像来启动 Serving 服务了。



需要注意的是 TensorFlow Serving 服务的版本最好与训练时用到的 TensorFlow 版本保持一致，以减少不必要的兼容性问题。可以从 dockerhub 网站查询该镜像的所有可用版本，比如稳定版 (latest) ，指定版本 (2.2.0) 或者每天更新版 (nightly) 等。



如果要使用 GPU 来支持模型的预测服务，则需要获取 TensorFlow Serving 镜像相应的 GPU 版本 (docker pull tensorflow/serving:version-gpu) 并且要配置好本地的 GPU 环境。



单模型 Serving 服务



当我们训练完成并保存好一个模型后，可以很方便地启动一个 Serving 服务来进行测试与验证。



首先将保存的 SavedModel 格式的模型文件放置于本地的 /path/to/tfs/models/model/version 目录下，该目录的结构如下所示：



model/

└── 0

├── assets

├── saved_model.pb

└── variables

├── variables.data-00000-of-00001

└── variables.index



其中 model 表示将要加载的模型名称， 0 表示该模型的可用版本，这里只有一个版本，也可以存在多个版本。版本目录下的文件即为 SavedModel 格式的文件，在模型保存一文中已经对这些文件存储的内容做过介绍，这里就不再赘述。



然后使用以下命令即可启动一个 Serving 服务：



docker run -d -p 8501:8501 \

-v /path/to/tfs/models/model:/models/model \

tensorflow/serving:2.2.0



该 Serving 服务仅加载了一个模型，模型的名称为 model ，版本号为 0 。搭载该 Serving 服务的容器暴露了 8501 端口，用于接收 HTTP 接口的访问请求。



我们可以在容器启动时通过设置容器内的环境变量 MODEL_BASE_PATH 来指定模型的存储路径，该环境变量的默认值为 /models ，表示从容器内的 /models 路径加载模型。同样地，可以通过 MODEL_NAME 环境变量来指定要加载的模型名称，该环境变量的默认值为 model 。基于环境变量的 Serving 服务启动命令如下所示：



docker run -d -p 8501:8501 \

-v /path/to/tfs/models/model:/models/model \

-e MODEL_BASE_PATH=/models \

-e MODEL_NAME=model \

tensorflow/serving:2.2.0



除了设置容器内的环境变量，我们还可以使用 Serving 服务的启动参数 --model_base_path 和 --model_name 来分别指定模型的存储路径和模型名称。启动命令如下所示：



docker run -d -p 8501:8501 \

-v /path/to/tfs/models/model:/models/model \

tensorflow/serving:2.2.0 \

--model_base_path=/models \

--model_name=model



在 Serving 服务成功启动后，可以通过访问特定的 HTTP 接口来查看模型是否加载成功。其请求和响应的示例如下所示：



$ curl http://localhost:8501/v1/models/model

{

"model_version_status": [

{

"version": "0",

"state": "AVAILABLE",

"status": {

"error_code": "OK",

"error_message": ""

}

}

]

}



当模型状态为 AVAILABLE 时表示该模型的相应版本已经成功加载，并且已经准备好提供 Serving 服务了。如果调用该接口返回错误或没有返回，则说明模型加载出现问题，此时可以根据返回的错误信息或者使用 docker logs containerid 查看容器的日志以定位问题。



需要注意的是，如果模型的存储路径下包含多个模型版本，则 Serving 服务默认会加载最大版本号对应的模型，也就是说一个模型同时只能有一个版本提供 Serving 服务。



多模型 Serving 服务



一般而言，线上的 Serving 服务中会同时部署多个模型或者模型的多个版本，以供 A/B Test 测试使用，进而区分不同模型的实际运行效果。而上一节介绍的单模型 Serving 服务由于其模型名称和加载的模型版本都是固定的，因此并不能满足这一需求，此时可以使用带有配置文件 (models.config) 的 Serving 服务来实现上述目标。



模型配置文件的内容是基于 ModelServerConfig 结构生成的， ModelServerConfig 是 model_server_config.proto 文件中定义的一种数据结构 (message) ，具体定义信息可参见其源码。该配置文件的基础示例如下所示：



model_config_list {

config {

name: 'first_model'

base_path: '/models/first_model'

model_platform: 'tensorflow'

}

config {

name: 'second_model'

base_path: '/models/second_model'

model_platform: 'tensorflow'

}

}



配置文件中的每一个 config 都对应于一个将要被加载的模型，其中 base_path 对应于该模型的加载路径， name 对应于模型的名称，如果该路径中存在多个版本的模型文件，那么 TensorFlow Serving 还是会选择最大版本号的模型来提供 Serving 服务。



将上述配置文件放置于 /path/to/tfs/config 目录并使用如下命令即可启动一个多模型的 TensorFlow Serving 服务：



docker run -d -p 8501:8501 \

-v /path/to/tfs/models:/models \

-v /path/to/tfs/config:/config \

tensorflow/serving:2.2.0 \

--model_config_file=/config/models.config



同理在 Serving 服务启动后可以使用 HTTP 接口来查看各个模型的加载信息：



$ curl http://localhost:8501/v1/models/first_model

$ curl http://localhost:8501/v1/models/second_model

{

"model_version_status": [

{

"version": "0",

"state": "AVAILABLE",

"status": {

"error_code": "OK",

"error_message": ""

}

}

]

}



此时我们就可以使用多个模型来同时进行线上 Serving 服务了。



Serving 服务配置



模型配置



models.config 配置文件除了可以指定多个模型的名称和加载路径以外，还可以指定模型的版本策略 (version policy)、版本的标签 (labels) 以及请求日志的记录 (logging) 方式等，为我们提供了极大的便利。



在同一模型路径下， Serving 服务会默认加载版本号最大的那个模型，而通过修改配置文件中的 model_version_policy 配置项我们可以指定要加载的模型版本。假如我们要使用版本号为 N 的模型提供 Serving 服务，首先需要将 model_version_policy 策略设置为 specific ，然后在 specific 中提供相应的版本号 N 即可。指定版本号的模型配置如下所示：



config {

name: 'first_model'

base_path: '/models/first_model'

model_platform: 'tensorflow'

model_version_policy {

specific {

versions: 0

}

}

}



这种配置选项在最新版本的模型 Serving 出现问题需要回滚到一个已知的较好版本时会比较有用。



如果需要同时使用多个版本的模型来提供 Serving 服务，也是同样地设置方式，只不过需要在 specific 中提供多个版本号。模型配置如下所示：



config {

name: 'first_model'

base_path: '/models/first_model'

model_platform: 'tensorflow'

model_version_policy {

specific {

versions: 0

versions: 1

}

}

}



有时为模型的版本号指定一个别名或标签会很有帮助，这样客户端在调用时就不必知道具体的版本号，直接访问对应的标签即可。比如我们可以设置一个稳定版 (stable) 标签，它可以指向任一版本号的模型，客户端只需访问 stable 标签即可获取最新 Serving 服务。如果有新的稳定版本，则只需要修改 stable 标签指向的版本号，而客户端对这次改变是无感知的，因此也无需做任何修改。注意只有通过 gRPC 接口访问时才可以使用标签功能，HTTP 接口则不支持。



带有标签的模型配置如下所示：



config {

name: 'first_model'

base_path: '/models/first_model'

model_platform: 'tensorflow'

model_version_policy {

specific {

versions: 0

versions: 1

}

}

version_labels {

key: 'stable'

value: 1

}

version_labels {

key: 'canary'

value: 0

}

}



如果模型需要回滚，则只需要修改配置文件中相应标签对应的版本号即可。



注意只有模型版本已被加载的且该模型版本的状态为 AVAILABLE 时，才能给该模型版本指定一个标签。如果需要给一个尚未加载的模型版本指定标签（比如在 Serving 启动时，配置文件中同时提供了模型版本和标签），则需要将 --allow_version_labels_for_unavailable_models 启动参数设置为 true 。



而上述启动参数，只适用于为新标签指定版本号。如果要给一个已在使用的标签重新分配版本，则必须将其分配给一个已加载的模型版本，这样可以避免在版本切换时发送到该标签的请求失效而造成线上故障。因此，如果要将标签 stable 从版本 N 重新分配到版本 N + 1，则必须首先提交同时包含版本 N 和版本 N + 1 的配置，待版本 N + 1 加载成功后，再提交将标签 stable 指向版本 N + 1 的配置以完成标签的更新操作。



监控配置



在线上 Serving 时，我们需要了解 Serving 服务的各项指标，以便于我们及时发现问题并作出调整。



我们可以使用 --monitoring_config_file 参数来启用 Serving 服务的监控指标获取功能。该参数需要指定一个配置文件，其内容对应于 monitoring_config.proto 文件中定义的 MonitoringConfig 数据结构 (message) ，具体定义可参见源码。配置文件的内容如下所示：



prometheus_config {

enable: true,

path: "/metrics"

}



其中 enable 表示是否开启监控， path 表示获取监控指标的 uri 。将上述配置保存到 monitor.config 文件中并将该文件放置于 /path/to/tfs/config 目录下，然后使用如下命令即可启动带有监控指标的 Serving 服务：



docker run -d -p 8501:8501 \

-v /path/to/tfs/models:/models \

-v /path/to/tfs/config:/config \

tensorflow/serving:2.2.0 \

--model_config_file=/config/models.config \

--monitoring_config_file=/config/monitor.config



访问 http://localhost:8501/metrics 即可看到 TensorFlow Serving 服务的实时监控指标信息。部分监控指标如下所示：



# TYPE :tensorflow:api:op:using_fake_quantization gauge

# TYPE :tensorflow:cc:saved_model:load_attempt_count counter

:tensorflow:cc:saved_model:load_attempt_count{model_path="/models/first_model/0",status="success"} 1

:tensorflow:cc:saved_model:load_attempt_count{model_path="/models/first_model/1",status="success"} 1

:tensorflow:cc:saved_model:load_attempt_count{model_path="/models/second_model/1",status="success"} 1

# TYPE :tensorflow:cc:saved_model:load_latency counter

:tensorflow:cc:saved_model:load_latency{model_path="/models/first_model/0"} 61678

:tensorflow:cc:saved_model:load_latency{model_path="/models/first_model/1"} 59848

:tensorflow:cc:saved_model:load_latency{model_path="/models/second_model/1"} 95868

# TYPE :tensorflow:cc:saved_model:load_latency_by_stage histogram

:tensorflow:cc:saved_model:load_latency_by_stage_bucket{model_path="/models/first_model/0",stage="init_graph",le="10"} 0



为了更直观的监控这些指标，可以将所有的指标都采集到 Prometheus 并使用 Grafana 进行可视化展示。部分指标可视化的结果如下图所示：





批处理配置



Serving 服务可以对客户端的请求进行批处理，以实现更好的吞吐量。对于 Serving 服务加载的所有模型和模型版本，批处理操作将会在全局范围内进行统一调度，以确保可以最大程度的利用基础计算资源。可以使用 --enable_batching 参数来启用批处理操作，并使用 --batching_parameters_file 启动参数指定批处理参数配置文件 (batching.config)来对与批处理有关的参数进行配置。



批处理参数配置文件的内容如下所示：



max_batch_size { value: 128 }

batch_timeout_micros { value: 0 }

num_batch_threads { value: 8 }

max_enqueued_batches { value: 8 }



其中 max_batch_size 参数用来控制吞吐量和延迟之间的权衡，同时它也可以防止因 batch 过大超出了资源限制而导致请求失败。 batch_timeout_micros 参数表示执行一次批处理操作之前所要等待的最长时间（即使可能尚未达到 max_batch_size 也会执行），主要用于控制尾部延迟。 num_batch_threads 表示并行执行批处理操作的最大数量。 max_enqueued_batches 表示可以进入调度程序队列的批处理任务的数量，用来对排队带来的延迟进行限制。



将 batching.config 文件并放置于 /path/to/tfs/config 目录下，然后使用以下命令即可启动一个带有批处理操作的 Serving 服务：



docker run -d -p 8501:8501 \

-v /path/to/tfs/models:/models \

-v /path/to/tfs/config:/config \

tensorflow/serving:2.2.0 \

--model_config_file=/config/models.config \

--enable_batching=true \

--batching_parameters_file=/config/batching.config



注意在调整 max_batch_size 和 max_enqueued_batches 参数时，不能设置的过大，避免因内存占用过高而导致内存溢出，从而影响线上的 Serving 服务。



服务启动参数



除了上面介绍过的一些 Serving 服务启动参数外，还有其它一些启动参数需要了解，使用这些参数可以对部署的 Serving 服务进行微调，以达到想要的效果。下面对其中一些比较重要的启动参数做简要介绍：



1. --port：gRPC 服务的监听端口，默认为 8500 端口。



1. --rest_api_port：HTTP 服务的监听端口，默认为 8501 端口。



1. --rest_api_timeout_in_ms：HTTP 请求的超时限制（毫秒），默认为 30000 毫秒。



1. --model_config_file：模型配置文件路径。



1. --model_config_file_poll_wait_seconds：定期加载模型配置文件的时间间隔（秒），默认为 0 ，表示 Serving 服务启动后就不再定期加载。



1. --file_system_poll_wait_seconds：定期加载新模型版本的时间间隔（秒），默认为 1 秒。



1. --enable_batching：bool，是否开启请求批处理操作，默认为 false 。



1. --batching_parameters_file：批处理操作的参数配置文件路径。



1. --monitoring_config_file：用于监控的配置文件路径。



1. --allow_version_labels_for_unavailable_models：bool，是否可以对尚未加载的模型分配标签，默认为 false 。



1. --model_name：模型名称，在单模型 Serving 时使用。



1. --model_base_path：模型加载路径，在单模型 Serving 时使用。



1. --enable_model_warmup：bool，是否使用数据对模型进行预热，以减少第一次请求的响应延迟，默认为 false 。因为 TensorFlow 运行时具有延迟初始化的组件，这可能导致在模型加载后发送给模型的第一次请求的响应时间比较长，而且这个延迟的时间可能比单个请求所需的时间高好几个数量级。为了减小延迟初始化对请求响应的影响，可以在模型加载时提供一组请求样本来触发组件的初始化，这个过程被称为模型预热。



1. 更多的启动参数可以参见源码。



完整示例



一个配置齐全的多模型 Serving 服务的启动方式如下所示：



docker run -d -p 8500:8500 -p 8501:8501 \

-v /path/to/tfs/models:/models \

-v /path/to/tfs/config:/config \

tensorflow/serving:2.2.0 \

--model_config_file=/config/models.config \

--monitoring_config_file=/config/monitor.config \

--enable_batching=true \

--batching_parameters_file=/config/batching.config \

--model_config_file_poll_wait_seconds=10 \

--file_system_poll_wait_seconds=10 \

--allow_version_labels_for_unavailable_models=true



HTTP 接口访问



我们可以通过访问 Serving 服务的 HTTP 接口来查询模型信息，包括模型的加载状态，模型的元数据以及模型的预测结果等。



所有的请求和响应的 Body 都是 json 格式的，对于错误的请求， Serving 服务会返回如下格式的错误信息：



{

"error": "error message string"

}



模型状态



访问 http://host:port/v1/models/${MODEL_NAME}[/versions/${MODEL_VERSION}] 接口可以获取模型的指定版本的状态信息，其中 /versions/${MODEL_VERSION} 是可选部分，如果不指定则会返回该模型所有版本的状态信息。请求和响应示例如下所示：



$ curl http://localhost:8501/v1/models/first_model/versions/0

{

"model_version_status": [

{

"version": "0",

"state": "AVAILABLE",

"status": {

"error_code": "OK",

"error_message": ""

}

}

]

}



模型 Metadata



访问 http://host:port/v1/models/${MODEL_NAME}[/versions/${MODEL_VERSION}]/metadata 接口可以获取模型的指定版本的元数据信息。其中 /versions/${MODEL_VERSION} 是可选部分，如果不指定则会返回该模型最新版本的元数据。请求和响应示例如下所示：



$ curl http://localhost:8501/v1/models/first_model/versions/0/metadata

{

"model_spec": {

"name": "first_model",

"signature_name": "",

"version": "0"

},

"metadata": {

"signature_def": {

"signature_def": {

"serving_default": {

"inputs": {

"input_1": {

"dtype": "DT_INT64",

"tensor_shape": {

"dim": [

{

"size": "-1",

"name": ""

},

{

"size": "31",

"name": ""

}

],

"unknown_rank": false

},

"name": "serving_default_input_1:0"

}

},

"outputs": {

"output_1": {

"dtype": "DT_FLOAT",

"tensor_shape": {

"dim": [

{

"size": "-1",

"name": ""

},

{

"size": "1",

"name": ""

}

],

"unknown_rank": false

},

"name": "StatefulPartitionedCall:0"

}

},

"method_name": "tensorflow/serving/predict"

},

"__saved_model_init_op": {

"inputs": {},

"outputs": {

"__saved_model_init_op": {

"dtype": "DT_INVALID",

"tensor_shape": {

"dim": [],

"unknown_rank": true

},

"name": "NoOp"

}

},

"method_name": ""

}

}

}

}

}



元数据信息中包含了该模型输入张量的数据类型和维度信息，还包含了输入张量的名称 (key) ，这里为 input_1 ，这对于后面使用数据进行模型预测十分重要，因为数据的 input_key 以及输入格式必须要与 metadata 中的定义保持一致。



模型预测



访问 http://host:port/v1/models/${MODEL_NAME}[/versions/${MODEL_VERSION}]:predict 接口可以获取指定输入数据的预测值，即给定模型的数据输入，获取模型的预测输出。 其中 /versions/${MODEL_VERSION} 是可选部分，如果不指定则会默认使用最新版本的模型进行预测。



访问该接口需要提供一个 json 格式的请求 Body ，其格式如下所示：



{

// 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": |<(nested)list>|

"inputs": |<(nested)list>|