InfraValidator to składnik TFX, który jest używany jako warstwa wczesnego ostrzegania przed wprowadzeniem modelu do produkcji. Nazwa walidator „infra” wzięła się stąd, że waliduje on model w rzeczywistym modelu obsługującym „infrastrukturę”. Jeśli ewaluator ma zagwarantować wydajność modelu, InfraValidator ma zagwarantować, że model jest mechanicznie w porządku i zapobiega wypychaniu złych modeli.
Jak to działa?
InfraValidator pobiera model, uruchamia serwer modelu w piaskownicy z modelem i sprawdza, czy można go pomyślnie załadować i opcjonalnie odpytać. Wynik walidacji infra zostanie wygenerowany w wyniku blessing
w taki sam sposób, jak robi to Evaluator .
InfraValidator koncentruje się na kompatybilności między binarnym modelem serwera (np. TensorFlow Serving ) a modelem do wdrożenia. Pomimo nazwy „infra” walidator, użytkownik jest odpowiedzialny za prawidłowe skonfigurowanie środowiska, a walidator infra współpracuje tylko z serwerem modelowym w środowisku skonfigurowanym przez użytkownika, aby sprawdzić, czy działa poprawnie. Prawidłowe skonfigurowanie tego środowiska zapewni, że pomyślna lub niepomyślna walidacja infra będzie wskazywać, czy model będzie obsługiwany w produkcyjnym środowisku obsługującym. Oznacza to, między innymi, następujące kwestie:
- InfraValidator używa tego samego pliku binarnego serwera modelu, który będzie używany w produkcji. Jest to minimalny poziom, do którego musi zbiegać się środowisko walidacji w podczerwieni.
- InfraValidator wykorzystuje te same zasoby (np. Ilość alokacji i typ procesora, pamięć i akceleratory), które będą używane w produkcji.
- InfraValidator używa tej samej konfiguracji serwera modelu, która będzie używana w produkcji.
W zależności od sytuacji użytkownicy mogą wybrać, w jakim stopniu InfraValidator ma być identyczny ze środowiskiem produkcyjnym. Technicznie model może zostać poddany walidacji infra w lokalnym środowisku Dockera, a następnie bez problemu obsługiwany w zupełnie innym środowisku (np. Klastrze Kubernetes). Jednak InfraValidator nie będzie sprawdzać tej rozbieżności.
Tryb pracy
W zależności od konfiguracji walidacja infra odbywa się w jednym z następujących trybów:
- Tryb
LOAD_ONLY
: sprawdzanie, czy model został pomyślnie załadowany do infrastruktury obsługującej, czy nie. LUB - Tryb
LOAD_AND_QUERY
: trybLOAD_ONLY
plus wysyłanie przykładowych żądań, aby sprawdzić, czy model jest w stanie obsługiwać wnioski. InfraValidator nie dba o to, czy prognoza była poprawna, czy nie. Liczy się tylko to, czy żądanie się powiodło, czy nie.
Jak tego używam?
Zwykle InfraValidator jest definiowany obok komponentu Evaluator, a jego dane wyjściowe są przekazywane do Pusher. Jeśli InfraValidator zawiedzie, model nie zostanie przekazany.
evaluator = Evaluator(
model=trainer.outputs['model'],
examples=example_gen.outputs['examples'],
baseline_model=model_resolver.outputs['model'],
eval_config=EvalConfig(...)
)
infra_validator = InfraValidator(
model=trainer.outputs['model'],
serving_spec=ServingSpec(...)
)
pusher = Pusher(
model=trainer.outputs['model'],
model_blessing=evaluator.outputs['blessing'],
infra_blessing=infra_validator.outputs['blessing'],
push_destination=PushDestination(...)
)
Konfigurowanie składnika InfraValidator.
Istnieją trzy rodzaje protokołów do konfigurowania narzędzia InfraValidator.
ServingSpec
ServingSpec
jest najważniejszą konfiguracją dla InfraValidator. Określa:
- jaki typ serwera modelowego do uruchomienia
- gdzie to uruchomić
Obsługujemy modele serwerów (zwane serwującymi binarnymi)
Obecnie obsługiwane są następujące platformy obsługujące:
- Lokalny Docker (Docker powinien być zainstalowany wcześniej)
- Kubernetes (ograniczona obsługa tylko KubeflowDagRunner)
Wyboru platformy obsługującej oneof
binarne i platformy obsługującej dokonuje się, określając jeden z bloków specyfikacji ServingSpec
. Na przykład, aby użyć pliku binarnego obsługi TensorFlow działającego w klastrze kubernetes
należy ustawić pola tensorflow_serving
i kubernetes
.
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=ServingSpec(
tensorflow_serving=TensorFlowServing(
tags=['latest']
),
kubernetes=KubernetesConfig()
)
)
Aby dokładniej skonfigurować ServingSpec
, zapoznaj się z definicją protobuf .
ValidationSpec
Opcjonalna konfiguracja w celu dostosowania kryteriów walidacji infra lub przepływu pracy.
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=ServingSpec(...),
validation_spec=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
)
)
Wszystkie pola ValidationSpec mają domyślną wartość dźwiękową. Sprawdź więcej szczegółów z definicji protobuf .
RequestSpec
Opcjonalna konfiguracja, aby określić, jak budować przykładowe żądania podczas uruchamiania walidacji infra w trybie LOAD_AND_QUERY
. Aby użyć trybu LOAD_AND_QUERY
, wymagane jest określenie zarówno właściwości wykonania request_spec
, jak i examples
kanału wejściowego w definicji komponentu.
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=ServingSpec(
# Depending on what kind of model server you're using, RequestSpec
# should specify the compatible one.
tensorflow_serving=TensorFlowServing(tags=['latest']),
local_docker=LocalDockerConfig(),
),
request_spec=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=TensorFlowServingRequestSpec(
signature_names=['classification']
),
num_examples=10 # How many requests to make.
)
)
Ograniczenia
Obecny InfraValidator nie jest jeszcze ukończony i ma pewne ograniczenia.
- Można zweryfikować tylko format modelu TensorFlow SavedModel .
- Podczas uruchamiania TFX na Kubernetes potok powinien być wykonywany przez
KubeflowDagRunner
wewnątrz Kubeflow Pipelines. Serwer modelowy zostanie uruchomiony w tym samym klastrze Kubernetes i przestrzeni nazw, której używa Kubeflow. - InfraValidator koncentruje się głównie na wdrożeniach w TensorFlow Serving i chociaż nadal jest przydatny, jest mniej dokładny w przypadku wdrożeń w TensorFlow Lite i TensorFlow.js lub innych strukturach wnioskowania.
Istnieje ograniczone wsparcie na
LOAD_AND_QUERY
trybie do przewidzenia podpis metody (co jest jedynym sposobem eksportowalne w TensorFlow 2). InfraValidator wymaga podpisu Predict, aby korzystać z serializowanegotf.Example
jako jedynego wejścia.@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')) })
- Zapoznaj się z przykładowym kodem Penguin, aby zobaczyć, jak ten podpis współdziała z innymi składnikami TFX.