公開：2026年9月17日, 最終更新：2026年9月17日
30秒サマリー
- AWSがEKS上でNVRxを使いLLM分散学習の耐障害性を高める実装方法を公式ブログで解説
- 非同期チェックポイントにより従来の同期保存で失われていた最大40%のGPU稼働時間を削減可能
- ソフト障害・ハード障害をそれぞれ異なる復旧レイヤーで自動対処し、無駄なGPU時間を最小化
何が起きたか
AWSのMachine Learning Blogは、NVIDIA Resiliency Extension（NVRx）をAmazon EKS上のPyTorch FSDP分散学習に組み込む手法を解説した記事を公開した。記事では、大規模分散学習においてGPU障害が発生すると、NCCLタイムアウトが正常なワーカーにも波及してポッドがクラッシュし、高価なGPU時間を無駄に消費する問題を取り上げている。また、従来の同期チェックポイントでは全ランクがI/O待ちになる時間が、当該記事の検証規模で最大40%に達することも示されている。
NVRxはpipでインストールできるPythonライブラリで、カスタムカーネルやPyTorchのフォークを必要とせず既存のFSDPスクリプトに追加できる。主要機能は3つ：①TorchAsyncCheckpointによる非同期チェックポイント（保存処理をバックグラウンドで実行しトレーニングと並列化）、②inprocess.Wrapperによるインプロセス再起動（NCCLハングや例外発生時にプロセスを終了させず数秒で復旧）、③ft_launcherによるジョブ内再起動（OOMやSIGKILLなどハードな障害に対応）。
インフラ構成はAmazon EKSにp5.48xlargeインスタンス（H100 80GB×8基、EFAネットワークインターフェース×32）を2〜8ノード展開し、チェックポイント共有ストレージにはAmazon FSx for Lustre（SCRATCH_2、1.2TB）を使用。ベンチマークはH100 GPUを用いて2〜8ノード規模で実施されており、コードは再現可能な形で公開されているとしている。検証ではLlama-3.1-8Bモデルを使用したと原文に記載されている。
原典ハイライト
原文によると、同期チェックポイントのI/O待機は検証環境の規模で「総ウォールタイムの最大40%」を消費する。NVRxの非同期チェックポイントはFSDP LOCAL_STATE_DICTと組み合わせることで、全ランクでのall-gatherやrank-0ボトルネックを排除し、各ランクが自身のシャードを直接書き込む構成を実現する。復旧レイヤーはソフト障害（インプロセス再起動）、ハード障害（ft_launcher）、ノード消失（クラスターオーケストレーター）の3層が独立して機能し、必要なものだけを選択適用できる設計となっている。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
LLM事前学習や大規模ファインチューニングでは、数日〜数週間に及ぶジョブ中に障害は「もし起きたら」ではなく「必ず起きる」前提で設計する必要がある。NVRxは既存のPyTorch/FSDPコードへの変更を最小限に抑えながら、①無駄なGPU待機時間の削減、②障害時の自動復旧、という2つの課題を同時に解決する実装パスを提供する。GPU時間のコストを考えると、チェックポイントI/O改善だけでも経済的な効果は大きい。
日本企業への示唆
H100やA100クラスターでLLMの学習を行っている、または計画している日本企業・研究機関にとって直接参考になる実装事例といえる。特に注目すべき点は3つ：①NVRxはpip一行で導入でき、既存コードの大幅改修が不要な点、②EKS＋FSx for Lustreの構成はAWSマネージドサービスのみで完結するためインフラ管理コストが低い点、③障害復旧レイヤーを障害クラス別に段階導入できるため、リスクを抑えながら段階的に適用できる点。GPU調達コストが高騰する中、稼働効率の改善はコスト削減に直結する。社内MLOpsチームはまず非同期チェックポイントの単体導入から検証を始めることを検討する価値がある。
背景・経緯
大規模分散学習における障害耐性は、LLMの学習コスト増大とともに重要課題となっている。NVIDIAはNVRxをオープンソースのPythonライブラリとして提供しており、原文ではバージョン0.4.1でベンチマークを実施、現行デプロイにはv0.6.0を推奨している。AWSはEKS上での分散学習インフラ構成についてawsome-distributed-aiリポジトリでもガイドを公開しており、今回の記事はその延長上に位置するとみられる。
