Crea un clúster de GKE optimizado para IA con la configuración predeterminada

En esta página, se muestra cómo crear tu propio clúster de Google Kubernetes Engine (GKE) optimizado para IA que usa máquinas virtuales (VM) A4X, A4, A3 Ultra, A3 Mega y A3 High (8 GPUs) para admitir tus cargas de trabajo de IA y AA.

Las series de máquinas A4X, A4, A3 Ultra, A3 Mega y A3 High (8 GPUs) están diseñadas para permitirte ejecutar clústeres de IA/AA a gran escala con funciones como la colocación de cargas de trabajo segmentadas, controles avanzados de mantenimiento de clústeres y programación que considera la topología. Para obtener más información, consulta la descripción general de la administración de clústeres.

GKE proporciona una sola plataforma para ejecutar un conjunto diverso de cargas de trabajo según las necesidades de tu organización. Esto incluye el entrenamiento previo distribuido de alto rendimiento, el ajuste de modelos, la inferencia de modelos, la entrega de aplicaciones y los servicios de asistencia. GKE reduce la carga operativa de administrar varias plataformas.

Elige cómo crear un clúster de GKE optimizado para IA

Las siguientes opciones para la creación de clústeres proporcionan diferentes grados de facilidad y flexibilidad en la configuración del clúster y la programación de cargas de trabajo:

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
  • Verifica que tengas los permisos necesarios para crear y administrar el clúster de GKE y las cuentas de servicio asociadas:
    • Administrador de Kubernetes Engine (roles/container.admin)
    • Administrador de Compute (roles/compute.admin)
    • Administrador de almacenamiento (roles/storage.admin)
    • Administrador del proyecto de IAM (roles/resourcemanager.projectIamAdmin)
    • Administrador de cuenta de servicio (roles/iam.serviceAccountAdmin)
    • Usuario de la cuenta de servicio (roles/iam.serviceAccountUser)
    • Consumidor de Service Usage (roles/serviceusage.serviceUsageConsumer)
    • Administrador de roles (roles/iam.roleAdmin)
    • Administrador de versiones de secretos de Secret Manager (roles/secretmanager.secretVersionManager)

Elige una opción de consumo y obtén capacidad

  1. Elige una opción de consumo. Elige en función de cómo deseas obtener y usar los recursos de GPU. Para obtener más información, consulta Elige una opción de consumo.

    En el caso de GKE, ten en cuenta la siguiente información adicional cuando elijas una opción de consumo:

  2. Obtener capacidad El proceso para obtener capacidad difiere para cada opción de consumo.

    Para obtener información sobre el proceso de la opción de consumo que elegiste, consulta Descripción general de la capacidad.

Requisitos

