이 페이지는 Cloud Translation API를 통해 번역되었습니다.

GKE의 TPU 정보

Autopilot Standard

이 페이지에서는 용어, Tensor Processing Unit (TPU)의 이점, 워크로드 예약 고려사항을 비롯하여 Cloud TPU가 Google Kubernetes Engine (GKE)과 함께 작동하는 방식을 설명합니다. TPU는 TensorFlow, PyTorch, JAX와 같은 프레임워크를 사용하는 ML 워크로드를 가속화하기 위해 Google에서 맞춤 개발한 애플리케이션 특정 통합 회로 (ASIC)입니다.

이 페이지는 대규모이거나 장시간 실행되거나 행렬 계산이 중심이 되는 머신러닝 (ML) 모델을 운영하는 플랫폼 관리자 및 운영자, 데이터 및 AI 전문가를 대상으로 합니다. Google Cloud콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.

이 페이지를 읽기 전에 ML 가속기 작동 방식을 숙지해야 합니다. 자세한 내용은 Cloud TPU 소개를 참고하세요.

GKE에서 TPU를 사용할 때의 이점

GKE는 TPU VM 생성, 구성, 삭제를 포함해 TPU 노드 및 노드 풀의 전체 수명 주기 관리를 완전히 지원합니다. GKE는 스팟 VM 및 예약된 Cloud TPU 사용도 지원합니다. 자세한 내용은 Cloud TPU 소비 옵션을 참조하세요.

GKE에서 TPU를 사용할 때의 이점은 다음과 같습니다.

일관된 운영 환경: 모든 머신러닝 및 기타 워크로드에 단일 플랫폼을 사용할 수 있습니다.
자동 업그레이드: GKE는 버전 업데이트를 자동화하여 운영 오버헤드를 줄입니다.
부하 분산: GKE는 부하를 분산하여 지연 시간을 줄이고 안정성을 개선합니다.
반응형 확장: GKE는 워크로드의 요구사항을 충족하는 TPU 리소스를 자동으로 확장합니다.
리소스 관리: Kubernetes 기반 작업 큐 시스템인 Kueue를 사용하면 큐, 선점, 우선순위 지정, 공정 공유를 사용하여 조직 내 여러 테넌트에서 리소스를 관리할 수 있습니다.
샌드박싱 옵션: GKE Sandbox는 gVisor를 사용하여 워크로드를 보호하는 데 도움이 됩니다. 자세한 내용은 GKE Sandbox를 참고하세요.

Ironwood (TPU7x) 시작하기

Ironwood (TPU7x)는 대규모 AI 워크로드를 위해 설계된 Google의 7세대 TPU입니다. Ironwood (TPU7x)에 대한 자세한 내용은 다음 리소스를 참고하세요.

Ironwood (TPU7x)의 이점에 대한 자세한 내용은 실리콘에서 소프트맥스까지: Ironwood AI 스택 내부를 참고하세요.
Ironwood (TPU7x) 아키텍처에 대한 자세한 내용은 Ironwood (TPU7x)를 참고하세요.
TPU 설정을 시작하려면 GKE에서 TPU 계획을 참고하세요.

클러스터 생성에 사용할 수 있는 다음 옵션은 클러스터 구성 및 워크로드 예약의 용이성과 유연성이 서로 다릅니다.

가속화된 처리 키트 (XPK)를 사용하여 GKE 클러스터를 빠르게 만들고 개념 증명 및 테스트를 위한 워크로드를 실행합니다. 자세한 내용은 XPK 문서를 참고하세요.
Google Cloud CLI를 사용하여 기존 프로덕션 GKE 환경을 정확하게 맞춤설정하거나 확장하기 위해 GKE 클러스터 인스턴스를 수동으로 만드세요.

GKE의 TPU 관련 용어

이 페이지에서는 TPU와 관련하여 다음 용어를 사용합니다.

