Configuración de servicio de Tensorflow

En esta guía, repasaremos los numerosos puntos de configuración de 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 modelo

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

Puede proporcionar este archivo de configuración usando el indicador --model_config_file e indicarle a Tensorflow Serving que sondee periódicamente las versiones actualizadas de este archivo de configuración en la ruta especificada configurando el indicador --model_config_file_poll_wait_seconds .

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

Recargar la configuración del servidor de modelos

Hay dos formas de recargar la configuración de Model Server:

  • Configurando el indicador --model_config_file_poll_wait_seconds para indicarle al servidor que verifique periódicamente si hay un nuevo archivo de configuración en la ruta del archivo --model_config_file .

  • Emitiendo llamadas RPC HandleReloadConfigRequest al servidor y proporcionando una nueva configuración de Model Server mediante programación.

Tenga en cuenta que cada vez que el servidor carga el nuevo archivo de configuración, actuará para realizar el contenido de la nueva configuración especificada y solo la nueva configuración especificada. 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 del servidor modelo

El archivo de configuración de Model Server proporcionado debe ser un búfer de protocolo ModelServerConfig .

Para todos los casos de uso excepto los más avanzados, querrás usar la opción ModelConfigList, que es una lista de buffers del protocolo ModelConfig . Aquí hay un ejemplo básico, antes de profundizar 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 que se entregará, incluido su nombre y la ruta donde el Model Server 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.

Sirviendo una versión específica de un modelo

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

model_version_policy {
  specific {
    versions: 42
  }
}

Esta opción es útil para volver a una versión buena, en caso de que se descubra un problema con las últimas versiones.

Sirviendo múltiples versiones de un modelo

Para ofrecer múltiples versiones del modelo simultáneamente, por ejemplo, para permitir el almacenamiento de una nueva versión tentativa con una porción de tráfico, establezca model_version_policy en "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 del modelo para simplificar Canary y Rollback

A veces resulta útil agregar un nivel de indirección a las versiones del modelo. En lugar de informar a todos sus clientes que deberían consultar la versión 42, puede asignar un alias como "estable" a cualquier versión que los clientes deban consultar actualmente. Si desea redirigir una porción del tráfico a una versión provisional del modelo canario, puede utilizar un segundo alias "canario".

Puede configurar estos alias o etiquetas de versión del 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 sus consultas a uno de "estable" o "canario". (quizás basado en el hash de la identificación del usuario) usando el campo version_label del búfer del protocolo ModelSpec y avanza la etiqueta en el servidor sin notificar a los clientes. Una vez que haya terminado de canarying 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 solo se pueden asignar a versiones de modelos que ya están cargadas y disponibles para su publicación. Una vez que una versión del modelo esté disponible, se puede recargar la configuración del modelo sobre la marcha para asignarle una etiqueta. Esto se puede lograr usando un RPC HandleReloadConfigRequest o si el servidor está configurado para sondear periódicamente el sistema de archivos en busca del archivo de configuración, como se describe anteriormente .

Si desea asignar una etiqueta a una versión que aún no está cargada (por ejemplo, proporcionando tanto la versión del modelo como la etiqueta en el momento del inicio), debe establecer el indicador --allow_version_labels_for_unavailable_models en verdadero, lo que permite que se agreguen nuevas etiquetas. asignarse a versiones de modelo que aún no están cargadas.

Tenga en cuenta que esto se aplica sólo a las etiquetas de nuevas versiones (es decir, aquellas 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 que apunta 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 DESCANSO

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

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

Tenga en cuenta que la etiqueta de versión está restringida a una secuencia de caracteres de Word, compuesta de caracteres alfanuméricos y guiones bajos (es decir [a-zA-Z0-9_]+ ).

Configuración de monitoreo

Puede proporcionar una configuración de monitoreo al servidor usando el indicador --monitoring_config_file para especificar un archivo que contiene un búfer del protocolo MonitoringConfig . He aquí un ejemplo:

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

Para leer las métricas de la URL de monitoreo anterior, primero debe habilitar el servidor HTTP configurando el indicador --rest_api_port . Luego puede configurar su servidor Prometheus para extraer métricas de Model Server pasándole los valores de --rest_api_port y path .

Tensorflow Serving recopila todas las métricas capturadas por Serving y por Tensorflow principal.

Configuración por lotes

Model Server tiene la capacidad de procesar solicitudes por lotes en una variedad de configuraciones para lograr un mejor rendimiento. La programación de este procesamiento por lotes se realiza globalmente para todos los modelos y versiones de modelos en el servidor para garantizar la mejor utilización posible de los recursos subyacentes, sin importar cuántos modelos o versiones de modelos estén siendo atendidos actualmente por el servidor ( más detalles ). Puede habilitar este comportamiento configurando el indicador --enable_batching y controlarlo pasando una configuración al indicador --batching_parameters_file .

Archivo de parámetros de procesamiento por lotes de ejemplo:

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

Consulte la guía de procesamiento por lotes para obtener una discusión detallada y consulte la sección sobre parámetros para comprender cómo configurar los parámetros.

Banderas varias

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

  • --port : puerto para escuchar la API de gRPC
  • --rest_api_port : Puerto para escuchar la API HTTP/REST
  • --rest_api_timeout_in_ms : Tiempo de espera para llamadas API HTTP/REST
  • --file_system_poll_wait_seconds : El período con el que el servidor sondea el sistema de archivos en busca de nuevas versiones de modelo en la respectiva ruta_base_modelo de cada modelo.
  • --enable_model_warmup : habilita el calentamiento del modelo utilizando PredictionLogs proporcionados por el usuario en el directorio activos.extra/
  • --mixed_precision=bfloat16 : habilita la precisión mixta automática BF16