Desplegar un modelo en un endpoint

Para obtener inferencias online de un modelo entrenado, primero debes desplegarlo en un endpoint. Para ello, puedes usar la Google Cloud consola, la CLI de Google Cloud o la API de Vertex AI.

En este documento se describe el proceso para desplegar modelos en endpoints.

Qué ocurre cuando implementas un modelo

Al desplegar un modelo, se asocian recursos físicos al modelo para que pueda ofrecer inferencias online con baja latencia.

Puede desplegar varios modelos en un endpoint o desplegar el mismo modelo en varios endpoints. Para obtener más información, consulta Motivos para implementar más de un modelo en el mismo endpoint.

Preparar el despliegue de un modelo en un endpoint

Durante la implementación del modelo, debes tomar las siguientes decisiones importantes sobre cómo ejecutar la inferencia online:

Recurso creado Ajuste especificado al crear el recurso
Endpoint Ubicación en la que se van a ejecutar las inferencias
Modelo Contenedor que se va a usar (ModelContainerSpec)
DeployedModel Recursos de computación que se usarán para la inferencia online

Una vez que el modelo se haya desplegado en el endpoint, estos ajustes de despliegue no se podrán cambiar. Para cambiarlos, debes volver a desplegar el modelo.

El primer paso del proceso de implementación es decidir qué tipo de endpoint se va a usar. Para obtener más información, consulta Elegir un tipo de endpoint.

A continuación, comprueba que el modelo se muestre en el registro de modelos de Vertex AI. Es necesario para que el modelo se pueda desplegar. Para obtener información sobre Model Registry, incluido cómo importar artefactos de modelos o crearlos directamente en Model Registry, consulta la introducción a Vertex AI Model Registry.

El siguiente paso es decidir qué recursos de computación se van a usar para publicar 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 un modelo, puedes mutate algunos de esos recursos sin crear una nueva implementación.

El recurso de endpoint proporciona el endpoint de servicio (URL) que se usa para solicitar la inferencia. Por ejemplo:

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

Desplegar un modelo en un endpoint

Puedes desplegar un modelo en un endpoint mediante la Google Cloud consola o con la CLI de gcloud o la API de Vertex AI.

Desplegar un modelo en un endpoint público con la Google Cloud consola

En la Google Cloud consola, puede desplegar un modelo en un punto final público dedicado o compartido, o bien crear un punto final durante el proceso de despliegue. Para obtener más información, consulta Desplegar un modelo con la consola Google Cloud .

Desplegar un modelo en un endpoint público mediante la CLI de gcloud o la API de Vertex AI

Cuando despliegues un modelo con la CLI de gcloud o la API de Vertex AI, primero debes crear un endpoint dedicado o compartido y, a continuación, desplegar el modelo en él. Para obtener información detallada, consulta estos enlaces:

  1. Crear un endpoint público dedicado o compartido
  2. Desplegar un modelo con la CLI de gcloud o la API de Vertex AI

Desplegar un modelo en un endpoint de Private Service Connect

Para obtener más información, consulta Usar puntos finales de Private Service Connect para la inferencia online.

Usar un despliegue continuo para actualizar un modelo desplegado

Puedes usar una implementación gradual para sustituir un modelo implementado por una versión nueva del mismo modelo. El nuevo modelo reutiliza los recursos de computación del anterior. Para obtener más información, consulta Usar una implementación gradual para sustituir un modelo implementado.

Anular el despliegue de un modelo y eliminar el endpoint

Puedes anular el despliegue de un modelo y eliminar el endpoint. Para obtener más información, consulta Retirar un modelo y eliminar el endpoint.

Motivos para desplegar más de un modelo en el mismo endpoint

Si despliegas dos modelos en el mismo endpoint, podrás sustituir uno por otro de forma gradual. Por ejemplo, supongamos que estás usando un modelo y encuentras una forma de aumentar la precisión de ese modelo con nuevos datos de entrenamiento. Sin embargo, no quieres actualizar tu aplicación para que apunte a una nueva URL de endpoint ni quieres crear cambios repentinos en tu aplicación. Puedes añadir el nuevo modelo al mismo endpoint, que sirva un pequeño porcentaje del tráfico, y aumentar gradualmente la división del tráfico del nuevo modelo hasta que sirva el 100% del tráfico.

