GKE で TPU を計画する

このページでは、Google Kubernetes Engine（GKE）で Tensor Processing Unit（TPU）の使用量を計画し、TPU の構成ミス、非可用性エラー、割り当て不足による中断リスクを軽減する方法について説明します。

GKE で TPU を使用する前に、GKE での TPU の定義と用語を理解しておいてください。

TPU 構成を計画する

GKE クラスタで TPU を使用するには、構成を計画する必要があります。次の手順をおすすめします。

  1. GKE のオペレーション モードを選択する: GKE Autopilot または Standard クラスタの TPU でワークロードを実行します。

    ベスト プラクティス:

    フルマネージドの Kubernetes エクスペリエンスを実現するには、Autopilot クラスタを使用します。

  2. TPU のバージョンを選択する: TPU のタイプによって、価格対性能比、トレーニング スループット、サービス レイテンシなどが異なります。TPU のタイプは、使用可能な CPU とメモリの容量に影響します。

  3. TPU の可用性を確認する: TPU は特定の Google Cloudリージョンで利用できます。GKE ワークロードで TPU タイプを使用するには、そのタイプでサポートされているリージョンにクラスタが存在する必要があります。

  4. TPU トポロジを選択する: TPU スライス内の TPU の物理的な配置。モデルの並列処理要件に一致するトポロジを選択してください。

このページの参照表を使用して、ノードプールが単一ホスト TPU スライスノードか、マルチホスト TPU スライスノードかを特定します。

GKE のオペレーション モードを選択する

TPU は、クラスタで使用可能な GKE オペレーション モードで使用できます。

  • Standard モード: 個々のノードの構成を含め、基盤となるインフラストラクチャをユーザーが管理します。
  • Autopilot モード（推奨）: 基盤となるインフラストラクチャ（ノード構成、自動スケーリング、自動アップグレード、ベースライン セキュリティ構成、ベースライン ネットワーキング構成など）は GKE によって管理されます。Autopilot では、TPU のタイプとトポロジを選択して Kubernetes マニフェストで指定します。GKE は、TPU を使用してノードをプロビジョニングし、ワークロードのスケジューリングを管理します。

ワークロードに最適な GKE のオペレーション モードを選択するには、GKE のオペレーション モードを選択するをご覧ください。

TPU の使用オプションを選択する

GKE で TPU 構成を計画するときは、ワークロードのニーズに合った使用量オプションを選択します。選択した使用量オプションは、使用可能な TPU バージョンと、構成が必要な割り当てに影響します。GKE には、ワークロードのパフォーマンスを維持しながら、リソースの割り当てと費用を最適化するために、次の TPU 使用量オプションが用意されています。

  • Flex Start: 最大 7 日間 Flex Start VM をプロビジョニングします。GKE は、可用性に基づいてベスト エフォートでハードウェアを自動的に割り当てます。詳細については、Flex Start プロビジョニング モードでの GPU、TPU、H4D のプロビジョニングについてをご覧ください。
  • Spot VM: Spot VM をプロビジョニングすると、大幅な割引が適用されます。ただし、Spot VM はいつでもプリエンプトされる可能性があります（30 秒前に警告が表示されます）。詳細については、Spot VM をご覧ください。
  • 最大 90 日間の将来の予約（カレンダー モード）: 指定した期間に最大 90 日間 TPU リソースをプロビジョニングします。詳細については、カレンダー モードの将来の予約で TPU をリクエストするをご覧ください。
  • TPU 予約: 1 年以上の将来の予約をリクエストします。
  • オンデマンド: 事前に容量を調整することなく TPU を使用します。リソースをリクエストする前に、特定のタイプと数量の TPU VM に対して十分なオンデマンド割り当てが必要です。オンデマンドは最も柔軟な使用オプションですが、リクエストを満たすのに十分なオンデマンド リソースが利用できる保証はありません。

別のオプションを指定しない場合、オンデマンドは GKE の TPU のデフォルトの使用モデルです。ワークロードの要件を満たす使用オプションを選択するには、GKE での AI/ML ワークロードのアクセラレータ使用オプションについてをご覧ください。

TPU のバージョンを選択する

TPU スライスの VM の技術特性は次のとおりです。

標準

