AI Platform Prediction: conceptos de contenedores personalizados

En este documento, se analizan los modelos de aprendizaje automático (AA) en Google Cloud mediante contenedores personalizados en AI Platform Prediction.

AI Platform Prediction es la plataforma de entrega del modelo del AA administrado de Google Cloud. Como servicio administrado, la plataforma maneja la configuración, el mantenimiento y la administración de la infraestructura. AI Platform Prediction admite la inferencia de CPU y GPU, y ofrece una selección de formas de nodo n1-standard en Compute Engine, lo que te permite personalizar la unidad de escalamiento para adaptarla a tus requisitos.

El servicio AI Platform Prediction simplifica el servicio de modelos porque requiere que especifiques solo dónde almacenas los artefactos de tu modelo. Sin embargo, con esta simplicidad, se reduce la flexibilidad. Por ejemplo, solo puedes entregar frameworks incorporados en el servicio. Con contenedores personalizados, AI Platform Prediction reduce el nivel de abstracción para que puedas elegir el framework, el servidor de modelos, el procesamiento previo y el procesamiento posterior que necesites.

Este documento forma parte de una serie dirigida a ingenieros y arquitectos de AA que diseñan, compilan y mantienen una plataforma de entrega de modelos de alto rendimiento en Google Cloud:

En este documento, se analizan las opciones de entrega de modelos con un enfoque en los contenedores personalizados en AI Platform Prediction. El documento asociado se centra en la integración de Triton Inference Server con contenedores personalizados en AI Platform Prediction.

Cuándo usar contenedores personalizados con AI Platform Prediction

Google Cloud ofrece varias opciones para entregar modelos de AA. Para ayudarte a elegir qué plataforma se adapta mejor a tus necesidades de predicción, la siguiente tabla proporciona opciones comunes que se basan en varios requisitos:

Necesidades de predicción AI Platform Prediction básico Contenedores personalizados de AI Platform Prediction Google Kubernetes Engine (GKE) Dataflow (se usa como canalización de predicción)
Un servicio de predicción de modelos administrados No
Predicción síncrona de latencia baja No
Análisis de transmisiones asíncronas No No No
Predicción por lotes Según el servidor de modelos
Compatibilidad integrada para frameworks TensorFlow, scikit-learn, XGBoost Ninguno, usuario alojado en contenedor Ninguno, usuario alojado en contenedor Usuario cargado
Compatibilidad con servidores de modelos de terceros No Usuario alojado en contenedor Usuario alojado en contenedor No aplicable
La elección del tipo de máquina del nodo mls1 y n1-standard n1-standard Cualquiera que sea compatible con GKE Cualquiera que sea compatible con Dataflow
Asistencia de GPU
Procesamiento personalizado externo al servidor de modelos Rutinas de predicción personalizadas No aplicable

En las siguientes secciones, se proporcionan más detalles para ayudarte a evaluar tus opciones.

Activación

Es importante considerar cómo se consume un modelo después de que se entrega. Las aplicaciones, como el riesgo de transacciones y la entrega de anuncios, en general, llaman a la predicción síncrona en línea y son sensibles a la latencia. Por lo general, las recomendaciones y las predicciones del valor del ciclo de vida del cliente (CLV) se procesan de manera más efectiva en lotes periódicos grandes. Por lo general, los casos de uso del mantenimiento predictivo transmiten la telemetría de manera asíncrona. En estos casos, se usa un modelo para identificar las condiciones de fallas, y el consumidor de las predicciones puede ser una aplicación de agregación que no sea el remitente de la telemetría. La elección de una plataforma de entrega depende de cómo se consume tu modelo.

Asistencia de Compute

AI Platform Prediction básica admite tipos de máquinas mls1 y n1-standard, mientras que los contenedores personalizados en AI Platform Prediction admiten tipos de máquinas n1-standard. Para obtener el mejor rendimiento, considera solo los tipos de máquina n1-standard.

