GPU チェックポイントの関係マップ

更新：2026-09-06。 対象：GPU プロセスの checkpoint/restart（C/R）を中心に、OpenCL、kernel 内部の実行状態、復元による高速起動まで。 情報源：原論文の本文またはアブストラクトと、実装元の公式資料。 個別ノートが未作成の研究は原資料へ直接リンクする。 本文未取得の項目と、原資料の確認が残る候補は末尾で区別する。

GPU C/R の研究は、状態をどう再構築するか、CUDA をどこで実行するか、保存と計算をどう重ねるかという別々の設計問題に分かれる。 CheCUDA から FlowGPU までを一本の後継関係で結ぶと、これらの違いが見えなくなる。 CRAC と FlowGPU は通常実行時のプロセス間通信を減らす設計だが、GCR はドライバによる制御状態の保存と独自のデータ転送を組み合わせる。CRAC、FlowGPU、GCR

補足図（AI生成）：実線の矢印は資料で確認できる拡張または利用関係。同じ枠に置いた研究は設計上の分類であり、直接の継承を意味しない。図は主要な分岐を示し、収録範囲は以下の表で補う。

1. 保存する状態と API の位置

CUDA を使う経路は、説明用には次のように置ける。 Application が Driver API を直接呼ぶ場合もある。NVIDIA CUDA Driver API

Application
  ↓ CUDA Runtime API を利用する場合
CUDA Runtime API
  ↓
CUDA Driver API  ← Application が直接利用する場合もある
  ↓
NVIDIA GPU driver
  ↓
GPU hardware

API 層と、C/R が保存すべき状態は区別する。 CPU のメモリやスレッドに加えて、GPU メモリ、CUDA の context や stream、複数プロセスが共有する資源などを整合させる必要がある。 CRIUgpu は CPU 側を CRIU、GPU 側をベンダ別プラグインで扱う。CRIUgpu §3–4

API interception は API 呼び出しを捕捉すること、API forwarding は捕捉した処理を別の実行主体へ転送することを指す。 proxy process は転送先を別プロセスに置く構成であり、interception と排他的な方式ではない。 FlowGPU は interception を残しながら、通常実行時の中央 proxy への forwarding を外している。FlowGPU §3–4

同じ「チェックポイント」でも、保存単位によって読む地図が変わる。

2. プロセス C/R の主要研究

年は原則として会議または掲載巻の年とし、初出が異なるものは併記した。 表の「配置」と「保存方式」は別の軸として読む。

CRCUDA の位置づけは NVCR v2 の Introduction と CRUM の関連研究 に基づく。 「NVCR 2011 と NVCR 2023」は同名でも実行配置が異なるため、表と参考文献で分けた。

3. 設計の分岐と、それぞれが減らすコスト

API 記録と再構築

CheCUDA と NVCR v1 は、CPU 用 checkpoint ツールが直接扱えない CUDA 資源をいったん外し、後で再構築する。 NVCR v1 は特に、復元時に device pointer の値を維持するため memory-related API を replay する。 単に VRAM のバイト列を保存するだけでは、アプリが保持するアドレスとの対応を戻せないためである。CheCUDA 原論文、NVCR 原論文 abstract

この方式とドライバ支援方式の差は、制御状態の再構築を誰が実装するかにある。 cuda-checkpoint ではドライバが CUDA 資源の保存と復元を提供する。 ただし FlowGPU のように、2026年でも API 記録と replay を用いる設計は続いている。NVIDIA README、FlowGPU §4

CUDA 実行を分離する場所

proxy の先行例は CRUM より前にある。 CheCL は OpenCL の各 API を別プロセスへ転送し、application 側には仮想 handle を残す。 CRUM は CUDA の UVM を扱うため、application と proxy のメモリを shadow page 同期で整合させる。CheCL 会議 abstract、CRUM §3

CRAC はこの分離を同じアドレス空間の中に置き、IPC を除去する。 FlowGPU は通常実行を task 内で進め、checkpoint 時だけ ghost process に GPU 状態を引き受けさせる。 両者を比較する軸は、分離を維持する場所とタイミングである。 「CRAC の次が FlowGPU」という直接の継承関係は、ここでは主張しない。CRAC、FlowGPU

計算と保存を重ねる段階

CRUM の forked checkpoint は、GPU から host へ退避した後のディスク書き込みを計算と重ねる。 PhoenixOS は GPU buffer の read/write を追跡して、GPU 状態のコピー自体と計算を重ねる。 したがって「非同期 checkpoint」という名前だけでは、隠せる時間を比較できない。CRUM §3、PhOS §5–6

PhOS の soft CoW は、保存前の buffer に書き込もうとしたときに旧内容を保護する。 soft recopy はコピー中に更新された buffer を再転送し、on-demand restore は実行が必要とする buffer の復元を先行させる。 初期の quiesce では CPU／GPU を同期するため、「GPU を一度も止めない」という説明にはしない。PhOS §5–6