TPU バージョン マシンタイプ cloud.google.com/gke-tpu-accelerator vCPU 数 VM あたりのチップ数 NUMA ノードの数 プリエンプトされる可能性
Ironwood（TPU7x） tpu7x-standard-4t tpu7x 224 4 2 なし
TPU Trillium（v6e） ct6e-standard-1t tpu-v6e-slice 44 1 1 高い
TPU Trillium（v6e） ct6e-standard-4t tpu-v6e-slice 180 4 1 中
TPU Trillium（v6e） ct6e-standard-8t tpu-v6e-slice 180 8 2 低
TPU v5p
 ct5p-hightpu-4t tpu-v5p-slice 208 4 2 なし
TPU v5e
 ct5lp-hightpu-1t tpu-v5-lite-podslice 24 1 1 高
TPU v5e
 ct5lp-hightpu-4t tpu-v5-lite-podslice 112 4 1 中
TPU v5e
 ct5lp-hightpu-8t tpu-v5-lite-podslice 224 8 1 低
TPU v4
 ct4p-hightpu-4t tpu-v4-podslice 240 4 2 なし
TPU v3（単一ホストのみ）
 ct3-hightpu-4t tpu-v3-device 96 4 2 なし
TPU v3
 ct3p-hightpu-4t tpu-v3-slice 48 4 1 なし

マルチホスト ct5lp- マシンタイプは、大規模なモデルの提供やトレーニングに適しています。マルチホスト ct5lp- マシンは高速リンクで相互接続されています。

Autopilot

TPU バージョン cloud.google.com/gke-tpu-accelerator vCPU 数 NUMA ノードの数 TPU スライスノード内の TPU チップの最大数
Ironwood（TPU7x） tpu7x 224 2 2048
TPU Trillium（v6e） tpu-v6e-slice 44～180 1～2 256
TPU v5p
 tpu-v5p-slice 208 2 6,144
TPU v5e
 tpu-v5-lite-podslice 24～224 1 256
TPU v4
 tpu-v4-podslice 240 2 4,096
TPU v3（単一ホストのみ）
 tpu-v3-device 96 2 8
TPU v3
 tpu-v3-slice 48 1 256

使用する TPU 構成を決定するには、Cloud TPU の料金に関するドキュメントで TPU の仕様と料金を確認してください。

制限事項

使用する TPU を選択する際に、次の制限事項を考慮してください。

  • Ironwood（TPU7x）には次の制限があります。

  • TPU Trillium は、次のバージョンで使用できます。

    • バージョン 1.31.1-gke.1846000 以降の Standard クラスタ。
    • バージョン 1.31.2-gke.1115000 以降の Autopilot クラスタ。

  • TPU Trillium は、ct6e-standard-8t で 2 に設定された SMT の構成をサポートしていません。

  • TPU v5p 自動スケーリングは、バージョン 1.29.2-gke.1035000 または 1.28.7-gke.1020000 以降のコントロール プレーンを実行する GKE クラスタでサポートされています。

  • 容量予約では、特定の予約を使用します。

  • 1 つの TPU VM で最大 256 個の Pod を実行できます。

  • GKE の費用割り当てと使用状況の測定に、TPU の使用量や費用に関するデータは含まれません。

  • クラスタ オートスケーラーは、10 時間以上待機ステータスになっている TPU ノードプールのスケールアップ オペレーションをキャンセルします。クラスタ オートスケーラーは、リソースが使用可能になると、このようなスケールアップ オペレーションを再試行します。この動作のため、予約を使用しない場合に、TPU の取得可能性が低下する可能性があります。

  • Ubuntu ノードはサポートされていません。

  • TPU ノード アーキテクチャは非推奨になりました。GKE で TPU ノード アーキテクチャを引き続きサポートしている TPU バージョンは TPU v3 のみです。

GKE で TPU の可用性を検証する

TPU は特定の Google Cloud リージョンで利用できます。GKE クラスタで TPU タイプを使用するには、そのタイプでサポートされているリージョンにクラスタが存在する必要があります。

Standard

TPU バージョン 次で始まるマシンタイプ 最小 GKE バージョン 可用性 ゾーン
TPU Ironwood（TPU7x） tpu7x-standard-4t 1.34.0-gke.2201000 GA
  • us-central1-ai1a
  • us-central1-c
TPU Trillium（v6e） ct6e- 1.31.2-gke.1115000 GA
  • asia-northeast1-b
  • europe-west4-a
  • southamerica-west1-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • us-south1-ai1b
TPU v5e ct5lp- 1.27.2-gke.2100 GA
  • europe-west4-b
  • us-central1-a
  • us-south1-a
  • us-west1-c
  • us-west4-a
TPU v5p ct5p- 1.28.3-gke.1024000 GA
  • europe-west4-b
  • us-central1-a
  • us-east5-a
