このドキュメントでは、Google Kubernetes Engine（GKE）の動的スライスについて説明します。動的スライスを使用すると、プロビジョニングされた TPU サブブロックをさまざまなトポロジに構成できます。この機能により、ノードプールを再作成する必要性が減り、障害発生時の自動復旧が可能になることでフォールト トレランスが強化され、リソース使用率が最適化されます。
動的スライスは、TPU の使用率を最適化し、プロビジョニング時間を短縮し、大規模なトレーニングと推論のワークロードのフォールト トレランスを向上させたい AI/ML エンジニアとプラットフォーム管理者を対象としています。
このドキュメントを読む前に、次のことを理解しておいてください。
- GKE の TPU。
- TPU Cluster Director。動的スライスは、TPU Cluster Director によって有効になる TPU 機能です。
- All Capacity モードの予約。動的スライス機能は、All Capacity モードを使用する TPU でのみ使用できます。
動的スライスとは
動的スライスを使用すると、TPU のプロビジョニングを切り離すことができるため、Cloud TPU の容量を柔軟に管理できます。動的スライスには次のプロセスが含まれます。
- リソースをより小さな単位でプロビジョニングする: リソースをサブブロックと呼ばれる単位でプロビジョニングします。サブブロックは、Ironwood（TPU7x）容量の基本的な論理ビルディング ユニットです。Ironwood（TPU7x）の場合、サブブロックは、相互接続された TPU チップの
4x4x4トポロジを持つ TPU VM の 16 ノード グループを表します。TPU All Capacity モードと動的スライシングのコンテキストでは、ノードプールはサブブロックに直接マッピングされます。 - サブブロックを結合する: 動的スライスは、これらのサブブロックを結合して大きなスライスにします。
動的スライスのメリット
動的スライスを使用すると、次のことが可能になります。
- プロビジョニング時間を短縮する: サブブロックを個別にプロビジョニングすると、単一の障害の影響が最小限に抑えられるため、全体的なプロビジョニングが高速化されます。
- 復旧時間を短縮する: TPU チップの障害が発生した場合、障害の最小単位はサブブロックです。動的スライスは、障害のあるサブブロックを分離するため、ワークロードを健全なサブブロックに再スケジュールする方が、大きなスライス全体を再プロビジョニングするよりも高速です。
- 容量の再構成: ワークロード要件が多様な場合、トポロジの変更のためにノードプールを削除して再作成する必要はありません。代わりに、指定したシェイプに合わせてプロビジョニングされたノードプールを動的に再構成できます。
動的スライシングの主な要素
動的スライスでは、次の重要なコンセプトが導入されています。
- ノードプールの増分プロビジョニング: 動的スライスでは、ノードプールのフォールト トレラントなプロビジョニング モデルである増分プロビジョニングが使用されます。このモデルは、すべての TPU 容量を 16 ノードの TPU VM グループのノードプールに変換します。
- スライス コントローラ: GKE コントロール プレーン内で実行され、動的スライスを管理する Kubernetes カスタム リソース コントローラ。スライス コントローラは、動的スライスを表す Slice カスタム リソースのライフサイクルを管理します。スライス コントローラは、スライスの作成、継続的なモニタリング、削除を処理します。スケジューラを使用すると、スケジューラは Slice カスタム リソースの作成と削除を指示します。
- スライス カスタム リソース: リクエストされた TPU トポロジに基づいてサブブロックを動的に結合します。このプロセスでは、OCS ネットワークの動的再構成を利用して TPU ノードプールを接続し、パフォーマンスの最適化を実現します。Slice カスタム リソースのステータス フィールドを調べることで、動的スライスの形成の進行状況や健全性を確認できます。
動的スライシングのスケジューラ
Kueue と Topology Aware Scheduling（TAS）を構成して、Slice カスタム リソースを自動的に作成できます。独自のスケジューラを使用して Slice カスタム リソースを管理することもできます。