Google adds TPU systems for protected data and longer AI context

Google announced TPU 8tx and TPU 8i Max on November 9, reconfiguring existing chips for confidential processing and larger context alongside expanded operating software.

TPU 8i Max combines two TPU 8i chips in one package. Google says this doubles compute, on-chip SRAM and high-bandwidth-memory bandwidth. The target is agents working across a whole codebase or long videos, where supplying the model with context becomes a constraint.

TPU 8tx pairs Google’s accelerator with fifth-generation AMD EPYC CPUs for confidential computing. AMD says prompts, model weights and intermediate results stay encrypted in CPU memory and in transit, with hardware isolation during accelerator execution. Intended workloads include inference and training with private data.

The system checks an accelerator’s identity and security configuration before granting protected-memory access. Host CPUs also coordinate work and communication. AMD qualifies the protection: server manufacturers or cloud providers must enable it, and customers must confirm support.

Moving working memory beyond the accelerator

TPU Sync transfers cached model context between accelerator memory, host memory and servers while computation continues. Requests sharing instructions or documents can reuse that context.

The public repository says distributions are currently development versions preceding a stable release, and recommends pinning a verified version. Its validated hardware list names TPU v6e and 7x. Separately, the announcement marks storage tiering and reinforcement-learning weight transfers as experimental.

Cloud Pathways is generally available on GKE. A single controller manages multiple TPU slices, redistributing work when a chip or slice fails. Programs on each host handle data loading and checkpointing, supporting long training jobs through partial interruptions. Teams can inspect work from notebooks and share persistent resource pools.

GKE’s dynamic slicing joins or divides pre-provisioned TPU resources to match a job. Its documentation describes replacing static pools that otherwise need to be recreated for different job sizes. Current requirements include Ironwood TPU7x and Standard clusters in the Rapid channel. Joining large slices and dividing them into smaller ones have different minimum software versions. Faulty partitions can be isolated and replaced with healthy spares while other concurrent jobs retain their resources. Under static layouts, a failed node can affect the full pool.

The migration path uses the PyTorch backend open-sourced last month. Current documentation describes preserving standard execution behavior, inspecting operations step by step and compiling models for TPUs. Serving backends retain their existing schedulers and request-handling servers while using TPU execution underneath. Model definitions and hardware-specific optimization can be maintained separately. The previous PyTorch route on TPUs used deferred graph recording, often requiring code to mark compilable regions. The newer backend executes operations immediately by default, retaining the familiar structure for debugging an existing program.

The announcement specifies no price or general-availability date for the new hardware. Cloud Pathways supports TPU v5e, v5p, v6e and 7x on GKE; its separate integration with Slurm remains in preview.