TPU v4 ct4p- 1.26.1-gke.1500 GA
  • us-central2-b
TPU v3 ct3p- 1.31.1-gke.1146000 GA
  • europe-west4-a
  • us-central1-a
  • us-central1-b
TPU v3 ct3- 1.31.0-gke.1500 GA
  • europe-west4-a
  • us-central1-a
  • us-central1-b

Autopilot

TPU バージョン cloud.google.com/gke-tpu-accelerator 最小 GKE バージョン 可用性 ゾーン
TPU Ironwood（TPU7x） tpu7x 1.34.1-gke.3084001 GA
  • us-central1-ai1a
  • us-central1-c
TPU Trillium（v6e） tpu-v6e-slice 1.31.2-gke.1384000 GA
  • asia-northeast1-b
  • europe-west4-a
  • southamerica-west1-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • us-south1-ai1b
TPU v5e tpu-v5-lite-podslice 1.27.2-gke.2100 GA
  • europe-west4-b
  • us-central1-a
  • us-south1-a
  • us-west1-c
  • us-west4-a
TPU v5p tpu-v5p-slice 1.28.3-gke.1024000 GA
  • europe-west4-b
  • us-central1-a
  • us-east5-a
TPU v4 tpu-v4-podslice 1.26.1-gke.1500 GA
  • us-central2-b
TPU v3 tpu-v3-slice 1.31.1-gke.1146000 GA
  • europe-west4-a
  • us-central1-a
  • us-central1-b
TPU v3 tpu-v3-device 1.31.0-gke.1500 GA
  • europe-west4-a
  • us-central1-a
  • us-central1-b

トポロジを選択する

TPU バージョンを選択したら、サポートされているトポロジを選択します。トポロジは、TPU スライス内の TPU チップの物理的な配置を定義します。トポロジが大きいほど TPU チップの数が増え、大規模なモデルをより高速に、またはより大きなデータセットでトレーニングするための並列処理が増えます。

GKE は VM のプロビジョニングを自動的に管理しますが、単一ホスト ノードプールとマルチホスト ノードプールの違いを理解すると、トポロジ内のチップの数が基盤となる VM にどのように関連しているかを明確にできます。

  • 単一ホスト: すべてのチップが単一の VM に存在する TPU スライス。通常、チップの数は 4 枚以下です。
  • マルチホスト: チップが複数の VM に分散されている TPU スライス。これは、ほとんどの大規模な TPU ワークロードで一般的です。

チップの合計数が、その TPU バージョンの単一 VM で使用可能なチップ数を超えるトポロジをリクエストすると、GKE は自動的にマルチホスト環境としてプロビジョニングします。このシナリオでは、GKE はチップを分散するために複数のノードを起動します。

たとえば、ct6e-standard-4t マシンタイプと 4x4 トポロジについて考えてみましょう。

  • マシンタイプ ct6e-standard-4t には、VM ごとに 4 個のチップがあります。
  • トポロジ 4x4 には、合計 16 個のチップ（4 * 4）が必要です。
  • 16（トポロジ チップ数）は 4（VM あたりのチップ数）より大きいため、この構成ではマルチホスト TPU スライス ノードプールが作成されます。GKE は 16 個のチップを 4 つの VM に分散します。

下の表を使用して、ユースケースに応じた TPU マシンタイプとトポロジを選択してください。

Standard

TPU のタイプとトポロジを選択したら、それらをワークロード マニフェストで指定します。手順については、GKE Standard に TPU ワークロードをデプロイするをご覧ください。

TPU バージョン マシンタイプ ノードプールのタイプ 技術仕様
Ironwood（TPU7x） tpu7x-standard-4t 単一ホスト
  • トポロジ: 2 x 2 x 1
  • トポロジの TPU チップ数: 4
  • ホスト数: 1
  • VM 数: 1
  • キューブ数: 1/16
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 2 x 2 x 2
  • トポロジの TPU チップ数: 8
  • ホスト数: 2
  • VM 数: 2
  • キューブ数: 1/8
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 2 x 2 x 4
  • トポロジの TPU チップ数: 16
  • ホスト数: 4
  • VM 数: 4
  • キューブ数: 1/4
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • ホスト数: 8
  • VM 数: 8
  • キューブ数: 1/2
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 4 x 4 x 4
  • トポロジの TPU チップ数: 64
  • ホスト数: 16
  • VM 数: 16
  • キューブ数: 1
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 4 x 4 x 8
  • トポロジの TPU チップ数: 128
  • ホスト数: 32
  • VM 数: 32
  • キューブ数: 2
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 4 x 8 x 8
  • トポロジの TPU チップ数: 256
  • ホスト数: 64
  • VM 数: 64
  • キューブ数: 4
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 8 x 8 x 8
  • トポロジの TPU チップ数: 512
  • ホスト数: 128
  • VM 数: 128
  • キューブ数: 8
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: 8 x 8 x 16
  • トポロジの TPU チップ数: 1,024
  • ホスト数: 256
  • VM 数: 256
  • キューブ数: 16
