기본 구성으로 AI에 최적화된 GKE 클러스터 만들기

이 페이지에서는 A4X, A4, A3 Ultra, A3 Mega, A3 High (GPU 8개) 가상 머신 (VM)을 사용하여 AI 및 ML 워크로드를 지원하는 AI 최적화 Google Kubernetes Engine(GKE) 클러스터를 만드는 방법을 보여줍니다.

A4X, A4, A3 Ultra, A3 Mega, A3 High (8 GPU) 머신 시리즈는 대규모 AI/ML 클러스터를 실행할 수 있도록 설계되었으며, 워크로드 배치 지정, 고급 클러스터 유지보수 제어, 토폴로지 인식 스케줄링과 같은 기능을 제공합니다. 자세한 내용은 클러스터 관리 개요를 참조하세요.

GKE는 조직의 요구사항에 맞는 다양한 워크로드를 실행할 수 있는 단일 플랫폼을 제공합니다. 여기에는 고성능 분산 사전 학습, 모델 미세 조정, 모델 추론, 애플리케이션 서빙, 지원 서비스가 포함됩니다. GKE는 여러 플랫폼을 관리하는 운영 부담을 줄여줍니다.

AI 최적화 GKE 클러스터를 만드는 방법 선택

다음 클러스터 생성 옵션은 클러스터 구성 및 워크로드 예약의 용이성과 유연성이 각각 다릅니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
  • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
  • GKE 클러스터 및 연결된 서비스 계정을 만들고 관리하는 데 필요한 권한이 있는지 확인합니다.
    • Kubernetes Engine 관리자(roles/container.admin)
    • Compute 관리자(roles/compute.admin)
    • 스토리지 관리자(roles/storage.admin)
    • 프로젝트 IAM 관리자(roles/resourcemanager.projectIamAdmin)
    • 서비스 계정 관리자(roles/iam.serviceAccountAdmin)
    • 서비스 계정 사용자(roles/iam.serviceAccountUser)
    • 서비스 사용량 소비자(roles/serviceusage.serviceUsageConsumer)
    • 역할 관리자 (roles/iam.roleAdmin)
    • Secret Manager 보안 비밀 버전 관리자 (roles/secretmanager.secretVersionManager)

소비 옵션 선택 및 용량 확보

  1. 소비 옵션을 선택합니다. GPU 리소스를 가져와 사용하는 방법에 따라 선택하세요. 자세한 내용은 사용 옵션 선택을 참고하세요.

    GKE의 경우 소비 옵션을 선택할 때 다음 추가 정보를 고려하세요.

  2. 용량 확보 용량을 확보하는 프로세스는 각 소비 옵션마다 다릅니다.

    선택한 소비 옵션의 프로세스에 대해 알아보려면 용량 개요를 참고하세요.

요구사항

