Acerca del consumo de GPU, TPU y H4D con el modo de aprovisionamiento de inicio flexible

En esta página, se describe el inicio flexible en Google Kubernetes Engine (GKE). El inicio flexible, con tecnología de l programador dinámico de cargas de trabajo, proporciona una técnica flexible y rentable para consumir recursos de procesamiento especializados, como GPUs o TPUs, cuando necesitas ejecutar cargas de trabajo de IA/AA.

El inicio flexible te permite aprovisionar de forma dinámica VMs de inicio flexible para GPUs, TPUs y series de máquinas H4D 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 más pequeñas o medianas con requisitos de demanda fluctuantes o duraciones cortas. Por ejemplo, el preentrenamiento 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:

  • Comprender cómo funciona el inicio flexible en GKE.
  • Decidir si el inicio flexible es adecuado para tu carga de trabajo.
  • Decidir qué configuración de inicio flexible es adecuada para tu carga de trabajo.
  • Administrar las interrupciones cuando se usan VMs de inicio flexible.
  • Comprender las limitaciones de las VMs de inicio flexible en GKE.

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

Cuándo usar el inicio flexible

Te recomendamos que uses el inicio flexible 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.
  • Tus cargas de trabajo requieren otro hardware especializado, como la serie de máquinas H4D optimizada para HPC.
  • 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 del 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 acceso rentable. El inicio flexible cuenta con la tecnología del programador dinámico de cargas de trabajo y se factura con los precios del programador dinámico de cargas de trabajo:

  • Descuento (hasta un 53%) para CPU virtuales, GPUs y TPUs.
  • Pago por uso.

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, consulta los requisitos de la versión de GKE en Planifica las TPUs en GKE. El inicio flexible admite las siguientes versiones y zonas:

    • Ironwood (TPU7x) en us-central1-c.
    • 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 y v4.

Cómo funciona el modo de aprovisionamiento de inicio flexible

Con el inicio flexible, especificas la capacidad de procesamiento requerida (como GPUs o TPUs) en tus cargas de trabajo. Además, con los clústeres de Standard, configuras el inicio flexible en grupos de nodos específicos. GKE aprovisiona automáticamente las VMs de inicio flexible 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 mediante la especificación de la carga de trabajo o a través de herramientas de organizació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 una duración más corta si especificas un valor en el parámetro maxRunDurationSeconds. Si no especificas un valor para el parámetro maxRunDurationSeconds, el valor predeterminado es de siete días.
  5. Una vez que finaliza el tiempo de ejecución que definiste en el maxRunDurationSeconds parámetro finaliza, se interrumpen los nodos y los Pods 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 de 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:

  • Inicio flexible, 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 las configuraciones de inicio flexible:

Inicio flexible Inicio flexible con aprovisionamiento en cola
Disponibilidad Vista previa

Disponible de manera general (DG)

Nota: El inicio flexible admite las marcas flex-start y enable-queued-provisioning en la versión preliminar.
Aceleradores compatibles
Tamaño de carga de trabajo recomendado Pequeño a mediano, lo que significa que la carga de trabajo se puede ejecutar en un solo nodo. Por ejemplo, esta configuración funciona bien si ejecutas trabajos de entrenamiento pequeños, inferencia sin conexión o trabajos por lotes. Mediano a grande, lo que significa que la carga de trabajo se puede ejecutar en varios nodos. Tu carga de trabajo requiere varios recursos y no puede comenzar a ejecutarse hasta que todos los nodos se aprovisionen y estén listos al mismo tiempo. Por ejemplo, esta configuración funciona bien si ejecutas cargas de trabajo de entrenamiento de aprendizaje automático distribuido.
Tipo de aprovisionamiento GKE aprovisiona un nodo a la vez cuando los recursos están disponibles. Para las TPUs, GKE crea un nodo a la vez en grupos de nodos de porción de TPU de host único y la porción completa a la vez en grupos de nodos de porción de TPU de varios hosts. GKE asigna todos los recursos solicitados de forma simultánea.
Complejidad de la configuración Menos complejo. Esta configuración es similar a las VMs Spot y bajo demanda. Es más complejo. Te recomendamos que uses una herramienta de administración de cuotas, como Kueue.
Compatibilidad con clases de procesamiento personalizadas Sí No
Reciclaje de nodos Sí No
Precio SKU de inicio flexible SKU de inicio flexible
Quota
Estrategia de actualización de nodos Actualizaciones de corta duración Actualizaciones de corta duración
gcloud container node pool create marca --flex-start
  • --flex-start
  • --enable-queued-provisioning
Comenzar GPUs: TPUs: Ejecuta una carga de trabajo a gran escala con inicio flexible con aprovisionamiento en cola

Optimiza la configuración de inicio flexible

Para crear una infraestructura de IA/AA sólida y rentable, puedes combinar 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 definida.

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 que se aprovisionan 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, impide que se ejecuten.

Todos los nodos que usan VMs de inicio flexible, 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. Se crean nodos nuevos con la configuración nueva, y se reemplazan gradualmente los nodos existentes con la configuración anterior con el tiempo. Las versiones anteriores de GKE, que no admiten el inicio flexible ni las actualizaciones de corta duración, requieren diferentes prácticas recomendadas.

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

Los nodos que usan VMs 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:

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

Prácticas recomendadas para minimizar la interrupción de las cargas de trabajo para 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 1.32.2-gke.1652000 o versiones posteriores con nodos de aprovisionamiento en cola existentes se actualizan automáticamente para usar actualizaciones de corta duración.

Para los nodos que ejecutan estas versiones anteriores, consulta la siguiente guía:

Consideraciones para cuando tu clúster migra 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 una 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:

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 alcanza el final de su duración, GKE lo reemplaza 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 procesamiento personalizado e incluir el campo nodeRecycling en la especificación flexStart con el leadTimeSeconds parámetro.

El parámetro leadTimeSeconds te permite equilibrar la disponibilidad de recursos y la rentabilidad. Este parámetro especifica con qué anticipación (en segundos) antes de que un nodo alcance el final de su duración de siete días debe comenzar un proceso de aprovisionamiento de nodos nuevos para sustituirlo. Un tiempo de espera más largo aumenta la probabilidad de que el nodo nuevo esté listo antes de que se quite el anterior, pero puede 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 de nodos: Comienza el proceso de creación del nodo nuevo, que pasa por las fases de cola y aprovisionamiento. La duración de la fase de cola puede variar de forma dinámica según la zona y la capacidad específica del acelerador.

  3. Acordonar el nodo que está llegando al final de su duración de siete días: Después de que se ejecuta el nodo nuevo, se acordonan el nodo anterior. Esta acción impide que se programen Pods nuevos en él. Los Pods existentes en ese nodo continúan ejecutándose.

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

En el siguiente ejemplo de una configuración de 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 rentable y de 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 dinámico de cargas de trabajo en el mismo grupo de nodos.
  • Las reservas no son compatibles con el programador dinámico de cargas de trabajo. Debes especificar la marca --reservation-affinity=none cuando creas el grupo de nodos. El programador dinámico de cargas de trabajo solo requiere y admite la ANY política de ubicación 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 Google Cloud proyecto. Si intentas crear una solicitud del programador dinámico de cargas de trabajo que sea 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 las cargas de trabajo que usan el programador dinámico de cargas de trabajo.
  • Es posible que veas VMs adicionales de corta duración adicionales 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 un trabajo la implementa, configura el trabajo con el modo de finalización establecido en Indexed.
  • Un solo objeto ProvisioningRequest admite solo una entrada en la lista podSets. Las solicitudes con varias entradas podSet fallan.

¿Qué sigue?