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

# Amazon SageMaker HyperPod でのトポロジー認識スケジューリングの使用
<a name="sagemaker-hyperpod-topology"></a>

データ転送効率は、ハイパフォーマンスコンピューティング (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 アーキテクチャ
<a name="sagemaker-hyperpod-topology-ultraserver-architecture"></a>

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

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

## EKS トポロジーラベル
<a name="sagemaker-hyperpod-topology-eks-scheduling"></a>

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 ネットワークトポロジープラグイン
<a name="sagemaker-hyperpod-topology-slurm-plugins"></a>

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

### トポロジー/ブロックプラグインの使用
<a name="w2aac13c35c39c15b5"></a>

NVIDIA は、以下の特性を持つノードのブロック間で階層スケジューリングを提供するトポロジ/ブロックプラグインを開発しました。
+ ブロックとはノードの連続範囲です。
+ ブロックは互いに重複することはありません。
+ ブロック内のすべてのノードは、次のブロックを使用する前にジョブに割り当てられます。
+ 計画ブロックサイズは、設定された最小ブロックサイズです
+ ブロックレベルサイズが増大すると、前のブロックレベルの累乗になります。

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

#### 設定
<a name="w2aac13c35c39c15b5b9"></a>

トポロジー/ブロックプラグインを使用してトポロジー認識スケジューリングを設定するには
+ SageMaker HyperPod はトポロジー/ブロックプラグインを自動的に設定します。プラグインを設定する場合は、Slurm 設定ディレクトリの topology.conf ファイルで以下を指定します。

  ```
  BlockName=us1 Nodes=ultraserver1-[0-17]
    
  BlockName=us2 Nodes=ultraserver2-[0-17]
    
  BlockSizes=18
  ```
+ `slurm.conf` に以下が含まれていることを確認します。

  ```
  TopologyPlugin=topology/block
  ```

#### 使用方法
<a name="w2aac13c35c39c15b5c11"></a>

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

## UltraServer トポロジーのベストプラクティス
<a name="sagemaker-hyperpod-topology-best-practices"></a>

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 トポロジー認識スケジューリングの制限
<a name="sagemaker-hyperpod-topology-limitations"></a>

`topology/block` プラグインには、異種クラスター (異なるインスタンスタイプのクラスター) の制限があります。
+ Slurm がスケジュールできるのは、ブロックにリストされているノードのみです。
+ すべてのブロックには少なくとも `BlockSizes[0]` ノードが必要です。

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