Ironwood（TPU7x） tpu7x-standard-4t マルチホスト
  • トポロジ: {A} x {B} x {C}（A、B、C は 2 の倍数）
  • トポロジの TPU チップ数: A x B x C
  • ホスト数: (A x B x C) / 4
  • VM 数: (A x B x C / 4)
  • キューブ数: (A x B x C / 64)
TPU Trillium（v6e） ct6e-standard-1t 単一ホスト
  • トポロジ: 1 x 1
  • トポロジの TPU チップ数: 1
  • VM 数: 1
TPU Trillium（v6e） ct6e-standard-8t 単一ホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 1
TPU Trillium（v6e） ct6e-standard-4t 単一ホスト
  • トポロジ: 2 x 2
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU Trillium（v6e） ct6e-standard-4t マルチホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU Trillium（v6e） ct6e-standard-4t マルチホスト
  • トポロジ: 4 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU Trillium（v6e） ct6e-standard-4t マルチホスト
  • トポロジ: 4 x 8
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU Trillium（v6e） ct6e-standard-4t マルチホスト
  • トポロジ: 8 x 8
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU Trillium（v6e） ct6e-standard-4t マルチホスト
  • トポロジ: 8 x 16
  • トポロジの TPU チップ数: 128
  • VM 数: 32
TPU Trillium（v6e） ct6e-standard-4t マルチホスト
  • トポロジ: 16 x 16
  • トポロジの TPU チップ数: 256
  • VM 数: 64
TPU v5p ct5p-hightpu-4t 単一ホスト
  • トポロジ: 2 x 2 x 1
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v5p ct5p-hightpu-4t マルチホスト
  • トポロジ: 2 x 2 x 2
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU v5p ct5p-hightpu-4t マルチホスト
  • トポロジ: 2 x 2 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v5p ct5p-hightpu-4t マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v5p ct5p-hightpu-4t マルチホスト
  • トポロジ: {A} x {B} x {C}（A、B、C は 2 の倍数）
  • トポロジの TPU チップ数: A x B x C
  • VM 数: (A x B x C ÷ 4)1
TPU v5e ct5lp-hightpu-1t 単一ホスト
  • トポロジ: 1 x 1
  • トポロジの TPU チップ数: 1
  • VM 数: 1
TPU v5e ct5lp-hightpu-4t 単一ホスト
  • トポロジ: 2 x 2
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v5e ct5lp-hightpu-8t 単一ホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 1
TPU v5e ct5lp-hightpu-4t マルチホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU v5e ct5lp-hightpu-4t マルチホスト
  • トポロジ: 4 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v5e ct5lp-hightpu-4t マルチホスト
  • トポロジ: 4 x 8
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v5e ct5lp-hightpu-4t マルチホスト
  • トポロジ: 8 x 8
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU v5e ct5lp-hightpu-4t マルチホスト
  • トポロジ: 8 x 16
  • トポロジの TPU チップ数: 128
  • VM 数: 32
TPU v5e ct5p-hightpu-4t マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v5e ct5p-hightpu-4t 単一ホスト
  • トポロジ: 2 x 2 x 1
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v4 ct4p-hightpu-4t マルチホスト
  • トポロジ: 2 x 2 x 2
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU v4 ct4p-hightpu-4t マルチホスト
  • トポロジ: 2 x 2 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v4 ct4p-hightpu-4t マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v4 ct4p-hightpu-4t マルチホスト
  • トポロジ: {A} x {B} x {C}（A、B、C は 2 の倍数）
  • トポロジの TPU チップ数: A x B x C
  • VM 数: (A x B x C ÷ 4)1
TPU v3 ct3-hightpu-4t 単一ホスト
  • トポロジ: 2 x 2
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 4 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 4 x 8
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 8 x 8
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 8 x 16
  • トポロジの TPU チップ数: 128
  • VM 数: 32
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 16 x 16
  • トポロジの TPU チップ数: 256
  • VM 数: 64
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 16 x 32
  • トポロジの TPU チップ数: 512
  • VM 数: 128
