# チェックポイント ## 定義 チェックポイント(checkpoint)とは、計算状態を周期的に保存し、障害発生時に直近の保存点から復旧する耐障害手法。大規模 LLM 訓練では障害頻度が高く([[耐障害LLM訓練]])、高頻度チェックポイントが信頼性の要となる一方で、保存コスト(時間・帯域・ストレージ)が問題になる。GPU カーネルの実行系では、再実行しても結果が変わるカーネルの状態を守るためにチェックポイントが必要になる。([[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]]) ## 横断的知見 - **チェックポイント対象を絞り込む「何を保存しないか」の方向は、エッジ環境でも有効である**: 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]]) - **チェックポイントコスト削減には 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]]) ## 未解決の問い - 異種ランタイムや異種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 だけでは層を分離できないため、ストレージ側メトリクスと同時に測る標準計装は何か。 ## 関連 - ソース: [[@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]] - 概念: [[耐障害LLM訓練]] / [[べき等性]] / [[GPUクラスタ運用]] / [[LLM分散学習]] / [[並列化戦略]] / [[ランタイム中立チェックポイント]] / [[WebAssembly]] / [[リスタート保護]] - エンティティ: [[PICKER]] / [[Asymmetric Resilience]] / [[Chimera]] / [[FlashRecovery]] / [[FFTrainer]] - 関連 MOC: [[AI Infra Telemetry - MOC]] / [[分散深層学習 - MOC]] ## 出典 - [[@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 コンテナのホットリスタートと動的ランタイム切り替え)