Implementar un modelo en un extremo

Antes de poder obtener predicciones en línea de un modelo entrenado, debes implementarlo en un extremo. Esto se puede hacer mediante la consola de Google Cloud, Google Cloud CLI o la API de Vertex AI.

En este documento, se describe el proceso para implementar modelos en extremos.

Qué sucede cuando implementas un modelo

La implementación de un modelo asocia recursos físicos con el modelo para que pueda entregar predicciones en línea con baja latencia.

Puedes implementar varios modelos en un extremo o puedes implementar el mismo modelo en varios extremos. Para obtener más información, consulta Motivos para implementar más de un modelo en el mismo extremo.

Prepárate para implementar un modelo en un extremo

Durante la implementación del modelo, toma las siguientes decisiones importantes sobre cómo ejecutar la predicción en línea:

Recurso creado Configuración especificada durante la creación del recurso
Extremo Ubicación en la que se ejecutan las predicciones
Modelo Contenedor que se usará (ModelContainerSpec)
DeployedModel Recursos de procesamiento que se usan para la predicción en línea

Una vez que el modelo se implementa en el extremo, no se puede cambiar esta configuración de implementación. Para cambiarlos, debes volver a implementar tu modelo.

El primer paso en el proceso de implementación es decidir qué tipo de extremo usar. Para obtener más información, consulta Elige un tipo de extremo.

A continuación, asegúrate de que el modelo sea visible en Vertex AI Model Registry. Esto es necesario para que el modelo se pueda implementar. Para obtener información acerca de Model Registry, incluido cómo importar artefactos del modelo o crearlos directamente en Model Registry, consulta Introducción a Vertex AI Model Registry.

La siguiente decisión que debes tomar es qué recursos de procesamiento usar para entregar el modelo. El tipo de entrenamiento del modelo (AutoML o personalizado) y el tipo de datos (AutoML) determinan los tipos de recursos físicos disponibles para el modelo. Después de implementar el modelo, puedes mutate algunos de esos recursos sin crear una implementación nueva.

El recurso de extremo proporciona el extremo del servicio (URL) que usas para solicitar la predicción. Por ejemplo:

   https://us-central1-aiplatform.googleapis.com/v1/projects/{project}/locations/{location}/endpoints/{endpoint}:predict

Implementa un modelo en un extremo

Puedes implementar un modelo en un extremo con la consola de Google Cloud o con la CLI de gcloud o la API de Vertex AI.

Implementa un modelo en un extremo público con la consola de Google Cloud

En la consola de Google Cloud, puedes implementar un modelo en un extremo público dedicado o compartido existente, o bien crear uno nuevo durante el proceso de implementación. Para obtener más información, consulta Implementa un modelo con la consola de Google Cloud.

Implementa un modelo en un extremo público con la CLI de gcloud o la API de Vertex AI

Cuando implementas un modelo con la CLI de gcloud o la API de Vertex AI, primero debes crear un extremo dedicado o compartido y, luego, implementar el modelo en él. Para obtener detalles, consulta:

  1. Crea un extremo público dedicado o compartido
  2. Implementa un modelo con la CLI de gcloud o la API de Vertex AI

Implementa un modelo en un extremo de Private Service Connect

Para obtener más información, consulta Usa extremos de Private Service Connect para la predicción en línea.

Usa una implementación progresiva para actualizar un modelo implementado

Puedes usar una implementación continua para reemplazar un modelo implementado por una versión nueva del mismo modelo. El modelo nuevo reutiliza los recursos de procesamiento del anterior. Para obtener más información, consulta Cómo usar una implementación continua para reemplazar un modelo implementado.

Anula la implementación de un modelo y borra el extremo

Puedes anular la implementación de un modelo y borrar el extremo. Para obtener más información, consulta Anula la implementación de un modelo y borra el extremo.

Razones para implementar más de un modelo en el mismo extremo

Implementar dos modelos en el mismo extremo te permite reemplazar de forma gradual un modelo por el otro. Por ejemplo, supongamos que usas un modelo y encuentras una manera de aumentar la exactitud de ese modelo con datos de capacitación nuevos. Sin embargo, no quieres actualizar tu aplicación para que apunte a una URL de extremo nueva y tampoco deseas crear cambios repentinos en la aplicación. Puedes agregar el modelo nuevo al mismo extremo, que entrega un pequeño porcentaje de tráfico, y aumentar de forma gradual la división del tráfico del modelo nuevo hasta que entregue el 100% del tráfico.

Debido a que los recursos están asociados con el modelo en lugar del extremo, puedes implementar modelos de diferentes tipos en el mismo extremo. Sin embargo, la práctica recomendada es implementar modelos de un tipo específico (por ejemplo, tabular de AutoML o entrenado de forma personalizada) en un extremo. Esta configuración es más fácil de administrar.

