Información acerca del aprovisionamiento de GPU y TPU con el modo de aprovisionamiento de inicio flexible

En esta página, se describe el modo de aprovisionamiento de inicio flexible en Google Kubernetes Engine (GKE). El inicio flexible, con la tecnología del Programador dinámico de cargas de trabajo, proporciona una técnica flexible y rentable para obtener GPUs y TPU cuando necesitas ejecutar cargas de trabajo de IA/AA.

Flex-start te permite aprovisionar de forma dinámica GPU y TPU según sea necesario, por hasta siete días, sin estar limitado a una hora de inicio específica y sin la administración de reservas a largo plazo. Por lo tanto, el inicio flexible funciona bien para cargas de trabajo pequeñas y medianas con requisitos de demanda fluctuantes o duraciones cortas. Por ejemplo, el entrenamiento previo de modelos pequeños, el ajuste de modelos o los modelos de entrega escalables.

La información de esta página puede ayudarte a hacer lo siguiente:

• Comprende cómo funciona flex-start en GKE.
• Decide si el inicio flexible es adecuado para tu carga de trabajo.
• Decide qué configuración de inicio flexible es la adecuada para tu carga de trabajo.
• Administra las interrupciones cuando uses flex-start.
• Comprende las limitaciones de flex-start en GKE.

Esta página está dirigida a administradores y operadores de plataformas y a ingenieros de aprendizaje automático (AA) que deseen optimizar la infraestructura de aceleradores para sus cargas de trabajo.

Cuándo usar flex-start

Te recomendamos que uses flex-start si tus cargas de trabajo cumplen con todas las siguientes condiciones:

• Tus cargas de trabajo requieren recursos de GPU.
• Tus cargas de trabajo requieren recursos de TPU que se ejecutan en grupos de nodos de porción de TPU de host único.
• Tienes una capacidad limitada o no reservada de GPU o TPU, y necesitas un acceso más confiable a estos aceleradores.
• Tu carga de trabajo es flexible, y tu caso de uso puede permitirse esperar para obtener toda la capacidad solicitada, por ejemplo, cuando GKE asigna los recursos de GPU fuera de las horas de mayor actividad.

Precios de inicio flexible

Se recomienda el inicio flexible si tu carga de trabajo requiere recursos aprovisionados de forma dinámica según sea necesario, por hasta siete días con reservas a corto plazo, sin administración compleja de cuotas y con acceso rentable. El inicio flexible cuenta con la tecnología del programador dinámico de cargas de trabajo y se factura según los precios del programador dinámico de cargas de trabajo:

• Descuento (hasta un 53%) en CPU virtuales, GPU y TPU.
• Pagas por lo que usas.

Requisitos

Para usar el inicio flexible en GKE, tu clúster debe cumplir con los siguientes requisitos:

• Para ejecutar GPUs, usa la versión 1.32.2-gke.1652000 de GKE o una posterior.

• Para ejecutar TPUs, usa la versión 1.33.0-gke.1712000 de GKE o una posterior. Flex-start admite las siguientes versiones y zonas:

  • TPU Trillium (v6e) en asia-northeast1-b y us-east5-a.
  • TPU v5e en us-west4-a.
  • TPU v5p en us-east5-a.

  No se admiten las TPU v3 ni v4.

Cómo funciona el modo de aprovisionamiento de inicio flexible

Con el inicio flexible, especificas la capacidad de GPU o TPU requerida en tus cargas de trabajo. Además, con los clústeres de Standard, puedes configurar el inicio flexible en grupos de nodos específicos. GKE aprovisiona automáticamente las VMs completando el siguiente proceso cuando la capacidad está disponible:

1. La carga de trabajo solicita capacidad que no está disponible de inmediato. Esta solicitud se puede realizar directamente a través de la especificación de la carga de trabajo o mediante herramientas de programación, como clases de procesamiento personalizadas o Kueue.
2. GKE identifica que tu nodo tiene habilitado el inicio flexible y que la carga de trabajo puede esperar por un tiempo indeterminado.
3. El escalador automático del clúster acepta tu solicitud y calcula la cantidad de nodos necesarios y los trata como una sola unidad.
4. El escalador automático de clústeres aprovisiona los nodos necesarios cuando están disponibles. Estos nodos se ejecutan durante un máximo de siete días o por un período más corto si especificas un valor en el parámetro maxRunDurationSeconds. Este parámetro está disponible con la versión 1.28.5-gke.1355000 de GKE o una posterior. Si no especificas un valor para el parámetro maxRunDurationSeconds, el valor predeterminado es siete días.
5. Después de que finaliza el tiempo de ejecución que definiste en el parámetro maxRunDurationSeconds, los nodos y los Pods se interrumpen.
6. Si los Pods finalizan antes y los nodos ya no se usan, el escalador automático del clúster los quita según el perfil de ajuste de escala automático.

