이 페이지에서는 다중 계층 체크포인트를 사용하여 GKE에서 머신러닝 모델을 학습하는 동안 체크포인트를 안정적으로 저장하고 관리하는 방법을 보여줍니다. 체크포인트 저장 및 관리는 수천 개 이상의 노드를 사용하는 대규모 학습 작업에 매우 중요합니다. 이러한 대규모 작업은 자주 (시간당) 중단되며 복구하는 데 시간이 오래 걸릴 수 있습니다.
이점
다중 계층 체크포인트를 사용하면 다음과 같은 이점이 있습니다.
- 다음 워크로드의 백업, 복제, 자동 복원을 비롯한 완전히 오케스트레이션된 체크포인트 데이터 관리
- TPU에서 실행되는 상태 관리를 위해 Orbax를 사용하는 JAX 학습 실행
- GPU의 PyTorch 워크로드
- 로컬 노드에 저장된 체크포인트에서 학습 작업을 빠르게 복구합니다. 학습 클러스터의 다른 노드에 저장된 체크포인트를 사용하여 복구할 수도 있습니다.
- 클러스터 내 체크포인트가 없는 최악의 시나리오에서 Cloud Storage 백업에 저장된 체크포인트로부터 학습 작업을 빠르게 복원합니다.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화하세요. 이전에 gcloud CLI를 설치한 경우
gcloud components update
를 실행하여 최신 버전을 가져옵니다.
- 프로젝트에 사용할 Cloud Storage 버킷을 만듭니다(아직 없는 경우). 계층적 네임스페이스를 사용 설정해야 합니다. 그렇지 않으면 백업이 실패합니다.
요구사항
다중 계층 체크포인트에는 GKE 클러스터 버전 1.32.4-gke.1415000 이상이 필요합니다.
제한사항
- Autopilot 클러스터는 지원되지 않습니다.
다중 계층 체크포인트를 사용하도록 GKE 노드 구성
이 섹션에서는 새 클러스터와 기존 클러스터에서 GKE 노드를 구성하는 방법을 설명합니다.
새 클러스터에서 노드 구성
다중 계층 체크포인트, Cloud Storage FUSE CSI 드라이버, GKE용 워크로드 아이덴티티 제휴가 사용 설정된 클러스터를 만듭니다. 머신러닝 워크로드에 TPU 슬라이스를 사용하는 경우 TPU 슬라이스 노드 풀의 구성을 포함하도록 클러스터 생성 명령어를 조정해야 합니다.
gcloud container clusters create CLUSTER_NAME \ --addons=HighScaleCheckpointing,GcsFuseCsiDriver \ --node-locations=NODE_LOCATION \ --workload-pool=PROJECT_ID.svc.id.goog \ --cluster-version=CLUSTER_VERSION --location=CLUSTER_LOCATION \ --machine-type=MACHINE_TYPE \ --num-nodes=NUM_NODES
다음 값을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.NODE_LOCATION
: 클러스터 노드의 영역입니다. TPU 용량이 있는 위치입니다.PROJECT_ID
: Google Cloud 프로젝트 IDCLUSTER_VERSION
: 클러스터의 버전입니다. 1.32.4-gke.1415000은 지원되는 최소 버전입니다.CLUSTER_LOCATION
: 클러스터를 만들려는 리전입니다.MACHINE_TYPE
: JobSet 컨트롤러 및 다중 계층 체크포인트 컨트롤러와 같은 구성요소를 실행하는 노드에 사용되는 머신 유형입니다. 대규모 학습의 경우e2-standard-4
머신을 2대 이상 사용하는 것이 좋습니다. 모델 학습에는 이 머신 유형을 사용하지 않습니다. 대신 이 목적을 위해 별도의 노드 풀을 만들며, 가속기 최적화 VM 계열을 사용하는 경우가 많습니다.NUM_NODES
: 각 클러스터 영역에 생성할 노드 수입니다.
기존 클러스터에서 노드 구성
기존 클러스터에서 다중 계층 체크포인트를 사용하려면 다음 명령어를 사용하여 Cloud Storage FUSE CSI 드라이버 및 GKE용 워크로드 아이덴티티 제휴와 함께 사용 설정합니다. 기존 클러스터 버전이 1.32.3-gke.1170000보다 높아야 합니다.
GKE용 워크로드 아이덴티티 제휴 사용 설정
gcloud container clusters update CLUSTER_NAME \ --workload-pool=PROJECT_ID.svc.id.goog \ --location=CLUSTER_LOCATION
다음 값을 바꿉니다.
CLUSTER_NAME
: 클러스터의 이름입니다.PROJECT_ID
: Google Cloud 프로젝트 IDCLUSTER_LOCATION
: 클러스터의 리전
다중 계층 체크포인트 및 Cloud Storage FUSE CSI 드라이버를 사용 설정합니다.
gcloud container clusters update CLUSTER_NAME \ --update-addons=HighScaleCheckpointing=ENABLED,GcsFuseCsiDriver=ENABLED \ --location=CLUSTER_LOCATION
다중 계층 체크포인트를 사용하도록 권한 구성
이 섹션에서는 다중 계층 체크포인트를 사용하도록 권한을 구성하는 방법을 설명합니다.
Cloud Storage 버킷에 대한 액세스 권한 부여
다중 계층 체크포인트 CSI 드라이버에서 사용하는 임시 볼륨은 기존 Cloud Storage 버킷을 사용해야 합니다.
Cloud Storage 버킷에 체크포인트를 저장하려면 다중 계층 체크포인트에 버킷 액세스 권한이 필요합니다. 다중 계층 체크포인트의 Kubernetes 서비스 계정에 버킷의 스토리지 객체 사용자 (roles/storage.objectUser
) IAM 역할을 부여합니다.
gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
--member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-managed-checkpointing/sa/gke-checkpointing-multitier-node" \
--role "roles/storage.objectUser"
다음 값을 바꿉니다.
GCS_BUCKET
: 데이터를 전송할 Cloud Storage 버킷의 이름입니다.PROJECT_ID
: Google Cloud 프로젝트 IDPROJECT_NUMBER
: 자동으로 생성되는 프로젝트의 고유 식별자입니다. 이 값을 찾으려면 프로젝트 만들기 및 관리를 참고하세요.
(선택사항) Compute Engine 기본 서비스 계정에 액세스 권한 부여
Compute Engine 인스턴스에 Cloud Storage 버킷에 대한 읽기 액세스 권한이 필요한 경우 Compute Engine 기본 서비스 계정에 스토리지 객체 뷰어 (roles/storage.objectViewer
) IAM 역할을 부여합니다.
gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
--member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--role roles/storage.objectViewer
JobSet 컨트롤러 배포
JobSet 컨트롤러는 GKE에서 모델 학습을 실행하는 일괄 작업을 관리하며, 리소스 할당은 워크로드를 효율적으로 처리하도록 조정됩니다. 학습 작업 런처가 JobSet을 배포하고 사용하는지 확인합니다.
JobSet 배포에서 관리자 컨테이너의 메모리 요청을 1Gi로, 메모리 한도를 2Gi로, CPU 요청을 1로 늘리려면 다음 패치 명령어를 실행하세요.
kubectl patch -n jobset-system deploy jobset-controller-manager --type json \
--patch '[{"op": "add", "path": "/spec/template/spec/containers/0/resources", "value": {"limits": {"memory": "2Gi"}, "requests": {"cpu": "1", "memory": "1Gi"}}}]'
다중 계층 체크포인트 CSI 드라이버 초기화
이 섹션에서는 워크로드가 실행될 노드에서 다중 계층 체크포인트 CSI 드라이버를 초기화하는 방법을 설명합니다. CSI 드라이버는 모델 학습 프로세스 중에 체크포인트의 저장 및 관리를 처리합니다.
CheckpointConfiguration 만들기
CheckpointConfiguration은 다중 계층 체크포인트 CSI 드라이버를 배포하기 위한 속성을 지정하는 Kubernetes 커스텀 리소스입니다. 이 리소스는 클러스터 범위입니다.
다음
checkpoint.yaml
매니페스트를 만듭니다.apiVersion: checkpointing.gke.io/v1 kind: CheckpointConfiguration metadata: name: MTC_CONFIG_NAME-configuration spec: cloudStorageBucketName: GCS_BUCKET nodeSelector: node.kubernetes.io/instance-type: MACHINE_TYPE tolerations: - key: TOLERATION_KEY operator: Exists effect: NoSchedule inMemoryVolumeSize: IN_MEMORY_VOLUME_SIZE gcsFuseMountOptions: - implicit-dirs - metadata-cache:negative-ttl-secs:0 - metadata-cache:ttl-secs:-1 - metadata-cache:stat-cache-max-size-mb:-1 - metadata-cache:type-cache-max-size-mb:-1 - file-cache:max-size-mb:-1 - file-cache:cache-file-for-range-read:true - file-system:kernel-list-cache-ttl-secs:0 - file-cache:enable-parallel-downloads:true - read_ahead_kb=1024 - write:enable-streaming-writes:true
다음을 바꿉니다.
- MTC_CONFIG_NAME: CheckpointConfiguration의 이름입니다. 이 이름은 클러스터의 전역 이름이며 작업별 이름이 아닙니다.
- GCS_BUCKET: 체크포인트 데이터를 저장할 Cloud Storage 버킷의 이름입니다. 권한이 있는 Cloud Storage 버킷 설정 단계에서 설정한 버킷을 사용합니다.
MACHINE_TYPE: 해당 가속기의 머신 유형입니다. 이 값은 다음 중 하나일 수 있습니다.
- TPU v5p:
ct5p-hightpu-4t
- TPU v5e:
ct5e-hightpu-4t
- TPU v6e:
ct6e-standard-4t
- NVIDIA H100 80GB GPU (A3 시리즈):
GKE를 사용하여 GPU에서 분산 워크로드를 실행하는 방법에 대한 자세한 내용은 멀티 인스턴스 GPU 실행을 참고하세요. TPU의 경우 TPU 슬라이스 노드 풀 만들기를 참고하세요.
- TPU v5p:
TOLERATION_KEY: 이 필드를 사용하면 CSI 드라이버를 일치하는 taint가 있는 노드에 예약할 수 있습니다. 다양한 가속기 유형에서 테인트가 작동하는 방식에 관한 자세한 내용은 다음 페이지를 참고하세요.
IN_MEMORY_VOLUME_SIZE: 메모리 내 체크포인트 캐시의 크기입니다. 수량과 단위 (예: 200Gi)를 지정합니다. 이 값은 다음을 충족해야 합니다.
- TPU의 로컬 체크포인트 크기에 2.2를 곱한 값
- 단일 피어가 있는 GPU의 로컬 체크포인트 크기에 6.6을 곱한 값입니다.
매니페스트를 적용합니다.
kubectl apply -f checkpoint.yaml
CSI 드라이버가 실행 중인지 확인합니다.
kubectl get pod -n gke-managed-checkpointing
출력은 다음과 비슷하게 표시됩니다. 가속화된 노드당 하나의 항목이 있으므로 항목이 여러 개 있습니다.
NAME READY STATUS RESTARTS AGE multitier-driver-e2b033a7-a4e7-496a-87a3-ffd7fcc2e57b-2d4fz 5/5 Running 0 114s
다중 계층 체크포인트 CSI 드라이버 제거
다중 계층 체크포인트 CSI 드라이버를 배포 해제하려면 CheckpointConfiguration
리소스를 삭제하세요. 다중 계층 체크포인트 컨트롤러가 노드에서 CSI 드라이버를 삭제합니다. 이렇게 하면 RAM 디스크가 삭제되고 다른 워크로드를 위해 메모리가 확보됩니다. 예를 들면 다음과 같습니다.
kubectl delete -f checkpoint.yaml
Cloud Storage 백업의 데이터 보관 및 가비지 컬렉션 관리
체크포인트의 Cloud Storage 백업에 대한 보관 정책을 구현할 책임은 사용자에게 있습니다. 다중 계층 체크포인트는 체크포인트 백업을 Cloud Storage에만 쓰고 수정하거나 삭제하지는 않습니다.
다음과 같은 많은 오픈소스 도구에서 보관 및 가비지 수집을 처리할 수 있습니다.
다음 예에서는 backup
디렉터리가 Cloud Storage FUSE를 사용하는 백업 위치에 마운트된 경우 backup-warden
를 사용합니다.
# Add --delete option to actually delete the backups, as is it only shows what would be deleted (dry-run)
backup-warden -p backup \
--hourly 24 \
--daily 7 \
--weekly 5 \
--monthly always \
--yearly always \
--prefer-recent
워크로드 JobSet 매니페스트 업데이트
대규모 체크포인트 볼륨을 포함하도록 작업의 JobSet 매니페스트를 업데이트합니다. 세부정보는 워크로드에 따라 다릅니다.
예를 들어 GKE에서 TPU 멀티슬라이스 배포의 샘플 JobSet을 확장하려면 다음 단계를 따르세요.
jax-tpu
컨테이너에 다음 줄을 추가합니다.volumeMounts: - name: checkpoint mountPath: CHECKPOINT_DIR
CHECKPOINT_DIR를 체크포인트 디렉터리 경로로 바꿉니다.
replicator.yaml
가 생성되고 다중 계층 체크포인트가 체크포인트 저장 작업을 실행하는 위치입니다. 자세한 내용은 애플리케이션에 다중 계층 체크포인트 통합을 참고하세요.작업 사양의
spec.template.spec
필드에 다음 줄을 추가합니다.volumes: - name: checkpoint csi: driver: multitier-checkpoint.csi.storage.gke.io
애플리케이션에 다중 계층 체크포인트 통합
체크포인트 위치 및 복제 준비 상태에 관한 정보를 공유하려면 다음 프로토콜을 사용하여 다중 계층 체크포인트와 통신하도록 애플리케이션을 수정하세요.
시작
이 섹션에서는 애플리케이션이 다중 계층 체크포인트와 상호작용하는 데 필요한 초기 단계를 설명합니다.
리플리케이터는 다중 계층 체크포인트의 핵심 구성요소로, CSI 드라이버의 일부로 모든 노드에서 실행됩니다. 리플리케이터는 로컬 RAM 디스크에서 피어 노드, Cloud Storage와 같은 외부 스토리지에 이르기까지 스토리지 계층 전반에서 체크포인트 복제를 관리합니다.
replicator.yaml
파일은 ML 학습 작업 (프레임워크 코드)과 리플리케이터 구성요소 간의 동적 제어 영역 역할을 합니다. ML 애플리케이션은 학습 작업과 리플리케이터 서비스 모두에서 액세스할 수 있는 로컬 볼륨 (RAMDisk)에 이 파일을 프로그래매틱 방식으로 생성합니다. 이 매니페스트를 사용하면 ML 프레임워크가 백엔드 설정 중에 정의된 정적 인프라 매개변수(예: Cloud Storage 업로드 빈도)와는 별개로 런타임 구성 및 수명 주기 관리 안내를 리플리케이터에 제공할 수 있습니다.
이 상호작용의 구체적인 예는 다음을 참고하세요.
- Cloud TPU에서 JAX에 이 아키텍처를 사용하는 MaxText 프로젝트
- PyTorch 참조 예시: GPU에서 PyTorch 및 NVIDIA NeMO와 함께 이 아키텍처를 활용합니다.
애플리케이션은 시작 중에 다음 단계를 실행해야 합니다.
replicator.yaml
파일이 없을 때까지 기다립니다. 이는 리플리케이터가 애플리케이션에 의해 구성될 준비가 되었음을 나타냅니다.replicator.yaml
파일은 워크로드 JobSet 매니페스트 업데이트 섹션에서 구성한 CHECKPOINT_DIR 위치에 생성됩니다.모델 학습 작업을 처음 만들 때는
replicator.yaml
파일이 없으므로 애플리케이션이 즉시 진행될 수 있습니다. 하지만 실패나 수동 개입으로 인해 작업이 다시 시작된 경우 시스템에서 이전 작업 인스턴스를 계속 처리할 수 있으며 해당 인스턴스의replicator.yaml
가 로컬 볼륨에 계속 있을 수 있습니다.애플리케이션 또는 ML 작업에서 다음과 비슷한 구성으로
replicator.yaml
파일을 만듭니다.Orbax
job-name: orbax framework: orbax assume-data-parallelism: 3 node-rank: 0 nodes: 32 peer-ranks: [1, 16] or peers-per-node: 2 backup-interval-minutes: 30
PyTorch
job-name: nemo framework: pytorch.distributed node-rank: 0 nodes: 32 peer-ranks: [1, 16] or peers-per-node: 2 backup-interval-minutes: 30
이 예시 구성에는 다음 필드가 있습니다.
name
: 학습 작업의 이름입니다.framework
: 학습 작업에서 사용되는 ML 프레임워크입니다.node-rank
: 분산 학습 작업 내 현재 노드의 고유 식별자입니다. 이 파일이 생성된 노드의 노드 순위를 나타냅니다. 실행에 참여하는 각 노드에는 자체 순위가 있습니다.nodes
: 분산 학습 작업에 참여하는 총 노드 수입니다. 이 값은 포드의 메타데이터에서 가져옵니다. ML 학습 작업에서도 이 값을 볼 수 있습니다.peer-ranks
또는peers-per-node
: 복제 토폴로지를 지정하는 두 가지 대체 방법입니다. 이 두 매개변수 중 하나만 있어야 합니다.peer-ranks
: 현재 노드의 체크포인트 데이터를 복제해야 하는 피어 노드의 명시적 순위입니다. 이를 통해 복제 파트너로 사용되는 특정 노드를 세부적으로 제어할 수 있습니다.peers-per-node
: Replicator가 복제를 위해 자동으로 선택해야 하는 노드당 피어 노드 수입니다.
backup-interval-minutes
: 체크포인트가 Cloud Storage에 백업되는 빈도(분)입니다. 이 값을 30분 이상으로 설정하는 것이 좋습니다.
새
replicator.yaml
파일이 시스템에 의해 삭제될 때까지 기다립니다. 이는 리플리케이터가 다시 시작되어 정리 작업을 실행했음을 나타냅니다. 이 단계를 통해 애플리케이션이 다음 섹션의 단계를 실행할 때 로컬 볼륨에 오래된 파일이나 임시 파일이 없도록 할 수 있습니다.
마지막으로 알려진 정상 (LKG) 체크포인트에서 복원
리플리케이터가 초기화되면 다중 계층 체크포인트는 TPU 또는 GPU 작업자당 하나의 심볼릭 링크를 만듭니다. 이러한 심볼릭 링크는 작업에서 체크포인트를 저장하는
replicator.yaml
파일과 동일한 마운트된 로컬 볼륨에 생성됩니다.심볼릭 링크는
<job-name>-s{step}-n<node-rank>-w<worker-index>.restore
형식입니다.해당
.restore
파일에서 각 작업자를 복원합니다. 예를 들어 다음 섹션의 Orbax 복제 체크포인트 관리자 예를 참고하세요.
체크포인트 저장
학습 작업이 진행되는 동안 애플리케이션은 이러한 단계를 여러 번 실행합니다. 저장 작업은 워크로드 JobSet 매니페스트 업데이트에서 구성한 CHECKPOINT_DIR 위치에서 발생합니다.
Orbax
Orbax 체크포인트 만들기 디렉터리 이름은 단계 번호로 지정됩니다. 리플리케이터는 새로 생성된 체크포인트 디렉터리를 감지하고 필요에 따라 복제 또는 백업을 실행하며 자동으로 정리합니다.
Orbax 리플리케이터 체크포인트 관리자를 사용하는 방법에 관한 자세한 내용은 MaxtTest checkpointing
파일을 참고하세요.
리플리케이터 서비스 상호작용의 예는 MaxText max_utils
파일을 참고하세요.
PyTorch
InClusterLocalCheckpointIO
을 맞춤 pytorch_lightning.CheckpointIO
로 사용하여 로컬 스토리지를 통해 올바른 분산 체크포인트를 사용 설정합니다. 다음 예시 명령어는 NVIDIA NeMo 프레임워크를 기반으로 빌드된 참조 구현을 사용하여 다중 계층 체크포인트를 사용 설정합니다.
torchrun train.py <other_train_flags> \
--local-ckpt-dir=CHECKPOINT_DIR \
--local-ckpt-interval=20 \
--job-name=JOB_NAME \
--enable-high-scale-ckpt
다음을 바꿉니다.
CHECKPOINT_DIR
: 체크포인트 디렉터리의 경로입니다.JOB_NAME
: 학습 작업 워크로드의 이름입니다.
클러스터 업그레이드
클러스터 업그레이드의 경우 업그레이드 전후에 CheckpointConfiguration
객체를 삭제하고 다시 만들 수 있습니다. 이 객체에 의해 동적으로 배포되는 노드 체크포인트 드라이버 데몬 세트는 자동으로 업그레이드되지 않으므로 이 작업이 필요합니다.
daemonset 사양을 동일하게 유지하려면 아무 조치도 취하지 않아도 됩니다.
문제 해결
이 섹션에서는 다중 계층 체크포인트와 관련된 문제를 해결하기 위한 문제 해결 안내를 제공합니다. 일반적인 스토리지 문제 해결은 GKE에서 Cloud Storage 문제 해결을 참고하세요.
다중 계층 체크포인트가 사용 설정되지 않음
다음 오류는 클러스터에서 다중 계층 체크포인트가 사용 설정되지 않았음을 나타냅니다.
error: unable to recognize "checkpoint.yaml": no matches for kind "CheckpointConfiguration" in version "checkpointing.gke.io/v1"
CheckpointConfiguration 만들기 단계에서 kubectl apply -f checkpoint.yaml
를 실행한 후 이 오류가 발생할 수 있습니다.
이 문제를 해결하려면 다음 명령어를 사용하여 클러스터에서 다중 계층 체크포인트를 사용 설정했는지 확인하세요.
gcloud container clusters describe CLUSTER_NAME \
--project PROJECT_ID
--location CLUSTER_LOCATION
다중 계층 체크포인트가 사용 설정된 경우 출력은 다음과 비슷해야 합니다.
addonsConfig:
gcePersistentDiskCsiDriverConfig:
enabled: true
gcsFuseCsiDriverConfig:
enabled: true
highScaleCheckpointingConfig:
enabled: true
kubernetesDashboard:
disabled: true
networkPolicyConfig:
disabled: true
다중 계층 체크포인트가 사용 설정되어 있지 않으면 클러스터를 업데이트하여 다중 계층 체크포인트를 사용 설정합니다.
다중 계층 체크포인트 CSI 드라이버가 볼륨을 마운트할 수 없음
CSI 드라이버가 Cloud Storage 볼륨을 마운트할 수 없는 경우 이 문제가 발생할 수 있습니다. 이와 유사한 줄이 여러 개 있을 수 있습니다.
kubectl get pod -n gke-managed-checkpointing
NAME READY STATUS RESTARTS AGE
multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 0/5 Init:0/1 0 6m32s
이 문제를 해결하려면 다음 예와 같이 CSI 드라이버 포드 이벤트를 확인하세요.
kubectl describe pod multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 -n gke-managed-checkpointing
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 17m default-scheduler Successfully assigned gke-managed-checkpointing/multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 to gke-my-cluster-default-pool-353c773f-6d8q
Warning FailedMount 82s (x16 over 17m) kubelet MountVolume.SetUp failed for volume "gcs" : rpc error: code = PermissionDenied desc = failed to get GCS bucket "checkpointing-test-bucket": googleapi: Error 403: Caller does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist)., forbidden
예에 표시된 것처럼 Cloud Storage 버킷 PermissionDenied
오류로 인해 문제가 발생하는 경우 권한을 올바르게 설정하여 문제를 해결할 수 있습니다.
다음 단계
- Google Kubernetes Engine에 TPU Multislice를 배포하는 방법 자세히 알아보기
- Google Kubernetes Engine에서 성능을 위해 Cloud Storage FUSE CSI 드라이버를 최적화하는 방법 알아보기
- Orbax 체크포인트 옵션 살펴보기