> [!abstract] 概要(Abstract 日本語訳) > チェックポインティングは、大規模モデル訓練における主要な耐障害性手法として、学界・産業界の双方で関心の的になりつつある。しかし既存のチェックポイント設計は訓練プロセスと密結合しており、訓練効率を低下させる中断を招く。チェックポイントが訓練に与える影響を減らすため、本論文はチェックポイント操作を訓練プロセスから分離し、訓練をブロックすることなくチェックポイント保存を可能にする新規のチェックポインティングシステム FlowCheck を提示する。具体的には、FlowCheck は通常の訓練のネットワークトラフィックから完全な勾配情報を抽出することでチェックポイントを更新する。FlowCheck はこの設計を支えるためにトラフィックミラーリングネットワークを配備する。ミラー化されたトラフィックをチェックポイント操作に利用するには、2 つの重要な課題に対処する必要がある。第一に、訓練トラフィックからの勾配パケットの正確な識別と抽出を達成する必要がある。第二に、ミラーリンク上の伝送は再送をトリガーできないため信頼性がない。(1) パケットカウントに基づくトラフィック識別、(2) パケット冗長回復機構、という2つの鍵となる設計を通じて、FlowCheck は既存の訓練ネットワークを用いた効率的なチェックポインティングシステムを実装し、上記2つの課題を解決する。実験と推定により、FlowCheck が訓練への影響ゼロでチェックポイント操作を達成することを検証し、実運用上の障害条件下で FlowCheck が98%超の有効訓練時間を達成することを示す。 ## 論文情報 - タイトル: FlowCheck: Decoupling Checkpointing and Training of Large-Scale Models - 著者: Zimeng Huang(Shanghai Jiao Tong University・Alibaba Cloud、共同筆頭著者)、Hao Nie(Alibaba Cloud・Peking University、共同筆頭著者)、Haonan Jia(Alibaba Cloud)、Bo Jiang(Shanghai Jiao Tong University、corresponding author)、Junchen Guo(Alibaba Cloud)、Jianyuan Lu(Alibaba Cloud)、Rong Wen(Alibaba Cloud)、Biao Lyu(Zhejiang University・Alibaba Cloud)、Shunmin Zhu(Hangzhou Feitian Cloud・Alibaba Cloud)、Xinbing Wang(Shanghai Jiao Tong University) - 媒体: Twentieth European Conference on Computer Systems(EuroSys '25)、2025年3月30日〜4月3日、ロッテルダム、オランダ。ACM、16 ページ - DOI: https://doi.org/10.1145/3689031.3696088(ACM ISBN 979-8-4007-1196-1/25/03) - コード: https://github.com/AlibabaResearch/flowcheck-eurosys25(オープンソース) - Shepherd: John Wilkes ## 概要 FlowCheck は、大規模モデル訓練のチェックポイント操作を訓練プロセスから完全に分離するシステムである。既存手法(vanilla PyTorch Checkpoint・CheckFreq・[[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints|Gemini]])はいずれも訓練ノード自身がチェックポイント通信を能動的に開始する設計であり、程度の差はあれ訓練を妨げる。FlowCheck はデータセンタースイッチのポートミラーリング機能を使って data parallelism(DP)の allreduce 通信トラフィックを傍受し、CPU 専用の「チェックポイントノード」がミラー化されたトラフィックから勾配データを再構成してモデル状態を更新する。訓練ノード側は一切の追加通信・追加処理を必要としない。 ## 問題設定 入力は、固定の計算資源を用いる静的・同期的な大規模モデル訓練(産業界で一般的な設定、[[LLM分散学習]])と、その DP 通信が leaf switch を経由するというネットワーク構成([[集合通信]])。前提として、DP が利用されその通信がネットワークスイッチを通過してさえいれば、下位のアクセラレータ種別(A100 に加え AMD MI300X 等)や、DP と併用される他の並列化戦略(テンソル並列・パイプライン並列)によらず FlowCheck は適用可能である。ただし現在の実装は暗号化されていない通信を前提としており、暗号化通信への対応はチェックポイントノード側に追加の復号手段が必要になる限界として明記されている。出力は、CPU 専用チェックポイントノード上に維持される、訓練ノードと同期したモデルパラメータ・オプティマイザ状態の最新チェックポイントである。 パラメータ更新は次式で表される(式1)。 $\boldsymbol{W}_t = O(\boldsymbol{W}_{t-1}, \Delta_t)$ ここで $W_t$ は $t$ 番目のイテレーションのモデルパラメータ、$O(\cdot)$ は SGD や Adam などのオプティマイザ関数、$\Delta_t$ はパラメータのグローバル勾配である。FlowCheck はミラー化されたトラフィックからこの $\Delta_t$ を再構成できれば、訓練ノードの正常動作を妨げずにこの式を再現できるという観察に基づく。 **背景: ring allreduce の仕組み**。DP の allreduce には ring allreduce が広く使われる(本論文はこれを対象とし、他の allreduce アルゴリズムへの拡張は考察節で扱う)。$N$ ノードのリングでは、勾配テンソルを $N$ 個のチャンクに分割し、reduce-scatter フェーズと allgather フェーズをそれぞれ $N-1$ ステップで実行する。reduce-scatter の完了時点では各ノードが $1/N$ 個のチャンクについてのみ完全な集約結果を持ち、allgather フェーズで初めて全ノードが全チャンクの完全な集約勾配を得る。 **Figure 2: ring allreduce の図解** ![[_attachments/2026__EuroSys__FlowCheck/fig02-ring-allreduce.png]] (Figure 2. 3 GPU・チャンク a/b/c の例。Initial State ⓪ → Reduce-Scatter ①② → Allgather ③④ の順で進み、Reduce-Scatter の各ステップで GPU $i$ がチャンクを GPU $i+1$ へ送信・集約する。Allgather 完了時点で全 GPU が全チャンクの完全な集約勾配を持つ。Source: 論文 Figure 2。) この構造から、単一ノードの片方向トラフィック(inbound のみ、または outbound のみ)を観測しても、完全な勾配データの $(N-1)/N$ しか得られない。完全な集約勾配が伝送されるのは allgather フェーズのみであり、ノード $i$ の inbound のみを監視するとインデックス $i+1$ のチャンクを、outbound のみを監視するとインデックス $i+2$ のチャンクを取り逃す。したがって完全な勾配を得るには、少なくとも2つの異なる inbound/outbound ポートを監視する必要がある。 ## 提案手法 **アーキテクチャ** **Figure 1: FlowCheck の全体像** ![[_attachments/2026__EuroSys__FlowCheck/fig01-architecture-overview.png]] (Figure 1. 4ノードの DP リングを例に、FlowCheck がミラーストリーム(青破線)で allreduce 通信(赤実線)を傍受し、Checkpoint Node がミラー化された NIC 0/NIC 1 のトラフィックから Gradient を抽出して Training State を更新する様子。Source: 論文 Figure 1。) FlowCheck は「トラフィックミラーリングネットワークモジュール」(ネットワーク層、§5)と「チェックポイント更新モジュール」(ソフトウェア層、§6)の2モジュールで構成される。 **Figure 4: FlowCheck の詳細アーキテクチャ** ![[_attachments/2026__EuroSys__FlowCheck/fig04-flowcheck-overview.png]] (Figure 4. 左: トラフィックミラーリングネットワーク(§5)。GPU/NIC からのミラーストリームを CPU サーバーの NIC 0/NIC 1 が受信する。右: チェックポイント更新モジュール(§6)。Real-time Dumper → Packet Parser → Data Concatenator(損失時は冗長性チェック)→ Model Updater の順にパイプライン処理し、リモート永続ストレージへ定期転送する。完全な勾配データの捕捉には最低2本のミラーストリームが必要で、追加ストリームはパケット損失への耐性を高める。Source: 論文 Figure 4。) 「Mirroring Network Module」は、他の多段チェックポイントシステム([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints|Gemini]] 等)と異なり、チェックポイントデータを訓練ノード自身やその近傍ノードのホストメモリには保存せず、訓練ネットワークに追加した CPU 専用チェックポイントサーバーノードへミラー化されたトラフィック経由で保存する。各チェックポイントサーバーノードは、監視対象の訓練ノードに対応するモデル状態(チェックポイント)を保持する。「Checkpoint Update Module」は各チェックポイントノードのモデルパラメータ・オプティマイザ状態を訓練ノードと整合するよう初期化し、状態機械ベースのパケットパーサでミラー化トラフィックから勾配データフラグメントを抽出する(§6.1)。パケット損失に対しては複数ノードを跨いだデータ捕捉による部分冗長化で対処する(§6.2)。 **トラフィックミラーリングネットワークの設計(§5)** **Figure 5: マルチレールネットワーク上でのミラーリング配置** ![[_attachments/2026__EuroSys__FlowCheck/fig05-traffic-mirroring-network.png]] (Figure 5. GPU マルチレールネットワークアーキテクチャに基づくトラフィックミラーリング配置。各 Training Node の NIC0〜NIC3 が対応する Leaf Switch へ接続され、各 Leaf Switch にぶら下がる Capture Server がミラーストリームを受信する。Source: 論文 Figure 5。) チェックポイントノードの配置には2つの実務上の困難がある。**困難1: チェックポイントノードの配置規模**。各 DP グループの inbound/outbound トラフィックを少なくとも2ノード分捕捉する必要があるため、単純な配置では最悪ケースで通常訓練 GPU と同数以上の CPU ノードを各 leaf switch 配下に配備する必要が生じうる。FlowCheck はこれを「マルチレールネットワーキング構造」の採用で緩和する。GPU マルチレール構成では同一ランク番号の GPU が同一 leaf switch に接続されるため、既存のトレーニングフレームワークの DP/TP 配分の下では、各 DP グループ全体が同一 leaf switch に接続されることが保証される。現行のデータセンタースイッチのインタフェース容量(典型64)と DP グループサイズ16という前提のもと、各 leaf switch あたり3組の CPU ノードで足りると試算している。**困難2: リアルタイムのミラーパケットダンプ**。ミラー化パケットの仮想アドレスと CPU チェックポイントノードの物理アドレスの対応マッピングがないため RDMA プロトコルスタックのオフロードを直接利用できず、TCPdump のような CPU ベースのダンプは 100Gbps 級の高速 RDMA トラフィックの実時間処理に不足する。FlowCheck は CPU 側の複数 DMA エンジン(Intel I/OAT)を活用し、受信順にラージページメモリへ並行してパケットを書き出すことでこの帯域を満たす(§7 で実測評価)。 **アルゴリズム/手法の詳細** チェックポイントの整合性を保つため、非 allreduce トラフィックからチェックポイント可能な勾配トラフィックを区別する必要がある。パイプライン並列やテンソル並列を併用する場合、ノード間通信には allreduce 以外の活性化・勾配伝送(下図)も含まれる。 **Figure 3: 訓練中の各種通信トラフィック** ![[_attachments/2026__EuroSys__FlowCheck/fig03-communication-traffic-types.png]] (Figure 3. モデル並列有効時の1イテレーションにおける通信の流れ: Activations In → FW → Activations Out → Gradient In → BW → Gradient Out → All-reduce。モデル並列が有効な場合、各ステージの前後で活性化・勾配の inbound/outbound 通信が発生し、allreduce トラフィックと区別する必要がある。Source: 論文 Figure 3。) FlowCheck は「パケットカウントベースのトラフィック識別」を用いる。初期化時にワークロードに基づき各通信操作で送信される RDMA パケット数を計算し、五タプル(送信元/宛先 IP アドレス・ポート番号・プロトコル種別)フィルタリングで訓練関連トラフィックのみを抽出したうえで、受信パケット数のカウントにより現在の伝送フェーズとデータインデックスを判定する。 **Figure 6: 訓練トラフィック解析の有限状態遷移** ![[_attachments/2026__EuroSys__FlowCheck/fig06-state-transition.png]] (Figure 6. non-allreduce traffic → allreduce-step1 → … → allreduce-step(N-1)(reduce-scatter)→ allreduce-stepN → … → allreduce-step2(N-1)(allgather)の状態遷移。allgather 完了後は初期状態に戻り次イテレーションの解析へ移る。Source: 論文 Figure 6。) Algorithm 1(Payload Parsing Algorithm)は、モデルが fp32 精度で学習される前提(勾配1要素あたり4バイト)のもと、パケットカウンタ $c$、非 allreduce パケット数 $t$、NIC の MTU $m$、Queue Pair ID $q$、パケットシーケンス番号 $p$、DP グループサイズ $n$、モデルの層数 $d$、各層のパラメータサイズ $L=\{l_1,\dots,l_d\}$ を入力に、現在のパケットがどの層(`cur_layer`)のどのインデックス(`cur_index`)に対応するかを出力する。$c < t$ なら非 allreduce トラフィックと判定し(-1 を返す)、そうでなければ層ごとの累積パケット数 `total_pkt_num` を計算して現在の層を特定し、`single_block_size` と `cur_step` から reduce-scatter 段階か否かを判定した上で、オフセット計算により勾配データブロックの位置を復元する。チェックサムにより伝送エラーを検知でき、再送パケットが閾値内に到着すれば正しいデータを再取得できる。パケット順序の入れ替わりは PSN の不連続性検出で自動的に補正する。 パケット冗長回復(§6.2)は次の観察に基づく。$N$ 台の DP リングで inbound を監視すると、監視対象GPUごとに $\frac{N-1}{N}$ の勾配データが得られる。 **Figure 8: 監視ストリームの冗長性** ![[_attachments/2026__EuroSys__FlowCheck/fig08-redundancy-scheme.png]] (Figure 8. $N$ ノードの DP リングで2ノード($i_1,i_2$)を監視すると $\frac{N-2}{N}$ が2重化・$\frac{2}{N}$ が無冗長、3ノード($i_1,i_2,i_3$)を監視すると $\frac{N-3}{N}$ が3重化・$\frac{3}{N}$ が2重化・データなしが $\frac{1}{N}$。Source: 論文 Figure 8。) ミラーリンクの損失率を $p$、送信すべき勾配パケット総数を $K$、$M$ ノードが互いに冗長バックアップを提供する場合、単一イテレーションでの勾配結合失敗確率は式2で与えられる。 $P(fail)_M = 1-(1-p^{M-1})^{\frac{M}{N}K}\cdot(1-p^M)^{\frac{N-M}{N}K}$ 実測でミラーリンクの損失率はおよそ $10^{-9}$。DP グループサイズ8・A100 40GB 1台あたり約1600万パケットが allreduce フェーズで送信される設定において、2ノード監視では単一イテレーションの勾配データ損失確率を $4\times10^{-3}$ 未満(約1000イテレーションに1回)、3ノード監視では $6\times10^{-12}$(約 $10^{12}$ イテレーションに1回)まで低減できる。この試算に基づき、FlowCheck は各 DP リングで少なくとも3台の訓練GPUのトラフィックを捕捉し相互バックアップすることを推奨する。回復不能な場合、CPU チェックポイントノードは制御プレーンネットワーク経由で訓練フレームワークへ通知し、次イテレーション開始時に通常のチェックポイント操作を実行させることで正確性を保証する。 **実装上の工夫** **Figure 7: CPU チェックポイントアップデータのパイプライン設計** ![[_attachments/2026__EuroSys__FlowCheck/fig07-checkpoint-updater-pipeline.png]] (Figure 7. Real-Time Dumper(NIC RX → DMA → Shared Mem への書き込み)→ Packet Parser(パケット読み出し・インデックス書き込み)→ Data Concatenator(インデックス読み出し・Grad i/k の共有メモリからモデルメモリへのロード)→ Model Updater(層 i の勾配ロード完了後にパラメータ更新)の4段パイプライン。各段は別々の CPU コアに割り当てられ、後段は前段の全パケット処理完了を待たずに逐次処理を開始できる。Source: 論文 Figure 7。) 実装は Xeon 8369B デュアルソケット CPU サーバー(NVIDIA ConnectX-6 NIC ×2)を CPU チェックポイントノードとして用い、DPDK ベースのアプリケーションで100Gbps 訓練トラフィックのリアルタイム傍受を実現している。パケットダンパーは Intel I/OAT の8基の DMA エンジンを活用し、Queue Pair ごとにラージページ MMAP メモリ領域へパケットをキューイングする。Data Concatenator では AVX512 命令セットで共有メモリからモデルメモリ空間へのコピーを最適化している。Updater モジュールは Python と Cython のハイブリッド実装で、ネイティブ API サポートとデータ処理速度の両立を図る。チェックポイントノードは通常時は最新版のモデルパラメータ・オプティマイザ状態のみを保持し(高速リカバリ用)、1時間おきなどの定期間隔でリモート永続ストレージへ多段チェックポイントの上位層として転送する(多段チェックポイントの保存頻度設計自体は先行研究に委ね、本論文のスコープ外としている)。 ## 新規性 既存手法との比較は以下の通り。Pytorch Checkpoint はチェックポイント通信を訓練ノードから能動的に開始するため訓練の一時停止を要する。CheckFreq はホストメモリを使い GPU-to-host のコピーで訓練とのオーバーラップを図るが、GPU-to-host 転送自体(実測約2GB/s)がボトルネックとなり停止を排除できない。[[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints|Gemini]] は訓練ノードのネットワーク遊休時間帯を精密にプロファイルしてチェックポイント通信を挿入することでスループットへの影響をほぼゼロにするが、遊休時間帯の推定には最大10%の標準偏差があり、依然として訓練ノード側の通信をスケジューリングする以上、チェックポイントトラフィックと訓練トラフィックが同一ネットワーク上で競合するリスクを完全には排除できない。FlowCheck はこれら既存手法と異なり、**チェックポイント通信を訓練ノードの通信経路から物理的に分離**する。訓練ノードは通常のミラーリング機能によって自動的にトラフィックを複製されるだけで、チェックポイントのために能動的な通信や待機を一切行わない。この設計により、チェックポイントノード側の処理時間さえイテレーション時間内に収まれば、訓練ノード側の挙動は理論上完全にチェックポイントなしの場合と同一になる。 ## 実験設定 - **テストベッド**: H3C S9850-32H スイッチ、訓練サーバー2台(各 Intel XEON 4314(16コア)×2、NVIDIA A100 40GB×4)、チェックポイントサーバー(Intel XEON 8369B(32コア)×2)。チェックポイントノードは100Gbps Mellanox CX-6 RDMA NIC ×2(in/outbound ミラーフロー両対応)、訓練ノードは100Gbps Mellanox CX-6 RDMA NIC ×4。全サーバーは H3C スイッチへ直結。Docker で GPU リソースを隔離し NVLink 通信を無効化することで、最大8ノードの訓練通信を模擬。 - **ワークロード**: BERT(110M)、RoBERTa(330M)、GPT-3(1.3B)、Llama2-7B(7B)。 **Table 1: 評価に用いたモデル** | Model | #Params | Hidden size | #Layer | #AH | |---|---|---|---|---| | BERT | 110M | 768 | 12 | 12 | | RoBERTa | 330M | 1024 | 24 | 16 | | GPT-3 | 1.3B | 2048 | 24 | 16 | | Llama2-7B | 7B | 4096 | 32 | 32 | (Table 1. AH は attention heads の略、M は million、B は billion。Source: 論文 Table 1。) micro-batch サイズ32、activation recomputation 有効、Adam オプティマイザ、NCCL v2.19.4(NCCL LL 通信プロトコル)を使用。 - **比較対象**: vanilla PyTorch checkpointing API(多くの DL 実務者の第一選択)、CheckFreq(オープンソース学術コミュニティで最良性能の既存チェックポイントフレームワーク)。[[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints|Gemini]] はオープンソースでないため比較対象から除外している。 - **評価指標**: イテレーション時間、チェックポイント時間の割合、有効訓練時間比率(effective training time proportion、OPT-175B のトレーニングログブックの障害頻度データと CPR のモデリングを援用して算出)、パケット損失下での勾配回復率、パケット処理時間の内訳(Dump/Unpack/Extract/Update)。 ## 実験結果 **DP-only シナリオでの性能**。8台の訓練 GPU でデータ並列のみを用い、チェックポイント保存頻度を毎イテレーションに設定して評価した。 **Figure 9: DP-only でのイテレーション時間** ![[_attachments/2026__EuroSys__FlowCheck/fig09-iteration-time-dp-only.png]] (Figure 9. チェックポイントなし(理想)・FlowCheck・CheckFreq・vanilla PyTorch API の比較。FlowCheck はチェックポイントなしの理想値とほぼ同一のイテレーション時間を維持する一方、CheckFreq と vanilla PyTorch API はワークロードが大きくなるほど乖離が拡大する(Llama2 7B で理想約23秒に対し CheckFreq 約29秒・vanilla 約40秒)。Source: 論文 Figure 9。) これは、allreduce 操作間の時間間隔が、FlowCheck の指定チェックポイントノードによるチェックポイント収集・保存操作の完了に十分な余裕を持つためである。 **Figure 10: チェックポイント時間比率(DP/DP-MP)** ![[_attachments/2026__EuroSys__FlowCheck/fig10-ckpt-time-proportion-dp.png]] (Figure 10. 棒グラフは各ワークロードでのチェックポイント時間と残り時間、折れ線は DP/DP-MP それぞれのチェックポイント時間比率。FlowCheck のチェックポイントノードは全チェックポイント操作完了後もなお次イテレーションの allreduce トラフィック到着を待つ遊休時間が残る。ワークロード規模が増えるほど、フォワード・バックワード計算に費やす時間の割合が増加するため、チェックポイント処理に許容される時間的余裕は相対的に緩くなる。Source: 論文 Figure 10。) **DP-MP シナリオでの性能**。8 GPU・2 MP ステージ(層数に基づき2分割、各セクション常に4GPU)で評価。 **Figure 11: DP-MP でのイテレーション時間** ![[_attachments/2026__EuroSys__FlowCheck/fig11-iteration-time-dp-mp.png]] (Figure 11. DP-MP でも FlowCheck はチェックポイント保存操作が訓練をブロックしないことを維持する。Source: 論文 Figure 11。) DP-only と比較して、MP のステージ間通信により連続する allreduce 操作間の間隔が拡大するため、DP-MP シナリオの方が FlowCheck にとってチェックポイント操作に利用可能な遊休時間が多い(Figure 10 参照)。vanilla PyTorch API では GPU-to-host コピー中の GPU ブロッキングが発生する上、CUDA のピン留めメモリ操作や GPU キャッシュの制約から PCIe 転送効率が低下し、GPU-CPU 間のチェックポイント転送に要する時間が単一 GPU イテレーションより長くなる。CheckFreq もホストメモリを用いた高速オフロードと GPU 計算のオーバーラップを図るが、実測の GPU-CPU 転送帯域は約2GB/s(REFT の実測とも一致)に留まり、モダンな PCIe リンクの能力を大きく下回る。マルチGPUサーバーノードでは複数 GPU からホストメモリへの転送が帯域を奪い合い、さらに通信効率が悪化する。 **有効訓練時間比率**。OPT のトレーニングログブックにある障害頻度データと CPR のモデリングを用いて、24時間の継続訓練を想定した際の有効訓練時間(チェックポイント保存・復旧・状態ロールバックによる冗長計算に費やされない時間)比率を算出した。 **Figure 12: ワークロード別の有効訓練時間比率** ![[_attachments/2026__EuroSys__FlowCheck/fig12-effective-training-time-workloads.png]] (Figure 12. ワークロード規模が増加するほど他ベースラインの有効訓練時間比率は急速に低下するのに対し(チェックポイントオーバーヘッド増大により最適チェックポイント頻度が低下するため)、FlowCheck はチェックポイントと訓練の分離設計により毎イテレーションのチェックポイント保存でも訓練をブロックせず、有効訓練時間比率を98%超に維持する。Source: 論文 Figure 12。) **システム信頼性分析(§8.3)**。実運用トラフィック統計から一般的なリンクパケット損失率は約 $10^{-9}$ と観測された。GPT-3 1.3B ワークロードでチェックポイントノードのパケット損失率を手動で $10^{-9}$〜$10^{-7}$ まで変化させ、各設定で100イテレーションのチェックポイント保存試験を実施した。 **Figure 13: パケット損失率別の勾配回復率** ![[_attachments/2026__EuroSys__FlowCheck/fig13-recovery-rate-packet-loss.png]] (Figure 13. m はチェックポイントノード数、k は DP グループサイズ。冗長化なしと2ノード冗長($m=2$)は損失率上昇に伴い回復率が大きく低下する一方(no redundancy は $10^{-7}$ で約17%まで低下)、3ノード冗長($m=3$)は $10^{-7}$ でも100%近い回復率を維持する。Source: 論文 Figure 13。) 3ノード監視による冗長化方式は、単一イテレーションの復元不能率を $10^{-8}$ 未満に維持でき、FlowCheck のチェックポイント設計の信頼性を最大化するには3台以上の監視ノードが有効であることを示す。 **パケット処理効率(§8.4)**。 **Figure 14: マルチ DMA キャプチャ性能改善** ![[_attachments/2026__EuroSys__FlowCheck/fig14-multi-dma-capture.png]] (Figure 14. 100Gbps RDMA NIC 使用時、CPU コアのみによるパケットダンプは実際に送信されたパケット総数(Total Send Pkts)に満たない受信数しか達成できず、100Gbps 級のリアルタイム処理には不十分であることを示す。マルチ DMA エンジン活用後は、モデル規模を問わずパケット損失なくホストメモリへ全パケットをダンプできる。Source: 論文 Figure 14。) **Figure 15: パイプライン設計の性能** ![[_attachments/2026__EuroSys__FlowCheck/fig15-pipeline-updater-perf.png]] (Figure 15. Dump/Unpack/Extract/Update の内訳付きで、パイプライン化した「Ours」と非パイプラインの「No-ppl」を比較。赤破線は各ワークロードの平均イテレーション時間を示す。パイプライン化により GPT3 1.3B で処理時間が約9.8秒(No-ppl)から約6秒(Ours)へ短縮され、イテレーション時間内に収まりやすくなる。Source: 論文 Figure 15。) Real-Time Dumper モジュールは訓練通信とリアルタイムに動作する必要があり、パイプライン化の有無によらずダンプ時間自体をさらに短縮することはできないため、パイプライン化の効果は主に Unpack/Extract/Update 段階の重畳に現れる。 **システムスケーラビリティ(§8.5)**。数千 GPU 規模の LLM 訓練インスタンスへの適用可能性を推定で示す。Megatron-LM が推奨する構成に基づき、Calculon シミュレーションを計算・通信時間の代理指標として用いた。 **Table 2: 推定に用いた Megatron-LM モデル** | #Parameter | #GPU | #Layer | TP Size | MP Size | DP Size | |---|---|---|---|---|---| | 175B | 1536 | 96 | 8 | 12 | 16 | | 530B | 2240 | 105 | 8 | 35 | 8 | | 1T | 3072 | 128 | 8 | 64 | 6 | (Table 2. TP はテンソル並列、MP はモデル並列(パイプライン並列)、DP はデータ並列のサイズ。Source: 論文 Table 2。) **Figure 16: 大規模ワークロードでのチェックポイント時間比率推定** ![[_attachments/2026__EuroSys__FlowCheck/fig16-estimation-ckpt-time-proportion.png]] (Figure 16. 175B〜1T・最大3072GPU規模のワークロード推定でも、FlowCheck は通常訓練の単一イテレーション内でチェックポイント操作を完了できる。モデル規模が大きくなっても単一 DP 通信グループの通信規模自体は大きく増加しない一方、他の並列化手法による非 allreduce 通信時間が増加し続けるため、大規模訓練シナリオではパケット処理・チェックポイント更新に十分な時間的余裕が生じる。Source: 論文 Figure 16。) コスト試算として、Alibaba Cloud の2024年9月時点の価格を代理指標に用い、8×A100 サーバーのレンタルコストは1時間30ドル、RDMA ネットワークカード付き CPU サーバーは1時間1.37ドルとした。1536GPU の175Bモデル訓練・1日2回の障害発生率という設定において、native PyTorch による毎時チェックポイントでは障害由来の計算浪費が1日あたり約5,760ドルに達する。これに対し FlowCheck では、障害由来の浪費と追加ハードウェアコストを合算した1日あたりのコストが約526ドルに抑えられる。 **Figure 17: 障害頻度別の有効訓練時間比率** ![[_attachments/2026__EuroSys__FlowCheck/fig17-effective-training-time-failure-rate.png]] (Figure 17. Megatron-LM 1T の訓練設定に基づく推定。障害頻度が1日8回に達しても、FlowCheck は96%超の有効訓練時間比率を維持する一方、他ベースラインの比率は障害頻度の増加とともに急速に低下する。これは障害頻度が高くなるほど、通常訓練による計算の浪費がより顕著になるためであり、FlowCheck は毎イテレーションでのチェックポイント更新により、障害に起因する計算浪費を最小化する。Source: 論文 Figure 17。) ## 考察 FlowCheck の中核的な洞察は、DP の allreduce トラフィックがすでにチェックポイントに必要な完全な勾配情報を含んでいる、という観察を、データセンタースイッチの標準的なポートミラーリング機能と組み合わせることで、チェックポイント通信を訓練ノードの通信経路から**物理的に**切り離せる、という点にある。[[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints|Gemini]] が訓練ノードの通信スケジュールの遊休時間帯を精密に予測してチェックポイント通信を割り込ませる「時間軸での分離」を追求したのに対し、FlowCheck は「経路そのものの分離」によって同じ目標(チェックポイントの訓練への非干渉)をより根本的に達成しようとしている。ただし、この設計は訓練ネットワークがスイッチを経由するというインフラ上の前提(データセンター内の GPU クラスタでは一般的だが、NVLink 等の直接相互接続のみで完結する構成には適用できない)と、チェックポイントノードという追加ハードウェアの投資を必要とする。また、パケットカウントベースの識別はワークロードの通信パターンが決定論的であることに依存しており、動的な通信スケジューリングや非同期訓練には別の設計が必要になる可能性がある(著者ら自身は静的・同期的訓練を前提とすると明記している)。§9(Discussion)で述べられている tree allreduce・FSDP・ZeRO-3 への拡張可能性は理論的な議論に留まり、実験による検証はなされていない。 ## 強み / 弱点・課題 - **強み**: (1) チェックポイント通信を訓練ノードの通信経路から物理的に分離するという設計により、訓練ノード側に一切の追加処理を課さない。(2) パケットカウントベースの状態機械という軽量な手法で、アプリケーション層情報を持たない生パケットから allreduce のフェーズとデータ位置を正確に復元する。(3) ミラーリンクの信頼性欠如という固有の課題に対し、DP の allreduce が持つ構造的冗長性を利用した確率論的に裏付けられた回復方式を提示している(式2)。(4) 実機評価(8ノード・4モデル)に加えて、175B〜1Tパラメータ・最大3072GPU規模までの外挿推定で、コスト試算を含めた実用性の見通しを示している。(5) ソフトウェア実装をオープンソース公開している。 - **弱点・課題**: (1) 暗号化された訓練通信には対応しておらず、平文トラフィックを前提としている(著者ら自身が限界として明記)。(2) 評価は最大8ノード(Docker によるエミュレーション)にとどまり、大規模ワークロードでの実測は行われていない(§8.5 はあくまで推定)。(3) チェックポイントノードという追加の CPU ハードウェアとネットワークポート(マルチレール構成でも leaf switch あたり追加のミラーポートが必要)を要し、既存インフラへの後付けコストがある。(4) [[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints|Gemini]] との直接比較評価がない(オープンソースでないことが理由と説明されている)。(5) 静的・同期的な訓練を前提としており、弾性訓練(elastic training)や非同期訓練、FSDP/ZeRO-3 のような動的な通信パターンへの実際の適用は将来課題として議論のみに留まる。(6) ネットワーク帯域が今後さらに高速化した場合、CPU 側 DMA エンジンのみに依存するパケットダンプ設計はボトルネックになりうるとし、NIC ドライバの変更が必要になる可能性を自ら指摘している。