Si no tienes inconvenientes en administrar una plataforma de predicción en el nivel de infraestructura, y tus aplicaciones no tienen estado y están diseñadas para reintentos en solicitudes perdidas, puedes usar GKE con nodos interrumpibles. Los nodos interrumpibles pueden ayudarte a reducir los costos de procesamiento. Sin embargo, necesitas saber que los nodos interrumpibles solo duran hasta 24 horas. Si planeas usar nodos interrumpibles en producción, solo debes implementar cargas de trabajo que toleren que los nodos desaparezcan. Los trabajos sin conexión que se pueden reiniciar con puntos de control son ideales para los nodos interrumpibles.

Servidores de modelos de terceros

Si necesitas un servidor de modelos personalizado, como Triton Inference Server o Facebook TorchServe, debes elegir una plataforma de predicción que pueda entregar directamente desde un contenedor o cargar servidores de modelos personalizados.

Compatibilidad integrada para frameworks

AI Platform Prediction es un servicio de predicción administrado que admite de forma directa TensorFlow, XGBoost y scikit-learn. Recomendamos AI Platform Prediction básico si los frameworks y las versiones del frameworks compatibles pueden entregar tu modelo directamente.

Procesamiento previo y posterior de los datos

Cuando implementas un modelo para la predicción, la forma de los datos rara vez es la misma que la forma de los datos que se usaron para entrenar el modelo. Esta dinámica, que se conoce como desviación entre el entrenamiento y la entrega, requiere que proceses tus datos antes de que el modelo pueda procesar solicitudes de predicción. Los resultados previstos también se suelen usar con algún tipo de procesamiento posterior. Si es posible, te recomendamos que agregues las operaciones de procesamiento a tu modelo. Los frameworks, como TensorFlow, te permiten agregar operaciones al grafo de entrega, lo que no solo simplifica el entorno, sino que también aumenta su rendimiento porque se reducen los saltos.

A veces, no puedes incorporar el procesamiento en el grafo del modelo. Por ejemplo, es posible que uses el procesamiento previo con XGBoost, o tu procesamiento previo es un modelo que se entrena en PyTorch, pero tu clasificador es un modelo que está entrenado en TensorFlow. Aunque las rutinas de predicción personalizadas en AI Platform Prediction te permiten incorporar este tipo de código de procesamiento previo, recomendamos que uses contenedores personalizados por motivos de rendimiento. Las rutinas de predicción personalizadas no solo agregan un salto adicional, el nodo adicional es el tipo mls1 de menor rendimiento.

Arquitectura para contenedores personalizados en AI Platform Prediction

En el siguiente diagrama, se ilustran los componentes principales de los contenedores personalizados en AI Platform Prediction:

Los componentes principales incluyen la imagen del contenedor, cualquier código de procesamiento previo o posterior, el modelo y el almacén de modelos.

En las siguientes secciones, se explican los conceptos importantes del diagrama anterior.

Imagen base

Proporcionas una imagen de contenedor personalizada (A) que es una imagen base de un servidor de modelos o una imagen derivada de la imagen base de un servidor de modelos. En el ejemplo que se proporciona en AI Platform Prediction: configuración directa del servidor de modelos para NVIDIA Triton Inference Server, el servidor de modelos es Triton Inference Server.

Código de procesamiento previo y procesamiento posterior

Si se requiere algún código especial (B), como enrutamiento o procesamiento personalizado, usa un Dockerfile nuevo para incorporar los artefactos en el contenedor. El código de procesamiento previo detecta solicitudes entrantes, aplica el procesamiento previo y, luego, pasa la solicitud procesada con anterioridad al servidor de modelo. Todo código de procesamiento posterior debe ejecutar y mostrar los resultados al cliente.

Tienda de modelos

En la elección de la ubicación donde se conserva el modelo, tienes dos opciones:

  • Especifica la ruta de acceso a los artefactos del modelo en Cloud Storage. Si el servidor de modelos puede leer directamente desde Cloud Storage, es preferible usar esta opción (C). Te permite implementar una versión nueva del modelo sin necesidad de crear un contenedor nuevo.
  • Copiar los artefactos del modelo directamente en el contenedor. Esta opción (D) es para servidores de modelos que no pueden leer directamente desde Cloud Storage. Esta opción requiere un contenedor nuevo cada vez que implementas una nueva versión del modelo.