Motivos para implementar un modelo en más de un extremo

Es posible que desees implementar tus modelos con diferentes recursos para diferentes entornos de aplicaciones, como pruebas y producción. Es posible que también quieras admitir diferentes SLO para tus solicitudes de predicción. Quizás una de tus aplicaciones necesite un rendimiento mucho más alto que las otras. En este caso, puedes implementar ese modelo en un extremo de mayor rendimiento con más recursos de máquina. Para optimizar los costos, también puedes implementar el modelo en un extremo de menor rendimiento con menos recursos de máquina.

Comportamiento del escalamiento

Cuando implementas un modelo para la predicción en línea como DeployedModel, puedes configurar nodos de predicción para que se escalen automáticamente. Para ello, configura dedicatedResources.maxReplicaCount con un valor mayor que dedicatedResources.minReplicaCount.

Cuando configuras un DeployedModel, debes configurar dedicatedResources.minReplicaCount en, como mínimo, 1. En otras palabras, no puedes configurar DeployedModel para escalar a 0 nodos de predicción cuando no se usa.

De forma predeterminada, la operación de implementación solo se considera exitosa si la cantidad de nodos de predicción alcanza dedicatedResources.minReplicaCount antes del valor de tiempo de espera de la solicitud de implementación. De lo contrario, la implementación se marca como fallida y se liberan los recursos subyacentes.

Implementación y mutación parcialmente exitosas

Puedes modificar el comportamiento predeterminado de la implementación configurando dedicatedResources.requiredReplicaCount en un valor inferior a dedicatedResources.minReplicaCount. En este caso, cuando la cantidad de nodos de predicción alcanza dedicatedResources.requiredReplicaCount, la operación de implementación se marca como exitosa, aunque aún no esté completa. La implementación continúa hasta que se alcanza dedicatedResources.minReplicaCount. Si no se llega a dedicatedResources.minReplicaCount antes del tiempo de solicitud de implementación, la operación se realiza de forma correcta, pero se muestra un mensaje de error para las réplicas que fallaron en DeployedModel.status.message.

La cuota para la entrega de modelos personalizados se calcula en función del uso en tiempo real de los recursos de procesamiento del modelo implementado. Si la suma de maxReplicaCount para todas las implementaciones de tu proyecto supera la cuota de tu proyecto, es posible que algunas implementaciones no hagan un ajuste de escala automático debido a que se agota la cuota.

Los extremos aumentan y disminuyen por máquina, pero la cuota se calcula por CPU o GPU. Por ejemplo, si tu modelo se implementa en el tipo de máquina a2-highgpu-2g, cada réplica activa se cuenta como 24 CPU y 2 GPU en la cuota de tu proyecto. Para obtener más información, consulta Cuotas y límites.

Los nodos de predicción para la predicción por lotes no se escalan automáticamente. Vertex AI usa BatchDedicatedResources.startingReplicaCount e ignora BatchDedicatedResources.maxReplicaCount.

Uso y configuración de destino

De forma predeterminada, si implementas un modelo sin recursos de GPU dedicados, Vertex AI aumentará o disminuirá la escala de la cantidad de réplicas de forma automática para que el uso de CPU coincida con el valor objetivo predeterminado del 60%.

De forma predeterminada, si implementas un modelo con recursos de GPU dedicados (si machineSpec.accelerator_count es superior a 0), Vertex AI escalará vertical y horizontalmente la cantidad de réplicas automáticamente para que el uso de CPU o GPU, el que sea más alto, coincida con el valor objetivo predeterminado del 60%. Por lo tanto, si la capacidad de procesamiento de tu predicción causa un uso elevado de GPU, pero no un uso elevado de CPU, Vertex AI escalará de forma vertical y el uso de CPU será muy bajo, lo que será visible en la supervisión. Por el contrario, si tu contenedor personalizado tiene poco uso de la GPU, pero tiene un proceso no relacionado que aumenta el uso de CPU por encima del 60%, Vertex AI escalará verticalmente, incluso si esto no fue necesario para lograr los objetivos de QPS y latencia.

Puedes anular la métrica y el objetivo de límite predeterminados si especificas autoscalingMetricSpecs. Ten en cuenta que, si tu implementación está configurada para escalar solo según el uso de CPU, no se escalará de forma vertical, incluso si el uso de GPU es alto.

Administra el uso de recursos

Puedes supervisar tu extremo para hacer un seguimiento de las métricas, como el uso de CPU y acelerador, la cantidad de solicitudes, la latencia y la cantidad actual y objetivo de réplicas. Esta información puede ayudarte a comprender el uso de los recursos de tu extremo y el comportamiento del escalamiento.

