TPU VM의 AI/ML 워크로드를 위한 스토리지 권장사항

TPU VM에서 AI/ML 워크로드의 성능과 비용 효율성을 극대화하려면 워크로드에 적합한 스토리지 솔루션을 선택하고 구성하세요. I/O 병목 현상을 제거하면 TPU 액셀러레이터의 유휴 시간을 줄여 학습 시간과 비용을 절감할 수 있습니다.

이 문서에서는 TPU VM에서 학습, 체크포인트, 제공, 캐싱을 위한 워크로드별 스토리지 권장사항과 최적화 권장사항을 제공합니다. 이러한 방법을 적용하기 전에 사용 가능한 TPU 데이터 스토리지 옵션을 검토하세요. 이 문서에서는 사용자가 TPU VM에 익숙하고 Cloud Storage 리소스 프로비저닝 경험이 있다고 가정합니다.

워크로드별 안내

다음 표에서는 다양한 워크로드에 대한 스토리지 권장사항을 선호도 순으로 나열합니다.

워크로드 권장사항 최적화 및 도구 (해당하는 경우)
데이터 준비를 포함한 학습 데이터 세트
  1. Rapid Cache 및 클라이언트 측 조정 (예: 미리 읽기)과 함께 Cloud Storage 리전 버킷을 사용하여 비용을 최소화합니다.
  2. 최고의 성능과 확장성을 위해 Cloud Storage Rapid Bucket을 사용하세요.
  3. 높은 메타데이터 동시성 또는 작은 파일 (1MB 미만)로 인해 Lustre (파일 시스템 스토리지)를 표준화하는 경우 Managed Lustre를 사용합니다.
  • 리전 Cloud Storage 버킷의 경우 계층적 네임스페이스를 사용 설정합니다.
  • 리전 Cloud Storage 버킷 또는 Rapid Bucket의 경우 Cloud Storage FUSE 및 gRPC를 사용합니다. GKE의 경우 gcsfusecsi-training 프로필을 사용합니다.
  • Managed Lustre의 경우 동적 등급을 사용하여 비용을 절감하고 성능을 자동으로 최적화하는 것이 좋습니다.
체크포인트 및 강화 학습 가중치
  1. 동기 체크포인트 및 강화 학습을 위한 고속 가중치 전파와 같이 짧은 지연 시간 (1ms 미만) 요구사항에 맞게 광범위하게 조정하지 않고도 고성능을 위해 Managed Lustre를 사용하세요.
  2. 비동기 및 다중 계층 체크포인트와 체크포인트 작업을 스토리지에 병렬화하는 데 가장 높은 처리량을 얻으려면 Cloud Storage Rapid Bucket을 사용하세요. Rapid Bucket은 이러한 워크로드에 필요한 높은 처리량을 제공합니다.
Rapid Bucket의 경우 gcsfusecsi-checkpointing 프로필을 사용합니다.
모델 저장 및 다운로드
  1. 소규모 모델 캐싱 및 최대 2,500개의 인스턴스에는 Hyperdisk ML을 사용합니다.
  2. 단일 스토리지 솔루션을 표준화하려면 학습 데이터 세트에 사용하는 스토리지 솔루션(Managed Lustre, Rapid Bucket 또는 리전 버킷)을 사용하세요.
모델을 다운로드하려면 GKE Run:ai Model Streamer 또는 gcsfusecsi-serving 프로필을 사용하여 별도의 마운트 지점이 있는 Cloud Storage FUSE를 사용합니다.
키-값 (KV) 캐시 오프로드
  1. 항상 호스트 CPU 메모리 (RAM)를 기본 계층으로 사용하여 상당한 지연 시간을 추가하지 않고 VRAM을 확보합니다.
  2. CPU 메모리가 부족한 경우 Managed Lustre를 캐시 계층 구조의 병렬 저지연 시간 2단계로 사용하여 높은 처리량 (최대 10TB/s)에서 KV 캐시 오프로드의 매우 짧은 지연 시간 (1ms 미만) 요구사항을 충족하세요.

Cloud Storage 최적화

다음 섹션에서는 TPU VM과 함께 Cloud Storage를 사용할 때 성능을 최적화하기 위한 권장사항을 설명합니다.

메타데이터 최적화를 위해 계층적 네임스페이스 사용 설정

메타데이터 성능을 개선하려면 AI/ML 워크로드용 리전 버킷을 만들 때 계층적 네임스페이스를 사용 설정하세요. 메타데이터 성능은 Cloud Storage가 파일 콘텐츠 자체를 읽거나 쓰는 대신 객체 경로와 폴더를 조회하거나 나열하거나 수정하는 작업을 얼마나 빠르게 처리할 수 있는지를 나타냅니다.