Modelo

AI Platform Prediction usa un paradigma arquitectónico basado en modelos y versiones de modelos, en el que el modelo es una agrupación lógica de versiones de modelos. Un uso típico de este paradigma es el entrenamiento continuo. En este caso, las aplicaciones diseñadas para un modelo en particular usan ese modelo, pero adoptan versiones más recientes del modelo cuando se vuelve a entrenar con el tiempo.

Versión de modelo

Una versión del modelo en AI Platform Prediction es una instancia de un modelo entrenado con un conjunto de datos, hiperparámetros y configuración específicos. En AI Platform Prediction, las versiones del modelo se tratan como inmutables. Si necesitas actualizar un modelo (por ejemplo, entrenaste el modelo con un conjunto de datos nuevo), debes crear una versión nueva del modelo y, luego, implementarlo. Las versiones del modelo ayudan a simplificar los lanzamientos de versiones canary. Debido a que las versiones del modelo existen dentro de un modelo, debes crear el modelo antes de crear el modelo de la versión.

Contenedor personalizado

Un contenedor personalizado (E) es una instancia de la versión del modelo. Debes crear el contenedor personalizado a partir de la imagen de contenedor personalizado.

Cliente de inferencia

Después de configurar el servidor de modelos, el cliente de inferencia (F) se comunica con AI Platform Prediction.

Patrones de contenedores personalizados

En esta serie, nos referimos a dos patrones arquitectónicos generales para contenedores personalizados: el patrón del servidor de modelo directo y el servidor de modelo con patrón de objeto de escucha. El patrón del objeto de escucha puede incluir el procesamiento previo y posterior personalizado. Para ayudarte a elegir el patrón de entrega del modelo que mejor se adapte a tus necesidades, en la siguiente tabla se describen algunos casos de uso compatibles con cada patrón:

Necesidades de predicción Servidor directo de modelos Servidor de modelos con objeto de escucha
Implementación simplificada No
Latencia más baja posible Depende del procesamiento
Asistencia para un solo modelo
Pila de varios modelos No
Procesamiento previo y procesamiento complejo que es externo al servidor de modelos No
Opciones de enrutamiento personalizables o múltiples No

En las secciones siguientes, se describen los dos patrones del contenedor.

Servidor directo de modelos

El patrón del servidor de modelos directo ofrece acceso directo de AI Platform al servidor de modelos sin ninguna conexión intermedia, como se muestra en el siguiente diagrama:

El servidor de modelos se almacena en un contenedor personalizado, y se accede a él directamente.

Este patrón es útil cuando necesitas lo siguiente:

  • Una ruta de predicción. Según el servidor de modelos, la compatibilidad con más de un modelo puede requerir varias rutas. Si entregas un solo modelo o si puedes administrar tu servidor de modelos con una sola ruta de predicción, el patrón de servidor de modelos directo es tu mejor opción. Por lo general, ese patrón es el más fácil de configurar.
  • Latencia baja. La comunicación directa entre AI Platform y el servidor de modelos elimina las posibles demoras causadas por un intermediario.
  • La capacidad de encapsular el procesamiento previo y posterior en el modelo. Los frameworks como TensorFlow te permiten agregar operaciones de procesamiento previo y posterior al grafo de procesamiento. Por lo general, este enfoque es la forma más eficaz de controlar el procesamiento previo y posterior, ya que minimizas el ordenamiento de memoria en los procesos. Algunos servidores de modelos, como el Triton Inference Server, ofrecen un modelo de conjunto, en el que el resultado de un modelo puede ser la entrada para otro modelo. Esta capacidad permite el procesamiento previo ascendente y el procesamiento posterior dentro del servidor de modelo.

Servidor de modelos con objeto de escucha

En este patrón, configuras un objeto de escucha entre AI Platform y el servidor de modelos, como se muestra en el siguiente diagrama:

Un contenedor personalizado almacena el servidor de modelos y un objeto de escucha que contiene cualquier código de procesamiento previo o posterior.

