Google’s Z4M Ships 168,000 GiB of Local SSD. The Ratio Is What You Buy.

Google made the Z4M machine series generally available as both virtual machines and bare metal. The headline is 168,000 GiB of local SSD in a single instance. The number that decides whether you can use it is 1.4 to 1.

That is the ratio Google advertises between local SSD throughput and network throughput, and it says the machine was sized so the fabric matches the disk instead of trailing it. Each instance carries up to 192 vCPUs, 1,536 GiB of memory and 400 Gbps of Cloud RDMA, on fifth-generation Intel Xeon Scalable processors paired with Titanium.

The load-bearing number is 875 GiB per vCPU

Google also publishes a per-vCPU figure, 875 GiB of local SSD for every virtual CPU, and it is the same fact as the capacity number. At the 192 vCPU ceiling the two multiply out to exactly 168,000 GiB. You are not buying a big disk. You are buying a fixed amount of disk per core, and the top of the range is just more cores.

That only pays off where the work reads large blocks locally instead of pulling them across a network. It covers the three workloads Google names, checkpointing, distributed KV cache and parallel file systems. The company claims 15.6M random-read IOPS and 75,600 MiB/s of sequential read, which it puts at up to 70 percent and 110 percent better than Z3. GPUDirect Storage and TPUDirect Storage carry the data onward at line rate, and Google puts the latency gain over TCP at up to 60 percent.

Local SSD is scratch, and scratch has no durability story

Local SSD in Compute Engine belongs to the instance, so the data does not survive a stopped instance. Z4M is aimed at data a job can rebuild, checkpoints and cache, not the system of record. Durable capacity comes from Hyperdisk instead, up to 512 TiB per instance, with Hyperdisk Extreme at 500K IOPS and 12,500 MiB/s.

Bare metal is the more interesting half. Google says the metal instances suit agentic workloads as isolated sandboxes, including with Agent Substrate. A dedicated host is a stronger isolation boundary than a shared one, and agent runtime vendors have spent the year arguing about exactly where that line sits.

The performance numbers carry a caveat. Silk reports 3.7 times lower latency and 6 times lower CPU use than TCP on Z4M, and WEKA reports roughly double the read throughput and up to 79 percent more IOPS than Z3. Both ran in their own labs, on their own storage stack, and both are Google partners.

Three questions before anyone sizes a pool. Does your file system read locally enough to use 875 GiB per vCPU, or will the fabric carry everything anyway? Can your checkpoint path survive a host that disappears? And can you place Z4M next to the GPU and TPU clusters it feeds, since Cluster Director is the piece that decides whether the data ever moves? Our look at why AWS put an SSD ceiling on its cheap Lustre tier runs the same arithmetic from the other end.