AWS上でのファンデーションモデル訓練・推論を支える4層アーキテクチャ解説（EC2 P6・EFA・Slurm・PyTorch）

記事のサマリー（TL;DR）

• スケーリング則が「事前学習・事後学習・テスト時計算」の3軸に分化し、インフラ要件は収束している
• AWS EC2 P6世代（B200/B300）はNVLink BW 14.4 TB/s・EFA v4を搭載し、P5比で集合通信性能を大幅向上
• OSS観測基盤（Prometheus + Grafana）とDCGM-Exporterによるクラスタ健全性監視が大規模訓練の前提条件

大規模GPU訓練・推論基盤を構築する日本企業が押さえるべき設計指針

スケーリング則の3軸化（事前学習・SFT/RLHF・テスト時計算）に伴い、いずれのフェーズもタイトに結合したGPUコンピュート・高帯域ネットワーク・分散ストレージを必要とする点は共通です。日本国内でもLLM開発・ファインチューニング基盤をAWS上に構築する動きが増えており、EC2 P5/P6インスタンスとAmazon FSx for Lustre、SageMaker HyperPodの組み合わせは現実的な選択肢として定着しています。SageMaker HyperPodが提供する「チェックポイントレス訓練（checkpointless training）」はピアツーピアでのGPU間状態レプリケーションにより復旧レイテンシを削減するもので、マルチテラバイト規模のチェックポイントを毎回FSx/S3から読み直す従来手法に比べてダウンタイムを大幅に短縮できます。kintone・Salesforceなどの業務SaaS基盤とは直接交差しませんが、BigQueryによるデータ統合基盤を持つ組織がGPUクラスタ上でのモデル訓練ループを設計する際、ストレージ階層（NVMe→Lustre→S3）の理解は設計品質に直結します。

詳細

スケーリング則の多様化とインフラへの影響

Kaplan et al.（2020）が示したパワーロー則—モデルパラメータ数・データセットサイズ・訓練計算量を増やすと損失が予測可能に低下する—は長年にわたり大規模アクセラレータ投資を正当化してきました。しかし現在のフロンティアは変化しており、NVIDIAが提唱する「3つのスケーリング則」の枠組みに示されるように、パフォーマンスは次の3軸で向上します。

1. 事前学習スケーリング（Pre-training scaling）
2. 事後学習スケーリング（Post-training scaling）：SFT・RL系手法（RLHF、GRPOなど）
3. テスト時計算スケーリング（Test-time compute scaling）：「long thinking」、サーチ/検証、マルチサンプル戦略

この3軸すべてが、タイトに結合したアクセラレータコンピュート・高帯域低遅延ネットワーク・分散ストレージを必要とし、リソース管理のオーケストレーションとハードウェア・アプリケーション両面の可観測性の重要性を高めています。

OSSエコシステムも不可欠な要素です。クラスタ層ではSlurmとKubernetesがリソース管理を担い、PyTorchとJAXがモデル開発・分散訓練を支え、PrometheusとGrafanaが可観測性を提供します（図1参照）。

インフラ層：コンピュート・ネットワーク・ストレージ

アクセラレータコンピュート

AWSはAmazon EC2アクセラレーテッドコンピューティングインスタンスとして複数世代のNVIDIA GPUを提供しています。

P5インスタンスファミリー

• p5.48xlarge：NVIDIA H100 × 8基
• p5.4xlarge：H100 × 1基（小規模ワークロード向け）
• p5e.48xlarge / p5en.48xlarge：NVIDIA H200 × 8基

P6インスタンスファミリー

• p6-b200.48xlarge：NVIDIA Blackwell B200 × 8基
• p6-b300.48xlarge：Blackwell Ultra B300 × 8基

各世代の主要スペック比較（dense、SXM/HGX仕様）：

注：NVIDIAは通常「with sparsity」値を公表。本表はdenseスループット（sparse値の半分）を記載。

モデルのスケールアップに伴い、ステップ時間は生の計算スループットより集合通信・メモリ移動がボトルネックになるケースが多く、スケールアップ（ノード内）とスケールアウト（ノード間）の帯域を別々に評価する必要があります。

各インスタンスの通信仕様：

Elastic Fabric Adapter（EFA）

