이 페이지에서는 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 클러스터를 만드는 방법 선택
다음 클러스터 생성 옵션은 클러스터 구성 및 워크로드 예약의 용이성과 유연성이 각각 다릅니다.
컴퓨팅, 스토리지, 네트워킹 리소스의 기본 구성과 GPUDirect RDMA-over-Converged-Ethernet (RoCE)이 사용 설정된 클러스터를 만듭니다.
- 클러스터 툴킷을 사용하여 프로덕션에 즉시 사용 가능한 GKE 클러스터를 빠르게 만듭니다.
- 가속 처리 키트 (XPK)를 사용하여 개념 증명 및 테스트를 위한 GKE 클러스터를 빠르게 만듭니다.
또는 GKE 클러스터를 수동으로 만들어 기존 프로덕션 GKE 환경을 정확하게 맞춤설정하거나 확장할 수 있습니다. AI에 최적화된 GKE 클러스터를 수동으로 만들려면 다음 페이지 중 하나를 참고하세요.
- A4X: A4X를 사용하는 맞춤 AI 최적화 GKE 클러스터를 만듭니다.
- A4 또는 A3 Ultra: A4 또는 A3 Ultra를 사용하는 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)
- Kubernetes Engine 관리자(
소비 옵션 선택 및 용량 확보
소비 옵션을 선택합니다. GPU 리소스를 가져와 사용하는 방법에 따라 선택하세요. 자세한 내용은 사용 옵션 선택을 참고하세요.
GKE의 경우 소비 옵션을 선택할 때 다음 추가 정보를 고려하세요.
- A4X VM은 flex-start로 프로비저닝할 수 없습니다.
- flex-start(미리보기) 및 GKE에 대한 자세한 내용은 flex-start를 사용한 GPU 획득 가능성 정보를 참고하세요.
- Flex-start는 최선의 방식의 간단한 배치를 사용합니다. 토폴로지를 검사하려면 GKE 클러스터의 노드 물리적 토폴로지 보기를 참고하세요.
- 압축 배치를 구성한 경우에만 스팟 VM을 사용할 때 토폴로지 정보를 가져올 수 있습니다.
용량 확보 용량을 확보하는 프로세스는 각 소비 옵션마다 다릅니다.
선택한 소비 옵션의 프로세스에 대해 알아보려면 용량 개요를 참고하세요.
요구사항
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
- Cloud Shell을 실행합니다. 다른 환경을 사용할 수도 있지만, 종속 항목이 클러스터 툴킷에 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 안내에 따라 종속 항목을 설치하여 다른 환경을 준비하세요.
git 저장소에서 Cluster Toolkit을 클론합니다.
cd ~ git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.gitCluster Toolkit을 설치합니다.
cd cluster-toolkit && git checkout main && makeTerraform 배포 상태를 저장할 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 배포의 상태를 저장할 컴퓨팅 리전입니다.
GitHub 저장소의
examples/gke-a4x/gke-a4x-deployment.yaml청사진에서terraform_backend_defaults및vars섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.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파일을 수정하세요.필요한 경우 클러스터에서 클러스터 상태 스캐너 (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)
Terraform에 대한 액세스 권한을 제공하기 위해 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성합니다. Cloud Shell을 사용하는 경우 다음 명령어를 실행하면 됩니다.
gcloud auth application-default loginA4X 머신 유형을 사용하여 GKE 인프라를 프로비저닝하도록 블루프린트를 배포합니다.
cd ~/cluster-toolkit ./gcluster deploy -d \ examples/gke-a4x/gke-a4x-deployment.yaml \ examples/gke-a4x/gke-a4x.yaml메시지가 표시되면 적용을 선택하여 블루프린트를 배포합니다.
- 이 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
- 청사진에서
fio-bench-job-template작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.
A4
- Cloud Shell을 실행합니다. 다른 환경을 사용할 수도 있지만, 종속 항목이 클러스터 툴킷에 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 안내에 따라 종속 항목을 설치하여 다른 환경을 준비하세요.
git 저장소에서 Cluster Toolkit을 클론합니다.
cd ~ git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.gitCluster Toolkit을 설치합니다.
cd cluster-toolkit && git checkout main && makeTerraform 배포 상태를 저장할 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 배포의 상태를 저장할 컴퓨팅 리전입니다.
클러스터를 만들기 위해 수정해야 하는 파일은 배포에 사용하는 소비 옵션에 따라 달라집니다. 해당 소비 옵션의 프로비저닝 모델에 해당하는 탭을 선택하세요.
예약에 따름
GitHub 저장소의
examples/gke-a4/gke-a4-deployment.yaml청사진에서terraform_backend_defaults및vars섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.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을 수정합니다.유연한 시작
GitHub 저장소의
examples/gke-a4/gke-a4-deployment.yaml청사진에서terraform_backend_defaults및vars섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.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입니다.
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의 경우 다음을 수행합니다.
vars블록에gpu_nominal_quota: NOMINAL_QUOTA를 추가합니다.gpu_nominal_quota값은ClusterQueue사양에서 GPU의nominalQuota을 설정하는 데 사용됩니다 (아래에서ClusterQueue설정 단계 참고). 이 예에서ClusterQueue는 GPU 요청의 합계가NOMINAL_QUOTA값보다 작거나 같은 경우에만 워크로드를 허용합니다.ClusterQueue에 대한 자세한 내용은 다음 클러스터 대기열의 Kueue 문서를 참고하세요.kueue블록을 다음과 같이 업데이트합니다.kueue: install: true config_path: $(vars.kueue_configuration_path) config_template_vars: num_gpus: $(vars.gpu_nominal_quota)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로 바꿉니다.
스팟
GitHub 저장소의
examples/gke-a4/gke-a4-deployment.yaml청사진에서terraform_backend_defaults및vars섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.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입니다.
GitHub 저장소의
examples/gke-a4/gke-a4.yaml청사진에서 다음 변경사항을 적용합니다.vars블록에서 전체reservation블록 (reservation줄 자체 포함)을spot: true로 바꿉니다.id: a4-pool에서reservation_affinity블록을 삭제합니다. 이 블록을 다음 줄로 바꿉니다.spot: $(vars.spot)
필요한 경우 클러스터에서 클러스터 상태 스캐너 (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)
Terraform에 대한 액세스 권한을 제공하기 위해 애플리케이션 기본 사용자 인증 정보 (ADC)를 생성합니다. Cloud Shell을 사용하는 경우 다음 명령어를 실행하면 됩니다.
gcloud auth application-default login청사진을 배포하여 A4 머신 유형을 사용하여 GKE 인프라를 프로비저닝합니다.
cd ~/cluster-toolkit ./gcluster deploy -d \ examples/gke-a4/gke-a4-deployment.yaml \ examples/gke-a4/gke-a4.yaml메시지가 표시되면 적용을 선택하여 블루프린트를 배포합니다.
- 이 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
- 청사진에서
fio-bench-job-template작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.
A3 Ultra
- Cloud Shell을 실행합니다. 다른 환경을 사용할 수도 있지만, 종속 항목이 클러스터 툴킷에 이미 사전 설치되어 있으므로 Cloud Shell을 사용하는 것이 좋습니다. Cloud Shell을 사용하지 않으려면 안내에 따라 종속 항목을 설치하여 다른 환경을 준비하세요.
git 저장소에서 Cluster Toolkit을 클론합니다.
cd ~ git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.gitCluster Toolkit을 설치합니다.
cd cluster-toolkit && git checkout main && makeTerraform 배포 상태를 저장할 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 배포의 상태를 저장할 컴퓨팅 리전입니다.
클러스터를 만들기 위해 수정해야 하는 파일은 배포에 사용하는 소비 옵션에 따라 달라집니다. 해당 소비 옵션의 프로비저닝 모델에 해당하는 탭을 선택하세요.
예약에 따름
GitHub 저장소의
examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml청사진에서terraform_backend_defaults및vars섹션의 다음 변수를 배포의 특정 값과 일치하도록 바꿉니다.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을 수정합니다.유연한 시작
GitHub 저장소의
examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml청사진에서terraform_backend_defaults및vars섹션의 다음 변수를 배포의 특정 값과 일치하도록 바꿉니다.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입니다.
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의 경우 다음 세 단계를 따르세요.
vars블록에gpu_nominal_quota: NOMINAL_QUOTA를 추가합니다.gpu_nominal_quota값은ClusterQueue사양에서 GPU의nominalQuota을 설정하는 데 사용됩니다. 이 예시에서ClusterQueue는 GPU 요청의 합계가NOMINAL_QUOTA값보다 작거나 같은 경우에만 워크로드를 허용합니다.ClusterQueue에 대한 자세한 내용은 다음 클러스터 대기열의 Kueue 문서를 참고하세요.kueue블록을 다음과 같이 업데이트합니다.kueue: install: true config_path: $(vars.kueue_configuration_path) config_template_vars: num_gpus: $(vars.gpu_nominal_quota)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로 바꿉니다.
스팟
GitHub 저장소의
examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml청사진에서terraform_backend_defaults및vars섹션에 배포의 특정 값과 일치하는 다음 설정을 입력합니다.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입니다.
GitHub 저장소의
examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml청사진에서 다음 변경사항을 적용합니다.vars블록에서 전체reservation블록 (reservation줄 자체 포함)을spot: true로 바꿉니다.id: a3-ultragpu-pool에서reservation_affinity블록을 삭제합니다. 이 블록을 다음 줄로 바꿉니다.spot: $(vars.spot)
필요한 경우 클러스터에서 클러스터 상태 스캐너 (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)
Terraform에 대한 액세스 권한을 제공하기 위해 애플리케이션 기본 사용자 인증 정보(ADC)를 생성합니다. Cloud Shell을 사용하는 경우 다음 명령어를 실행하면 됩니다.
gcloud auth application-default login청사진을 배포하여 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메시지가 표시되면 적용을 선택하여 블루프린트를 배포합니다.
- 이 청사진은 VPC 네트워크, GPU RDMA VPC 네트워크, 서비스 계정, 클러스터, 노드 풀을 만듭니다.
- 청사진에서
fio-bench-job-template작업 템플릿을 지원하기 위해Google Cloud 버킷, 네트워크 스토리지, 영구 볼륨 리소스가 생성됩니다.
XPK를 사용하여 클러스터 만들기 및 워크로드 실행
가속 처리 키트 (XPK)를 사용하면 클러스터를 빠르게 프로비저닝하고 활용할 수 있습니다. XPK는 워크로드 실행이 기본 초점인 경우에 적합한 사전 구성된 학습 최적화 인프라를 생성합니다.
XPK를 사용하여 A3 Ultra VM으로 클러스터를 만들고 워크로드를 실행합니다.
- XPK 기본 요건을 충족하는 데 필요한 도구를 설치합니다.
- XPK의 태그가 지정된 최신 버전 번호를 복사합니다(예: 'v0.8.0'). 다음 명령어에서
XPK_TAG을 최신 XPK 버전 번호로 바꿉니다. 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/binA3 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 프로젝트 IDNUM_NODES: 노드 풀의 워커 노드 수입니다.RESERVATION_NAME: 예약의 이름XPK는 비공개 클러스터 생성, Vertex AI Tensorboard 생성, 노드 자동 프로비저닝 사용을 위한 인수를 비롯하여 클러스터 생성에 사용할 수 있는 추가 인수를 제공합니다. 자세한 내용은 XPK의 클러스터 생성 가이드를 참고하세요.
클러스터가 성공적으로 생성되었는지 확인합니다.
python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID선택사항: 워크로드를 실행하여 클러스터 환경을 테스트합니다.
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다음 변수를 바꿉니다.
네트워크 성능 테스트
프로비저닝된 클러스터의 기능을 검증하는 것이 좋습니다. 이렇게 하려면 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을 기반으로 합니다.
다음 단계
- TAS 및 Kueue를 사용하여 GKE 클러스터에서 워크로드를 예약하는 방법을 알아보려면 Topology Aware Scheduling로 GKE 워크로드 예약을 참고하세요.
- GKE 클러스터 및 AI 워크로드와 관련된 일반적인 이벤트를 관리하는 방법을 알아보려면 AI에 최적화된 GKE 클러스터 관리를 참고하세요.
- 환경을 테스트하여 올바르게 설정하고 최적화하는 방법에 대한 자세한 내용은 클러스터 네트워킹 최적화 개요를 참고하세요.