NVIDIA Dynamo スナップショット：Kubernetes 上の推論ワークロードにおける高速起動

## コールドスタートの問題 本番環境での推論デプロイメントでは、需要は時間とともに変動するため、推論レプリカを弾力的にスケーリングする必要があります。しかし、Kubernetes 上で推論ワークロードをコールドスタートするには数分かかることがあります。その間、GPU は割り当てられていますがアイドル状態であり、トークンを生成せず、リクエストも処理できません。 この遅延は、システムが突然の需要増加を吸収するために十分に迅速にスケーリングできないため、トラフィックの急増時にサービスレベルアグリーメント（SLA）違反のリスクを高めます。 単一 GPU の vLLM (v0.20.0) ワークロードにおけるコールドスタートレイテンシの内訳は以下の通りです： ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-1-Snapshot.webp)*図 1. 単一 GPU 推論ワーカーのコールドスタートレイテンシ内訳* 起動時間を大幅に短縮するため、Kubernetes 上の AI 推論ワークロード向けのチェックポイント/リストアアプローチである [NVIDIA Dynamo Snapshot](https://docs.nvidia.com/dynamo/kubernetes-deployment/deployment-guide/snapshot) を導入します。本稿では、単一 GPU ワークロードにおいて光速に近い起動時間を達成する初期プロトタイプ背後の設計上の選択と最適化について説明します。 これは、Dynamo における高速スタートアップに関するシリーズ記事の第 1 回です。 ## CRIU と cuda-checkpoint 実行中の推論ワーカーのチェックポイント可能な状態には、2 つのコンポーネントがあります： - デバイス状態（GPU 側）：CUDA コンテキスト、ストリーム、デバイスメモリ、仮想アドレスマッピングなど。これはホストからは見えません。この状態をシリアライズするために、各 CUDA コンテキストを持つプロセスの CPU メモリへデバイスの状態をダンプする CUDA ドライバーのチェックポイント機能（cuda-checkpoint コマンドラインツールでも公開されています）を使用します。 - ホスト状態（CPU 側）：CPU メモリ、スレッド、ファイル記述子、名前空間など。Linux カーネルにはこの状態をシリアライズするために必要なすべての管理情報が含まれています。私たちはオープンソースツールである CRIU (Checkpoint/Restore in Userspace) を使用して Linux カーネルの管理情報を参照し、プロセスツリーの状態をディスクへシリアライズします。 これら 2 つのツールは、推論ワーカー全体の状態をチェックポイント/リストアできるようにきれいに連携しています。チェックポイント実行時： - cuda-checkpoint がすべてのデバイス状態を CPU メモリにダンプします。 - CRIU がすべてのホスト側のプロセスツリー状態をストレージ内のフォルダーへダンプします。 リストア実行時（同じノードまたは異なるノード）： - CRIU が NFS/SMB などの分散ストレージからシリアライズされた状態に基づいてプロセスツリーをリストアし、チェックポイントされたアーティファクトを別のノードから取得できるようにします。 - cuda-checkpoint が CPU メモリにシリアライズされた内容から新しい GPU へ GPU 状態をリストアします。 CRIU は本質的に「凍結・再開」メカニズムです。プロセスがリストアされると、実行はチェックポイントされた時点の正確な命令から再開され、チェックポイントやリストアが行われたことを完全に認識しません。 このため、チェックポイント前のワークロードの静置化や、復元後の外部状態の再確立など、必要な調整は、オーケストレーターまたはワークロード固有フックを通じて外部で処理する必要があります。これらのメカニズムについては、以下のセクションで説明します。 ## Dynamo Snapshot: Kubernetes Kubernetes では、ワークロードはポッド内のコンテナ内で実行されます。CRIU チェックポイントにはコンテナの書き込み可能ファイルシステム層への参照が含まれるため、プロセスツリーの状態とファイルシステムが一緒に移動するように、コンテナレベルでチェックポイントを行います。 Helm チャートを通じてインストール可能な特権 DaemonSet「snapshot-agent」を提供します。このエージェントは各ノード上で実行され、runc 自体への修正を必要とせずに、runc で管理されるコンテナのチェックポイントおよび復元処理を担当します。 チェックポイント時には、エージェントはワークロードの準備完了プローブを待機した後、ホスト側から cuda-checkpoint および CRIU を呼び出し、アーティファクトを共有ストレージに書き込みます。ワークロードがコンテナローカル（つまりオーバーレイファイルシステム）でファイルを作成または削除している場合があり、エージェントは CRIU ステージ後にこれらもチェックポイントします。 復元時には、エージェントは軽量なプレースホルダーポッドを開始し、オーバーレイファイルシステムを復元した後、CRIU/CUDA チェックポイントをそれぞれの名前空間に復元します。その後、復元されたワーカーが実行を引き継ぎます。 各エージェントはローカルノード上で独立して動作するため、チェックポイントと復元をクラスター全体で自然に並列化できます。私たちはこれを、runc の Kubernetes ネイティブなチェックポイント/復元サポート（これも CRIU に委譲しています）に依存する代わりに構築しました。DaemonSet アプローチは完全に移植可能であり、クラウドプロバイダーによるチェックポイント/復元機能ゲートのサポートに依存しません。 これにより、パフォーマンスチューニングのための CRIU に対する制御がより厳密になり、チェックポイントアーティファクトを OCI イメージに埋め込むのではなく、柔軟なストレージバックエンド上に保存できるようになります。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-2.-Kubernetes-Checkpoint-and-Restore-Lifecycle-with-Dynamo-Snapshot-1.webp)*Figure 2. Kubernetes checkpoint and restore lifecycle with Dynamo Snapshot* ## Dynamo Snapshot: The workload Dynamo インフェレンスワーカーは、以下の 2 つのフェーズで起動します： - エンジンの初期化：設定されたインフェレンスエンジンが起動されます。コミュニケーターが初期化され、重みが読み込まれ、カーネルがウォームアップされ、グラフがコンパイル/キャプチャされますなど。このフェーズの終了時には、ワーカーは完全にウォーム状態になります。リクエストに応えることは可能ですが、まだ自身のポッド外部からは検出できません。 - 分散ランタイムの起動：ワーカーは Dynamo コントロールプレーンに接続し、ディスカバリーバックエンドに登録することで、ルーターやグラフの残りの部分がワーカーを検出できるようにします。この時点から、ワーカーは「稼働中」となり、コントロールプレーンへのオープンな接続が確立され、クラスター内の他のコンポーネントもこのワーカーのポッドIDを認識しています。 もしワークロードがチェックポイント化されていることを知らされないまま、チェックポイント/リストアを素朴に実装した場合、チェックポイントジョブの準備状態プローブは、ディスカバリープレーンに登録された完全に初期化された分散ランタイムに対応することになります。つまり、CRIU によってキャプチャできないアクティブな TCP 接続が存在することになります。 これを解決する一般的なパターンは、クイエスク/レジュームフックです：ワークロードがクイエスク状態であることを保証し、リストア完了時に発火する外部シグナルでブロックします。これはチェックポイント/リストアにおいて強力な抽象化となります。なぜなら： - ワークロードがチェックポイント化される前にリソースをクリーンアップできるため、最終的なチェックポイントサイズが最適化され（したがってリストア時間が短縮されます）。 - チェックポイント化できないリソースをレジューム後に再作成できるようにするためです。これは特にマルチ GPU およびマルチノードのチェックポイント（将来のリリースで予定されています）において重要です：RPC に使用される確立された状態のアウトバウンド TCP 接続は、ポッド IP がチェックポイントとリストアの間に変更されるため、チェックポイント化できません。また、RDMA 登録や NIC 状態も、レジューム後に再作成する必要があります。 Dynamo Snapshot では、これらのフックを「チェックポイント準備完了」シグナルファイルの存在を readiness probe として定義することで実装しています。ワーカーはエンジンが初期化された後、分散ランタイム起動前にこのファイルを作成します。 その時点で、ワーカーはスナップショットエージェントが外部でチェックポイントを取得している間、別の「復元完了」シグナルファイルを待つポーリングループに入ります。チェックポイントは、このポーリングループ内の任意の命令で行うことができます。 CRIU はチェックポイントが行われた正確な命令位置で実行を復元するため、ワーカーはポーリングループ内で直接再開し、シグナルファイルを検知して追加の同期処理を必要とせずに分散ランタイムの初期化を進めます。 ## 最適化 #1: KV キャッシュのアンマップおよび解放 チェックポイントサイズを削減するための一つの最適化手法は、チェックポイント実行前に KV キャッシュメモリを解放することです。重み、CUDA グラフ、その他のバッファ/活性化が割り当てられている間の GPU メモリ使用量のピークを測定した後、推論エンジンは残りの GPU メモリを大規模な KV キャッシュバッファとして割り当てます。 ただし、チェックポイントはレプリカがリクエストを処理する前の静止状態で行われるため、この KV キャッシュバッファは全くチェックポイントする必要はありません。しかし、この CUDA グラフに埋め込まれているため、この KV キャッシュの仮想アドレスを安定して維持する必要があります。つまり、CUDA 仮想メモリ管理 API (cuMemCreate および cuMemMap) を介して KV キャッシュバッファを割り当てた後、仮想アドレスを安定させたまま基盤となる物理割り当てを解放するには、cuMemAddressFree を呼び出すのではなく、cuMemUnmap と cuMemRelease を呼び出すだけで十分です。幸いにも、この機能は vLLM (sleep() および wake_up() を経由) および SGLang (torch_memory_saver を経由) でネイティブに既に利用可能です。 KV キャッシュのアンマップと解放により、B200 上の Qwen3-0.6B の全アーティファクトサイズは約 190 GiB から約 6 GiB に削減されます。この効果は、KV キャッシュサイズが大きい場合（つまり、GPU サイズに対してモデル重みが相対的に小さい場合）に最も顕著です。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-3.-KV-Cache-Unmap-and-Release-Reduces-Checkpoint-Size-1.webp)*図 3. KV キャッシュのアンマップと解放によりチェックポイントサイズが削減される* ## オプティマイゼーション #2: CRIU の高速化 現時点では、復元時間はまだ許容できるレベルにはほど遠いです。また、より大規模なモデルの場合、復元時間がコールドスタートよりも長くなり、チェックポイント/リストレートの目的そのものを無効にしてしまいます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-4.-Restore-Time-with-Upstream-CRIU-Exceeds-Cold-Start-Time-1.webp)*Figure 4. Restore time with upstream CRIU exceeds cold-start time* 主な理由は、CRIU と cuda-checkpoint がメモリを光速度（SOL: Speed-of-Light）でコピーできないからです。Linux プロセスには、匿名メモリ（プロセスのヒープやスタックなど）と共有メモリ（プロセス間で共有されるメモリ）の 2 種類のメモリが存在します。CRIU はこれらの両方のメモリタイプを復元する責任を負っており、大規模モデルにおいてはどちらも重要なボトルネックとなります。このセクションでは、プロセスメモリの復元を大幅に高速化するために私たちが CRIU に実装した最適化手法について概説します。 **注:** これらの CRIU 最適化は現時点では Dynamo Snapshot の一部として提供されておらず、アップストリームの CRIU にマージされた時点で利用可能になります。 **注 #2:** ベンチマーク対象のワークロードにおけるオーバーレイファイルシステムは非常に小さく（<100 MiB）、復元時間の計算において無視できるほどであるため、ここでは省略しています。 ## 最適化 #2.1: Parallel memfd restore vLLM の sleep()/wake_up() パスと SGLang の torch_memory_saver（quiesce/resume フック内で呼び出します）は、ウェイトタグ付きの GPU 割り当てをピン留めされた CPU シャドウバッファへ移動させます。これは、高帯域幅のホストからデバイスへ、およびデバイスからホストへのメモリコピー（H2D/D2H）における一般的な慣行です。CUDA はこれらの割り当てを共有匿名メモリでバックアップし、その後 NVIDIA ドライバによってピン留めされます。Linux カーネル内ではこれらは memfds として現れます。これは MAP_SHARED でマッピング可能な、RAM バックアップの匿名ファイルです。 gpt-oss-120b の場合、これらのバッファは合計 120 GiB を超え、多くの独立した 2 GiB 以下のバッファに分割されていました。Upstream CRIU はこれらのバッファを逐次的に復元します：シャムバックアップされたオブジェクトを 1 つ作成し、サイズを変更し、マッピングし、チェックポイントイメージからその内容をを読み込み、その後次のオブジェクトへ進むという手順です。 私たちは CRIU を変更し、まずすべての一意な shmem バックアップオブジェクトを列挙した上で、スレッドプールを開始して並列に復元するようにしました。各ワーカーは独立してバッファを割り当ててチェックポイントから読み込むため、復元処理が一度に 1 つのバッファを処理するのではなく、利用可能なストレージ帯域幅と CPU の並列性を活用できるようになりました。 ## オプティマイゼーション #2.2: 匿名メモリに対する Linux ネイティブ AIO CRIU が共有リソース（ファイル、ソケット、共有メモリオブジェクト、memfds など）の復元を終えた後、各プロセスのプライベートメモリを埋める必要があります。具体的にはヒープページ、スタック、匿名マッピング、コピーオンライトのプライベートファイルマッピングです。これらのページは共有されず、1 つのプロセスに属し、チェックポイント前に持っていた正確な仮想アドレスに配置される必要があります。 アップストリームの CRIU では、この埋め込みパスは同期型の preadv ループです。レストアラーはリストから 1 つのジョブを取り出し、preadv に渡して待機します。カーネルはその単一の読み取りをストレージデバイスに発行し、デバイスは DMA でバイトを宛先の VMA ページに転送し、preadv が返ります。その後初めて、レストアラーは次のジョブに進みます。常に飛行中の読み取りは 1 つだけであり、リクエスト間のストレージデバイスのアイドル状態が残されます。単一のブロッキングストリームでは高速な NVMe バンド幅を飽和させることはできず、ネットワーク接続ストレージの場合、次の読み取りを開始する前に各読み取りで往復遅延が発生します。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-5.-Serial-preadv-Memory-Restore-one-read-in-flight-at-a-time.webp)*Figure 5. Serial preadv Memory Restore (one read in flight at a time)* 私たちは preadv ループを Linux ネイティブの AIO に置き換えました。CRIU は事前に読み込みジョブのリストを構築します。各ジョブは、ファイルオフセット、バイト数、および宛先の VMA ページを指す iovec を記述する iocb です。復元プログラムは AIO コンテキストを作成し、これにより多数の異なる読み取りトランザクションを同時に保持できます。これにより、ストレージデバイスは内部チャネル全体でこれらの処理を並行して実行できます。復元プログラムは AIO コンテキストを作成し、io_submit を使って一連の iocb を提出し、最大 128 の読み込みを同時に飛行状態（in flight）として保持します。io_getevents を経由して完了が戻ってくると、新しい提出でウィンドウが埋められ、すべてのジョブが完了するまでこれが続きます。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/05/Figure-6.-Linux-Native-AIO-Memory-Restore-up-to-128-reads-in-flight-concurrently.webp)*Figure 6. Linux Native AIO Memory Restore (up to 128 reads in flight concurrently)* ## Direct I/O and the page cache ストレージバックエンドがサポートしている場合、匿名メモリおよび共有メモリの読み取りは O_DIRECT を使用します。復元は主にチェックポイントファイルから宛先メモリへの単一のストリーム処理であるため、カーネルページキャッシュに入力ページをキャッシュすることは通常無駄になります。ダイレクト I/O を使用しない場合、大規模な復元により、チェックポイントデータでページキャッシュが一時的に満たされると同時に、宛先の shmem ページが割り当てられ、メモリの圧力が上昇して他のワークロードにとって有用なデータがスワップアウトされる可能性があります。 さらに重要なのは、Linux ネイティブ AIO（非同期入出力）は O_DIRECT フラグ付きで開かれたファイルに対してのみ真に非同期動作する点です。O_DIRECT が利用できない、あるいは信頼性が低いファイルシステム、例えば一部の NFS 環境などでは、復元処理はバッファード I/O にフォールバックし、逐次読みAhead（先読み）が行われるため、カーネル側では予測可能なストリーミングアクセスパターンが維持されますが、AIO による性能向上効果は大幅に低下します。 ## 結果 同じ環境において、CRIU の復元時間に劇的な改善が見られ、チェックポイントからの復元が推論ワーカーの完全起動（コールドスタート）よりもはるかに高速になりました： **モデル****チェックポイントサイズ****CRIU (upstream)****CRIU (AIO)****CRIU (AIO + parallel memfd)****上流版に対する速度向上比****SOL** **Qwen3-0.6B**6.2 GiB6.8 秒2.9 秒2.4 秒2.8 倍0.95 秒 **Qwen3-8B**26 GiB24 秒11 秒4.7 秒5.1 倍1.8 秒 **gpt-oss-120b**129 GiB119 秒54 秒15 秒7.9 倍11 秒 *表 1. 上流版 CRIU と最適化された復元パスの復元時間比較。Linux ネイティブ AIO および並列 memfd 復元により、モデルサイズに関わらず復元レイテンシが大幅に削減され、光速（SOL）に近いパフォーマンスを実現しています。*

NVIDIA Dynamo スナップショット：Kubernetes 上の推論ワークロードにおける高速起動

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト