# SageMaker HyperPod、パーティションごとに最適なネットワークトポロジーを選べるようになったよ！

やっほー、しぃちゃんだよ！今日は Amazon SageMaker HyperPod の新機能について紹介するよ！大規模な GPU クラスターを使う人にとってはうれしいアップデートなの！

## なにが発表されたの？

AWS の What's New で、Amazon SageMaker HyperPod が Slurm で管理するクラスターにおいて、パーティション単位でネットワークトポロジーを設定できるようになったと発表されたよ！

1 つのクラスターの中でも、あるパーティションは tree トポロジー、別のパーティションは block トポロジーというふうに、パーティションごとに異なるトポロジーを混在させられるようになったんだって。それぞれのパーティションが使っているインスタンスタイプに最も合ったトポロジーを選べるから、分散トレーニングの性能を底上げできるの。

## 今までどうだったの？

これまでは、クラスター全体で 1 つのトポロジーしか使えなかったみたい。でも実際のクラスターにはいろんなインスタンスタイプが混在していることが多くて、インスタンスタイプごとの相互接続の特性に合わないトポロジーで動かすと、GPU 間の通信効率が落ちてしまう問題があったんだよ。

## これで何が変わるの？

HyperPod が各パーティションのインスタンスタイプを見て、自動でトポロジーを判定・維持してくれるようになったよ。ジョブの配置がインターコネクトの特性に沿うようになるから、GPU 同士の通信が速くなって、NCCL の集合通信もより効率的になり、トレーニングのスループットが向上するの。

しかも設定はいらなくて、トポロジー対応スケジューリングはデフォルトで有効になっているよ！大規模な GPU クラスターを運用しているチームなら、何もしなくても恩恵を受けられるのがうれしいポイントだね。

## 深く潜ってみよう

トポロジーの割り当てルールはこんな感じだよ！

- **block トポロジー**: Amazon EC2 UltraServer のインスタンスタイプ(例: ml.p6e-gb200.36xlarge)を使うパーティション
- **tree トポロジー**: 階層型インターコネクトのインスタンスタイプ(例: ml.p5.48xlarge、ml.p5e.48xlarge、ml.p5en.48xlarge)を使うパーティション
- ネットワークトポロジー情報を提供しないインスタンスタイプのパーティションは、そのままスケジュール可能な状態を維持

クラスターがスケールアップ・スケールダウンしたり、ノードが入れ替わったりしても、HyperPod がこの設定を自動で維持してくれるから、パーティションのトポロジーは常にクラスターの最新状態を反映するよ。

利用するには、Slurm 25.11 以降を実行している SageMaker HyperPod Slurm クラスターを新規作成するか、既存クラスターをアップデートして、対応 GPU インスタンスタイプを使うだけで OK。この機能は、Amazon SageMaker HyperPod が利用できるすべての AWS リージョンで使えるよ。

## まとめ

- SageMaker HyperPod の Slurm クラスターで、パーティションごとに異なるネットワークトポロジー(tree / block)を設定できるようになった
- インスタンスタイプに応じて HyperPod が自動でトポロジーを判定・維持し、スケーリングやノード入れ替え時も追従する
- 設定不要でデフォルト有効。必要なのは Slurm 25.11 以降と対応 GPU インスタンスタイプだけ
- 大規模な分散トレーニングを HyperPod で運用しているエンジニアにとって、通信効率とスループットの底上げにつながるアップデートだよ