Información sobre el consumo de GPUs, TPUs y H4Ds 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). Flex-start, que se basa en Dynamic Workload Scheduler, ofrece una técnica flexible y rentable para consumir recursos de computación especializados, como GPUs o TPUs, cuando necesitas ejecutar cargas de trabajo de IA o aprendizaje automático.

El inicio flexible te permite consumir dinámicamente recursos de computación especializados según sea necesario, durante un máximo de siete días, sin estar limitado a una hora de inicio específica y sin tener que gestionar reservas a largo plazo. Por lo tanto, el inicio flexible funciona bien en cargas de trabajo de tamaño pequeño o mediano con requisitos de demanda fluctuantes o de corta duración. Por ejemplo, el preentrenamiento de modelos pequeños, el ajuste de modelos o los modelos de servicio escalables.

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

• Descubre cómo funciona el inicio flexible 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.
• Gestionar las interrupciones al usar la función de inicio flexible.
• Conocer las limitaciones de flex-start en GKE.

Esta página está dirigida a administradores y operadores de la plataforma y a ingenieros de aprendizaje automático que quieran 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 todas las condiciones siguientes:

• Tus cargas de trabajo requieren recursos de GPU.
• Tus cargas de trabajo requieren recursos de TPU que se ejecuten en grupos de nodos de segmentos de TPU de un solo host.
• Tus cargas de trabajo requieren otro hardware especializado, como la serie de máquinas H4D optimizada para HPC.
• Tienes una capacidad de GPU o TPU reservada limitada o nula, y necesitas un acceso más fiable a estos aceleradores.
• Tu carga de trabajo es flexible en cuanto a los tiempos y tu caso práctico puede esperar a 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 dinámicamente según sea necesario, durante un máximo de siete días con reservas a corto plazo, sin una gestión de cuotas compleja y con un acceso rentable. La función de inicio flexible se basa en Dynamic Workload Scheduler y se factura según los precios de Dynamic Workload Scheduler:

• Descuento (hasta el 53%) en vCPUs, GPUs y TPUs.
• Pagas a medida que avanzas.

Requisitos

Para usar flex-start en GKE, tu clúster debe cumplir los siguientes requisitos:

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

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

  • TPU Trillium (v6e) en asia-northeast1-b, us-east5-a y us-east5-b.
  • 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 Inicio flexible, puedes especificar la capacidad de computación necesaria (como GPUs o TPUs) en tus cargas de trabajo. Además, con los clústeres estándar, puedes configurar el inicio flexible en grupos de nodos específicos. GKE aprovisiona automáticamente las VMs siguiendo este proceso cuando hay capacidad disponible:

1. La carga de trabajo solicita capacidad que no está disponible inmediatamente. Esta solicitud puede realizarse directamente mediante la especificación de la carga de trabajo o a través de herramientas de programación como las clases de computación personalizadas o Kueue.
2. GKE identifica que tu nodo tiene habilitada la función de inicio flexible y que la carga de trabajo puede esperar un tiempo indeterminado.
3. El autoescalador de clústeres acepta tu solicitud y calcula el número de nodos necesarios, tratándolos como una sola unidad.
4. La herramienta de adaptación dinámica de clústeres aprovisiona los nodos necesarios cuando están disponibles. Estos nodos se ejecutan durante un máximo de siete días o durante un periodo más corto si especifica un valor en el parámetro maxRunDurationSeconds. Si no especifica ningún valor para el parámetro maxRunDurationSeconds, el valor predeterminado es de siete días.
5. Cuando finalice el tiempo de ejecución que hayas definido en el parámetro maxRunDurationSeconds, los nodos y los pods se desalojarán.
6. Si los pods terminan antes y los nodos ya no se utilizan, el escalador automático del clúster los elimina según el perfil de escalado automático.

GKE cuenta la duración de cada solicitud de inicio flexible a nivel de nodo. El tiempo disponible para ejecutar pods puede ser ligeramente inferior debido a los retrasos durante el inicio. Los reintentos de Pod comparten esta duración, lo que significa que los Pods tienen menos tiempo disponible después de reintentar. 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:

• Inicio flexible: GKE asigna recursos nodo por nodo. Para esta configuración, solo tienes que definir la marca --flex-start durante la creación del nodo.