Cloud TPU ICI 복원력: 큐브 간에 TPU를 연결하는 광 연결 및 광학 회로 스위치 (OCS)의 내결함성을 개선하는 데 도움이 되는 기능입니다. 자세한 내용은 TPU 아키텍처를 참고하세요.
TPU 큐브: 상호 연결된 TPU 칩의 4x4x4 토폴로지입니다. 이는 3-튜플 ({A}x{B}x{C})의 토폴로지에만 적용됩니다.
TPU 유형: Cloud TPU 유형입니다(예: v5e).
TPU 슬라이스: 고속 칩 간 상호 연결 (ICI)을 통해 연결된 동일한 TPU Pod 내에 모두 위치한 칩 모음입니다. 슬라이스는 TPU 버전에 따라 칩 또는 TensorCore 단위로 표현됩니다.
TPU 슬라이스 노드: 하나 이상의 상호 연결된 TPU 칩이 있는 단일 VM으로 표시되는 Kubernetes 노드입니다.
TPU 슬라이스 노드 풀: 모두 동일한 TPU 구성을 가진 클러스터 내의 Kubernetes 노드 그룹입니다.
TPU 토폴로지: TPU 슬라이스에 있는 TPU 칩의 수와 물리적 배열입니다.
원자적: GKE는 상호 연결된 모든 노드를 단일 단위로 취급합니다. 확장 작업 중에 GKE는 전체 노드 집합을 0으로 확장하고 새 노드를 만듭니다. 그룹의 머신이 실패하거나 종료되면 GKE에서 전체 노드 집합을 새 단위로 다시 만듭니다.
Immutable: 상호 연결된 노드 집합에 수동으로 새 노드를 추가할 수 없습니다. 하지만 원하는 TPU 토폴로지가 있는 새 노드 풀을 만들고 새 노드 풀에서 워크로드를 예약할 수 있습니다.

TPU 슬라이스 노드 풀 유형

GKE는 다음 두 가지 유형의 TPU 노드 풀을 지원합니다.

멀티 호스트 TPU 슬라이스
단일 호스트 TPU 슬라이스

TPU 유형과 토폴로지에 따라 TPU 슬라이스 노드가 멀티 호스트인지 단일 호스트인지가 결정됩니다. 다음 조치를 취해 보시기 바랍니다.

대규모 모델의 경우 멀티 호스트 TPU 슬라이스 노드를 사용합니다.
소규모 모델의 경우 단일 호스트 TPU 슬라이스 노드를 사용합니다.
대규모 학습 또는 추론의 경우 Pathways를 사용합니다. Pathways는 단일 JAX 클라이언트가 여러 대규모 TPU 슬라이스에서 워크로드를 조정할 수 있도록 지원하여 대규모 머신러닝 계산을 간소화합니다. 자세한 내용은 Pathways를 참조하세요.

멀티 호스트 TPU 슬라이스 노드 풀

멀티 호스트 TPU 슬라이스 노드 풀은 상호 연결된 TPU VM이 2개 이상 포함된 노드 풀입니다. 각 VM에는 연결된 TPU 기기가 있습니다. 멀티 호스트 TPU 슬라이스의 TPU는 고속 상호 연결(ICI)을 통해 연결됩니다. 멀티 호스트 TPU 슬라이스 노드 풀을 생성한 후에는 노드를 추가할 수 없습니다. 예를 들어 v4-32 노드 풀을 만든 후 나중에 이 노드 풀에 Kubernetes 노드 (TPU VM)를 추가할 수 없습니다. GKE 클러스터에 TPU 슬라이스를 추가하려면 새 노드 풀을 만들어야 합니다.

멀티 호스트 TPU 슬라이스 노드 풀의 VM은 단일 원자적 단위로 취급됩니다. GKE가 슬라이스에 노드 하나를 배포할 수 없는 경우 TPU 슬라이스 노드에는 노드가 배포되지 않습니다.

멀티 호스트 TPU 슬라이스 내의 노드를 복구해야 하는 경우 GKE는 TPU 슬라이스의 모든 VM을 종료하여 워크로드의 모든 Kubernetes 포드를 강제로 제거합니다. TPU 슬라이스의 모든 VM이 가동되어 실행된 후 새 TPU 슬라이스의 VM에서 Kubernetes 포드를 예약할 수 있습니다.

다음 다이어그램은 v5litepod-16 (v5e) 멀티 호스트 TPU 슬라이스를 보여줍니다. 이 TPU 슬라이스에는 VM이 4개 있습니다. TPU 슬라이스의 각 VM에는 고속 상호 연결 (ICI)과 연결된 4개의 TPU v5e 칩이 있으며, 각 TPU v5e 칩에는 하나의 TensorCore가 있습니다.

멀티 호스트 TPU 슬라이스 다이어그램

다음 다이어그램은 TPU v5litepod-16 (v5e) TPU 슬라이스 1개 (토폴로지: 4x4)와 TPU v5litepod-8 (v5e) 슬라이스 1개 (토폴로지: 2x4)가 포함된 GKE 클러스터를 보여줍니다.

TPU v5e Pod 다이어그램

단일 호스트 TPU 슬라이스 노드 풀

