성능 조정 권장사항

이 페이지에서는 주요 Cloud Storage FUSE 기능과 구성을 사용하여 Cloud Storage FUSE를 개선하여 특히 학습, 서비스, 체크포인트와 같은 인공지능 및 머신러닝(AI/ML) 워크로드의 최대 처리량과 최적의 성능을 달성하는 방법을 안내합니다.

고려사항

이 페이지에서 권장하는 구성을 적용하기 전에 다음 사항을 고려하세요.

• 이 페이지의 권장 구성은 다음 세 가지 방법으로 적용할 수 있습니다.

  • Cloud Storage FUSE 구성 파일

  • Cloud Storage FUSE CLI 옵션

  • Google Kubernetes Engine만 해당: 샘플 Google Kubernetes Engine YAML 파일

• 최신 버전의 Cloud Storage FUSE를 실행하고 있는지 확인합니다. 권장 구성은 Cloud Storage FUSE 버전 3.0 이상과 GKE 클러스터 버전 1.32.2-gke.1297001 이상에서 실행되는 Google Kubernetes Engine용 Cloud Storage FUSE CSI 드라이버에만 적용해야 합니다.

• 권장 구성은 작업 기간 동안 Cloud Storage 메타데이터를 캐시하며 파일 시스템의 초기 마운트 후에는 확인되지 않습니다. 따라서 최적의 성능을 위해 파일 시스템이 읽기 전용이거나 파일 시스템 시맨틱스가 새 파일에 쓰기 애플리케이션(애플리케이션이 항상 새 파일에 쓰기)인 것이 좋습니다. 다음 AI/ML 워크로드는 새 파일에 쓰기입니다.

  • 체크포인트

  • 학습

  • 제공

  • jax.jit() 캐싱

• 이 페이지의 권장 구성은 메모리 양이 많고 대역폭이 높은 네트워크 인터페이스가 있는 대규모 Cloud GPU 및 Cloud TPU 대형 머신 유형에 대해 검증되었습니다. Cloud GPU와 Cloud TPU 머신 유형은 호스트 노드 구성 내에서 사용 가능한 리소스(예: CPU, 메모리, 로컬 스토리지)의 수가 다를 수 있습니다. 이는 다음과 같은 구성의 성능에 직접적인 영향을 미칠 수 있습니다.

  • A3 Ultra

  • A3 Mega - 1.8TiB 메모리, 6TiB LSSD

  • Cloud TPU v5e - 188GiB 메모리, LSSD 없음

  • Cloud TPU v5p - 448GiB 메모리, LSSD 없음

  • Cloud TPU v6(Trillium) - 1.5TiB 메모리, LSSD 없음

계층적 네임스페이스가 사용 설정된 버킷 사용

항상 계층적 네임스페이스가 사용 설정된 버킷을 사용하세요. 계층적 네임스페이스는 데이터를 계층적 파일 시스템 구조로 구성하여 버킷 내 작업을 더 효율적으로 만듭니다. 따라서 응답 시간이 더 빨라지고 모든 작업에 대한 전체 목록 호출 수가 줄어듭니다.

계층적 네임스페이스의 이점은 다음과 같습니다.

• 계층적 네임스페이스가 있는 버킷은 평면 버킷에 비해 초기 초당 쿼리 수(QPS)가 최대 8배 더 높습니다. 계층적 네임스페이스는 초당 40,000개의 초기 객체 읽기 요청과 8,000개의 초기 객체 쓰기 요청을 지원합니다. 이는 초기 초당 객체 읽기 요청이 5,000개이고 초기 객체 쓰기 요청이 1,000개인 일반적인 Cloud Storage FUSE 플랫 버킷보다 훨씬 높은 수치입니다.