• Inicio flexible con aprovisionamiento en cola: GKE asigna todos los recursos solicitados al mismo tiempo. Para usar esta configuración, debes añadir las marcas --flex-start y enable-queued-provisioning al crear el grupo de nodos. GKE sigue el proceso descrito en la sección Cómo funciona el modo de aprovisionamiento de inicio flexible de 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 las configuraciones de flex-start:

Optimizar la configuración de flex-start

Para crear una infraestructura de IA y aprendizaje automático sólida y optimizada en cuanto a costes, puedes combinar configuraciones de inicio flexible con las funciones de GKE disponibles. Te recomendamos que uses clases de Compute para definir una lista priorizada de configuraciones de nodos en función de los requisitos de tu carga de trabajo. GKE seleccionará la configuración más adecuada en función de la disponibilidad y la prioridad que hayas definido.

Gestionar las interrupciones en las cargas de trabajo que usan Dynamic Workload Scheduler

Las cargas de trabajo que requieren la disponibilidad de todos los nodos o de la mayoría de los nodos de un pool de nodos son sensibles a las expulsiones. Además, los nodos aprovisionados mediante solicitudes de Dynamic Workload Scheduler no admiten la reparación automática. La reparación automática elimina todas las cargas de trabajo de un nodo y, por lo tanto, impide que se ejecuten.

Todos los nodos que usen flex-start, aprovisionamiento en cola o ambos, usarán actualizaciones de corta duración cuando el plano de control del clúster ejecute la versión mínima de flex-start, 1.32.2-gke.1652000 o una posterior.

Las actualizaciones de corta duración actualizan un grupo de nodos Estándar o un grupo de nodos de un clúster de Autopilot sin interrumpir los nodos en ejecución. Los nodos nuevos se crean con la nueva configuración y, con el tiempo, sustituyen gradualmente a los nodos existentes con la configuración antigua. Las versiones anteriores de GKE, que no admiten el inicio flexible ni las actualizaciones de corta duración, requieren otras 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 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 ventanas y exclusiones de mantenimiento para definir cuándo debe y cuándo no debe realizar GKE operaciones de actualización, como las actualizaciones de nodos, y al mismo tiempo asegúrate de que GKE tenga tiempo para llevar a cabo el mantenimiento automático.
• Inhabilita la reparación automática de nodos.

En el caso de los nodos de clústeres que ejecutan versiones anteriores a la 1.32.2-gke.1652000 y, por lo tanto, no utilizan actualizaciones de corta duración, consulta las directrices específicas para esos nodos.

Prácticas recomendadas para minimizar las interrupciones de las cargas 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 la 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 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 directrices:

• En función del canal de lanzamiento de tu clúster, sigue estas prácticas recomendadas para evitar que las actualizaciones automáticas de los nodos interrumpan tus cargas de trabajo:
  • Si tu clúster está registrado en un canal de lanzamiento, usa ventanas de mantenimiento y exclusiones para evitar que GKE actualice automáticamente tus nodos mientras se ejecuta tu carga de trabajo.
  • Si tu clúster no está registrado en un canal de lanzamiento, inhabilita las actualizaciones automáticas de los nodos. Sin embargo, te recomendamos que utilices canales de lanzamiento, donde puedes usar exclusiones de mantenimiento con ámbitos más específicos.
• Inhabilita la reparación automática de nodos.
• Usa ventanas y exclusiones de mantenimiento para minimizar las interrupciones en las cargas de trabajo en ejecución y, al mismo tiempo, asegurarte de 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 asegurarte de que tu grupo de nodos esté actualizado, actualízalo manualmente cuando no haya solicitudes de Dynamic Workload Scheduler activas y el grupo de nodos esté vacío.

Consideraciones sobre la migración de tu clúster a actualizaciones de corta duración

GKE actualiza los nodos que ya existen mediante 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 una posterior. GKE no actualiza otros ajustes, como habilitar las actualizaciones automáticas de nodos si las has inhabilitado en un grupo de nodos específico.

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

• Si has inhabilitado las actualizaciones automáticas de nodos mediante la marca --no-enable-autoupgrade, esta migración no volverá a habilitarlas en el grupo de nodos. Te recomendamos que habilites las actualizaciones automáticas de nodos, ya que las actualizaciones de corta duración no interrumpen los nodos ni las cargas de trabajo que se ejecutan en ellos. Para obtener más información, consulta Mejoras de corta duración.
• También te recomendamos que, si tu clúster aún no está registrado en un canal de lanzamiento, lo registres para poder usar ámbitos de exclusión de mantenimiento más específicos.

