Odpowiedz już dziś na lokalne wydarzenie TensorFlow Everywhere!
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Komponent InfraValidator TFX Pipeline

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:

  1. 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.
  2. InfraValidator wykorzystuje te same zasoby (np. Ilość alokacji i typ procesora, pamięć i akceleratory), które będą używane w produkcji.
  3. 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 : tryb LOAD_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 serializowanego tf.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.