翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon SageMaker HyperPod でのトポロジー認識スケジューリングの使用 データ転送効率は、ハイパフォーマンスコンピューティング (HPC) と機械学習ワークロードの重要な要素です。Amazon SageMaker HyperPod で UltraServer を使用する場合、SageMaker HyperPod はトポロジーラベルをリソースに自動的に適用します。トポロジー認識スケジューリングは、インスタンストポロジー (インスタンス内でのリソースの接続方法) とネットワークトポロジー (インスタンス間の接続方法) の両方を考慮して、リソースを割り当てて、データ転送オーバーヘッドを最小限に抑えるのに役立ちます。インスタンスサイズの詳細については、「[Amazon EC2 インスタンスタイプのトポロジー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html)」を参照してください。 トポロジー認識スケジューリングは、Slurm と Amazon EKS の両方のクラスターで機能します。トポロジと Slurm の連携に関する一般的な情報については、「[Slurm ドキュメントのトポロジガイド](https://slurm.schedmd.com/topology.html)」を参照してください。 Amazon SageMaker HyperPod では、データ転送オーバーヘッドが通常 3 つの主要なソースから発生します。 + **GPU-to-GPU データ転送**: NVLink や NVLink スイッチなどの最新のテクノロジーにより、他のコンピューティングリソースを介さず GPU 間で高スループットのデータ転送が可能になります。これは非常に効率的ですが、通常は単一のインスタンスに限定されます。 + **GPU-to-CPU データ転送**: 不均一なメモリアクセス (NUMA) システムには、単一のクリップボードに複数のシステムバスがあります。p5.48xlarge などの一般的な EC2 インスタンスアーキテクチャには、それぞれ CPU と 4 つの GPU を備えた 2 つの異なるシステムバスがあります。最適なパフォーマンスを得るには、GPU との間でデータをロードまたは読み取るプロセスは、GPU と同じシステムバスに接続された CPU で実行されている必要があります。 + **インスタンス間のネットワーク通信**: インスタンスはネットワークスイッチのチェーンを介してデータを転送します。通常、最短パスでは最小のレイテンシーになります。 ## UltraServer アーキテクチャ SageMaker HyperPod は、p6e-gb200.36xlarge インスタンスを使用した UltraServer アーキテクチャをサポートしています。UltraServer には、各インスタンスに 4 個の GPU を備えたp6e-gb200.36xlarge インスタンスが最大 18 個含まれています。すべてのノードのすべての GPU は NVLink スイッチを介して相互接続されるため、ネットワークインターフェイスを使用せずに 2 つの GPU 間でデータ転送を行うことができます。 このアーキテクチャは、個々のインスタンスと比較してパフォーマンスが大幅に向上します。このアーキテクチャを効果的に活用するには、単一の UltraServer からコンピューティングノードにジョブを送信する必要があります。 ### EKS トポロジーラベル EC2 インスタンストポロジーに従って、HyperPod はノードに自動的に次のラベルを付けます。 + **topology.kubernetes.io/region** - ノード AWS リージョン が存在する 。 + **topology.kubernetes.io/zone** - ノードが配置されているアベイラビリティーゾーン + **topology.k8s.aws/network-node-layer** - NetworkNodes はインスタンスのネットワークノードセットを記述します。各ネットワークノードセットではネットワークノードは上から下に階層的に一覧表示されます。インスタンスに接続されているネットワークノードは一覧にある最後のネットワークノード (最下層) です。最大 4 つのネットワークノードレイヤーがあり、各ノードにはラベルが付けられます。使用可能なレイヤーは、`topology.k8s.aws/network-node-layer-1`、`topology.k8s.aws/network-node-layer-2`、`topology.k8s.aws/network-node-layer-3` です。 + **topology.k8s.aws/ultraserver-id** - Ultraserver 内の同じ NVLink ドメインに属する各インスタンスにラベルを付けるために使用される識別子。SageMaker HyperPod と UltraServer の連携の詳細については、「[Amazon SageMaker HyperPod での UltraServer の使用](sagemaker-hyperpod-ultraserver.md)」を参照してください。 これらのラベルを使用すると、HyperPod タスクガバナンスでトポロジー認識スケジューリングを使用してトポロジラベルと注釈を適用し、ワークロードのトレーニング効率を最適化できます。詳細については、「[Amazon SageMaker HyperPod タスクガバナンスでのトポロジー認識スケジューリングの使用](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks-scheduling.md)」を参照してください。 ## Slurm ネットワークトポロジープラグイン Slurm は、ネットワークトポロジー認識のための組み込みプラグインを提供しています。SageMaker HyperPod は、クラスター内のインスタンスタイプに基づいて、適切なトポロジプラグインを自動的に選択して設定します。 ### 自動トポロジ選択 HyperPod Slurm クラスターを作成すると、システムはすべてのインスタンスグループと関連するインスタンスタイプを検査し、各インスタンスタイプの GPU 通信特性を識別し、適切なトポロジプラグインを使用して Slurm を設定します。このプロセスは自動的に実行され、設定は必要ありません。 HyperPod は、動的に生成された設定ファイルを通じてトポロジを管理します。Slurm 25.11 以降では、トポロジは信頼できるソースであり、複数のトポロジ定義とパーティションごとの割り当てをサポートする `topology.yaml` ファイルで定義されます。Slurm 24.x では、トポロジは単一のクラスター全体のトポロジを持つ`topology.conf`ファイルで定義されます。クラスターがスケーリングオペレーションまたはノード置換によって進化するにつれて、HyperPod はトポロジ設定を継続的に調整して、現在のクラスターの状態を反映します。詳細については、「[動的なトポロジの更新](#sagemaker-hyperpod-topology-dynamic-updates)」を参照してください。 ### ネットワークトポロジーをサポートするインスタンスタイプ HyperPod は、Amazon EC2 インスタンストポロジをサポートするインスタンスタイプのツリートポロジまたはブロックトポロジを設定します。サポートされているインスタンスタイプの信頼できるup-to-dateリストについては、[Amazon EC2 ユーザーガイド」の「Amazon EC2 トポロジの前提条件](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology-prerequisites.html#inst-net-topology-prereqs-instance-types)」を参照してください。 *Amazon EC2 * サポートされているインスタンスタイプには、G6e、G7e、P4d、P4de、P5、P5e、P5en、P6e-GB200 などの高速コンピューティングファミリーや、Trn1、Trn1n、Trn2 などの AWS Trainium ファミリーが含まれます。UltraServer インスタンスタイプ ( など`ml.p6e-gb200.36xlarge`) はブロックトポロジを使用し、他のトポロジ対応インスタンスタイプはツリートポロジを使用します。 ### トポロジ/ツリープラグインの使用 `topology/tree` プラグインは、複数の帯域幅階層を持つ階層通信構造をモデル化します。ツリートポロジを使用すると、Slurm はクロスティア通信を最小限に抑え、ローカリティを最大化する方法でジョブを配置できます。 ツリートポロジは、分散トレーニングワークロードがローカリティ対応配置の恩恵を受ける階層相互接続を持つインスタンスタイプに使用されます。これには、`ml.p5.48xlarge`、、 などのインスタンスタイプが含まれます`ml.p5e.48xlarge``ml.p5en.48xlarge`。 クラスターがこれらのインスタンスタイプを使用する場合、SageMaker HyperPod は自動的に`topology/tree`プラグインを設定します。生成されたトポロジ設定は、ノードをハードウェアの通信階層を反映するスイッチ階層にマッピングします。 `slurm.conf` に以下が含まれていることを確認します。 ``` TopologyPlugin=topology/tree ``` #### 設定 SageMaker HyperPod は、Amazon EC2 から提供された情報に基づいてツリートポロジを自動的に設定します。Amazon EC2 トポロジの詳細については、[Amazon EC2 インスタンストポロジ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html)」を参照してください。 Slurm 25.11 以降では、HyperPod は信頼できるソース`topology.yaml`である でトポロジを定義します。ツリートポロジエントリは、ノードをハードウェアの通信階層を反映するスイッチ階層にマッピングします。 ``` - topology: tree cluster_default: true tree: switches: - switch: root children: leaf-0,leaf-1 - switch: leaf-0 nodes: compute-1,compute-2 - switch: leaf-1 nodes: compute-3,compute-4 ``` Slurm 24.x では、`topology.conf`代わりにツリートポロジが で定義され、次の形式が使用されます。 ``` SwitchName=nn-6fe9d8a965d34d181 Switches=nn-0b53107754517bf0e SwitchName=nn-0b53107754517bf0e Switches=nn-424c855d4ad825aa4,nn-95acd7c656329fc30 SwitchName=nn-424c855d4ad825aa4 Nodes=ip-10-1-111-198 SwitchName=nn-95acd7c656329fc30 Nodes=ip-10-1-53-231 ``` #### 使用方法 `topology/tree` プラグインが設定されると、Slurm は互いに近いマシンの割り当てを試みます。`--switch` コマンドラインパラメータを `sbatch`または に渡すことで、Slurm が単一のスイッチにマシンを割り当てるように強制できます`srun`。 ``` sbatch --switch=1 .... ``` ### トポロジ/ブロックプラグインの使用 NVIDIA は、次の特性を持つノードのブロック間で階層スケジューリングを提供する`topology/block`プラグインを開発しました。 + ブロックとはノードの連続範囲です。 + ブロックは互いに重複することはありません。 + ブロック内のすべてのノードは、次のブロックを使用する前にジョブに割り当てられます。 + 計画ブロックサイズは、設定された最小ブロックサイズです + ブロックレベルサイズが増大すると、前のブロックレベルの累乗になります。 このプラグインは、定義されたネットワークトポロジーに基づいてノードを割り当てます。 ブロックトポロジは、すべての GPUsに参加する、均一で高帯域幅の通信ドメインをモデル化します。ブロックトポロジは、すべてのノードを単一の結合通信ユニットの一部として扱います。SageMaker HyperPod の UltraServer アーキテクチャは、ブロックプラグインをサポートしています。 ブロックトポロジは、 などの UltraServer インスタンスタイプに使用されます`ml.p6e-gb200.36xlarge`。 `slurm.conf` に以下が含まれていることを確認します。 ``` TopologyPlugin=topology/block ``` #### 設定 SageMaker HyperPod はブロックトポロジを自動的に設定します。Slurm 25.11 以降では、信頼できるソース`topology.yaml`である でブロックトポロジが定義されています。クラスターのブロックトポロジとツリートポロジは、同じファイルで一緒に定義されます。次の例は、P5 パーティション (ツリー) と UltraServer パーティション (ブロック) を持つクラスターを示しています。 ``` - topology: tree cluster_default: true tree: switches: - switch: root children: leaf-0,leaf-1 - switch: leaf-0 nodes: compute-p5-1,compute-p5-2 - switch: leaf-1 nodes: compute-p5-3,compute-p5-4 - topology: block cluster_default: false block: block_sizes: - 18 blocks: - block: cb-001 nodes: ultraserver-1-[1-18] ``` Slurm 24.x では、ブロックトポロジは`topology.conf`代わりに で定義され、次の形式を使用します。 ``` BlockName=us1 Nodes=ultraserver1-[0-17] BlockName=us2 Nodes=ultraserver2-[0-17] BlockSizes=18 ``` #### 使用方法 ジョブを送信する際は、`sbatch` コマンドと `srun` コマンドで次の追加の引数を使用できます。 + `--segment=N`: グループ化するノードの数を指定します。セグメントのサイズは、計画ブロックサイズ以下である必要があります。 + `--exclusive=topo`: 同じブロックに他のジョブを配置しないようにリクエストします。これは、ベンチマークやパフォーマンス重視のアプリケーションに役立ちます。 以下は、ブロックの割り当てを検討する際に考慮すべきシナリオの例です。 **空のシステムにノードのブロック全体を割り当てる** ``` sbatch -N18 ``` **空のシステムに 2 つのノードのブロックを割り当てる** ``` sbatch -N36 ``` **あるブロックに 18 ノードを割り当て、別のブロックに 6 ノードを割り当てる** ``` sbatch -N24 ``` **あるブロックに 12 ノードを割り当て、別のブロックに 12 ノードを割り当てる** ``` sbatch -N24 --segment=12 ``` **-- exclusive=topo の場合、ジョブは他のジョブなしでブロックに配置する必要があります** ``` sbatch -N12 --exclusive=topo ``` ### パーティションレベルのトポロジの選択 Slurm 25.11 以降、HyperPod はパーティションレベルでトポロジ設定をサポートしています。各パーティションにはコンピューティングインスタンスグループのインスタンスタイプに基づいてトポロジが割り当てられるため、1 つのクラスターは 1 つのパーティションでツリートポロジを実行し、別のパーティションでトポロジをブロックできます。ネットワークトポロジがサポートされていないインスタンスタイプを含むパーティションは、クラスター全体の`flat`デフォルトを継承し、ノードをスケジュール可能に保ちます。 HyperPod は、次のように各パーティションのトポロジを解決します。 + パーティション内のすべてのコンピューティングインスタンスグループが UltraServer インスタンスタイプである場合、パーティションは`block`トポロジを使用します。 + パーティション内のすべてのコンピューティングインスタンスグループがネットワークトポロジをサポートしている場合 (パーティションがすべての UltraServer ではない）、パーティションは`tree`トポロジを使用します。 + パーティションに UltraServer と他のトポロジ対応インスタンスタイプの両方が含まれている場合、パーティションは`tree`トポロジを使用します。 + パーティション内のコンピューティングインスタンスグループがネットワークトポロジをサポートしていないインスタンスタイプを使用している場合、パーティションにはトポロジの割り当てがなく、クラスター全体の`flat`デフォルトを継承します。 クラスター全体のデフォルトトポロジは、クラスター全体に存在するトポロジに基づいて選択されます。トポロジタイプが 1 つしかない場合、そのタイプがデフォルトです。ブロックとツリーの両方にトポロジ以外のグループが存在しない場合、ツリーがデフォルトです。トポロジ以外のコンピューティンググループが存在する場合、 `flat` がデフォルトであるため、それらのノードはスケジュール可能です。 次の表は、HyperPod が混合インスタンスタイプのクラスターのトポロジを解決する方法の例を示しています。 | インスタンスグループ | インスタンスタイプ | 適用トポロジ | | --- | --- | --- | | IG-1 | ml.p5.48xlarge | [ツリー] | | IG-2 | ml.p6e-gb200.36xlarge | ブロック | この例では、P5 パーティションはツリートポロジを使用し、UltraServer パーティションはブロックトポロジを使用します。パーティションレベルのトポロジでは、各パーティションが同じクラスター内で最適なトポロジを使用するため、各インスタンスタイプに理想的なトポロジモデルを提供するために個別のクラスターを作成する必要がなくなります。 **注記** Slurm 24.x を実行しているクラスターでは、クラスター全体のトポロジ設定は 1 つだけサポートされています。パーティションごとのトポロジには Slurm 25.11 以降が必要です。 ### フラットトポロジのデフォルト クラスターにトポロジ対応インスタンスタイプと非トポロジインスタンスタイプが混在している場合、HyperPod はクラスターのデフォルト`topology/flat`として適用されます。トポロジ対応パーティションは、 `slurm.conf` (Slurm 25.11 以降) のパーティションごとの`Topology=`ディレクティブを通じてツリーまたはブロックトポロジを指し、非トポロジノードを持つパーティションは`Topology=`ディレクティブを持たず、フラットデフォルトを継承します。これにより、すべてのノードがスケジュール可能になります。 ### トポロジプラグインを無効化または変更する Slurm クラスターが作成されると、HyperPod は最適なトポロジプラグインを自動的に選択します。トポロジプラグインを手動で変更するには、コントローラーノード`slurm.conf`の `TopologyPlugin`の値を更新します。 トポロジ対応配置を無効にするには、プラグインを `topology/flat` (または ) に設定します`topology/default`。 ``` # Set this value to disable topology-aware placement TopologyPlugin=topology/flat ``` ### 動的なトポロジの更新 トポロジ対応スケジューリングは、クラスターの変化に応じてトポロジの正確性を継続的に維持します。次のいずれかのイベントが発生すると、トポロジが自動的に再計算され、トポロジ設定ファイルが再生成されます。 + **スケールアップ**: 新しいノードがクラスターに追加されます。 + **スケールダウン**: ノードはクラスターから削除されます。 + **ノードの置き換え**: 失敗または異常なノードが置き換えられるか、[BatchReplaceClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchReplaceClusterNodes.html) API を使用して手動で置き換えられます。 トポロジが更新されると、新しいノードが正しいトポロジ構造に組み込まれ、削除されたノードがプルーニングされ、Slurm 設定が手動操作なしで更新されます。これにより、トポロジには常に実際のクラスターの状態が反映されます。 **注記** 上級ユーザーは、Slurm コントローラーノードにログインし、 `slurm.conf` と該当するトポロジファイル (`topology.yaml`Slurm 25.11 以降、または Slurm 24.x) を手動で変更することで、トポロジの動作`topology.conf`を上書きできます。ただし、スケーリングオペレーション、ノード交換、その他のクラスターライフサイクルイベントなど、以降のクラスター更新中に HyperPod によって手動の変更が上書きされる場合があります。これらのファイルを手動で変更する場合は、クラスターの更新後に変更を確認します。 ## UltraServer トポロジーのベストプラクティス SageMaker HyperPod の UltraServer アーキテクチャで最適なパフォーマンスを得るには: + **ブロックサイズを適切に設定する**: UltraServer アーキテクチャに合わせて `BlockSizes=18` (1 つのノードがスペアの場合は 17) と設定します。 + **可用性を高めるためにセグメントを使用する**: `--segment=16`、`--segment=8`、または `--segment=9` を `srun` コマンドと `sbatch` コマンドで使用して、ジョブのスケジュールの柔軟性を向上させます。 + **ジョブサイズとセグメントサイズを考慮する**: + `BlockSizes=18` の場合、最大 18 個のインスタンスを持つジョブは、常に単一の UltraServer で実行されます。 + `BlockSizes=16` の場合、16 インスタンス未満のジョブは常に 1 つの UltraServer で実行されますが、18 インスタンスのジョブは 1 つまたは 2 つの UltraServer で実行されます。 セグメント化について考えるときは、次の点を考慮してください。 + `--segment=1` の場合、各インスタンスを個別の UltraServer で実行できます。 + `-N 18 --segment 9` の場合、9 つのノードが 1 つの UltraServer に配置され、別の 9 つのノードが同じまたは別の UltraServer に配置されます。 + `-N 24 --segment 8` の場合、ジョブは 2 つまたは 3 つの UltraServerで実行でき、8 つのノードごとに同じサーバーに配置されます。 ## SageMaker HyperPod トポロジー認識スケジューリングの制限 Slurm 25.11 以降では、パーティションレベルのトポロジとクラスターのデフォルトにより、異種クラスター (異なるインスタンスタイプの`flat`クラスター) がサポートされています。各パーティションは、インスタンスタイプに最適なトポロジを受け取り、非トポロジノードと UltraServer ノードは同じクラスター内でスケジュール可能です。詳細については、「[パーティションレベルのトポロジの選択](#sagemaker-hyperpod-topology-partition-level)」を参照してください。 Slurm 24.x を実行しているクラスターでは、単一のクラスター全体のトポロジが適用され、`topology/block`プラグインには異種クラスターで以下の制限があります。 + ブロックにリストされているノードのみが Slurm によってスケジュール可能です。 + すべてのブロックには少なくとも `BlockSizes[0]` ノードが必要です。 Slurm 24.x の異種クラスターの場合は、次の代替方法を検討してください。 + 異種クラスターでは、ブロックプラグインを使用しないでください。代わりに、別のパーティションで UltraServer ノードを分離します。 + UltraServer を使用して、別のクラスターを同じ VPC 内にのみ作成し、Slurm のマルチクラスター設定を使用します。