InfraValidator — это компонент TFX, который используется в качестве уровня раннего предупреждения перед запуском модели в производство. Название «инфра»-валидатор произошло от того факта, что он проверяет модель в реальной модели, обслуживающей «инфраструктуру». Если Evaluator должен гарантировать производительность модели, InfraValidator должен гарантировать, что модель механически исправна и предотвращает распространение плохих моделей.
Как это работает?
InfraValidator берет модель, запускает изолированный сервер модели с моделью и проверяет, можно ли ее успешно загрузить и, при необходимости, запросить. Результат инфраструктурной проверки будет сгенерирован в выходных данных blessing
так же, как это делает Evaluator .
InfraValidator фокусируется на совместимости между двоичным файлом сервера модели (например, TensorFlow Serving ) и моделью для развертывания. Несмотря на название «инфра-валидатор», ответственность за правильную настройку среды лежит на пользователе , а инфраструктурный валидатор взаимодействует только с сервером модели в среде, настроенной пользователем, чтобы проверить, работает ли он нормально. Правильная настройка этой среды гарантирует, что прохождение или неудача инфраструктурной проверки будет указывать на то, будет ли модель обслуживаться в производственной среде обслуживания. Это подразумевает, помимо прочего, следующее:
- InfraValidator использует тот же двоичный файл модели сервера, который будет использоваться в рабочей среде. Это минимальный уровень, к которому должна сходиться среда инфраструктурной валидации.
- InfraValidator использует те же ресурсы (например, объем выделения и тип ЦП, памяти и ускорителей), которые будут использоваться в рабочей среде.
- InfraValidator использует ту же конфигурацию сервера модели, которая будет использоваться в рабочей среде.
В зависимости от ситуации пользователи могут выбирать, в какой степени InfraValidator должен быть идентичен производственной среде. Технически модель можно без проблем проверить в локальной среде Docker, а затем обслуживать в совершенно другой среде (например, в кластере Kubernetes). Однако InfraValidator не проверит это расхождение.
Режим работы
В зависимости от конфигурации инфраструктурная валидация осуществляется в одном из следующих режимов:
- Режим
LOAD_ONLY
: проверка того, была ли модель успешно загружена в обслуживающую инфраструктуру или нет. ИЛИ - Режим
LOAD_AND_QUERY
: режимLOAD_ONLY
плюс отправка нескольких образцов запросов, чтобы проверить, способна ли модель обслуживать выводы. InfraValidator не заботится о том, был ли прогноз верным или нет. Имеет значение только то, был ли запрос успешным или нет.
Как мне его использовать?
Обычно InfraValidator определяется рядом с компонентом Evaluator, и его выходные данные передаются в Pusher. Если InfraValidator завершится сбоем, модель не будет отправлена.
evaluator = Evaluator(
model=trainer.outputs['model'],
examples=example_gen.outputs['examples'],
baseline_model=model_resolver.outputs['model'],
eval_config=tfx.proto.EvalConfig(...)
)
infra_validator = InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(...)
)
pusher = Pusher(
model=trainer.outputs['model'],
model_blessing=evaluator.outputs['blessing'],
infra_blessing=infra_validator.outputs['blessing'],
push_destination=tfx.proto.PushDestination(...)
)
Настройка компонента InfraValidator.
Существует три типа прототипов для настройки InfraValidator.
ServingSpec
ServingSpec
— это наиболее важная конфигурация для InfraValidator. Он определяет:
- какой тип сервера модели запускать
- где его запустить
Для типов модельных серверов (так называемых обслуживающих двоичных файлов) мы поддерживаем
В настоящее время поддерживаются следующие обслуживающие платформы:
- Локальный Docker (Докер должен быть установлен заранее)
- Kubernetes (ограниченная поддержка только для KubeflowDagRunner)
Выбор обслуживающего двоичного файла и обслуживающей платформы осуществляется путем указания oneof
блоков ServingSpec
. Например, чтобы использовать двоичный файл TensorFlow Serving, работающий в кластере Kubernetes, необходимо установить поля tensorflow_serving
и kubernetes
.
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(
tensorflow_serving=tfx.proto.TensorFlowServing(
tags=['latest']
),
kubernetes=tfx.proto.KubernetesConfig()
)
)
Для дальнейшей настройки ServingSpec
ознакомьтесь с определением protobuf .
ValidationSpec
Дополнительная конфигурация для настройки критериев проверки инфраструктуры или рабочего процесса.
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(...),
validation_spec=tfx.proto.ValidationSpec(
# How much time to wait for model to load before automatically making
# validation fail.
max_loading_time_seconds=60,
# How many times to retry if infra validation fails.
num_tries=3
)
)
Все поля ValidationSpec имеют правильное значение по умолчанию. Более подробную информацию можно найти в определении protobuf .
RequestSpec
Дополнительная конфигурация, позволяющая указать, как создавать примеры запросов при выполнении инфраструктурной проверки в режиме LOAD_AND_QUERY
. Чтобы использовать режим LOAD_AND_QUERY
, необходимо указать как свойства выполнения request_spec
, так и входной канал examples
в определении компонента.
infra_validator = InfraValidator(
model=trainer.outputs['model'],
# This is the source for the data that will be used to build a request.
examples=example_gen.outputs['examples'],
serving_spec=tfx.proto.ServingSpec(
# Depending on what kind of model server you're using, RequestSpec
# should specify the compatible one.
tensorflow_serving=tfx.proto.TensorFlowServing(tags=['latest']),
local_docker=tfx.proto.LocalDockerConfig(),
),
request_spec=tfx.proto.RequestSpec(
# InfraValidator will look at how "classification" signature is defined
# in the model, and automatically convert some samples from `examples`
# artifact to prediction RPC requests.
tensorflow_serving=tfx.proto.TensorFlowServingRequestSpec(
signature_names=['classification']
),
num_examples=10 # How many requests to make.
)
)
Создание SavedModel с разминкой
(Начиная с версии 0.30.0)
Поскольку InfraValidator проверяет модель с помощью реальных запросов, он может легко повторно использовать эти запросы проверки в качестве запросов на прогрев SavedModel. InfraValidator предоставляет возможность ( RequestSpec.make_warmup
) экспортировать SavedModel с прогревом.
infra_validator = InfraValidator(
...,
request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)
Тогда выходной артефакт InfraBlessing
будет содержать SavedModel с прогревом и также может быть отправлен с помощью Pusher , как и артефакт Model
.
Ограничения
Текущий InfraValidator еще не завершен и имеет некоторые ограничения.
- Можно проверить только формат модели TensorFlow SavedModel .
- При запуске TFX в Kubernetes конвейер должен выполняться
KubeflowDagRunner
внутри Kubeflow Pipelines. Сервер модели будет запущен в том же кластере Kubernetes и пространстве имен, которое использует Kubeflow. - InfraValidator в первую очередь ориентирован на развертывание в TensorFlow Serving , и хотя он по-прежнему полезен, он менее точен для развертываний в TensorFlow Lite и TensorFlow.js или других платформах вывода.
В режиме
LOAD_AND_QUERY
имеется ограниченная поддержка сигнатуры метода Predict (которая является единственным экспортируемым методом в TensorFlow 2). InfraValidator требует, чтобы подпись Predict использовала сериализованныйtf.Example
в качестве единственного входного параметра.@tf.function def parse_and_run(serialized_example): features = tf.io.parse_example(serialized_example, FEATURES) return model(features) model.save('path/to/save', signatures={ # This exports "Predict" method signature under name "serving_default". 'serving_default': parse_and_run.get_concrete_function( tf.TensorSpec(shape=[None], dtype=tf.string, name='examples')) })
- Ознакомьтесь с примером кода Penguin , чтобы увидеть, как эта подпись взаимодействует с другими компонентами в TFX.