制御状態とデータの分離

GCR は device data を非同期コピーで host へ保存し、その GPU buffer を解放してから残る control state をドライバに保存させる。 これにより、大きな data をドライバ側で再び転送する重複を避ける。 復元時には control state を戻してから data を復元する。 増分保存には CPU shadow execution と dirty template を使い、更新された buffer を識別する。GCR §4–5

この分離は、PhOS の「コピー中の書き込みとの整合性をどう保つか」とは異なる設計問題である。 このマップでは、GCR を PhOS の単純な後継として結ばず、ドライバ支援を利用する別の分岐に置いた。 GCR の PhOS 比較には2024年の公開 commit が使われているため、比較結果を任意の現行版の順位に一般化しない。GCR §6、参考文献44

4. 周辺研究と実装への展開

gCROP のような高速復元もプロセス C/R の範囲に含める。 ただし、実行中ジョブの障害復旧と、初期化済み推論プロセスの起動では、保存のタイミングや最適化できる状態が異なる。

Dynamo Snapshot は、推論を始める前の空の KV cache を保存対象から外すなど、アプリの状態に応じた最適化を行う。 そのため「透過的なプロセス C/R なら上位層の協調は不要」とは整理できない。 GPU 状態の保存機構と、サービスへの再登録や外部接続の復元は別に設計する必要がある。Dynamo Snapshot の workload と availability 節

5. 比較するときに固定すべき条件

kernel の完了待ちと、kernel の途中状態の保存は異なる。 cuda-checkpoint は投入済み work の完了を待つ。 GPU メモリや context を保存できることから、実行中 kernel の任意命令位置で停止して再開できるとは推論しない。NVIDIA README、CUDA kernel C/R

ドライバの対応範囲は年表の「2024」だけでは決まらない。 2026-09-06 に確認した公式 README は、570 の CRIU 4.0 統合、580 の GPU migration、595 の ARM、610 の特定 CUDA IPC 対応を分けて記載している。 UVM と cuMemExportToShareableHandle() 由来の IPC は同 README の非対応項目に残る。 復元先の GPU には同じ chip type と十分なメモリが必要と API 仕様に記載されている。NVIDIA README、CUDA Checkpointing API

性能比較では次の条件を揃える。 以下は各論文で異なる計測範囲を比較するための、このマップでの整理である。

特に、増分保存、圧縮、不要データの除外は別の操作である。 GCR は更新 buffer の識別、CRIU-LZ4 はページ圧縮、Dynamo Snapshot は推論開始前の不要状態の除外を扱う。 サイズの削減率だけを横並びにすると、何を削減したかが失われる。GCR、CRIU-LZ4、Dynamo Snapshot

6. 読む順序と調査の残り

プロセス C/R の設計を追うなら、次の順序で読むと比較点を固定しやすい。 これは学習上の推奨順であり、引用または実装の継承関係ではない。

1. CheCUDA → NVCR v1：GPU 資源の再構築と device address の維持。
2. CheCL → CRUM → CRAC：API proxy、UVM、同一アドレス空間での分離。
3. Cricket と Singularity：リモート GPU 実行と分散ジョブ管理への接続。NVCR v2 も proxy の比較対象に置く。
4. cuda-checkpoint → CRIUgpu：ベンダの保存機能と、CPU／コンテナ全体との統合。
5. PhOS、GCR、FlowGPU を対比：並行コピー、control/data 分離、通常時 forwarding の除去。
6. gCROP → CRIU-LZ4 → Dynamo Snapshot：必要データの先行復元、I/O 削減、推論サービスへの組み込み。

今回の探索では、提示された研究名の照合に加え、CRUM、CRAC、NVCR v2、Cricket、PhOS、GCR、FlowGPU、CRIUgpu の関連研究をたどり、2026年の公式実装も確認した。 主系列の設計比較は更新したが、GPU 関連 C/R の全論文を網羅したとはしない。 NVCR v1／v2、Two-level CheCL、CUDA kernel C/R、compiler-directed preemption には全文未取得の項目がある。 CRCUDA は原発表資料の確認が残るため、後続著者論文から確認できる関係に限定した。

今後の探索候補は、CRUM が挙げる VOCL-FT などの OpenCL 耐障害性、Cricket が挙げる HKC、VM／vGPU migration の系列である。 これらは今回、原論文を照合しきれておらず、主系列の実装詳細には混ぜていない。CRUM 関連研究、Cricket 関連研究

書誌情報はリポジトリの main.bib で管理する。 FlowGPU は出版社の引用形式に合わせて yang2027flowgpu とし、2026年のオンライン公開日を注記した。 本文未取得の研究は当該 abstract の範囲を超えて説明せず、論文と公式実装の対応範囲も同一視しない。

関連する地図：アプリケーションレベルの checkpoint、学習 checkpoint、ノートブック状態管理、全体ハブ。