GKE cuenta la duración de cada solicitud de inicio flexible a nivel del nodo. El tiempo disponible para ejecutar Pods puede ser un poco menor debido a demoras durante el inicio. Los reintentos de Pod comparten esta duración, lo que significa que hay menos tiempo disponible para los Pods después del reintento. GKE cuenta la duración de cada solicitud de inicio flexible por separado.

Configuraciones de inicio flexible

GKE admite las siguientes configuraciones de inicio flexible:

• Flex-start, en el que GKE asigna recursos nodo por nodo. Esta configuración solo requiere que establezcas la marca --flex-start durante la creación del nodo.

• Inicio flexible con aprovisionamiento en cola, en el que GKE asigna todos los recursos solicitados al mismo tiempo. Para usar esta configuración, debes agregar las marcas --flex-start y enable-queued-provisioning cuando crees el grupo de nodos. GKE sigue el proceso que se describe en Cómo funciona el modo de aprovisionamiento de inicio flexible en este documento, pero también aplica las siguientes condiciones:

  • El programador espera hasta que todos los recursos solicitados estén disponibles en una sola zona.
  • Todos los Pods de la carga de trabajo pueden ejecutarse juntos en nodos recién aprovisionados.
  • Los nodos aprovisionados no se reutilizan entre las ejecuciones de cargas de trabajo.

En la siguiente tabla, se comparan los parámetros de configuración de flex-start:

Optimiza la configuración de inicio flexible

Para crear una infraestructura de IA/AA sólida y optimizada en cuanto a costos, puedes combinar las configuraciones de inicio flexible con las funciones disponibles de GKE. Te recomendamos que uses clases de procesamiento para definir una lista priorizada de configuraciones de nodos según los requisitos de tu carga de trabajo. GKE seleccionará la configuración más adecuada según la disponibilidad y la prioridad que definiste.

Administra las interrupciones en las cargas de trabajo que usan el programador dinámico de cargas de trabajo

Las cargas de trabajo que requieren la disponibilidad de todos los nodos, o de la mayoría de los nodos, en un grupo de nodos son sensibles a las expulsiones. Además, los nodos aprovisionados con solicitudes del programador dinámico de cargas de trabajo no admiten la reparación automática. La reparación automática quita todas las cargas de trabajo de un nodo y, por lo tanto, evita que se ejecuten.

Todos los nodos que usan el inicio flexible, el aprovisionamiento en cola o ambos usan actualizaciones de corta duración cuando el plano de control del clúster ejecuta la versión mínima para el inicio flexible, 1.32.2-gke.1652000 o posterior.

Las actualizaciones de corta duración actualizan un grupo de nodos de Standard o un grupo de nodos en un clúster de Autopilot sin interrumpir los nodos en ejecución. Los nodos nuevos se crean con la configuración nueva y, con el tiempo, reemplazan gradualmente a los nodos existentes con la configuración anterior. Las versiones anteriores de GKE, que no admiten actualizaciones de inicio flexible ni de corta duración, requieren diferentes prácticas recomendadas.

Prácticas recomendadas para minimizar las interrupciones de las cargas de trabajo en los nodos que usan actualizaciones de corta duración

Los nodos de inicio flexible y los nodos que usan el aprovisionamiento en cola se configuran automáticamente para usar actualizaciones de corta duración cuando el clúster ejecuta la versión 1.32.2-gke.1652000 o una posterior.

Para minimizar las interrupciones en las cargas de trabajo que se ejecutan en nodos que usan actualizaciones de corta duración, realiza las siguientes tareas:

• Configura períodos de mantenimiento y exclusiones para establecer cuándo GKE debe y no debe realizar operaciones de actualización, como actualizaciones de nodos, y, al mismo tiempo, asegúrate de que GKE tenga tiempo para realizar el mantenimiento automático.
• Inhabilita la reparación automática de nodos.