• 계층적 네임스페이스는 Cloud Storage FUSE를 사용한 체크포인트에 원자성을 보장하는 데 필요한 원자적 디렉터리 이름 변경을 제공합니다. 계층적 네임스페이스가 사용 설정된 버킷을 사용하는 것은 특히 대규모로 체크포인트를 지정할 때 유용합니다. ML 프레임워크는 디렉터리 이름 변경을 사용하여 체크포인트를 완료하는데, 이는 빠르고 원자적 명령어이며 계층적 네임스페이스가 사용 설정된 버킷에서만 지원되기 때문입니다. 계층적 네임스페이스가 사용 설정된 버킷을 사용하지 않으려면 비 HNS 버킷의 이름 변경 한도 늘리기를 참조하세요.

계층적 네임스페이스가 사용 설정된 버킷을 만드는 방법을 알아보려면 계층적 네임스페이스가 사용 설정된 버킷 만들기를 참조하세요. 계층적 네임스페이스가 사용 설정된 버킷을 마운트하는 방법은 계층적 네임스페이스가 사용 설정된 버킷 마운트를 참조하세요. 계층적 네임스페이스는 Google Kubernetes Engine 버전 1.31.1-gke.2008000 이상에서 지원됩니다.

디렉터리별 마운트 실행

버킷 내의 특정 디렉터리에 액세스하려면 전체 버킷을 마운트하는 대신 only-dir 마운트 옵션을 사용하여 특정 디렉터리만 마운트하면 됩니다. 디렉터리별 마운트를 실행하면 파일 이름을 확인할 때 순회할 디렉터리 수가 제한되므로 목록 호출이 가속화되고 전체 목록 및 통계 호출 수가 줄어듭니다. LookUpInode 호출과 버킷 또는 디렉터리 액세스 요청은 경로에 있는 각 파일 또는 디렉터리에 대해 목록 및 통계 호출을 자동으로 생성하기 때문입니다.

특정 디렉터리를 마운트하려면 다음 방법 중 하나를 사용하세요.

volumeHandle: BUCKET_NAME



only-dir:DIRECTORY_NAME

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

디렉터리 마운트 실행 방법에 대한 자세한 내용은 버킷 내에 디렉터리 마운트를 참조하세요.

메타데이터 캐시 값 늘리기

반복 읽기의 성능을 개선하려면 Cloud Storage FUSE가 많은 양의 메타데이터를 캐시하고 메타데이터 만료를 우회하도록 구성하면 됩니다. 이렇게 하면 Cloud Storage에 대한 반복적인 메타데이터 요청을 방지하고 성능을 크게 개선할 수 있습니다.

메타데이터 캐시 값을 늘리면 반복적인 Cloud Storage 호출을 방지하기 위해 반복 읽기가 있는 워크로드와 무한 TTL을 설정할 수 있는 읽기 전용 볼륨에 유용합니다.

메타데이터 캐시 값을 늘리기 전에 다음 사항을 고려하세요.

• 무한 수명(TTL)은 읽기 전용이거나 새로 쓰기 전용인 볼륨에만 설정해야 합니다.

• 메타데이터 캐시는 각 노드에서 지정된 마운트 지점의 모든 메타데이터를 캐시하고 Cloud Storage에 대한 추가 액세스 필요성을 없애므로 메모리 구성이 큰 노드에서만 크기가 크게 증가하도록 사용 설정해야 합니다.

• 이 섹션의 구성은 액세스된 모든 메타데이터를 무한 TTL로 캐시하므로 다른 클라이언트가 동일한 Cloud Storage 버킷에서 변경사항을 적용할 때 일관성 보장에 영향을 줄 수 있습니다(예: 파일 덮어쓰기 또는 파일 삭제).

• 메모리 소비가 영향을 받지 않는지 확인하려면 메타데이터 캐시에서 소비하는 메모리 양이 허용되는지 확인하세요. 이 양은 기가바이트까지 늘어날 수 있으며 마운트된 버킷의 파일 수와 사용 중인 마운트 지점 수에 따라 달라집니다. 예를 들어 각 파일의 메타데이터는 메모리를 약 1.5KiB 사용하며, 백만 개의 파일의 메타데이터는 메모리를 약 1.5GiB 사용합니다. 자세한 내용은 캐싱 개요를 참조하세요.