TPU v3 ct3p-hightpu-4t マルチホスト
  • トポロジ: 32 x 32
  • トポロジの TPU チップ数: 1,024
  • VM 数: 256

  1. トポロジの積を 4 で割った値から計算されます。↩

Autopilot

TPU のタイプとトポロジを選択したら、それらをワークロード マニフェストで指定します。手順については、GKE Autopilot に TPU ワークロードをデプロイするをご覧ください。

TPU バージョン マシンタイプ ノードプールのタイプ 技術仕様
Ironwood（TPU7x） tpu7x 単一ホスト
  • トポロジ: 2 x 2 x 1
  • トポロジの TPU チップ数: 4
  • ホスト数: 1
  • VM 数: 1
  • キューブ数: 1/16
Ironwood（TPU7x） tpu7x マルチホスト
  • トポロジ: 2 x 2 x 2
  • トポロジの TPU チップ数: 8
  • ホスト数: 2
  • VM 数: 2
  • キューブ数: 1/8
Ironwood（TPU7x） tpu7x マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • ホスト数: 8
  • VM 数: 8
  • キューブ数: 1/2
Ironwood（TPU7x） tpu7x マルチホスト
  • トポロジ: 4 x 4 x 4
  • トポロジの TPU チップ数: 64
  • ホスト数: 16
  • VM 数: 16
  • キューブ数: 1
Ironwood（TPU7x） tpu7x マルチホスト
  • トポロジ: 8 x 8 x 8
  • トポロジの TPU チップ数: 512
  • ホスト数: 128
  • VM 数: 128
  • キューブ数: 8
Ironwood（TPU7x） tpu7x マルチホスト
  • トポロジ: 8 x 8 x 16
  • トポロジの TPU チップ数: 1,024
  • ホスト数: 256
  • VM 数: 256
  • キューブ数: 16
Ironwood（TPU7x） tpu7x マルチホスト
  • トポロジ: 8 x 16 x 16
  • トポロジの TPU チップ数: 2,048
  • ホスト数: 512
  • VM 数: 512
  • キューブ数: 32
TPU Trillium（v6e） tpu-v6e-slice 単一ホスト
  • トポロジ: 1 x 1
  • トポロジの TPU チップ数: 1
  • VM 数: 1
TPU Trillium（v6e） tpu-v6e-slice 単一ホスト
  • トポロジ: 2 x 2
  • トポロジの TPU チップ数: 4
  • VM 数: 4
TPU Trillium（v6e） tpu-v6e-slice 単一ホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 8
TPU Trillium（v6e） tpu-v6e-slice マルチホスト
  • トポロジ: 4 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU Trillium（v6e） tpu-v6e-slice マルチホスト
  • トポロジ: 4 x 8
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU Trillium（v6e） tpu-v6e-slice マルチホスト
  • トポロジ: 8 x 8
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU Trillium（v6e） tpu-v6e-slice マルチホスト
  • トポロジ: 8 x 16
  • トポロジの TPU チップ数: 128
  • VM 数: 32
TPU Trillium（v6e） tpu-v6e-slice マルチホスト
  • トポロジ: 16 x 16
  • トポロジの TPU チップ数: 256
  • VM 数: 64
TPU v5p tpu-v5p-slice 単一ホスト
  • トポロジ: 2 x 2 x 1
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v5p tpu-v5p-slice マルチホスト
  • トポロジ: 2 x 2 x 2
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU v5p tpu-v5p-slice マルチホスト
  • トポロジ: 2 x 2 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v5p tpu-v5p-slice マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v5p tpu-v5p-slice マルチホスト
  • トポロジ: 4 x 4 x 4
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU v5p tpu-v5p-slice マルチホスト
  • トポロジ: {A} x {B} x {C}
  • トポロジの TPU チップ数: {A} x {B} x {C}
  • VM 数: (A x B x C ÷ 4)1
TPU v5e tpu-v5-lite-podslice 単一ホスト
  • トポロジ: 1 x 1
  • トポロジの TPU チップ数: 1
  • VM 数: 1
