GKE에서 TPU 멀티슬라이스 배포

Autopilot Standard

이 페이지에서는 비용 효율적인 대규모 학습을 위해 Cloud TPU 멀티슬라이스 구성을 사용하여 Google Kubernetes Engine(GKE)에서 워크로드를 배포하는 방법을 보여줍니다.

GKE에서 멀티슬라이스를 구성하려면 다음 개념을 숙지해야 합니다.

TPU 멀티슬라이스란?

TPU 멀티슬라이스는 Cloud TPU 슬라이스 2개 이상이 데이터 센터 네트워크(DCN)를 통해 통신하는 TPU 슬라이스의 VM 아키텍처 구성입니다. 멀티슬라이스는 TPU 칩을 최대 10,000개까지 선형에 가깝게 수직 확장하여 경제적인 풀 스택 대규모 학습을 지원합니다. 멀티슬라이스 구성에서 GKE는 여러 TPU 슬라이스에 멀티슬라이스 워크로드를 배포합니다. 슬라이스 내에서 TPU 칩 간 통신은 내부 칩 상호 연결(ICI)을 통해 수행됩니다. 슬라이스 간 통신은 DCN을 통해 수행됩니다.

작업이 너무 커서 단일 TPU 슬라이스에 맞지 않으면 멀티슬라이스를 사용하는 것이 좋습니다.

GKE의 멀티슬라이스 가용성

Standard는 1.27.4-gke.900 이상 버전에서 멀티슬라이스를 지원합니다.
Autopilot은 1.29.2-gke.1521000 이상 버전에서 멀티슬라이스를 지원합니다.
멀티슬라이스는 JAX 및 PyTorch 프레임워크를 지원합니다. 지원되는 최소 JAX 버전은 2.1입니다.
멀티슬라이스는 멀티 호스트 TPU 슬라이스 노드 풀만 지원합니다. 예를 들어 2x2x1 토폴로지의 ct4p-hightpu-4t 또는 2x2 토폴로지의 ct5lp-hightpu-4t에는 단일 호스트 TPU 슬라이스 노드 풀이기 때문에 멀티슬라이스를 사용할 수 없습니다.
멀티슬라이스는 동기식 멀티 컨트롤러 학습만 지원합니다.
멀티슬라이스 워크로드는 동일한 TPU 유형, 크기, 토폴로지를 공유하는 TPU 슬라이스에서만 실행될 수 있습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

Google Kubernetes Engine API를 사용 설정합니다.

Google Kubernetes Engine API 사용 설정

이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우 gcloud components update를 실행하여 최신 버전을 가져옵니다.
참고: 기존 gcloud CLI 설치의 경우 compute/region 및 compute/zone 속성을 설정해야 합니다. 기본 위치를 설정하면 gcloud CLI에서 One of [--zone, --region] must be supplied: Please specify location과 같은 오류를 방지할 수 있습니다.

멀티슬라이스를 지원하는 버전을 실행하는 Standard 클러스터 또는 Autopilot 클러스터를 만듭니다. 지원되는 버전은 GKE의 멀티슬라이스 가용성을 참조하세요.
GKE에서 Cloud TPU에 대해 프로젝트 할당량이 충분한지 확인합니다.
v0.2.3 이상의 JobSet을 설치합니다.

멀티슬라이스에서 워크로드 실행

이 섹션에서는 멀티슬라이스에서 워크로드를 실행하는 방법을 보여줍니다. GKE Autopilot 모드를 사용하는 경우 멀티슬라이스 워크로드 실행 섹션으로 건너뜁니다. 버전 1.29.2-gke.1521000 이상을 실행하는 Autopilot 클러스터는 기본적으로 TPU를 사용 설정합니다.

Standard 모드 노드 풀 준비

이 섹션에서는 다음 단계에 대해 설명합니다.

3개의 멀티 호스트 TPU 슬라이스 노드 풀 만들기
노드 풀 상태 확인

TPU 슬라이스 노드 풀 만들기