다음 안내에 따라 Cloud Storage FUSE를 구성하여 많은 양의 메타데이터를 캐시하고 메타데이터 만료를 우회하세요.

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1
type-cache-max-size-mb: -1

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1
      - metadata-cache:type-cache-max-size-mb:-1

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

메타데이터 캐시 자동 입력

워크로드를 실행하기 전에 메타데이터 캐시를 미리 채우는 것이 좋습니다. 이렇게 하면 특히 implicit-dirs 구성 옵션을 사용하는 경우 성능이 크게 향상되고 Cloud Storage에 대한 메타데이터 호출 수가 크게 줄어듭니다. GKE용 Cloud Storage FUSE CSI 드라이버는 메타데이터 캐시 자동 입력을 처리하는 API를 제공합니다(메타데이터 미리 가져오기를 사용하여 메타데이터 캐시 자동 입력 참고).

메타데이터 캐시를 미리 채우려면 다음 방법 중 하나를 사용하세요.

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"
  

ls -R MOUNT_POINT > /dev/null

ls -R MOUNT_POINT > /dev/null

파일 캐싱 및 동시 다운로드 사용 설정

파일 캐싱을 사용하면 자주 액세스하는 파일 데이터를 머신에 로컬로 저장하여 반복 읽기를 가속화하고 Cloud Storage 비용을 절감할 수 있습니다. 파일 캐싱을 사용 설정하면 동시 다운로드도 자동으로 사용 설정됩니다. 병렬 다운로드는 파일 캐시 디렉터리를 프리페치 버퍼로 사용하여 여러 작업자가 파일을 동시에 다운로드하므로 모델 로드 시간이 9배 빨라집니다.

파일 캐싱 및 동시 다운로드를 사용 설정하고 구성하는 방법을 알아보려면 파일 캐싱 동작 사용 설정 및 구성을 참조하세요. 샘플 구성을 사용하려면 파일 캐싱 및 동시 다운로드를 사용 설정하는 샘플 구성을 참조하세요.

파일 캐싱 및 병렬 다운로드 사용 시 Cloud GPU 및 Cloud TPU 고려사항

파일 캐시는 다음 안내에 따라 로컬 SSD, RAM, Persistent Disk 또는 Google Cloud Hyperdisk에서 호스팅할 수 있습니다. 어떤 경우든 데이터 또는 개별 대용량 파일은 max-size-mb 구성을 사용하여 제어되는 파일 캐시 디렉터리의 사용 가능한 용량 내에 있어야 합니다.

Cloud GPU 고려사항

로컬 SSD는 학습 데이터 및 체크포인트 다운로드에 적합합니다. Cloud GPU 머신 유형에는 사용할 수 있는 SSD 용량이 포함됩니다(예: SSD 12TiB가 포함된 A4 머신 유형).

• RAM 디스크는 시스템의 사용되지 않은 RAM 양에 비해 크기가 작기 때문에 모델 가중치를 로드하는 데 가장 적합한 성능을 제공합니다.

• Persistent Disk 또는 Google Cloud Hyperdisk는 모두 캐시로 사용할 수 있습니다.

Cloud TPU 고려사항

Cloud TPU는 로컬 SSD를 지원하지 않습니다. 수정 없이 Cloud TPU에서 파일 캐싱을 사용하면 사용되는 기본 위치는 부팅 볼륨이며, 이는 권장되지 않으며 성능이 저하됩니다.

부팅 볼륨 대신 성능이 우수하고 추가 비용이 없는 RAM 디스크를 사용하는 것이 좋습니다. 하지만 RAM 디스크는 크기가 제한되는 경우가 많으며 체크포인트 크기와 사용 가능한 RAM에 따라 모델 가중치 또는 체크포인트 다운로드에 가장 유용합니다. 또한 캐싱 목적으로 Persistent Disk와 Google Cloud Hyperdisk를 사용하는 것이 좋습니다.