AI 최적화 GKE 클러스터에는 다음 요구사항이 적용됩니다.

  • A4X의 경우 1.33 이상의 경우 GKE 버전 1.33.4-gke.1036000 이상을 사용해야 합니다. 또는 1.32의 경우 GKE 버전 1.32.8-gke.1108000 이상을 사용합니다. 이러한 버전을 통해 A4X는 다음을 사용합니다.

    • R580: A4X의 최소 GPU 드라이버 버전입니다.
    • 일관된 드라이버 기반 메모리 관리(CDMM)(기본적으로 사용 설정됨) NVIDIA는 Kubernetes 클러스터가 메모리 과다 보고 문제를 해결하기 위해 이 모드를 사용 설정할 것을 권장합니다. CDMM을 사용하면 운영체제 (OS) 대신 드라이버를 통해 GPU 메모리를 관리할 수 있습니다. 이 접근 방식을 사용하면 OS에서 GPU 메모리를 온라인 상태로 전환하는 것을 방지하고 GPU 메모리를 OS에 비균일 메모리 액세스 (NUMA) 노드로 노출할 수 있습니다. CDMM이 사용 설정된 경우 멀티 인스턴스 GPU는 지원되지 않습니다. CDMM에 관한 자세한 내용은 하드웨어 및 소프트웨어 지원을 참고하세요.
    • A4X 노드 풀이 A4X의 네트워킹 기능을 사용하도록 설정하는 것이 권장되는 GPUDirect RDMA
  • 머신 유형에 따라 최소 GPU 드라이버 버전을 사용해야 합니다.

    • A4X: A4X VM의 GB200 GPU에는 최소 R580 GPU 드라이버 버전이 필요합니다. 앞서 언급한 버전 요구사항을 참고하세요.
    • A4: A4 VM의 B200 GPU에는 최소 R570 GPU 드라이버 버전이 필요합니다. GKE는 기본적으로 A4에 필요한 최소 버전인 1.32.1-gke.1729000 이상을 실행하는 모든 A4 노드에 이 드라이버 버전을 자동으로 설치합니다.
    • A3 Ultra: A3 Ultra VM의 H200 GPU에는 최소 R550 GPU 드라이버 버전이 필요하며, 이는 GKE 1.31에서 latest 드라이버 버전으로 제공됩니다. A3 Ultra의 경우 GKE 1.31로 gpu-driver-version=latest을 설정해야 합니다. GKE 버전 1.31.5-gke.1169000 이상에서는 GKE가 기본적으로 A3 Ultra 노드에 R550 GPU 드라이버 버전을 자동으로 설치합니다.
  • A3 Ultra 노드 풀의 경우 디스크 유형을 hyperdisk-balanced로 설정해야 합니다.

  • GPUDirect RDMA를 사용하려면 머신 유형에 따라 다음 최소 버전을 사용하세요.

    • A4X: 이전에 언급한 버전 요구사항을 참고하세요.
    • A4: 1.32.2-gke.1475000 이상을 사용합니다.
    • A3 Ultra: 1.31.4-gke.1183000 이상을 사용합니다.
  • GPUDirect RDMA를 사용하려면 GKE 노드가 Container-Optimized OS 노드 이미지를 사용해야 합니다. Ubuntu 및 Windows 노드 이미지는 지원되지 않습니다.

  • 예약에 따름 프로비저닝 모델을 사용하여 A4X로 클러스터를 만들어야 합니다. 다른 프로비저닝 모델은 지원되지 않습니다.

클러스터 만들기

다음 안내에 따라 Cluster Toolkit 또는 XPK를 사용하여 클러스터를 만듭니다.

Cluster Toolkit을 사용하여 클러스터 만들기

이 섹션에서는 클러스터 생성 프로세스를 안내하여 프로젝트가 권장사항을 따르고 AI 최적화 GKE 클러스터의 요구사항을 충족하는지 확인합니다.

A4X

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수도 있지만, 종속 항목이 클러스터 툴킷에 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 안내에 따라 종속 항목을 설치하여 다른 환경을 준비하세요.
  2. git 저장소에서 Cluster Toolkit을 클론합니다.

    cd ~
    git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
    
  3. Cluster Toolkit을 설치합니다.

    cd cluster-toolkit && git checkout main && make
    
  4. Terraform 배포 상태를 저장할 Cloud Storage 버킷을 만듭니다.

    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
    

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포의 상태를 저장할 컴퓨팅 리전입니다.
  5. GitHub 저장소의 examples/gke-a4x/gke-a4x-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.

    • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4x입니다.
    • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
    • COMPUTE_ZONE: A4X 머신의 노드 풀의 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • NODE_COUNT: 클러스터의 노드 풀에 있는 A4X 노드 수입니다. 18개 이하여야 합니다. NVLink 도메인을 사용하여 하나의 하위 블록에서 1x72의 GPU 토폴로지를 얻으려면 18개 노드를 사용하는 것이 좋습니다.
    • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
    • extended_reservation 필드의 경우 노드 풀을 프로비저닝할 때 예약의 특정 블록을 타겟팅할지 여부에 따라 다음 중 하나를 사용합니다.

      • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름(RESERVATION_NAME)을 제공합니다.
      • 예약 내의 특정 블록을 타겟팅하려면 다음 형식으로 예약 및 블록 이름을 사용하세요.

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

      예약에서 사용 가능한 블록을 모르는 경우 예약 토폴로지 보기를 참고하세요.

    • 시스템 및 A4X 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 200입니다.
      • A4X_NODE_POOL_DISK_SIZE_GB: A4X 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.

    고급 설정을 수정하려면 examples/gke-a4x/gke-a4x.yaml 파일을 수정하세요.

  6. 필요한 경우 클러스터에서 클러스터 상태 스캐너 (CHS)를 사용 설정할 수 있습니다. CHS는 클러스터가 워크로드를 실행할 준비가 되었는지 확인하는 테스트를 실행하여 GPU 클러스터의 상태를 확인합니다. CHS를 사용 설정하려면 examples/gke-a4x/gke-a4x-deployment.yaml 파일에서 다음을 변경하세요.

    • vars 블록에서 enable_periodic_health_checks 필드를 true로 설정합니다.

    • 기본적으로 상태 점검은 매주 일요일 오전 12시(PST)에 실행됩니다. 이 설정을 변경하려면 vars 블록에서 health_check_schedule 필드를 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. Terraform에 대한 액세스 권한을 제공하기 위해 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성합니다. Cloud Shell을 사용하는 경우 다음 명령어를 실행하면 됩니다.

    gcloud auth application-default login
    
  8. A4X 머신 유형을 사용하여 GKE 인프라를 프로비저닝하도록 블루프린트를 배포합니다.

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml
    
  9. 메시지가 표시되면 적용을 선택하여 블루프린트를 배포합니다.

    • 이 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

