Я описал, как обслуживать обученные модели тензорного потока с использованием тензорного потока, в разделе Обслуживание предварительно смоделированного и настраиваемого оценщика тензорного потока с обслуживанием тензорного потока. В статье я объяснил, как создавать модели тензорного потока с помощью оценщика и как обслуживать модели с обслуживанием тензорного потока и докером. И обслуживание 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 для запроса.