Para los nodos en clústeres que ejecutan versiones anteriores a la 1.32.2-gke.1652000 y, por lo tanto, no usan actualizaciones de corta duración, consulta la orientación específica para esos nodos.

Prácticas recomendadas para minimizar las interrupciones de la carga de trabajo en los nodos de aprovisionamiento en cola sin actualizaciones de corta duración

Los nodos que usan el aprovisionamiento en cola en un clúster que ejecuta una versión de GKE anterior a 1.32.2-gke.1652000 no usan actualizaciones de corta duración. Los clústeres actualizados a la versión 1.32.2-gke.1652000 o posterior con nodos de aprovisionamiento en cola existentes se actualizan automáticamente para usar actualizaciones de corta duración.

En el caso de los nodos que ejecutan estas versiones anteriores, consulta las siguientes instrucciones:

• Según la inscripción del canal de versiones de tu clúster, usa las siguientes prácticas recomendadas para evitar que las actualizaciones automáticas de nodos interrumpan tus cargas de trabajo:
  • Si tu clúster está inscrito en un canal de versiones, usa períodos de mantenimiento y exclusiones para evitar que GKE actualice de manera automática los nodos mientras se ejecuta la carga de trabajo.
  • Si tu clúster no está inscrito en un canal de versiones, inhabilita las actualizaciones automáticas de nodos. Sin embargo, recomendamos usar canales de versiones, en los que puedes usar exclusiones de mantenimiento con alcances más detallados.
• Inhabilita la reparación automática de nodos.
• Usa períodos de mantenimiento y exclusiones para minimizar las interrupciones en las cargas de trabajo en ejecución y, al mismo tiempo, garantizar que GKE tenga tiempo para realizar el mantenimiento automático. Asegúrate de programar ese tiempo para cuando no se estén ejecutando cargas de trabajo.
• Para garantizar que tu grupo de nodos permanezca actualizado, actualiza de forma manual tu grupo de nodos cuando no haya solicitudes activas del programador dinámico de cargas de trabajo y el grupo de nodos esté vacío.

Consideraciones para cuando tu clúster migre a actualizaciones de corta duración

GKE actualiza los nodos existentes con el aprovisionamiento en cola para usar actualizaciones de corta duración cuando el clúster se actualiza a la versión 1.32.2-gke.1652000 o posterior. GKE no actualiza otros parámetros de configuración, como habilitar las actualizaciones automáticas de nodos si las inhabilitaste para un grupo de nodos específico.

Te recomendamos que consideres implementar las siguientes prácticas recomendadas ahora que tus grupos de nodos usan actualizaciones de corta duración:

• Si inhabilitaste las actualizaciones automáticas de nodos con la marca --no-enable-autoupgrade, esta migración no volverá a habilitar las actualizaciones automáticas de nodos para el grupo de nodos. Te recomendamos que habilite las actualizaciones automáticas de nodos, ya que las actualizaciones de corta duración no interrumpen los nodos existentes ni las cargas de trabajo que se ejecutan en ellos. Para obtener más información, consulta Actualizaciones de corta duración.
• También te recomendamos que, si tu clúster aún no está inscrito en un canal de versiones, lo inscribas para que puedas usar exclusiones de mantenimiento más detalladas.

Reciclaje de nodos en el inicio flexible

Para garantizar una transición fluida de los nodos y evitar el tiempo de inactividad de los trabajos en ejecución, el inicio flexible admite el reciclaje de nodos. Cuando un nodo llega al final de su duración, GKE lo reemplaza automáticamente por uno nuevo para conservar tus cargas de trabajo en ejecución.

Para usar el reciclaje de nodos, debes crear un perfil de clase de procesamiento personalizado y, luego, incluir el campo nodeRecycling en la especificación flexStart con el parámetro leadTimeSeconds.

El parámetro leadTimeSeconds te permite equilibrar la disponibilidad de recursos y la eficiencia en cuanto a costos. Este parámetro especifica con cuánta anticipación (en segundos) antes de que un nodo alcance el final de su duración de siete días debe comenzar un nuevo proceso de aprovisionamiento de nodos para sustituirlo. Un plazo más largo aumenta la probabilidad de que el nodo nuevo esté listo antes de que se quite el anterior, pero podría generar costos adicionales.

