GKE Pod Snapshots、起動遅延を最大89%削減 70Bモデルのロードも37秒に短縮

概要

Googleは、2026年5月に一般提供(GA)が始まったGKE Pod Snapshotsの性能ベンチマーク結果を公開した。実行中のワークロードのメモリ状態をチェックポイントとして保存し、必要に応じて復元する仕組みにより、Pod起動時の遅延を最大89%削減できるという。特にAI推論ワークロードでの効果が大きく、70Bパラメータ規模のモデルは37秒、8Bパラメータのモデルは15秒でロードが完了したと報告されている。実例としてCodewayのケースも紹介されており、従来のカスタムキャッシング層では1分かかっていた処理がPod Snapshotsの導入で8秒まで短縮されたという。

技術的な仕組み

Pod SnapshotsはgVisorランタイムを基盤としており、利用にはGKE Sandboxが必須となる。Autopilotクラスタではデフォルトで有効だが、Standardクラスタの場合はgVisorを有効化したノードプールの設定が必要だ。スナップショットにはCPU/GPUメモリ、ファイルディスクリプタと実行中スレッド、CPUレジスタ、EmptyDirボリュームやtmpfsマウント、コンテナのルートファイルシステムまでが含まれ、データはCloud Storageに保存される。各ノード上のエージェントがスナップショットのライフサイクル管理を担い、記事のタイトルが示す通り、処理の重点が実行時の最適化からこのライフサイクル管理側へと移っている。

ライフサイクル管理と互換性検証

記事では、実務上の最大の課題としてスナップショットの無効化が挙げられている。GKEは「distilled Pod spec」と呼ばれるハッシュをスナップショットに埋め込み、復元時にPod仕様が同一のハッシュを生成することを要求する。復元先ノードは同じマシンシリーズ・CPUアーキテクチャである必要があり、gVisorカーネルやGPUドライバのバージョンも一致していなければならない。ノードプールの更新でこれらのバージョンが変わると既存のスナップショットは互換性を失い、エラーを出すことなく通常起動にフォールバックしてしまう点は運用上注意が必要だ。一方で、プロセスメモリの復元を諦める代わりにマシンファミリをまたいだ復元を許可する「rootfs-only scope」というオプションもあり、柔軟性と速度のトレードオフを選べるようになっている。

設定はPodSnapshotStorageConfig(保存先バケットの指定)とPodSnapshotPolicy(ラベルによるPod選択、自動/手動トリガー、保持期間)という2つのカスタムリソースで制御する。復元時はgVisorカーネルが数秒で復帰し、メモリの読み込みはバックグラウンドで継続しながらアプリケーションの実行が始まる仕組みだ。ただし暗号化キーや証明書の再作成、環境変数を/proc/gvisor/spec_environから読み込む必要があるなど、アプリケーション側に求められる対応もある。外部接続は復元時に切断され、Persistent Volumeはチェックポイント対象外、iptables/nftablesルールも復元されないため、ステートレスな設計がより重要になる。

ハードウェアの制約と今後の展望

現時点ではE2マシンでの完全なスナップショットは利用できず、マルチGPU環境ではL4 GPUのみがサポート対象で、Multi-Instance GPUにも非対応といった制約がある。また、スナップショットはワークロードの完全なメモリ内容をファイル化したものであり、エージェントサンドボックス環境では信頼できないモデル生成コードのメモリも含まれうるため、Workload Identity FederationとIAMバインディングを通じたアクセス制御が重要になる。この技術は、同じく2026年5月にGAとなったGKE Agent Sandbox(毎秒最大300サンドボックスを割り当て、90%が200ミリ秒以内に完了)でアイドルエージェントの一時停止に活用されているほか、Googleが並行して進めるオープンソースプロジェクト「Agent Substrate」でも、より高密度な一時停止・復帰の多重化が検討されている(ただし現時点ではプロダクション非対応)。AI推論ワークロードのスケーリング効率を高める基盤技術として、今後の発展が注目される。