InfraValidator è un componente TFX utilizzato come livello di allarme preventivo prima di mettere in produzione un modello. Il nome validatore "infra" deriva dal fatto che sta convalidando il modello nel modello reale che serve "infrastruttura". Se Evaluator deve garantire le prestazioni del modello, InfraValidator deve garantire che il modello sia meccanicamente corretto e impedisca l'invio di modelli errati.
Come funziona?
InfraValidator prende il modello, avvia un server modello sandbox con il modello e verifica se può essere caricato correttamente e, facoltativamente, interrogato. Il risultato dell'infra validazione verrà generato nell'output blessing allo stesso modo di Evaluator .
InfraValidator si concentra sulla compatibilità tra il modello binario del server (ad esempio TensorFlow Serving ) e il modello da distribuire. Nonostante il nome validatore "infra", è responsabilità dell'utente configurare correttamente l'ambiente e il validatore infra interagisce solo con il server modello nell'ambiente configurato dall'utente per vedere se funziona correttamente. La corretta configurazione di questo ambiente garantirà che il superamento o il fallimento della convalida infra indicherà se il modello sarà utilizzabile nell'ambiente di produzione. Ciò implica alcuni dei seguenti, ma non è limitato a:
- InfraValidator utilizza lo stesso modello binario del server che verrà utilizzato nella produzione. Questo è il livello minimo al quale deve convergere l'ambiente di infra validazione.
- InfraValidator utilizza le stesse risorse (ad esempio, quantità allocata e tipo di CPU, memoria e acceleratori) che verranno utilizzate nella produzione.
- InfraValidator utilizza la stessa configurazione del server modello che verrà utilizzata nella produzione.
A seconda della situazione, gli utenti possono scegliere in che misura InfraValidator deve essere identico all'ambiente di produzione. Tecnicamente, un modello può essere validato infra in un ambiente Docker locale e poi servito in un ambiente completamente diverso (ad esempio cluster Kubernetes) senza problemi. Tuttavia, InfraValidator non avrà verificato questa divergenza.
Modalità operativa
A seconda della configurazione, la convalida infra viene eseguita in una delle seguenti modalità:
- Modalità
LOAD_ONLY: verifica se il modello è stato caricato correttamente nell'infrastruttura servente o meno. O - Modalità
LOAD_AND_QUERY: modalitàLOAD_ONLYoltre all'invio di alcune richieste di esempio per verificare se il modello è in grado di fornire inferenze. A InfraValidator non interessa che la previsione fosse corretta o meno. Importa solo se la richiesta ha avuto successo o meno.
Come lo uso?
Di solito InfraValidator è 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 protocolli per configurare InfraValidator.
ServingSpec
ServingSpec è la configurazione più importante per InfraValidator. Definisce:
- che tipo di server modello eseguire
- dove eseguirlo
Per i tipi di server modello (detti binari di servizio) supportiamo
Sono attualmente supportate le seguenti piattaforme di servizio:
- Docker locale (Docker deve essere installato in anticipo)
- Kubernetes (supporto limitato solo per KubeflowDagRunner)
La scelta del binario di servizio e della piattaforma di servizio viene effettuata specificando un blocco oneof di ServingSpec . Ad esempio, per utilizzare il binario TensorFlow Serving in esecuzione sul cluster Kubernetes, è necessario impostare tensorflow_serving e il campo kubernetes .
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(
tensorflow_serving=tfx.proto.TensorFlowServing(
tags=['latest']
),
kubernetes=tfx.proto.KubernetesConfig()
)
)
Per configurare ulteriormente ServingSpec , controlla la definizione del protobuf .
ValidationSpec
Configurazione facoltativa per regolare i criteri di convalida infra 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. Controlla maggiori dettagli dalla definizione di protobuf .
RequestSpec
Configurazione facoltativa per specificare come creare richieste di esempio durante l'esecuzione della convalida infra in modalità LOAD_AND_QUERY . Per utilizzare la modalità LOAD_AND_QUERY , è necessario specificare sia le proprietà di esecuzione request_spec sia il canale di input examples 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)
Poiché InfraValidator convalida il modello con richieste reali, può facilmente riutilizzare queste richieste di convalida come richieste di riscaldamento di un SavedModel. InfraValidator fornisce un'opzione ( RequestSpec.make_warmup ) per esportare un SavedModel con il riscaldamento.
infra_validator = InfraValidator(
...,
request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)
Quindi l'artefatto InfraBlessing di output conterrà un SavedModel con riscaldamento e potrà anche essere inviato dal Pusher , proprio come l'artefatto Model .
Limitazioni
L'attuale InfraValidator non è ancora completo e presenta alcune limitazioni.
- È possibile convalidare solo il formato del modello TensorFlow SavedModel .
- Quando si esegue TFX su Kubernetes, la pipeline deve essere eseguita da
KubeflowDagRunnerall'interno di Kubeflow Pipelines. Il server modello verrà avviato nello stesso cluster Kubernetes e nello stesso spazio dei nomi utilizzato da Kubeflow. - InfraValidator si concentra principalmente sulle distribuzioni su TensorFlow Serving e, sebbene sia comunque utile, è meno accurato per le distribuzioni su TensorFlow Lite e TensorFlow.js o altri framework di inferenza.
Esiste un supporto limitato in modalità
LOAD_AND_QUERYper la firma del metodo Predict (che è l'unico metodo esportabile in TensorFlow 2). InfraValidator richiede che la firma Predict utilizzi untf.Exampleserializzato come unico input.@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')) })- Dai un'occhiata a un codice di esempio di esempio Penguin per vedere come questa firma interagisce con altri componenti in TFX.