EFAはAmazon EC2向けのネットワークインターフェースで、Scalable Reliable Datagram（SRD）プロトコルを用いたOSバイパスRDMA機能を提供します。Libfabric APIを通じてアプリケーションがOSカーネルを迂回してネットワークデバイスと直接通信することで、集合通信のレイテンシを削減しスループットを向上させます。

• EFAv2：P5・P5e搭載
• EFAv3（P5en搭載）：EFAv2比でパケットレイテンシ約35%削減
• EFAv4（P6搭載）：EFAv3比で集合通信性能をさらに18%改善

ストレージ階層

大規模訓練（ストリーミングコーパス・マルチテラバイトチェックポイント書き込み）と大規模推論（重みのステージングとKVキャッシュ管理）の両方が、3層ストレージ階層を必要とします。

1. ローカルNVMe SSD（ホットデータ）：インスタンスストア（エフェメラル）として30.72 TB（8 × 3.84 TB NVMe SSD）
2. Amazon FSx for Lustre（高スループット共有アクセス）：TBレベルのスループット、数百万IOPS、サブミリ秒レイテンシ。Data Repository AssociationsによるS3連携も可能
3. Amazon S3（永続ストレージ）：耐久性の高いチェックポイント保存

Amazon EC2 UltraClusterとUltraServer

クラスタスケールでは、Amazon EC2 UltraClustersが数千台のアクセラレーテッドインスタンスをひとつの密置クラスタとして単一AZ内に展開し、ペタビットスケールのノンブロッキングネットワークで相互接続します。

MoEモデルのエキスパート並列処理のようにall-to-all通信が多いワークロードでは、NVLinkドメインのサイズが重要な制約になります。Amazon EC2 UltraServersは複数のコンポーネントインスタンスを専用アクセラレータ相互接続でつなぎ、NVLinkドメインを1インスタンスを超えて拡張します。

• p6e-gb200.36xlarge（コンポーネントインスタンス）：GB200 NVL72 GPU × 4基、EFA v4
• u-p6e-gb200x36（UltraServer）：36 GPU、6.7 TB HBM3e、EFA BW 1,800 GB/s
• u-p6e-gb200x72（UltraServer）：72 GPU、13.4 TB HBM3e、EFA BW 3,600 GB/s

P6e-GB200 UltraServerはNVIDIA GB200 NVL72プラットフォームをベースに構築されており、1つのNVLinkドメイン内に最大72基のBlackwell GPUと13.4 TBのHBM3eを備えます。Grace CPUメモリとBlackwell GPU HBMをキャッシュコヒーレントNVLink-C2C（NVLink Chip-to-Chip）で接続することで、CPU/GPUアタッチメモリ間の明示的なホストデバイスコピーが不要になります。冷たいモデル状態やKVキャッシュをCPUアタッチメモリに配置することでGPUワークロードの実効メモリを拡張できますが、ローカルHBMと比較してレイテンシが高く帯域が低い点は考慮が必要です。

リソースオーケストレーション：SlurmとKubernetes

512 GPUを要する訓練ジョブは64台の8-GPUノード（Pインスタンス）を同時にco-scheduleし、完了または失敗時にアトミックにリリースする必要があります。SlurmとKubernetesはいずれも制御プレーンアーキテクチャでこの課題に対応します。

Slurm（Simple Linux Utility for Resource Management）

SlurmはHPCの主力ワークロードマネージャです。

• ジョブレベルスケジューリング：マルチノードジョブ全体をアトミックに割り当てる
• バックフィルスケジューラ：高優先ジョブを遅らせずに低優先ジョブをアイドルスロットで実行
• マルチファクタ優先システム：フェアシェア使用率・ジョブ待機時間・QOSティアを組み合わせてキューを制御
• トポロジ認識配置：EFAファブリックトポロジをエンコードしてスイッチホップ数を最小化
• Generic Resource（GRES）インターフェース：GPUタイプを追跡しデバイスアフィニティを管理

AWSのSlurm展開オプション：

• AWS ParallelCluster：オープンソースのクラスタ管理ツール
• AWS Parallel Computing Service（PCS）：マネージドコントロールプレーンを提供
• Amazon SageMaker HyperPod（Slurmモード）：継続的なノード健全性監視とジョブ自動再開機能を追加

Kubernetes