Como los recursos están asociados al modelo en lugar de al endpoint, puedes implementar modelos de diferentes tipos en el mismo endpoint. Sin embargo, la práctica recomendada es desplegar modelos de un tipo específico (por ejemplo, tabulares de AutoML o entrenados de forma personalizada) en un endpoint. Esta configuración es más fácil de gestionar.

Motivos para desplegar un modelo en más de un endpoint

Puede que quieras desplegar tus modelos con diferentes recursos para distintos entornos de aplicaciones, como los de pruebas y producción. También puede que quieras admitir diferentes SLOs para tus solicitudes de inferencia. Puede que una de tus aplicaciones tenga necesidades de rendimiento mucho mayores que las demás. En este caso, puede implementar ese modelo en un endpoint de mayor rendimiento con más recursos de máquina. Para optimizar los costes, también puedes implementar el modelo en un endpoint de menor rendimiento con menos recursos de máquina.

Comportamiento de escalado

Cuando despliegues un modelo para la inferencia online como DeployedModel, puedes configurar los nodos de inferencia para que se escalen automáticamente. Para ello, asigna a dedicatedResources.maxReplicaCount un valor superior a dedicatedResources.minReplicaCount.

Cuando configures un DeployedModel, debes asignar el valor 1 o superior a dedicatedResources.minReplicaCount. Es decir, no puedes configurar la DeployedModel para que se escale a 0 nodos de inferencia cuando no se esté usando.

De forma predeterminada, la operación de implementación solo se considera correcta si el número de nodos de inferencia alcanza dedicatedResources.minReplicaCount antes de que se agote el 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.

Despliegue y mutación parcialmente correctos

Puedes modificar el comportamiento de implementación predeterminado asignando a dedicatedResources.requiredReplicaCount un valor inferior a dedicatedResources.minReplicaCount. En este caso, cuando el número de nodos de inferencia alcanza dedicatedResources.requiredReplicaCount, la operación de implementación se marca como correcta, aunque aún no se haya completado. La implementación continúa hasta que se alcanza el dedicatedResources.minReplicaCount. Si no se alcanza dedicatedResources.minReplicaCount antes de la hora de la solicitud de implementación, la operación se realizará correctamente, pero se devolverá un mensaje de error de las réplicas fallidas en DeployedModel.status.message.

La cuota de servicio de modelos personalizados se calcula en función del uso en tiempo real de los recursos de computación de tu modelo implementado. Si la suma de maxReplicaCount de todas las implementaciones de tu proyecto es superior a la cuota del proyecto, es posible que algunas implementaciones no puedan escalar automáticamente porque se haya agotado la cuota.

Los endpoints se escalan verticalmente 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 contabiliza como 24 CPUs y 2 GPUs en la cuota de tu proyecto. Para obtener más información, consulta Cuotas y límites.

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

Uso y configuración previstos

De forma predeterminada, si despliegas un modelo sin recursos de GPU dedicados, Vertex AI aumenta o reduce automáticamente el número de réplicas para que el uso de la 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 mayor que 0), Vertex AI aumentará o reducirá automáticamente el número de réplicas para que el uso de la CPU o la GPU, el que sea mayor, coincida con el valor objetivo predeterminado del 60 %. Por lo tanto, si el rendimiento de la inferencia provoca un uso elevado de la GPU, pero no de la CPU, Vertex AI aumentará la escala y la utilización de la CPU será muy baja, lo que se podrá ver en la monitorización. Por el contrario, si tu contenedor personalizado no está aprovechando la GPU, pero tiene un proceso no relacionado que aumenta la utilización de la CPU por encima del 60%, Vertex AI aumentará la escala, aunque no sea necesario para alcanzar los objetivos de QPS y latencia.

Para anular la métrica y el objetivo predeterminados, especifica autoscalingMetricSpecs. Ten en cuenta que, si tu despliegue está configurado para escalarse solo en función del uso de la CPU, no se escalará aunque el uso de la GPU sea alto.

