Sintonizar con las primeras mujeres en ML Simposio este martes, 19 de octubre a 09 a.m. PST Registrar ahora

El componente de canalización InfraValidator TFX

InfraValidator es un componente TFX que se utiliza como una capa de alerta temprana antes de llevar 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, lanza un servidor de modelos en caja de arena 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 asegurará que la validación de infra que pase o falle sea indicativo de si el modelo podría ser útil en el entorno de servicio de producción. Esto implica algunos de, entre otros, los siguientes:

  1. InfraValidator está utilizando el mismo modelo binario de servidor que se utilizará en producción. Este es el nivel mínimo al que debe converger el entorno de infravalidación.
  2. InfraValidator está usando los mismos recursos (por ejemplo, cantidad de asignación y tipo de CPU, memoria y aceleradores) que se usarán en producción.
  3. InfraValidator está utilizando la misma configuración de servidor modelo que se utilizará en producción.

Dependiendo de la situación, los usuarios pueden elegir hasta qué punto InfraValidator debe ser idéntico al entorno de producción. Técnicamente, un modelo puede ser infravalidado en un entorno Docker local y luego servido 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 infra se realiza en uno de los siguientes modos:

  • LOAD_ONLY modo: comprobar si el modelo se ha cargado correctamente en la infraestructura que sirve o no. O
  • LOAD_AND_QUERY modo: LOAD_ONLY modo 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 que la predicción sea 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 InfraValidator falla, 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 protos 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 los tipos de servidor modelo (llamado servidor binario) admitimos

Actualmente se admiten las siguientes plataformas de servicio:

  • Local Docker (Docker debe instalarse de antemano)
  • 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 infra o 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 sólido. 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.
    )
)

Producir un modelo guardado con calentamiento

(Desde 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 KubeflowDagRunner dentro Kubeflow tuberías. El servidor modelo se lanzará en el mismo clúster de Kubernetes y en el espacio de nombres que usa 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_QUERY modo para la Predecir firma del método (que es el único método exportable en TensorFlow 2). InfraValidator requiere la firma Predecir consumir una serializado tf.Example como 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.