멀티 호스트 TPU 노드 풀을 2개 이상 만들 수 있습니다. 이 가이드에서는 멀티 호스트 TPU 슬라이스 노드 풀을 3개 만들어 멀티슬라이스 워크로드를 실행합니다. Google Cloud CLI, Terraform 또는 Google Cloud 콘솔을 사용하여 멀티 호스트 TPU 슬라이스 노드 풀을 만들 수 있습니다.

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONE \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    [--spot \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME]

다음을 바꿉니다.

POOL_NAME: 새 노드 풀의 이름.
LOCATION: 사용할 TPU 버전에 따른 영역의 이름
- TPU v4의 경우 us-central2-b를 사용합니다.
- ct5l-로 시작하는 TPU v5e 머신 유형은 멀티 호스트가 아닙니다.
- ct5lp-로 시작하는 TPU v5e 머신 유형의 경우 us-west1-c, us-west4-a, us-west4-b, us-central1-a, us-east1-c, us-east5-b, europe-west4-a를 사용합니다.
- ct5p-로 시작하는 TPU v5p 머신 유형의 경우 us-east1-d, us-east5-a, us-east5-c를 사용합니다.
자세한 내용은 GKE의 TPU 가용성을 참조하세요.
CLUSTER_NAME: 클러스터의 이름
NODE_ZONE: GKE가 노드 풀을 만드는 하나 이상의 영역 쉼표로 구분된 목록
MACHINE_TYPE: 노드에 사용할 머신 유형. 사용 가능한 머신 유형에 대해 자세히 알아보려면 TPU 구성 매핑을 참조하세요.
TPU_TOPOLOGY: TPU 슬라이스의 물리적 토폴로지. 토폴로지 형식은 다음과 같이 TPU 버전에 따라 달라집니다.
- TPU v4 또는 v5p: 3-튜플({A}x{B}x{C})로 토폴로지를 정의합니다(예: 4x4x4).
- TPU v5e: 2-튜플({A}x{B})로 토폴로지를 정의합니다(예: 2x2).
자세한 내용은 토폴로지를 참조하세요.
NUM_NODES: 노드 풀의 노드 수. 0이거나, TPU_TOPOLOGY에 정의된 값의 곱({A}x{B}x{C})을 각 VM의 칩 수로 나눈 값이어야 합니다. 멀티 호스트 TPU v4 및 TPU v5e의 경우 각 VM의 칩 수는 4개입니다. 따라서 TPU_TOPOLOGY가 2x4x4(각 VM에 4개의 칩이 포함된 TPU v4)인 경우 NUM_NODES는 8과 동일한 32/4입니다.

선택적으로 다음 플래그를 사용할 수도 있습니다.

RESERVATION_NAME: 노드 풀을 만들 때 GKE가 사용하는 예약의 이름. 이 플래그를 생략하면 GKE에서 사용 가능한 TPU 슬라이스 노드 풀을 사용합니다. TPU 예약에 대한 자세한 내용은 TPU 예약을 참조하세요.
--spot: TPU 슬라이스 노드에 스팟 VM을 사용하도록 노드 풀을 설정합니다. 노드 풀을 만든 후에는 변경할 수 없습니다. 자세한 내용은 스팟 VM을 참조하세요.
--enable-autoscaling: 자동 확장이 사용 설정된 노드 풀을 만듭니다. GKE는 멀티 호스트 TPU 슬라이스 노드 풀을 확장할 때 노드 풀을 0에서 최대 크기로 원자적으로 수직 확장합니다.
- MAX_NODES: 노드 풀의 최대 크기입니다. --enable-autoscaling이 제공되는 경우 --max-nodes 플래그가 필요하며 TPU_TOPOLOGY({A}x{B}x{C})에 정의된 값의 곱을 각 VM의 칩 수로 나눈 값과 같아야 합니다.

Terraform