파일 캐싱 및 병렬 다운로드를 사용 설정하기 위한 샘플 구성

기본적으로 파일 캐시는 Google Kubernetes Engine 노드에 ephemeral-storage-local-ssd 모드가 사용 설정된 경우 로컬 SSD를 사용합니다. 로컬 SSD를 사용할 수 없는 경우(예: Cloud TPU 머신) 파일 캐시는 Google Kubernetes Engine 노드의 부팅 디스크를 사용하며 이는 권장되지 않습니다. 이 경우 RAM 디스크를 캐시 디렉터리로 사용할 수 있지만 파일 캐싱에 사용할 수 있는 RAM의 양과 포드에 필요한 양을 고려해야 합니다.

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME MOUNT_POINT

음수 통계 캐시 항목 사용 중지

기본적으로 Cloud Storage FUSE는 존재하지 않는 파일의 항목인 음수 통계 항목을 5초의 TTL로 캐시합니다. 분산 체크포인트와 같이 파일이 자주 생성되거나 삭제되는 워크로드에서는 이러한 캐시된 항목이 빠르게 오래되어 성능 문제가 발생할 수 있습니다. 이를 방지하려면 negative-ttl-secs 구성 옵션을 사용하여 학습, 제공, 체크포인트 워크로드의 부정 통계 캐시를 사용 중지하는 것이 좋습니다.

다음 안내에 따라 부정 통계 캐시를 사용 중지하세요.

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME

metadata-cache:
 negative-ttl-secs: 0

mountOptions:
    - metadata-cache:negative-ttl-secs:0

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME MOUNT_POINT

스트리밍 쓰기 사용 설정

스트리밍 쓰기는 데이터가 작성될 때 Cloud Storage에 직접 업로드하므로 지연 시간과 디스크 공간 사용량이 줄어듭니다. 이는 체크포인트와 같은 대규모 순차 쓰기에 특히 유용합니다. 스트리밍 쓰기는 Cloud Storage FUSE 버전 3.0 이상에서 기본적으로 사용 설정되어 있습니다.

스트리밍 쓰기가 기본적으로 사용 설정되어 있지 않으면 다음 안내에 따라 사용 설정하세요. 스트리밍 쓰기를 사용 설정하려면 Google Kubernetes Engine 버전 1.32.1-gke.1729000 이상에서 사용할 수 있는 Cloud Storage FUSE 버전 3.0이 필요합니다.

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME

write:
 enable-streaming-writes: true

mountOptions:
    - write:enable-streaming-writes:true

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME MOUNT_POINT

커널 미리 읽기 크기 증가

서빙 및 체크포인트 복원과 같이 대용량 파일의 순차 읽기가 주로 포함된 워크로드의 경우 미리 읽기 크기를 늘리면 성능이 크게 향상될 수 있습니다. 이 작업은 로컬 머신에서 read_ahead_kb Linux 커널 파라미터를 사용하여 실행할 수 있습니다. 대부분의 Linux 배포에 설정된 기본값인 128KB를 사용하는 대신 read_ahead_kb 커널 파라미터를 1MB로 늘리는 것이 좋습니다. Compute Engine 인스턴스의 경우 커널 파라미터를 성공적으로 늘리려면 sudo 또는 root 권한이 필요합니다.

특정 Cloud Storage FUSE 마운트 디렉터리의 read_ahead_kb 커널 파라미터를 1MB로 늘리려면 다음 안내를 따르세요. 명령어를 실행하기 전에 버킷을 Cloud Storage FUSE에 마운트해야 합니다. 그렇지 않으면 커널 파라미터가 증가하지 않습니다.

mountOptions:



read_ahead_kb=1024

