С точки зрения непрофессионала, раскрытие любого программного обеспечения клиент-сервер через хост (IP-адрес:порт) называется обслуживанием, и это обеспечивает легкий доступ к любому программному обеспечению/данным для клиента. Обслуживание предоставляет возможность легкого производства любого программного обеспечения (что здесь является моделью глубокого обучения). Что ж, простота производства на самом деле не означает простоту установки и обслуживания. Проходя утомительный процесс обслуживания модели DL, я столкнулся с рядом ошибок и проблем. Поскольку хорошая документация необходима для простого использования службы DL, я решил написать эту статью.

Обслуживание Tensorflow

Обслуживание любой обученной модели через хост, чтобы клиент мог запросить хост для прогнозирования результата по входным данным, называется обслуживанием модели. Модели машинного обучения обычно имеют большой размер, поэтому загрузка модели каждый раз для прогнозирования требует много времени и места. Этого процесса можно избежать благодаря обслуживанию модели, что также позволяет нескольким пользователям получать доступ к модели.

TensorFlow Serving – это гибкая высокопроизводительная система обслуживания моделей машинного обучения, разработанная для производственных сред. TensorFlow Serving упрощает развертывание новых алгоритмов и экспериментов, сохраняя при этом ту же архитектуру сервера и API. TensorFlow Serving обеспечивает готовую интеграцию с моделями TensorFlow, но может быть легко расширен для обслуживания других типов моделей и данных.

Как это работает?

Модель тензорного потока обслуживается с помощью образа докера тензорного потока, а API предоставляется по указанному адресу хоста. Клиент отправляет входные данные и запрашивает прогнозируемый результат из API. Servable — это термин, используемый для объекта (модели), который клиент использует для вычислений. Размер и степень детализации Servable являются гибкими. Один Servable может включать в себя что угодно, от одного фрагмента таблицы поиска до одной модели и кортежа моделей вывода.

Любой запрос от клиента принимает менеджер tf serve . Менеджер отвечает за загрузку, обслуживание и выгрузку Servables.

Загрузчики управляют жизненным циклом Servable. API загрузчика обеспечивает общую инфраструктуру, независимую от конкретных алгоритмов обучения, данных или вариантов использования продукта. В частности, загрузчики стандартизируют API для загрузки и выгрузки Servable.

Источники — это подключаемые модули, которые находят и предоставляют сервисы. Каждый источник предоставляет ноль или более обслуживаемых потоков. Для каждого обслуживаемого потока источник предоставляет один экземпляр загрузчика для каждой версии, доступной для загрузки. (Источник фактически связан с нулем или более SourceAdapters, и последний элемент в цепочке создает загрузчики.) Интерфейс TensorFlow Serving для источников может обнаруживать servables из произвольных систем хранения. TensorFlow Serving включает общие эталонные реализации Source. Например, Источники могут обращаться к таким механизмам, как RPC, и могут опрашивать файловую систему.

Требуемые версии представляют собой набор версий для обслуживания, которые должны быть загружены и готовы. Источники сообщают этот набор обслуживаемых версий для одного обслуживаемого потока за раз.

Менеджеры прослушивают Исходники и отслеживают все версии. Менеджер пытается выполнить запросы Источников, но может отказаться загрузить требуемую версию, если, скажем, требуемые ресурсы недоступны. Менеджеры также могут отложить «разгрузку». Например, менеджер может дождаться выгрузки, пока не завершится загрузка более новой версии, на основе политики, гарантирующей постоянную загрузку по крайней мере одной версии.

Чтобы узнать больше о внутренней работе, нажмите здесь

Как обслуживать модель с помощью тензорного потока?

Для начала нам нужно вытащить образ докера, содержащий тензорный поток, с помощью команды ниже:

docker pull tensorflow/serving

После извлечения изображения обслуживания тензорного потока мы готовы обслуживать нашу модель тензорного потока, используя следующую команду:

sudo docker run -p 8500:8500 --name tf_container_name — mount type=bind,source=/path/to/model,target=/path/to/destination -e MODEL_NAME=modelname -t tensorflow/serving &

Мы должны убедиться, что тег, предоставленный при сохранении модели, является «обслуживанием», а каталог модели содержит каталог переменных и файл pb сохраненной модели. Кроме того, все зависимости должны быть установлены во время обслуживания модели. Модель будет обслуживаться в порту 8500, а остальные API в 8501.

Теперь на стороне клиента мы используем службу gRPC и пишем скрипт Python для отправки входных данных и получения выходных данных модели.

Нам нужно импортировать API-функции tensorflow_serving «predict_pb2» и «prediction_service_pb2_grpc», а также убедиться, что они присутствуют в пути tensorflow_serving.apis.

from tensorflow_serving.apis import predict_pb2
from tensorflow_serving.apis import prediction_service_pb2_grpc

Теперь у нас есть все начальные настройки для доступа к порту, на котором обслуживается модель. Мы устанавливаем канал с сервером gRPC и создаем заглушку для прогнозирования.

channel = grpc.insecure_channel(FLAGS.server)
stub = prediction_service_pb2_grpc.PredictionServiceStub(channel)

После чего мы создаем объект запроса предсказания и указываем имя модели и имя подписи. На этом этапе мы должны указать то же имя модели, которое было объявлено во время обслуживания. Входные данные должны предоставляться в том же формате, что и модель тензорного потока.

request = predict_pb2.PredictRequest()
request.model_spec.name = 'model_name'
request.model_spec.signature_name = 'serving_default'
request.inputs['inputs'].CopyFrom(
  tf.contrib.util.make_tensor_proto(input, shape=input_shape))

Теперь мы готовы прогнозировать. Мы используем функцию прогнозирования созданной заглушки и предоставляем значение тайм-аута.

result = stub.Predict(request, 30.0)

Переменная результата будет содержать результат прогнозирования модели тензорного потока.

Теперь представьте, что v1 и v2 модели динамически генерируются во время выполнения, когда экспериментируют с новыми алгоритмами или когда модель обучается с новым набором данных. В производственной среде мы можем захотеть создать сервер, поддерживающий постепенное развертывание, в котором v2 можно будет обнаружить, загрузить, протестировать, отследить или отменить во время обслуживания v1. В качестве альтернативы мы можем захотеть удалить v1, прежде чем поднимать v2. TensorFlow Serving поддерживает оба варианта (нажмите здесь, чтобы узнать больше) — хотя один хорош для поддержания доступности во время перехода, другой хорош для минимизации использования ресурсов (например, ОЗУ).

Всякий раз, когда доступна новая версия, AspiredVersionsManager загружает новую версию и по умолчанию выгружает старую.

Надеюсь, это помогло!