Kubernetesは宣言的・APIドリブンなアプローチを取ります。ただし、タイトに結合した分散訓練に対してネイティブスケジューリングモデルにはいくつかのギャップがあります。

• ポッドレベルスケジューリングのため、マルチノード訓練ジョブが部分的に起動してGPUを無駄にする可能性
• バッチキューのセマンティクス（優先度付きバックフィル）の欠如
• NVLinkドメイン・EFA相互接続のトポロジ認識の欠如

これらのギャップを補う主要プロジェクト：

• Kueue：アドミッションコントローラとして動作し、ジョブレベルのギャングアドミッション・マルチテナントクォータ・優先度プリエンプションを管理
• Volcano：汎用バッチスケジューラとして機能し、ギャングスケジューリングとトポロジ認識配置を統合
• NVIDIA KAI Scheduler：NVLink/NVSwitchの深い認識を持つGPU最適化配置スケジューラ

KueueはアドミッションとクォータポリシーをVolcanoやKAI Schedulerに委ねる形で補完的に機能します。

AWSのKubernetes展開オプション：

• Amazon EKS：NVIDIA device pluginによるGPUスケジューリングをサポート
• Amazon SageMaker HyperPod（EKSモード）：HyperPodの訓練特化機能とKubernetes管理を組み合わせ

HyperPod EKSの主要機能：

• Task governance：マネージドKueueとKarpenterを統合したコンピュート割り当て・ポリシー管理
• チェックポイントレス訓練：GPUをまたいだ継続的なピアツーピア状態レプリケーションにより、障害発生時にEFAベース通信で失われた状態を再構築（FSx/S3からのチェックポイント読み込み不要）
• エラスティック訓練：リソース可用性に基づいてジョブを自動スケールイン/スケールアウト

MLソフトウェアスタック

分散訓練と推論は5層のランタイムスタックとして整理できます。

層1：ハードウェアイネーブルメント（カーネルドライバ）

• NVIDIA GPUドライバ：コンピュート機能を公開し、GPUDirect RDMAによるGPU-ネットワークアダプタ間の直接データ転送をサポート
• GDRCopyドライバ（gdrdrv）：NCCLが小メッセージ転送に使用する低レイテンシCPU起点コピーを実現
• EFAドライバ：libfabric API経由のOSバイパスネットワーキングを提供
• Lustreクライアントドライバ：FSx for LustreへのPOSIXアクセスを実現

層2：アクセラレータランタイム・コンパイラ・カーネルライブラリ

• CUDAプラットフォーム（最新版：CUDA Toolkit 13.x）：Blackwellアーキテクチャ（compute capability 10.x）をサポート
• FlashAttention：アテンション計算を1パスに融合しHBMトラフィックを削減
• Triton（PythonベースGPUカーネルコンパイラ）・NVIDIA CuTe（テンソルレイアウト/ワープレベルDSL）：カスタムカーネル記述を可能に
• CUTLASS：高度に最適化されたGEMMとfusionのビルディングブロック

層3：通信サブストレート（NCCLとトランスポートプラグイン）

**NVIDIA Collective Communications Library（NCCL）**はall-reduce、all-gather、reduce-scatter、all-to-all、broadcast、point-to-pointをトポロジ認識アルゴリズムで実装します。

MoE（Mixture-of-Experts）モデルはエキスパート並列処理でall-to-all集合通信を多用します。dispatch all-to-allが各トークンを担当エキスパートのGPUに送り、combine all-to-allがエキスパート出力を元のGPUに返します。GPU間でデータを全員と交換するため、エキスパート並列度が高くなるとall-to-all通信ボリュームが支配的なボトルネックになります。

AWSではaws-ofi-ncclプラグインがNCCLのトランスポートAPIをlibfabricインターフェースにマッピングし、アプリケーション変更なしにEFAのSRDプロトコルを活用できます。

推論向けには、prefillとdecodeフェーズを別々のGPUプールに分離したdisaggregated inference（分離型推論）アーキテクチャが効率的なpoint-to-pointデータ移動を必要とします。**NVIDIA Inference Xfer Library（NIXL）**がHBM・DRAM・NVMe・分散ストレージにまたがる統一APIでこの要件に対応し、NVIDIA DynamoやUCX・GPUDirect Storageとも統合されます。

層4：MLフレームワーク（PyTorch）

PyTorchはtorch.distributedモジュールを中心に分散ワークロードの基盤を提供します。