export MOUNT_POINT=/path/to/mount/point
echo 1024 | sudo tee /sys/class/bdi/0:$(stat -c "%d" $MOUNT_POINT)/read_ahead_kb

중복 검사를 방지하기 위해 보안 토큰 서비스 사용 중지

Google Kubernetes Engine용 Cloud Storage FUSE CSI 드라이버에는 버킷과 GKE 서비스 계정 간의 워크로드 아이덴티티 바인딩에 대한 사용자 잘못된 구성으로 인한 포드 복구 가능성을 보장하기 위한 액세스 확인이 있습니다. 이로 인해 대규모로 기본 보안 토큰 서비스 API 할당량에 도달할 수 있습니다. 영구 볼륨 CSI 드라이버의 skipCSIBucketAccessCheck 볼륨 속성을 설정하여 이 기능을 사용 중지할 수 있습니다. 포드의 마운트 실패를 방지하려면 GKE 서비스 계정에 타겟 Cloud Storage 버킷에 대한 적절한 액세스 권한이 있는지 확인하는 것이 좋습니다.

또한 Google Kubernetes Engine 클러스터가 6,000개가 넘는 노드로 구성된 경우 보안 토큰 서비스 할당량을 기본값인 6000 이상으로 늘려야 합니다. 대규모 배포에서 늘리지 않으면 429 오류가 발생할 수 있습니다. 할당량 및 한도 페이지를 통해 보안 토큰 서비스 할당량을 늘려야 합니다. 할당량을 마운트 수와 동일하게 유지하는 것이 좋습니다. 예를 들어 클러스터에 마운트가 10,000개 있는 경우 할당량을 10000으로 늘려야 합니다.

skipCSIBucketAccessCheck 볼륨 속성을 설정하려면 다음 샘플 구성을 참조하세요.

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"
   

기타 성능 고려사항

앞서 설명한 기본 최적화 외에도 여러 요인이 Cloud Storage FUSE의 전반적인 성능에 큰 영향을 미칠 수 있습니다. 다음 섹션에서는 Cloud Storage FUSE를 사용할 때 고려하는 것이 좋은 추가 성능 고려사항을 설명합니다.

HNS가 아닌 버킷의 이름 변경 한도 증가

체크포인트 워크로드는 항상 계층적 네임스페이스가 사용 설정된 버킷으로 실행해야 합니다. 원자적이고 빠른 이름 변경과 읽기 및 쓰기의 높은 QPS 때문입니다. 하지만 디렉터리 이름 변경이 원자적이지 않고 시간이 오래 걸릴 위험을 감수한다면 계층적 네임스페이스가 없는 버킷을 사용하여 체크포인트를 실행할 때 rename-dir-limit 구성 옵션을 사용하여 특정 시점에 디렉터리 이름 변경 작업에 포함된 파일 또는 작업 수를 제한할 수 있습니다.

체크포인트 실패를 방지하려면 rename-dir-limit 구성 옵션을 높은 값으로 설정하는 것이 좋습니다. Cloud Storage FUSE는 플랫 네임스페이스를 사용하고 객체는 변경할 수 없으므로 디렉터리 이름 바꾸기 작업에는 디렉터리 내의 모든 개별 파일의 이름을 바꾸고 삭제하는 작업이 포함됩니다. rename-dir-limit 구성 옵션을 설정하여 이름 바꾸기 작업의 영향을 받는 파일 수를 제어할 수 있습니다.

다음 안내에 따라 rename-dir-limit 구성 옵션을 설정합니다.

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME

file-system:
 rename-dir-limit: 200000

mountOptions:
    - rename-dir-limit=200000

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME MOUNT_POINT

커널 목록 캐싱

목록 캐시는 디렉터리 및 파일 목록 또는 목록 작업 속도를 개선하는 응답인 ls를 위한 캐시입니다. Cloud Storage FUSE에서 관리하는 통계 및 유형 캐시와 달리 목록 캐시는 커널의 페이지 캐시에 보관되며 메모리 가용성을 기반으로 커널에 의해 제어됩니다.

