Now generally available: GKE dynamic slicing for higher resilience

Google Cloud launched general availability for GKE dynamic slicing on Tensor Processing Units (TPUs), according to Google Cloud Blog's report by product manager Kavitha Gowda and engineering manager Wenzhe Li on November 10, 2026. The release decouples logical TPU slice formation from physical nodepool provisioning inside Google Kubernetes Engine Standard clusters. By shifting away from rigid static nodepools assigned to single TPU slices, the system slashes AI workload startup latency by up to 5x and accelerates cluster failure recovery by 4.5x, maximizing overall TPU goodput and fleet utilization at scale.

This report details how platform engineers, machine learning operations teams, and infrastructure builders can transition from static node allocations to dynamic TPU topology slicing. It covers dynamic super-slicing across optical circuit switches, sub-slicing within single physical cubes, incremental provisioning models, failure domain isolation, and workload manifest scheduling requirements for both multi-thousand-chip training runs and multi-tenant inference fleets.

What Now generally shipped

Google Cloud made GKE dynamic slicing generally available to allow Kubernetes clusters to dynamically carve out and stitch TPU resources without deleting or recreating static nodepools. Previously, managing TPU capacity on GKE Standard required operators to configure dedicated, fixed TPU slice topology nodepools for each separate job. Under that legacy model, changing workload dimensions required manually deleting existing nodepools and provisioning new ones from scratch, leaving hardware idle and blocking multi-host nodepools from serving multiple distinct AI jobs concurrently.

Dynamic slicing resolves that constraint by decoupling physical hardware provisioning from runtime logical slice construction. Platform operators convert baseline capacity into standardized 16-VM nodepools known as TPU cubes, configured in 4x4x4 topologies. The system introduces two deployment modes: dynamic super-slicing, which connects multiple cubes together to build large-scale training topologies, and dynamic sub-slicing, which carves a single 16-VM cube into independent partitions down to single-host four-chip slices to support multiple isolated workloads inside one shared nodepool.

What changed for builders in Now generally

For platform engineering teams, dynamic slicing eliminates the operational overhead of the manual delete-and-recreate nodepool lifecycle while sharply improving resilience against hardware faults. In legacy configurations, any single hardware fault crashed an entire static slice, forcing slow end-to-end reprovisioning across the whole failure domain. Dynamic slicing isolates large slice failures directly to an individual 16-VM TPU cube, allowing the scheduler to swap out an unhealthy cube in one to two minutes instead of tearing down the entire compute fabric.

The operational improvements deliver measurable gains across cluster startup, recovery time, and topology flexibility across diverse training and serving workloads.

Dynamic sub-slicing also introduces multi-tenant packing within a single 16-VM cube, activating the high-speed Inter-Chip Interconnect network mesh to serve distinct workloads side by side. When a job completes, the scheduler deconstructs the logical sub-slice and returns healthy partitions to the shared pool immediately. Even if one host inside a cube suffers a fault, builders can continue utilizing the remaining healthy partitions rather than abandoning the entire physical block.

How to install or upgrade Now generally

Adopting dynamic slicing requires converting TPU capacity into uniform baseline nodepools of 16 VMs each, representing individual 4x4x4 TPU cubes or sub-blocks. Teams must configure incremental provisioning nodepools, an operational model that replaces previous all-or-nothing validation rules by provisioning all currently healthy nodes within the cube while continuously reconciling state in the background to attach recovering hosts automatically.

Builders then enable the GKE slice controller on the cluster, deploy the dynamic slicing scheduler or link a compatible custom scheduler, and submit standard Kubernetes manifests containing dynamic slice annotations. When the scheduler detects these workload annotations, it directs the slice controller to instantiate a Slice Custom Resource, triggering optical circuit switching or Inter-Chip Interconnect mesh allocation at runtime.

gcloud container clusters update CLUSTER_NAME --enable-tpu-slice-controller --region REGION

apiVersion: v1
kind: Pod
metadata:
  name: tpu-dynamic-workload
  annotations:
    gke.cloud.google.com/tpu-slice-type: "dynamic"
    gke.cloud.google.com/tpu-topology: "4x4x16"
spec:
  containers:
  - name: trainer
    image: gcr.io/google-samples/tpu-workload:latest

Gotchas and compatibility in Now generally

Builders must account for structural topology constraints when migrating existing AI pipelines to dynamic slicing. Super-slicing relies directly on Google TPU Optical Circuit Switching technology, requiring uniform underlying 16-VM (4x4x4) cube footprints to stitch larger topologies together, such as combining four Ironwood cubes totaling 64 VMs and 256 chips into a 4x4x16 super-slice. Environments that rely on non-standard, heterogeneous slice shapes that cannot be mapped into 16-VM building blocks cannot utilize dynamic super-slice stitching.

Additionally, dynamic sub-slicing requires incremental provisioning nodepools to be established as a strict prerequisite before the high-speed Inter-Chip Interconnect network can be partitioned on the fly. While the architecture isolates single-cube failures to prevent whole-cluster crashes, scheduling workloads onto partially healthy nodepools requires monitoring potential partition health and usage metrics to ensure sub-sliced inference tasks receive their expected hardware shapes without unexpected resource contention.

What to watch after Now generally

Following this general availability milestone, platform teams should evaluate how dynamic slicing integrates across diverse cluster requirements, spanning massive 8,000-chip single slices, multi-slices running thousands of chips, and small four-chip single-host inference pods. Because the scheduler inspects incoming Kubernetes manifests to dynamically assemble and deform slice resources, operators can unify large distributed training jobs and dense multi-tenant inference services on a single fleet of uniform TPU cubes.

Teams should monitor scheduler placement metrics and automated repair cycles as dynamic slicing handles production hardware disruptions. With the GKE slice controller automatically creating Slice Custom Resources and swapping failed 16-VM cubes in one to two minutes, builders can observe whether their workloads maintain continuous goodput without manual intervention, and evaluate custom scheduler hooks for proactive health-based placement across large-scale accelerator pools.