Конфигурация обслуживания Tensorflow

В этом руководстве мы рассмотрим многочисленные точки настройки обслуживания Tensorflow.

Обзор

Хотя большинство конфигураций относятся к серверу модели, существует множество способов указать поведение обслуживания Tensorflow:

Модель конфигурации сервера

Самый простой способ обслуживания модели — указать флаги --model_name и --model_base_path (или установить переменную среды MODEL_NAME при использовании Docker). Однако, если вы хотите обслуживать несколько моделей или настроить такие параметры, как частота опроса для новых версий, вы можете сделать это, написав файл конфигурации Model Server.

Вы можете предоставить этот файл конфигурации, используя флаг --model_config_file , и поручить Tensorflow Serving периодически опрашивать обновленные версии этого файла конфигурации по указанному пути, установив флаг --model_config_file_poll_wait_seconds .

Пример использования Docker: 

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

Перезагрузка конфигурации сервера модели

Существует два способа перезагрузить конфигурацию Model Server:

  • Установив флаг --model_config_file_poll_wait_seconds , чтобы указать серверу периодически проверять наличие нового файла конфигурации по адресу --model_config_file filepath.

  • Путем выдачи RPC-вызовов HandleReloadConfigRequest на сервер и программного обеспечения новой конфигурации Model Server.

Обратите внимание, что каждый раз, когда сервер загружает новый файл конфигурации, он будет реализовывать содержимое новой указанной конфигурации и только новой указанной конфигурации. Это означает, что если модель A присутствовала в первом файле конфигурации, который заменяется файлом, содержащим только модель B, сервер загрузит модель B и выгрузит модель A.

Подробности конфигурации сервера модели

Предоставленный файл конфигурации Model Server должен быть буфером протокола ModelServerConfig .

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

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

Настройка одной модели

Каждый ModelConfig определяет одну обслуживаемую модель, включая ее имя и путь, по которому сервер моделей должен искать версии обслуживаемой модели, как показано в приведенном выше примере. По умолчанию сервер будет обслуживать версию с наибольшим номером версии. Это значение по умолчанию можно переопределить, изменив поле model_version_policy.

Обслуживание конкретной версии модели

Чтобы обслуживать конкретную версию модели, а не всегда переходить к версии с наибольшим номером, установите для model_version_policy значение «специфический» и укажите номер версии, которую вы хотите обслуживать. Например, чтобы закрепить версию 42 как обслуживаемую:

model_version_policy {
  specific {
    versions: 42
  }
}

Эта опция полезна для возврата к проверенной версии в случае обнаружения проблемы с последней версией(ями).

Обслуживание нескольких версий модели

Чтобы одновременно обслуживать несколько версий модели, например, чтобы включить предварительную новую версию с частью трафика, установите для model_version_policy значение «специфический» и укажите несколько номеров версий. Например, для обслуживания версий 42 и 43: 

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

Назначение строковых меток версиям модели для упрощения канарейки и отката

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

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

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

В приведенном выше примере вы обслуживаете версии 42 и 43 и связываете ярлык «стабильный» с версией 42 и ярлык «канарейка» с версией 43. Вы можете попросить своих клиентов направлять запросы к одной из «стабильных» или «канарейских» версий. (возможно, на основе хеширования идентификатора пользователя), используя поле version_label буфера протокола ModelSpec , и перемещайте метку вперед на сервере, не уведомляя клиентов. Как только вы закончите сборку версии 43 и будете готовы перевести ее в стабильную версию, вы можете обновить конфигурацию до:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

Если впоследствии вам понадобится выполнить откат, вы можете вернуться к старой конфигурации, в которой версия 42 является «стабильной». В противном случае вы можете двигаться дальше, выгрузив версию 42 и загрузив новую версию 44, когда она будет готова, а затем переместив метку canary на 44 и так далее.

Обратите внимание, что ярлыки можно назначать только тем версиям модели, которые уже загружены и доступны для обслуживания. Как только версия модели станет доступна, можно будет перезагрузить конфигурацию модели на лету, чтобы присвоить ей метку. Этого можно добиться с помощью RPC HandleReloadConfigRequest или если сервер настроен на периодический опрос файловой системы на наличие файла конфигурации, как описано выше .

Если вы хотите присвоить метку еще не загруженной версии (например, указав и версию модели, и метку во время запуска), вам необходимо установить для флага --allow_version_labels_for_unavailable_models значение true, что позволяет новым меткам быть назначены версиям модели, которые еще не загружены.

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

Чтобы соответствовать этой проверке безопасности, при повторном назначении метки уже используемой версии вы должны назначать ее только уже загруженным версиям. Например, если вы хотите переместить метку с указателя на версию N на версию N+1, вы можете сначала отправить конфигурацию, содержащую версии N и N+1, а затем отправить конфигурацию, содержащую версию N+1, метку указывает на N+1 и отсутствие версии N.

Использование REST

Если вы используете поверхность REST API для выполнения запросов на вывод вместо использования

/v1/models/<model name>/versions/<version number>

просто запросите версию, используя метку, структурировав путь запроса следующим образом.

/v1/models/<model name>/labels/<version label> .

Обратите внимание, что метка версии ограничена последовательностью символов Word, состоящей из буквенно-цифровых символов и символов подчеркивания (например, [a-zA-Z0-9_]+ ).

Конфигурация мониторинга

Вы можете предоставить серверу конфигурацию мониторинга, используя флаг --monitoring_config_file , чтобы указать файл, содержащий буфер протокола MonitoringConfig . Вот пример:

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

Чтобы прочитать метрики из приведенного выше URL-адреса мониторинга, сначала необходимо включить HTTP-сервер, установив флаг --rest_api_port . Затем вы можете настроить свой сервер Prometheus для получения показателей с сервера моделей, передав ему значения --rest_api_port и path .

Tensorflow Serving собирает все метрики, которые фиксирует Serving, а также основной Tensorflow.

Пакетная конфигурация

Модельный сервер имеет возможность группировать запросы с различными настройками для повышения пропускной способности. Планирование этой пакетной обработки выполняется глобально для всех моделей и версий моделей на сервере, чтобы обеспечить максимально возможное использование базовых ресурсов независимо от того, сколько моделей или версий моделей в настоящее время обслуживается сервером ( подробнее ). Вы можете включить это поведение, установив флаг --enable_batching , и управлять им, передав конфигурацию флагу --batching_parameters_file .

Пример файла параметров пакетной обработки:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

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

Разные флаги

Помимо флагов, рассмотренных в руководстве, здесь мы перечисляем еще несколько примечательных. Полный список можно найти в исходном коде .

  • --port : порт для прослушивания gRPC API
  • --rest_api_port : порт для прослушивания HTTP/REST API
  • --rest_api_timeout_in_ms : Таймаут для вызовов HTTP/REST API
  • --file_system_poll_wait_seconds : период, в течение которого сервер опрашивает файловую систему на наличие новых версий модели по соответствующему model_base_path каждой модели.
  • --enable_model_warmup : включает прогрев модели с использованием предоставленных пользователем журналов PredictionLogs в каталоге assets.extra/.
  • --mixed_precision=bfloat16 : Включает автоматическую смешанную точность BF16.