# Now generally available: GKE dynamic slicing for higher resilience, and efficiency for TPUs > Source: > Published: 2026-11-09 13:00:00+00:00 Running large-scale AI workloads on TPU and Google Kubernetes Engine (GKE) requires infrastructure that adapts as fast as your models change. Dynamic Slicing is generally available on GKE, which decouples logical TPU slice formation from physical nodepool provisioning. Compared to creating a static nodepool for each TPU slice, dynamic slicing reduces AI workload startup times by up to **5x** and workload recovery by **4.5x** — maximizing TPU goodput, efficiency, and workload resilience at scale.  Previously, managing TPU capacity at GKE standard required separate, fixed TPU slice topology nodepools, increasing startup times and complexity while preventing multi-host nodepools from hosting multiple AI workloads. Changing workload needs meant manually deleting and recreating nodepools. Additionally, this tight coupling created large failure domains where a single hardware fault crashed an entire slice, slowing recovery while reprovisioning. To overcome these challenges, we built GKE dynamic slicing, which decouples physical hardware provisioning from logical slice formation, dynamically stitching together TPU cubes using TPU optical circuit switching (OCS) technology to form various larger slice topologies (super-slicing), or partitioning TPU cubes into smaller slices for multiple workloads to run inside a nodepool (sub-slicing). By enabling workloads to assemble custom TPU slice topologies on demand without having to delete and recreate static nodepools, dynamic slicing reduces job startup latency, limits the blast radius of hardware failures, accelerates recovery of workloads, and improves fleet utilization and efficiency. Dynamic slicing delivers several key improvements for platform teams: **Zero-downtime topology agility:** Completely eliminates the rigid "delete-and-create" nodepool cycle, allowing to dynamically stitch together TPU cubes (16 VMs nodepools) to form large TPU slices, or carve out smaller-slices on the fly as an AI workload is submitted. **Up to 5x faster job startup:** Slashes job startup times by up to five times by instantly assembling logical slice topologies from pre-provisioned TPU nodepools instead of waiting for a slow, new nodepool deployment. **Improved fleet utilization:** Improves resource efficiency and eliminates idle capacity by enabling multi-tenant packing of smaller workloads within nodepools. Additionally, it lets you provision partially healthy nodepools. This way, you can utilize healthy hosts that would otherwise be unavailable. **Up to 4.5x faster recovery and fault tolerance:** Accelerates recovery by isolating large slice failures to a TPU cube (a 16-VM 4x4x4 slice topology) and swapping unhealthy cubes in one to two minutes.  **Enhanced visibility and control:** Offers comprehensive insight into potential TPU partitions (slices) within each cube, covering real-time health and usage metrics to facilitate proactive, optimized workload scheduling. GKE dynamic slicing is offered in two forms: super-slicing, to create larger scale TPU slices that exceed the size of a single TPU cube; and sub-slicing, which provisions smaller, independent slices from a single cube. GKE dynamic super-slicing utilizes TPU optical circuit switching (OCS) technology to dynamically connect TPU cubes (consisting of 16 VMs configured in a 4x4x4 slice topology) at the time of workload scheduling. By altering the OCS network configuration dynamically, larger slice topologies are created and tailored to the workload slice needs outlined in the Kubernetes workload manifest, significantly enhancing operational efficiency. Super-slicing fundamentally relies on a baseline conversion of all available TPU capacity into uniform nodepools composed of 16-VM (4x4x4) TPU cubes. When a TPU slice topology is specified in Kubernetes workload YAML file, the GKE scheduler (or your custom scheduler) identifies the request and instantiates slice creation. This process uses the TPU [optical circuit switch](http://cloud.google.com/blog/topics/systems/the-evolution-of-googles-jupiter-data-center-network?e=48754805) to stitch multiple 4x4x4 cubes together, dynamically instantiating the targeted slice topology and scheduling the workload directly onto the newly established super-slice. Dynamic sub-slicing partitions a single, pre-provisioned TPU cube (16 VM nodepool) into smaller, independent sub-slices on demand. You can manage a single pool of uniform TPU cubes and partition them on demand. With this approach, multiple distinct jobs with completely different slice topology requirements can run concurrently and fully isolated inside the same physical TPU cube, boosting overall resource utilization and allowing you to salvage and run workloads on healthy partitions, even if a portion of the cube is unhealthy. When a workload is scheduled, sub-slicing dynamically parses its specific slice topology requirements from the incoming Kubernetes manifest. It then locates healthy partitions within the cubes, activates the high-speed Inter-Chip Interconnect (ICI) network to form sub-slices, and deploys the workload onto the newly created slice. Upon workload completion, the scheduler automatically deconstructs ("deforms") the slice and returns the partitions to the shared pool, making them immediately available for future workloads without having to recreate the GKE nodepool. You can leverage dynamic slicing to form massive TPU slice topologies to meet large scale training, ranging from large 8,000-chip single slices to multi-slices of multiple thousands of chips, down to single-host four-chip configurations. This supports a wide variety of heterogeneous AI workloads within the same environment. Designed for the demands of largest-scale workloads, **dynamic slicing** delivers resiliency and operational efficiency for AI workloads running across thousands of accelerators. **Sub-slicing** offers the versatility to efficiently scale inference workloads ranging from small to large-scale deployments.   GKE provides deployable schedulers optimized for dynamic slicing, or you can use your own custom scheduler to manage workload placement. This flexibility allows for intelligent workload scheduling based on proactive health status monitoring. See more in our [documentation](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/dynamic-slicing). To get started, you must perform a one-time activity of pre-provisioning TPU capacity into nodepools of 16 VMs each (maps to a TPU cube or sub-block). This baseline conversion allows for dynamic stitching of these units into custom slice topologies on demand. Dynamic slicing introduces a new type of nodepools called an incremental provisioning nodepool. An incremental provisioning nodepool is a fault-tolerant model that supersedes the traditional "all-or-nothing" approach for creating TPU slices. GKE provisions the nodepool using all available healthy hosts even if some hosts in a 4x4x4 (16 VM) slice are faulty. The system continuously reconciles state, automatically adding pending nodes once faulty hosts recover. This setup is a prerequisite for dynamic sub-slicing, as it allows the high-speed ICI network mesh to be dynamically configured. By using incremental provisioning, you can create nodepools for your entire capacity at once, reducing operational toil and maximizing TPU utilization by enabling sub-slicing on healthy nodes. After enabling the slice controller in the GKE cluster and configuring the GKE scheduler, you can indicate the need for dynamic slices for your workloads using simple workload annotations. Upon detecting these annotations, the scheduler automatically triggers the GKE slice controller to create a Slice [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CR) to form the dynamic slice at runtime. Once the slice is formed, the workload is scheduled on the dynamic slice. Refer to [documentation](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/use-gke-dynamic-slicing) for examples. When host or network failures disrupt workloads, the GKE scheduler maintains resilience and continuous operation through targeted recovery strategies: **Super-slicing (slices larger than 1 TPU cube):** Hardware failures are isolated to a smaller unit — the TPU "cube" — allowing the scheduler to quickly reform the slice by removing the unhealthy cube and choosing all healthy cubes. **Sub-slicing:** Slices on faulty infrastructure are dynamically reformed using available healthy partitions. Dynamic slicing (super-slice and sub-slice) is available for  TPUs and is offered in all regions where TPUs are available. It is supported exclusively in [TPU All Capacity](https://docs.cloud.google.com/tpu/docs/all-capacity-overview) under reservation mode. For  working examples of dynamic slicing, refer to the [documentation](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/dynamic-slicing).