A4

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수도 있지만, 종속 항목이 클러스터 툴킷에 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 안내에 따라 종속 항목을 설치하여 다른 환경을 준비하세요.
  2. git 저장소에서 Cluster Toolkit을 클론합니다.

    cd ~
    git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
    
  3. Cluster Toolkit을 설치합니다.

    cd cluster-toolkit && git checkout main && make
    
  4. Terraform 배포 상태를 저장할 Cloud Storage 버킷을 만듭니다.

    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
    

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포의 상태를 저장할 컴퓨팅 리전입니다.
  5. 클러스터를 만들기 위해 수정해야 하는 파일은 배포에 사용하는 소비 옵션에 따라 달라집니다. 해당 소비 옵션의 프로비저닝 모델에 해당하는 탭을 선택하세요.

    예약에 따름

    GitHub 저장소의 examples/gke-a4/gke-a4-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.

    • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4입니다.
    • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
    • COMPUTE_ZONE: A4 머신의 노드 풀의 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • NODE_COUNT: 클러스터의 A4 노드 수입니다.
    • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
    • reservation 필드의 경우 노드 풀을 프로비저닝할 때 예약의 특정 블록을 타겟팅할지 여부에 따라 다음 중 하나를 사용합니다.

      • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름 (RESERVATION_NAME)을 제공합니다.
      • 예약 내의 특정 블록을 타겟팅하려면 다음 형식으로 예약 및 블록 이름을 사용하세요.

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

      예약에서 사용 가능한 블록을 모르는 경우 예약 토폴로지 보기를 참고하세요.

    • 시스템 및 A4 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
      • A4_NODE_POOL_DISK_SIZE_GB: A4 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.

    고급 설정을 수정하려면 examples/gke-a4/gke-a4.yaml을 수정합니다.

    유연한 시작

    1. GitHub 저장소의 examples/gke-a4/gke-a4-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.

      • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4입니다.
      • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
      • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
      • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
      • COMPUTE_ZONE: A4 머신의 노드 풀의 컴퓨팅 영역입니다.
      • static_node_count를 삭제합니다.
      • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
      • reservation 필드를 삭제하고 enable_flex_start: true로 바꿉니다. 대기열에 추가된 프로비저닝도 사용하려면 다음 줄에 enable_queued_provisioning: true를 추가합니다. 자세한 내용은 큐에 추가된 프로비저닝을 통한 flex-start로 노드 풀 사용을 참고하세요.
      • 시스템 및 A4 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
        • A4_NODE_POOL_DISK_SIZE_GB: A4 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
    2. GitHub 저장소의 examples/gke-a4/gke-a4.yaml 청사진에서 다음 변경사항을 적용합니다.

      • vars 블록에서 static_node_count를 삭제합니다.
      • vars 블록에서 version_prefix 숫자가 "1.32." 이상인지 확인합니다. GKE에서 flex-start를 사용하려면 클러스터에서 버전 1.32.2-gke.1652000 이상을 사용해야 합니다.
      • vars 블록에서 전체 reservation 블록 (reservation 줄 자체 포함)을 enable_flex_start: true 및 선택적으로 enable_queued_provisioning: true로 바꿉니다.
      • vars 블록에서 대기열에 추가된 프로비저닝이 필요하지 않으면 kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")) 줄을 삭제합니다.
      • id: a4-pool에서 다음 줄을 삭제합니다. static_node_count: $(vars.static_node_count)
      • id: a4-pool에서 reservation_affinity 블록을 삭제합니다. 이 블록을 다음 줄로 바꿉니다.

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • 대기열에 추가된 프로비저닝의 경우 사용 설정하려면 다음 줄을 추가합니다.
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • id: workload-manager-install에서 다음 블록을 삭제합니다.

         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)
        
        • 큐에 추가된 프로비저닝을 통한 flex-start의 경우 다음을 수행합니다.

          1. vars 블록에 gpu_nominal_quota: NOMINAL_QUOTA를 추가합니다. gpu_nominal_quota 값은 ClusterQueue 사양에서 GPU의 nominalQuota을 설정하는 데 사용됩니다 (아래에서 ClusterQueue 설정 단계 참고). 이 예에서 ClusterQueue는 GPU 요청의 합계가 NOMINAL_QUOTA 값보다 작거나 같은 경우에만 워크로드를 허용합니다. ClusterQueue에 대한 자세한 내용은 다음 클러스터 대기열의 Kueue 문서를 참고하세요.

          2. kueue 블록을 다음과 같이 업데이트합니다.

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. kueue-configuration.yaml.tftpl 파일의 콘텐츠를 다음으로 바꿉니다.

            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"
            ---
            
      • id: job-template에서 node_count 변수를 2로 바꿉니다.

    스팟

    1. GitHub 저장소의 examples/gke-a4/gke-a4-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.

      • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다. 기본값은 gke-a4입니다.
      • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
      • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
      • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
      • COMPUTE_ZONE: A4 머신의 노드 풀의 컴퓨팅 영역입니다.
      • STATIC_NODE_COUNT: 클러스터의 A4 노드 수입니다.
      • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
      • reservation 줄 자체를 포함한 전체 reservation 블록을 spot: true로 바꿉니다.
      • 시스템 및 A4 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
        • A4_NODE_POOL_DISK_SIZE_GB: A4 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
    2. GitHub 저장소의 examples/gke-a4/gke-a4.yaml 청사진에서 다음 변경사항을 적용합니다.

      • vars 블록에서 전체 reservation 블록 (reservation 줄 자체 포함)을 spot: true로 바꿉니다.
      • id: a4-pool에서 reservation_affinity 블록을 삭제합니다. 이 블록을 다음 줄로 바꿉니다.

        • spot: $(vars.spot)
  6. 필요한 경우 클러스터에서 클러스터 상태 스캐너 (CHS)를 사용 설정할 수 있습니다. CHS는 클러스터가 워크로드를 실행할 준비가 되었는지 확인하는 테스트를 실행하여 GPU 클러스터의 상태를 확인합니다. CHS를 사용 설정하려면 examples/gke-a4/gke-a4-deployment.yaml 파일에서 다음을 변경하세요.

    • vars 블록에서 enable_periodic_health_checks 필드를 true로 설정합니다.

    • 기본적으로 상태 점검은 매주 일요일 오전 12시(PST)에 실행됩니다. 이 설정을 변경하려면 vars 블록에서 health_check_schedule 필드를 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. Terraform에 대한 액세스 권한을 제공하기 위해 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성합니다. Cloud Shell을 사용하는 경우 다음 명령어를 실행하면 됩니다.

    gcloud auth application-default login
    
  8. 청사진을 배포하여 A4 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml
    
  9. 메시지가 표시되면 적용을 선택하여 블루프린트를 배포합니다.

    • 이 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