Se aplican los siguientes requisitos a un clúster de GKE optimizado para IA:

  • Para A4X, asegúrate de usar, para la versión 1.33 o posterior, la versión 1.33.4-gke.1036000 de GKE o una posterior. O bien, para la versión 1.32, usa la versión 1.32.8-gke.1108000 de GKE o una posterior. Estas versiones garantizan que A4X use lo siguiente:

    • R580, la versión mínima del controlador de GPU para A4X.
    • Administración de memoria coherente basada en el controlador (CDMM), que está habilitada de forma predeterminada. NVIDIA recomienda que los clústeres de Kubernetes habiliten este modo para resolver el exceso de informes de memoria. El CDMM permite que la memoria de la GPU se administre a través del controlador en lugar del sistema operativo (SO). Este enfoque te ayuda a evitar que el SO ponga en línea la memoria de la GPU y expone la memoria de la GPU como un nodo de acceso no uniforme a memoria (NUMA) para el SO. No se admiten GPUs de varias instancias cuando CDMM está habilitado. Para obtener más información sobre el CDMM, consulta Compatibilidad con hardware y software.
    • GPUDirect RDMA, que se recomienda habilitar para que los grupos de nodos A4X usen las capacidades de redes de A4X
  • Asegúrate de usar la versión mínima del controlador de GPU, según el tipo de máquina:

    • A4X: Las GPUs GB200 en las VMs A4X requieren como mínimo la versión del controlador de GPU R580. Consulta los requisitos de versión mencionados anteriormente.
    • A4: Las GPUs B200 en las VMs A4 requieren una versión mínima del controlador de GPU R570. De forma predeterminada, GKE instala automáticamente esta versión del controlador en todos los nodos A4 que ejecutan la versión mínima requerida para A4, 1.32.1-gke.1729000 o posterior.
    • A3 Ultra: Las GPU H200 en las VMs A3 Ultra requieren una versión mínima del controlador de GPU R550, que está disponible en GKE 1.31 como la versión del controlador latest. En el caso de A3 Ultra, debes configurar gpu-driver-version=latest con GKE 1.31. En la versión 1.31.5-gke.1169000 o posterior de GKE, GKE instala automáticamente, de forma predeterminada, las versiones del controlador de GPU R550 en los nodos A3 Ultra.
  • En el caso de los grupos de nodos A3 Ultra, debes establecer el tipo de disco en hyperdisk-balanced.

  • Para usar GPUDirect RDMA, usa las siguientes versiones mínimas según el tipo de máquina:

    • A4X: Consulta los requisitos de versión mencionados anteriormente.
    • A4: Usa la versión 1.32.2-gke.1475000 o una posterior.
    • A3 Ultra: Usa 1.31.4-gke.1183000 o una versión posterior.
  • Para usar GPUDirect RDMA, los nodos de GKE deben usar una imagen de nodo de Container-Optimized OS. Las imágenes de nodos de Ubuntu y Windows no son compatibles.

  • Debes usar el modelo de aprovisionamiento vinculado a la reserva para crear clústeres con A4X. No se admiten otros modelos de aprovisionamiento.

Crea un clúster

Usa las siguientes instrucciones para crear un clúster con Cluster Toolkit o XPK.

Crea un clúster con Cluster Toolkit

En esta sección, se te guía por el proceso de creación del clúster y se garantiza que tu proyecto siga las prácticas recomendadas y cumpla con los requisitos para un clúster de GKE optimizado para IA.

A4X

  1. Inicia Cloud Shell. Puedes usar un entorno diferente. Sin embargo, recomendamos Cloud Shell porque las dependencias ya están preinstaladas para Cluster Toolkit. Si no quieres usar Cloud Shell, sigue las instrucciones para instalar dependencias y preparar un entorno diferente.
  2. Clona Cluster Toolkit desde el repositorio de Git:

    cd ~
    git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
    
  3. Instala Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make
    
  4. Crea un bucket de Cloud Storage para almacenar el estado de la implementación de Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning
    

    Reemplaza las siguientes variables:

    • BUCKET_NAME: Es el nombre del nuevo bucket de Cloud Storage.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: Es la región de procesamiento en la que deseas almacenar el estado de la implementación de Terraform.
  5. En el blueprint de examples/gke-a4x/gke-a4x-deployment.yaml del repositorio de GitHub, completa los siguientes parámetros de configuración en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

    • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, falla la creación del clúster. El valor predeterminado es gke-a4x.
    • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • COMPUTE_REGION: Es la región de procesamiento del clúster.
    • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A4X. Ten en cuenta que esta zona debe coincidir con la zona en la que las máquinas están disponibles en tu reserva.
    • NODE_COUNT: Es la cantidad de nodos A4X en el grupo de nodos de tu clúster, que debe ser de 18 nodos o menos. Te recomendamos que uses 18 nodos para obtener la topología de GPU de 1x72 en un subbloque con un dominio de NVLink.
    • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
    • Para el campo extended_reservation, usa una de las siguientes opciones, según si deseas segmentar bloques específicos en una reserva cuando aprovisiones el grupo de nodos:

      • Para colocar el grupo de nodos en cualquier lugar de la reserva, proporciona el nombre de tu reserva (RESERVATION_NAME).
      • Para segmentar un bloque específico dentro de tu reserva, usa los nombres de la reserva y del bloque con el siguiente formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

      Si no sabes qué bloques están disponibles en tu reserva, consulta Cómo ver la topología de una reserva.

    • Establece los tamaños de los discos de arranque para cada nodo del sistema y los grupos de nodos de A4X. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 200.
      • A4X_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A4X. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.

    Para modificar la configuración avanzada, edita el archivo examples/gke-a4x/gke-a4x.yaml.

  6. De manera opcional, puedes habilitar el Analizador de estado del clúster (CHS) en el clúster. El CHS verifica el estado de tus clústeres de GPU ejecutando pruebas para verificar que estén listos para ejecutar tus cargas de trabajo. Para habilitar CHS, realiza los siguientes cambios en el archivo examples/gke-a4x/gke-a4x-deployment.yaml:

    • En el bloque vars, establece el campo enable_periodic_health_checks en true.

    • De forma predeterminada, las verificaciones de estado se ejecutan todos los domingos a las 12:00 a.m. (PST). Si quieres cambiar este parámetro de configuración, en el bloque vars, establece el campo health_check_schedule en un valor adecuado, en formato cron.
      Programar en formato cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Genera credenciales predeterminadas de la aplicación (ADC) para proporcionar acceso a Terraform. Si usas Cloud Shell, puedes ejecutar el siguiente comando:

    gcloud auth application-default login
    
  8. Implementa el blueprint para aprovisionar la infraestructura de GKE con tipos de máquinas A4X:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml
    
  9. Cuando se te solicite, selecciona (A)pply para implementar el blueprint.

    • El blueprint crea redes de VPC, una red de VPC de RDMA para GPU, cuentas de servicio, un clúster y un grupo de nodos.
    • Para admitir la plantilla de trabajo fio-bench-job-template en el blueprint, se crean recursos de buckets, almacenamiento de red y volúmenes persistentes deGoogle Cloud .

