AWS Parallel Computing Service が NVIDIA Blackwell 世代の P6e UltraServer をサポートしました

AWS Parallel Computing Service が NVIDIA Blackwell 世代の P6e UltraServer をサポートしました

AWS Parallel Computing Service(PCS)が P6e-GB200・P6e-GB300 UltraServer に対応しました。既存の HPC クラスターから大規模言語モデル学習環境を構築できるようになった一方で、SageMaker HyperPod との違いや利用上の制約も押さえておく必要があります。このアップデートの概要と、両サービスの選び分けについてまとめます。
2026.07.18

はじめに

AWS Parallel Computing Service(以下 PCS)は、HPC(High Performance Computing)クラスターのマネージドサービスです。Amazon EC2 UltraServer は、複数の EC2 インスタンスを高帯域幅のネットワークで相互接続する仕組みです。今回のアップデートで、P6e-GB200 と P6e-GB300 の UltraServer を PCS のコンピュートノードグループとして利用できるようになりました。個人的に押さえておきたい点として、大規模言語モデルの学習環境では比較対象になる SageMaker HyperPod との対応状況の違いを整理します。

pcs-p6e-ultraserver-support.png

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-parallel-computing-service/

確認結果

今回確認できた要点は次のとおりです。

  • PCS がコンピュートノードグループとして P6e-GB200 UltraServer と P6e-GB300 UltraServer に対応(2026 年 7 月時点)
  • Capacity Block の内容を PCS が自動検査し、Slurm の topology/block プラグインを自動設定(利用者側の設定は不要)
  • UltraServer 向け Capacity Blocks は、P6e-GB200 が US East (Dallas) ローカルゾーン(us-east-1-dfw-2a)の 1 か所のみ。P6e-GB300 は対応リージョンを一次情報で確認できず
  • UltraServer の予約は AWS 営業担当への問い合わせが必要
  • SageMaker HyperPod も P6e-GB200 には対応済みだが、P6e-GB300 のサポートはしていない

なにが嬉しいのか

既存の HPC クラスターの延長で LLM 学習環境を用意できる

AWS PCS の得意領域は、CFD(数値流体力学)、気象予測、有限要素解析(FEA)、半導体設計(EDA)といった伝統的な HPC ワークロードです。今回のアップデートで、既存の PCS クラスターに UltraServer のノードグループを追加し、大規模言語モデルの学習にも使いやすくなりました。ML 専用の基盤を新たに立てず、使い慣れたクラスターのまま NVIDIA Blackwell 世代を扱えることが PCS を選ぶ利点と言えます。

UltraServer は複数の EC2 インスタンスを低遅延、高帯域の GPU 間接続で束ねます。その性能を引き出すには、ジョブが NVLink 接続の範囲内に収まるようトポロジーを設計する必要がありました。今回のアップデートでは、PCS が Capacity Block から UltraServer の種類を自動判定します。そのうえで Slurm の topology/block プラグインを PCS が自動で設定するため、利用者側の設定作業は不要です。ジョブは同一 UltraServer 内に自動配置され、GPU 間通信は EFA(Elastic Fabric Adapter)でなく NVLink を使います。

複数の UltraServer にまたがるジョブでは、UltraServer 間に NVLink 接続がないため EFA にフォールバックします。この挙動については以下のドキュメントを参照してください。

https://docs.aws.amazon.com/pcs/latest/userguide/capacity-blocks-nvidia-imex.html

利用可能リージョンと予約方法

2026 年 7 月時点の情報です。UltraServer 向け Capacity Blocks の対応リージョンは、通常の Capacity Blocks とは別建てで管理されています。EC2 公式ドキュメントの対応表には UltraServer 向けの行として Trn2 と P6e-GB200 のみが掲載されており、P6e-GB300 の行は存在しませんでした。

インスタンス UltraServer Capacity Blocks の対応リージョン
P6e-GB200 US East (Dallas) ローカルゾーン(us-east-1-dfw-2a)の 1 か所のみ
P6e-GB300 一次情報で確認できませんでした
Trn2(参考) US East (Ohio) us-east-2

この状況は 2025 年 7 月の P6e-GB200 GA 時点から変わっていませんでした。ローカルゾーンで購入・利用するには、対象ゾーンへのオプトインが必要です。

PCS の What's New では、UltraServer の予約方法は AWS 営業担当への問い合わせとされています。

To reserve P6e UltraServers, contact your AWS sales representative.

出典: AWS Parallel Computing Service supports P6e-GB200 and P6e-GB300 UltraServers

P6e-GB300 は 2025 年 12 月の GA 発表時点から営業担当への問い合わせが必要とされており、この扱いは 2026 年 7 月時点でも変わっていないようです。

To initiate the use of P6e-GB300 UltraServers, contact an AWS sales representative.

出典: Amazon EC2 P6e-GB300 UltraServers accelerated by NVIDIA GB300 NVL72 are now generally available

インスタンス自体のスペックは、以下の記事を参照してください。

https://dev.classmethod.jp/articles/amazon-ec2-p6e-gb300-ultraservers-nvidia-gb300-nvl72-generally-available/

https://dev.classmethod.jp/articles/p6e-gb200-ultraservers-and-aws-technology/

PCS での利用方法の概要

予約からノードグループ作成までの流れ

