AWS、NVRx を用いた Amazon EKS 上での分散学習耐障害性向上ガイドを公開──H100 クラスタのチェックポイント I/O 待ち時間を削減
Amazon EKS と NVIDIA Resiliency Extension を組み合わせ、大規模 LLM 分散学習におけるチェックポイントの同期 I/O 負荷やノード障害時のダウンタイムを抑制する。
リリース: 2026-09-16 · 読了 4 分記事の要約
1. 核心（What）
- AWS は Amazon EKS と NVIDIA Resiliency Extension (NVRx) を統合し、大規模分散学習における耐障害性を高めるアーキテクチャを公開した。
- NVRx の非同期チェックポイント機能により、状態辞書の保存処理をバックグラウンドプロセスへ逃がし、同期 I/O による学習停止を防ぐ。
- ソフトウェア例外や NCCL などのソフト障害にはインプロセス再起動、OOM などのハード障害には ft_launcher による自動ワーカー再生成を適用する。
- p5.48xlarge (8x H100) インスタンスと Amazon FSx for Lustre を組み合わせた具体的な検証コードと構成が提供されている。
2. 影響（Why）
- I/O 待ち時間の削減: 同期型チェックポイント保存は全ランクをブロックしてクラスタ全体のウォールタイムを最大 40% 圧迫するため、非同期化による効率化が不可欠である。
- 自動復旧による運用負荷低減: 単一の GPU 障害でクラスタ全体が停止するカスケード障害を防ぎ、障害検知から再開までのダウンタイムを数秒単位に短縮する。
3. 根拠・詳細（How）
- TorchAsyncCheckpoint による非同期保存: torch.save の代わりに async_save() を呼び出し、FSDP LOCAL_STATE_DICT と組み合わせて各ランクが自身のシャードをバックグラウンドで直接書き込む。
- 多層障害リカバリの仕組み: ソフト障害は inprocess.Wrapper でインタプリタを維持したまま再接続し、SIGKILL や OOM などのハード障害は ft_launcher の RankMonitorClient が検出して同一ジョブ内でワーカーを再生成する。
4. 展望・課題（Next）
- 対応バージョンの要件: 検証結果の再現には PyTorch 2.9+ と NVRx 0.4.1 が必要であり、本番展開では最新の v0.6.0 系および対応するランチャー設定への追従が推奨される。