A4

  1. Inicia Cloud Shell. Puedes usar un entorno diferente. Sin embargo, recomendamos Cloud Shell porque las dependencias ya están preinstaladas para Cluster Toolkit. Si no quieres usar Cloud Shell, sigue las instrucciones para instalar dependencias y preparar un entorno diferente.
  2. Clona Cluster Toolkit desde el repositorio de Git:

    cd ~
    git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
    
  3. Instala Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make
    
  4. Crea un bucket de Cloud Storage para almacenar el estado de la implementación de Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning
    

    Reemplaza las siguientes variables:

    • BUCKET_NAME: Es el nombre del nuevo bucket de Cloud Storage.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: Es la región de procesamiento en la que deseas almacenar el estado de la implementación de Terraform.
  5. Los archivos que debes editar para crear un clúster dependen de la opción de consumo que uses para tu implementación. Selecciona la pestaña que corresponde al modelo de aprovisionamiento de tu opción de consumo.

    Con reserva

    En el blueprint de examples/gke-a4/gke-a4-deployment.yaml del repositorio de GitHub, completa los siguientes parámetros de configuración en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

    • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, falla la creación del clúster. El valor predeterminado es gke-a4.
    • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • COMPUTE_REGION: Es la región de procesamiento del clúster.
    • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A4. Ten en cuenta que esta zona debe coincidir con la zona en la que las máquinas están disponibles en tu reserva.
    • NODE_COUNT: Es la cantidad de nodos A4 en tu clúster.
    • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
    • Para el campo reservation, usa una de las siguientes opciones, según si deseas segmentar bloques específicos en una reserva cuando aprovisiones el grupo de nodos:

      • Para colocar el grupo de nodos en cualquier lugar de la reserva, proporciona el nombre de tu reserva (RESERVATION_NAME).
      • Para segmentar un bloque específico dentro de tu reserva, usa los nombres de la reserva y del bloque con el siguiente formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

      Si no sabes qué bloques están disponibles en tu reserva, consulta Cómo ver la topología de una reserva.

    • Establece los tamaños del disco de arranque para cada nodo del sistema y los grupos de nodos de A4. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
      • A4_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A4. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.

    Para modificar la configuración avanzada, edita examples/gke-a4/gke-a4.yaml.

    Inicio flexible

    1. En el blueprint de examples/gke-a4/gke-a4-deployment.yaml del repositorio de GitHub, completa los siguientes parámetros de configuración en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

      • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, la creación del clúster fallará. El valor predeterminado es gke-a4.
      • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
      • PROJECT_ID: Es el ID del proyecto de Google Cloud .
      • COMPUTE_REGION: Es la región de procesamiento del clúster.
      • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A4.
      • Quita static_node_count.
      • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
      • Quita el campo reservation y reemplázalo por enable_flex_start: true. Agrega enable_queued_provisioning: true en la siguiente línea si también deseas usar el aprovisionamiento en cola. Para obtener más información, consulta Usa grupos de nodos con flex-start y aprovisionamiento en cola.
      • Establece los tamaños del disco de arranque para cada nodo del sistema y los grupos de nodos de A4. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
        • A4_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A4. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
    2. En el plano examples/gke-a4/gke-a4.yaml del repo de GitHub, realiza los siguientes cambios:

      • En el bloque vars, quita static_node_count.
      • En el bloque vars, asegúrate de que el número de version_prefix sea "1.32." o superior. Para usar el inicio flexible en GKE, tu clúster debe usar la versión 1.32.2-gke.1652000 o una posterior.
      • En el bloque vars, reemplaza todo el bloque reservation (incluida la línea reservation) por enable_flex_start: true y, de manera opcional, enable_queued_provisioning: true.
      • En el bloque vars, si no necesitas el aprovisionamiento en cola, quita la siguiente línea: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • En id: a4-pool, quita la siguiente línea: static_node_count: $(vars.static_node_count).
      • En id: a4-pool, quita el bloque reservation_affinity. Reemplaza este bloque con las siguientes líneas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para el aprovisionamiento en cola, si deseas habilitarlo, agrega las siguientes líneas adicionales:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • En id: workload-manager-install, quita el siguiente bloque:

         kueue:
            install: true
            config_path: $(vars.kueue_configuration_path)
            config_template_vars:
               num_gpus: $(a3-ultragpu-pool.static_gpu_count)
               accelerator_type: $(vars.accelerator_type)
        
        • Para el inicio flexible con aprovisionamiento en cola, haz lo siguiente:

          1. Agrega gpu_nominal_quota: NOMINAL_QUOTA al bloque vars. El valor de gpu_nominal_quota se usa para establecer el nominalQuota de las GPUs en la especificación de ClusterQueue (a continuación, consulta el paso para establecer ClusterQueue). En este ejemplo, ClusterQueue solo admite cargas de trabajo si la suma de las solicitudes de GPU es menor o igual que el valor de NOMINAL_QUOTA. Para obtener más información sobre ClusterQueue, consulta el siguiente documento de Kueue sobre la fila del clúster.

          2. Actualiza el bloque kueue de la siguiente manera:

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. Reemplaza el contenido del archivo kueue-configuration.yaml.tftpl por lo siguiente:

            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ResourceFlavor
            metadata:
               name: "default-flavor"
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: AdmissionCheck
            metadata:
               name: dws-prov
            spec:
               controllerName: kueue.x-k8s.io/provisioning-request
               parameters:
                  apiGroup: kueue.x-k8s.io
                  kind: ProvisioningRequestConfig
                  name: dws-config
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ProvisioningRequestConfig
            metadata:
               name: dws-config
            spec:
               provisioningClassName: queued-provisioning.gke.io
               managedResources:
               - nvidia.com/gpu
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ClusterQueue
            metadata:
               name: "dws-cluster-queue"
            spec:
               namespaceSelector: {}
               resourceGroups:
               - coveredResources: ["nvidia.com/gpu"]
                  flavors:
                  - name: "default-flavor"
                  resources:
                  - name: "nvidia.com/gpu"
                     nominalQuota: ${num_gpus}
               admissionChecks:
               - dws-prov
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: LocalQueue
            metadata:
               namespace: "default"
               name: "dws-local-queue"
            spec:
               clusterQueue: "dws-cluster-queue"
            ---
            
      • En id: job-template, reemplaza la variable node_count por 2.

    Spot

    1. En el blueprint de examples/gke-a4/gke-a4-deployment.yaml del repositorio de GitHub, completa los siguientes parámetros de configuración en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

      • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, la creación del clúster fallará. El valor predeterminado es gke-a4.
      • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
      • PROJECT_ID: Es el ID del proyecto de Google Cloud .
      • COMPUTE_REGION: Es la región de procesamiento del clúster.
      • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A4.
      • STATIC_NODE_COUNT: Es la cantidad de nodos A4 en tu clúster.
      • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
      • Reemplaza todo el bloque reservation (incluida la línea reservation) por spot: true.
      • Establece los tamaños del disco de arranque para cada nodo del sistema y los grupos de nodos de A4. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
        • A4_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A4. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
    2. En el plano examples/gke-a4/gke-a4.yaml del repo de GitHub, realiza los siguientes cambios:

      • En el bloque vars, reemplaza todo el bloque reservation (incluida la línea reservation) por spot: true.
      • En id: a4-pool, quita el bloque reservation_affinity. Reemplaza este bloque por la siguiente línea:

        • spot: $(vars.spot)
  6. De manera opcional, puedes habilitar el Analizador de estado del clúster (CHS) en el clúster. El CHS verifica el estado de tus clústeres de GPU ejecutando pruebas para verificar que estén listos para ejecutar tus cargas de trabajo. Para habilitar CHS, realiza los siguientes cambios en el archivo examples/gke-a4/gke-a4-deployment.yaml:

    • En el bloque vars, establece el campo enable_periodic_health_checks en true.

    • De forma predeterminada, las verificaciones de estado se ejecutan todos los domingos a las 12:00 a.m. (PST). Si quieres cambiar este parámetro de configuración, en el bloque vars, establece el campo health_check_schedule en un valor adecuado, en formato cron.
      Programar en formato cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Genera credenciales predeterminadas de la aplicación (ADC) para proporcionar acceso a Terraform. Si usas Cloud Shell, puedes ejecutar el siguiente comando:

    gcloud auth application-default login
    
  8. Implementa el blueprint para aprovisionar la infraestructura de GKE con tipos de máquinas A4:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml
    
  9. Cuando se te solicite, selecciona (A)plicar para implementar el blueprint.

    • El blueprint crea redes de VPC, una red de VPC de RDMA para GPU, cuentas de servicio, un clúster y un grupo de nodos.
    • Para admitir la plantilla de trabajo fio-bench-job-template en el blueprint, se crean recursos de buckets, almacenamiento de red y volúmenes persistentes deGoogle Cloud .