google 제공업체 버전 4.84.0 이상을 사용해야 합니다.
Terraform 구성에 다음 블록을 추가합니다.
```
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}
```
다음을 바꿉니다.
- NODE_POOL_RESOURCE_NAME: Terraform 템플릿의 노드 풀 리소스 이름
- PROJECT_ID: 프로젝트 ID입니다.
- CLUSTER_NAME: 노드 풀을 추가할 기존 클러스터의 이름
- POOL_NAME: 만들 노드 풀의 이름
- CLUSTER_LOCATION: 클러스터의 컴퓨팅 위치. Kubernetes 제어 영역의 신뢰성 향상을 위해 리전 클러스터를 사용하는 것이 좋습니다. 영역 클러스터를 사용할 수도 있습니다. 자세한 내용은 TPU 버전 및 토폴로지 선택을 참조하세요.
- NODE_ZONES: GKE가 노드 풀을 만드는 하나 이상의 영역을 쉼표로 구분한 목록
- NUM_NODES: 노드 풀의 노드 수. 0이거나 TPU 칩 수의 곱을 4(멀티 호스트 TPU 슬라이스의 TPU 슬라이스 노드마다 칩이 4개 있기 때문)로 나눈 값이어야 합니다. 예를 들어 TPU_TOPOLOGY가 4x8이면 칩이 32개 있으므로 NUM_NODES는 8이어야 합니다. TPU 토폴로지에 대한 자세한 내용은 TPU 구성 매핑의 표를 참조하세요.
- TPU_TOPOLOGY: TPU 슬라이스에 대해 원하는 물리적 토폴로지를 나타냅니다. 토폴로지 형식은 사용 중인 TPU 버전에 따라 달라집니다.
  - TPU v4의 경우: 3-튜플({A}x{B}x{C})로 토폴로지를 정의합니다(예: 4x4x4).
  - TPU v5e: 2-튜플({A}x{B})로 토폴로지를 정의합니다(예: 2x2).
선택적으로 다음 변수를 사용할 수도 있습니다.
- RESERVATION_NAME: TPU 예약을 사용하는 경우 노드 풀을 만들 때 사용할 예약 리소스의 라벨 목록입니다. reservation_affinity 필드에 RESERVATION_LABEL_VALUES를 채우는 방법에 대한 자세한 내용은 Terraform 제공업체를 참조하세요.
- autoscaling: 자동 확장이 사용 설정된 노드 풀을 만듭니다. GKE는 멀티 호스트 TPU 슬라이스 노드 풀을 확장할 때 노드 풀을 0에서 최대 크기로 원자적으로 수직 확장합니다.
  - MAX_NODES: 노드 풀의 최대 크기입니다. TPU_TOPOLOGY에 정의된 값의 곱({A}x{B}x{C})을 각 VM의 칩 수로 나눈 값이어야 합니다.
- spot: 노드 풀에서 TPU 슬라이스 노드에 스팟 VM을 사용할 수 있게 합니다. 노드 풀을 만든 후에는 변경할 수 없습니다. 자세한 내용은 스팟 VM을 참조하세요.

콘솔

TPU가 포함된 노드 풀을 만들려면 다음 안내를 따르세요.

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.
노드 풀 추가를 클릭합니다.
노드 풀 세부정보 섹션에서 노드 위치 지정 체크박스를 선택합니다.
사용할 TPU 버전에 따라 영역을 선택합니다.
- TPU v4의 경우 us-central2-b를 사용합니다.
- ct5l-로 시작하는 TPU v5e 머신 유형은 멀티 호스트가 아닙니다.
- ct5lp-로 시작하는 TPU v5e 머신 유형의 경우 us-west1-c, us-west4-a, us-west4-b, us-central1-a, us-east1-c, us-east5-b, europe-west4-a를 사용합니다.
- ct5p-로 시작하는 TPU v5p 머신 유형의 경우 us-east1-d, us-east5-a, us-east5-c를 사용합니다.
탐색창에서 노드를 클릭합니다.
머신 구성 섹션에서 TPU를 선택합니다.
시리즈 드롭다운 메뉴에서 다음 중 하나를 선택합니다.
- CT4P: TPU v4의 경우에 선택합니다.
- CT5LP: TPU v5e의 경우에 선택합니다.
머신 유형 드롭다운 메뉴에서 노드에 사용할 머신 이름을 선택합니다. TPU 구성 매핑 테이블을 사용하여 머신 유형 및 멀티 호스트 TPU 노드 풀을 만드는 TPU 토폴로지를 정의하는 방법을 알아봅니다.
TPU 토폴로지 드롭다운 메뉴에서 TPU 슬라이스의 물리적 토폴로지를 선택합니다.
필요한 변경사항 대화상자에서 변경을 클릭합니다.
부팅 디스크 유형이 표준 영구 디스크 또는 SSD 영구 디스크인지 확인합니다.
선택적으로 노드 풀의 노드에 Spot VM을 사용하려면 스팟 VM에서 노드 사용 설정 체크박스를 선택합니다.
만들기를 클릭합니다.