Este patrón es útil cuando necesitas controlar lo siguiente:

  • Enrutamiento complejo o pilas de varios modelos. Algunos servidores de modelos admiten varios modelos en la misma instancia y requieren rutas separadas para acceder a los modelos. Para multiplexar la ruta de predicción, por lo general, se requiere un objeto de escucha, con información de ruta de destino incorporada en otro lugar (como el encabezado).
  • Procesamiento previo y posterior complejos. Algunos frameworks que no te permiten incorporar la lógica de procesamiento previo y posterior requieren un procesamiento fuera del proceso de inferencia. Además, puede haber situaciones en las que un paso de procesamiento previo necesite realizar una llamada externa a otro servicio. Estos patrones se vuelven difíciles o imposibles de incluir en un gráfico.
  • Conversión de formato de inferencia. Para admitir los diferentes formatos en varios servidores de modelos, puedes usar un objeto de escucha a fin de realizar la conversión de formato.

Es importante comprender que el objeto de escucha es el intermediario entre el servidor del modelo y AI Platform, por lo que agrega latencia al proceso. El impacto de esta latencia es mayor en un modelo liviano que en un modelo pesado. Por ejemplo, si el tiempo de inferencia para un modelo de aprendizaje profundo pesado es de 50 milisegundos (ms) y agregas 20 ms de procesamiento previo, esos 20 ms aumentan en un 40%. Si agregas los mismos 20 ms a un tiempo de inferencia de 10 ms para un modelo ligero de XGBoost, esos 20 ms equivalen a un aumento del 200%.

Planifica un modelo y una versión del modelo

AI Platform Prediction organiza los artefactos del modelo en una jerarquía de versión del proyecto y modelo. Por ejemplo, una empresa puede tener varios proyectos de Google Cloud. Cada proyecto puede tener varios modelos. Cada modelo puede tener una o más versiones del modelo. Esta estructura se ve de la siguiente manera:

  • Organización de ejemplo
    • Proyecto SalesOps
      • Modelo CustomerPropensity
        • model_version v20201131
        • model_version v20201107
        • model_version v20201009

Para obtener más información sobre modelos y versiones de modelos, consulta Descripción general de la predicción.

Antes de crear una versión del modelo, debes crear un modelo. El siguiente es el formato de la solicitud de REST para crear un modelo:

POST -d "{'name': 'MODEL_NAME'}" \
    ENDPOINT/projects/PROJECT_ID/models/

Esta solicitud contiene los siguientes valores:

  • MODEL_NAME: El nombre del modelo que estás creando, por ejemplo, buyer_recommendation
  • ENDPOINT: El servicio de AI Platform en https://ml.googleapis.com/v1
  • PROJECT_ID: Es el proyecto de Google Cloud en el que deseas crear este modelo.

Puedes crear versiones posteriores del modelo con la siguiente solicitud POST:

POST -d @version_spec.json \
    ENDPOINT/projects/PROJECT_ID/models/MODEL_NAME/versions

Para obtener más información, consulta los comandos de REST en la referencia de AI Platform Prediction.

El siguiente es un archivo version_spec.json de muestra para Triton Inference Server:

{
  "name": "v3",
  "deployment_uri": "gs://model-artifacts-source-location",
  "container": {
    "image": "gcr.io/my_project/triton:20.06",
    "args": ["tritonserver",
             "--model-repository=$AIP_STORAGE_URI"
    ],
    "env": [
    ],
    "ports": [
      { "containerPort": 8000 }
    ]
  },
  "routes": {
    "predict": "/v2/models/$AIP_MODEL_NAME/infer",
    "health": "/v2/models/$AIP_MODEL_NAME"
  },
  "machine_type": "n1-standard4",
  "acceleratorConfig": {
    "count":1,
    "type":"nvidia-tesla-t4"
  },
  "autoScale": {
    "minNodes":1
  }
}

En la siguiente tabla, se describen los elementos de la especificación JSON anterior:

