全体地図(overview)
論文同士がどう繋がるかを散文で語る地図。各分野の詳細マップへの入口と、分野をまたぐ橋だけをここに置く。「何があるか」の索引は トップページ を参照。
役割分担:トップページ
index.md= 何があるか(分類された一覧)/このoverview/*= なぜ繋がるか(系譜・対立・補完を散文と図で)。各分野マップは完成したものから順に公開し、未着手分はあとから足す。
分野別マップ
- ✅ 状態管理・チェックポイント・移行 — 粒度(変数〜プロセス)と狙い(最小化/完全化/配置/GPU/UX)でアプローチを整理。中心系譜は ElasticNotebook → Kishu → Chipmink。
- ✅ アプリケーションレベルのチェックポイント — 「アプリ自身が必要な状態だけを保存する」技術を分野横断で見渡す地図。HPC 科学計算、ストリーム処理、データベース、言語処理系イメージ、ワークフロー、プリエンプション耐性まで、上の3分野(ノートブック、深層学習、GPU)の外側を描く。他分野の地図と直交する軸なので、既存の地図を束ねる位置に置いている。
- ✅ ノートブックの実態調査・データセット — 公開データセットを「何を記録しているか」で静的→実行成否→ランタイム資源のスペクトラムに並べ、セル別の実行時間・メモリ・CPU/GPU を集めた公開データセットが空白であることを示す。
- うち 性能分析(SLR §5.2.4) ✅ — 「性能」という共通語の関心を ①計測して見せる/②測って運用判断/③LLMに与える の3方向で整理。
- ✅ GPU チェックポイント:CheCUDA から PhOS、GCR、FlowGPU まで、API 記録、proxy/split-process、ドライバ支援、並行コピーの設計分岐を比較。OpenCL、kernel 内部の保存、推論の高速起動も整理(2026-09-06 更新)。
- うち 深層学習のチェックポイント ✅ — 保存対象(重み、オプティマイザ状態等)を整理し、単一ノードと分散の違いを明確化。
- うち 分散深層学習のチェックポイント ✅ — 35本の論文をストレージ階層、サイズ削減、頻度・並行性、形式統一、チェックポイント不要の5アプローチで整理。
- うち 深層学習のチェックポイント ✅ — 保存対象(重み、オプティマイザ状態等)を整理し、単一ノードと分散の違いを明確化。
- ✅ 学習時の GPU メモリ管理(再計算とスワップ) — 学習中の GPU メモリを節約する技術(activation checkpointing とテンソルスワップ)の系譜。「チェックポイント」の語は同じでも、耐障害性(上の GPU チェックポイント群)ではなく時間とメモリのトレードオフを扱う別分野。中心系譜は Chen/vDNN → Capuchin → Checkmate/XEngine → ProTrain。
- ⬜ インフラ・HPC・クラウド運用 —(作成予定)
分野をまたぐ橋
ここは分野別マップが揃うにつれて充実させる。現時点で、各ノートの本文から確認できる分野横断のつながりだけを記す。
- チェックポイント/移行 ⇄ HPC・クラウド運用:Elsa は「アイドルセッションを退避して運用コストを下げる」という、HPC・クラウド運用側の動機(コスト・稼働率)とチェックポイント技術(CRIU)が交わる地点。Absolute State も Airavata / Cybershuttle 系のゲートウェイ上でのノートブック実行という上位文脈を共有する。
- 性能分析 ⇄ HPC・クラウド運用:faenza2024containerized の「コンテナ化(K8s)が性能をどれだけ食うか」という実測は、ElasticHub など JupyterHub の Kubernetes 運用が暗黙に前提する「コンテナ化のコストは許容範囲」という仮定の裏づけにあたる。性能分析マップ を参照。
- 実態調査・データセット ⇄ 性能分析 ⇄ HPC・クラウド運用:データセットマップ が示す空白(セル別の実行時間・メモリ・CPU/GPU を集めた公開データセットが無い)は、性能分析 側の「資源を測るツールはある(JUmPER・ElasticNotebook の内部計測)」と、運用側の「ElasticHub は資源を測ってスケーリング判断に使いたい」という需要のちょうど中間にある。計測技術と需要は揃っているのにデータが欠けている、という橋。
- ノートブック状態管理 ⇄ 学習時 GPU メモリ管理:ElasticNotebook の「変数ごとに保存と再計算をコスト最適に使い分ける」という発想は、Capuchin が GPU テンソルに対して行う「スワップか再計算か」の判断と構造的に同型である。ただし両分野に引用関係はなく(ElasticNotebook・Kishu の参考文献に DNN メモリ管理系の論文は含まれない)、同じトレードオフの独立再発見になっている。解法の対比(min-cut / ILP / ランタイムヒューリスティック)は 学習時の GPU メモリ管理マップ の橋の節を参照。
- ノートブック状態管理 ⇄ HPC のアプリケーションレベル C/R:ElasticNotebook が Application History Graph 上で「保存するか再計算するか」を最小カットで決める手続きは、HPC で C3(PPoPP 2003)や AutoCheck(2024)が MPI プログラムのデータ依存から保存すべき臨界変数を自動特定する手続きと、解こうとしている問題が一致する。制約が MPI か Python ランタイムかの違いしかない。同様に、Kishu の差分チェックポイントと Flink のインクリメンタルチェックポイントも同じ問いへの別解になっている。詳細は アプリケーションレベルのチェックポイントマップ の橋の節を参照。
- (ほかの橋は各分野マップ作成時に追記)