노드 풀 상태 확인

kubectl을 사용해 클러스터에 액세스할 수 있도록 사용자 인증 정보를 받습니다.
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID
```
다음을 바꿉니다.
- CLUSTER_NAME: 클러스터의 이름
- PROJECT_ID: 프로젝트 ID입니다.
Cloud Shell에서 kubectl을 사용하여 TPU 슬라이스 노드를 확인합니다.
```
kubectl get nodes -l cloud.google.com/gke-tpu-accelerator=TPU_ACCELERATOR \
   -l cloud.google.com/gke-tpu-topology=TPU_TOPOLOGY
```
다음을 바꿉니다.
- TPU_ACCELERATOR: 노드 풀을 만들 때 사용한 TPU 가속기의 유형입니다. 예를 들면 tpu-v4-podslice, tpu-v5-lite-device, tpu-v5-lite-podslice입니다.
- TPU_TOPOLOGY: TPU 슬라이스의 물리적 토폴로지입니다.
출력은 다음과 비슷합니다.
```
 NAME                                    STATUS   ROLES    AGE    VERSION
 gke-tpu-20ee2cce-5tv6                   Ready    <none>   34h     v1.28.1-gke.1066000
```

멀티슬라이스 워크로드 실행

이 섹션에서는 TPU 슬라이스의 전역 TPU 칩 수를 표시하고 종료되는 JAX 워크로드를 실행합니다.

JAX 워크로드를 실행하려면 다음을 수행합니다.

다음 tpu-multislice.yaml 매니페스트를 만듭니다.

Autopilot

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: multislice-job
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-nodepool
spec:
  failurePolicy:
    maxRestarts: 4
  replicatedJobs:
    - name: slice
      replicas: NUM_SLICES
      template:
        spec:
          parallelism: NUM_NODES
          completions: NUM_NODES
          backoffLimit: 0
          template:
            spec:
              nodeSelector:
                cloud.google.com/gke-tpu-accelerator: ACCELERATOR_TYPE
                cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
              containers:
              - name: jax-tpu
                image: python:3.8
                ports:
                - containerPort: 8471
                - containerPort: 8080
                - containerPort: 8431
                command:
                - bash
                - -c
                - |
                  pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                  python -c 'import jax; print("Global device count:", jax.device_count())'
                  sleep 60
                resources:
                 limits:
                    google.com/tpu: NUM_CHIPS

표준

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: multislice-job
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-nodepool
spec:
  failurePolicy:
    maxRestarts: 4
  replicatedJobs:
    - name: slice
      replicas: NUM_SLICES
      template:
        spec:
          parallelism: NUM_NODES
          completions: NUM_NODES
          backoffLimit: 0
          template:
            spec:
              hostNetwork: true
              dnsPolicy: ClusterFirstWithHostNet
              nodeSelector:
                cloud.google.com/gke-tpu-accelerator: ACCELERATOR_TYPE
                cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
              containers:
              - name: jax-tpu
                image: python:3.8
                ports:
                - containerPort: 8471
                - containerPort: 8080
                - containerPort: 8431
                securityContext:
                  privileged: true
                command:
                - bash
                - -c
                - |
                  pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                  python -c 'import jax; print("Global device count:", jax.device_count())'
                  sleep 60
                resources:
                  limits:
                   google.com/tpu: NUM_CHIPS

다음을 바꿉니다.

NUM_SLICES: TPU 슬라이스 노드 풀 수입니다. 여기에서 NUM_SLICES는 3입니다.
ACCELERATOR_TYPE: 노드 풀을 만들 때 사용한 TPU 가속기의 유형입니다. 예를 들면 tpu-v4-podslice, tpu-v5-lite-device, tpu-v5-lite-podslice입니다.
TPU_TOPOLOGY: TPU 슬라이스의 물리적 토폴로지입니다. 예를 들어 TPU 버전에 따라 4x4x4 또는 2x2입니다.
NUM_NODES: 노드 풀의 노드 수입니다. 0이거나 TPU_TOPOLOGY에 정의된 값의 곱({A}x{B}x{C})을 각 VM의 TPU 칩 수로 나눈 값이어야 합니다. 멀티호스트 TPU v4의 경우 각 VM의 TPU 칩 수는 4개입니다. 멀티호스트 TPU v5e의 경우 각 VM의 TPU 칩 수는 1개, 4개 또는 8개입니다. 따라서 TPU_TOPOLOGY가 2x4x4(VM마다 TPU 칩 4개가 있는 TPU v4)인 경우 NUM_NODES는 8과 같은 32/4입니다.
NUM_CHIPS: 멀티호스트 TPU v4의 경우 각 VM의 TPU 칩 수는 4개입니다. 멀티호스트 TPU v5e의 경우 각 VM의 TPU 칩 수는 1개, 4개 또는 8개입니다. 자세한 내용은 TPU 슬라이스의 VM에 있는 TPU 칩을 참조하세요.

이 매니페스트에서 각 항목은 다음을 수행합니다.

JobSet는 JobSet 이름과 같은 이름의 헤드리스 서비스입니다(여기에서는 multislice-job).
maxRestarts: 4는 하위 작업이 실패할 때 GKE가 JobSet를 다시 시작하는 최대 횟수를 나타냅니다. JobSet 재시작이 정의된 최댓값에 도달하면 JobSet가 실패로 표시됩니다.
parallelism 및 completions 필드는 각 노드 풀에 있는 노드 수와 동일합니다.
멀티슬라이스가 동기식 멀티 컨트롤러 학습만 지원하기 때문에 backoff는 0입니다. 0으로 설정해야 합니다. 포드가 실패하면 작업이 실패합니다.
어피니티 섹션의 값은 멀티슬라이스 그룹에서 TPU 멀티슬라이스 워크로드가 하나만 실행되도록 보장합니다.
containerPort: 8080은 MXLA 코디네이터의 포트입니다.
containerPort: 8431은 TPU 사용량 측정항목을 내보내는 포트입니다.
securityContext: privileged: true는 TPU에 액세스하기 위해 노드에 권한 모드가 사용 설정되었음을 나타냅니다. GKE 버전 1.28 이상의 노드는 TPU에 액세스하기 위해 권한 모드를 사용 설정할 필요가 없습니다. 자세한 내용은 권한 모드 없이 컨테이너 실행을 참조하세요.

매니페스트를 적용합니다.
```
kubectl apply -f tpu-multislice.yaml
```

워크로드가 수락되었는지 확인합니다.

kubectl get jobsets

출력은 다음과 비슷합니다.

NAME            RESTARTS   COMPLETED   AGE
multislice-job                         3s

프로비저닝된 포드의 상태를 모니터링합니다.

kubectl get pods

출력은 다음과 비슷합니다.

 NAME                                READY   STATUS      RESTARTS   AGE
 multislice-job-slice-0-0-wzq9t      0/1     Completed   0          2m31s
 multislice-job-slice-0-1-zf4dp      0/1     Completed   0          2m30s
 multislice-job-slice-1-0-hbfn5      0/1     Completed   0          2m31s
 multislice-job-slice-1-1-45fgl      0/1     Completed   0          2m30s
 multislice-job-slice-2-0-wjbp4      0/1     Completed   0          2m30s
 multislice-job-slice-2-1-lwnvs      0/1     Completed   0          2m30s

multislice-job JobSet는 포드를 예약하고, 만들고, 끝까지 실행합니다. 포드 이름은 <jobsetName>-<jobName>-<jobReplicaIndex>-<randomSuffix> 형식입니다. jobsetName 프리픽스에 따라 포드가 속한 JobSet가 결정됩니다.

추가 구성

다음 섹션에서는 멀티슬라이스에 적용할 수 있는 추가 구성에 대해 설명합니다.

GKE Standard 포드에서 hostNetwork 사용 설정

TPU 슬라이스 간의 네트워크 성능을 향상시키려면 hostNetworking을 사용 설정하는 것이 좋습니다. 포드 사양에서 hostNetwork: true를 사용해서 Kubernetes 네트워킹 스택을 모두 건너뛰고 Kubernetes 포드가 VM간 통신에 호스트 네트워크를 직접 사용할 수 있게 합니다.

hostNetworking을 사용 설정하려면 포드 사양에서 다음 두 줄을 삭제합니다.

hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet

hostNetwork를 사용하는 워커 노드 검색에 podHostnames를 계속 사용하려면 dnsPolicy: ClusterFirstWithHostNet를 설정합니다. 이는 자동 재개 학습 작업을 실행 중이고 동일한 체크포인트를 새로고침하기 위해 동일한 이름을 사용해야 하는 경우에 중요합니다.

로깅

TPU 슬라이스 노드를 포함하여 GKE 노드에서 실행되는 컨테이너에서 내보낸 로그는 클러스터에서 GKE 시스템 로깅을 사용 설정한 경우에 로그 탐색기에 표시됩니다.

다음 필터와 함께 로그 탐색기를 사용해서 GKE에서 로그를 확인하여 워크로드의 컨테이너 로그를 볼 수 있습니다.

resource.type="k8s_container"
resource.labels.cluster_name=CLUSTER_NAME
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"=JOBSET_NAME

TPU 슬라이스 및 작업자에 대해 다음 필터를 사용합니다.

resource.type="k8s_container"
resource.labels.cluster_name=CLUSTER_NAME
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"=JOBSET_NAME
resource.labels.pod_name:<jobSetName>-<replicateJobName>-<job-index>-<worker-index>

자세한 내용은 GKE TPU 로그 보기를 참조하세요.

관측 가능성 및 측정항목

일반적인 TPU 측정항목 외에도 4개의 추가 멀티슬라이스 특정 TPU 런타임 측정항목이 있습니다. 이러한 측정항목은 GKE 버전 1.29.1-gke.1016000 이상에서 사용할 수 있습니다. TPU 워크로드는 JAX 버전 0.4.24를 사용해야 합니다.

다음은 사용 가능한 멀티슬라이스 측정항목입니다.

DCN(데이터 센터 네트워크) 전송 지연 시간: 멀티슬라이스 트래픽의 네트워크 전송 지연 시간 분포입니다.
집합 지연 시간: 멀티슬라이스 트래픽의 엔드 투 엔드 집합 지연 시간의 분포입니다.
호스트-기기 전송 지연 시간: 멀티슬라이스 트래픽의 각 데이터 청크에 대한 호스트-기기 전송 지연 시간 분포입니다.
기기-호스트 전송 지연 시간: 멀티슬라이스 트래픽의 각 데이터 청크에 대한 기기-호스트 전송 지연 시간 분포입니다.

이러한 측정항목은 Kubernetes 컨테이너(k8s_container) 스키마에 있습니다.

kubernetes.io/container/multislice/network/dcn_transfer_latencies
kubernetes.io/container/multislice/network/collective_end_to_end_latencies
kubernetes.io/container/multislice/accelerator/host_to_device_transfer_latencies
kubernetes.io/container/multislice/accelerator/device_to_host_transfer_latencies

TPU 슬라이스와 멀티슬라이스 비교

다음 표에서는 TPU 슬라이스와 멀티슬라이스의 아키텍처 구성을 비교해서 보여줍니다.

	TPU 슬라이스	멀티슬라이스
상호 연결	워크로드가 단일 TPU 슬라이스에서 실행됩니다. 슬라이스의 모든 TPU 칩이 ICI로 연결됩니다.	워크로드가 여러 TPU 슬라이스에서 실행됩니다. 슬라이스 내 통신이 ICI를 통해 수행됩니다. 슬라이스 간 통신이 DCN을 통해 수행됩니다.
지원되는 노드 풀	단일 호스트 TPU 슬라이스와 멀티 호스트 TPU 슬라이스	멀티 호스트 TPU 슬라이스의 그룹
권장 워크로드 유형	IndexedJob 또는 JobSet	JobSet

다음 단계

TPU 슬라이스로 멀티슬라이스 워크로드 조정 방법 알아보기