Amazon SageMaker HyperPod でのトポロジ対応スケジューリングの使用 - Amazon SageMaker AI
UltraServer アーキテクチャトポロジラベルSlurm トポロジプラグインベストプラクティス制限

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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

Amazon SageMaker HyperPod では、データ転送オーバーヘッドは通常 3 つの主要なソースから発生します。

  • GPU-to-GPUデータ転送: NVLink や NVLink スイッチなどの最新のテクノロジーにより、他のコンピューティングリソースを介さずGPUs 間で高スループットのデータ転送が可能になります。これは非常に効率的ですが、通常は 1 つのインスタンスに限定されます。

  • GPU-to-CPUデータ転送: 不均一なメモリアクセス (NUMA) システムには、1 つのクリップボードに複数のシステムバスがあります。p5.48xlarge などの一般的な EC2 インスタンスアーキテクチャでは、それぞれ CPU と 4 GPUs。最適なパフォーマンスを得るには、GPUs との間でデータをロードまたは読み取るプロセスが、GPU と同じシステムバスに接続された CPU で実行する必要があります。

  • インスタンス間のネットワーク通信: インスタンスはネットワークスイッチのチェーンを介してデータを転送します。最短パスは通常、最小のレイテンシーに対応します。

UltraServer アーキテクチャ

SageMaker HyperPod は、p6e-gb200.36xlarge インスタンスを使用した UltraServer アーキテクチャをサポートしています。UltraServer には最大 18 個の p6e-gb200.36xlarge インスタンスが含まれ、各インスタンスに 4 個の GPUs。すべてのノードのすべての GPUs は NVLink スイッチを介して相互接続されるため、ネットワークインターフェイスを使用せずに 2 つの GPUs 間でデータ転送を行うことができます。

このアーキテクチャは、個々のインスタンスと比較してパフォーマンスが大幅に向上します。このアーキテクチャを効果的に活用するには、単一の 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 での UltraServers の使用の詳細については、「」を参照してくださいAmazon SageMaker HyperPod での UltraServers の使用 HyperPod。

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

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

Slurm は、ネットワークトポロジを認識するための組み込みプラグインを提供します。SageMaker HyperPod の UltraServer アーキテクチャは、 ブロックプラグインをサポートしています。

トポロジ/ブロックプラグインの使用

NVIDIA は、以下の特性を持つノードのブロック間で階層スケジューリングを提供するトポロジ/ブロックプラグインを開発しました。

  • ブロックはノードの連続した範囲です

  • ブロックは互いに重複できません

  • ブロック内のすべてのノードは、次のブロックを使用する前にジョブに割り当てられます。

  • 計画ブロックサイズは、設定された最小ブロックサイズです

  • ブロックレベルサイズが大きいほど、前のブロックレベルよりも 2 の累乗になります。

このプラグインは、定義されたネットワークトポロジに基づいてノードを割り当てます。

設定

トポロジ/ブロックプラグインを使用してトポロジ対応スケジューリングを設定するには、

  • SageMaker HyperPod はトポロジ/ブロックプラグインを自動的に設定します。プラグインを設定する場合は、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

1 つのブロックに 18 個のノードを割り当て、別のブロックに 6 個のノードを割り当てる

sbatch -N24

1 つのブロックに 12 個のノードを割り当て、別のブロックに 12 個のノードを割り当てる

sbatch -N24 —segment=12

— exclusive=topo の場合、ジョブは他のジョブなしでブロックに配置する必要があります

sbatch -N12 —exclusive=topo

UltraServer トポロジのベストプラクティス

SageMaker HyperPod の UltraServer アーキテクチャで最適なパフォーマンスを得るには：

  • 適切なブロックサイズを設定する: UltraServer アーキテクチャに合わせて を設定します BlockSizes=18 (1 つのノードがスペアの場合は 17)。

  • 可用性を高めるためにセグメントを使用する: --segment=16、--segment=8、または --segment=9srunと sbatch コマンドを使用して、ジョブのスケジュールの柔軟性を向上させます。

  • ジョブサイズとセグメントサイズを考慮します。

    • の場合BlockSizes=18、最大 18 個のインスタンスを持つジョブは、常に単一の UltraServer で実行されます。

    • の場合BlockSizes=16、16 インスタンス未満のジョブは常に 1 つの UltraServer で実行されますが、18 インスタンスのジョブは 1 つまたは 2 つの UltraServers。

セグメント化について考えるときは、次の点を考慮してください。

  • では--segment=1、各インスタンスを個別の UltraServer で実行できます。

  • では-N 18 --segment 9、9 つのノードを 1 つの UltraServer に配置し、別の 9 つのノードを同じ UltraServer または別の UltraServer に配置することができます。

  • では-N 24 --segment 8、ジョブは 2 つまたは 3 つの UltraServers で実行でき、8 つのノードごとに同じサーバーに配置されます。

SageMaker HyperPod トポロジ対応スケジューリングの制限

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

  • ブロックにリストされているノードのみが Slurm によってスケジュール可能

  • すべてのブロックには少なくとも BlockSizes[0]ノードが必要です

異種クラスターの場合は、次の代替方法を検討してください。

  • ブロックプラグインを異種クラスターで使用しないでください。代わりに、別のパーティションで UltraServer ノードを分離します。

  • UltraServers を使用して別のクラスターを同じ VPC 内にのみ作成し、Slurm のマルチクラスター設定を使用します。