ML Community Day è il 9 novembre! Unisciti a noi per gli aggiornamenti da tensorflow, JAX, e più Per saperne di più

Il componente della pipeline TFX di InfraValidator

InfraValidator è un componente TFX che viene utilizzato come livello di avviso preventivo prima di avviare la produzione di un modello. Il nome validatore "infra" deriva dal fatto che sta convalidando il modello nel modello attuale che serve "infrastruttura". Se Evaluator è quello di garantire le prestazioni del modello, InfraValidator è quello di garantire il modello è meccanicamente bene e impedisce modelli cattivi di essere spinto.

Come funziona?

InfraValidator prende il modello, avvia un server modello in modalità sandbox con il modello e verifica se può essere caricato correttamente e, facoltativamente, interrogato. Il risultato convalida infra verrà generato nella blessing di uscita nello stesso modo come valutatore fa.

InfraValidator concentra sulla compatibilità tra il binario server di modello (ad esempio tensorflow servizio ) e il modello da distribuire. Nonostante il nome validatore "infra", è responsabilità dell'utente per configurare l'ambiente in modo corretto, e infra validator solo interagisce con il server del modello nell'ambiente configurato dall'utente per vedere se funziona bene. La configurazione corretta di questo ambiente assicurerà che il superamento o l'esito negativo della convalida dell'infrastruttura indichi se il modello può essere utilizzato nell'ambiente di produzione. Ciò implica alcuni dei seguenti, ma non solo:

  1. InfraValidator utilizza lo stesso binario del server modello che verrà utilizzato in produzione. Questo è il livello minimo a cui deve convergere l'ambiente di convalida dell'infrastruttura.
  2. InfraValidator utilizza le stesse risorse (ad es. quantità di allocazione e tipo di CPU, memoria e acceleratori) che verranno utilizzate in produzione.
  3. InfraValidator utilizza la stessa configurazione del server modello che verrà utilizzata in produzione.

A seconda della situazione, gli utenti possono scegliere fino a che punto InfraValidator deve essere identico all'ambiente di produzione. Tecnicamente, un modello può essere convalidato infra in un ambiente Docker locale e quindi servito in un ambiente completamente diverso (es. cluster Kubernetes) senza problemi. Tuttavia, InfraValidator non avrà verificato questa divergenza.

Modalità di funzionamento

A seconda della configurazione, la convalida dell'infrastruttura viene eseguita in una delle seguenti modalità:

  • LOAD_ONLY modalità: verificare se il modello è stato caricato con successo nell'infrastruttura servire o meno. O
  • LOAD_AND_QUERY modalità: LOAD_ONLY modalità più l'invio di alcune richieste di campioni per controllare se il modello è in grado di servire inferenze. InfraValidator non si preoccupa che la previsione fosse corretta o meno. Conta solo se la richiesta è andata a buon fine o meno.

Come lo uso?

Di solito InfraValidator viene definito accanto a un componente Evaluator e il suo output viene inviato a un Pusher. Se InfraValidator fallisce, il modello non verrà inviato.

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(...)
)

Configurazione di un componente InfraValidator.

Esistono tre tipi di prototipi per configurare InfraValidator.

ServingSpec

ServingSpec è la configurazione più cruciale per l'InfraValidator. Definisce:

  • il tipo di server modello da corsa
  • dove per eseguirlo

Per i tipi di server modello (chiamati binari di servizio) supportiamo

Attualmente sono supportate le seguenti piattaforme di servizio:

  • Local Docker (Docker dovrebbe essere installato in anticipo)
  • Kubernetes (supporto limitato solo per KubeflowDagRunner)

La scelta per servire binario e servire piattaforma sono realizzati specificando un oneof blocchi del ServingSpec . Ad esempio utilizzare tensorflow Serving esecuzione binaria nel cluster kubernetes, tensorflow_serving e kubernetes campo dovrebbe essere impostato.

infra_validator=InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=tfx.proto.ServingSpec(
        tensorflow_serving=tfx.proto.TensorFlowServing(
            tags=['latest']
        ),
        kubernetes=tfx.proto.KubernetesConfig()
    )
)

Per ulteriori configurare ServingSpec , si prega di consultare la definizione di protobuf .

ValidationSpec

Configurazione facoltativa per regolare i criteri di convalida dell'infrastruttura o il flusso di lavoro.

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
    )
)

Tutti i campi ValidationSpec hanno un valore predefinito sonoro. Controllare più in dettaglio dalla definizione di protobuf .

RequestSpec

Configurazione opzionale per specificare come costruire richieste di campioni quando si esegue la convalida infra in LOAD_AND_QUERY modalità. Per poter utilizzare LOAD_AND_QUERY modalità, è necessario specificare sia request_spec proprietà di esecuzione nonché examples canale di ingresso nella definizione del componente.

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.
    )
)

Produzione di un modello salvato con il riscaldamento

(Dalla versione 0.30.0)

Dal momento che il modello InfraValidator Convalida con le richieste reali, si può facilmente riutilizzare queste richieste di validazione come le richieste di riscaldamento e di un SavedModel. InfraValidator fornisce un'opzione ( RequestSpec.make_warmup ) per esportare un SavedModel con riscaldamento.

infra_validator = InfraValidator(
    ...,
    request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)

Poi l'uscita InfraBlessing artefatto conterrà una SavedModel con riscaldamento, e può anche essere spinto dalla Pusher , proprio come Model artefatto.

Limitazioni

L'attuale InfraValidator non è ancora completo e presenta alcune limitazioni.

  • Solo tensorflow SavedModel formato modello può essere convalidato.
  • Quando si esegue TFX sul kubernetes, il gasdotto dovrebbe essere eseguito da KubeflowDagRunner all'interno Kubeflow Condotte. Il server modello verrà avviato nello stesso cluster Kubernetes e nello spazio dei nomi utilizzato da Kubeflow.
  • InfraValidator si concentra principalmente sulla implementazioni a tensorflow di servizio , e mentre ancora utile è meno accurata per le distribuzioni a tensorflow Lite e TensorFlow.js , o di altre misure di inferenza.
  • C'è un supporto limitato su LOAD_AND_QUERY modalità per la Predict firma del metodo (che è l'unico metodo esportabile in tensorflow 2). InfraValidator richiede la firma Prevedere di consumare un serializzato tf.Example come unico ingresso.

    @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'))
    })
    
    • Guarda un esempio Penguin codice di esempio per vedere come questa firma interagisce con altri componenti TFX.