Google has published benchmark results for GKE Pod snapshots. The company reports startup latency reductions of as much as 89%. A 70B parameter model loaded in 37 seconds, and an 8B model loaded in 15 seconds. The feature saves the running state of a workload, including CPU and GPU memory, and restores it on demand. It reached general availability in May on clusters running version 1.35.3-gke.1234000 or later.
This is checkpoint and restore, not caching. The snapshot holds everything the application had running, such as open file descriptors, threads, CPU registers, and memory. It also holds the container root filesystem, EmptyDir volumes, and tmpfs mounts. A new replica picks up from there. It never runs the initialization that loads the model, which is where most of the startup time goes on large models.
gVisor makes whole pod snapshots possible
gVisor makes that capability possible, and it comes with a condition. Pods have to run in GKE Sandbox, since that is where the gVisor runtime lives. Autopilot clusters already have it. Standard clusters need a node pool with gVisor turned on. An agent on each node handles the snapshot lifecycle. A controller on the control plane clears out obsolete snapshots, and Cloud Storage holds the data.
Two custom resources handle the configuring. PodSnapshotStorageConfig points at the bucket. PodSnapshotPolicy picks Pods by label, sets the trigger to workload or manual, and sets retention with a lastAccessTimeout and a cap on snapshots per group.
Customer results and practitioner questions
Google's customer example is Codeway. Its Retake platform had a custom caching layer for compiled artifacts, which got startup down to a minute. Lead DevOps engineer Ahmet Furkan Çomak said Pod snapshots cut that to just 8 seconds. The team now starts H100 instances for a specific job and shuts them down when it finishes.
Practitioner reaction has centered less on the capture than on what happens afterward. Senior DevOps and MLOps engineer Mohana Narasimha G. questioned snapshot invalidation and compatibility keys. Google's documentation answers the first half of that. GKE builds a hash from the Pod's essential runtime fields, called the distilled Pod spec, and embeds it in the snapshot. A Pod restoring from it must produce an identical hash.
The target node must have an identical machine series and CPU architecture. The gVisor kernel version and GPU driver version must match those captured. Where no compatible snapshot exists, the Pod starts normally. A rootfs-only scope relaxes the rules by skipping the hash comparison, allowing snapshots to cross machine families, including to E2.
Read nextNvidia Releases Free 100-Parameter AI Model for Real-Time Speaker IdentificationHardware limits and security considerations
Hardware support is narrower than the framing suggests. Whole-pod snapshots do not work on E2 machine types. Multi-GPU Pods are supported only on L4 GPUs, and GPU sharing with Multi-Instance GPU is not supported. The governance question follows from what a snapshot contains, as a file in Cloud Storage holds the complete memory of a running workload. Access rests on Workload Identity Federation and IAM bindings for each Pod's service account.
Google describes the feature as workload-agnostic, naming Java applications, game servers, and legacy monoliths alongside AI inference. The decisions left to teams include choosing which node pools run gVisor and setting up access policies. The next known step is for teams to evaluate their node pools, choose storage buckets, and determine how their applications handle state refreshed from a frozen process.
