InfraValidator to komponent TFX, który służy jako warstwa wczesnego ostrzegania przed wprowadzeniem modelu do produkcji. Nazwa walidator „infra” wzięła się stąd, że waliduje model w rzeczywistym modelu służącym „infrastrukturze”. Jeśli Oceniający jest zagwarantowanie skuteczności modelu, InfraValidator jest zagwarantowanie model jest mechanicznie porządku i zapobiega złe modele z pchanych.
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 przeszukać. Wynik walidacji infra zostaną wygenerowane w blessing produkcji w taki sam sposób jak Oceniający robi.
InfraValidator skupia się na zgodności między modelem binarnym serwera (np TensorFlow Serving ) oraz model wdrażania. Pomimo nazwy „infra” walidator, to odpowiedzialność użytkownika, aby skonfigurować środowisko poprawnie i infra Validator tylko współdziała z serwerem modelu w środowisku użytkownika skonfigurowany tak, aby sprawdzić, czy działa poprawnie. Prawidłowe skonfigurowanie tego środowiska zapewni, że przejście lub niepowodzenie walidacji w infra będzie wskazywać, czy model będzie możliwy do serwowania w środowisku obsługi produkcyjnej. Oznacza to, ale nie ogranicza się do następujących:
- InfraValidator używa tego samego modelu serwera binarnego, który będzie używany w środowisku produkcyjnym. Jest to minimalny poziom, do którego musi dojść do konwergencji środowiska infrawalidacji.
- InfraValidator wykorzystuje te same zasoby (np. ilość alokacji i typ procesora, pamięci i akceleratorów), jakie będą używane w środowisku produkcyjnym.
- InfraValidator korzysta z tej samej konfiguracji serwera modelowego, która będzie używana w środowisku produkcyjnym.
W zależności od sytuacji użytkownicy mogą wybrać, w jakim stopniu InfraValidator ma być identyczny ze środowiskiem produkcyjnym. Z technicznego punktu widzenia model można bez problemu poddać walidacji infra w lokalnym środowisku Docker, a następnie obsłużyć w zupełnie innym środowisku (np. klastrze Kubernetes). Jednak InfraValidator nie sprawdził tej rozbieżności.
Tryb pracy
W zależności od konfiguracji, infra-walidacja odbywa się w jednym z następujących trybów:
-
LOAD_ONLYmode: sprawdzenie, czy model został pomyślnie załadowany do infrastruktury służącej czy nie. LUB -
LOAD_AND_QUERYmode:LOAD_ONLYtryb Plus wysyłając kilka przykładowych żądań, by sprawdzić, czy model jest w stanie obsłużyć wnioski. InfraValidator nie dba o to, czy prognoza była poprawna, czy nie. Liczy się tylko to, czy żądanie zakończyło się powodzeniem, czy nie.
Jak z niego korzystać?
Zwykle InfraValidator jest definiowany obok komponentu oceniającego, a jego dane wyjściowe są przekazywane do Pushera. Jeśli InfraValidator nie powiedzie się, model nie zostanie wypchnięty.
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(...)
)
Konfigurowanie komponentu InfraValidator.
Istnieją trzy rodzaje protos do skonfigurowania InfraValidatora.
ServingSpec
ServingSpec jest najistotniejszym konfiguracja InfraValidator. Określa:
- jaki typ modelu serwera do uruchomienia
- gdzie go uruchomić
Obsługujemy typy serwerów modelowych (zwanych binarnymi obsługującymi)
Obecnie obsługiwane są następujące platformy obsługujące:
- Lokalny Docker (Docker należy zainstalować wcześniej)
- Kubernetes (ograniczona obsługa tylko KubeflowDagRunner)
Wybór do serwowania binarny i obsługujących platformę są określając oneof bloku ServingSpec . Na przykład, aby użyć TensorFlow Serving bieg binarny na klastrze Kubernetes, tensorflow_serving i kubernetes pole powinno być ustawione.
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(
tensorflow_serving=tfx.proto.TensorFlowServing(
tags=['latest']
),
kubernetes=tfx.proto.KubernetesConfig()
)
)
Do dalszego skonfigurowania ServingSpec , proszę zapoznać się z definicją Protobuf .
ValidationSpec
Opcjonalna konfiguracja umożliwiająca dostosowanie kryteriów walidacji w podczerwieni lub przepływu pracy.
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
)
)
Wszystkie pola ValidationSpec mają dźwiękową wartość domyślną. Zobacz więcej szczegółów z definicji Protobuf .
RequestSpec
Opcjonalna konfiguracja, aby określić, jak zbudować żądania próbek podczas uruchamiania walidacji infra w LOAD_AND_QUERY trybie. W celu wykorzystania LOAD_AND_QUERY trybie jest wymagane określenie zarówno request_spec właściwości wykonanie, jak również examples kanał wejściowy w definicji składnika.
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.
)
)
Tworzenie SavedModel z rozgrzewką
(od wersji 0.30.0)
Od modelu InfraValidator sprawdza z prawdziwych wniosków, można go łatwo ponownie wykorzystać te żądania walidacji jak prośby Warmup o SavedModel. InfraValidator zapewnia opcję ( RequestSpec.make_warmup ) wyeksportować SavedModel z rozgrzewki.
infra_validator = InfraValidator(
...,
request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)
Następnie wyjście InfraBlessing artefakt będzie zawierać SavedModel z rozgrzewki, a także może być popychany przez Pusher , podobnie jak Model artefaktu.
Ograniczenia
Obecny InfraValidator nie jest jeszcze kompletny i ma pewne ograniczenia.
- Tylko TensorFlow SavedModel Format model może zostać zatwierdzone.
- Uruchamiając TFX na Kubernetes rurociąg powinien być wykonywany przez
KubeflowDagRunnerwewnątrz Kubeflow rurociągów. Serwer modelowy zostanie uruchomiony w tym samym klastrze Kubernetes i przestrzeni nazw, z której korzysta Kubeflow. - InfraValidator koncentruje się przede wszystkim na wdrożeniach do TensorFlow Serving , a jednocześnie użyteczny jest mniej dokładne dla wdrożeń do TensorFlow Lite i TensorFlow.js lub innych ram wnioskowania.
Istnieje ograniczone wsparcie na
LOAD_AND_QUERYtrybie do przewidzenia podpis metody (co jest jedynym sposobem eksportowalne w TensorFlow 2). InfraValidator wymaga podpisu Przewidywanie spożywać zserializowanątf.Examplejako 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')) })- Sprawdź się przykładem Penguin przykładowy kod, aby zobaczyć, jak podpis ten współdziała z innymi składnikami w TFX.