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

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

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

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

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

UltraServer アーキテクチャ

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

このアーキテクチャは、個々のインスタンスと比較してパフォーマンスが大幅に向上します。このアーキテクチャを効果的に活用するには、単一の UltraServer からコンピューティングノードにジョブを送信する必要があります。

EKS トポロジーラベル

EC2 インスタンストポロジーに従って、HyperPod はノードに自動的に次のラベルを付けます。

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

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

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

自動トポロジ選択

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

HyperPod は、動的に生成された設定ファイルを通じてトポロジを管理します。Slurm 25.11 以降では、トポロジは信頼できるソースであり、複数のトポロジ定義とパーティションごとの割り当てをサポートする topology.yaml ファイルで定義されます。Slurm 24.x では、トポロジは単一のクラスター全体のトポロジを持つtopology.confファイルで定義されます。クラスターがスケーリングオペレーションまたはノード置換によって進化するにつれて、HyperPod はトポロジ設定を継続的に調整して、現在のクラスターの状態を反映します。詳細については、「動的なトポロジの更新」を参照してください。

ネットワークトポロジーをサポートするインスタンスタイプ

HyperPod は、Amazon EC2 インスタンストポロジをサポートするインスタンスタイプのツリートポロジまたはブロックトポロジを設定します。サポートされているインスタンスタイプの信頼できるup-to-dateリストについては、Amazon EC2 ユーザーガイド」の「Amazon EC2 トポロジの前提条件」を参照してください。 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.48xlargeml.p5en.48xlarge。

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

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

TopologyPlugin=topology/tree

設定

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

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 コマンドで次の追加の引数を使用できます。

以下は、ブロックの割り当てを検討する際に考慮すべきシナリオの例です。

空のシステムにノードのブロック全体を割り当てる

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 は、次のように各パーティションのトポロジを解決します。

クラスター全体のデフォルトトポロジは、クラスター全体に存在するトポロジに基づいて選択されます。トポロジタイプが 1 つしかない場合、そのタイプがデフォルトです。ブロックとツリーの両方にトポロジ以外のグループが存在しない場合、ツリーがデフォルトです。トポロジ以外のコンピューティンググループが存在する場合、 flat がデフォルトであるため、それらのノードはスケジュール可能です。

次の表は、HyperPod が混合インスタンスタイプのクラスターのトポロジを解決する方法の例を示しています。

この例では、P5 パーティションはツリートポロジを使用し、UltraServer パーティションはブロックトポロジを使用します。パーティションレベルのトポロジでは、各パーティションが同じクラスター内で最適なトポロジを使用するため、各インスタンスタイプに理想的なトポロジモデルを提供するために個別のクラスターを作成する必要がなくなります。

フラットトポロジのデフォルト

クラスターにトポロジ対応インスタンスタイプと非トポロジインスタンスタイプが混在している場合、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

動的なトポロジの更新

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

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

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

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

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

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

Slurm 25.11 以降では、パーティションレベルのトポロジとクラスターのデフォルトにより、異種クラスター (異なるインスタンスタイプのflatクラスター) がサポートされています。各パーティションは、インスタンスタイプに最適なトポロジを受け取り、非トポロジノードと UltraServer ノードは同じクラスター内でスケジュール可能です。詳細については、「パーティションレベルのトポロジの選択」を参照してください。

Slurm 24.x を実行しているクラスターでは、単一のクラスター全体のトポロジが適用され、topology/blockプラグインには異種クラスターで以下の制限があります。

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