커널 목록 캐싱을 사용 설정하는 것이 가장 유용한 사용 사례는 다음과 같습니다.

• 디렉터리 목록이 반복되는 워크로드: 이 구성은 AI/ML 학습 실행과 같이 전체 디렉터리 목록을 자주 실행하는 워크로드에 특히 유용합니다. 이는 서빙 및 학습 워크로드 모두에 도움이 될 수 있습니다.

• 읽기 전용 마운트: 일관성 문제를 방지하려면 읽기 전용 마운트와 함께 목록 캐싱을 사용하는 것이 좋습니다.

커널 목록 캐싱을 사용 설정할 때는 주의해야 하며, 작업 실행 중에 디렉터리 콘텐츠 변경이 예상되지 않는 파일 시스템이 실제로 읽기 전용인 경우에만 사용해야 합니다. 이 플래그를 사용하면 TTL이 -1로 설정된 경우 특히 로컬 애플리케이션에서 업데이트를 볼 수 없기 때문입니다.

예를 들어 클라이언트 1은 directoryA를 나열하므로 directoryA가 커널 목록 캐시에 상주하게 됩니다. 클라이언트 2가 Cloud Storage 버킷의 directoryA 아래에 fileB를 만듭니다. 클라이언트 1은 directoryA에서 fileB를 지속적으로 확인합니다. 이는 기본적으로 커널 목록 캐시 항목을 확인하는 것이며 네트워크를 통해 이동하지 않습니다. 파일 목록이 로컬 커널 목록 캐시에서 지속적으로 제공되므로 클라이언트 1에는 디렉터리에 새 파일이 표시되지 않습니다. 그러면 클라이언트 1이 시간 초과되고 프로그램이 중단됩니다.

다음 안내에 따라 목록 캐싱을 사용 설정합니다.

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME

file-system:
 kernel-list-cache-ttl-secs: -1

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME MOUNT_POINT

file-system:kernel-list-cache-ttl-secs 마운트 옵션을 사용하는 경우 값은 다음을 의미합니다.

• 양수 값은 커널의 페이지 캐시에 디렉터리 목록 응답을 유지하기 위한 TTL을 초 단위로 나타냅니다.

• -1 값은 항목 만료를 우회하고 사용 가능한 경우 캐시에서 목록 응답을 반환합니다.

Cloud Storage FUSE와 함께 JAX 영구 컴파일(JIT) 캐시 사용

JAX는 컴파일된 함수 아티팩트를 저장하는 선택적 영구 컴파일 캐시인 적시(JIT) 캐시를 지원합니다. 이 캐시를 사용하면 중복 컴파일 단계를 방지하여 후속 스크립트 실행 속도를 크게 높일 수 있습니다.

JIT 캐싱을 사용 설정하려면 다음 요구사항을 충족해야 합니다.

• 최신 버전의 JAX 사용: 최신 캐시 기능과 최적화를 위해 JAX 버전 0.5.1 이상을 사용합니다.

• 캐시 용량 최대화: 캐시 삭제로 인한 성능 저하를 방지하려면 특히 기본 설정을 재정의하려는 경우 무제한 캐시 크기를 설정하는 것이 좋습니다. 환경 변수를 설정하여 이를 달성할 수 있습니다.

  export JAX_COMPILATION_CACHE_MAX_SIZE=-1
  

• 체크포인트 포드 YAML 확인: JAX JIT 캐시의 마운트 지점에 체크포인트 구성을 사용합니다.

다음 단계

• 샘플 Google Kubernetes Engine YAML 파일을 사용하여 조정 권장사항을 구성합니다.

• Cloud Storage FUSE 구성 파일 옵션에 대해 자세히 알아보세요.

• Cloud Storage FUSE CLI 옵션에 대해 자세히 알아보세요.