A3 Ultra

  1. Cloud Shell을 실행합니다. 다른 환경을 사용할 수도 있지만, 종속 항목이 클러스터 툴킷에 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 안내에 따라 종속 항목을 설치하여 다른 환경을 준비하세요.
  2. git 저장소에서 Cluster Toolkit을 클론합니다.

    cd ~
    git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
    
  3. Cluster Toolkit을 설치합니다.

    cd cluster-toolkit && git checkout main && make
    
  4. Terraform 배포 상태를 저장할 Cloud Storage 버킷을 만듭니다.

    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
    

    다음 변수를 바꿉니다.

    • BUCKET_NAME: 새 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION_TERRAFORM_STATE: Terraform 배포의 상태를 저장할 컴퓨팅 리전입니다.
  5. 클러스터를 만들기 위해 수정해야 하는 파일은 배포에 사용하는 소비 옵션에 따라 달라집니다. 해당 소비 옵션의 프로비저닝 모델에 해당하는 탭을 선택하세요.

    예약에 따름

    GitHub 저장소의 examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션의 다음 변수를 배포의 특정 값과 일치하도록 바꿉니다.

    • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다.
    • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
    • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
    • COMPUTE_ZONE: A3 Ultra 머신의 노드 풀의 컴퓨팅 영역입니다. 이 영역은 예약에서 머신을 사용할 수 있는 영역과 일치해야 합니다.
    • NODE_COUNT: 클러스터의 A3 Ultra 노드 수입니다.
    • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
    • reservation 필드의 경우 노드 풀을 프로비저닝할 때 예약의 특정 블록을 타겟팅할지 여부에 따라 다음 중 하나를 사용합니다.

      • 예약의 아무 곳에나 노드 풀을 배치하려면 예약 이름 (RESERVATION_NAME)을 제공합니다.
      • 예약 내의 특정 블록을 타겟팅하려면 다음 형식으로 예약 및 블록 이름을 사용하세요.

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

      예약에서 사용 가능한 블록을 모르는 경우 예약 토폴로지 보기를 참고하세요.

    • 시스템 및 A3 Ultra 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB: A3 Ultra 노드 풀의 각 노드에 대한 부팅 디스크의 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.

    고급 설정을 수정하려면 examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml을 수정합니다.

    유연한 시작

    1. GitHub 저장소의 examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션의 다음 변수를 배포의 특정 값과 일치하도록 바꿉니다.

      • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다.
      • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
      • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
      • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
      • COMPUTE_ZONE: A3 Ultra 머신의 노드 풀의 컴퓨팅 영역입니다.
      • static_node_count를 삭제합니다.
      • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
      • reservation 필드를 삭제하고 enable_flex_start: true로 바꿉니다. 대기열에 추가된 프로비저닝도 사용하려면 다음 줄에 enable_queued_provisioning: true를 추가합니다. 자세한 내용은 큐에 추가된 프로비저닝을 통한 flex-start로 노드 풀 사용을 참고하세요.
      • 시스템 및 A3 Ultra 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: A3 Ultra 노드 풀의 각 노드에 대한 부팅 디스크의 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
    2. GitHub 저장소의 examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml 청사진에서 다음 변경사항을 적용합니다.

      • vars 블록에서 static_node_count를 삭제합니다.
      • vars 블록에서 version_prefix 숫자를 "1.32." 이상으로 업데이트합니다. GKE에서 flex-start를 사용하려면 클러스터에서 버전 1.32.2-gke.1652000 이상을 사용해야 합니다.
      • vars 블록에서 전체 reservation 블록 (reservation 줄 자체 포함)을 enable_flex_start: true 및 선택적으로 enable_queued_provisioning: true로 바꿉니다.
      • vars 블록에서 kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")) 줄을 삭제합니다.
      • id: a3-ultragpu-pool에서 다음 줄을 삭제합니다. static_node_count: $(vars.static_node_count)
      • id: a3-ultragpu-pool에서 reservation_affinity 블록을 삭제합니다. 이 블록을 다음 줄로 바꿉니다.

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • 대기열에 추가된 프로비저닝의 경우 사용 설정하려면 다음 줄을 추가합니다.
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • id: workload-manager-install에서 다음 블록을 삭제합니다.

        config_path: $(vars.kueue_configuration_path)
        config_template_vars:
          num_gpus: $(a4-pool.static_gpu_count)
          accelerator_type: $(vars.accelerator_type)
        
        • 큐에 추가된 프로비저닝을 통한 flex-start의 경우 다음 세 단계를 따르세요.

          1. vars 블록에 gpu_nominal_quota: NOMINAL_QUOTA를 추가합니다. gpu_nominal_quota 값은 ClusterQueue 사양에서 GPU의 nominalQuota을 설정하는 데 사용됩니다. 이 예시에서 ClusterQueue는 GPU 요청의 합계가 NOMINAL_QUOTA 값보다 작거나 같은 경우에만 워크로드를 허용합니다. ClusterQueue에 대한 자세한 내용은 다음 클러스터 대기열의 Kueue 문서를 참고하세요.

          2. kueue 블록을 다음과 같이 업데이트합니다.

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. kueue-configuration.yaml.tftpl 파일의 콘텐츠를 다음으로 바꿉니다.

            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"
            ---
            
        • id: job-template 필드에서 node_count 변수를 2로 바꿉니다.

    스팟

    1. GitHub 저장소의 examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml 청사진에서 terraform_backend_defaultsvars 섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.

      • DEPLOYMENT_NAME: 배포의 고유 이름으로, 길이는 6~30자(영문 기준) 사이여야 합니다. 배포 이름이 프로젝트 내에서 고유하지 않으면 클러스터 생성에 실패합니다.
      • BUCKET_NAME: 이전 단계에서 만든 Cloud Storage 버킷의 이름입니다.
      • PROJECT_ID: Google Cloud 프로젝트 ID입니다.
      • COMPUTE_REGION: 클러스터의 컴퓨팅 리전입니다.
      • COMPUTE_ZONE: A3 Ultra 머신의 노드 풀의 컴퓨팅 영역입니다.
      • STATIC_NODE_COUNT: 클러스터의 A3 Ultra 노드 수입니다.
      • IP_ADDRESS/SUFFIX: 클러스터에 연결하도록 허용할 IP 주소 범위입니다. 이 CIDR 블록에는 Terraform을 호출하는 데 사용할 머신의 IP 주소가 포함되어야 합니다. 자세한 내용은 승인된 네트워크 작동 방식을 참고하세요.
      • reservation 줄 자체를 포함한 전체 reservation 블록을 spot: true로 바꿉니다.
      • 시스템 및 A3 Ultra 노드 풀의 각 노드에 대한 부팅 디스크 크기를 설정합니다. 필요한 디스크 크기는 사용 사례에 따라 다릅니다. 예를 들어 디스크를 캐시로 사용하여 이미지를 반복적으로 가져오는 지연 시간을 줄이는 경우 프레임워크, 모델 또는 컨테이너 이미지를 수용하도록 더 큰 디스크 크기를 설정할 수 있습니다.

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: 시스템 노드 풀의 각 노드에 대한 부팅 디스크 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: A3 Ultra 노드 풀의 각 노드에 대한 부팅 디스크의 크기입니다. 허용되는 최소 디스크 크기는 10입니다. 기본값은 100입니다.
    2. GitHub 저장소의 examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml 청사진에서 다음 변경사항을 적용합니다.

      • vars 블록에서 전체 reservation 블록 (reservation 줄 자체 포함)을 spot: true로 바꿉니다.
      • id: a3-ultragpu-pool에서 reservation_affinity 블록을 삭제합니다. 이 블록을 다음 줄로 바꿉니다.

        • spot: $(vars.spot)
  6. 필요한 경우 클러스터에서 클러스터 상태 스캐너 (CHS)를 사용 설정할 수 있습니다. CHS는 클러스터가 워크로드를 실행할 준비가 되었는지 확인하는 테스트를 실행하여 GPU 클러스터의 상태를 확인합니다. CHS를 사용 설정하려면 examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml 파일에서 다음을 변경하세요.

    • vars 블록에서 enable_periodic_health_checks 필드를 true로 설정합니다.

    • 기본적으로 상태 점검은 매주 일요일 오전 12시(PST)에 실행됩니다. 이 설정을 변경하려면 vars 블록에서 health_check_schedule 필드를 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. Terraform에 대한 액세스 권한을 제공하기 위해 애플리케이션 기본 사용자 인증 정보(ADC)를 생성합니다. Cloud Shell을 사용하는 경우 다음 명령어를 실행하면 됩니다.

    gcloud auth application-default login
    
  8. 청사진을 배포하여 A3 Ultra 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml
    
  9. 메시지가 표시되면 적용을 선택하여 블루프린트를 배포합니다.

    • 이 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
    • 청사진에서 fio-bench-job-template 작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.