• DDP（Distributed Data Parallel）：GPUをまたいでモデルを複製しall-reduceで勾配を同期
• FSDP2（Fully Sharded Data Parallel 2）：ZeROアルゴリズムをベースにパラメータ・勾配・オプティマイザ状態をシャーディングし、単一GPU容量を超えるモデルの訓練を実現

層5：分散訓練・推論フレームワーク

訓練フレームワーク（例）：

推論サービングフレームワーク：

両フレームワークともテンソル並列処理をサポートし、NVIDIA Dynamoとの統合によりprefill/decode分離のdisaggregated servingアーキテクチャに対応します。

可観測性（Observability）

分散訓練システムのデバッグと運用には、ハードウェア障害・ネットワーク輻輳・ストレージボトルネック・アプリケーション非効率のいずれが原因かを切り分けるための可視性が不可欠です。

可観測性は3つのテレメトリカテゴリにまたがります：

1. インフラメトリクス（GPU・ネットワーク・ストレージ）
2. ワークロードメトリクス（訓練スループット・キューレイテンシ）
3. プロアクティブ障害検知のためのアラート

コアスタック：PrometheusとGrafana

• Prometheus：プルベースモデルでメトリクスエクスポーターのHTTPエンドポイントを定期的にスクレイプし、時系列データベース（TSDB）に保存。PromQLで柔軟なクエリ・集約・アラートルール評価
• Grafana：Prometheusをデータソースとしてダッシュボードを描画しアラートをトリガー

マネージドサービスとして：

• Amazon Managed Service for Prometheus（AMP）：1秒あたり数百万サンプルのインジェストにスケールするフルマネージドPrometheus互換時系列DB
• Amazon Managed Grafana（AMG）：AMPとIAM Identity Center経由のAWS認証をネイティブ統合したマネージドGrafanaワークスペース

GPU・ネットワーク・アプリケーションテレメトリ

• DCGM-Exporter：NVIDIA GPUメトリクス（使用率・メモリ使用量・電力・温度・ECCエラー・XIDイベント）をPrometheus形式で公開。SM活性度（DCGM_FI_PROF_SM_ACTIVE）は基本的な使用率指標より正確なコンピュート効率の計測値
• EFAドライバ統計：バイト数・パケット数・再送信・タイムアウトを公開し、集合通信ボトルネックの診断に活用
• FSx for Lustreクライアントサイドメトリクス：スループット・メタデータレイテンシを公開
• アプリケーションレベルメトリクス：ステップ時間・トークン/秒・損失値（訓練）、TTFT・トークン間レイテンシ（推論）をPrometheusクライアントライブラリ経由で公開

GPUヘルス監視とアラート

DCGMヘルスメトリクスを監視し、エラーカウントが閾値を超えたらアラートを発火させる典型的なワークフロー：

• ECCシングルビットエラー（SBE）：少数であれば許容範囲内だが、増加率がダブルビットエラー（DBE）の前兆になることが多い
• XID 63（行リマップ失敗）、XID 64（GPUがバスから脱落）、XID 94/95（封じ込め済み/未封じ込めエラー）：即時ノード交換を推奨

GPU Health – Clusterダッシュボード（Grafana dashboard ID: 21645）が、全クラスタノードのECCエラー・XIDイベント・熱違反・行リマッピングステータスを集約し、訓練ジョブへの影響前に障害ハードウェアを特定するリファレンス可視化として提供されています。

まとめ

事前学習・事後学習・テスト時計算という3つの相補的なスケーリング領域への移行は、インフラ要件を分散させることなく、むしろ収束させました。3つの領域すべてが、タイトに結合したアクセラレータコンピュート・高帯域低遅延ネットワーキング・スケーラブルな分散ストレージを必要とし、主にワークロードプロファイルとリソーススケジューリングパターンで異なります。

本記事は、AWS上でこれらの要件に対応する4層アーキテクチャを提示しました：

1. インフラビルディングブロック：EC2 P-インスタンス・EFAネットワーキング・階層型ストレージ
2. リソースオーケストレーション：Slurm・Kubernetes（SageMaker HyperPod）
3. MLソフトウェアスタック：PyTorchベースの5層ランタイム
4. 可観測性：Prometheus + Grafana + DCGM-Exporter