Ten en cuenta que cada réplica ejecuta solo un contenedor. Esto significa que si un contenedor de predicción no puede usar por completo el recurso de procesamiento elegido, como un solo código de subproceso para una máquina de varios núcleos o un modelo personalizado que llame a otro servicio como parte de la predicción, es posible que tus nodos no se escalen de forma vertical.

Por ejemplo, si usas FastAPI o cualquier servidor de modelos que tenga una cantidad configurable de trabajadores o subprocesos, existen muchos casos en los que tener más de un trabajador puede aumentar el uso de recursos, lo que mejora la capacidad del servicio para escalar de forma automática la cantidad de réplicas.

Por lo general, recomendamos empezar con un trabajador o subproceso por núcleo. Si notas que el uso de CPU es bajo, en especial con una carga alta o tu modelo no escala de forma vertical porque el uso de CPU es bajo, aumenta la cantidad de trabajadores. Por otro lado, si notas que el uso es demasiado alto y las latencias aumentan más de lo esperado con la carga, intenta usar menos trabajadores. Si ya usas un solo trabajador, intenta usar un tipo de máquina más pequeño.

Comportamiento y retraso del escalamiento

Vertex AI ajusta la cantidad de réplicas cada 15 segundos mediante los datos de la ventana de 5 minutos anteriores. Para cada ciclo de 15 segundos, el sistema mide el uso del servidor y genera una cantidad objetivo de réplicas según la siguiente fórmula:

target # of replicas = Ceil(current # of replicas * (current utilization / target utilization))

Por ejemplo, si tienes dos réplicas que se usan al 100%, el objetivo es 4:

4 = Ceil(3.33) = Ceil(2 * (100% / 60%))

Otro ejemplo, si tienes 10 réplicas y el uso disminuye al 1%, el objetivo es 1:

1 = Ceil(.167) = Ceil(10 * (1% / 60%))

Al final de cada ciclo de 15 segundos, el sistema ajusta la cantidad de réplicas para que coincida con el valor objetivo más alto de la ventana anterior de 5 minutos. Ten en cuenta que, como se elige el valor objetivo más alto, tu extremo no reducirá la escala verticalmente si hay un aumento en el uso durante ese período de 5 minutos, incluso si el uso general es muy bajo. Por otro lado, si el sistema necesita escalar de forma vertical, lo hará en un plazo de 15 segundos, ya que se elige el valor objetivo más alto en lugar del promedio.

Ten en cuenta que, incluso después de que Vertex AI ajuste la cantidad de réplicas, el inicio o el apagado de las réplicas lleva tiempo. Por lo tanto, hay un retraso adicional antes de que el extremo pueda ajustarse al tráfico. Los factores principales que contribuyen a este momento incluyen los siguientes:

  • El tiempo para aprovisionar y, luego, iniciar las VMs de Compute Engine
  • El tiempo para descargar el contenedor desde el registro
  • El tiempo para cargar el modelo desde el almacenamiento

La mejor manera de comprender el comportamiento de escalamiento del modelo real es ejecutar una prueba de carga y optimizar las características importantes para el modelo y tu caso de uso. Si el escalador automático no escala de forma vertical lo suficientemente rápido para la aplicación, aprovisiona min_replicas suficientes para controlar el tráfico del modelo de referencia esperado.

Actualiza la configuración de escalamiento

Si especificaste DedicatedResources o AutomaticResources cuando implementaste el modelo, puedes actualizar la configuración de escalamiento sin volver a implementar el modelo mediante una llamada a mutateDeployedModel.

Por ejemplo, la siguiente solicitud actualiza max_replica y autoscaling_metric_specs y luego, inhabilita el registro de contenedores.

{
  "deployedModel": {
    "id": "2464520679043629056",
    "dedicatedResources": {
      "maxReplicaCount": 9,
      "autoscalingMetricSpecs": [
        {
          "metricName": "aiplatform.googleapis.com/prediction/online/cpu/utilization",
          "target": 50
        }
      ]
    },
    "disableContainerLogging": true
  },
  "update_mask": {
    "paths": [
      "dedicated_resources.max_replica_count",
      "dedicated_resources.autoscaling_metric_specs",
      "disable_container_logging"
    ]
  }
}

Notas de uso:

  • No puedes cambiar el tipo de máquina ni cambiar de DedicatedResources a AutomaticResources o viceversa. Los únicos campos de configuración de escalamiento que puedes cambiar son min_replica, max_replica, required_replica y AutoscalingMetricSpec (solo DedicatedResources).
  • Debes enumerar todos los campos que necesites actualizar en updateMask. Los campos no enumerados se ignoran.
  • El DeployedModel debe tener un estado DEPLOYED. Puede haber, como máximo, una operación de mutación activa por modelo implementado.
  • mutateDeployedModel también te permite habilitar o inhabilitar el registro de contenedores. Para obtener más información, consulta Registro de predicciones en línea.

¿Qué sigue?