계층적 네임스페이스가 사용 설정되지 않은 버킷에서 폴더는 실제 리소스로 존재하지 않지만 슬래시 (/)로 구분된 객체 이름 접두사로 표시되는 시뮬레이션된 폴더로 대신 존재합니다. 이로 인해 시스템이 해당 접두사가 있는 모든 객체를 검색해야 하므로 디렉터리 콘텐츠 나열 또는 디렉터리 이름 바꾸기와 같은 작업이 느려집니다. 계층적 네임스페이스는 실제 파일 시스템 구조를 제공하며, 이는 다음과 같은 여러 이유로 AI/ML 워크로드에 중요합니다.

  • 원자적 디렉터리 이름 변경: ML 프레임워크는 디렉터리 이름 변경을 사용하여 체크포인트를 완료합니다. 계층적 네임스페이스는 원자적 이름 변경을 지원하여 체크포인트가 빠르게 완료되도록 합니다.
  • 초기 QPS 증가: 계층적 네임스페이스는 계층적 네임스페이스가 사용 설정되지 않은 버킷에 비해 읽기 및 쓰기에 대한 초기 초당 쿼리 수 (QPS)가 최대 8배 더 높습니다. 이렇게 하면 여러 TPU가 동시에 스토리지에 액세스할 때 병목 현상이 발생하지 않습니다.
  • 효율적인 폴더 수준 작업: 특정 디렉터리 내에서 파일을 찾고 나열하는 속도가 훨씬 빨라져 학습 및 데이터 로드 중 응답 시간이 단축됩니다.

Rapid Bucket을 통해 제공되는 영역 버킷은 기본적으로 계층적 네임스페이스를 사용합니다. 자세한 내용은 계층적 네임스페이스 개요를 참고하세요.

적절한 프로필로 Cloud Storage FUSE 사용

Cloud Storage FUSE는 버킷을 로컬 파일 시스템으로 마운트할 수 있는 FUSE 어댑터입니다. Google Kubernetes Engine을 사용하는 경우 Cloud Storage FUSE CSI 드라이버와 Cloud Storage FUSE 프로필을 사용하여 성능 조정을 자동화하는 것이 좋습니다.

Cloud Storage FUSE 사용 권장사항에 대한 자세한 내용은 성능 조정 권장사항을 참고하세요.

TPU VM 부팅 디스크 맞춤설정

시작 스크립트를 사용하거나 커스텀 이미지를 만들어 TPU VM의 게스트 OS 환경을 맞춤설정할 수 있습니다. 부팅 디스크를 맞춤설정하는 것은 다음 시나리오에 유용합니다.

  • 소프트웨어 및 라이브러리 사전 로드: 특정 ML 프레임워크, 종속 항목 또는 맞춤 소프트웨어를 설치하여 VM 시작 시간을 줄이고 일관된 환경을 보장합니다.
  • 비표준 OS 배포 사용: Google 관리 목록에 포함되지 않은 OS 배포 또는 버전을 사용합니다.
  • 보안 및 모니터링 구성 적용: 맞춤 보안 설정을 적용하거나, 모니터링 에이전트를 설치하거나, 환경 변수를 설정합니다.

하지만 TPU VM의 부팅 디스크 복구는 제한됩니다. 오프라인 복구를 위해 부팅 디스크를 분리하거나 스냅샷을 만들 수 없으므로 부팅 프로세스에 영향을 미치는 변경사항을 적용할 때는 주의하세요. 이러한 권장사항을 따르면 TPU VM 환경을 맞춤설정할 때 부팅 실패 위험을 줄일 수 있습니다.

부팅 디스크를 맞춤설정할 때는 다음 핵심 원칙을 염두에 두세요.

  • 부팅 디스크 수정 최소화: 가능하면 부팅 디스크를 많이 수정하는 대신 영구 디스크 또는 하이퍼디스크 볼륨에 애플리케이션을 설치하고 데이터를 저장하세요.

  • 마운트 시 UUID 사용: /etc/fstab 파일에 항목을 추가할 때는 항상 /dev/sdb1과 같은 기기 이름 대신 UUID를 사용하여 디스크와 파티션 (UUID=...)을 식별합니다. 자동 생성된 기기 이름은 재부팅 시 안정적이지 않을 수 있습니다.