XPK를 사용하여 클러스터 만들기 및 워크로드 실행

가속 처리 키트 (XPK)를 사용하면 클러스터를 빠르게 프로비저닝하고 활용할 수 있습니다. XPK는 워크로드 실행이 기본 초점인 경우에 적합한 사전 구성된 학습 최적화 인프라를 생성합니다.

XPK를 사용하여 A3 Ultra VM으로 클러스터를 만들고 워크로드를 실행합니다.

  1. XPK 기본 요건을 충족하는 데 필요한 도구를 설치합니다.
  2. XPK의 태그가 지정된 최신 버전 번호를 복사합니다(예: 'v0.8.0'). 다음 명령어에서 XPK_TAG을 최신 XPK 버전 번호로 바꿉니다.
  3. Linux 머신에서 셸 창을 열고 다음 명령어를 입력하여 Git 저장소에서 XPK를 클론하고 필요한 패키지를 설치합니다.

      ## 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. A3 Ultra VM을 사용하여 표준 클러스터를 만듭니다. 예약된 용량을 사용하여 클러스터의 노드를 프로비저닝할 수 있습니다.

      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
    

    다음 변수를 바꿉니다.

    • CLUSTER_NAME: 클러스터 이름입니다.
    • COMPUTE_ZONE: A3 Ultra 머신의 노드 풀에 대한 컴퓨팅 영역입니다. 예약된 용량을 사용하려면 용량을 예약한 영역을 사용해야 합니다. 일반적으로 지연 시간을 최소화하기 위해 사용자와 가까운 영역을 선택하는 것이 좋습니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID
    • NUM_NODES: 노드 풀의 워커 노드 수입니다.
    • RESERVATION_NAME: 예약의 이름

      XPK는 비공개 클러스터 생성, Vertex AI Tensorboard 생성, 노드 자동 프로비저닝 사용을 위한 인수를 비롯하여 클러스터 생성에 사용할 수 있는 추가 인수를 제공합니다. 자세한 내용은 XPK의 클러스터 생성 가이드를 참고하세요.

  5. 클러스터가 성공적으로 생성되었는지 확인합니다.

      python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID
    
  6. 선택사항: 워크로드를 실행하여 클러스터 환경을 테스트합니다.

      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
    

    다음 변수를 바꿉니다.

    • WORKLOAD_NAME: 워크로드의 이름입니다.
    • CLUSTER_NAME: 클러스터의 이름입니다.
    • WORKLOAD_NUM_NODES: 워크로드 실행에 사용되는 작업자 노드 수입니다.
    • COMPUTE_ZONE: A3 Ultra 머신의 노드 풀의 컴퓨팅 영역입니다.
    • PROJECT_ID: Google Cloud 프로젝트 ID입니다.