TPU v5e tpu-v5-lite-podslice 単一ホスト
  • トポロジ: 2 x 2
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v5e tpu-v5-lite-podslice 単一ホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 1
TPU v5e tpu-v5-lite-podslice マルチホスト
  • トポロジ: 2 x 4
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU v5e tpu-v5-lite-podslice マルチホスト
  • トポロジ: 4 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v5e tpu-v5-lite-podslice マルチホスト
  • トポロジ: 4 x 8
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v5e tpu-v5-lite-podslice マルチホスト
  • トポロジ: 8 x 8
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU v5e tpu-v5-lite-podslice マルチホスト
  • トポロジ: 8 x 16
  • トポロジの TPU チップ数: 128
  • VM 数: 32
TPU v5e tpu-v5-lite-podslice マルチホスト
  • トポロジ: 16 x 16
  • トポロジの TPU チップ数: 256
  • VM 数: 64
TPU v4 tpu-v4-podslice 単一ホスト
  • トポロジ: 2 x 2 x 1
  • トポロジの TPU チップ数: 4
  • VM 数: 1
TPU v4 tpu-v4-podslice マルチホスト
  • トポロジ: 2 x 2 x 2
  • トポロジの TPU チップ数: 8
  • VM 数: 2
TPU v4 tpu-v4-podslice マルチホスト
  • トポロジ: 2 x 2 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 4
TPU v4 tpu-v4-podslice マルチホスト
  • トポロジ: 2 x 4 x 4
  • トポロジの TPU チップ数: 32
  • VM 数: 8
TPU v4 tpu-v4-podslice マルチホスト
  • トポロジ: 4 x 4 x 4
  • トポロジの TPU チップ数: 64
  • VM 数: 16
TPU v4 tpu-v4-podslice マルチホスト
  • トポロジ: {A} x {B} x {C}
  • トポロジの TPU チップ数: {A} x {B} x {C}
  • VM 数: (A x B x C ÷ 4)1
TPU v3 tpu-v3-slice マルチホスト
  • トポロジ: 4 x 4
  • トポロジの TPU チップ数: 16
  • VM 数: 2
TPU v3 tpu-v3-slice マルチホスト
  • トポロジ: 4 x 8
  • トポロジの TPU チップ数: 32
  • VM 数: 4
TPU v3 tpu-v3-slice マルチホスト
  • トポロジ: 8 x 8
  • トポロジの TPU チップ数: 64
  • VM 数: 8
TPU v3 tpu-v3-slice マルチホスト
  • トポロジ: 8 x 16
  • トポロジの TPU チップ数: 128
  • VM 数: 16
TPU v3 tpu-v3-slice マルチホスト
  • トポロジ: 16 x 16
  • トポロジの TPU チップ数: 256
  • VM 数: 32
TPU v3 tpu-v3-device 単一ホスト
  • トポロジ: 2 x 2
  • トポロジの TPU チップ数: 4
  • VM 数: 1

  1. トポロジの積を 4 で割った値から計算されます。↩

    64 個を超えるチップのカスタム トポロジがサポートされています。次の条件が適用されます。

    • 64 個を超えるチップの場合、{A}、{B}、{C} は 4 の倍数にする必要があります。
    • 最大のトポロジは 16x16x24 です。
    • 値は {A}≤{B}≤{C} にする必要があります（例: 8x12x16）。

  2. カスタム トポロジはサポートされていません。

高度な構成

以降のセクションでは、高度な TPU 構成のスケジューリングのベスト プラクティスについて説明します。

AI ゾーン

AI ゾーンは、AI/ML トレーニング ワークロードと推論ワークロードに使用される特殊なゾーンです。これらのゾーンは、ML アクセラレータの容量を大幅に提供します。詳細については、AI ゾーンのドキュメントをご覧ください。

GKE で AI ゾーンを使用する前に、次の特性を考慮してください。

  • AI ゾーンは、追加のストレージ容量と電力を提供するために、標準ゾーンから物理的に分離されています。この分離によりレイテンシが増加する可能性がありますが、通常、AI/ML ワークロードでは許容されます。
  • AI ゾーンには、ai 表記の接尾辞が付いています。たとえば、us-central1 リージョンの AI ゾーンの名前は us-central1-ai1a です。
  • 現在、サポートされているのは TPU VM のみです。
  • クラスタのコントロール プレーンは、AI ゾーンと同じリージョン内の 1 つ以上の標準ゾーンで実行されます。

  • 次の要件を満たしている場合にのみ、TPU が接続されていない VM を AI ゾーンで実行できます。

    • 同じゾーンで TPU VM を使用する他のワークロードがすでに実行されている。
    • TPU 以外の VM は、Spot VM、予約に関連付けられている VM、または特定のアクセラレータと汎用 VM の比率を持つノードプールの一部です。

  • AI ゾーンは、同じリージョン内で同じ接尾辞を持つ標準ゾーンと、ネットワーキング接続やソフトウェア ロールアウトなどのコンポーネントを共有します。高可用性ワークロードには、異なるゾーンを使用することをおすすめします。たとえば、高可用性のために us-central1-ai1a と us-central1-a の両方を使用することは避けてください。

