Google Cloud's Z4M Puts 168,000 GiB of Local SSD Behind AI Checkpoints

TL;DR

• Z4M is a storage-optimized machine series in Google Cloud's Compute Engine, built for workloads that move very large data volumes beside the compute that reads them.
• Google published general availability on 6 November 2026, with VMs and bare-metal instances, up to 168,000 GiB of local SSD per instance and up to 400 Gbps of Cloud RDMA.
• The ratio that shapes the design is 875 GiB of local SSD per vCPU, with local-SSD throughput balanced against network throughput at 1.4:1.
• RDMA sits directly on the checkpoint path: Google puts the latency gain at up to 60% against TCP, and the instances reach GPUDirect Storage and TPUDirect Storage.
• The maintenance rule depends on capacity and RDMA: VMs with 42,000 GiB or less can live-migrate when Cloud RDMA is disabled; Cloud RDMA disables live migration at every capacity, and VMs with 84,000 GiB or more plus bare-metal instances terminate with data preserved.
• The announcement gives 1,536 GiB as the ceiling across the VM and bare-metal portfolio; the machine-type documentation lists 1,488 GB for VMs and 1,536 GB for bare metal.
• Parallel file systems are the named companion tier, with Weka, Sycomp, Silk and VDURA in the workload table, and the operator still owns durability because local SSD belongs to one instance.

What Z4M is: Intel Xeon, Titanium SSD and 168,000 GiB of local disk

Google published the announcement on 6 November 2026 under bob Napaa's byline, and the series runs on fifth-generation Intel Xeon Scalable processors with the Titanium stack alongside. The headline capacity is local SSD: up to 168,000 GiB per instance, served through Titanium SSDs that take local storage processing off the CPU.

The design goal is stated plainly. Checkpointing, a distributed KV cache and parallel file systems all need storage and network throughput at the same time, and Google built the series for workloads that handle huge data volumes with massive parallel processing. Instance sizes run from 16 to 192 vCPUs, and Z4M uses highmem machine types.

The bare-metal variant deserves separate attention. Google lists custom hypervisors, licensing requirements and agentic AI workloads as its audience, and names Agent Substrate as a way to run isolated sandboxes at scale. A storage-heavy bare-metal box with 168,000 GiB of local disk is a plausible host for sandboxes that need scratch space, and it also inherits the maintenance rule covered below.

The ratio that matters: 875 GiB of local SSD per vCPU

Capacity is one input to sizing. The number an architect can size against is 875 GiB of local SSD per vCPU, because it sets how much scratch space arrives with each unit of compute. A checkpoint written from a training job needs a burst of sequential write bandwidth, and the density per vCPU decides how many writer processes a single instance can feed before the disk becomes the constraint.

Google also publishes the balance it engineered between the two paths, an LSSD-to-networking-throughput ratio of 1.4:1. That ratio describes the intent: process data locally on an instance and still hand it to clients at line rate. A team that runs parallel file system servers on Z4M reads that as the design constraint, since a server that ingests faster than its network can emit builds a queue.

RDMA on the checkpoint path

Cloud RDMA is the part of the announcement that changes how the storage path behaves. Google reports up to 400 Gbps of RDMA-enabled networking and puts the data-access latency reduction at up to 60% compared with TCP, and the instances transfer at line rate with NVIDIA GPUDirect Storage and TPUDirect Storage.

The practical consequence sits in the checkpoint loop. A training job that stops to write a checkpoint waits for the write to land, and a storage path that bypasses the host CPU shortens that wait. The same path serves a distributed KV cache, where a serving fleet reads context from a shared tier between requests. Google presents checkpointing and distributed KV cache as workloads that require high storage and networking throughput together with low-latency data access.

Numbers in the announcement fill in the rest of the profile. Random reads reach up to 15.6M IOPS and sequential reads up to 75,600 MiB/s, which Google puts at up to 70% and 110% above Z3. The partner quotes add their own measurements: Silk reports up to 3.7x lower latency and up to 6x lower CPU usage than TCP in its testing, and WEKA reports roughly twice the read throughput and up to 79% more IOPS against the Z3 family. Those figures come from companies selling software on the platform, and they measure their own stacks.

