UltraServer アーキテクチャトポロジーラベル Slurm トポロジープラグインベストプラクティス制限事項

Amazon SageMaker HyperPod でのトポロジー認識スケジューリングの使用

データ転送効率は、ハイパフォーマンスコンピューティング (HPC) と機械学習ワークロードの重要な要素です。Amazon SageMaker HyperPod で UltraServer を使用する場合、SageMaker HyperPod はトポロジーラベルをリソースに自動的に適用します。トポロジー認識スケジューリングは、インスタンストポロジー (インスタンス内でのリソースの接続方法) とネットワークトポロジー (インスタンス間の接続方法) の両方を考慮して、リソースを割り当てて、データ転送オーバーヘッドを最小限に抑えるのに役立ちます。インスタンスサイズの詳細については、「Amazon EC2 インスタンスタイプのトポロジー」を参照してください。

トポロジー認識スケジューリングは、Slurm と Amazon EKS の両方のクラスターで機能します。トポロジと Slurm の連携に関する一般的な情報については、「Slurm ドキュメントのトポロジガイド」を参照してください。

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 の使用」を参照してください。

これらのラベルを使用すると、HyperPod タスクガバナンスでトポロジー認識スケジューリングを使用してトポロジラベルと注釈を適用し、ワークロードのトレーニング効率を最適化できます。詳細については、「Amazon SageMaker HyperPod タスクガバナンスでのトポロジー認識スケジューリングの使用」を参照してください。

Slurm ネットワークトポロジープラグイン

Slurm は、ネットワークトポロジー認識のための組み込みプラグインを提供しています。SageMaker HyperPod は、クラスター内のインスタンスタイプに基づいて適切なトポロジプラグインを自動的に選択して設定します。

自動トポロジ選択

HyperPod Slurm クラスターを作成すると、システムはすべてのインスタンスグループと関連するインスタンスタイプを検査し、各インスタンスタイプの GPU 通信特性を識別し、適切なトポロジプラグインを使用して Slurm を設定します。このプロセスは自動的に実行され、設定は必要ありません。

HyperPod は、動的に生成されたtopology.confファイルを通じてトポロジを管理します。クラスターがスケーリングオペレーションまたはノード置換によって進化するにつれて、HyperPod はトポロジ設定を継続的に調整して、現在のクラスターの状態を反映します。詳細については、「動的トポロジの更新」を参照してください。

トポロジ/ツリープラグインの使用

topology/tree プラグインは、複数の帯域幅階層を持つ階層通信構造をモデル化します。ツリートポロジにより、Slurm はクロスティア通信を最小限に抑え、ローカリティを最大化する方法でジョブを配置できます。

ツリートポロジは、分散トレーニングワークロードがローカリティ対応配置の恩恵を受ける階層相互接続を持つインスタンスタイプに使用されます。これには、ml.p5.48xlarge、、などのインスタンスタイプが含まれますml.p5e.48xlargeml.p5en.48xlarge。

クラスターがこれらのインスタンスタイプを使用する場合、SageMaker HyperPod はtopology/treeプラグインを自動的に設定します。生成されたは、ハードウェアの通信階層を反映するスイッチ階層にノードをtopology.confマッピングします。

slurm.conf に以下が含まれていることを確認します。


TopologyPlugin=topology/tree

設定

SageMaker HyperPod は、Amazon EC2 から提供された情報に基づいてtopology/treeプラグインを自動的に設定します。Amazon EC2 トポロジの詳細については、Amazon EC2 インスタンストポロジ」を参照してください。

topology/tree プラグインを使用すると、Slurm は次の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 アーキテクチャは、ブロックプラグインをサポートしています。

ブロックトポロジは、 ml.p6e-gb200.NVL72やなどのインスタンスタイプに使用されますml.p6e-gb300.NVL72。

設定

SageMaker HyperPod はtopology/blockプラグインを自動的に設定します。プラグインを手動で設定する場合は、Slurm 設定ディレクトリの topology.conf ファイルで以下を指定します。


BlockName=us1 Nodes=ultraserver1-[0-17]
BlockName=us2 Nodes=ultraserver2-[0-17]
BlockSizes=18