A3 Ultra

  1. Inicia Cloud Shell. Puedes usar un entorno diferente. Sin embargo, recomendamos Cloud Shell porque las dependencias ya están preinstaladas para Cluster Toolkit. Si no quieres usar Cloud Shell, sigue las instrucciones para instalar dependencias y preparar un entorno diferente.
  2. Clona Cluster Toolkit desde el repositorio de Git:

    cd ~
    git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
    
  3. Instala Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make
    
  4. Crea un bucket de Cloud Storage para almacenar el estado de la implementación de Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning
    

    Reemplaza las siguientes variables:

    • BUCKET_NAME: Es el nombre del nuevo bucket de Cloud Storage.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: Es la región de procesamiento en la que deseas almacenar el estado de la implementación de Terraform.
  5. Los archivos que debes editar para crear un clúster dependen de la opción de consumo que uses para tu implementación. Selecciona la pestaña que corresponde al modelo de aprovisionamiento de tu opción de consumo.

    Con reserva

    En el plano de examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml del repositorio de GitHub, reemplaza las siguientes variables en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

    • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, falla la creación del clúster.
    • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • COMPUTE_REGION: Es la región de procesamiento del clúster.
    • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A3 Ultra. Ten en cuenta que esta zona debe coincidir con la zona en la que las máquinas están disponibles en tu reserva.
    • NODE_COUNT: Es la cantidad de nodos A3 Ultra en tu clúster.
    • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
    • Para el campo reservation, usa una de las siguientes opciones, según si deseas segmentar bloques específicos en una reserva cuando aprovisiones el grupo de nodos:

      • Para colocar el grupo de nodos en cualquier lugar de la reserva, proporciona el nombre de tu reserva (RESERVATION_NAME).
      • Para segmentar un bloque específico dentro de tu reserva, usa los nombres de la reserva y del bloque con el siguiente formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

      Si no sabes qué bloques están disponibles en tu reserva, consulta Cómo ver la topología de una reserva.

    • Establece los tamaños del disco de arranque para cada nodo del sistema y los grupos de nodos A3 Ultra. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A3 Ultra. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.

    Para modificar la configuración avanzada, edita examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Inicio flexible

    1. En el plano de examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml del repositorio de GitHub, reemplaza las siguientes variables en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

      • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, la creación del clúster fallará.
      • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
      • PROJECT_ID: Es el ID del proyecto de Google Cloud .
      • COMPUTE_REGION: Es la región de procesamiento del clúster.
      • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A3 Ultra.
      • Quita static_node_count.
      • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
      • Quita el campo reservation y reemplázalo por enable_flex_start: true. Agrega enable_queued_provisioning: true en la siguiente línea si también deseas usar el aprovisionamiento en cola. Para obtener más información, consulta Usa grupos de nodos con flex-start y aprovisionamiento en cola.
      • Establece los tamaños del disco de arranque para cada nodo del sistema y los grupos de nodos A3 Ultra. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A3 Ultra. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
    2. En el plano examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml del repositorio de GitHub, realiza los siguientes cambios:

      • En el bloque vars, quita static_node_count.
      • En el bloque vars, actualiza el número version_prefix a "1.32." o un número mayor. Para usar el inicio flexible en GKE, tu clúster debe usar la versión 1.32.2-gke.1652000 o una posterior.
      • En el bloque vars, reemplaza todo el bloque reservation (incluida la línea reservation) por enable_flex_start: true y, de manera opcional, enable_queued_provisioning: true.
      • En el bloque vars, quita la siguiente línea: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • En id: a3-ultragpu-pool, quita la siguiente línea: static_node_count: $(vars.static_node_count).
      • En id: a3-ultragpu-pool, quita el bloque reservation_affinity. Reemplaza este bloque con las siguientes líneas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para el aprovisionamiento en cola, si deseas habilitarlo, agrega las siguientes líneas adicionales:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • En id: workload-manager-install, quita el siguiente bloque:

        config_path: $(vars.kueue_configuration_path)
        config_template_vars:
          num_gpus: $(a4-pool.static_gpu_count)
          accelerator_type: $(vars.accelerator_type)
        
        • Para el inicio flexible con aprovisionamiento en cola, sigue estos tres pasos:

          1. Agrega gpu_nominal_quota: NOMINAL_QUOTA al bloque vars. El valor de gpu_nominal_quota se usa para establecer el nominalQuota de las GPUs en la especificación de ClusterQueue. En este ejemplo, ClusterQueue solo admite cargas de trabajo si la suma de las solicitudes de GPU es menor o igual que el valor de NOMINAL_QUOTA. Para obtener más información sobre ClusterQueue, consulta el siguiente documento de Kueue sobre la fila del clúster.

          2. Actualiza el bloque kueue de la siguiente manera:

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. Reemplaza el contenido del archivo kueue-configuration.yaml.tftpl por lo siguiente:

            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ResourceFlavor
            metadata:
               name: "default-flavor"
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: AdmissionCheck
            metadata:
               name: dws-prov
            spec:
               controllerName: kueue.x-k8s.io/provisioning-request
               parameters:
                  apiGroup: kueue.x-k8s.io
                  kind: ProvisioningRequestConfig
                  name: dws-config
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ProvisioningRequestConfig
            metadata:
               name: dws-config
            spec:
               provisioningClassName: queued-provisioning.gke.io
               managedResources:
               - nvidia.com/gpu
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ClusterQueue
            metadata:
               name: "dws-cluster-queue"
            spec:
               namespaceSelector: {}
               resourceGroups:
               - coveredResources: ["nvidia.com/gpu"]
                  flavors:
                  - name: "default-flavor"
                  resources:
                  - name: "nvidia.com/gpu"
                     nominalQuota: ${num_gpus}
               admissionChecks:
               - dws-prov
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: LocalQueue
            metadata:
               namespace: "default"
               name: "dws-local-queue"
            spec:
               clusterQueue: "dws-cluster-queue"
            ---
            
        • En el campo id: job-template, reemplaza la variable node_count por 2.

    Spot

    1. En el plan examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml del repositorio de GitHub, completa los siguientes parámetros de configuración en las secciones terraform_backend_defaults y vars para que coincidan con los valores específicos de tu implementación:

      • DEPLOYMENT_NAME: Es un nombre único para la implementación, que debe tener entre 6 y 30 caracteres. Si el nombre de la implementación no es único dentro de un proyecto, la creación del clúster fallará.
      • BUCKET_NAME: Es el nombre del bucket de Cloud Storage que creaste en el paso anterior.
      • PROJECT_ID: Es el ID del proyecto de Google Cloud .
      • COMPUTE_REGION: Es la región de procesamiento del clúster.
      • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A3 Ultra.
      • STATIC_NODE_COUNT: Es la cantidad de nodos A3 Ultra en tu clúster.
      • IP_ADDRESS/SUFFIX: Es el rango de direcciones IP al que deseas permitir que se conecte con el clúster. Este bloque CIDR debe incluir la dirección IP de la máquina que deseas usar para llamar a Terraform. Para obtener más información, consulta Cómo funcionan las redes autorizadas.
      • Reemplaza todo el bloque reservation (incluida la línea reservation) por spot: true.
      • Establece los tamaños del disco de arranque para cada nodo del sistema y los grupos de nodos A3 Ultra. El tamaño de disco que necesitas depende de tu caso de uso. Por ejemplo, si usas el disco como caché para reducir la latencia de la extracción repetida de una imagen, puedes establecer un tamaño de disco más grande para que se adapte a tu framework, modelo o imagen de contenedor:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos del sistema. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: Es el tamaño del disco de arranque para cada nodo del grupo de nodos A3 Ultra. El tamaño de disco más pequeño permitido es 10. El valor predeterminado es 100.
    2. En el plano examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml del repo de GitHub, realiza los siguientes cambios:

      • En el bloque vars, reemplaza todo el bloque reservation (incluida la línea reservation) por spot: true.
      • En id: a3-ultragpu-pool, quita el bloque reservation_affinity. Reemplaza este bloque por la siguiente línea:

        • spot: $(vars.spot)
  6. De manera opcional, puedes habilitar el Analizador de estado del clúster (CHS) en el clúster. El CHS verifica el estado de tus clústeres de GPU ejecutando pruebas para verificar que estén listos para ejecutar tus cargas de trabajo. Para habilitar CHS, realiza los siguientes cambios en el archivo examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml:

    • En el bloque vars, establece el campo enable_periodic_health_checks en true.

    • De forma predeterminada, las verificaciones de estado se ejecutan todos los domingos a las 12:00 a.m. (PST). Si quieres cambiar este parámetro de configuración, en el bloque vars, establece el campo health_check_schedule en un valor adecuado, en formato cron.
      Programar en formato cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Genera credenciales predeterminadas de la aplicación (ADC) para proporcionar acceso a Terraform. Si usas Cloud Shell, puedes ejecutar el siguiente comando:

    gcloud auth application-default login
    
  8. Implementa el blueprint para aprovisionar la infraestructura de GKE con tipos de máquinas A3 Ultra:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml
    
  9. Cuando se te solicite, selecciona (A)pply para implementar el blueprint.

    • El blueprint crea redes de VPC, una red de VPC de RDMA para GPU, cuentas de servicio, un clúster y un grupo de nodos.
    • Para admitir la plantilla de trabajo fio-bench-job-template en el blueprint, se crean recursos de buckets, almacenamiento de red y volúmenes persistentes deGoogle Cloud .

