InfraValidator es un componente TFX que se utiliza como una capa de alerta temprana antes de enviar un modelo a producción. El nombre de validador "infra" proviene del hecho de que está validando el modelo en el modelo real que sirve a la "infraestructura". Si Evaluador es garantizar el funcionamiento del modelo, InfraValidator es garantizar el modelo es mecánicamente muy bien y evita malos modelos de ser empujado.
¿Como funciona?
InfraValidator toma el modelo, inicia un servidor de modelo en espacio aislado con el modelo y ve si se puede cargar correctamente y, opcionalmente, consultar. El resultado de la validación infra se generará en la blessing de salida de la misma manera como evaluador hace.
InfraValidator se centra en la compatibilidad entre el binario del servidor modelo (por ejemplo TensorFlow Sirviendo ) y el modelo de implementar. A pesar del nombre validador "infra", es responsabilidad del usuario para configurar el entorno correctamente, y validadores infra sólo interactúa con el servidor de modelo en el entorno configurado por el usuario para ver si funciona bien. La configuración correcta de este entorno garantizará que la aprobación o el fracaso de la validación de infraestructura sea indicativo de si el modelo se puede servir en el entorno de servicio de producción. Esto implica algo de, pero no se limita a, lo siguiente:
- InfraValidator está utilizando el mismo binario de servidor modelo que se utilizará en producción. Este es el nivel mínimo al que debe converger el entorno de validación de infraestructura.
- InfraValidator utiliza los mismos recursos (por ejemplo, cantidad de asignación y tipo de CPU, memoria y aceleradores) que se utilizarán en producción.
- InfraValidator utiliza la misma configuración de servidor modelo que se utilizará en producción.
Según la situación, los usuarios pueden elegir hasta qué punto InfraValidator debe ser idéntico al entorno de producción. Técnicamente, un modelo se puede validar por infraestructura en un entorno Docker local y luego servir en un entorno completamente diferente (por ejemplo, un clúster de Kubernetes) sin ningún problema. Sin embargo, InfraValidator no habrá verificado esta divergencia.
Modo de operación
Dependiendo de la configuración, la validación de infraestructura se realiza en uno de los siguientes modos:
-
LOAD_ONLYmodo: comprobar si el modelo se ha cargado correctamente en la infraestructura que sirve o no. O -
LOAD_AND_QUERYmodo:LOAD_ONLYmodo además el envío de algunas solicitudes de muestras para comprobar si el modelo es capaz de servir inferencias. A InfraValidator no le importa si la predicción fue correcta o no. Solo importa si la solicitud fue exitosa o no.
¿Como lo uso?
Por lo general, InfraValidator se define junto a un componente Evaluator y su salida se envía a un Pusher. Si falla InfraValidator, el modelo no se enviará.
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(...)
)
Configuración de un componente InfraValidator.
Hay tres tipos de prototipos para configurar InfraValidator.
ServingSpec
ServingSpec es la configuración más crucial para el InfraValidator. Se define:
- qué tipo de servidor de modelo para una ejecución
- donde para ejecutarlo
Para tipos de servidores modelo (llamados servidores binarios) admitimos
Actualmente se admiten las siguientes plataformas de servicio:
- Docker local (Docker debe instalarse con antelación)
- Kubernetes (soporte limitado solo para KubeflowDagRunner)
La elección para servir binario y sirviendo plataforma se hacen mediante la especificación de un oneof de bloques de la ServingSpec . Por ejemplo, para utilizar TensorFlow Sirviendo funcionamiento binario en el clúster Kubernetes, tensorflow_serving y kubernetes campo se debe ajustar.
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(
tensorflow_serving=tfx.proto.TensorFlowServing(
tags=['latest']
),
kubernetes=tfx.proto.KubernetesConfig()
)
)
Para seguir configurando ServingSpec , por favor echa un vistazo a la definición protobuf .
ValidationSpec
Configuración opcional para ajustar los criterios de validación de infraestructura o el flujo de trabajo.
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
)
)
Todos los campos ValidationSpec tienen un valor predeterminado de sonido. Compruebe más detalle de la definición protobuf .
RequestSpec
Configuración opcional para especificar cómo construir solicitudes de muestras cuando se ejecuta la validación infra en LOAD_AND_QUERY modo. Para utilizar LOAD_AND_QUERY modo, se requiere para especificar ambas request_spec propiedades de ejecución, así como examples canal de entrada en la definición 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.
)
)
Producción de un modelo guardado con calentamiento
(A partir de la versión 0.30.0)
Dado que el modelo InfraValidator valida con las peticiones reales, se puede reutilizar fácilmente estas solicitudes de validación como solicitudes de preparación de un SavedModel. InfraValidator ofrece una opción ( RequestSpec.make_warmup ) exportar un SavedModel con calentamiento.
infra_validator = InfraValidator(
...,
request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)
Entonces la salida InfraBlessing artefacto contendrá un SavedModel con calentamiento, y también puede ser empujado por el empujador , al igual Model artefacto.
Limitaciones
El InfraValidator actual aún no está completo y tiene algunas limitaciones.
- Sólo TensorFlow SavedModel formato de modelo puede ser validada.
- Cuando se ejecuta el TFX Kubernetes, la tubería debe ser ejecutado por
KubeflowDagRunnerdentro Kubeflow tuberías. El servidor modelo se lanzará en el mismo clúster de Kubernetes y el espacio de nombres que utiliza Kubeflow. - InfraValidator se centra principalmente en los despliegues a TensorFlow que sirven , y al mismo tiempo útil que es menos precisa para despliegues a TensorFlow Lite y TensorFlow.js otros marcos de inferencia, o.
Hay un apoyo limitado en
LOAD_AND_QUERYmodo para la Predecir firma del método (que es el único método exportable en TensorFlow 2). InfraValidator requiere la firma Predecir consumir una serializadotf.Examplecomo la única entrada.@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')) })- Echa un vistazo a un ejemplo Pingüino código de ejemplo para ver cómo esta firma interactúa con otros componentes en TFX.