시스템을 변경할 때 부팅 실패 위험을 줄이려면 다음 권장사항을 따르세요.

  • 오류 처리: 스크립트에 강력한 오류 확인 및 정상적인 실패 모드를 구현합니다. 디버깅에 도움이 되도록 직렬 콘솔 및 Cloud Logging에 상세 메시지를 로깅합니다.

  • 중요한 종속 항목: /etc/fstab 파일, 네트워크 구성, 부트로더 설정 등 부팅에 필수적인 파일을 수정할 때는 매우 주의해야 합니다. 문법 오류 또는 잘못된 항목으로 인해 VM을 부팅할 수 없게 될 수 있습니다.

  • 보조 디스크: 스크립트가 보조 디스크를 사용하는 경우 디스크가 없을 수 있거나 예상보다 오래 걸려 연결되는 사례를 처리해야 합니다. 절대적으로 필요한 경우가 아니라면 부팅 프로세스가 보조 디스크 마운트에 심각하게 의존하지 않도록 합니다.

    다음은 보조 디스크를 마운트할 때 권장되는 /etc/fstab 항목과 권장되지 않는 /etc/fstab 항목의 예입니다.

    • 권장: UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /mnt/mydata ext4 defaults,nofail 0 2
    • 권장하지 않음: /dev/sdb1 /mnt/mydata ext4 defaults 0 2

    nofail 옵션을 사용하면 디스크를 찾을 수 없는 경우 시스템이 중지되지 않지만 애플리케이션이 마운트 지점을 사용할 수 없는 상황을 처리할 수 있는지 확인하세요.

  • 패키지 관리: 서드 파티 저장소를 추가할 때는 주의해야 합니다. 신뢰할 수 있고 기본 OS 이미지와 호환되는지 확인합니다. 설치하는 패키지의 종속 항목과 시스템 라이브러리에 미치는 잠재적 영향을 이해합니다.

  • 디스크 공간: 부팅 디스크 사용량을 모니터링합니다. 광범위한 로깅이나 대규모 소프트웨어 설치로 인해 부팅 디스크가 가득 차면 VM이 시작되지 않을 수 있습니다.

  • 로깅: TPU VM의 부팅 문제를 진단하는 기본 도구이므로 직렬 콘솔에 자세히 로깅하도록 애플리케이션과 스크립트를 구성합니다.

스토리지 용량 계획

워크로드에서 액셀러레이터를 완전히 활용하는 데 필요한 스토리지 용량을 계획하는 것이 중요합니다. 여기에는 저장용량과 체크포인트 대역폭이 포함됩니다.

스토리지 추정

다음 예상치를 스토리지 요구사항의 시작점으로 사용할 수 있습니다.

워크로드 유형 데이터 세트 스토리지 체크포인트 저장소
LLM 사전 학습 TPU당 2TB TPU당 200GB
멀티모달 학습 TPU당 12TB TPU당 1TB
추론 TPU당 1TB TPU당 1GB

체크포인트 대역폭 추정

다음 공식을 사용하여 학습 워크로드에 필요한 최소 체크포인트 대역폭을 추정할 수 있습니다. 데이터 읽기, 여러 학습 실행 또는 학습 및 추론의 경우 예상 대역폭 요구사항을 비례적으로 늘립니다.

  1. 체크포인트 크기: 매개변수 수 × 매개변수당 바이트 수 (FP16 + 옵티마이저 상태의 경우 매개변수당 약 12~16바이트). 옵티마이저 상태와 다양한 정밀도를 위해 버퍼(약 3배)를 추가합니다.
  2. 체크포인트 간격: 체크포인트를 저장하는 빈도 (예: 15분마다)입니다.
  3. 필요한 대역폭: 체크포인트 크기 ÷ 체크포인트 간격

다음 예에서는 Qwen3-72B의 최소 체크포인트 지정 대역폭을 추정하는 방법을 보여줍니다.

  1. 체크포인트 크기: 72B 매개변수 × 12바이트 ≈ 체크포인트당 864GB 버퍼를 포함하면 3 × 864GB ≈ 2.5TB입니다.
  2. 체크포인트 간격: 2분 = 120초
  3. 필요한 대역폭: 2.5TB ÷ 120초 ≈ 20GBps

참조 레시피

특정 하드웨어 및 워크로드의 스토리지 구성 예시는 다음 레시피를 참고하세요.

할당량 및 대역폭 한도

Cloud Storage 및 Compute Engine 제품의 대역폭은 기본 할당량에 의해 제한됩니다. 할당량을 초과하면 입력 및 출력 요청이 제한될 수 있습니다.

Cloud Storage 할당량 및 할당량 증가를 요청하는 방법에 대한 자세한 내용은 Cloud Storage 문서의 할당량 및 한도를 참고하세요. Hyperdisk 및 Persistent Disk의 Compute Engine 할당량에 관한 자세한 내용은 디스크 할당량을 참고하세요.

다음 단계