slurm.conf に以下が含まれていることを確認します。


TopologyPlugin=topology/block

使用方法

ジョブを送信する際は、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

混合インスタンスタイプのクラスターのトポロジーの選択

HyperPod は現在、クラスターごとに 1 つのトポロジ設定のみをサポートする Slurm 24.11 を使用しています。つまり、パーティションごとのトポロジの選択はサポートされておらず、複数のトポロジモデルが 1 つのクラスター内で共存できず、すべてのノードが 1 つのトポロジ定義に準拠している必要があります。

クラスターに複数のインスタンスタイプが含まれている場合、HyperPod はすべてのインスタンスタイプで互換性のあるトポロジを選択します。次の表は、HyperPod が混合インスタンスタイプのクラスターのトポロジを解決する方法の例を示しています。

インスタンスグループ	インスタンスタイプ	優先トポロジ
IG-1	ml.p5.48xlarge	[ツリー]
IG-2	ml.p6e-gb300.NVL72	ブロック

この例では、ブロックトポロジは ml.p6e-gb300.NVL72 に最適ですが、ツリートポロジは ml.p5.48xlarge と ml.p6e-gb300.NVL72 の両方と互換性があります。HyperPod は、クラスター全体のトポロジとしてツリートポロジを選択し、すべてのノードが正しくスケジューリングに参加でき、インスタンスタイプが除外されたり、誤って表現されたりしないようにします。

重要

トポロジ対応スケジューリングがパフォーマンスにとって重要なワークロードでは、1 つのクラスターに異なるインスタンスタイプを組み合わせるのではなく、インスタンスタイプごとに個別のクラスターを作成することをお勧めします。これにより、各クラスターはハードウェアに最適なトポロジを使用し、可能な限り最高のワークロードパフォーマンスを提供します。たとえば、ツリートポロジが互換性のある侵害として選択されている単一のクラスターで ml.p5.48xlarge インスタンスと ml.p6e-gb300.NVL72 インスタンスを組み合わせる代わりに、それぞれが理想的なトポロジモデルを使用するように、インスタンスタイプごとに専用クラスターを作成します。

トポロジプラグインを無効化または変更する

Slurm クラスターが作成されると、HyperPod は最適なトポロジプラグインを自動的に選択します。トポロジプラグインを手動で変更するには、コントローラーノードの slurm.conf TopologyPluginの値を更新します。

例:


# Set this value to disable topology plugin
TopologyPlugin=topology/flat

動的トポロジの更新

トポロジ対応スケジューリングは、クラスターの変化に応じてトポロジの正確性を継続的に維持します。トポロジは自動的に再計算され、次のいずれかのイベントが発生するとtopology.confファイルが再生成されます。

スケールアップ: 新しいノードがクラスターに追加されます。
スケールダウン: ノードはクラスターから削除されます。
ノードの置き換え: 失敗または異常なノードが置き換えられるか、BatchReplaceClusterNodes API を使用して手動で置き換えられます。

トポロジが更新されると、新しいノードが正しいトポロジ構造に組み込まれ、削除されたノードがプルーニングされ、Slurm 設定が手動操作なしで更新されます。これにより、トポロジには常に実際のクラスターの状態が反映されます。

注記

上級ユーザーは、Slurm コントローラーノードにログインし、 slurm.conf とを手動で変更することで、トポロジの動作を上書きできます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 トポロジー認識スケジューリングの制限

topology/block プラグインには、異種クラスター (異なるインスタンスタイプのクラスター) の制限があります。

Slurm がスケジュールできるのは、ブロックにリストされているノードのみです。
すべてのブロックには少なくとも BlockSizes[0] ノードが必要です。

異種クラスターの場合は、次の代替方法を検討します。

異種クラスターでは、ブロックプラグインを使用しないでください。代わりに、別のパーティションで UltraServer ノードを分離します。
UltraServer を使用して、別のクラスターを同じ VPC 内にのみ作成し、Slurm のマルチクラスター設定を使用します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ワークロードをデプロイします。

HyperPod にモデルをデプロイする