Elemento (* = obligatorio) Descripción
name* El nombre de la versión del modelo.
deployment_uri La ubicación de los modelos en Cloud Storage. Cuando se crea una versión del modelo, AI Platform copia los artefactos de esta ubicación y los pone a disposición mediante la variable de entorno AIP_STORAGE_URI.
container:image* La ruta de acceso a la imagen de contenedor.
container:args El comando y los argumentos que se usan cuando se inicia el contenedor.
container:env Las variables de entorno Estas variables de entorno proporcionadas por el usuario están disponibles para el contenedor en el entorno de ejecución.
container:ports* El puerto de red que AI Platform usa para comunicarse con los contenedores. Si no se especifica un puerto, el puerto predeterminado es 8080.
routes:predict

El extremo del contenedor que usa AI Platform para reenviar las solicitudes de predicción al contenedor. Si este elemento está ausente, el extremo enruta de forma predeterminada al siguiente:

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME:predict

routes:health

La ruta del extremo del contenedor que AI Platform usa para verificar el estado del contenedor de la versión del modelo. Solo después de una respuesta exitosa, un código de estado HTTP 200 del contenedor con HTTP GET, el tráfico se dirige a esta instancia de la versión del modelo. Si no se especifica este elemento, la ruta de extremo se establece de forma predeterminada en lo siguiente:

/v1/models/$AIP_MODEL_NAME/version/$AIP_VERSION_NAME

machine_type* El tipo de máquina virtual para el nodo de inferencia
acceleratorConfig:Count La cantidad de GPU para cada nodo es obligatoria.
acceleratorConfig:Type El tipo de GPU es obligatorio si se requiere una GPU.
autoScale:minNodes Los nodos mínimos en el modo de ajuste de escala automático Este elemento no se puede usar con el elemento manualScale.
manualScale:nodes El recuento de nodos en el modo de ajuste de escala manual Este elemento no se puede usar con el elemento autoScale.

Las variables de entorno que tienen el prefijo AIP_ en spec.json solo existen después de que se crea el contenedor de la versión del modelo. En el archivo de muestra anterior de version_spec.json, ten en cuenta lo siguiente:

  • $AIP_STORAGE_URI. Cuando creas una versión del modelo, AI Platform copia los artefactos del modelo de deployment_uri. Cuando el contenedor se conecta, busca $AIP_STORAGE_URI en sus recursos de modelo. En la muestra, definimos la marca para el repositorio del modelo del Triton Inference Server como --model-repository=$AIP_STORAGE_URI.
  • $AIP_MODEL_NAME. Los servidores de modelos como Triton Inference Server y TorchServe admiten más de un modelo en simultáneo y esperan que la ruta de acceso del extremo de solicitud especifique qué modelo ejecutar la inferencia para la solicitud. El valor de este entorno deriva de ${MODEL_NAME} cuando se crea la versión del modelo.

En la tabla siguiente, se describen algunas variables comunes de entorno AIP_ que están disponibles para el contenedor:

Variable de entorno Descripción
AIP_PROJECT_NUMBER El número de proyecto en el que se crea un modelo.
AIP_MODEL_NAME El nombre del modelo en el que se crean las versiones del modelo. El nombre se toma del valor ${MODEL_NAME} en el comando POST que usas para crear el modelo.
AIP_VERSION_NAME Es el nombre de una versión del modelo. El nombre de la versión del modelo se toma del valor name en la especificación JSON anterior que usas para crear el modelo.
AIP_HTTP_PORT El puerto de destino del objeto de escucha en el contenedor personalizado con el que se comunica AI Platform. El objeto de escucha puede ser el servidor de modelos o un intermediario, como el procesamiento previo de datos, que sube al servidor del modelo. Este puerto se toma de container:ports en la especificación JSON anterior.
AIP_PREDICT_ROUTE La ruta a la que AI Platform reenvía las solicitudes de predicción cuando se comunica con el contenedor personalizado. Esta ruta se toma de routes:predict en la especificación JSON anterior.
AIP_HEALTH_ROUTE La ruta que usa AI Platform para verificar el estado del contenedor personalizado. Esta ruta se toma de routes:health en la especificación JSON anterior.
AIP_STORAGE_URI La ubicación en la que se copian los elementos del modelo desde deployment_uri en la especificación JSON anterior. Esta variable de entorno define el lugar en el que el servidor de modelos busca artefactos de modelo.

¿Qué sigue?