단일 호스트 슬라이스 노드 풀은 하나 이상의 독립적인 TPU VM을 포함하는 노드 풀입니다. 각 VM에는 연결된 TPU 기기가 있습니다. 단일 호스트 슬라이스 노드 풀 내의 VM은 데이터 센터 네트워크 (DCN)를 통해 통신할 수 있지만 VM에 연결된 TPU는 상호 연결되지 않습니다.

다음 다이어그램은 7개의 v4-8 머신이 포함된 단일 호스트 TPU 슬라이스의 예시를 보여줍니다.

단일 호스트 슬라이스 노드 풀 다이어그램

GKE의 TPU 특성

TPU에는 특별한 계획과 구성이 필요한 고유한 특성이 있습니다.

TPU 소비

워크로드 성능의 균형을 유지하면서 리소스 사용률과 비용을 최적화하기 위해 GKE는 다음 TPU 소비 옵션을 지원합니다.

flex-start(유연한 시작): 최대 7일 동안 Flex-start VM을 프로비저닝합니다. GKE가 가용성을 기반으로 최선을 다해 하드웨어를 자동으로 할당합니다. 자세한 내용은 flex-start(유연한 시작) 프로비저닝 모드를 사용한 GPU 및 TPU 프로비저닝 정보를 참조하세요.
스팟 VM: 스팟 VM을 프로비저닝하면 상당한 할인을 받을 수 있지만 스팟 VM은 언제든지 30초 경고와 함께 선점될 수 있습니다. 자세한 내용은 스팟 VM을 참조하세요.
최대 90일간의 미래용 예약(캘린더 모드): 지정된 기간 동안 최대 90일간 TPU 리소스를 프로비저닝합니다. 자세한 내용은 캘린더 모드에서 미래용 예약으로 TPU 요청하기를 참조하세요.
TPU 예약: 1년 이상의 미래용 예약을 요청합니다.

워크로드 요구사항을 충족하는 소비 옵션을 선택하려면 GKE의 AI/ML 워크로드용 가속기 소비 옵션 정보를 참조하세요.

GKE에서 TPU를 사용하기 전에 워크로드 요구사항에 가장 적합한 소비 옵션을 선택하세요.

토폴로지

토폴로지는 TPU 슬라이스 내에서 TPU의 물리적 배열을 정의합니다. GKE는 TPU 버전에 따라 2차원 또는 3차원 토폴로지로 TPU 슬라이스를 프로비저닝합니다. 토폴로지를 다음과 같이 각 측정기준의 TPU 칩 수로 지정합니다.

멀티 호스트 TPU 슬라이스 노드 풀에 예약된 TPU v4, v5p, Ironwood(TPU7x)(미리보기)의 경우 3-튜플({A}x{B}x{C})로 토폴로지를 정의하세요(예: 4x4x4). {A}x{B}x{C}의 결과(곱)는 노드 풀의 TPU 칩 수를 정의합니다. 예를 들어 2x2x2, 2x2x4, 2x4x4와 같은 토폴로지 형식으로 TPU 칩이 64개 이하인 소규모 토폴로지를 정의할 수 있습니다. 64개 이상의 TPU 칩이 있는 더 큰 토폴로지를 사용하는 경우 {A}, {B}, {C}에 할당하는 값은 다음 조건을 충족해야 합니다.

{A}, {B}, {C}는 4의 배수여야 합니다.
v4에서 지원되는 가장 큰 토폴로지는 12x16x16이고 v5p의 경우 16x16x24입니다.
할당된 값은 A ≤ B ≤ C 패턴을 유지해야 합니다. 예를 들면 4x4x8 또는 8x8x8입니다.

머신 유형

TPU 리소스를 지원하는 머신 유형은 ct<version>-hightpu-<node-chip-count>t와 같이 TPU 버전과 노드 슬라이스당 TPU 칩 수를 포함하는 이름 지정 규칙을 따릅니다. 예를 들어 머신 유형 tpu7x-standard-4t는 Ironwood (TPU7x)를 지원하며 TPU 칩 4개를 포함합니다.

권한이 있는 모드

1.28 이전의 GKE 버전을 사용하는 경우 TPU에 액세스할 수 있는 특수 기능으로 컨테이너를 구성해야 합니다. Standard 모드 클러스터에서는 권한 모드를 사용하여 이 액세스 권한을 부여할 수 있습니다. 권한 모드는 securityContext의 다른 많은 보안 설정을 재정의합니다. 자세한 내용은 권한이 있는 모드 없이 컨테이너 실행을 참고하세요.

버전 1.28 이상에는 권한 모드나 특수 기능이 필요하지 않습니다.

GKE의 TPU 작동 방식

