Cloud & DevOpsInfrastructureMachine Learning

GKE Workspaces: Pause GPU Notebooks and Save State on GKE

Google shipped GKE Workspaces on November 4, and the feature developers actually care about is a pause button for GPU notebooks that works the right way: click pause, your in-memory variables are frozen, your loaded model weights are frozen, and the GPU billing stops. Click resume later and you pick up exactly where you left off — no reloading a 70B-parameter model, no re-running three hours of preprocessing. The underlying mechanism is GKE Pod Snapshots, using NVIDIA’s cuda-checkpoint to serialize GPU state to Cloud Storage. This is not a workaround. It shipped.

The GPU Idle Tax Is Real

Cast AI’s 2026 Kubernetes Resource Optimization Report analyzed 23,000 clusters and found average GPU utilization sitting at 5%. An idle H100 runs $3/hour — that’s $2,160 a month for a machine doing nothing. Researchers spin up GPU notebooks, run an experiment, grab lunch, and come back three hours later to find the instance still humming. Leave one running over a weekend and you’ve burned over $100 for zero compute work.

The standard options before this were bad. Auto-shutdown your notebook and you lose everything in memory — restart means reloading model weights, re-importing libraries, re-running cells. Leave it running and your cloud bill grows while you sleep. GKE Workspaces adds a third option: pause with full state preservation, resume later.

How the Pause Works

When you click pause in the Workspaces Dashboard, GKE runs the following sequence:

  1. NVIDIA’s cuda-checkpoint captures the GPU state — loaded model weights, CUDA memory, in-flight computation state — into process memory.
  2. GKE snapshots the full Pod: CPU memory, Python variables, filesystem changes, everything.
  3. The snapshot writes to Cloud Storage.
  4. The GPU hardware is released. Accelerator billing stops.

When you click resume, GKE restores the Pod from the snapshot. No cold start. Google’s benchmarks put a 70B-parameter model back up in 37 seconds. An 8B model takes about 15 seconds. That compares to several minutes for a cold start from a fresh container. Across tested workloads, Google reports up to 89% startup latency reduction.

Supported hardware: L4, A100, and H100. Multi-GPU Pods work on L4. Multi-Instance GPU (MIG) sharing is not supported.

Deploying It: Easier Than Full Kubeflow

GKE Workspaces runs standalone on GKE Standard or Autopilot. You do not need to install the full Kubeflow platform, and critically, you do not need Istio. For anyone who has attempted a full Kubeflow install, removing the Istio dependency alone is a significant reduction in ops overhead.

Prerequisites: GKE version 1.35.3-gke.1234000 or later. Once your cluster meets that requirement, deploy with Kustomize pointing at the kubeflow/notebooks remote base:

kubectl apply --kustomize   "github.com/kubeflow/notebooks/workspaces/controller/manifests/kustomize/samples?ref=v2.0.0-rc.0"

Administrators define WorkspaceKinds — templates that specify base images, resource profiles, and pod configuration. Users then pick an IDE (JupyterLab or in-browser VS Code), select a WorkspaceKind, and get a development environment provisioned in minutes.

When to Use This vs Vertex AI Workbench

GKE Workspaces is not the right tool for every situation. Vertex AI Workbench is easier to set up and fully managed — if you want to get a GPU notebook running in under ten minutes without touching Kubernetes, Workbench is still the answer. Colab Enterprise is similar: hosted, collaborative, low friction.

GKE Workspaces makes sense when you are already running GKE infrastructure, have data residency or compliance requirements that rule out managed services, and have teams that routinely leave notebooks idle. The pause-and-resume feature only saves money if people actually pause. The fact that it preserves state removes the main reason people avoided shutting down before.

Open Source and What Google Is Doing With It

GKE Workspaces is released under the Apache 2.0 license. Google is actively upstreaming the GKE-specific features — the standalone deployment path, the integrated auth, the pause/resume integration — back to the Kubeflow community. Kubeflow itself graduated from the CNCF in August 2026, so the ecosystem is maturing in the right direction.

The practical implication: the features you use in GKE Workspaces today should be available to self-hosted Kubeflow installs on other clouds or on-premises in a future release. This is not a GCP-only feature with a GCP-only future.

The Bottom Line

If you are running ML workloads on GKE and GPU idle time is costing you money — which it almost certainly is — GKE Workspaces is worth testing. The pause-and-resume feature changes the calculus around notebook lifecycle management. Pausing now means no lost state, so the disincentive to shut down goes away. At H100 prices, reclaiming even a few overnight hours of idle GPU time per week pays for the ops cost of running your own workspace infrastructure.

Full deployment details and the official announcement are on the Google Open Source Blog.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *