Google Cloud announced general availability of GKE dynamic TPU slicing on November 9, allowing jobs to form logical slices from provisioned capacity.
The big change
- The change: Jobs can use different slice shapes.
- Why it matters: Teams manage shared resources across workloads.
- What to watch: Eligibility depends on the infrastructure.
How slices are formed
Google says the baseline consists of pre-provisioned 16-VM Ironwood cubes. Super-slicing connects cubes using optical switches; sub-slicing partitions a cube for smaller workloads. Its documentation gives an example: two 4x4x4 pools form one 4x4x8 slice.
If a component fails, the system can reform a slice using healthy capacity; a usable spare is still needed.
The reservation and scheduling constraints
All Capacity mode gives customers more direct control over reserved TPU resources. In managed mode, host recovery is automatic. All Capacity exposes the reserved capacity and makes the customer responsible for managing healthy spares. A reservation remains an infrastructure commitment, not extra hardware created for free when a job starts.
Dynamic slicing requires Ironwood TPU7x, an All Capacity reservation and a GKE Standard cluster in the Rapid channel with Container-Optimized OS. Super-slicing requires GKE 1.35.2-gke.1842000 or later; sub-slicing requires 1.36.0-gke.3712000 or later. Google says it is offered in TPU regions, subject to quota and capacity.
Workload admission is a separate concern. Kueue’s documentation explains that it checks quota and resource types before reserving resources. Flexible slice shapes do not guarantee immediate admission for every job.