デフォルトでは、GKE は AI ゾーンにワークロードをデプロイしません。AI ゾーンを使用するには、次のいずれかのオプションを構成する必要があります。

  • （推奨）ComputeClass: AI ゾーンでオンデマンド TPU をリクエストするように、優先度を最高に設定します。ComputeClasses を使用すると、ワークロードのハードウェア構成の優先順位付きリストを定義できます。例については、ComputeClass についてをご覧ください。
  • ノード自動プロビジョニング: Pod 仕様で nodeSelector または nodeAffinity を使用して、AI ゾーンにノードプールを作成するようにノード自動プロビジョニングに指示します。ワークロードが AI ゾーンを明示的にターゲットにしていない場合、ノード自動プロビジョニングは、新しいノードプールの作成時に標準ゾーンまたは --autoprovisioning-locations のゾーンのみを考慮します。この構成により、AI/ML モデルを実行しないワークロードは、明示的に別の構成を行わない限り、標準ゾーンに残ります。nodeSelector を使用するマニフェストの例については、自動作成されたノードのデフォルト ゾーンを設定するをご覧ください。
  • GKE Standard: ノードプールを直接管理する場合は、ノードプールの作成時に --node-locations フラグで AI ゾーンを使用します。例については、GKE Standard に TPU ワークロードをデプロイするをご覧ください。

GKE での TPU の自動スケーリング

GKE は、ML ワークロードを高速化するために Tensor Processing Unit（TPU）をサポートしています。単一ホストの TPU スライス ノードプールとマルチホストの TPU スライス ノードプールはどちらも、自動スケーリングと自動プロビジョニングをサポートしています

GKE クラスタで --enable-autoprovisioning フラグを指定すると、GKE は、TPU のバージョンとトポロジが保留中のワークロードの要件を満たしている単一ホストまたはマルチホストの TPU スライス ノードプールを作成または削除します。

--enable-autoscaling を使用すると、GKE はタイプに基づいてノードプールを次のようにスケーリングします。

  • 単一ホストの TPU スライス ノードプール: GKE は、既存のノードプールで TPU ノードを追加または削除します。ノードプールには、0 からノードプールの最大サイズまでの任意の数の TPU ノードが含まれます。最大サイズは、--max-nodes フラグと --total-max-nodes フラグによって決まります。ノードプールがスケーリングされると、ノードプール内のすべての TPU ノードのマシンタイプとトポロジは同じになります。単一ホストの TPU スライス ノードプールを作成する方法については、ノードプールを作成するをご覧ください。

  • マルチホスト TPU スライス ノードプール: GKE は、ノードプールを 0 から TPU トポロジを満たすために必要なノード数までアトミックにスケールアップします。たとえば、マシンタイプが ct5lp-hightpu-4t でトポロジが 16x16 の TPU ノードプールの場合、ノードプールには 64 個のノードが含まれます。GKE オートスケーラーは、このノードプールのノード数が 0 または 64 になるように調整します。スケールダウンすると、GKE はスケジュールされたすべての Pod を強制排除し、ノードプール全体が 0 になるようにドレインします。マルチホスト TPU スライス ノードプールの作成方法については、ノードプールを作成するをご覧ください。

TPU スライスに追加のストレージをプロビジョニングする

TPU スライスの VM には 100 GiB のブートディスクが含まれています。TPU スライスでトレーニングまたは前処理に追加のストレージが必要な場合や、チェックポイントを保存する必要がある場合は、TPU で使用可能な Google Cloud Hyperdisk またはバランス永続ディスク ストレージを使用できます。TPU の各バージョンでサポートされているディスクタイプの詳細については、Hyperdisk と Persistent Disk の TPU サポートをご覧ください。

Standard クラスタの CPU

GKE は各 TPU スライスを独自のノードに配置するため、このセクションの説明は Autopilot クラスタには当てはまりません。詳細については、Autopilot モードでの TPU の仕組みをご覧ください。

Standard クラスタの場合は、次のスケジューリングのベスト プラクティスを検討してください。

