nvidia-resiliency-ext

LLM 学習チェックポイントの設定をどう決めるか はじめに チェックポイントは、学習を中断した地点から再開するために、モデルとオプティマイザの状態をストレージに書き出したものです。1 回に書く量、保存の間隔、書き込みにかけてよい時間が、ストレージに必要な容量と書き込みスループットを決めます。この記事では、これらを決めるための数字を公開資料から整理し、予算内でできるだけ安い FSx for Lustre を見積もる流れを示します。例には、NVIDIA Nemotron 3.5 Super 120B-A12B（以下 Nemotron 3.5 Super）を 32 ノードで学習する場合を使います。 ! 実際に大規模な学習を運用していて、チェックポイントの設定やストレージの選び方について現場の知見をお持ちの方がいたら、ぜひコメントで教えてください。とても喜びます。 ! この記事が扱うのは、チェックポイントの書き込みです。Physical AI のように動画を大量に読む学習では、ストレージへの要求は読み込みが中心になり、話が変わります。たとえば Turing の記事は、7 台の車載カメラの動画を PB 級の規模で S3 から直接読むために、Range GET で必要な部分だけを取り、先読みで S3 のレイテンシーを隠しています。デコードの置き場所も設計の対象で、NVIDIA DALI の動画リーダーは GPU のハードウェアデコーダーで動画をデコードします。読み込みの設計は、この記事とは別に検討が必要です。 保存時の書き込み ZeRO-3 や FSDP、テンソル並列、パイプライン並列、エキスパート並列で学習する場合、モデルとオプティマイザの状態は全ノードに分割されて置かれています。これを PyTorch の Distributed Checkpoint や Megatron-LM の分散チェックポイントで共有ファイルシステムに保存すると、全ノードが同じタイミングで、それぞれが持つ分割をシャードとして書き込みます。データ並列で同じ値を持つ部分は、どれか 1 つのランクだけが書くように重複が除かれます。一方、DDP のように全ランクが同じ状態を持ち、1 つのランクだけがファイルに書く方式では、書き込みスループットの上限はそのノード 1 台で決まります。書き込み先には、EC2 のインスタンスストアとしてノードに付いたローカルの NVMe、全ノードが同じファイルシステムをマウントする FSx for Lustre、オブジェクトストレージの S3 があります。ただし、書き込み先によって必要な仕組みが違います。FSx for Lustre にはファイルシステム向けの書き込みでそのまま書けますが、S3 に直接書くには S3 向けの書き込みの実装が要り、ノードごとのローカル NVMe から再開するには、後の節で扱うローカルチェックポイントの仕組みが要ります。 ローカルの NVMe は、ノードごとに独立しているので、全体の書き込みスループットはノード数に比例して増えます。その代わり、そのノードが使えなくなると、書いたシャードも読めなくなります。FSx for Lustre は全ノードで共有され、ノードを失ってもデータは残ります。全体の書き込みスループットの基準値は、確保したストレージ容量と、作成時に選ぶ容量 1 TiB あたりのスループットの積で決まります。後者を、コンソールではストレージ単位あたりのスループット、API では PerUnitStorageThroughput と呼びます。S3 は容量を事前に確保する必要がなく、ノードを失ってもデータは残ります。 保存の方式には、同期と非同期があります。同期では、ストレージへの書き込みが終わるまで学習を止めます。非同期では、状態を GPU のメモリからホストのメモリへコピーする間だけ学習を止め、ストレージへの書き込みは学習と並行して進めます。どちらの方式でも、書き込みが完了するまでそのチェックポイントは再開に使えず、その間にジョブが中断すると、直近の書き込みが完了したチェックポイントから再開します。 非同期で短くなるのは学習が止まる時間 C です。中断したときに失う学習の時間は、保存の開始から書き込みの完了までの時間 t で決まり、同じ書き込みスループットなら同期と非同期で t はほぼ同じです。非同期で書き込みにかける時間を長くとるほど t は延び、失う学習の時間は長くなります。 設定を決める量 この記事で決める設定は、保存の間隔、同期か非同期か、ストレージの書き込みスループットと容量です。保存の回数を増やすほど学習が止まる時間の合計が増え、減らすほど中断したときに失う学習が増えるので、これらは次の量の関係で決まります。 記号 意味 S 全ノードを合計した、1 回のチェックポイントの大きさ C 1 回の保存で学習が止まる時間。同期では書き込みの完了まで、非同期ではホストのメモリへのコピーの間 t_a 非同期で、学習を再開してから書き込みが完了するまでの時間。同期では 0 t 保存の開始から書き込みの完了までの時間で、t = C + t_a t_w ストレージへの書き込みにかける時間。同期では C、非同期では t_a T 保存の開始から次の保存の開始までの間隔 M ジョブの平均中断間隔。故障を含め、チェックポイントからの再開が必要になる中断の平均間隔 R 中断してから学習を再開するまでの時間 \eta 学習時間のうち、保存で止まる時間と中断で失う時間を合わせて無駄になる割合 T^{*} \eta が最も小さくなる保存間隔 図の下段に並べた 2 つの式は、\eta の近似式と、そこから求めた T^{*} です。どちらも「保存間隔の決め方」の節で導きます。 S を t_w の間に書き終えるには、ストレージが 1 秒あたり S/t_w 以上を書ける必要があります。これが必要な書き込みスループット W の最小値です。t_w は測る値ではなく、同期なら学習を止めてよい時間、非同期なら次の保存までに書き終える時間として、設計する側が決める値です。実際には、書き込みの効率やほかの I/O との競合を見込んで、これより大きく確保します。 W = \frac{S}{t_w} チェックポイントの大きさ 重みのバイト数 2026 年 11 月に Hugging Face の API で取得した Nemotron 3.5 Super の BF16 版の重みのファイルサイズの合計は約 248.9 GB で、総パラメータ数の約 124.5B で割ると 1 パラメータあたり 2.0 バイトです。 MoE（Mixture of Experts）は、expert と呼ぶ複数の部分ネットワークのうち、トークンごとに一部だけを使うモデルです。1 トークンの計算に使うパラメータを活性パラメータと呼び、モデル名の 120B-A12B は総パラメータ約 120B、活性パラメータ約 12B を表します。保存では使われなかった expert の重みも書き出すので、チェックポイントの大きさは活性パラメータ数ではなく総パラメータ数に比例します。 再開に必要な状態 故障による中断や手動での一時停止で学習を止めたあと、止めた地点から同じように学習を再開するには、重みに加えて、オプティマイザの状態も保存します。混合精度の学習では、計算用の bf16 の重みに加えて、更新の丸め誤差をためないための fp32 の重みを持ちます。この fp32 の重みを master weight と呼びます。オプティマイザに Adam を使う場合、1 パラメータあたりのバイト数は次のとおりです。 状態 バイト数 bf16 の重み 2 fp32 の master weight 4 fp32 の Adam の 1 次と 2 次のモーメント 8 合計 14 この内訳は、Megatron-LM の distributed optimizer のように、bf16 の重みと fp32 の master weight を別々に持つ構成の値です。ZeRO の論文は、fp16 の重みと勾配で同じバイト数の内訳を示していて、勾配の 2 バイトを含めると 16 バイトです。FSDP2 を使う TorchTitan のように、分割して持つ重み自体が fp32 で、bf16 の重みは計算の間だけ作る構成では、保存するのは fp32 の重みとモーメントの 4 + 8 = 12 バイトです。モーメントを bf16 で持つ構成では 2 + 4 + 4 = 10 バイトになります。DeepSeek-V3 の技術報告は、AdamW の 1 次と 2 次のモーメントを bf16 で持ち、master weight を fp32 で持つと書いています。bf16 の重みと bf16 のモーメントだけを持ち、fp32 の重みを持たない構成では 2 + 4 = 6 バイトです。どの値になるかはフレームワークと設定で決まるので、実際に 1 回保存して確かめます。再開には、学習率のスケジューラ、ステップ数、乱数生成器、データの読み取り位置などの状態も必要ですが、これらは重みとオプティマイザの状態に比べて小さいので、大きさの計算では数えていません。 Nemotron 3.5 Super の大きさ 試算に使う Nemotron 3.5 Super の総パラメータ数は約 124.5B で、この値には画像エンコーダーのパラメータも含まれます。1 パラメータあたりのバイト数ごとに、チェックポイントの大きさ S と、32 ノードに均等に分けたときの 1 ノードあたりの大きさは次のとおりです。 保存する状態 1 パラメータあたり S 1 ノードあたり bf16 の重みだけ 2 バイト 約 0.25 TB 約 7.8 GB 重みとオプティマイザの状態 14 バイト 約 1.74 TB 約 54 GB モーメントを bf16 にした場合 10 バイト 約 1.24 TB 約 39 GB bf16 の重みと bf16 のモーメントだけの場合 6 バイト 約 0.75 TB 約 23 GB 画像エンコーダーを凍結して学習するなら、そのパラメータはオプティマイザの状態を持たないので、bf16 の重みの 2 バイトだけを保存すれば足ります。公開されている例では、awsome-distributed-ai の verl の例が、20B のモデルを GPU 12 枚で学習すると 1 つのチェックポイントが約 117 GB になると書いています。以降の試算では 14 バイトの約 1.74 TB を使い、最後に 6 バイトの場合の結果も示します。 公開事例の保存間隔 保存の間隔についての公開情報は乏しく、モデルの技術報告にはほとんど書かれていません。後の節で見るとおり、フレームワークに既定値がある場合も、時間ではなくステップ数で決まっています。時間で間隔を書いている公開事例は、次の表のように少数です。 出典 間隔 補足 BLOOM 176B 3 時間ごと。学習ログによると、計算機の保守の停止に備えて 100 ステップごとに変更 Hugging Face のブログによると 1 回が 2.3 TB、学習ログによると保存は 40 秒 DeepSeek の Fire-Flyer AI-HPC 5 分 保存と読み込みはどちらも数秒 Meta の信頼性の論文 大規模ジョブの典型は 1 時間 1,024 GPU のジョブの平均故障間隔は 7.9 時間 Unicron 30 分。再計算の時間を比べるために論文が置いた値 128 GPU のクラスターでの評価 ジョブの平均中断間隔 保存の間隔は、1 回の保存で止まる時間と、ジョブがどのくらいの頻度で中断するかの両方で決まります。次の表は、公開されている故障や中断の記録を、1 ノードに GPU 8 枚を積んだ 32 ノードのジョブの平均中断間隔に換算した値です。中断がノード数に比例して起きると仮定し、元の平均間隔を M_0、元のノード数を N_0 として M = M_0 N_0 / 32 で計算しました。ノード数は、論文の GPU 数を 1 ノード 8 GPU として割った値です。元の論文が数えた範囲、たとえば対象のクラスターや期間の取り方で値は変わるので、表の値は目安です。数えている事象は出典ごとに違い、GPU の故障、ハードウェアが原因の再起動、原因を問わない中断が混ざっているので、比べるときは注意が必要です。 出典 規模と期間 32 ノードに換算した平均中断間隔 Meta の信頼性の論文 128 ノード、1,024 GPU のジョブで 7.9 時間 約 32 時間 OPT-175B 124 ノード、60 日とみなした 2 か月で、ハードウェアの障害による手動の再起動が少なくとも 35 回、自動の再起動が 70 回以上 105 回で約 53 時間、35 回で約 159 時間 BLOOM 48 ノードで、GPU の故障が週 1〜2 回 約 126〜252 時間 Llama 3 2,048 ノード、54 日で 466 回の中断。うち想定外が 419 回で、その約 78%、約 327 回がハードウェアの問題と確認されたか、そう疑われた中断 466 回で約 178 時間、419 回で約 198 時間、327 回で約 254 時間 MegaScale 10,000 GPU を超える本番の学習で、3 週間とみなした数週間に 100 回を超える再起動。1,250 ノードとして計算 約 197 時間。GPU 数も回数も「超える」なので目安 Acme 588 ノード、182.5 日とみなした 6 か月で、ハードウェアが原因の故障が 103 件 約 781 時間 ネットワークの障害や、複数のノードがまとめて故障する場合があるので、ノード数に比例させる換算は目安です。ジョブの中断には GPU の故障のほかにネットワークやソフトウェアの障害も含まれるので、GPU の故障率だけからは M を決められません。参考として、NCSA Delta の研究は、GPU 1 枚あたりのメモリエラーの平均間隔を H100 で約 88,768 時間、A100 で約 283,271 時間と報告しています。B200 と B300 の故障率は公開されていません。 保存間隔の決め方 Young の式 保存間隔 T は、学習が止まる時間と、中断で失う学習の時間の合計が最も小さくなるように決めます。学習時間のうち無駄になる割合を \eta とすると、次の式で近似できます。 \eta \approx \frac{C}{T} + \frac{T/2 + t + R}{M} 第 1 項は、保存で学習が止まる分です。間隔 T ごとに C だけ止まるので、止まる割合は C/T です。 第 2 項は、中断で失う分です。1 回の中断で失う時間の期待値を T/2 + t + R とし、中断が平均 M に 1 回起きるので M で割ります。ここで t は、保存を始めてから書き込みが終わり、そのチェックポイントが再開に使えるようになるまでの時間です。 ! ここからの導出は、確率変数と期待値を使います。数理統計になじみがない方は、導出を飛ばして「1 回の中断で失う時間の平均は T/2 + t になる」という結論だけを眺めても、この先を読み進められます。内容は統計検定 2 級くらいなので、学んでおくと性能の見積もりなどいろいろな場面で役に立ちます。 T/2 + t は、次のように求まります。直近の保存を始めた時刻から中断までの経過時間を連続型の確率変数 X とし、中断は間隔のどこでも同じように起きる、つまり X が区間 [0, T) の連続一様分布に従うと仮定します。また、保存は予定どおり t < T で書き終わり、C は T より十分短いとします。 X \sim \mathrm{U}(0, T), \qquad E[X] = \frac{T}{2}, \qquad P(X < t) = \frac{t}{T} X \ge t なら直近の保存は書き終わっているので、やり直すのは X だけです。X < t なら直近の保存はまだ使えないので、1 つ前の保存まで戻り、さらに間隔 1 つ分の T をやり直します。やり直す時間を L とすると、指示関数 \mathbf{1}{X < t} を使って次のように書けます。 L = X + T \cdot \mathbf{1}{X < t} 期待値をとると、次のようになります。 E[L] = E[X] + T \cdot P(X < t) = \frac{T}{2} + T \cdot \frac{t}{T} = \frac{T}{2} + t 最悪の場合は X が t の直前のときで、L は T + t に近づきます。 これに再開までの時間 R を足したものが、1 回の中断で失う時間です。たとえば T が 45 分、t が 5 分なら、学習のやり直しは平均 22.5 分 + 5 分 = 27.5 分、最悪で 45 分 + 5 分 = 50 分です。 t と R が T によらないとすると、右辺を T で微分して 0 と置いた -C/T^2 + 1/(2M) = 0 から、最適な間隔は次のようになります。 T^{*} \approx \sqrt{2\,C\,M} この式は Young が 1974 年に示したもので、C \ll T \ll M のときに成り立ちます。C が M に比べて無視できない場合の補正は、Daly が 2006 年に加えています。 ! Young の式と Daly の補正は、HPC のチェックポイント研究で古くから使われてきた式です。もともとは、スーパーコンピューターで長時間の計算を故障に備えてどの間隔で保存するかを決めるためのものでした。大規模な LLM の学習でも同じ考え方が使われていて、Meta の信頼性の論文もこの形の式で保存の間隔を見積もっています。 M は、Llama 3 の換算値の約 178〜254 時間の範囲にある 200 時間とし、R は 15 分とします。 方式 M C t T^{*} \eta 同期 200 時間 5 秒 5 秒 約 45 分 約 0.50% 同期 200 時間 60 秒 60 秒 約 2.6 時間 約 1.42% 同期 200 時間 300 秒 300 秒 約 5.8 時間 約 3.05% 非同期 200 時間 5 秒 5 分 5 秒 約 45 分 約 0.54% 同期 約 32 時間 5 秒 5 秒 約 18 分 約 1.72% 同期 約 781 時間 5 秒 5 秒 約 88 分 約 0.22% 最後の 2 行は、M を前の節の表で最も短い Meta の換算値と、最も長い Acme の換算値にした場合で、T^{*} は M によって大きく変わります。 式の前提 この式は、故障が互いに独立で、故障の起きやすさが時間によらないこと、つまり故障間隔が指数分布に従うことを前提にしています。Aupy らの論文が引く Heien らの測定では、HPC システムの故障間隔は形状パラメータ 0.58〜0.71 の Weibull 分布に当てはまりました。Weibull 分布は、形状パラメータが 1 のとき指数分布と同じになり、1 より小さいほど故障の直後に次の故障が集中します。同じ論文は、形状パラメータ 0.5、2^{19} プロセスのシミュレーションで、Daly の式の間隔を使うと、論文が提案する間隔の場合より実行時間が約 61%、Young の式では約 50% 長くなったと報告しています。 平均中断間隔も一定ではないので、運用中に記録した中断から M を更新して、間隔を見直します。評価の節目、損失が急に悪化したときの巻き戻し、予約した計算資源の期限などでもチェックポイントから再開するので、これらの時刻に合わせて保存する場合もあります。 フレームワークの既定値 Megatron-LM、それを継承する Megatron Bridge、TorchTitan では、非同期の保存は既定で無効です。有効にしなければ同期で保存され、書き込みが終わるまで学習は止まります。次の表は、2026 年 10 月に取得したコミットのソースコードで確かめた既定値で、リンク先はそのコミットの該当行です。 フレームワーク 保存間隔の既定 非同期保存の既定 Megatron-LM 既定値はなしで、保存先を指定すると間隔の指定が必須 無効。分散チェックポイント形式で --use-persistent-ckpt-worker を指定しないと、有効にしても無効に戻される Megatron Bridge Megatron-LM の設定を継承 Megatron-LM の設定を継承するので無効。async_save で有効にする TorchTitan 500 ステップ 無効 Hugging Face Trainer 500 ステップ 非同期保存の機能はなく、save_steps ごとに同期で保存 ローカル NVMe と複製 前の節の非同期保存を一歩進めると、チェックポイントを短い間隔で各ノードのローカル NVMe に書き、共有ストレージへは長い間隔で書く方法があります。ローカル NVMe は書き込みが速いので、学習が止まる時間と、共有ストレージに必要な書き込みスループットを小さくできます。弱点は、そのノードを失うとローカルに書いた分も失うことです。NVIDIA Resiliency Extension は、このローカルへの保存を提供するライブラリで、ほかのノードに複製を持って冗長性を高める仕組みも備えています。ローカルに書いたチェックポイントを共有ストレージへ移す処理は含まず、共有ストレージへの保存は、通常のチェックポイントとして別に行います。この節では、この方法で何を守れて何を守れないかを整理します。次の図は、保存先ごとに、プロセスの再起動、1 ノードの喪失、クラスター全体の停止のあとでデータが残るかを示しています。 NVIDIA B300 を 8 枚積んだ p6-b300.48xlarge には、3,800 GB の NVMe SSD が 8 本、合計 30,400 GB のインスタンスストアがあり、1 ノードあたり約 54 GB のシャードを何世代分も置けます。共有ストレージへの転送が終わるまでは、そのノードが使えなくなるとシャードを失います。 NVIDIA Resiliency Extension のローカルチェックポイントは、Megatron-LM などの学習ループに組み込んで使い、各ノードの SSD か RAM ディスクに保存し、ほかのノードにも複製を持つことで、1 ノードを失っても複製からシャードを復元します。複製の組み方は設定で決め、保存と再開で同じ設定にする必要があります。 NVIDIA Resiliency Extension は、GPU 1 枚を受け持つプロセスであるランクを組にして、組の中で複製を持ち合います。組の作り方は、組の大きさ F と、組の中のランクの間隔 J の 2 つの設定で決まり、それぞれ replication_factor と replication_jump です。J の既定値は 1 ノードの GPU 数なので、組のランクは別々のノードに置かれ、組の中の F ノードが互いの分の複製をすべて持ちます。複製は既定では無効で、Megatron-LM では --replication で有効にします。F の既定値は NVIDIA Resiliency Extension でも Megatron-LM でも 2 です。ランクの総数が J \times F で割り切れないと、組を作る処理が止まります。p6-b300.48xlarge 32 台ではランクの総数が 256、J が 8 なので、F に使えるのは 1、2、4、8、16、32 です。 組を持っていても、故障したノードの分の複製を作り直す前に、同じ組のほかのノードもすべて失われると、そのシャードは失われます。この確率を、組に固定する NVIDIA Resiliency Extension の置き方と、比較のために複製先をランダムに選ぶ置き方で比べます。前提は次のとおりです。 前提 内容 ノード数 32 組の大きさ F 既定値の 2。原本を含めて 2 か所に置く 最初の故障 ノード A が故障する \Delta A の分の複製を作り直すまでの時間。例では 1 時間 M_n 1 ノードが失われてインスタンスストアのデータが読めなくなる平均間隔。例では 6,400 時間で、ジョブの中断がすべてノードの喪失によるとした多めの見積もり p ほかの各ノードが \Delta の間に失われる確率で、p \approx \Delta / M_n。例では約 0.016% 独立性 ほかのノードは互いに独立に失われる シャードの数 A が持つシャードは十分に多い 組に固定する場合 F = 2 では、A と組になるノード B が、A のシャードの複製をすべて持ちます。A のシャードを失うのは、B が \Delta の間に失われるときだけなので、確率は次のとおりです。 P_{\text{組}} = p 複製先をランダムに選ぶ場合 A の各シャードの複製を、ほかの 31 ノードからランダムに選んだ 1 台に置くとします。シャードが十分に多いと、31 ノードのどれにも A のどれかのシャードの複製があります。そのため、31 ノードのどれか 1 台が \Delta の間に失われれば、A のシャードのどれかを失います。31 台のどれも失われない確率は、各ノードが独立に確率 1 - p で残るので (1 - p)^{31} です。A のシャードを失う確率はその余事象なので、次のようになり、p が小さければ 31p で近似できます。 P_{\text{ランダム}} = 1 - (1 - p)^{31} \approx 31\, p 近似は、(1 - p)^{31} を二項定理で展開し、p が小さいときに p^2 以降の項を捨てたものです。 (1 - p)^{31} = 1 - 31p + \binom{31}{2}p^2 - \binom{31}{3}p^3 + \cdots \approx 1 - 31p 31p は、31 台それぞれが失われる確率 p を足した値です。2 台以上が同時に失われる場合を重ねて数えていますが、p が小さければその分は無視できます。前提の表の例の値では、正確な値が約 0.4832%、近似が約 0.4844% です。 前提の表の例の値を入れると、組に固定する場合は約 0.016%、ランダムに置く場合は約 0.48% で、ランダムに置くと約 31 倍になります。例の M_n は、ジョブの平均中断間隔 200 時間を 32 倍した値です。F を 4 にすると、組に固定する場合は組のほかの 3 台がすべて失われるときだけなので p^3、ランダムでは、シャードが十分に多く 3 台の組み合わせのどれにも複製があるとして、p が小さいときの近似で \binom{31}{3} p^3 = 4{,}495\, p^3 になり、どちらも桁違いに小さくなります。その代わり、各ノードが持つ複製の量は F に比例して増えます。 チェックポイントは、シャードが 1 つでも欠けると再開に使えません。そのため、ある世代のシャードを 1 つ失っても全部失っても、その世代は同じように使えなくなります。複数の世代を同じ組に置いている場合は、組を失えばそれらの世代をまとめて失い、共有ストレージにある世代まで戻ります。どちらの置き方でも失う世代の数は同じなので、確率が低い、組に固定する置き方のほうが有利です。置き方によってデータを失う組み合わせの数が変わることは、Copysets の論文が分散ストレージについて示しています。 この計算は故障が独立だという前提に立っているので、ラックや電源の障害で複数のノードがまとめて止まる場合や、クラスター全体が止まる場合には当てはまりません。その場合に備えて、FSx for Lustre か S3 にもコピーを置きます。 データが通る経路 チェックポイントのデータは、GPU のメモリからホストのメモリを経て、ローカル NVMe か、ネットワークインターフェースを通って共有ストレージへ書かれます。経路の途中にはそれぞれ上限があり、いちばん低い上限が書き込みスループットを決めます。 ローカル NVMe は PCIe でつながったノード内のディスクなので、ネットワークの帯域は効かず、ディスクの性能で決まります。S3、S3 Files、EFA を使わない FSx for Lustre は、ENA というネットワークインターフェースで TCP を使って通信します。EFA は、OS を通らずに SRD というプロトコルで通信するネットワークインターフェースで、EFA を有効にした FSx for Lustre との通信や、ノード間の集団通信に使います。 ネットワークインターフェースの帯域は、インスタンスの種類で大きく違います。 インスタンス ネットワークインターフェースの帯域 c6in.2xlarge 最大 40 Gbps、基準値 12.5 Gbps g6e.12xlarge 100 Gbps p6-b300.48xlarge 1 枚目のネットワークカードが 350 Gbps、ほかに 400 Gbps のネットワークカードが 16 枚あり、16 枚の合計は 6,400 Gbps TCP には、インスタンスの帯域とは別の上限もあります。EC2 の文書によると、同じクラスタープレイスメントグループにない相手との 1 本の TCP 接続は 5 Gbps までです。同じグループの中では 10 Gbps、同じ AZ で ENA Express を使えば 25 Gbps まで上がりますが、いずれにしても 1 本の接続には上限があります。S3 の性能のガイドラインも、多数の接続に分けて並列に送ることを勧めています。FSx for Lustre の文書は、クライアント 1 台あたりの最大スループットを、EFA を使わない場合は 100 Gbps、EFA では 700 Gbps、EFA と GPUDirect Storage では 1,200 Gbps としています。ENA で TCP を使う場合のもう 1 つの上限は、次の節で説明します。 FSx for Lustre の容量と書き込みスループット FSx for Lustre の SSD を使う Persistent 2 では、ディスクのスループットの基準値は確保したストレージ容量とストレージ単位あたりのスループットの積で決まり、ストレージ単位あたりのスループットは 125、250、500、1,000 MB/s/TiB から選びます。料金は使用量ではなく確保した容量にかかり、ストレージ容量の文書にあるとおり、容量は増やせますが減らせません。 容量は GiB で指定し、EFA を使わない場合は 1,200 GiB も選べます。それより大きい容量の単位はストレージサーバー 1 台あたりの容量で決まります。EFA を使わない場合は 2,400 GiB、EFA を使う場合は 125 MB/s/TiB で 38,400 GiB、250 MB/s/TiB で 19,200 GiB、500 MB/s/TiB で 9,600 GiB、1,000 MB/s/TiB で 4,800 GiB です。スループットの計算では、AWS の文書の例に合わせて 1,000 GiB を 1 TiB として扱います。EFA を使うファイルシステムは、スループットが 10 GB/s を超える場合に推奨されていて、作成後に EFA の有無もストレージ単位あたりのスループットも変えられません。EFA を使わない SSD のファイルシステムは、作成後にストレージ単位あたりのスループットを変更できます。 ストレージ単位あたりのスループットは、ディスクのスループットの基準値です。性能の表によると、125 MB/s/TiB と 250 MB/s/TiB には、ディスクのスループットを一時的に 500 MB/s/TiB まで上げるバーストがあり、500 MB/s/TiB と 1,000 MB/s/TiB にはありません。また、ENA で TCP を使って通信する場合、クライアント 1 台とストレージサーバー 1 台の間のトラフィックは 5 Gbps が上限なので、1 台のクライアントが書けるのは、ストレージサーバーの台数に 5 Gbps を掛けた値までです。 Nemotron 3.5 Super の S を 1.74 TB とすると、ストレージへの書き込みにかける時間 t_w ごとに必要な書き込みスループット W = S / t_w は次のとおりです。 t_w W 300 秒 約 5.8 GB/s 60 秒 約 29 GB/s 20 秒 約 87 GB/s 同期で保存するなら t_w がそのまま学習の止まる時間 C になるので、C を短くするほど確保する容量と料金が増えます。非同期なら C と t_w を別々に決められます。前回の書き込みが次の保存の開始までに終わっていない場合の動きは、フレームワークで違います。TorchTitan は前回の書き込みが終わるまで待つので、その分だけ学習が止まります。Megatron-LM と Megatron Bridge は警告を出して次の保存を始めるので、学習は止まりませんが、書き終わっていない書き込みが積み重なります。どちらでも重なりを避けるには W \ge S/(T - C) が必要で、T が約 45 分なら約 0.65 GB/s が下限です。t_w を長くすると W は小さくなりますが、t が延びるので中断で失う学習の時間 T + t と \eta は大きくなります。ローカルの NVMe を経由して共有ストレージへ転送する場合も、次の保存までに転送を終える必要があるので、平均で S/T 以上の書き込みスループットが要ります。 ! コラム: 保存で止まる GPU 時間と FSx for Lustre の料金のトレードオフ 同期で保存する場合、C を短くすると FSx for Lustre の料金は増えますが、保存で止まる GPU の時間は減ります。1 年間の学習で両者を比べると次のとおりです。前提は、S が 1.74 TB、p6-b300.48xlarge 32 台、M が 200 時間、T を Young の式で \sqrt{2CM} に置くことです。GPU の時間は、1 年の 8,760 時間に止まる割合 C/T を掛け、2026 年 11 月時点の p6-b300.48xlarge のオレゴンのオンデマンド料金、1 時間 142.416 ドルで金額にしました。FSx for Lustre は、各 C で最も安い構成の月額の 12 か月分で、必要な書き込みスループットが 10 GB/s を超える場合は EFA を使う構成にしています。 C 止まる GPU 時間/年 その金額/年 FSx for Lustre/年 合計/年 30 秒 約 10,200 GPU 時間 約 18.2 万ドル 約 44.9 万ドル 約 63.1 万ドル 60 秒 約 14,500 GPU 時間 約 25.8 万ドル 約 24.2 万ドル 約 50.0 万ドル 120 秒 約 20,500 GPU 時間 約 36.4 万ドル 約 13.8 万ドル 約 50.3 万ドル 300 秒 約 32,400 GPU 時間 約 57.6 万ドル 約 4.9 万ドル 約 62.5 万ドル 実際には GPU は年単位で確保していることが多く、保存で止まっても GPU の支払いは変わりません。その場合、止まる GPU 時間の金額は、その時間で行えたはずの追加の学習を金額に換算した機会費用として読みます。この考え方では、合計は C が 90 秒前後で最も小さく、年に約 46 万ドルです。この比較は保存で止まる時間だけを数えています。中断で失う学習も GPU 時間なので、それも足すと合計は年に約 76 万ドルになり、最も小さくなる C は 50 秒前後に移ります。C を短くしすぎると FSx for Lustre の料金が、長くしすぎると止まる GPU の時間が、合計を押し上げます。GPU の単価が予約や個別の価格で下がれば、最も小さくなる C は長い側へ動きます。非同期で保存できるなら、止まる時間はホストのメモリへのコピーの間だけになります。書き込みにかける時間は学習を止めずに長くとれるので、FSx for Lustre の料金と、中断で失う学習の時間の釣り合いだけで決められ、止まる GPU 時間の費用を小さくできます。Megatron-LM では分散チェックポイント形式と常駐の保存ワーカーが条件になるので、使っているフレームワークで有効にできるなら、非同期で保存するのがよいと考えます。 確保する容量は、残す世代数を k、ストレージ単位あたりのスループットを \tau、容量の単位を u として、次の式で決まります。容量は GiB で比べ、kS はバイト数を 2^{30} で割って GiB にし、W/\tau は MB/s を MB/s/TiB で割った値を 1,000 倍して GiB とします。 \text{確保する容量} = u \left\lceil \frac{\max\left(k S,\ W/\tau\right)}{u} \right\rceil Nemotron 3.5 Super で FSx for Lustre を見積もる 見積もりは、チェックポイントの設定を決め、そこから FSx for Lustre に必要な書き込みスループットと容量を逆算し、最も安い構成の月額を求める順に進めます。式はこれまでの節で説明したとおりで、計算の過程はこの節の最後の折りたたみにまとめました。 見積もる人が決める値 次の値を決めれば、見積もりができます。既存の環境で測れる値は測り、測れない値は右の概算から始めます。 値 決め方 測れないときの概算 この例の値 総パラメータ数 モデルの定義から読む なし 約 124.5B 1 パラメータあたりのバイト数 小さい構成で 1 回保存し、チェックポイントの大きさを総パラメータ数で割る bf16 の重み、fp32 の master weight、fp32 のモーメントなら 14、fp32 の重みとモーメントなら 12、モーメントが bf16 なら 10 14 ノード数 学習の計画から決める なし 32 同期か非同期か 使うフレームワークで非同期を有効にできるかで決める なし 非同期 保存で止まる時間 C 1 回保存し、学習のステップが止まった時間を測る 非同期は 1 ノード分を GPU からホストへ写す時間で、MegaScale と Fire-Flyer はどちらも数秒と報告している。同期は t_w と同じ 5 秒程度 書き込みにかける時間 t_w 予算と、中断で失ってよい学習の時間から決める なし 5 分または 20 分 平均中断間隔 M 既存のクラスターのジョブの中断を記録する ジョブの平均中断間隔の節の表から選ぶ 200 時間 再開までの時間 R 中断から再開までを 1 回試して測る 10 分にチェックポイントの読み込み時間を足す 約 15 分。FSx for Lustre の構成で変わる 残す世代数 k 何世代前まで戻れればよいかで決める 完了した 3 世代と書き込み中の 1 世代 4 EFA を使うか 必要な書き込みスループットが 10 GB/s を超えるなら、AWS の推奨に合わせて使う なし 使わない 料金 使うリージョンの料金ページで確かめる なし オレゴン 見積もりの結果 左のグラフは、書き込みにかける時間 t_w ごとに、FSx for Lustre の最も安い構成の月額を示します。右のグラフは、同じ t_w で、同期と非同期それぞれの無駄になる割合 \eta を示します。 t_w を延ばすほど必要な書き込みスループットが下がり、FSx for Lustre は安くなります。容量が残す世代を置く量で決まるところまで下がると、それ以上は安くなりません。 EFA を使う構成は容量の単位が大きいので、同じ書き込みスループットなら、EFA を使わない構成と同じか高くなります。10 GB/s を超える範囲では、AWS の推奨に合わせて EFA を使う構成で計算しています。 同期では t_w がそのまま学習の止まる時間になるので、\eta は t_w とともに急に増えます。非同期では止まる時間が数秒のままなので、t_w を延ばしても \eta はゆっくりしか増えません。 主な組み合わせの結果は次のとおりです。「最も安い構成」の列は、FSx for Lustre を作るときに選ぶ 2 つの値で、たとえば「250 MB/s/TiB、7,200 GiB」は、ストレージ単位あたりのスループットを 250 MB/s/TiB に、ストレージ容量を 7,200 GiB にすることを意味します。この構成の書き込みスループットの基準値は、7,200 GiB を 7.2 TiB として 250 MB/s/TiB を掛けた 1.8 GB/s です。250 MB/s/TiB 以下ではバーストで一時的にこれを超えられますが、見積もりでは基準値を使います。容量は、必要な書き込みスループットから出る容量と、残す世代を置く容量の大きいほうで決まるので、世代を置く容量で決まった場合は、基準値が必要な書き込みスループットより大きくなります。 チェックポイントの設定 必要な書き込みスループット 最も安い構成 書き込みスループットの基準値 容量を決めたもの 月額 \eta 14 バイト、非同期、20 分で書き終える 約 1.45 GB/s 250 MB/s/TiB、7,200 GiB 1.8 GB/s 世代を置く容量 約 1,500 ドル 約 0.76% 14 バイト、非同期、5 分で書き終える 約 5.8 GB/s 500 MB/s/TiB、12,000 GiB 6.0 GB/s 書き込みスループット 約 4,100 ドル 約 0.54% 6 バイト、非同期、5 分で書き終える 約 2.5 GB/s 500 MB/s/TiB、7,200 GiB 3.6 GB/s 書き込みスループット 約 2,400 ドル 約 0.53% 14 バイト、同期、60 秒で書き終える 約 29 GB/s EFA あり、1,000 MB/s/TiB、33,600 GiB 33.6 GB/s 書き込みスループット 約 20,200 ドル 約 1.39% この例では、非同期で 45 分ごとに保存し、20 分で書き終えればよいとすると、250 MB/s/TiB の 7,200 GiB、月額約 1,500 ドルで予算を見積もれます。中断で失う学習を減らしたい場合は、書き終える時間を 5 分に縮めて月額約 4,100 ドルで見積もります。 計算の過程: 14 バイト、非同期、5 分で書き終える場合 ノード数を N、総パラメータ数を P、1 パラメータあたりのバイト数を b とします。 チェックポイントの大きさと 1 ノードあたりの大きさ S = P \times b = 124.45 \times 10^{9} \times 14 \approx 1.74\ \text{TB}, \qquad \frac{S}{N} = \frac{1.74\ \text{TB}}{32} \approx 54\ \text{GB} 保存で止まる時間 C を 5 秒にするのに必要な、1 ノードあたりの GPU からホストへの転送 \frac{S/N}{C} = \frac{54\ \text{GB}}{5\ \text{s}} \approx 11\ \text{GB/s} 保存間隔 T^{*} = \sqrt{2CM} = \sqrt{2 \times 5\ \text{s} \times 720{,}000\ \text{s}} \approx 2{,}683\ \text{s} \approx 45\ \text{min} 必要な書き込みスループット W = \frac{S}{t_w} = \frac{1.74\ \text{TB}}{300\ \text{s}} \approx 5.8\ \text{GB/s} 確保する容量。kS を GiB にし、W/\tau は MB/s を MB/s/TiB で割った値を 1,000 倍して GiB にします。\tau = 500 MB/s/TiB、u = 2{,}400 GiB では次のとおりです。 kS = \frac{4 \times 1.742\ \text{TB}}{2^{30}} \approx 6{,}491\ \text{GiB}, \qquad \frac{W}{\tau} \times 1{,}000 = \frac{5{,}808}{500} \times 1{,}000 \approx 11{,}616\ \text{GiB} u \left\lceil \frac{\max(6{,}491,\ 11{,}616)}{2{,}400} \right\rceil = 2{,}400 \times 5 = 12{,}000\ \text{GiB} 月額。オレゴンの 500 MB/s/TiB の料金は GiB 月あたり 0.340 ドルです。 12{,}000\ \text{GiB} \times 0.340\ \text{USD} = 4{,}080\ \text{USD/month} 再開までの時間と無駄になる割合。この構成のスループットの基準値は 12{,}000 / 1{,}000 \times 500 = 6{,}000 MB/s で、読み込みも同じ程度出ると仮定すると、約 290 秒です。 R = 600 + \frac{1.74\ \text{TB}}{6.0\ \text{GB/s}} \approx 890\ \text{s}, \qquad t = C + t_w = 305\ \text{s} \eta = \frac{C}{T} + \frac{T/2 + t + R}{M} = \frac{5}{2{,}683} + \frac{1{,}341 + 305 + 890}{720{,}000} \approx 0.54\% 中断で失う学習の時間の上限は、T + t \approx 2{,}683 + 305 \approx 2{,}988 秒、約 50 分です。 ほかのストレージ単位あたりのスループットと EFA の有無で同じ計算をすると、次のようになります。 ストレージ単位あたりのスループット EFA なし EFA あり 125 MB/s/TiB 48,000 GiB、約 7,000 ドル/月 76,800 GiB、約 11,100 ドル/月 250 MB/s/TiB 24,000 GiB、約 5,000 ドル/月 38,400 GiB、約 8,100 ドル/月 500 MB/s/TiB 12,000 GiB、約 4,100 ドル/月 19,200 GiB、約 6,500 ドル/月 1,000 MB/s/TiB 7,200 GiB、約 4,300 ドル/月 9,600 GiB、約 5,800 ドル/月 まとめ FSx for Lustre をできるだけ安く見積もるには、先にチェックポイントの大きさ、保存間隔、書き込みにかける時間を決め、そこから必要な書き込みスループットと容量を逆算します。Nemotron 3.5 Super を 32 ノードで学習する例では、非同期で 45 分ごとに保存し、20 分で書き終えればよいとすると、250 MB/s/TiB の 7,200 GiB、月額約 1,500 ドルで足ります。書き込みにかける時間を延ばすほど FSx for Lustre は安くなりますが、中断で失う学習と再開の時間は延びるので、その釣り合いで決めます。ここでの値はどれも試算なので、実際の構成で保存と再開の時間、中断の頻度、書き込みスループットを測って置き換えてください。