Gestionar el uso de recursos

Puedes monitorizar tu endpoint para hacer un seguimiento de métricas como el uso de la CPU y del acelerador, el número de solicitudes, la latencia y el número actual y objetivo de réplicas. Esta información puede ayudarte a comprender el uso de recursos y el comportamiento de escalado de tu endpoint.

Ten en cuenta que cada réplica ejecuta un solo contenedor. Esto significa que, si un contenedor de inferencia no puede usar por completo el recurso de computación seleccionado (por ejemplo, código de un solo hilo para una máquina de varios núcleos o un modelo personalizado que llama a otro servicio como parte de la inferencia), es posible que tus nodos no se escalen verticalmente.

Por ejemplo, si usas FastAPI o cualquier servidor de modelos que tenga un número configurable de trabajadores o de hilos, hay muchos casos en los que tener más de un trabajador puede aumentar la utilización de recursos, lo que mejora la capacidad del servicio para escalar automáticamente el número de réplicas.

Por lo general, recomendamos empezar con un trabajador o un hilo por núcleo. Si observas que el uso de la CPU es bajo, sobre todo cuando la carga es alta, o que tu modelo no se está escalando porque el uso de la CPU es bajo, aumenta el número de trabajadores. Por otro lado, si observas que el uso es demasiado alto y que las latencias aumentan más de lo esperado cuando hay carga, prueba a usar menos workers. Si ya solo usas un trabajador, prueba a usar un tipo de máquina más pequeño.

Comportamiento de escalado y latencia

Vertex AI ajusta el número de réplicas cada 15 segundos con los datos de la ventana de los 5 minutos anteriores. En cada ciclo de 15 segundos, el sistema mide la utilización del servidor y genera un número 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 están utilizando al 100%, el objetivo es 4:

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

Otro ejemplo: si tienes 10 réplicas y la utilización se reduce al 1%, el objetivo es 1:

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

Al final de cada ciclo de 15 segundos, el sistema ajusta el número de réplicas para que coincida con el valor de destino más alto de la ventana de los 5 minutos anteriores. Ten en cuenta que, como se elige el valor de destino más alto, tu endpoint no se reducirá si hay un pico de utilización durante ese periodo de 5 minutos, aunque la utilización general sea muy baja. Por otro lado, si es necesario aumentar la escala del sistema, se 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, aunque Vertex AI ajuste el número de réplicas, se tarda un tiempo en iniciar o desactivar las réplicas. Por lo tanto, hay un retraso adicional antes de que el endpoint pueda adaptarse al tráfico. Estos son los principales factores que influyen en este tiempo:

  • El tiempo necesario para aprovisionar e iniciar las máquinas virtuales de Compute Engine
  • El tiempo que se tarda en descargar el contenedor del registro
  • Tiempo necesario para cargar el modelo desde el almacenamiento.

La mejor forma de entender el comportamiento de escalado de tu modelo en el mundo real es hacer una prueba de carga y optimizar las características que sean importantes para tu modelo y tu caso práctico. Si el escalador automático no aumenta la escala lo suficientemente rápido para tu aplicación, aprovisiona suficientes min_replicas para gestionar el tráfico base previsto.

Actualizar la configuración de escalado

Si has especificado DedicatedResources o AutomaticResources al desplegar el modelo, puedes actualizar la configuración de escalado sin volver a desplegarlo llamando a mutateDeployedModel.

Por ejemplo, la siguiente solicitud actualiza max_replica, autoscaling_metric_specs e 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 sobre el uso:

  • No puedes cambiar el tipo de máquina ni pasar de DedicatedResources a AutomaticResources o viceversa. Los únicos campos de configuración de escalado que puedes cambiar son min_replica, max_replica, required_replica y AutoscalingMetricSpec (solo DedicatedResources).
  • Debes indicar todos los campos que quieras actualizar en updateMask. Los campos no incluidos en la lista se ignoran.
  • El DeployedModel debe tener el estado DEPLOYED. Solo puede haber 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 inferencias online.

Siguientes pasos