TPU スライスノード内の VM で TPU 以外のワークロードをスケジュールするには、GKE Pod が google.com/tpu taint を許容できることを確認します。ワークロードを特定のノードにデプロイする場合は、ノードセレクタを使用します。

Kubernetes のリソース管理と優先度では、TPU 内の VM は他の VM タイプと同じように扱われます。TPU を必要とする Pod を同じノード上の他の Pod よりも優先するには、その TPU スライスの最大 CPU またはメモリをリクエストします。優先度の低い TPU スライスは、次の処理を行います。

  1. CPU リクエストとメモリ リクエストを少なく設定して、ノードに TPU ワークロード用に十分なリソースを確保します。詳細については、Kubernetes がリソースのリクエストと上限を適用する方法をご覧ください。
  2. CPU の上限を設定しない（無制限）と、Pod がバーストして、未使用のサイクルがすべて使用される可能性があります。
  3. ノードが排除されるリスクを回避しながら、Pod が正常に機能するように、適切なメモリ上限を設定します。

Kubernetes Pod が TPU をリクエストしていても、CPU とメモリをリクエストしない場合、この Kubernetes Pod はベスト エフォート Pod となりますが、CPU とメモリが必要と見なされる保証はありません。このような状態が保証されるのは、CPU とメモリを明示的にリクエストする Pod のみです。特定の Kubernetes スケジューリングの場合、明示的な CPU とメモリのリクエストを使用して Pod のニーズを構成します。詳しくは、Pod とコンテナのリソース管理をご覧ください。

その他のベスト プラクティスについては、Kubernetes のベスト プラクティス: リソース リクエストと上限をご覧ください。

ワークロードの中断を減らす

ML モデルのトレーニングに TPU を使用していて、ワークロードが中断された場合、最後のチェックポイント以降に実行された作業はすべて失われます。ワークロードが中断される可能性を低くするには、次の操作を行います。

  • この Job に他のすべての Job よりも高い優先度を設定します。リソースが不足している場合、GKE スケジューラは優先度の低い Job をプリエンプトして、優先度の高い Job をスケジュールします。また、優先度の高いワークロードは、クラスタで使用可能な合計リソースの範囲内であれば、必要なすべてのリソースを受け取ることもできます。詳細については、Pod の優先度とプリエンプションをご覧ください。
  • メンテナンスの除外を構成する: メンテナンスの除外は、自動メンテナンスの実行が禁止される定期的な時間枠です。詳細については、メンテナンスの除外をご覧ください。
  • Autopilot で拡張ランタイム Pod を使用する: スケールダウンまたはノードのアップグレードのため、GKE が Pod を終了するまでの最大 7 日間の猶予期間は、拡張ランタイム Pod を使用します。
  • TPU Trillium でコレクション スケジューリングを使用する: コレクションを使用して、TPU スライス ノードプールがサービング ワークロードの一部であることを示します。 Google Cloud は、推論ワークロードのオペレーションに対する中断を制限し、効率化します。詳細については、コレクション スケジューリングの仕組みをご覧ください。

これらの推奨事項は中断を最小限に抑えるために役立ちますが、中断を完全に防ぐものではありません。たとえば、ハードウェア障害やデフラグメンテーションによるプリエンプションは引き続き発生する可能性があります。同様に、GKE メンテナンスの除外を設定しても、Compute Engine のメンテナンス イベントは実行されます。

ベスト プラクティス:

チェックポイントを頻繁に保存し、トレーニング スクリプトにコードを追加して、再開時に最後のチェックポイントから開始できるようにします。

ノード メンテナンスによる中断に対処する

TPU をホストする GKE ノードは、メンテナンス イベントなど、ノード シャットダウンの原因となる可能性のある中断の影響を受けます。コントロール プレーンがバージョン 1.29.1-gke.1425000 以降を実行している GKE クラスタでは、ワークロードを正常に停止するように GKE を構成することで、ワークロードの中断を軽減できます。

AI / ML ワークロードを実行している GKE ノードで発生する可能性のある中断イベントを理解、構成、モニタリングするには、GPU と TPU の GKE ノードの中断を管理するをご覧ください。

TPU 使用率を最大にする

TPU を最大限に活用するには、異なる優先度の Job を組み合わせてスケジュールし、TPU の稼働時間が最大になるようにキューに入れます。Job レベルのスケジューリングとプリエンプションの場合は、Job をキューにオーケストレートする Kubernetes のアドオンを使用する必要があります。

ベスト プラクティス:

Kueue を使用して、Job をキューにオーケストレートします。

次のステップ