Configuración de publicación de Tensorflow

En esta guía, repasaremos los numerosos puntos de configuración para Tensorflow Serving.

Descripción general

Si bien la mayoría de las configuraciones se relacionan con Model Server, hay muchas formas de especificar el comportamiento de Tensorflow Serving:

Configuración del servidor de modelos

La forma más fácil de servir a un modelo es proporcionar los --model_name y --model_base_path banderas (o poner la MODEL_NAME variable de entorno si se utiliza estibador). Sin embargo, si desea servir varios modelos o configurar opciones como la frecuencia de sondeo para nuevas versiones, puede hacerlo escribiendo un archivo de configuración de Model Server.

Usted puede proporcionar este archivo de configuración utilizando el --model_config_file bandera e instruir a Tensorflow Sirviendo a sondear periódicamente versiones actualizadas de este archivo de configuración en el camino specifed estableciendo el --model_config_file_poll_wait_seconds bandera.

Ejemplo usando Docker:

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

Recarga de la configuración del servidor de modelos

Hay dos formas de volver a cargar la configuración de Model Server:

  • Al establecer el --model_config_file_poll_wait_seconds bandera para indicar al servidor para comprobar periódicamente si hay un nuevo archivo de configuración en --model_config_file ruta de archivo.

  • Mediante la emisión de HandleReloadConfigRequest llamadas RPC al servidor y el suministro de una nueva configuración Modelo de servidor mediante programación.

Tenga en cuenta que cada vez que el servidor carga el nuevo archivo de configuración, que actuará a darse cuenta del contenido de la nueva configuración especificada y sólo la nueva configuración especificado. Esto significa que si el modelo A estaba presente en el primer archivo de configuración, que se reemplaza con un archivo que contiene solo el modelo B, el servidor cargará el modelo B y descargará el modelo A.

Detalles de configuración de Model Server

El archivo de configuración del servidor de modelo proporcionado debe ser un ModelServerConfig búfer de protocolo .

Para todos excepto los más avanzados casos de uso, tendrá que utilizar la opción ModelConfigList, que es una lista de ModelConfig búferes de protocolo. Aquí hay un ejemplo básico, antes de sumergirnos en las opciones avanzadas a continuación.

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

Configurar un modelo

Cada ModelConfig especifica un modelo a servir, incluido su nombre y la ruta donde el servidor de modelos debe buscar versiones del modelo para servir, como se ve en el ejemplo anterior. De forma predeterminada, el servidor ofrecerá la versión con el número de versión más grande. Este valor predeterminado se puede anular cambiando el campo model_version_policy.

Entrega de una versión específica de un modelo

Para publicar una versión específica del modelo, en lugar de pasar siempre a la que tiene el número de versión más grande, configure model_version_policy como "específico" y proporcione el número de versión que le gustaría publicar. Por ejemplo, para fijar la versión 42 como la que se va a publicar:

model_version_policy {
  specific {
    versions: 42
  }
}

Esta opción es útil para revertir a una versión buena conocida, en caso de que se descubra un problema con la (s) última (s) versión (s).

Sirviendo múltiples versiones de un modelo

Para servir múltiples versiones del modelo simultáneamente, por ejemplo, para habilitar la conversión de una nueva versión tentativa con una porción de tráfico, configure model_version_policy como "específico" y proporcione múltiples números de versión. Por ejemplo, para servir las versiones 42 y 43:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

Asignación de etiquetas de cadena a versiones de modelos para simplificar Canary y Rollback

A veces es útil agregar un nivel de direccionamiento indirecto a las versiones del modelo. En lugar de dejar que todos sus clientes sepan que deberían consultar la versión 42, puede asignar un alias como "estable" a la versión que los clientes deberían consultar actualmente. Si desea redirigir una parte del tráfico a una versión tentativa del modelo canary, puede utilizar un segundo alias "canary".

Puede configurar estos alias o etiquetas de versión de modelo, así:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

En el ejemplo anterior, está sirviendo las versiones 42 y 43, y asociando la etiqueta "estable" con la versión 42 y la etiqueta "canario" con la versión 43. Puede hacer que sus clientes dirijan las consultas a uno de "estable" o "canario" (quizás basado en hash del identificador de usuario) utilizando el campo de la version_label ModelSpec búfer de protocolo, y avanzar la etiqueta en el servidor sin notificar a los clientes. Una vez que haya terminado de cambiar la versión 43 y esté listo para promoverla a estable, puede actualizar la configuración a:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