UltraServer を PCS のコンピュートノードグループで使うには、次の順で設定します。

  1. Capacity Blocks for ML で UltraServer を予約する(AWS 営業担当への問い合わせが必要)
  2. EC2 起動テンプレートで InstanceMarketOptionsMarketTypecapacity-block に設定する。予約した CapacityReservationId を含む CapacityReservationSpecification も指定する
  3. この起動テンプレートを使うコンピュートノードグループを作成し、purchaseOptionCAPACITY_BLOCK に設定する

対象インスタンスタイプは p6e-gb200.36xlarge、p6e-gb200.72xlarge、p6e-gb300.36xlarge、p6e-gb300.72xlarge の 4 種類です。Slurm 25.05 以降が前提になります。

利用時の制約

--exclusive フラグのほかにも、PCS 公式ガイドでは以下の制約が挙げられています。

  • UltraServer 向けのコンピュートノードグループは、非 UltraServer のノードグループと別の専用キューに配置する必要がある
  • 1 つのコンピュートノードグループは、1 つの UltraServer Capacity Block にのみ関連付けられる。インスタンスタイプは後から変更できない
  • 同一キューに複数の UltraServer ノードグループを含める場合、インスタンス数は 2 のべき乗比率(例: 9 と 18、2 と 8)にする必要がある

Capacity Block 自体の制約として、EC2 の Capacity Blocks ドキュメントには以下が記載されています。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html

  • P6e-GB200 の Capacity Block は、終了時刻の 60 分前までにインスタンスを終了させる必要がある
  • UltraServer Capacity Block は、アカウント間や AWS Organizations 内でも共有できない

SageMaker HyperPod との比較

同じ Blackwell 世代 UltraServer を扱えるサービスとして、大規模モデルの学習と推論の基盤である SageMaker HyperPod もあります。HyperPod は 2025 年 8 月に P6e-GB200 UltraServer(ml.u-p6e-gb200x72、ml.u-p6e-gb200x36)に対応しました。

予約は SageMaker HyperPod の flexible training plans 経由で、こちらもダラスのローカルゾーン(us-east-1-dfw-2a)が対象です。オンデマンド予約もアカウントマネージャーへの連絡が前提です。P6e-GB300 は、HyperPod の What's New と API リファレンスのいずれにも記載を確認できませんでした。

観点 SageMaker HyperPod AWS PCS
主なターゲット 大規模基盤モデルの学習と推論 CFD、気象予測、FEA、EDA などのいわゆる HPC ワークロード
P6e-GB200 サポートあり(2025 年 8 月〜、flexible training plans 経由、ダラス ローカルゾーン限定) サポートあり(2026 年 6 月〜、Capacity Blocks for ML 経由、同じくダラス ローカルゾーン限定)
P6e-GB300 公式ドキュメントで記載を確認できず サポートあり(2026 年 6 月〜、対応リージョンは一次情報で確認できませんでした)
オーケストレーター Slurm、Amazon EKS Slurm のみ
追加の管理料金 キャパシティ割り当て期間のインスタンス課金のみ コントローラー料金とノード管理料金が別途かかります(P/TRN インスタンス向けの advanced tier は US East (N. Virginia) の例で $0.64/インスタンス/時)
キャパシティの調達単価 flexible training plans の料金(同一インスタンスの価格は Capacity Blocks より割高) Capacity Blocks の料金(需給に基づき定期見直し)
GPU ノード障害時の自動復旧 自動ノード復旧とチェックポイントからの auto-resume に対応 公式ドキュメントに記載なし

PCS のノード管理料金にはティア区分があり、P 系や TRN 系インスタンス向けの区分が advanced tier です。UltraServer のような大規模構成では、インスタンス数に比例するこの管理料金も無視できないコスト要素になります。

一方で、キャパシティの調達単価は逆の関係にあります。HyperPod の flexible training plans の時間単価は、同一インスタンスの公表価格では Capacity Blocks より割高です。たとえば米国東部(オハイオ)の p5.48xlarge の場合、Capacity Blocks は $41.528/時でした。対する flexible training plans(ml.p5.48xlarge)は $47.7572/時で、約 15% 割高でした(2026 年 7 月時点)。Capacity Blocks の価格は需給に基づいて定期的に見直されるため変動します。なお P6e UltraServer 自体の時間単価は、両者とも料金ページに掲載がありませんでした。管理料金の有無だけでなく、調達単価の差も含めた総額で比較する必要があります。

https://aws.amazon.com/sagemaker/ai/pricing/

https://aws.amazon.com/ec2/capacityblocks/pricing/

まとめ

AWS PCS が P6e-GB200 UltraServer と P6e-GB300 UltraServer をコンピュートノードグループとして利用できるようになりました。Capacity Block の内容から UltraServer の種類を自動判定し、Slurm の topology/block プラグインを自動設定する仕組みが追加されています。利用可能リージョンは現状ダラスのローカルゾーンに限られ、予約も AWS 営業担当への問い合わせが前提です。P6e-GB300 のサポートは、PCS が SageMaker HyperPod より先行している状況でした。

おわりに

すでに Slurm ベースの HPC 運用資産を持ち、GPU/Trainium と Capacity Blocks for ML の連携だけを使いたいチームには、PCS が扱いやすい選択肢になります。一方、長期間の大規模学習でノード障害からの自動復旧やジョブの自動再開を必要とする場合は、HyperPod のほうが機能面で充実しています。

https://dev.classmethod.jp/articles/aws-pcs-capacity-blocks-for-ml-support/

参考

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事