Reciclaje de nodos en inicio flexible

Para que la transición de los nodos se realice sin problemas y no se produzca un tiempo de inactividad en 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 sustituye automáticamente por uno nuevo para conservar las cargas de trabajo en ejecución.

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

El parámetro leadTimeSeconds le permite equilibrar la disponibilidad de los recursos y la eficiencia de los costes. Este parámetro especifica con cuánta antelación (en segundos) debe iniciarse el proceso de aprovisionamiento de un nuevo nodo para sustituir un nodo antes de que este último llegue al final de su duración de siete días. Si el tiempo de espera es mayor, aumenta la probabilidad de que el nuevo nodo esté listo antes de que se quite el antiguo, pero puede incurrir en costes adicionales.

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

1. Fase de reciclaje: GKE valida que un nodo aprovisionado con flex-start tenga el campo nodeRecycling con el parámetro leadTimeSeconds definido. 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 y 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 cálculo personalizada y, de forma predeterminada, es de siete días.

2. Creación de nodos: se inicia el proceso de creación del nuevo nodo, que pasa por las fases de puesta en cola y aprovisionamiento. La duración de la fase de puesta en cola puede variar dinámicamente en función de la zona y de la capacidad específica del acelerador.

3. Aísla el nodo que está llegando al final de su periodo de siete días: una vez que el nuevo nodo esté en funcionamiento, el antiguo se aísla. De este modo, se impide que se programen nuevos pods en él. Los pods que ya estén en ese nodo seguirán ejecutándose.

4. Desaprovisionamiento de nodos: el nodo que está llegando al final de su periodo de siete días se desaprovisiona al cabo de un tiempo adecuado, lo que ayuda a asegurar que las cargas de trabajo en ejecución se hayan migrado al nuevo nodo.

En el siguiente ejemplo de configuración de una clase de cálculo 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, consulta el tutorial Servir LLMs en GKE con una estrategia de aprovisionamiento de GPUs optimizada para los costes y de alta disponibilidad.

Limitaciones

• No se admite la antiafinidad entre pods. La herramienta de adaptación dinámica de clústeres no tiene en cuenta las reglas de antiafinidad entre pods durante el aprovisionamiento de nodos, lo que puede provocar que las cargas de trabajo no se puedan programar. Esta situación puede darse cuando se aprovisionan nodos de dos o más objetos de Dynamic Workload Scheduler en el mismo grupo de nodos.
• Las reservas no son compatibles con Dynamic Workload Scheduler. Debes especificar la marca --reservation-affinity=none al crear el grupo de nodos. Dynamic Workload Scheduler solo requiere y admite la ANY política de ubicación para el autoescalado de clústeres.
• Una sola solicitud de Dynamic Workload Scheduler puede crear hasta 1000 máquinas virtuales, que es el número máximo de nodos por zona para un solo grupo de nodos.
• GKE usa la cuota de ACTIVE_RESIZE_REQUESTS Compute Engine para controlar el número de solicitudes de Dynamic Workload Scheduler que están pendientes en una cola. De forma predeterminada, esta cuota tiene un límite de 100 solicitudes por proyecto Trusted Cloud. Si intentas crear una solicitud de Dynamic Workload Scheduler que supere esta cuota, la nueva solicitud fallará.
• Los grupos de nodos que usan Dynamic Workload Scheduler son sensibles a las interrupciones porque los nodos se aprovisionan juntos. Para obtener más información, consulta Gestionar las interrupciones en cargas de trabajo que usan Dynamic Workload Scheduler.
• Es posible que veas más máquinas virtuales de corta duración en la Trusted Cloud consola. Este comportamiento es el esperado, ya que Compute Engine puede crear y, después, eliminar rápidamente las VMs hasta que esté disponible la capacidad para aprovisionar todas las máquinas necesarias.
• No se admiten máquinas virtuales de acceso puntual.
• Dynamic Workload Scheduler no admite volúmenes efímeros. Debes usar volúmenes persistentes para el almacenamiento. Para seleccionar el mejor tipo de almacenamiento que utilice volúmenes persistentes, consulta la información general sobre el almacenamiento de clústeres de GKE.
• Si la carga de trabajo usa el reciclaje de nodos y se implementa mediante un trabajo, configura el trabajo con el modo de finalización definido como Indexed.

Siguientes pasos

• Selecciona un tipo de GPU.
• Despliega GPUs con Dynamic Workload Scheduler.