# CheckFreq: Frequent, Fine-Grained DNN Checkpointing > [!abstract] 概要(Abstract の日本語訳) > 深層ニューラルネットワーク(DNN)の訓練は、資源を大量に消費し時間のかかる処理である。訓練中、モデルは複数のエポックにわたって繰り返し GPU で計算を実行し重みを学習する。学習された重みは GPU メモリに存在し、耐障害性のために随時永続ストレージへチェックポイントされる(書き出される)。従来、モデルパラメータはエポック境界でチェックポイントされてきたが、現代の深層ネットワークでは1エポックが数時間に及ぶこともある。プリエンプション・ノード障害・プロセス障害による訓練ジョブの中断は、そのため回復時に数時間分の GPU 計算作業の損失をもたらす。 > 本稿では、(1) システマティックなオンラインプロファイリングを用いてイテレーション粒度でチェックポイント頻度をアルゴリズム的に決定し、(2) 適応的レート調整を用いてチェックポイントオーバーヘッドを制限するように実行時にチェックポイント頻度を動的に調整し、(3) 軽量な再開可能イテレータを用いてデータローダ状態をチェックポイントすることでデータセット中の各項目を1エポックにつき厳密に1回使用するという訓練データ不変条件を維持し、(4) 二相チェックポイントを導入することでチェックポイントを計算と注意深くパイプライン化してチェックポイントコストを削減する、自動的できめ細かいチェックポイントフレームワーク CheckFreq を提示する。多様なモデル・ストレージバックエンド・GPU 世代にわたる我々の実験は、CheckFreq が復旧時間を数時間から数秒へ短縮しつつ、ランタイムオーバーヘッドを 3.5% 以内に抑えられることを示している。 ## 論文情報 - タイトル: CheckFreq: Frequent, Fine-Grained DNN Checkpointing - 著者・所属: Jayashree Mohan([[UT Austin]]。本研究は Microsoft Research インターンシップの一環)/ Amar Phanishayee([[Microsoft Research]])/ Vijay Chidambaram([[UT Austin]] and VMware research) - 媒体・発表年: 19th USENIX Conference on File and Storage Technologies(FAST '21)、2021年2月23〜25日 - 実装: PyTorch 向けプラグイン可能モジュール(元の訓練スクリプトへの変更 10 行未満)。データイテレータは NVIDIA DALI 上に構築 ## 概要 CheckFreq は、DNN 訓練のチェックポイントを従来のエポック境界からイテレーション粒度へ引き上げるフレームワークである。チェックポイント頻度をモデル・ハードウェア・訓練環境ごとに自動決定するポリシーと、チェックポイントを計算にパイプライン化して低コスト化するメカニズムの2本柱で構成され、正しさ(データ不変条件の維持)を保ったまま復旧時間を数時間から数秒に短縮する。 ## 問題設定 - **入力**: 任意の DNN 訓練ジョブ(モデル・GPU 世代・ストレージ種別は問わない)。ユーザーが許容できるランタイムオーバーヘッド上限 `p`(例: 5%)を与える。 - **前提**: 学習可能パラメータ(モデル重み・オプティマイザ状態)は GPU メモリ上にあり、プリエンプション・ノード障害・プロセス障害によって訓練ジョブが予告なく中断されうる。BERT-large の訓練は 16 台の V100 GPU で並列化しても 2.5 日を要するなど、DNN 訓練は本質的に長時間ジョブであり、Microsoft の大規模 DNN 訓練クラスタの分析([[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]])では、2 か月間の分析期間中のジョブ障害間の平均時間(MTBF)は(初期障害を除いて)平均 45 分であったと報告されている。一般の大規模ビッグデータクラスタの MTBF は 4〜22 時間とされる。加えて、クラウドの低価格プリエンプティブル VM(専用 VM の 6〜8 分の1のコスト)は Google Cloud 上で少なくとも 24 時間ごと、頻繁には 15 分ごとにプリエンプトされうる。 - **課題**: エポック境界チェックポイントは、ResNext101 を V100 で ImageNet-1K に訓練する場合(1エポック約3.9時間、全体270時間)、中断1回あたり平均約2時間分の GPU 計算が失われるほど粗い。一方、素朴にチェックポイント頻度を上げる(例: 毎イテレーション)と、GPU がチェックポイント完了を待ってアイドルになる「チェックポイントストール」が生じ、高いランタイムオーバーヘッドを招く。さらに、ランダムな前処理(クロップ・リサイズ等)を伴うデータイテレータの多く(PyTorch・MxNet の標準イテレータ、DALI 含む)はイテレーション境界での再開に対応しておらず、イテレーション粒度でチェックポイントするとデータ不変条件(各エポックで全データ項目を厳密に1回処理する)が破られ、モデル精度が損なわれる。 ## 提案手法 ### 現状分析: 既存チェックポイントは「不正確」かつ「非効率」 CheckFreq は、PyTorch・TensorFlow・MxNet の公式訓練スクリプトと MLPerf v0.7 提出物を分析し、次の2つの問題を指摘する。 - **正確性**: 一部の PyTorch 公式ワークロードはストレージ節約のため同一チェックポイントファイルを毎エポック上書きするが、チェックポイント処理中のクラッシュによってファイルが破損しうる(ext3 のライトバックモードでは非アトミックな更新によるデータ破損、ext4 ではファイル切り詰めによるデータ損失)。さらに `torch.save` は `fsync()` を呼ばず、チェックポイントファイルが永続化されていない場合がある。 - **効率性**: チェックポイント間隔はアドホックに選ばれ(訓練を通じて一切チェックポイントしない、あるいは訓練の 60% が経過してから開始する等)、多くはエポック境界のみで、中断時に数時間分の GPU 時間が失われる。 ### アーキテクチャ CheckFreq は3つの主要コンポーネントからなる: 訓練ジョブへミニバッチを返す**再開可能なデータイテレータ**、いつチェックポイントを取るかを決める**フィードバック駆動のチェックポイントポリシー**、`snapshot()` と `persist()` の2フェーズに分かれた**低コストなチェックポイントメカニズム**である。 **Figure 3: CheckFreq でのアーキテクチャ** ![[_attachments/fast21-checkfreq/fig03-architecture.png]] (Figure 3. 訓練ジョブが `next_batch()` を呼ぶたびに Iterator が Policy へ `must_checkpoint()?` を問い合わせ(①②)、必要であれば Iterator が Snapshot() をトリガーし(③)、スナップショットはバッファ経由で Persist() へ渡って(④⑤)ストレージへ書き込まれ(⑥)、その結果が Feedback としてポリシーへ返る(⑦)。) CheckFreq が使う技術の全体像は次のとおりである(Table 1)。 **Table 1: CheckFreq が使う技術の概要** | 区分 | 技術 | 効果 | |---|---|---| | チェックポイントメカニズム(どう保存するか) | 二相チェックポイント | チェックポイントを2フェーズに分割し計算と注意深くパイプライン化することでチェックポイントを安価にする | | チェックポイントメカニズム(どう保存するか) | 再開可能なデータイテレータ | データ不変条件を維持し、精度に影響を与えずイテレーション境界での再開を可能にする | | チェックポイントポリシー(いつ保存するか) | システマティックなオンラインプロファイリング | モデル特性を踏まえてチェックポイント頻度を自動決定する | | チェックポイントポリシー(いつ保存するか) | 適応的レート調整 | 干渉によるオーバーヘッドを抑えるようチェックポイント頻度を動的に調整する | ### 復旧保証: 従来のエポック境界方式との対比 エポック境界チェックポイントでは、1エポックが `n` イテレーション・1イテレーション `ti` 秒のとき、平均復旧時間は `Ravg = (n/2) * ti`、最悪では `0 ≤ R ≤ n * ti` に達する(`n * ti` は1エポックの所要時間そのものであり、数時間規模になりうる)。 **Figure 1: 復旧時間** ![[_attachments/fast21-checkfreq/fig01-recovery-time.png]] (Figure 1. 中断発生時に失われ再実行が必要になる GPU 計算量を「復旧時間」と呼ぶ。エポック境界方式では直近の完了エポックまで巻き戻る。) これに対し CheckFreq は、任意の時点で進行中のチェックポイント操作が高々1つしか存在しないことを保証し、中断時には最新の開始済みチェックポイント(完了していれば)か、その1つ前のチェックポイントのいずれか高々1回分だけ巻き戻る。決定された頻度が `k` イテレーションであれば、復旧時間は `0 ≤ R ≤ 2 * k * ti`、平均で `Ravg = k * ti`(`k << n`)に収まる。評価では、選ばれる `k` は `n` より 100〜300 倍小さく、これがエポック境界方式に対する桁違いの復旧時間短縮につながる。 **Figure 2: 復旧時間の上界** ![[_attachments/fast21-checkfreq/fig02-bounding-recovery-time.png]] (Figure 2. CheckFreq は訓練が高々1つ前のチェックポイントまでしか巻き戻らないことを保証する。) 進行中のチェックポイントを放棄して次のチェックポイントを開始する設計は採らない。放棄した直後に障害が起きると両方のチェックポイントを失いかねず、連鎖的に古いチェックポイントまで巻き戻る危険があるため、CheckFreq は実行中のチェックポイントを一切放棄しない。 ### 二相チェックポイント DNN のチェックポイントは今日、訓練を一時停止して同期的に行われるのが通例であり、頻繁に実行すると大きなチェックポイントストールを招く。CheckFreq は DNN 対応の二相チェックポイントでこれを削減する。チェックポイント処理を **snapshot()** フェーズと **persist()** フェーズに分割し、それぞれを計算とパイプライン化する。 1. **フェーズ1: snapshot()**。各イテレーションの重み更新ステップの直後に、モデル状態のインメモリコピーを取る。学習可能パラメータは重み更新ステップで更新されるため、イテレーション `i` の `snapshot()` はイテレーション `i+1` の重み更新までの間、後続の計算とパイプライン化できる。もし `snapshot()` がそれまでに完了しなければ、イテレーション `i+1` は進行中の `snapshot()` の完了を待つ。この密結合は、確率的勾配降下法(SGD)の正しさを保つため、一部のイテレーションの重み更新が混ざった不整合なスナップショットを防ぐ目的で必要となる。さらに、空き GPU メモリがあれば GPU メモリ上に直接スナップショットを取ることで(GPU-based snapshot())、CPU へのコピーより1桁安価にできる。空き GPU メモリが無ければ CPU メモリへ直接スナップショットし、その場合はチェックポイント頻度を調整してオーバーヘッドを抑える。 2. **フェーズ2: persist()**。スナップショットをバックグラウンドで永続ストレージへ非同期に書き込む。`fsync()` を用いて永続化を保証したうえで、次のチェックポイント操作が始まる前に確実にディスクへ永続化されていることを保証する。 **Figure 4: 計算とチェックポイントのパイプライン化** ![[_attachments/fast21-checkfreq/fig04-pipelining-compute.png]] (Figure 4. 3イテレーションごとにチェックポイントする場合の3方式の比較。(a) 完全同期方式は高いチェックポイントストールを招く。(b) `persist()` のみをバックグラウンドでパイプライン化する方式(IO pipelining)。(c) CheckFreq は `snapshot()` も後続イテレーションのフォワード・バックワードパスとパイプライン化し、最も低いチェックポイントストールに抑える。) ### チェックポイント頻度の決定(アルゴリズム的な初期頻度決定) CheckFreq はシステマティックなオンラインプロファイリングでチェックポイント頻度を決定する。ジョブ開始時、データイテレータが最初のエポックの最初の1%のイテレーション、または最初の50イテレーションのうちいずれか少ない方をプロファイリングし、イテレーション時間 `Ti`・重み更新時間 `Tw`・GPU 上でのインメモリコピー時間 `Tg`・CPU 上でのインメモリコピー時間 `Tc`・ストレージへの書き込み時間 `Ts`・チェックポイントサイズ `m`・ピーク GPU メモリ使用量 `M`・総 GPU メモリ `Mmax` を収集する。この期間はチェックポイントを一切行わず、全体のごく小さな割合にとどまる。プロファイリング結果と決定したポリシーは永続ストレージにキャッシュされ、クラッシュ後のジョブ再開時にプロファイリングを再実行しなくてよい。 アルゴリズムはまず、空き GPU メモリが十分であれば `mode = GPU`(オーバーヘッド見積り `To = Tog = Tg`)、そうでなければ `mode = CPU`(`To = Toc = max(0, Tc - (Ti - Tw))`)を選ぶ。そのうえで、パイプライン化後にクリティカルパスに残るオーバーヘッドを `p`(許容オーバーヘッド比率)未満に償却するために必要なイテレーション数として、チェックポイント頻度 `k = ⌈(Tc + Ts - To) / Ti⌉`(下限 `kmin = ⌈To / (p * Ti)⌉` で頭打ち)を算出する。例えば、チェックポイントのコストとイテレーション時間がともに1単位時間で、許容オーバーヘッドが5%であれば、CheckFreq は20イテレーションごとにチェックポイントするよう選択する。 ### 適応的レート調整 静的なプロファイルベースの頻度決定は、訓練環境が実行を通じて変化しない場合にはうまく機能する。しかし実際には、同一ストレージを共有する他ジョブとの読み書き干渉などにより、実測のチェックポイントコストがプロファイル時の見積りから乖離しうる。そこで CheckFreq は、イテレータがジョブのランタイムと実測のチェックポイントコストを継続的に監視し、観測されたランタイムが目標オーバーヘッドを超えた場合にチェックポイント頻度を再計算するフィードバック駆動の**適応的レート調整**を行う。これにより、全体のランタイムオーバーヘッドが閾値 `p` を超えないよう保つ。 ### 再開可能なデータイテレータ CNN のようにエポックごとにランダムな前処理を行うモデルクラスでは、データ不変条件(各エポックが全データ項目を厳密に1回、ランダムな順序で、ランダムな前処理付きで処理する)を保つことが不可欠である。PyTorch・MxNet の既存イテレータは再開可能性を持たず、中断時にイテレータが状態を失うため、再開後のエポックでデータ項目の欠落や重複が生じ、精度低下を招く。 **Figure 5: イテレータ状態の再開** ![[_attachments/fast21-checkfreq/fig05-resuming-iterator.png]] (Figure 5. イテレータ状態が再開不能な場合、中断されたエポックでデータ項目が欠落しうる((b) では項目 3, 6, 7 が欠落)。CheckFreq のイテレータ(c) は中断前に処理していた地点から厳密に再開する。) CheckFreq の再開可能データイテレータは、エポック番号の関数であるシードを用いて毎エポックのデータシャッフルを行う。中断時には現在のエポック ID と処理済みデータ項目数のみを永続化すればよく(いずれも軽量な数バイト)、再開時はこの情報から同じシャッフル順序を再構成し、直前に中断した地点から決定論的に再開できる。ストレージオーバーヘッドは無視できる程度である。 ### 実装 CheckFreq は PyTorch 向けのプラグイン可能モジュールとして実装され、元の訓練スクリプトへの変更は10行未満で済む。データイテレータは NVIDIA DALI の上に構築され、既存の PyTorch データローダの drop-in 代替として使える。内部的には `torch.save()` に続けて `fsync()` を呼び persist() を実行することで永続性を保証する。データ破損を避けるため常に新規ファイルへチェックポイントを書き込む一方、ディスク使用量を抑えるため常時ディスク上に保持するチェックポイントは高々2つ(完了済み1つと書き込み中1つ)に限る。エポック境界のチェックポイントは(ユーザーが無効化しない限り)保持される。CheckFreq はオプティマイザの重み更新ステップをセマフォでラップし、進行中の `snapshot()` が完了してから次のイテレーションによる更新が行われることを保証する。 ## 新規性 - 既存の非同期 DNN チェックポイント研究(DeepFreeze)は CPU クラスタのみを対象とし、GPU から CPU へのモデル状態コピーコストを考慮していない。CheckFreq はモダンな GPU 最適化サーバでこのコストが無視できないことを示し、計算とのパイプライン化と空き GPU 容量の活用によって高速なスナップショットを実現する。 - DeepFreeze はチェックポイント頻度を手動でチューニングする必要があるのに対し、CheckFreq はモデル・ハードウェア・訓練環境から解析的に最適パラメータを特定し、共有クラスタ環境でもメモリ・ストレージ干渉に応じて頻度を適応させる点で優位である。 - HPC 分野の非同期チェックポイント研究はディスク I/O レイテンシの隠蔽を主眼とするが、DNN チェックポイント特有の課題は GPU から CPU へのモデル状態の同期コピーが高速化するGPU計算に対して相対的に高コストになる点にある。CheckFreq は DNN の学習構造(重み更新ステップの位置)を利用して、このインメモリスナップショットまで含めて正しく一貫性のあるパイプライン化を行う点で HPC 由来の手法と異なる。 - HPC のチェックポイント間隔推定はクラスタの障害分布から間隔を導出するのに対し、CheckFreq は DNN・ハードウェア特性に基づくオンラインプロファイリングで最短間隔を見つける、という異なるアプローチを取る。 - TensorFlow Checkpoint Manager はチェックポイント間隔をユーザーがアドホックに指定する必要があり、ランダムなデータ変換を伴うイテレータの状態を保存できず、演算グラフとプリフェッチ済みデータをまるごとストレージに書き出すためチェックポイントサイズが肥大化する。CheckFreq はこれらをすべて自動化・軽量化する。 - CRIU のようなフレームワーク透過的チェックポイント技術は VM 状態全体をバックアップできるが GPU やアクセラレータの状態を保存できず、たとえ保存できたとしてもデバイス状態全体はイテレーション境界で捕捉するモデル状態より1桁大きく、頻繁な CRIU チェックポイントは非現実的である。 ## 実験設定 2世代の GPU サーバ(Table 2)を用いて評価する。両サーバとも 24 CPU コア・500GB DRAM・8 GPU、64-bit Ubuntu 16.04、CUDA toolkit 10.0、PyTorch 1.1.0。 **Table 2: サーバ構成** | 構成名 | GPU 種別 | GPU メモリ(GB) | CPU メモリ(GB) | ストレージ媒体 | |---|---|---|---|---| | Conf-Pascal | 1080Ti | 11 | 500 | HDD | | Conf-Volta | V100 | 32 | 500 | SSD | 評価には7種の DNN を用いる: ResNet18・ResNet50・ResNext101・DenseNet121・VGG16・InceptionV3(いずれも ImageNet-1K データセット)、BERT-Large の事前学習(Wikipedia & BookCorpus データセット)。各モデルは文献で報告されている既定のミニバッチサイズを使用する。ベースラインは BERT を除く全モデルでエポック境界チェックポイント。BERT はイテレーション単位で訓練されるため、既定のチェックポイント間隔である200イテレーションをベースラインとする。正確な永続チェックポイントを行うため、チェックポイント操作の返却後にファイルを明示的にフラッシュする。 ## 実験結果 ### イテレータの再開可能性が精度に与える影響 ResNet18 を目標精度69.5%(または70エポック)まで、(1) 中断なし、(2) 既存 DALI イテレータで7分ごと(約2エポックごと)に中断、(3) CheckFreq のイテレータで同様に中断、の3設定で訓練した。 **Figure 6: 再開可能データイテレータが精度に与える影響** ![[_attachments/fast21-checkfreq/fig06-accuracy-resumable-iterator.png]] (Figure 6. 既存の再開不能イテレータでイテレーション粒度チェックポイントを行うとデータ不変条件が破られ、中断時に大幅な精度低下(最大13%)を招く。CheckFreq のイテレータは最終精度に影響を与えない。) チェックポイントされるイテレータ状態のストレージオーバーヘッドは、エポック番号とイテレーション番号という2つの整数(数バイト)のみで無視できる。 ### チェックポイントメカニズムの性能 Conf-Pascal で最大バッチサイズ64の VGG16 を用い、(1) 同期方式、(2) `persist()` のみパイプライン化(IO pipelining)、(3) `snapshot()` と `persist()` の両方をパイプライン化(CheckFreq)、の3方式のチェックポイントストールを比較した。 **Table 3: 利点の内訳(VGG16、2種のハードウェアでのチェックポイントストール秒数)** | ハードウェア | 同期方式 | IO pipelining | CheckFreq | |---|---|---|---| | Conf-Volta | 3.6 | 1.5 | 0.3 | | Conf-Pascal | 10.7 | 1.3 | 0.07 | 両ハードウェアで、CheckFreq は両フェーズをパイプライン化することでチェックポイントコストを IO pipelining のみの場合と比べて 5〜18 倍削減する。ストレージが遅い Conf-Pascal では `persist()` パイプライン化の寄与が大きく、高速ストレージの Conf-Volta では `snapshot()` の CPU コストと `persist()` のストレージコストが同程度に寄与するため、`snapshot()` のパイプライン化が大きな高速化をもたらす。 図7は、CheckFreq が選んだ頻度で複数モデルをチェックポイントした際のランタイムオーバーヘッドを示す。 **Figure 7: 各モデルのランタイムオーバーヘッド** ![[_attachments/fast21-checkfreq/fig07-runtime-overhead.png]] (Figure 7. CheckFreq が選んだ頻度で同期方式チェックポイントを行うと最大70%のオーバーヘッドになるのに対し、CheckFreq のパイプライン化チェックポイントはランタイムオーバーヘッドを3.5%未満に抑える。) 同期方式のベースラインは頻繁なチェックポイントにより17〜73%のランタイムオーバーヘッドを被るのに対し、CheckFreq は約3.5%に抑える。 ### チェックポイントポリシー 許容オーバーヘッド `p` = 3.5% として、8 GPU によるデータ並列訓練(Conf-Pascal)でのモデルごとのチェックポイント頻度を比較した。 **Table 4: チェックポイント頻度(1エポックあたりのチェックポイント回数とチェックポイントサイズ)** | モデル | ResNet18 | ResNet50 | ResNext101 | VGG16 | BERT | |---|---|---|---|---|---| | 頻度(回/エポック) | 147 | 125 | 238 | 83 | 100 | | サイズ(MB) | 90 | 195 | 482 | 1055 | 5000 | チェックポイント頻度はモデルごとに大きく異なり、頻度選択がモデル特性を考慮する必要があることを示す。CheckFreq は Conf-Pascal でエポック境界方式より 83〜278 倍、Conf-Volta では 25〜100 倍高頻度なチェックポイントを、3.5% 以下のオーバーヘッドで実現する。 **適応的頻度調整**の重要性を示すため、単一 GPU で VGG16(Job-A)を CheckFreq が決定した初期頻度(オーバーヘッド5%)で訓練させ、100イテレーション経過後に同一マシンの別 GPU で2つ目の VGG16 ジョブ(Job-B)を起動してストレージ帯域を競合させた。 **Table 5: 適応的頻度調整** | 設定 | 単独実行 | 静的(調整なし) | 適応的(CheckFreq) | |---|---|---|---| | オーバーヘッド | 5% | 35% | 5% | | 頻度(イテレーション数) | 14 | 14 | 19 | Job-B の投入によりストレージ帯域競合でチェックポイントコストが増大すると、頻度を14イテレーションのまま固定した場合オーバーヘッドは35%まで悪化するが、CheckFreq の適応的レート調整は頻度を19イテレーションへ動的に調整し、単独実行時と同じ5%のオーバーヘッドを維持する。 ### 復旧時間 単一GPU(Conf-Volta、Table 6a)と8GPUデータ並列(Conf-Pascal、Table 6b)の2設定で、エポック境界方式と CheckFreq の平均復旧時間を比較した。 **Table 6: 平均復旧時間(秒、CF = CheckFreq)** (a) 単一 GPU(V100) | モデル | Baseline | CF | |---|---|---| | ResNet18 | 840 | 5 | | ResNet50 | 2100 | 24 | | VGG16 | 5700 | 25 | | ResNext101 | 7080 | 32 | | DenseNet121 | 2340 | 7 | | InceptionV3 | 3000 | 27 | | BERT | 4920 | 85 | (b) 8 GPU(1080Ti) | モデル | Baseline | CF | |---|---|---| | ResNet18 | 180 | 3 | | ResNet50 | 540 | 8 | | VGG16 | 1320 | 31 | | ResNext101 | 1680 | 14 | | DenseNet121 | 600 | 4 | | InceptionV3 | 780 | 42 | | BERT | 4500 | 43 | CheckFreq は7モデル全てで復旧時間を数分〜数時間から数秒に短縮する。例えば、V100 で ResNext101 を訓練する場合、平均復旧時間は2時間から32秒に短縮される。 ### エンドツーエンド訓練 平均プリエンプション間隔5時間を想定したプリエンプティブルクラスタを模擬し、Conf-Pascal 上で ResNet50 をState-of-the-art精度まで訓練した。 **Figure 8: エンドツーエンド訓練** ![[_attachments/fast21-checkfreq/fig08-end-to-end-training.png]] (Figure 8. Conf-Pascal での ResNet50 訓練を5時間ごとに中断した場合、CheckFreq は復旧時間の短縮により、エポック境界方式に比べて2倍速く目標精度(76.1%)へ到達する。) Conf-Volta での同様の実験では ResNext101 の目標精度到達が1.6倍高速化した。 ## 考察 - **分散クラスタ訓練への適用可能性**: CheckFreq は現状、データ並列(DDP)モードで動作し、ノードあたり1つの GPU(rank 0)のみがチェックポイントを担当する。マルチノード構成への拡張は自然である。PyTorch のような DDP フレームワークでは同期ポイントごとに全ワーカーが同一バージョンの重みを見るため、各ノードで独立に CheckFreq を1インスタンス動かし、同期境界でローカル復旧用の同一チェックポイントを永続化すればよく、チェックポイントのための追加同期オーバーヘッドは生じない。 - **汎用性**: モデル並列・パイプライン並列を用いる先行研究もチェックポイントに依存するが、CheckFreq をミニバッチ境界(n イテレーションごと)で用いれば各パイプラインステージは自身が担当するパラメータ・オプティマイザ状態のサブセットのみを永続化すればよく、マイクロバッチ境界(m マイクロバッチごと)でのチェックポイントも、CheckFreq のイテレータがマイクロバッチのパイプライン投入を制御しているため可能になる(ただしこの場合、各ステージで蓄積された勾配など追加のモデル状態を保存する必要がある)。この統合は将来課題として残されている。 - PyTorch での実装に加え、TensorFlow や MxNet へもフレームワーク固有 API を CheckFreq が公開する API にラップすることで拡張できるとする。 ## 強み / 弱点・課題 - **強み**: (1) チェックポイント頻度の決定を完全に自動化し、モデル・ハードウェア・干渉状況に応じて動的に適応させる点、(2) DNN の計算構造(重み更新ステップの位置)を利用した二相パイプライン化によって、正しさ(SGD の一貫性)を保ったままチェックポイントコストを実質的に隠蔽する点、(3) 再開可能イテレータによってイテレーション粒度チェックポイントでもモデル精度を損なわない点、(4) 訓練スクリプトへの変更が10行未満で済む実用性、の組み合わせが評価できる。 - **弱点・課題**: (1) 評価時点ではデータ並列(DDP)構成が中心で、モデル並列・パイプライン並列への統合は将来課題として残されている、(2) チェックポイント担当は各ノードのrank 0 GPU に限定されており、ノード障害時の復旧手順(他ノードからの再構成)の詳細評価は本稿の主眼ではない、(3) 適応的レート調整の評価は単一の干渉シナリオ(同一マシン上の2ジョブによるストレージ帯域競合)に限られ、より複雑な多ジョブ共有クラスタでの挙動は今後の検証課題である。