# チェックポイント ## 定義 チェックポイント(checkpoint)とは、計算状態を周期的に保存し、障害発生時に直近の保存点から復旧する耐障害手法。大規模 LLM 訓練では障害頻度が高く([[耐障害LLM訓練]])、高頻度チェックポイントが信頼性の要となる一方で、保存コスト(時間・帯域・ストレージ)が問題になる。GPU カーネルの実行系では、再実行しても結果が変わるカーネルの状態を守るためにチェックポイントが必要になる。([[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) ## 横断的知見 - **DLモデルアーキテクチャ（Transformer vs CNN）によってチェックポイントのメタデータ感度は2.3倍異なり、最適チェックポイント間隔とオブジェクトチャンクサイズに大きな差異を生む**: チェックポイントの頻度とオーバーヘッドの議論において、[[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]] はMLPerf Storageを用いてTransformer（BERT）とCNN（ResNet-50）のストレージ感度を比較した。Transformerはメタデータ性能に対する感度がCNN比で2.3倍高く、より高頻度かつ小刻みなチェックポイント（最適間隔173秒、CNNは215秒）を要求する。また、LustreからMinIOオブジェクトストレージへオフロードする際のチャンクサイズを16〜32MBに設定することでチェックポイント遅延を41%削減できるなど、単一の静的チェックポイント戦略ではなくモデル認識型の動的パラメータ調整が訓練時間の短縮（12〜15%）に不可欠であることを示している。(Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]]) - **チェックポイント対象を絞り込む「何を保存しないか」の方向は、エッジ環境でも有効である**: LLM訓練では[[べき等性]]を持つカーネルをスキップする方向(PICKER、FlashRecovery)が示されているが、エッジクラウド間のWasmマイグレーションでは、OSカーネルのdirty memory検出を用いて使用済みメモリ領域のみを保存することで、CRIUと比較して30〜100倍のチェックポイント時間短縮とサイズ削減を達成した。「保存しない」対象は計算特性だけでなく、メモリ使用パターンにも依存する。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]]) - **ランタイム中立チェックポイントは、チェックポイントを「同種環境の復旧」から「異種ランタイム間の移行」へ拡張する**: EdgeSys ’24 と CANDARW 2025 は、プログラムカウンタ・スタック・メモリ・グローバル変数などをランタイム非依存表現に変換することで、WasmEdge と WAMR のような異なるランタイム間でチェックポイントを復元可能にした。これは、チェックポイントが障害復旧のための同一環境ロールバックに留まらず、性能とリソース効率の最適化を目的とした異種環境間マイグレーションにも使えることを示す。(Source: [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]], [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]]) - **データベース復旧でのトランザクション整合チェックポイントは LLM 訓練チェックポイントと同型の設計だが意味論が異なる**: VoltDB のノンブロッキング・トランザクション整合チェックポイント([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])は、スナップショット取得中もトランザクションを継続実行し(コピーオンライト機構)、コミット済みトランザクションのみを反映する。これは MegaScale の 2 段階チェックポイント([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])と「バックグラウンドで非同期に保存し、フォアグラウンドの処理を止めない」という構造で類似する。ただし前者は ACID の耐久性保証が目的であり、後者は訓練再開ポイントの保存が目的である。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **異種 interpreter 間の checkpoint では、実行点とスタックレイアウトの抽象化が必要である**: APSys 2024 の予備研究は、WasmEdge (standard interpreter) と WAMR・Wasm3 (fast interpreter) の間で checkpoint/restore を行うために、プログラムカウンタを相対アドレスに変換し、バリュースタックを型情報付きで変換する。これは、checkpoint が「同じプロセス・同じバイナリでの復旧」から「異なる実行実装間での復旧」へ拡張する際に、抽象化レベルを下げる必要があることを示す。(Source: [[@2024__APSys__A Checkpoint-Restore Mechanism with Interoperability Among Distinctive WebAssembly Interpreters]]) - **「何を保存しないか」でチェックポイントコストを攻める**: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](PICKER)は、[[べき等性]]を持つカーネルインスタンスはチェックポイント不要という発想で、耐障害システム Asymmetric Resilience のチェックポイントコストを 4% 未満に削減する。チェックポイント最適化が「速く保存する」だけでなく「保存対象を減らす」方向にも開けることを示す。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **FFTrainer が示す「第 5 の道」——遊休ネットワーク帯域を使って毎イテレーションにチェックポイントを無料化する**: [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]](FFTrainer)は、大規模訓練クラスタのネットワーク平均使用率が 1〜3% に過ぎないという観察から出発し、**Checkpoint Razor**(データ並列冗長を除去しチェックポイントサイズを 90% 削減)と **Neighboring Redundancy**(隣接ワーカーのメモリへ遊休帯域でストリーミング)を組み合わせることで、毎イテレーションのチェックポイントを通常訓練オーバーヘッド 3% 未満で実現する。FCR(Free Checkpointing Ratio)= `sbV/(2C)` ≥ 1 のとき計算時間がチェックポイント転送時間を完全に隠蔽し、現実的な設定で広く成立する。ディスクへの書き込みを回避することで専用ストレージネットワークも不要にした。(Source: [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]]) - **FFTrainer の「第 5 の道」の起源は 2 年早い [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]](SOSP '23)にある**: Gemini はネットワーク遊休時間帯を利用して訓練通信とチェックポイント通信をパイプライン化するアイデアを 2023 年に確立し、GPU マシンの CPU メモリへ毎イテレーションチェックポイントすることで既存手法比 13 倍超の障害復旧高速化を達成した。FFTrainer(2025)の「遊休ネットワーク帯域の利用」という出発点は、Gemini の §5(Minimizing Training Interference)がすでに定式化していた設計と本質的に同型である。両者の違いは、Gemini がチェックポイント配置の最適性を確率的に証明する理論(Theorem 1・Corollary 1)とチェックポイントのチャンク分割パイプラインアルゴリズム(Algorithm 2)を先に確立したのに対し、FFTrainer はデータ並列冗長除去(Checkpoint Razor)とロール/ランク分離(LCCL)という復旧手順自体の並列化に踏み込んだ点にある。同一の設計系統(訓練ネットワークの遊休帯域を保存経路に転用する)が独立した課題(チェックポイント配置の最適性 vs MTTR の秒単位短縮)に取り組む過程で 2 年越しに深化した例。(Source: [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]], [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]]) - **チェックポイントコスト削減には 4 つの方向がある(速く保存/予備機で待たない/そもそも保存しない/複製で保存不要化)**: 既存ソースを並べると、(1)**速く保存する**——[[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] は 2 段階チェックポイント(ホストメモリへの数秒書き込み + 非同期 HDFS 転送)で保存コストを隠す、(2)**予備機で待たない**——[[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]](ByteRobust)は warm standby と迅速な隔離で復旧の調整時間を縮める、(3)**そもそも保存しない**——PICKER はべき等カーネルのチェックポイントを省く。これらに対し [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] は **第 4 の道=データ並列の複製を冗長として周期チェックポイント自体を不要化(k0 = 0)**を加える。データ並列度 N のとき各デバイスに N−1 個のモデル状態の複製があり、障害時は同一データ並列グループの正常デバイスから集合通信で復元する。復旧損失は最大 1 ステップに限定され、定期チェックポイントの I/O オーバーヘッドを原理的に排除する。(Source: [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **複製冗長とチェックポイントは置換でなく相補**: FlashRecovery は周期チェックポイントを不要化する一方で、同一データ並列グループの N デバイスが同時に全滅するとモデル状態が失われるため、その稀な場合にはチェックポイントへの退避が要ると自ら認める(同時故障確率はデバイス故障率 0.001・N=4 で $0.001^N = 10^{-12}$ と極小だが 0 ではない)。PICKER がべき等カーネルに限ってチェックポイントを省くのと同型で、「保存不要化」はあくまで条件付きであり、最後の砦としてのチェックポイントは残る——複製冗長はチェックポイントの**頻度を下げる**機構であって完全な代替ではない。(Source: [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) - **チェックポイントの概念的起源は Gray 1985 の状態チェックポイント型[[プロセスペア]]にある**: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]] は 5 種のプロセスペアのうち、状態チェックポイント・自動チェックポイント・デルタチェックポイントの 3 種が「主プロセスの状態をバックアップに転送して障害時に引き継ぐ」設計であると整理した。Gray は最終的に永続プロセスペア(バックアップが健忘状態で起動) + トランザクション UNDO を推奨したが、現代の LLM 訓練チェックポイントは、状態を永続ストレージに保存して障害時にロールバックする点で、Gray の状態チェックポイント型とトランザクション型の組合せに位置づけられる。「性能は良好だがプログラミングが困難」というデルタチェックポイントの評価は、現代の非同期・2 段階チェックポイント設計の動機と通底する。(Source: [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **チェックポイント頻度は障害率とクラスタ規模から逆算される設計変数である**: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] は ETTR を `R/W` と定義し、長時間・高優先度ジョブでは `E[ETTR] ≈ 1 - Nnodes rf (u0 + Δtcp/2)` と近似する。つまり checkpoint interval `Δtcp` は単なる I/O チューニング値でなく、ジョブ規模 `Nnodes` と障害率 `rf` に応じて ETTR 目標から逆算される。RSC-1 全体を 16,000 GPU の単一ジョブに使う場合、60 分チェックポイントでは ETTR 0.7、5 分では 0.93 と推定され、10 万 GPU 級で ETTR 0.9 を狙うには RSC-2 並みの障害率でも約 2 分チェックポイントと約 2 分再起動が必要になる。(Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) - **本番 checkpoint I/O では、ネットワーク帯域より NFS/RPC キュー形成が先に見える場合がある**: MegaScale は 2 段階チェックポイントで HDFS 転送を非同期化し、ByteRobust は高頻度 checkpoint のブロッキングを下げる。一方 [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は NFS ベースの 504 GPU 本番クラスタで、再起動ロード平均 150.8 GB/s(最大 read 帯域 700 GB/s の 21.5%)、保存バースト平均 40.1 GB/s(最大 write 帯域 250 GB/s の 16.0%)に留まると報告する。特に WRITE RPC は平均 2.03 秒/要求のうち 1.89 秒(93.1%)がキュー時間であり、「帯域を太くする」前に NFS/RPC request queueing、transport backlog、client/server queue、restore 末尾 shard を分けて見る必要がある。(Source: [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **ロールとランクの分離がチェックポイントと復旧の直列依存を断ち切る**: PyTorch+NCCL の標準的な復旧では、ワーカー ID がネットワークランクを再利用するため、通信初期化完了後にしかモデルパーティションのロードが始められない。FFTrainer の [[LCCL]] は「訓練ロール(データ/テンソル/パイプライン並列グループ内の ID)」と「NCCL ランク」を切り離し、モデルロードと通信初期化を並列実行できる。2,048 GPU 規模で通信初期化に 1,000 秒超かかっていた直列のボトルネックを原理的に排除する。チェックポイントのサイズ最小化と復旧手順の並列化という二軸を組み合わせて初めて MTTR の 97% 削減が実現した。(Source: [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]]) - **手作業 waypoint 方式は、システムレベル最適化以前の「保存範囲を選別する」設計判断そのものの原型である**: 1960年代の Apollo Guidance Computer([[リスタート保護]])は、自動 dirty page 検出や条件付きべき等判定のような計装手段を持たず、開発者がコード中に手作業で waypoint を配置し、リスタート時にジョブごと直近の waypoint から再開する規約でチェックポイントを実現していた。現代の「何を保存しないか」を攻める諸手法(PICKER のべき等スキップ、FlashRecovery の複製冗長化)がシステムレベルの自動最適化であるのに対し、Apollo の waypoint は同じ目的(保存対象の最小化・復旧の高速化)を人間の設計判断のみで達成しており、チェックポイント最適化の本質が「自動化の有無によらず保存範囲の選別である」ことを示す。(Source: [[@2004__AAS__Tales from the Lunar Module Guidance Computer]]) - **冗長チェックポイントの配置場所そのものが復旧確率を左右する変数であり、最適配置は理論的に解ける**: Gemini の mixed placement strategy(グループ配置 + リング配置の組合せ)は、$N$ 台・$m$ レプリカのとき、$N$ が $m$ で割り切れればグループ配置が最適(Theorem 1)、割り切れなければ上界とのギャップが $(2m-3)/\binom{N}{m}$ に抑えられることを証明する。FlashRecovery のデータ並列複製(同一データ並列グループ内の N−1 個の複製)も同種の「冗長配置による復旧確率の最大化」だが、配置の最適性そのものを確率論的に証明した例は Gemini が本 concept 内で唯一。複製ベースのチェックポイント代替(FlashRecovery)を検討する際、複製を「どこに置くか」の最適化はまだ横展開されていない未解決の設計変数である。(Source: [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]) - **チェックポイントコスト削減に第5の道が加わる: 通信経路そのものを物理的に分離する**: 既存の4方向(速く保存する/予備機で待たない/そもそも保存しない/複製で保存不要化)に対し、[[@2025__EuroSys__FlowCheck - Decoupling Checkpointing and Training of Large-Scale Models]](FlowCheck, EuroSys '25)は「訓練ノードにチェックポイント通信を一切発生させない」という第5の方向を示す。データセンタースイッチのポートミラーリング機能で DP の allreduce トラフィックを傍受し、CPU 専用チェックポイントノードが受動的に勾配を再構成する。Gemini がネットワーク遊休時間帯という**時間軸**でチェックポイント通信を訓練通信から分離するのに対し、FlowCheck はミラーポートという**経路**そのものを分離する点で異なるアプローチを取りながら、同じ目標(チェックポイントが訓練をブロックしない)に到達している。パケットカウントベースの状態機械でアプリケーション層情報なしに allreduce のフェーズとデータ位置を復元し、ミラーリンクの再送不能という固有の信頼性問題には DP の構造的冗長性を用いた回復方式(3ノード監視で単一イテレーション損失率 $6\times10^{-12}$)で対処する。(Source: [[@2025__EuroSys__FlowCheck - Decoupling Checkpointing and Training of Large-Scale Models]], [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]]) - **[チェックポイント頻度は障害率とクラスタ規模から逆算される設計変数である] CheckFreq は、障害率ではなくオーバーヘッド予算からチェックポイント頻度を逆算するという、もう一つの頻度決定原理を提示する**: [[@2021__FAST__CheckFreq - Frequent Fine-Grained DNN Checkpointing]](FAST '21)は、HPC 分野の先行研究(Daly のチェックポイント間隔最適化等)がクラスタの障害分布から間隔を導出するのに対し、DNN・ハードウェア特性のシステマティックなオンラインプロファイリングから、ユーザーが許容するランタイムオーバーヘッド `p`(例:3.5%)以内に収まる最短のチェックポイント間隔 `k` イテレーションを解析的に決定する。GPU 上でのインメモリコピー(`snapshot()`)と非同期ディスク書き込み(`persist()`)を分離しそれぞれ後続イテレーションの計算とパイプライン化する**二相チェックポイント**により、エポック境界方式比 83〜278 倍(Conf-Pascal)・25〜100 倍(Conf-Volta)高頻度なチェックポイントを、ランタイムオーバーヘッド 3.5% 未満で達成し、復旧時間を数時間から数十秒へ短縮する。訓練環境の干渉(同一ストレージを共有する他ジョブ等)による実測コストの乖離には、フィードバック駆動の**適応的レート調整**で頻度を再計算し目標オーバーヘッドを維持する。この「オーバーヘッド予算から頻度を逆算する」設計は、[[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] や [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] が紹介する非同期2段階保存の設計系譜の先行例に位置づけられる。(Source: [[@2021__FAST__CheckFreq - Frequent Fine-Grained DNN Checkpointing]]) - **「時間軸分離」と「経路分離」はどちらも訓練ノードへの追加負荷を避けるが、コスト構造が異なる**: Gemini は既存の GPU マシンの CPU メモリ(訓練クラスタに元から存在するリソース)を転用するためハードウェア追加コストがほぼゼロだが、遊休時間帯の推定には最大10%の標準偏差があり訓練トラフィックとの競合リスクを完全には排除できない。FlowCheck は CPU 専用チェックポイントノードという追加ハードウェア(ポートミラーリング先・DMA エンジン・RDMA NIC)を必要とする一方、訓練ノード側の通信スケジュールには理論上一切影響しない。FlowCheck 自身の試算では1536GPU・175Bモデル訓練で障害由来の浪費+追加ハードウェアコストが1日あたり約526ドルに収まるとするが、この比較はハードウェア量産コストを含まない見積もりであり、Gemini 型(既存リソース転用)と FlowCheck 型(専用ハードウェア追加)のどちらが総保有コストで有利かは、クラスタ規模・障害率・電力コストに依存する未検証の設計変数である。(Source: [[@2025__EuroSys__FlowCheck - Decoupling Checkpointing and Training of Large-Scale Models]], [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]]) - **「LLM×DATA」サーベイは MegaScale・Gemini の設計を独立に第三の情報源として再確認しつつ、冗長計算による代替を「Bamboo→Oobleck→ReCycle」という粒度の異なる3段階として整理し、本ページが FlashRecovery で扱ってきた「複製冗長によるチェックポイント不要化」という第4の道に、より粒度の細かい系譜を追加する**: サーベイは MegaScale の2段階チェックポイント(ホストメモリへの高速書き込み+バックグラウンドでの非同期 HDFS 転送)と Gemini の階層ストレージ配置戦略を、既存の本ページの記述と同内容で説明しており、これは学術文献間の独立記述による相互検証にあたる。加えて、本ページが FlashRecovery(データ並列複製による周期チェックポイント自体の不要化)のみを「複製で保存不要化」の代表例として扱ってきたのに対し、サーベイは同じ系統に属する3手法を粒度別に紹介する: (1) **Bamboo**(RAID 冗長化に着想、各ノードが自身の担当層に加え隣接ノードの一部層も計算する「ノード単位」の冗長)、(2) **Oobleck**(パイプラインテンプレートから耐障害閾値 f+1 個の物理的に異種混在なパイプラインを事前インスタンス化する「パイプライン単位」の冗長)、(3) **ReCycle**(事前設定された待機冗長を持たず、並列訓練に内在する計算冗長性を活用し障害ノードのタスクを他データ並列グループの同一処理ノードへ動的に再割り当てする「実行時再割り当て」型)。FlashRecovery のデータ並列複製は Bamboo に最も近い設計思想(同一データ並列グループ内の N−1 個の複製)だが、ReCycle はデータ並列内で完結せず複数データ並列グループを横断する点で異なる。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5, [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]]) - **チェックポイント互換性問題への対応は「4つの方向(速く保存/予備機で待たない/そもそも保存しない/複製で保存不要化)」のいずれにも収まらない、独立した第5の軸として存在する**: 本ページがこれまで蓄積した4方向はいずれも「保存コスト・復旧速度」を最適化目標とするのに対し、サーベイが紹介する PaddleNLP の統合モデルストレージ技術は「分散訓練戦略(データ並列⇔モデル並列の切替等)やマシン数が変わっても単一の完全なチェックポイントのみで再開できる」という**互換性**を目標にする。モデル重み・オプティマイザ重みを統一 safetensors 形式で保存することで、構成変更のたびに別個のチェックポイントを必要としない設計を実現する。ByteCheckpoint の SSD/HDD 階層管理(新規チェックポイントは高速アクセスのため SSD へ「ホット」保存し、評価完了後アクセス頻度が下がると HDD へ「コールド」移行)は、Gemini の CPU メモリ階層配置と同じ「階層管理」方向に位置づけられるが、判定基準が「復旧確率」ではなく「アクセス頻度の実測に基づくホット/コールド分類」である点で異なる。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5) - **独立した2本目のサーベイが、チェックポイントフリー復旧を「ライブマイグレーション」と「モジュール冗長」の2系統に分けて Bamboo/SlipStream/SWARM/Parcae/Oobleck を整理し、既存の「複製で保存不要化」系統をより粒度細かく裏づける**: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] は Bamboo→Oobleck→ReCycle の3段階を「ノード単位冗長→パイプライン単位冗長→実行時再割り当て」という粒度別に整理していたが、[[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 8 Fault Tolerance]] は同じ Bamboo・SWARM に加えて SlipStream・Parcae・Oobleck を、目的軸である「ライブマイグレーション(異なるデータ並列パイプライン間でモデル状態を転送・再構成する)」と「モジュール冗長(冗長モジュールへ計算をルーティングし状態転送を伴わない)」で再分類する。前者の粒度分類(冗長の単位)と後者の目的分類(状態を動かすか、計算を動かすか)は直交する軸であり、2つの独立したサーベイが異なる切り口で同じシステム群に収束的なタクソノミーを与えたことになる。SWARM が両分類のいずれでも「複合型」(SlipStream 型の冗長計算とライブマイグレーションの両側面を持つ)として扱われる点も両者で一致する。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5, [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 8 Fault Tolerance]] §8.4) - **Universal Checkpointing の並列化戦略非依存フォーマットは、PaddleNLP の Unified Checkpoint と同じ「互換性」志向の系統に属する独立した第2の実装例である**: 本ページは既に PaddleNLP の統合モデルストレージ技術を「速く保存/予備機で待たない/そもそも保存しない/複製で保存不要化」の4方向とは独立した「フォーマット互換性」という第5の軸として記録していた。[[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 8 Fault Tolerance]] が紹介する **Universal Checkpointing [384]** も、分散チェックポイントストレージを並列化手法(データ/テンソル/パイプライン並列の構成)から分離する統一表現を導入し、構成変更時にチェックポイントを別途取り直す必要をなくす。異なる組織・異なるソースが独立に「チェックポイント形式を並列化構成から切り離す」という同じ設計目標に到達しており、この方向性が単発の工夫ではなく複数実装が収束する設計パターンであることを裏づける。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5, [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 8 Fault Tolerance]] §8.3) - **分散チェックポイント（DCP/FSDP）の読み込み（リストア）性能において、フラッシュ NAS は Lustre を最大 3 倍凌駕する**: チェックポイントの性能議論は書き込み（保存）スループットに偏りがちであるが、障害復旧時や強化学習（RL）のロールアウトワーカーによる重み読み出しでは、全ランク協調によるチェックポイント読み込みレイテンシが GPU アイドル時間に直結する。Meta FAIR の 8K GPU クラスタにおける評価([[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]])では、単一ファイル DDP 保存では Lustre が NAS 比 9〜35% 高速であったのに対し、全ランクが個別にシャードを読み出す FSDP load（および DDP load）ではフラッシュ NAS が Lustre を最大 3 倍上回った。並列分散書き込み（FSDP save）でも高並列度（256 タスク）では NAS が優勢となった。さらに、ストレージファームウェア更新時の NFS `openat` ロック競合による 5 秒のストールが FSDP load レイテンシを 8 倍に悪化させた事例は、チェックポイント I/O が単なるバルク帯域ではなくファイルシステム層のメタデータ・ロック制御の健全性に極めて敏感であることを実証している。(Source: [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]]) ## 未解決の問い - Transformerのようにメタデータ感度が極めて高いモデルにおいて、多腕バンディット（MAB）等の適応制御アルゴリズムをオンライン訓練中の学習フェーズ遷移や動的バッチサイズ変更にリアルタイム追従させる際の安定性と収束性のトレードオフは何か。(Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]]) - Bamboo/SlipStream/SWARM/Parcae/Oobleck を「粒度(ノード/パイプライン/実行時)」と「目的(状態転送 vs 計算ルーティング)」の2軸で同時に位置づけたとき、両分類は完全に独立か、それとも一方が他方を予測する相関があるか(例: 粒度が細かい手法ほど計算ルーティング型に寄るか)。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5, [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 8 Fault Tolerance]] §8.4) - Universal Checkpointing と PaddleNLP Unified Checkpoint はいずれも並列化構成非依存のチェックポイント形式を目指すが、両者のフォーマット設計(テンソルシャーディングの表現方法)を直接比較した検証はまだない。異なる実装が同じ目標に到達した場合、フォーマットの相互運用性(一方の形式で保存し他方で読み込む)は成立するか。 ## 未解決の問い - Transformerのようにメタデータ感度が極めて高いモデルにおいて、多腕バンディット（MAB）等の適応制御アルゴリズムをオンライン訓練中の学習フェーズ遷移や動的バッチサイズ変更にリアルタイム追従させる際の安定性と収束性のトレードオフは何か。(Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]]) - Gemini の配置戦略はデータ並列度に依存しない一般的なグループ/リング構造を仮定するが、FlashRecovery のデータ並列複製や他の並列化戦略([[並列化戦略]])と組み合わせたとき、配置の最適性証明(Theorem 1)はどう再定式化されるか。ソフトウェア障害(ローカル復旧)とハードウェア障害(グループ内の生存マシンから復旧)の切り分けは、テンソル並列・パイプライン並列を厚くした構成でも同様に成り立つか。(Source: [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]]) - 異種ランタイムや異種ISA間のマイグレーションでは、命令アドレスやスタックレイアウトなど実行形式に依存する状態をどう共通表現に変換してチェックポイント化すべきか。(Source: [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]]) - ランタイム中立チェックポイントを用いた場合、チェックポイントフォーマットの標準化と OS レベル状態(ソケット、ファイルディスクリプタ)の統合はどう実現するか。JIT/AOT コンパイル済みコードの実行点をインタプリタ実行点と対応づける方法は何か。(Source: [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]], [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]]) - fast interpreter と standard interpreter の間で、カスタムコード上の実行点を Wasm バイトコード上の相対アドレスに正確に対応づける一般的手法は何か。特に最適化により命令順序が変化する場合はどう扱うか。(Source: [[@2024__APSys__A Checkpoint-Restore Mechanism with Interoperability Among Distinctive WebAssembly Interpreters]]) - データベース復旧のトランザクション整合チェックポイントとコマンドロギングの組み合わせを、データ量が増えてスナップショットサイズが大きくなる環境(数百 GB 超)に適用すると、チェックポイント頻度とコマンドログ長がどうトレードオフになるか？(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - LLM 訓練の周期チェックポイントと、カーネル単位のべき等性に基づく省略は組み合わせ可能か。 - PICKER の評価は DNN 推論(ResNet/GPT-2 等)中心で、LLM 訓練の高頻度チェックポイント削減への直接適用は未検証。 - 集合通信の信頼性([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])やフォールトトレラント AllReduce(NCCLX の FTAR)など、チェックポイント以外の耐障害機構とどう役割分担するか。 - FlashRecovery の複製冗長は各デバイスに N−1 個のモデル状態の複製を要求する。複製を保持するメモリコストと、それで削減できるチェックポイント I/O・再計算コストの損益分岐点はどこか。チェックポイント頻度を下げる代わりに複製冗長へ資源を割く構成は、どのモデルサイズ・データ並列度で有利か。 - 同時全滅確率は $0.001^N$ でデータ並列度 N に強く依存する。テンソル/パイプライン並列を厚く取りデータ並列度 N を小さくする構成(例:N=2)では同時故障耐性が急減し、複製冗長だけでは守りきれずチェックポイントへの依存度が上がる。並列化配分とチェックポイント頻度をどう協調設計するか([[並列化戦略]])。 - ETTR 目標から逆算される分単位チェックポイントは、実際のストレージ帯域・チェックポイントサイズ・非同期書き込みの tail latency と両立するか。頻度だけを上げると保存系が新たな障害源や輻輳源にならないか。 - NFS/RPC キュー時間が checkpoint save の支配項になる場合、最適化対象は `nconnect`、`rsize/wsize`、readahead、NFS フロントエンド、バックエンド write handling のどこにあるか。クライアント側 mountstats だけでは層を分離できないため、ストレージ側メトリクスと同時に測る標準計装は何か。 - FlowCheck の経路分離設計はデータセンタースイッチのポートミラーリング機能とネットワークがスイッチを経由する構成に依存する。NVLink 等の GPU 直接相互接続のみで DP 通信が完結する構成(スイッチを経由しない)では、この設計はそもそも適用できない。GPU 直接相互接続が主流になった場合、経路分離型のチェックポインティングはどう再設計されるか。 - FlowCheck は暗号化された訓練通信に対応していない(平文トラフィックが前提)。TLS 等でトラフィックを暗号化する環境で経路分離型チェックポインティングを成立させるには、チェックポイントノード側にどの程度の復号コストが追加され、それは訓練ノードへの負荷ゼロという設計目標をどこまで損なうか。 - Gemini(時間軸分離・既存リソース転用)と FlowCheck(経路分離・専用ハードウェア追加)は、総保有コスト(TCO)の観点でどちらが有利か。クラスタ規模・障害率・電力コスト・ハードウェア償却期間を変数とした定量比較はまだ存在しない。 - Bamboo(ノード単位冗長)・Oobleck(パイプライン単位冗長)・ReCycle(実行時再割り当て)・FlashRecovery(データ並列複製)という4つの冗長計算系統は、いずれも「予備サーバなしで訓練を継続する」という同じ目標を異なる粒度で達成する。これらを同一クラスタ・同一障害シナリオで比較した場合、粒度が細かいほど復旧は速いが実装・スケジューリングの複雑度が増すというトレードオフが定量的にどう現れるか。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5) - PaddleNLP の Unified Checkpoint(構成変更に強いフォーマット互換性)と、Gemini/FlowCheck のような配置・経路最適化(復旧速度)は独立した最適化軸として紹介されているが、両者を1つのチェックポイントシステムに統合した場合(構成変更への耐性を保ちながら配置・経路も最適化する)、設計上の衝突は生じるか。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] §2.4.5) - FSDP や DCP による分散シャードチェックポイントにおいて、保存時（Write）の並列ストライピングと復旧時（Read）の同時オープン競合（openat ロック競合など）の非対称性を緩和するクライアント側協調読み出しアーキテクチャはどう設計されるべきか。 - CheckFreq のオーバーヘッド予算ベースの頻度決定(ランタイムオーバーヘッド `p` 以内に収める)と、HPCA の ETTR 目標から逆算する頻度決定は、同一クラスタで両方の制約を同時に満たす頻度算出にどう統合されるか。データ並列訓練で LLM 規模までスケールした場合、CheckFreq のオンラインプロファイリング(モデル・ハードウェア特性ベース)は数万 GPU 級の障害率変動にどこまで追従できるか。 ## 関連 - ソース: [[@2025__EuroSys__FlowCheck - Decoupling Checkpointing and Training of Large-Scale Models]] / [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]] / [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]] / [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] / [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] / [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] / [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]] / [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]] / [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]] / [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]] / [[@2021__FAST__CheckFreq - Frequent Fine-Grained DNN Checkpointing]] - 概念: [[耐障害LLM訓練]] / [[べき等性]] / [[GPUクラスタ運用]] / [[LLM分散学習]] / [[並列化戦略]] / [[ランタイム中立チェックポイント]] / [[WebAssembly]] / [[リスタート保護]] / [[集合通信]] - エンティティ: [[PICKER]] / [[Asymmetric Resilience]] / [[Chimera]] / [[FlashRecovery]] / [[FFTrainer]] / [[Zhuang Wang]] / [[T. S. Eugene Ng]] / [[Rice University]] / [[flowcheck-eurosys25]] / [[Bo Jiang]] / [[CheckFreq]] / [[Jayashree Mohan]] / [[Amar Phanishayee]] / [[Vijay Chidambaram]] - 関連 MOC: [[AI Infra Telemetry - MOC]] / [[分散深層学習 - MOC]] ## 出典 - [[@2025__EuroSys__FlowCheck - Decoupling Checkpointing and Training of Large-Scale Models]](ポートミラーリングによる訓練通信経路からのチェックポイント通信の物理的分離・パケットカウントベースの状態機械による勾配復元・DP 冗長性を用いたミラーリンクのパケット損失回復) - [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]](CPU メモリへのチェックポイント配置戦略の最適性証明・遊休ネットワーク帯域を使ったトラフィックパイプライニング・障害復旧 13 倍超高速化) - [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](べき等カーネルのチェックポイント省略・コスト 4% 未満) - [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]](データ並列複製による周期チェックポイント不要化 k0 = 0・損失 1 ステップ限定・同時全滅時のみチェックポイントへ退避) - [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]](ETTR 近似式とチェックポイント間隔の逆算、16k/100k GPU 級の頻度要件) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](2 段階チェックポイント:ホストメモリへの数秒書き込み + 非同期 HDFS 転送) - [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]](warm standby・迅速な隔離による復旧調整の高速化) - [[@1985__Tandem__Why Do Computers Stop and What Can Be Done About It]](プロセスペア5類型の比較・状態/デルタ/自動チェックポイントの概念的起源) - [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]](Checkpoint Razor + Neighboring Redundancy で毎イテレーション・オーバーヘッド 3% 未満のチェックポイント・MTTR 97% 削減) - [[@2024__EdgeSys__Stateful VM Migration Among Heterogeneous WebAssembly Runtimes for Efficient Edge-cloud Collaborations]](ランタイム中立チェックポイント・dirty memory 検出・異種 Wasm ランタイム間マイグレーション) - [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]](ランタイム中立チェックポイントを用いた Wasm コンテナのホットリスタートと動的ランタイム切り替え) - [[@2025__arXiv__A Survey of LLM × DATA - Chapter 2.4 Data Storage for LLM]](§2.4.5 Data Fault Tolerance: PaddleNLP 統合チェックポイント形式・CheckFreq 非同期2段階保存・MegaScale/Gemini/ByteCheckpoint の階層管理・Bamboo/Oobleck/ReCycle の冗長計算3系統) - [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]] - [[@2021__FAST__CheckFreq - Frequent Fine-Grained DNN Checkpointing]](オンラインプロファイリングによるオーバーヘッド予算ベースのチェックポイント頻度自動決定・二相チェックポイントによるオーバーヘッド 3.5% 未満)