NVIDIAがKubernetes向けのオープンソースツールSnapshotを公開した。初期化を終えたGPU実行環境で処理する作業であるワークロードの状態を保存し、新しいインスタンスで復元する。推論サービスの運用チームはモデルを再び準備する時間を短縮し、障害復旧や需要への対応を早められる。
1. 準備を終えた実行状態を再利用する
SnapshotはNVIDIA DSX AI Factory Platformの一部で、準備を終えた時点の実行状態を保存し、復元するシステムだ。CPUとGPUのメモリを、移動可能なファイル群であるアーティファクトとして保存し、新しいジョブで復元する。モデルの重みを再び読み込み、実行を最適化する準備段階を繰り返さない仕組みだ。
当初はNVIDIA Dynamoの推論ワーカー向けに開発されたが、他の推論エンジンや、実行ジョブの配置を決めるスケジューラー、要求された状態に合わせて調整するコントローラー、プラットフォームとも統合できる。
1つのノードで複数のGPUを併用する互換ワークロードも、単一のアーティファクトとして保存する。計算を複数のGPUに分けて処理する並列化を利用する大規模モデルにも適用できる。
2. 要求オブジェクトを作成して保存・復元する
実行状態の保存であるチェックポイントと復元は、Kubernetesに個別の要求オブジェクトを作成して処理する。実行中のジョブを保存するにはPodSnapshotを作成し、テンプレートから起動して準備が整い次第保存するにはSnapshotJobを使う。
復元時には、新しいPodにnvidia.com/restore-fromアノテーションを付けて、基準となるチェックポイントを指定する。
ワークロードは、チェックポイントの直前に一時停止し、復元後に実行を再開するよう連携させる必要がある。NVIDIAのリポジトリにはvLLM、SGLang、TensorRT LLMの連携例があり、プラットフォームチームは既存の推論環境に合わせて統合できる。
3. B200の試験で復元は3.6~42.7秒
同社の発表によると、試験はNVIDIA B200 GPU、615.71.09ドライバー、VAST(NFS)ストレージで実施された。以下は同じモデルをGPU 1基で実行した結果で、各エンジンを最初から起動するコールドスタートと、保存状態からの復元を比較している。
実行環境を最初から初期化するコールドスタートは、プロセスの起動からエンジンの初期化完了までを測定した。復元は、要求からサービス再開までを測定した。
表：Qwen3-0.6BのコールドスタートとSnapshotによる復元
条件：NVIDIA B200、ドライバー615.71.09、VAST (NFS)、Qwen3-0.6B、TP1(1 GPU)
単位：時間は秒、速度比は倍
| 推論エンジン | コールドスタート(秒) | 復元(秒) | 速度向上(倍) |
|---|---|---|---|
| vLLM 0.31.0 | 104.43 | 4.66 | 22.40 |
| SGLang 0.5.21 | 87.08 | 3.59 | 24.26 |
| TensorRT LLM 1.3.0 | 121.26 | 8.15 | 14.88 |
B200とVASTストレージを使った上記の結果では、3つのエンジンすべてで復元がコールドスタートより短かった。同社発表による全試験構成の復元時間は3.6~42.7秒で、コールドスタートより8~36倍速かった。8基のGPUを使った大規模モデルは約600GB~1TBのチェックポイントを43秒以内に復元し、その構成のコールドスタートは6~19分だった。
設計パートナーのCrusoeは、NVIDIA HGX B300でGLM-5.3 Podの準備時間を約8分から31秒に短縮したと述べた。Saturn CloudもNVIDIA HGX B300で、vLLMの起動時間を2~8.5分から6~34秒に短縮したと発表した。
4. 大規模モデルではGPU状態の転送が復元時間を左右する
コールドスタートは、エンジンの起動、重みの読み込み、メモリの準備、カーネルのコンパイル・自動チューニング・グラフキャプチャの順に進む。同社発表によると、DeepSeek-V4.1-FlashのvLLM構成では、最後のコンパイル・チューニング・キャプチャ段階が784.54秒、起動全体が1,110.65秒だった。Snapshotは完了済みの初期化処理を保存し、この繰り返しのコストを省く。
復元はアーティファクトを探し、CPUプロセスの状態とGPUメモリを復元してから実行を再開する。CPUの状態は、Linuxプロセスの保存・復元ツールであるCRIUで読み込む。
同社発表によると、8基のGPUを使った大規模モデルの復元では、GPU状態の転送が18~29秒、CPU状態の復元が4.2~10.8秒だった。大規模モデルの復元時間を短縮するには、GPUにデータを戻す区間を確認する必要がある。
5. 起動時間を短縮する代わりに保存作業と容量が必要になる
同社発表によると、チェックポイントの作成には構成に応じて15秒~5.5分かかり、アーティファクトは8.04GB~1,039.09GBとなる。作成時間はモデルと構成ごとに一度かかるコストで、試験したすべての構成で保存と初回復元の合計時間がコールドスタート1回より短かった。初期化の繰り返しを減らす代わりに、保存作業と大容量アーティファクトを運用に織り込む必要がある。
測定時間には、コンテナイメージのダウンロードとコンテナランタイムの準備は含まれない。復元には同じGPUモデル・ドライバーと実行互換性が必要で、会話の文脈を一時保存するKVキャッシュは保存前に空にするため、アーティファクトに含まれない。
SnapshotはGPUワークロードの初期化状態を再利用して起動時間を短縮し、その効果を得るにはチェックポイント時間と保存容量を運用設計に含める必要がある。