AWS における基盤モデルのトレーニングと推論のための構築ブロック

[記事一覧に戻る](https://huggingface.co/blog) 長い間、ファウンデーションモデルにおける「スケーリング」とは主に一つの意味を持っていました：事前学習により計算リソースをより多く投入すれば、能力が向上するというものです。この直感は、**モデルパラメータ**、**データセットサイズ**、および**トレーニング計算量**をスケールさせた際に損失に予測可能なべき乗則の傾向が見られると報告した実証的研究である [Kaplan et al. (2020)](https://arxiv.org/abs/2001.08361) によって裏付けられていました。実際、これらの傾向は、大規模なアクセラレータ容量への持続的な投資と、それを効率的に活用するために必要な周辺分散インフラストラクチャを正当化するものでした。 しかし最前線は進化しており、スケーリングはもはや単一の曲線ではありません。NVIDIA の「1 から 3 へのスケーリング法則」という枠組みは有用にも強調しています。事前学習を超えて、パフォーマンスは**ポストトレーニング**（例えば、教師あり微調整 (SFT) や強化学習 (RL) ベースの手法）および**推論時の計算量**（「長い思考」、検索/検証、マルチサンプル戦略など）を通じて、ますますスケーリングされるようになります。 **図：** NVIDIA ブログ ["AI's Three Scaling Laws, Explained"](https://blogs.nvidia.com/blog/ai-scaling-laws/) から改変。 これらスケーリングレジームを総合すると、ファウンデーションモデルのライフサイクル（事前学習、事後学習、推論）は、密結合したアクセラレータ計算、高帯域幅・低遅延ネットワーク、分散ストレージバックエンドという収束するインフラ要件へと向かいます。また、リソース管理におけるオーケストレーションの重要性が高まり、クラスターヘルスの維持や大規模環境でのパフォーマンス病理の診断には、アプリケーションレベルおよびハードウェアレベルの観測性（observability）が不可欠となります。 もう一つの重要なトレンドは、モデル開発フレームワーク、クラスターリソース管理、運用ツールにわたるオープンソースソフトウェア（OSS）エコシステムへの、ファウンデーションモデルのライフサイクルにおける依存度の高まりです。クラスター層では、リソース管理は通常、[Slurm](https://slurm.schedmd.com/documentation.html) や [Kubernetes](https://kubernetes.io/docs/) などのシステムによって提供されます。モデル開発と分散トレーニングは、一般的に [PyTorch](https://pytorch.org/) や [JAX](https://jax.readthedocs.io/) などのフレームワークで実装されています。監視および可視化、つまり観測可能性（observability）は、メトリクス収集には [Prometheus](https://prometheus.io/docs/introduction/overview/) を、可視化とアラート通知には [Grafana](https://grafana.com/docs/grafana/latest/) を使用して達成されることが多く、これらはインフラストラクチャおよびリソース管理の上に位置する運用層として機能します。図 1 はこの階層型アーキテクチャを示しており、ハードウェアインフラストラクチャがリソースオーケストレーションを支え、それがさらに ML フレームワークを可能にし、観測可能性がすべての層にわたって展開されている様子を描いています。 *Figure 1: ファウンデーションモデルのトレーニングおよび推論におけるオープンソースソフトウェアスタックの階層型アーキテクチャ* 本記事は、基盤モデルのトレーニングおよび推論に関わる機械学習エンジニアおよび研究者を対象としており、特にオープンソース（OSS）フレームワーク上に構築されたワークフローに重点を置いています。ここでは、AWS インフラストラクチャ（マルチノードアクセラレータ計算、高帯域・低遅延ネットワーク、分散共有ストレージ、および関連するマネージドサービス）が、基盤モデルのライフサイクル全体を通じて一般的な OSS スタックとどのように相互作用するかを分析します。主な目的は、事前トレーニング、事後トレーニング、推論にわたるシステムのボトルネックとスケーリング特性を理解するための技術的基盤を提供することです。本導入記事では、大規模分散トレーニングおよび推論を支える AWS インフラストラクチャコンポーネントと OSS ツールの統合ポイントに重点を置きつつ、全体システムアーキテクチャを紹介しています。 ## The AWS Building Blocks このシリーズの残りの部分では、この階層型アーキテクチャが AWS 上でどのように実現されるかを、インフラストラクチャ、リソースオーケストレーション、ML ソフトウェアスタック、および観測可能性（Observability）を通じて順を追って検証します。以下のセクションで各レイヤーをプレビューします。 ## Infrastructure: Compute, Network, and Storage 図 1 に示すように、インフラストラクチャは、大容量デバイスメモリを備えたアクセラレータ計算、集合通信のための広帯域インターコネクト、データおよびチェックポイント用のスケーラブルな分散ストレージという、3 つの結合されたビルディングブロックによって支えられています。 加速されたコンピューティングは、大規模なファウンデーションモデルの事前学習、事後学習、推論の基盤を形成しています。AWS は、Amazon EC2 P インスタンスファミリーを含む、[Amazon EC2 加速コンピューティングインスタンス](https://aws.amazon.com/ec2/instance-types/accelerated-computing/)の一部として、複数の世代にわたる NVIDIA GPU を提供しています。[P5 インスタンスファミリー](https://aws.amazon.com/ec2/instance-types/p5/)には、8 つの [NVIDIA H100](https://www.nvidia.com/en-us/data-center/h100/) GPU を搭載した p5.48xlarge、小規模なワークロード向けの単一の H100 GPU を搭載した p5.4xlarge、および [NVIDIA H200](https://www.nvidia.com/en-us/data-center/h200/) GPU を搭載した p5e.48xlarge/p5en.48xlarge バリアントが含まれます。[P6 インスタンスファミリー](https://aws.amazon.com/ec2/instance-types/p6/)では、p6-b200.48xlarge に [NVIDIA Blackwell B200](https://www.nvidia.com/en-us/data-center/dgx-b200/) アーキテクチャが導入され、[Blackwell Ultra B300](https://developer.nvidia.com/blog/inside-nvidia-blackwell-ultra-the-chip-powering-the-ai-factory-era/) を搭載した p6-b300.48xlarge が登場しています。 これらの世代全体を通じて、主要なスケーリング軸は、ピーク Tensor スループット、HBM（High Bandwidth Memory）の容量と帯域幅、およびノード内およびノード間の相互接続帯域幅です。 一次近似として、浮動小数点演算毎秒（FLOPS）で測定されるピーク Tensor Core スループットは、これらのアクセラレータを共通の軸上に位置づけるのに役立ちます。以下の表は、NVSwitch/NVLink ベースのマルチ GPU ノードと整合する SXM/HGX クラス仕様を用いた、密集型 BF16/FP16 および FP8 Tensor 演算ごとの GPU 別ピークスループット、HBM（High Bandwidth Memory）容量、および HBM バンド幅を要約したものです。 GPU（代表的なバリアント） BF16/FP16 Tensor ピーク（密集型） FP8 Tensor ピーク（密集型） FP4 Tensor ピーク（密集型） HBM 容量 HBM バンド幅 [H100 (SXM)](https://www.nvidia.com/en-us/data-center/h100/) 0.9895 PFLOPS 1.979 PFLOPS — 80 GB HBM3 3.35 TB/s [H200 (SXM)](https://www.nvidia.com/en-us/data-center/h200/) 0.9895 PFLOPS 1.979 PFLOPS — 141 GB HBM3e 4.8 TB/s [B200 (HGX, GPU 当たり)](https://www.nvidia.com/en-us/data-center/dgx-b200/) 2.25 PFLOPS 4.5 PFLOPS 9 PFLOPS 180 GB HBM3e 8 TB/s [B300 (HGX, GPU 当たり)](https://www.nvidia.com/en-us/data-center/dgx-b200/) 2.25 PFLOPS 4.5 PFLOPS 13.5 PFLOPS 288 GB HBM3e 8 TB/s *注記：NVIDIA の製品表では、スパース性を考慮したテンソルスループットを報告することが多いですが、本表は密な（dense）スループットを報告しています。該当する箇所では、NVIDIA が HGX クラスプラットフォームに対して示唆している通り、密なスループットはスパーススループットの半分として算出されています ([NVIDIA](https://www.nvidia.com/en-us/data-center/hgx/))。DGX の数値はシステムレベルのものです。B200 の HBM 容量および帯域幅の数値は、DGX の総量を 8 で割ることで GPU 単位の値として表されています ([NVIDIA](https://www.nvidia.com/en-us/data-center/dgx-b200/))。 モデルがスケールするにつれ、ステップ時間は生計算スループットよりも集合通信やメモリアクセスによって支配されることが多く、明示的なスケールアップおよびスケールアウトの帯域幅の考慮が必要となります。マルチ GPU インスタンスにおける GPU 間の通信は、2 つの領域にまたがります。**内部スケールアップ（NVLink/NVSwitch）** は、ノード内の GPU と GPU の間を高帯域・低遅延で接続し、ホストネットワークスタックを迂回して all-reduce や all-gather などの集合演算を実行可能にします。**外部スケールアウト（EFA）** は、OS をバイパスしたネットワークをノード間で提供し、AWS ではこれを [Amazon EC2 UltraClusters](https://aws.amazon.com/ec2/ultraclusters/) の構築ブロックとして利用しており、ここでは数千のインスタンスにわたって通信集約型の集合演算が行われます。以下の表は、これらのインスタンスタイプにおける主要な仕様を要約したものです： Instance Type GPU GPUs GPU Memory NVLink NVLink BW (aggregate) EFA EFA BW (aggregate) [p5.4xlarge](https://aws.amazon.com/ec2/instance-types/p5/) H100 1 80 GB HBM3 — — v2 12.5 GB/s [p5.48xlarge](https://aws.amazon.com/ec2/instance-types/p5/) H100 8 640 GB HBM3 第 4 世代 7.2 TB/s v2 400 GB/s [p5e.48xlarge](https://aws.amazon.com/ec2/instance-types/p5/) H200 8 1,128 GB HBM3e 第 4 世代 7.2 TB/s v2 400 GB/s [p5en.48xlarge](https://aws.amazon.com/ec2/instance-types/p5/) H200 8 1,128 GB HBM3e 第 4 世代 7.2 TB/s v3 400 GB/s [p6-b200.48xlarge](https://aws.amazon.com/ec2/instance-types/p6/) B200 8 1,440 GB HBM3e 第 5 世代 14.4 TB/s v4 400 GB/s [p6-b300.48xlarge](https://aws.amazon.com/ec2/instance-types/p6/) B300 8 2,100 GB HBM3e 第 5 世代 14.4 TB/s v4 800 GB/s *注：EFA（Elastic Fabric Adapter）の帯域幅は、他の帯域幅指標との整合性を保つため、Gbps から GB/s に換算されています（÷8）。詳細は [EC2 高速コンピューティングネットワーク仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_network) を参照してください。NVLink および EFA の帯域幅数値は、リンクごとの値ではなく、インスタンスあたりの集計値として表示されています。対応するノード間相互接続およびネットワーク特性については、[P5 インスタンスファミリーページ](https://aws.amazon.com/ec2/instance-types/p5/) および [P6 インスタンスファミリーページ](https://aws.amazon.com/ec2/instance-types/p6/) を参照してください。 Elastic Fabric Adapter (EFA) は、Amazon EC2 向けのネットワークインターフェースであり、[Scalable Reliable Datagram (SRD)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) プロトコルを使用して、OS をバイパスしたリモート直接メモリアクセス（RDMA）機能を提供します。Libfabric API を介してアプリケーションがネットワークデバイスと直接通信し、オペレーティングシステムカーネルをバイパスできるようにすることで、EFA は分散学習における集合演算のレイテンシを低減し、スループットを向上させます。 異なるインスタンスファミリーでは複数の世代の EFA が利用可能です。Amazon EC2 P5 および P5e インスタンスには EFA バージョン 2 (EFAv2) が搭載されています。[P5en インスタンスで提供される EFA バージョン 3 (EFAv3) は、EFAv2 と比較してパケットレイテンシを約 35% 削減します](https://aws.amazon.com/blogs/aws/new-amazon-ec2-p5en-instances-with-nvidia-h200-tensor-core-gpus-and-efav3-networking/)。[P6 インスタンスで利用可能な EFA バージョン 4 (EFAv4) は、EFAv3 と比較して集合通信のパフォーマンスをさらに 18% 向上させます](https://aws.amazon.com/blogs/machine-learning/aws-ai-infrastructure-with-nvidia-blackwell-two-powerful-compute-solutions-for-the-next-frontier-of-ai/)。 スケーラビリティの観点では、分散トレーニング（ストリーミングコーパスとマルチテラバイト単位のチェックポイント書き込み）および大規模推論（重みのステージングと KV キャッシュ成長の管理）の両方が、階層型ストレージ構造を必要とします。具体的には、ホットデータ用としてローカル NVMe SSD を、共有高スループットアクセス用として Lustre を、永続的保存用として [Amazon S3](https://aws.amazon.com/s3/) をそれぞれ利用します。 本シリーズの主要なマルチ GPU インスタンスでは、ローカル NVMe は **インスタンスストア（エフェメラル）** として提供され、**30.72 TB の生容量（8 × 3.84 TB の NVMe SSD）** を備えています。詳細は [EC2 アクセラレーテッドコンピューティング インスタンスのストレージ仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_instance-store) をご覧ください。 [Lustre](https://www.lustre.org/about/) は、オープンソースで POSIX 準拠の分散ファイルシステムであり、高性能計算（HPC）分野で広く利用されています。これは多数のクライアント間で高い集約スループットを備えた共有名前空間を提供するものです。[Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) は、Lustre をフルマネージドサービスとして提供し、秒間テラバイト単位のデータ転送能力、数百万の IOPS（入出力オペレーション数）、サブミリ秒のレイテンシを実現する並列ファイルシステムとして公開しています。Data Repository Associations（データリポジトリ関連付け）により [Amazon S3](https://aws.amazon.com/s3/) と統合が可能で、トレーニングデータの遅延読み込みや、永続性を確保するための自動チェックポイントエクスポートをサポートします。 クラスター規模では、これらのインスタンスは [Amazon EC2 UltraClusters](https://aws.amazon.com/ec2/ultraclusters/) にデプロイされており、これは 1 つの可用性ゾーン内に数千台のアクセラレータ付きインスタンスを単一の密接に配置されたクラスターとしてプロビジョニングし、ペタビット規模のノンブロッキングネットワークを使用して相互接続するものです。 **図:** 第 2 世代 Amazon EC2 UltraClusters（例：P5 UltraCluster）。 ステップごとの通信強度が高いワークロード（例えば、すべての GPU にわたってトークンの分散を行う MoE モデルにおけるエキスパート並列処理など）の場合、NVLink ドメインのサイズが主要な制約要因となる可能性があります。内部スケールアップ軸の拡張として NVLink ドメインを拡大することで、パフォーマンスに重要な通信が NVLink ファブリックから外部に出る頻度を低減できます。 [Amazon EC2 UltraServers](https://aws.amazon.com/ec2/ultraservers/) は、専用アクセラレータ相互接続を介して複数のコンポーネントインスタンスを接続することで、NVLink ドメインを単一の EC2 インスタンスを超えて拡張します。AWS によると、[P6e-GB200 UltraServers](https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-p6e-gb200-ultraservers-gpu-performance-ec2/) は [NVIDIA GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) プラットフォームを基盤として構築されており、1 つの NVLink ドメイン内で最大 72 個の Blackwell GPU と合計 13.4 TB の HBM3e を提供します。より大規模なスケールでは、EFA がマルチ UltraServer ジョブにおけるノード間ファブリックとして引き続き機能しますが、ドメイン内の GPU 数を増やすことで、パフォーマンスに重要な通信が NVLink ファブリックから外部に出る頻度を低減できます。 これらのシステムは、NVIDIA Grace–Blackwell スーパーチップで構築されており、キャッシュ整合性のある [NVLink-C2C](https://developer.nvidia.com/blog/nvidia-grace-hopper-superchip-architecture-in-depth/) を介して Grace CPU メモリと Blackwell GPU の HBM を結合しています。これにより、明示的なホスト - デバイス間のコピーを行わずに、CPU 接続メモリと GPU 接続メモリの間を直接アクセスすることが可能になります。実際には、これは GPU ワークロードに対して利用可能な有効メモリを拡張する効果があります（例えば、より冷たいモデル状態や KV キャッシュを CPU 接続メモリに配置するなど）。ただし、ローカル HBM に比べてレイテンシが高く、帯域幅が低いというトレードオフはあります。 P6e-GB200 UltraServers のコンポーネントインスタンスタイプは [p6e-gb200.36xlarge](https://aws.amazon.com/ec2/instance-types/p6/) であり、4 つの GPU と Elastic Fabric Adapter (EFA) v4 ネットワークを提供します。以下の表は、各インスタンスおよび構成された UltraServer の構成を要約したものです。 Instance Type | GPU | GPUs | GPU Memory | Memory BW | NVLink | NVLink BW | EFA | EFA BW ---|---|---|---|---|---|---|---|--- [p6e-gb200.36xlarge](https://aws.amazon.com/ec2/instance-types/p6/) | [GB200 NVL72](https://www.nvidia.com/en-us/data-center/gb200-nvl72/) | 4 | [740 GB HBM3e](https://aws.amazon.com/blogs/aws/new-amazon-ec2-p6e-gb200-ultraservers-powered-by-nvidia-grace-blackwell-gpus-for-the-highest-ai-performance/) | — | — | — | v4 | [200 GB/s](https://aws.amazon.com/blogs/aws/new-amazon-ec2-p6e-gb200-ultraservers-powered-by-nvidia-grace-blackwell-gpus-for-the-highest-ai-performance/) *注：p6e-gb200.36xlarge の EFA バンド幅は、公開された集約 EFA ネットワーク (4 × 400 Gbps) から GB/s に変換されています (÷8)。詳細は [EC2 アクセラレーテッドコンピューティングネットワーク仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_network) を参照してください。 UltraServer | Component instance type | GPUs (NVLink domain) | HBM3e (aggregate) | EFA | EFA BW ---|---|---|---|---|--- u-p6e-gb200x36 | [p6e-gb200.36xlarge](https://aws.amazon.com/ec2/instance-types/p6/) | 36 | 6.7 TB | v4 | 1,800 GB/s u-p6e-gb200x72 | [p6e-gb200.36xlarge](https://aws.amazon.com/ec2/instance-types/p6/) | 72 | 13.4 TB | v4 | 3,600 GB/s *注記：UltraServer の EFA バンド幅は、AWS が報告したテラビット毎秒 (Tbps) からギガバイト毎秒 (GB/s) に換算されています（÷8）；詳細は [P6e-GB200 UltraServers 発表](https://aws.amazon.com/blogs/aws/new-amazon-ec2-p6e-gb200-ultraservers-powered-by-nvidia-grace-blackwell-gpus-for-the-highest-ai-performance/) および [P6 インスタンスファミリーページ](https://aws.amazon.com/ec2/instance-types/p6/) をご参照ください。* ## リソースオーケストレーション：Slurm と Kubernetes トレーニングが数百から数千のアクセラレーターにまたがる場合、手動によるリソース管理は実質的に不可能になります。例えば、512 個の GPU を必要とするトレーニングジョブでは、64 台の 8-GPU ノード（P インスタンス）を同時にスケジューリングし、完了または失敗時にリソースを原子的に解放する必要があります。[Slurm](https://slurm.schedmd.com/) と [Kubernetes](https://kubernetes.io/) の両方は、この課題に対処するためにコントロールプレーンアーキテクチャを採用しています：集中型スケジューラーがクラスターの状態を維持し割り当て決定を行い、ワーカーノードは割り当てられたワークロードを実行します。 *図 2: AWS における Slurm ベースおよび Kubernetes ベースのリソースオーケストレーションのハイレベルアーキテクチャ* [Slurm](https://slurm.schedmd.com/)（Simple Linux Utility for Resource Management）は、高パフォーマンスコンピューティングにおける支配的なワークロードマネージャーであり、モジュール型プラグインアーキテクチャに基づいて構築されています。これにより、スケジューリングアルゴリズム、トポロジーモデル、リソースタイプ、およびアカウンティングバックエンドを独立して構成することが可能です。そのスケジューリングモデルは、リソースをパーティション（ノードの論理的なグループ化）に整理し、sbatch を介してジョブの提出を受け付け、割り当てられたノード間で同期起動を行いながら srun を通じて並列タスクを開始します。分散トレーニングにおいて特に重要なのは、Slurm がジョブレベルでスケジューリングを行う点です。つまり、タスクが開始される前に、マルチノジョブ全体を原子操作として割り当てます。[バックフィルスケジューラー](https://slurm.schedmd.com/sched_config.html) は、優先度の低いジョブをアイドル状態のスロットに開始し、より高い優先度のジョブの遅延を引き起こすことなく稼働させます。一方、[多要素優先度](https://slurm.schedmd.com/priority_multifactor.html) システムは、フェアシェア利用状況、ジョブの経過時間、QOS（Quality of Service）ティアを重み付けして、テナント間でのキュー順序を決定します。Slurm はまた、ネットワークスイッチ階層をモデル化するプラグインを通じて [トポロジー認識配置](https://slmur.schedmd.com/topology.html) をサポートしており、AWS 環境では EFA ファブリックのトポロジーをエンコードして、最小限のスイッチホップ数でノード上にジョブを共置します。さらに、Generic Resource（GRES）インターフェースを通じてネイティブな [GPU スケジューリング](https://slurm.schedmd.com/gres.html) をサポートしており、これは GPU タイプを追跡し、デバイスアフィニティを強制する機能を持っています。 AWS は、Slurm ベースのオーケストレーションに対して複数のデプロイオプションを提供しています。[AWS ParallelCluster](https://github.com/aws/aws-parallelcluster) は、EC2 上で Slurm クラスターを自動化して展開するオープンソースのクラスター管理ツールであり、ヘッドノードのプロビジョニング、計算リソース群のスケーリング、共有ストレージとの統合を処理します。[AWS Parallel Computing Service (PCS)](https://aws.amazon.com/pcs/) は、マネージドされたコントロールプレープを提供する代替手段です。特に分散型トレーニングワークロードについては、[Amazon SageMaker HyperPod](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod.html) が Slurm モードをサポートしており、大規模なトレーニング向けに特別に設計された追加機能として、[継続的なノードヘルスモニタリング](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-cluster-health-check.html) や [ジョブの自動再開機能](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-auto-resume.html) を提供しています。 [Kubernetes](https://kubernetes.io/) は宣言的かつ API ドライブ型のアプローチを採用しており、ユーザーはリソースマニフェストを通じて望ましい状態を指定し、コントローラーが実際の状態をその状態に一致させるように調整します。Kubernetes はモデル展開において卓越した能力を発揮しますが、そのネイティブなスケジューリングモデルには、密結合型分散トレーニングにおいていくつかの課題が存在します。Kubernetes はポッドレベルでスケジューリングを行うため、ジョブレベルでの原子性が欠如しており、マルチノード構成のトレーニングジョブが部分的に開始されることがあります。具体的には、一部のランクは実行中である一方で他のランクは Pending 状態のままとなり、GPU が無駄になったりデッドロックが発生したりする可能性があります。また、標準的な Kubernetes には、優先度ベースのバックフィルを備えたバッチキューのセマンティクスや、通信集約型の集合操作（collectives）の配置のために必要なネットワークファブリックトポロジ（NVLink ドメイン、EFA インターコネクトなど）への組み込み認識機能も不足しています。 いくつかの Kubernetes ネイティブプロジェクトが、異なるレイヤーにおいてこれらのギャップを埋めています。[Kueue](https://kueue.sigs.k8s.io/) はデフォルトスケジューラの上にアドミッションコントローラーとして動作し、ジョブレベルのガングアッドミッション、階層的公平共有によるマルチテナントクォータ管理、優先度ベースのプリエンプションを処理しますが、ポッド配置は基盤となるスケジューラに委譲します。[Volcano](https://volcano.sh/) と [NVIDIA KAI Scheduler](https://github.com/NVIDIA/KAI-Scheduler) は異なるアプローチを採用し、デフォルトスケジューラを置き換えまたは拡張して、ガンスケジューリングをトポロジ認識型ポッド配置と直接統合します。Volcano は汎用バッチスケジューラとして機能し、KAI Scheduler は GPU 最適化配置のための深い NVLink/NVSwitch 認識機能を備えています。これらのレイヤーは補完関係にあります：Kueue がアドミッションとクォータポリシーを管理しつつ、承認されたジョブをトポロジ認識型スケジューラに渡して配置を行うことができます。 AWS における Kubernetes ベースのオーケストレーションには、[Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) が、[NVIDIA デバイスプラグイン](https://github.com/NVIDIA/k8s-device-plugin) を介して GPU スケジューリング機能を備えたマネージド Kubernetes を提供しています。Amazon SageMaker HyperPod も [EKS モード](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks.html) をサポートしており、Kubernetes のオーケストレーション能力と HyperPod のトレーニング特化型機能を組み合わせています。HyperPod EKS は、大規模なファウンデーションモデルのトレーニング向けに設計された機能で EKS を拡張します。[タスクガバナンス](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance-policies.html) により、チーム間での計算リソースの割り当てとポリシーの強制が可能となり、管理された [Kueue](https://kueue.sigs.k8s.io/) を導入して admission control（入場制御）を行い、[Karpenter](https://karpenter.sh/) を用いてジョブ発生時に必要なノードを即時プロビジョニングします。[チェックポイントレストレーニング](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-checkpointless.html) は、従来のチェックポイントベースのフォールトトレランスに内在する回復遅延の問題に対処します。モデル状態を定期的に共有ストレージへシリアライズするのではなく、チェックポイントレストレーニングでは GPU 間で継続的なピアツーピアの状態複製を維持します。障害が発生した場合、生存しているノードは FSx for Lustre や S3 から数テラバイトのチェックポイントを読み込むのではなく、EFA ベースの通信を通じて失われた状態を再構築します。[エラスティックトレーニング](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-eks-elastic-training.html) により、ジョブはリソースの利用状況に基づいて自動的にスケールします。追加のアクセラレーターが利用可能になった場合（例えば、完了したジョブから解放されたものや新たにプロビジョニングされた容量）、エラスティックジョブはそれらを活用して拡張できます。一方、より優先度の高いワークロードがリソースを必要とする場合は、トレーニングの進捗を維持しながらジョブを縮小できます。 ## ML ソフトウェアスタック 分散トレーニングと推論には、正しく構成され調整される複数のソフトウェア層が含まれます。有用なモデルは、ランタイムスタックを 5 つの層として捉えます。これらは、ハードウェアに隣接するコンポーネント（何らかの実行を行うために正しく機能する必要がある）から、プログラマの生産性とモデルのスループットを決定するフレームワークレベルの抽象化まで順に並べられています。具体的には、ハードウェア対応、アクセラレータランタイムおよび数値計算ライブラリ、通信基盤、ML フレームワーク、分散トレーニング/推論フレームワークです。 *図 3: EC2 インスタンス上での分散トレーニングと推論における ML ソフトウェアスタック* ## ハードウェア対応：カーネルドライバ 基盤となる Linux カーネルドライバは、ハードウェアへの直接アクセスを提供します。NVIDIA GPU ドライバは計算機能の公開を行い、GPU とネットワークアダプタ間のデータ転送を可能にする [GPUDirect RDMA](https://docs.nvidia.com/cuda/gpudirect-rdma/index.html) をサポートしています。[GDRCopy](https://github.com/NVIDIA/gdrcopy) ドライバ（gdrdrv）は、GPU メモリへの CPU による低遅延コピーを可能にし、NCCL が小メッセージ転送に使用します。[EFA driver](https://github.com/amzn/amzn-drivers) は [libfabric](https://github.com/ofiwg/libfabric) API を通じて OS バイパスネットワークを提供し、[Lustre client](https://www.lustre.org/) ドライバは FSx for Lustre パラレルファイルシステムへの POSIX アクセスを可能にします。 ## アクセラレータランタイム、コンパイラ、およびカーネルライブラリ [CUDA](https://developer.nvidia.com/cuda-toolkit) プラットフォームは、GPU 計算のためのプログラミングモデルとランタイムを提供します。CUDA に基づいてコンパイルされたアプリケーションは、NVIDIA GPU でカーネルを実行し、デバイスメモリを管理し、複数のデバイスにわたる実行を調整できます。現在のリリースは CUDA Toolkit 13.x で、Blackwell アーキテクチャ（計算能力 10.x）をサポートしています。 現代のトレーニングおよび推論のパフォーマンスは、汎用ベンダープリミティブだけでなく、専門的な最適化ライブラリとカスタムカーネルによってますます駆動されています。[FlashAttention](https://github.com/Dao-AILab/flash-attention) などのカーネルは、アテンションを単一のメモリ効率的なパスに融合させ、HBM（High Bandwidth Memory）のトラフィックを削減し、スループットを向上させます。多くのチームは、形状や精度に特化した融合カーネル（例：レイヤーノーマライゼーション/リジューアル/活性化、量子化 GEMM、MoE 分散、KV キャッシュ操作など）を、自社のモデルに合わせてチューニングして記述しています。これは、[Triton](https://triton-lang.org/)（Python GPU カーネルコンパイラ）や NVIDIA の [CuTe](https://github.com/NVIDIA/cutlass/blob/main/media/docs/cute/00_quickstart.md)（テンソルレイアウトおよびワープレベル DSL）といったプログラム可能なツールチェーンによって可能になり、[CUTLASS](https://github.com/NVIDIA/cutlass) などのライブラリが高度に最適化された GEMM および融合のビルディングブロックを提供しています。実際には、このカーネルとコンパイラ層が ML フレームワークと同程度にエンドツーエンドのパフォーマンスを決定することが多いです。 ## コミュニケーション基盤：NCCL とトランスポートプラグイン マルチ GPU 学習は、効率的な集合通信に依存しています。[NVIDIA Collective Communications Library (NCCL)](https://developer.nvidia.com/nccl) は、トポロジ認識アルゴリズムを実装した集合演算（オールリダクション、オールギャザ、リダックスキャッター、オールツーオール、ブロードキャスト、およびポイントツーポイント送受信）を提供し、ノード内通信には NVLink を、ノード間トラフィックにはネットワーク転送を活用します。NCCL は動的に通信トポロジを検出し、メッセージサイズと利用可能な帯域幅に応じてリングまたはツリーアルゴリズムを選択します。データ並列およびテンソル並列戦略は主にオールリダクションとオールギャザに依存しますが、エキスパート並列性を備えた Mixture-of-Experts (MoE) モデルでは、トークンを GPU 間でルーティングするためにオールツーオールの集合通信が必要です：ディスパッチオールツーオールは各トークンを割り当てられたエキスパートをホストする GPU に送信し、コンバインオールツーオールはエキスパートの出力を発信元の GPU に返します ([NVIDIA Developer Blog](https://developer.nvidia.com/blog/accelerating-large-scale-mixture-of-experts-training-in-pytorch/))。エキスパート並列グループ内のすべての GPU が他のすべての GPU とデータを交換するため、オールツーオールの通信量はエクスパート数に比例して増加し、高い並列度では主要なボトルネックとなる可能性があります。 AWS では、NCCL のノード間通信は [aws-ofi-nccl](https://github.com/aws/aws-ofi-nccl) プラグインを介して有効化されており、これは NCCL のトランスポート API を [libfabric](https://github.com/ofiwg/libfabric) インターフェースにマッピングします。これにより、NCCL はアプリケーションの変更なしで EFA の OS バイパス機能とスケーラブル・リライアブル・データグラム（SRD）プロトコルを活用できます。 推論ワークロードにおいては、集合演算がすべての通信パターンを網羅するわけではありません。プリフェッチフェーズとデコードフェーズを別々の GPU プールに分離した非集約型推論アーキテクチャでは、特にインスタンス間で KV キャッシュ状態を転送する際に、効率的なポイント・ツー・ポイントデータ移動が必要です。[NVIDIA Inference Xfer Library (NIXL)](https://github.com/ai-dynamo/nixl) は、メモリ階層（HBM, DRAM, NVMe, 分散ストレージ）および相互接続（NVLink, InfiniBand, Ethernet）にわたるポイント・ツー・ポイント転送のための統一 API を提供することで、この要件に対応します。NIXL は NVIDIA Dynamo などの推論フレームワークと統合され、UCX や GPUDirect Storage などのバックエンドをサポートしています。 ## ML フレームワーク：PyTorch ファウンデーションモデル開発における2 つの主要なフレームワークは、[PyTorch](https://pytorch.org/) と [JAX](https://jax.readthedocs.io/) です。JAX は XLA を通じて SPMD（Single Program Multiple Data）アプローチを採用しており、同じプログラムがデバイス間で実行され、データ分布と集合的な lowering が自動的に行われます。本シリーズでは、オープンソースエコシステムでより広く採用されており、以下で議論される分散トレーニングおよび推論フレームワークの基礎となっている PyTorch に焦点を当てます。 PyTorch は、GPU によるアクセラレーション、自動微分、柔軟なイーグゼキューションモデルを備えたテンソル計算を提供します。分散ワークロードにおいては、PyTorch の torch.distributed モジュールが中核となるプリミティブを提供します。これには、集合通信のためのプロセスグループと、[Distributed Data Parallel (DDP)](https://docs.pytorch.org/docs/stable/nn.html#torch.nn.parallel.DistributedDataParallel) や [Fully Sharded Data Parallel (FSDP2)](https://docs.pytorch.org/docs/stable/distributed.fsdp.fully_shard.html) を含む分散データ並列化の抽象化が含まれます。DDP はモデルを GPU 間で複製し、all-reduce を通じて勾配を同期します。一方、FSDP2 は ZeRO アルゴリズムの技術を用いて、パラメータ、勾配、オプティマイザの状態をワーカー間でシャード（分割）することで、単一の GPU メモリ容量を超えるモデルのトレーニングを可能にします。 ## 分散トレーニングおよび推論フレームワーク 最上層には、PyTorch を基盤とし、大規模な分散トレーニングと推論のためのより高レベルの抽象化を提供するフレームワークが含まれています。トレーニングにおいては、3 つのカテゴリのフレームワークが、複雑性とパフォーマンスのトレードオフにおける異なるポイントに対応しています。以下にいくつかの例を示します。 [Hugging Face Transformers](https://huggingface.co/docs/transformers/) は、Trainer クラスを提供しており、[Accelerate](https://huggingface.co/docs/accelerate/) を介して DDP（Data Parallelism）、FSDP（Fully Sharded Data Parallel）、DeepSpeed に対する抽象化を内蔵した形でサポートしています。このアプローチは使いやすさと広範なモデル互換性を優先しており、設定の簡素さが最大のスループットよりも重要となるファインチューニングや中規模のトレーニングに適しています。 [NVIDIA Megatron Core](https://developer.nvidia.com/megatron-core) は、Transformer Engine を介した FP8 混合精度計算などの最適化を備えた 3D パラレリズム（テンソル並列、パイプライン並列、エキスパート並列）を実装することで、大規模における最大効率性を目標としています。[NeMo Framework](https://docs.nvidia.com/nemo-framework/user-guide/latest/) は Megatron Core を基盤としており、事前トレーニングとファインチューニングのためのエンドツーエンドのワークフローを提供します。 人間フィードバックからの強化学習（RLHF）および関連するポストトレーニング手法においては、[veRL](https://github.com/volcengine/verl)（Volcano Engine Reinforcement Learning）が、PPO、GRPO、REINFORCE++ などのアルゴリズムを実装した柔軟なフレームワークを提供します。veRL の HybridFlow アーキテクチャでは、トレーニングバックエンド（FSDP2, Megatron）と推論エンジン（vLLM, SGLang）を同じジョブ内で組み合わせることが可能であり、アクターコンポーネントとロールアウトコンポーネント間でモデル重みをメモリ上で共有することで、重みの同期に伴うオーバーヘッドを回避します。 推論サービングにおいては、[vLLM](https://github.com/vllm-project/vllm) が PagedAttention を実装し、KV キャッシュ（Key-Value Cache）をページ化された仮想メモリとして管理することで断片化を削減し、より大きなバッチサイズを実現します。[SGLang](https://github.com/sgl-project/sglang) はこれに RadixAttention を追加してリクエスト間での自動プレフィックス再利用を実現し、CPU のスケジューリングと GPU 計算を重畳させるゼロオーバーヘッドのバッチスケジューラ、および予測されたキャッシュヒット率に基づいてリクエストをルーティングするキャッシュ認識型ロードバランサを提供します。両方のフレームワークは、単一 GPU メモリを超えるモデルをサービングするためのテンソル並列化をサポートしており、[NVIDIA Dynamo](https://developer.nvidia.com/blog/introducing-nvidia-dynamo-a-low-latency-distributed-inference-framework-for-scaling-reasoning-ai-models/) と統合して、プリフェッチ（prefill）フェーズとデコード（decode）フェーズを分離する非集約型サービングアーキテクチャを実現します。 ## 観測可能性 観測可能性は、大規模な分散型トレーニングシステムのデバッグと運用に不可欠な前提条件です。トレーニングジョブが停止したりスループットが低下したりした場合、実践者はその原因がハードウェアの故障、ネットワークの輻輳、ストレージのボトルネック、あるいはアプリケーションレベルの非効率性のいずれにあるかを可視化する必要があります。本シリーズで議論されているインフラスケール（数千個の GPU、ペタビット規模の相互接続帯域幅、テラバイト規模のチェックポイントデータ）において、課題は単純な監視から、体系的なテレメトリ収集、保存、分析へと移行します。観測可能性には 3 つのテレメトリカテゴリが含まれます：インフラストラクチャ指標（GPU、ネットワーク、ストレージ）、ワークロード指標（トレーニングスループット、キュー待ち時間）、および予防的な障害検出のためのアラートです。 ## コアスタック：Prometheus と Grafana Kubernetes および HPC 環境における観測可能性の事実上の標準は、メトリクス収集に [Prometheus](https://prometheus.io/docs/introduction/overview/) を、可視化とアラートに [Grafana](https://grafana.com/docs/grafana/latest/) を組み合わせたものです。Prometheus はプルベースモデルで動作し、メトリクスエクスポート者が公開する HTTP エンドポイントを定期的にスクレイピングします。収集されたメトリクスは時系列データベース（TSDB）に保存され、集約、フィルタリング、アラートルールの評価を行うための柔軟なクエリ言語である PromQL を介して照会されます。Grafana は Prometheus をデータソースとして取り込み、PromQL 式に基づいてダッシュボードを描画し、アラートをトリガーします。 本番環境でのデプロイメントにおいては、[Amazon Managed Service for Prometheus (AMP)](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) が、ストレージ、レプリケーション、高可用性の管理をオペレーターが行う必要なく、1 秒間に数百万サンプルの取り込みに対応できるスケーラブルなフルマネージド型の Prometheus 互換時系列データベースを提供します。[Amazon Managed Grafana (AMG)](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html) は、AMP とのネイティブ統合および IAM Identity Center を介した AWS 認証機能を備えたマネージド型の Grafana ワークスペースを提供します。これら 2 つのサービスを組み合わせることで、既存の Prometheus エクスポートヤーや Grafana ダッシュボードとの互換性を維持しつつ、運用上のオーバーヘッドを解消できます。 ## GPU、ネットワーク、およびアプリケーションのテレメトリー [DCGM-Exporter](https://github.com/NVIDIA/dcgm-exporter) は、NVIDIA の GPU メトリクスを Prometheus 形式で公開します。これには利用率、メモリ使用量、電力消費、温度、ならびに ECC エラーや XID イベントといったハードウェア健全性の指標が含まれます。トレーニングワークロードにおいては、SM アクティビティ（DCGM_FI_PROF_SM_ACTIVE）が、基本的な利用率メトリクスよりも計算効率をより正確に測定する手段となることがよくあります。 EFA は、分散トレーニングにおける集合操作のボトルネックを診断するのに役立つ、ドライバーレベルの統計情報（バイト数、パケット数、再送信回数、タイムアウト）を公開します。[aws-ofi-nccl](https://github.com/aws/aws-ofi-nccl) プラグインは NCCL を libfabric インターフェースに橋渡しし、オペレーターは EFA カウンターと NCCL 診断情報（NCCL_DEBUG=INFO）を組み合わせて、ネットワーク層の問題を特定できます。 [Amazon FSx for Lustre](https://aws.amazon.com/fsx/lustre/) は、スループットやメタデータレイテンシなどのクライアントサイドのメトリクスを公開します。一方、アプリケーションレベルのメトリクス（トレーニングにおけるステップ時間、1 秒あたりのトークン数、損失値；推論における TTFT、トークン間レイテンシ）は、Prometheus クライアントライブラリ経由でエクスポートできます。 ## GPU ヘルスモニタリングとアラート 予防的な障害検知により、ハードウェアの問題が拡張されたトレーニングの中断へと波及するのを防ぎます。一般的なワークフローでは、DCGM のヘルスメトリクスを監視し、エラーカウントが閾値を超えた場合にアラートを発令します。ECC シングルビットエラー（SBE）は少量であれば許容される場合もありますが、SBE 発生率の加速は、ダブルビットエラー（DBE）やその他の障害の前兆であることがよくあります。XID 63（行再マッピング失敗）、XID 64（GPU がバスから脱落）、および XID 94/95（封じ込め済み/封じ込め不可能なエラー）は、通常、即座にノードの交換を要します。 【GPU ヘルス - クラスターダッシュボード】(Grafana dashboard ID 21645) は、一般的な GPU エラーパターンの参照用可視化を提供します。このダッシュボードは、クラスター内のすべてのノードにわたる ECC エラー、XID イベント、熱違反、および行リマップステータスを集約し、オペレーターがトレーニングジョブに影響を与える前に故障するハードウェアを特定できるようにします。 *図 4: GPU エラーパターンとインスタンスレポートを示す GPU ヘルス - クラスターダッシュボード* 本シリーズのパート 5 では、大規模なクラスターの健全性を維持するためのメトリクス収集戦略、ダッシュボード設定、アラートパターンを含む、観測可能性アーキテクチャについて包括的に解説します。 ## 結論 単一の事前トレーニングのスケーリング法則から、相互補完的な 3 つのレジーム（事前トレーニング、事後トレーニング、テスト時計算）への移行は、インフラストラクチャ要件を分断したのではなく、むしろ強化しました。これら 3 つのレジームすべてが、密結合されたアクセラレータ計算、高帯域幅・低遅延ネットワーク、スケーラブルな分散ストレージを必要としますが、主にワークロードプロファイルとリソーススケジューリングのパターンにおいて異なります。 本記事では、AWS 上でこれらの要件を満たすための 4 レイヤー構成を紹介しました。それは、インフラストラクチャのビルディングブロック（EC2 P インスタンス、EFA ネットワーク、階層型ストレージ）、リソースオーケストレーション（Slurm と SageMaker HyperPod を用いた Kubernetes）、ML ソフトウェアスタック（カーネルドライバや CUDA から NCCL、PyTorch まで）、そして観測性（Prometheus、Grafana、GPU ヘルスモニタリング）です。各レイヤーは上位のレイヤーを制約し、同時に可能にします。設定ミスをしたドライバや飽和したネットワークリンクが、最適化された並列処理戦略よりも効果的に、それ以外の点で適切に調整されたトレーニング実行のボトルネックとなる可能性があります。 これらの統合ポイントを理解することは、ファウンデーションモデルのライフサイクル全体を通じてパフォーマンスのボトルネックを診断し、根拠のあるスケーリング判断を下すための基盤となります。 ## 著者 **[Aman Shanbhag](https://www.linkedin.com/in/aman-shanbhag/)** は NVIDIA の MARS MLOps チームに所属する AI パフォーマンスおよびインフラストラクチャエンジニアです。研究チームがスケーラブルで高性能な ML トレーニングおよび推論システムを構築できるよう支援しています。以前は AWS でスペシャリストソリューションアーキテクトとして勤務し、世界中の顧客に対して AWS 上での ML トレーニングと推論の最適化をサポートしました。Aman はライス大学でコンピュータサイエンス、数学、そして起業家精神の学位を取得しており、AI インフラストラクチャやパフォーマンス最適化に注力しています。

AWS における基盤モデルのトレーニングと推論のための構築ブロック

背景や根拠まで確認しますか？

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

ニュースの次に確認する

調べる

選ぶ

サイト