El proceso de reciclaje de nodos consta de los siguientes pasos:

1. Fase de reciclaje: GKE valida que un nodo aprovisionado con inicio flexible tenga el campo nodeRecycling con el parámetro leadTimeSeconds establecido. Si es así, GKE inicia la fase de reciclaje de nodos cuando la fecha actual es mayor o igual que la diferencia entre los valores de los siguientes campos:

   • creationTimestamp más maxRunDurationSeconds
   • leadTimeSeconds

   La marca creationTimeStamp incluye la hora en la que se creó el nodo. El campo maxRunDurationSeconds se puede especificar en la clase de procesamiento personalizada y tiene un valor predeterminado de siete días.

2. Creación del nodo: Comienza el proceso de creación del nodo nuevo, que pasa por las fases de puesta en cola y aprovisionamiento. La duración de la fase de espera en la cola puede variar de forma dinámica según la zona y la capacidad específica del acelerador.

3. Acordona el nodo que está llegando al final de su duración de siete días: Después de que se ejecute el nodo nuevo, se acordona el nodo anterior. Esta acción evita que se programen Pods nuevos en él. Los Pods existentes en ese nodo siguen ejecutándose.

4. Anulación del aprovisionamiento del nodo: El nodo que alcanza el final de su duración de siete días se anula finalmente después de un período adecuado, lo que ayuda a garantizar que las cargas de trabajo en ejecución se hayan migrado al nodo nuevo.

En el siguiente ejemplo de configuración de una clase de procesamiento, se incluyen los campos leadTimeSeconds y maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Para obtener más información sobre cómo usar el reciclaje de nodos, prueba el instructivo Entrega LLMs en GKE con una estrategia de aprovisionamiento de GPU con optimización de costos y alta disponibilidad.

Limitaciones

• No se admite la antiafinidad entre Pods. El escalador automático del clúster no tiene en cuenta las reglas de antiafinidad entre Pods durante el aprovisionamiento de nodos, lo que puede generar cargas de trabajo no programables. Esta situación puede ocurrir cuando se aprovisionan nodos para dos o más objetos del Programador de cargas de trabajo dinámicos en el mismo grupo de nodos.
• Solo se admiten los nodos de GPU.
• Las reservas no son compatibles con el programador dinámico de cargas de trabajo. Debes especificar la marca --reservation-affinity=none cuando crees el grupo de nodos. El programador de cargas de trabajo dinámicas solo requiere y admite la política de ubicación ANY para el ajuste de escala automático del clúster.
• Una sola solicitud del programador dinámico de cargas de trabajo puede crear hasta 1,000 máquinas virtuales (VMs), que es la cantidad máxima de nodos por zona para un solo grupo de nodos.
• GKE usa la cuota ACTIVE_RESIZE_REQUESTS de Compute Engine para controlar la cantidad de solicitudes del programador dinámico de cargas de trabajo que están pendientes en una cola. De forma predeterminada, esta cuota tiene un límite de 100 solicitudes por proyecto de Google Cloud. Si intentas crear una solicitud de Dynamic Workload Scheduler superior a esta cuota, la solicitud nueva fallará.
• Los grupos de nodos que usan el programador dinámico de cargas de trabajo son sensibles a las interrupciones, ya que los nodos se aprovisionan juntos. Si deseas obtener más información, consulta Administra las interrupciones en cargas de trabajo que usan el programador dinámico de cargas de trabajo.
• Es posible que veas VMs adicionales de corta duración en la Google Cloud consola. Este comportamiento está previsto porque Compute Engine podría crear y quitar VMs de forma oportuna hasta que la capacidad de aprovisionar todas las máquinas necesarias esté disponible.
• No se admiten las VMs Spot.
• El programador dinámico de cargas de trabajo no admite volúmenes efímeros. Debes usar volúmenes persistentes para el almacenamiento. Para seleccionar el mejor tipo de almacenamiento que usa volúmenes persistentes, consulta Descripción general del almacenamiento de los clústeres de GKE.
• Si la carga de trabajo usa el reciclaje de nodos y se implementa con un trabajo, configura el trabajo con el modo de finalización establecido en Indexed.

¿Qué sigue?

• Selecciona un tipo de GPU
• Implementa GPUs con el Programador dinámico de cargas de trabajo.