Kubernetes 리소스 관리 및 우선순위는 TPU의 VM을 다른 VM 유형과 동일하게 취급합니다. TPU 칩을 요청하려면 리소스 이름 google.com/tpu를 사용하세요.

resources:
  requests:
    google.com/tpu: 4
  limits:
    google.com/tpu: 4

GKE에서 TPU를 사용할 때는 다음 TPU 특성을 고려하세요.

VM은 최대 8개의 TPU 칩에 액세스할 수 있습니다.
TPU 슬라이스에는 고정된 수의 TPU 칩이 포함되며, 이 수는 선택한 TPU 머신 유형에 따라 달라집니다.
요청된 google.com/tpu 수는 TPU 슬라이스 노드에서 사용 가능한 총 TPU 칩 수와 동일해야 합니다. TPU를 요청하는 GKE 포드의 모든 컨테이너에서 노드의 모든 TPU 칩을 사용해야 합니다. 그렇지 않으면 GKE에서 TPU 리소스를 부분적으로 사용할 수 없으므로 배포가 실패합니다. 다음과 같은 시나리오를 가정합니다.
- 2x4 토폴로지를 사용하는 ct5lp-hightpu-4t 머신 유형에는 각각 TPU 칩 4개가 있는 TPU 슬라이스 노드 2개가 포함되므로 TPU 칩이 총 8개입니다. 이 머신 유형을 사용하면 다음 작업을 할 수 있습니다.
- 이 노드 풀의 노드에 8개의 TPU 칩이 필요한 GKE 포드를 배포할 수 없습니다.
- 이 노드 풀의 두 노드 중 하나에 각각 4개의 TPU 칩이 필요한 두 개의 포드를 배포할 수 있습니다.
- 토폴로지 4x4를 사용하는 TPU v5e의 노드 4개에 TPU 칩 16개가 있습니다. 이 구성을 선택하는 GKE Autopilot 워크로드는 복제본 최대 1~4개까지 각 복제본에 TPU 칩 4개를 요청해야 합니다.
표준 클러스터에서는 Kubernetes 포드 여러 개를 VM에 예약할 수 있지만 각 포드의 컨테이너 하나만 TPU 칩에 액세스할 수 있습니다.
kube-dns와 같은 kube-system 포드를 만들려면 각 표준 클러스터에 하나 이상의 TPU 이외의 슬라이스 노드 풀이 있어야 합니다.
기본적으로 TPU 슬라이스 노드에는 TPU가 아닌 워크로드가 TPU 슬라이스 노드에서 예약되지 않도록 방지하는 google.com/tpu taint가 있습니다. TPU를 사용하지 않는 워크로드는 TPU가 아닌 노드에서 실행되므로 TPU를 사용하는 코드에 대해 TPU 슬라이스 노드에서 필요한 컴퓨팅을 확보할 수 있습니다. taint가 TPU 리소스의 완전한 활용을 보장하지는 않습니다.
GKE는 TPU 슬라이스 노드에서 실행되는 컨테이너에서 내보낸 로그를 수집합니다. 자세한 내용은 로깅을 참고하세요.
런타임 성능과 같은 TPU 사용률 측정항목은 Cloud Monitoring에서 사용할 수 있습니다. 자세한 내용은 관측 가능성 및 측정항목을 참고하세요.
GKE Sandbox를 사용하여 TPU 워크로드를 샌드박싱할 수 있습니다. GKE Sandbox는 TPU 모델 v4 이상에서 작동합니다. 자세한 내용은 GKE Sandbox를 참조하세요.

TPU를 사용한 노드 풀 자동 생성

노드 풀 자동 생성은 특정 GKE 버전에서만 다음 Cloud TPU를 지원합니다.

TPU v3: 1.31.0 이상
TPU v5 및 TPU v4: 1.29.0 이상
TPU Trillium: 1.31.1-gke.1146000 이상
Ironwood (TPU7x) (미리보기): 1.34.1-gke.2541000 이상

다른 Cloud TPU 유형은 모든 GKE 버전에서 지원됩니다.

Cloud TPU 노드 풀 자동 확장

GKE는 다음과 같은 방법 중 하나로 클러스터 자동 스케일러를 사용하는 자동으로 생성된 또는 수동으로 생성된 Cloud TPU 노드 풀을 자동으로 확장합니다.