Maintenance: live migration depends on capacity and RDMA policy

This paragraph is the one to read twice before choosing an instance size. Google gives several days of notice ahead of required maintenance. Google's documentation says Z4M VMs carrying 42,000 GiB of local SSD or less can live-migrate during maintenance when Cloud RDMA is disabled; enabling Cloud RDMA disables live migration and requires the Terminate host-maintenance policy. Instances carrying 84,000 GiB or more, and all bare-metal instances, must be terminated and restarted, with data preserved through the event.

An operator who wants the largest cache on a single instance or enables Cloud RDMA trades away live migration. That trade belongs in the deployment design: a training job needs a checkpoint before the maintenance window, and a serving fleet needs a second replica to absorb the restart. Google's Cluster Director and Cluster Toolkit cover the placement side, offering compact topology for performance and spread topology across availability domains for availability, and the maintenance can be combined or staggered across those domains.

Two memory figures the post and the documentation treat differently

The announcement states up to 192 vCPUs and up to 1,536 GiB of memory for the VMs and bare-metal instances. The documentation states up to 192 vCPUs and up to 1,488 GB of memory for the series, then adds that Z4M offers a bare-metal machine type with 192 vCPUs, 1,536 GB of memory and 168,000 GiB of Titanium SSD.

The announcement gives 1,536 GiB as the ceiling across the VM and bare-metal portfolio; the machine-type documentation gives VM types a 1,488 GB ceiling and the bare-metal type a 1,536 GB ceiling. The documentation caps Z4M VMs at 1,488 GB and lists 1,536 GB for the bare-metal type. Reading the machine-type table takes two minutes and prevents a surprise at deployment, which is the habit this pair of numbers rewards.

Where Z4M sits next to a parallel file system

Google's workload table pairs Z4M with parallel file systems and names Weka, Sycomp, Silk and VDURA, and it also lists business-critical databases: SQL, NoSQL, vector databases and data search. Hyperdisk support rounds the picture out, with Balanced, Throughput and Extreme attached up to 512 TiB per instance; Extreme reaches 500K IOPS and 12,500 MiB/s, while Balanced offers up to 320K IOPS for general workloads.

Local SSD belongs to one instance. A checkpoint on local disk survives a process or guest-OS restart. Deleting the instance, or a host failure that exceeds the recovery timeout, loses the checkpoint. Supported Z4M maintenance termination preserves Titanium SSD data through restart, and durable copies still belong on Hyperdisk, a parallel file system replica or object storage. The parallel file system partners fill that role, and the design question becomes how much of the working set stays local and how much lives on the shared tier.

What the specification leaves to the operator

Three decisions stay with the operator after the announcement is read. The first is checkpoint frequency against local capacity, since a checkpoint that outgrows the instance forces a redesign. The second is which tier holds the durable copy, because local SSD is temporary storage with preservation limited to documented maintenance and recovery scenarios. The third is maintenance posture, where the largest instance sizes require a restart plan that a smaller size avoids.

The series suits teams running checkpoint-heavy training or a shared context cache when the design keeps durable data on a persistent tier. An architecture based on moving the KV cache into a storage tier covers the software side of that split, and the hardware side now arrives with 168,000 GiB attached to a single VM. Sizing and operating that split is the daily work of managed cloud infrastructure, where capacity, maintenance windows and durability live on one plan.

Sources

• Introducing Z4M: storage-optimized compute for AI/ML and parallel file systems, Google Cloud blog, 2026-11-06, cloud.google.com
• Storage-optimized machine family, Compute Engine documentation, Google Cloud, cloud.google.com

Source: the Google Cloud announcement of 6 November 2026 by bob Napaa and the Storage-optimized machine family page of the Compute Engine documentation, both read in full on 6 November 2026. Capacity, IOPS, throughput, the RDMA latency figure, the 1.4:1 ratio, the maintenance thresholds, the Hyperdisk figures and the partner quotes come from the announcement; the vCPU range, the 1,488 GB series ceiling, the bare-metal 1,536 GB figure, the Z4M highmem configurations and the Z4D and Z3 comparison come from the documentation.