네트워크 성능 테스트

프로비저닝된 클러스터의 기능을 검증하는 것이 좋습니다. 이렇게 하려면 Google 환경에 최적화된 NVIDIA Collective Communications Library (NCCL) 테스트NCCL/gIB 테스트를 사용하세요.

재현 가능한 벤치마크 실행

GKE의 A4 및 A3 Ultra VM에서 대규모 머신러닝 오픈 모델의 사전 학습 벤치마크를 재현할 수 있습니다.

각 레시피는 다음 작업을 완료하는 방법을 안내합니다.

  • 환경을 준비합니다.
  • 벤치마크를 실행합니다.
  • 벤치마크 결과를 분석합니다. 여기에는 벤치마크 결과와 추가 분석을 위한 상세 로그가 포함됩니다.

사용 가능한 모든 레시피를 보려면 GPU 레시피 GitHub 저장소를 참고하세요.

모델 프레임워크 레시피
Llama-3.1-70B MaxText 32개 노드 워크로드
Llama-3.1-70B NeMo 32개 노드 워크로드
Mixtral-8-7B NeMo 32개 노드 워크로드

Cluster Toolkit으로 생성된 리소스 정리

이 페이지에서 사용한 리소스에 대한 반복 청구를 방지하려면 VPC 네트워크 및 GKE 클러스터를 비롯하여 클러스터 툴킷에서 프로비저닝한 리소스를 정리합니다.

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

CLUSTER_NAME을 클러스터 이름으로 바꿉니다. Cluster Toolkit으로 생성된 클러스터의 경우 클러스터 이름은 DEPLOYMENT_NAME을 기반으로 합니다.

다음 단계