단일 호스트 TPU 슬라이스 노드 풀: GKE는 기존 노드 풀에서 TPU 노드를 추가하거나 삭제합니다. 노드 풀은 0부터 --max-nodes 및 --total-max-nodes 자동 확장 플래그에 따라 결정되는 노드 풀의 최대 크기 사이의 TPU 노드 수를 포함할 수 있습니다. 노드 풀의 모든 TPU 노드의 머신 유형과 토폴로지는 동일합니다. 단일 호스트 TPU 슬라이스 노드 풀을 만드는 방법에 대한 자세한 내용은 단일 호스트 TPU 슬라이스 노드 풀 만들기를 참고하세요.
멀티 호스트 TPU 슬라이스 노드 풀: GKE는 노드 풀을 0부터 TPU 토폴로지를 충족하는 데 필요한 노드 수로 원자적으로 수직 확장합니다. 예를 들어 ct5lp-hightpu-4t 머신 유형과 16x16 토폴로지가 있는 TPU 노드 풀의 경우 노드 풀에는 항상 64개의 노드 또는 0개의 노드가 있습니다. 노드 풀에 TPU 워크로드가 없으면 GKE가 노드 풀을 축소합니다. 노드 풀을 축소하기 위해 GKE는 예약된 모든 포드를 제거하고 노드 풀의 모든 노드를 삭제합니다. 멀티 호스트 TPU 슬라이스 노드 풀을 만드는 방법에 대한 자세한 내용은 멀티 호스트 TPU 슬라이스 노드 풀 만들기를 참고하세요.

워크로드 정책

워크로드 정책은 Ironwood (TPU7x)에서만 지원됩니다.

워크로드 정책은 기본 인프라의 물리적 배치를 구성할 수 있는 리소스 정책의 한 유형입니다. 워크로드 정책은 더 세부적인 제어를 위한 계층적 구성 옵션을 제공합니다.

Ironwood (TPU7x)는 높은 처리량 워크로드 정책을 지원합니다. 이 정책을 사용하면 다음 작업을 할 수 있습니다.

고성능 컴퓨팅 (HPC) 또는 머신러닝 (ML) 학습과 같이 높은 처리량이 필요한 분산 워크로드를 실행합니다. 기본 인프라는 VM 간 네트워크 지연 시간을 줄이기 위해 TPU VM을 함께 배치하도록 구성됩니다.
워크로드 중단을 최소화하도록 TPU VM의 유지보수 전략을 정의합니다.

컬렉션 예약

컬렉션 예약은 TPU Trillium에서만 지원됩니다.

TPU Trillium에서는 컬렉션 예약을 사용하여 TPU 슬라이스 노드를 그룹화할 수 있습니다. 이러한 TPU 슬라이스 노드를 그룹화하면 워크로드 수요를 충족하도록 복제본 수를 더 쉽게 조정할 수 있습니다 . Google Cloud 는 소프트웨어 업데이트를 제어하여 컬렉션 내에서 항상 충분한 슬라이스를 사용하여 트래픽을 처리할 수 있도록 합니다.

TPU Trillium은 추론 워크로드를 실행하는 단일 호스트 및 멀티 호스트 노드 풀의 컬렉션 예약을 지원합니다. 다음은 컬렉션 예약 동작이 사용하는 TPU 슬라이스의 유형에 따라 어떻게 달라지는지 설명합니다.

멀티 호스트 TPU 슬라이스: GKE는 멀티 호스트 TPU 슬라이스를 그룹화하여 컬렉션을 형성합니다. 각 GKE 노드 풀은 이 컬렉션 내의 복제본입니다. 컬렉션을 정의하려면 멀티 호스트 TPU 슬라이스를 만들고 컬렉션에 고유한 이름을 할당합니다. 컬렉션에 TPU 슬라이스를 더 추가하려면 컬렉션 이름과 워크로드 유형이 동일한 멀티 호스트 TPU 슬라이스 노드 풀을 하나 더 만듭니다.
단일 호스트 TPU 슬라이스: GKE는 전체 단일 호스트 TPU 슬라이스 노드 풀을 컬렉션으로 간주합니다. 컬렉션에 TPU 슬라이스를 더 추가하려면 단일 호스트 TPU 슬라이스 노드 풀의 크기를 조정하면 됩니다.

컬렉션 예약 에는 다음과 같은 제한사항이 있습니다.

TPU Trillium의 컬렉션만 예약할 수 있습니다.
노드 풀을 만드는 동안에만 컬렉션을 정의할 수 있습니다.
스팟 VM은 지원되지 않습니다.
멀티 호스트 TPU 슬라이스 노드 풀을 포함하는 컬렉션은 컬렉션 내의 모든 노드 풀에 동일한 머신 유형, 토폴로지, 버전을 사용해야 합니다.

다음과 같은 시나리오에서 컬렉션 예약을 구성할 수 있습니다.

다음 단계

GKE에서 Cloud TPU를 설정하는 방법은 다음 페이지를 참조하세요.