Crea un clúster y ejecuta cargas de trabajo con XPK

El kit de tratamiento de datos acelerado (XPK) te permite aprovisionar y utilizar clústeres rápidamente. XPK genera infraestructura preconfigurada y optimizada para el entrenamiento, ideal para cuando la ejecución de la carga de trabajo es tu enfoque principal.

Crea un clúster y ejecuta cargas de trabajo con VMs A3 Ultra usando XPK:

  1. Instala las herramientas necesarias para cumplir con los requisitos previos de XPK.
  2. Copia el número de versión de la versión etiquetada más reciente de XPK, por ejemplo, "v0.8.0". En el siguiente comando, reemplaza XPK_TAG por el número de la versión más reciente del XPK.
  3. Abre una ventana de shell en una máquina Linux y, luego, ingresa los siguientes comandos para clonar XPK desde el repositorio de Git y, luego, instalar los paquetes necesarios:

      ## Setup virtual environment.
      VENV_DIR=~/venvp3
      python3 -m venv $VENV_DIR
      source $VENV_DIR/bin/activate
      ## Clone the repository.
      git clone --branch XPK_TAG https://github.com/google/xpk.git
      cd xpk
      ## Install required packages
      make install && export PATH=$PATH:$PWD/bin
    
  4. Crea un clúster estándar con VMs A3 Ultra. Puedes aprovisionar los nodos del clúster con capacidad reservada:

      python3 xpk.py cluster create \
         --cluster=CLUSTER_NAME \
         --device-type=h200-141gb-8 \
         --zone=COMPUTE_ZONE  \
         --project=PROJECT_ID \
         --num-nodes=NUM_NODES \
         --reservation=RESERVATION_NAME
    

    Reemplaza las siguientes variables:

    • CLUSTER_NAME: Es un nombre para el clúster.
    • COMPUTE_ZONE: Es la zona de procesamiento del grupo de nodos de máquinas A3 Ultra. Para usar la capacidad reservada, asegúrate de usar la zona en la que reservaste la capacidad. En general, recomendamos elegir una zona cercana al usuario para minimizar la latencia.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • NUM_NODES: Es la cantidad de nodos trabajadores en el grupo de nodos.
    • RESERVATION_NAME: Es el nombre de tu reserva.

      XPK ofrece argumentos adicionales para la creación de clústeres, incluidos los que se usan para crear clústeres privados, crear Vertex AI TensorBoards y usar el aprovisionamiento automático de nodos. Para obtener más información, consulta la guía de creación de clústeres para XPK.

  5. Verifica que el clúster se haya creado de forma correcta:

      python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID
    
  6. Opcional: Ejecuta una carga de trabajo para probar el entorno del clúster:

      python3 xpk.py workload create \
         --workload WORKLOAD_NAME --command "echo goodbye" \
         --cluster CLUSTER_NAME \
         --device-type=h200-141gb-8 \
         --num-nodes=WORKLOAD_NUM_NODES \
         --zone=COMPUTE_ZONE \
         --project=PROJECT_ID
    

    Reemplaza las siguientes variables:

    • WORKLOAD_NAME: Es el nombre de tu carga de trabajo.
    • CLUSTER_NAME: el nombre del clúster
    • WORKLOAD_NUM_NODES: Es la cantidad de nodos de trabajo que se usan para la ejecución de la carga de trabajo.
    • COMPUTE_ZONE: Es la zona de procesamiento para el grupo de nodos de máquinas A3 Ultra.
    • PROJECT_ID: Es el Google Cloud ID del proyecto.