Si posteriormente necesita realizar una reversión, puede volver a la configuración anterior que tiene la versión 42 como "estable". De lo contrario, puede avanzar descargando la versión 42 y cargando la nueva versión 44 cuando esté lista, y luego avanzando la etiqueta canary a 44, y así sucesivamente.

Tenga en cuenta que las etiquetas sólo se pueden asignar a las versiones de modelos que ya están cargados y disponibles para servir. Una vez que la versión del modelo está disponible, se puede volver a cargar la configuración del modelo sobre la marcha para asignarle una etiqueta. Esto se puede lograr usando un HandleReloadConfigRequest RPC o si el servidor está configurado para sondear periódicamente el sistema de ficheros para el fichero de configuración, tal como se describe anteriormente .

Si desea asignar una etiqueta a una versión que aún no se carga (por ej. Mediante el suministro tanto de la versión del modelo y la etiqueta en tiempo de inicio), entonces debe establecer el --allow_version_labels_for_unavailable_models marca como true, lo que permite a las nuevas etiquetas asignarse a versiones de modelo que aún no están cargadas.

Tenga en cuenta que esto se aplica solo a las etiquetas de la nueva versión (es decir, las que no están asignadas a una versión actualmente). Esto es para garantizar que durante los cambios de versión, el servidor no asigne prematuramente la etiqueta a la nueva versión, descartando así todas las solicitudes destinadas a esa etiqueta mientras se carga la nueva versión.

Para cumplir con esta verificación de seguridad, si reasigna una etiqueta de versión que ya está en uso, debe asignarla solo a las versiones ya cargadas. Por ejemplo, si desea mover una etiqueta de apuntar a la versión N a la versión N + 1, primero puede enviar una configuración que contenga la versión N y N + 1, y luego enviar una configuración que contenga la versión N + 1, la etiqueta apuntando a N + 1 y sin versión N.

Uso de REST

Si está utilizando la superficie de la API REST para realizar solicitudes de inferencia, en lugar de utilizar

/v1/models/<model name>/versions/<version number>

simplemente solicite una versión usando una etiqueta estructurando su ruta de solicitud de esta manera

/v1/models/<model name>/labels/<version label> .

Nota que etiqueta de versión se limita a una secuencia de caracteres de palabra, compuesta de caracteres y guiones alphanumeral (es decir, [a-zA-Z0-9_]+ ).

Configuración de monitoreo

Es posible proporcionar una configuración de supervisión para el servidor utilizando la --monitoring_config_file bandera para especificar un archivo que contiene una MonitoringConfig búfer de protocolo. He aquí un ejemplo:

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

Para leer las métricas de lo anterior el seguimiento de URL, primero tiene que activar el servidor HTTP mediante el establecimiento de la --rest_api_port bandera. A continuación, puede configurar el servidor de Prometeo a las métricas de extracción de modelo de servidor de pasándolo a los valores de --rest_api_port y path .

Tensorflow Serving recopila todas las métricas capturadas por Serving, así como el núcleo de Tensorflow.

Configuración de lotes

Model Server tiene la capacidad de realizar solicitudes por lotes en una variedad de configuraciones para lograr un mejor rendimiento. La programación de esta dosificación se realiza a nivel mundial para todos los modelos y versiones de modelo en el servidor para asegurar la mejor utilización posible de los recursos subyacentes no importa cuántos modelos o versiones de modelo actualmente están siendo servido por el servidor ( más detalles ). Es posible habilitar este comportamiento estableciendo la --enable_batching bandera y controlarlo mediante el paso de una configuración a la --batching_parameters_file bandera.

Ejemplo de archivo de parámetros de procesamiento por lotes:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

Por favor refiérase a la guía de procesamiento por lotes para una discusión en profundidad y consulte la sección de parámetros para entender cómo configurar los parámetros.

Banderas misceláneas

Además de las banderas cubiertas hasta ahora en la guía, aquí enumeramos algunas otras notables. Para una lista completa, consulte el código fuente .

  • --port : Puerto a la escucha para las API GRPC
  • --rest_api_port : Puerto a la escucha para las API HTTP / REST
  • --rest_api_timeout_in_ms : Tiempo de espera de llamadas a la API HTTP / REST
  • --file_system_poll_wait_seconds : El período con el que las encuestas de servidor del sistema de archivos para las nuevas versiones de modelo en model_base_path respectiva de cada modelo
  • --enable_model_warmup : Activa modelo de calentamiento usando PredictionLogs proporcionados por el usuario en assets.extra / directorio