Я описал, как обслуживать обученные модели тензорного потока с использованием тензорного потока, в разделе Обслуживание предварительно смоделированного и настраиваемого оценщика тензорного потока с обслуживанием тензорного потока. В статье я объяснил, как создавать модели тензорного потока с помощью оценщика и как обслуживать модели с обслуживанием тензорного потока и докером. И обслуживание tenorflow начинает поддерживать функцию RESTful API в версии 1.8 в дополнение к gRPC API. Итак, я хотел бы описать, как серверные API RESTful с обслуживанием тензорного потока.
В этой статье я расскажу вам о функции RESTful API. Цель состоит в том, чтобы обслуживать классификатор радужной оболочки глаза с помощью HTTP / REST API с использованием модели тензорного потока. Для этого у нас есть три основных шага, как показано ниже:
- Создайте модель тензорного потока для данных радужной оболочки с помощью средства оценки тензорного потока.
- Запустите сервер модели тензорного потока с HTTP / REST API на докере.
- Запрос к HTTP / REST API.
Я расширил репозиторий, который раньше использовался для объяснения gRPC API с использованием tenorflow, чтобы поддерживать RESTful API.
Модель поезда
Прежде всего, мы обучим модель классификации данных радужной оболочки глаза. Я уже объяснял, как обучить модель тензорного потока для обслуживания тензорного потока. Итак, я хотел бы сосредоточиться на создании RESTful API.
Во-первых, что не менее важно, наиболее важным является создание входных данных. Как вы, наверное, знаете, данные радужки имеют четыре характеристики: длина чашелистика, ширина чашелистника, длина лепестка и ширина лепестка. Эти четыре функции должны быть входными элементами RESTful API. Его serving_input_receiver_fn
может быть таким, как показано ниже. Мы определяем элементы ввода с помощьюreceiver_tensors
. То есть входными данными являются sepal_length
, sepal_width
, petal_length
и petal_width.
. Каждая функция может быть списком значений с плавающей запятой. А чтобы формат функций соответствовал обучающим данным, эти четыре функции объединяются перед помещением в граф тензорного потока. Полный код - iris_premodeled_estimator.py.
def serving_input_receiver_fn(): receiver_tensors = { 'sepal_length': tf.placeholder(tf.float32, [None, 1]), 'sepal_width': tf.placeholder(tf.float32, [None, 1]), 'petal_length': tf.placeholder(tf.float32, [None, 1]), 'petal_width': tf.placeholder(tf.float32, [None, 1]), } # Convert give inputs to adjust to the model. features = { INPUT_FEATURE: tf.concat([ receiver_tensors['sepal_length'], receiver_tensors['sepal_width'], receiver_tensors['petal_length'], receiver_tensors['petal_width'] ], axis=1) } return tf.estimator.export.ServingInputReceiver(receiver_tensors=receiver_tensors, features=features)
Следующая команда позволяет нам обучать модели. Контрольные точки и экспортированные модели будут созданы в.
/models/iris_premodeled_estimator
. Как и модель для обслуживания модели тензорного потока, находится в каталоге, путь которого похож на.
/model/iris_premodeled_estimator/export/models/1529121297
.
python python/train/iris_premodeled_estimator.py \ --steps 100 \ --model_dir ./models/iris_premodeled_estimator/
Как я описал ранее как показать сигнатуры обученной модели тензорного потока, saved_model_cli.py позволяет нам показать спецификацию API. Результат должен быть таким, как показано ниже.
python tensorflow/python/tools/saved_model_cli.py show \ --dir ./models/iris_premodeled_estimator/ckpt/export/models/1529109907/ \ --all signature_def['predict']: The given SavedModel SignatureDef contains the following input(s): inputs['petal_length'] tensor_info: dtype: DT_FLOAT shape: (-1, 1) name: Placeholder_2:0 inputs['petal_width'] tensor_info: dtype: DT_FLOAT shape: (-1, 1) name: Placeholder_3:0 inputs['sepal_length'] tensor_info: dtype: DT_FLOAT shape: (-1, 1) name: Placeholder:0 inputs['sepal_width'] tensor_info: dtype: DT_FLOAT shape: (-1, 1) name: Placeholder_1:0 The given SavedModel SignatureDef contains the following output(s): outputs['class_ids'] tensor_info: dtype: DT_INT64 shape: (-1, 1) name: dnn/head/predictions/ExpandDims:0 outputs['classes'] tensor_info: dtype: DT_STRING shape: (-1, 1) name: dnn/head/predictions/str_classes:0 outputs['logits'] tensor_info: dtype: DT_FLOAT shape: (-1, 3) name: dnn/logits/BiasAdd:0 outputs['probabilities'] tensor_info: dtype: DT_FLOAT shape: (-1, 3) name: dnn/head/predictions/probabilities:0 Method name is: tensorflow/serving/predict
То есть тело запроса HTTP / REST будет таким, как показано ниже.
{ "signature_name":"predict", "instances":[ { "sepal_length":[6.8], "sepal_width":[3.2], "petal_length":[5.9], "petal_width":[2.3] }, ] }
Предложить RESTful API с обслуживанием Tensorflow
Поскольку мы предлагаем сервер gRPC с докером, мы также предложим HTTP / REST API с докером. Все, что нам нужно для расширения Dockerfile, - это просто добавить параметры tensorflow_model_server
. Tensorflow, обслуживающий 1.8, поддерживает — rest_api_port
, который используется для указания номера порта REST API. Значение по умолчанию - 0. То есть по умолчанию он не предлагает REST API. Dockerfile находится здесь.
CMD tensorflow_model_server \ --port=8500 \ --rest_api_port=8501 \ --model_name="$MODEL_NAME" \ --model_base_path="$MODEL_PATH"
После создания образа докера с помощью Dockerfile мы подготовимся к обслуживаемой модели. Сначала мы создаем каталог для совместного использования между локальным компьютером и контейнером докеров. Затем мы выбираем обученную модель для обслуживания и затем копируем ее в каталог.
# Make a directory to store the served model. mkdir -p ./model_for_serving/iris/1 # Copy the model files to the appropriate directory. cp -R ./models/iris_premodeled_estimator/export/models/1529121297/ \ ./model_for_serving/iris/1
Теперь мы готовы предложить не только gRPC API, но и HTTP / REST API с докером. Следующая команда является примером запуска контейнера докеров, разделяющего каталог модели между локальным компьютером и контейнером докера. Где MODEL_NAME
используется для установки имени модели, а MODEL_PATH
используется для указания пути к обученным моделям.
docker run --rm -v /PATH/TO/models_for_serving:/models \ -e MODEL_NAME=iris_premodeled_estimator \ -e MODEL_PATH=/models/iris_premodeled_estimator \ -p 8500:8500 \ # gRPC port -p 8501:8501 \ # REST port --name tensorflow-serving-example \ tensorflow-serving-example:0.3
Запрос к RESTful API с обслуживанием Tensorflow
Документацию по RESTful API для обслуживания тензорного потока можно посмотреть здесь. TensorFlow ModelServer, работающий на хосте: порт принимает следующие запросы REST API:
POST http://host:port/<URI>:<VERB>
URI: /v1/models/${MODEL_NAME}[/versions/${MODEL_VERSION}]
VERB: classify|regress|predict
Мы запустили контейнер докеров, чтобы предложить RESTful API для классификации данных радужной оболочки глаза. Теперь давайте обратимся к HTTP / REST API с помощью curl
. Где имя модели - iris
, а версия - 1. Объект JSON находится в -d
параметрах. В результате мы можем получить идентификаторы классов, вероятности для каждого класса и так далее.
DOCKER_HOST="..." curl -X POST \ http://${DOCKER_HOST}:8501/v1/models/iris/versions/1:predict \ -d '{"signature_name":"predict","instances":[{"sepal_length":[6.8],"sepal_width":[3.2],"petal_length":[5.9],"petal_width":[2.3]}]}' { "predictions": [ { "class_ids": [2], "probabilities": [9.6812e-06, 0.155927, 0.844063], "classes": ["2"], "logits": [-4.74621, 4.94074, 6.62958] } ] }
Резюме
Благодаря обслуживанию тензорного потока, как только мы получили отличные модели с тензорным потоком, обслуживание тензорного потока позволяет нам автоматически создавать не только gRPC API, но и RESTful API. То есть мы, ребята, занимающиеся машинным обучением, можем больше сосредоточиться на создании моделей.
Если вы хотите ознакомиться с ним, официальный документ описывает тело запроса и ответа объекта JSON для запроса.