Prueba el rendimiento de la red

Te recomendamos que valides la funcionalidad de los clústeres aprovisionados. Para ello, usa las pruebas de NCCL/gIB, que son pruebas de la biblioteca de comunicación colectiva de NVIDIA (NCCL) optimizadas para el entorno de Google.

Ejecuta comparativas reproducibles

Puedes usar benchmarks de reproducción del entrenamiento previo para modelos grandes de aprendizaje automático de código abierto en VMs A4 y A3 Ultra en GKE.

Cada receta te proporciona las instrucciones para completar las siguientes tareas:

  • Prepara tu entorno.
  • Ejecuta la comparativa.
  • Analiza los resultados de las comparativas. Esto incluye los resultados de la comparativa y los registros detallados para un análisis posterior.

Para ver todas las recetas disponibles, consulta el repositorio de GitHub de recetas de GPU.

Modelos Framework Receta
Llama-3.1-70B MaxText Carga de trabajo de 32 nodos
Llama-3.1-70B NeMo Carga de trabajo de 32 nodos
Mixtral-8-7B NeMo Carga de trabajo de 32 nodos

Limpia los recursos creados por Cluster Toolkit

Para evitar cargos recurrentes por los recursos que se usan en esta página, limpia los recursos aprovisionados por Cluster Toolkit, incluidas las redes de VPC y el clúster de GKE:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

Reemplaza CLUSTER_NAME por el nombre del clúster. En el caso de los clústeres creados con Cluster Toolkit, el nombre del clúster se basa en DEPLOYMENT_NAME.

¿Qué sigue?