Compute

Day 0 support for Reflection’s Beam on Google Cloud: 5x faster perf with llm-d and NVIDIA Dynamo

Fri, 16 Oct 2026 17:00:00 +0000

Today, Reflection released Beam, its first open-weight model built to give developers, researchers, and enterprises open control and customization for frontier software engineering and long-horizon agentic tasks. Released under a permissive Apache 2.0 license with BF16, FP8, and NVFP4 checkpoints available at launch, Beam sets a new standard for inference efficiency in the 500B-parameter class by solving complex reasoning and coding problems with 3x to 4x higher reasoning compute efficiency than comparable open models.

Alongside today’s release, Google Cloud is announcing day 0 support and ready-to-run deployment recipes for serving Beam on Google Cloud AI Hypercomputer and NVIDIA AI Infrastructure.

To help developers get the full benefit of Beam’s token efficiency in production, we worked with Reflection to optimize performance of the underlying serving stack using llm-d (with vLLM) and NVIDIA Dynamo (with SGLang) on Google Cloud:

"By deploying our Beam model on Google Cloud, we achieved up to 5x higher performance and 8x lower latency to optimize serving of agentic workloads." - Joe Spisak, VP of Product & Head of Open Source, Reflection

With today’s day 0 release on Google Cloud, developers get:

Compounding model and system efficiency: Combining Beam’s 3x to 4x reasoning compute efficiency with system-level optimizations on A4X Max instances (NVIDIA GB300 NVL72) for up to 5x higher throughput and 8x lower latency,* and G4 VMs (NVIDIA RTX PRO 6000) for up to 2x higher throughput and 8x lower latency.*
High-efficiency multi-turn serving: KV-cache-aware routing, prefill/decode disaggregation, speculative decoding and hierarchical KV cache offloading to Host DRAM and Local SSD reduce redundant prompt recomputation across long coding sessions.
Turnkey optimized deployment: Our recommended performance optimized recipes for agentic workloads with llm-d and NVIDIA Dynamo are available in AI-Hypercomputer/gpu-recipes, llm-d repo and Model Garden in Gemini platform with a few clicks.

*Based on customer benchmarking

Scaling inference requires system-level optimization

When evaluating models for agentic coding and tool use, inference efficiency happens at two distinct layers: how efficiently the model reasons and how efficiently the serving system executes multi-turn loops.

Model-level efficiency: Reflection’s Beam

Reflection designed Beam (~501B total parameters with ~23B active parameters per token, and an approximately 1M-token context window) specifically for text-native software engineering and multi-step tool use. It plugs directly into the coding harnesses developers already use, including Reflection’s Mirror CLI, Claude Code, Hermes, OpenCode, and , to resolve GitHub issues, run CLI and DevOps workflows, and complete long-horizon tasks.

Because Beam activates only 23B parameters per token and reaches solutions using 3x to 4x fewer reasoning tokens than other comparable open weight models, it dramatically reduces the inference-time compute required for each reasoning step.

System-level efficiency: AI Hypercomputer optimized serving

Once developers deploy an agent into production, a second set of bottlenecks could appear at the serving layer. In an agentic coding loop, the model is called dozens of times in a single session. With every turn, the coding harness appends new file reads, code diffs, compiler logs, and tool outputs to a shared conversation history that quickly grows to tens or hundreds of thousands of tokens.

Even when the model itself generates 3x to 4x fewer reasoning tokens on each turn, the accumulated context window across turns creates two major infrastructure challenges:

First, prefill compute becomes a bottleneck. Standard Kubernetes load balancers distribute requests using stateless round-robin routing. When a coding harness sends Turn 15 of a session, it often lands on a different replica than Turn 14. That replica is forced to recompute the entire historical prompt from scratch, wasting GPU compute and creating long prefill queues that delay other users.

Second, decode becomes bottlenecked by KV cache capacity. Holding long-context KV caches for dozens of concurrent agent sessions quickly fills up GPU High-Bandwidth Memory (HBM). Once HBM fills up, the serving engine has to evict older KV blocks. As soon as those blocks are evicted, cache hit rates drop and GPU throughput stalls.

To preserve Beam’s model-level efficiency at cluster scale, the serving stack has to be optimized as a distributed system. That is why our recipes pair Beam with llm-d (with vLLM) and NVIDIA Dynamo (with SGLang).

Inside the AI Hypercomputer inference architecture

To run Beam’s BF16, FP8, and NVFP4 checkpoints at peak efficiency on Day 0, we designed a vertically integrated architecture on AI Hypercomputer where each layer handles a specific part of the agentic serving lifecycle.

System optimized architecture for serving agentic traffic

Rather than treating inference pods as stateless endpoints, each layer of the stack is co-designed around the multi-turn agent lifecycle:

Prefix- and load-aware routing (GKE + llm-d EPP / Dynamo router): Tracks cached prefixes and queue depth across worker pods, steering each follow-up turn from a coding harness to the replica holding its warm KV prefix while preventing queue saturation via turn-priority flow control.
Disaggregated compute and speculative decoding (A4X Max & G4 instance): Runs vLLM and SGLang with native Blackwell NVFP4, Expert Parallelism (EP) for Beam’s 23B active experts, Data-Parallel Attention, and DFlash2 speculative decoding. Separating Prefill and Decode (P/D) pools ensures heavy prompt bursts never stall active token generation.
Tiered KV cache (GPU Memory -> DRAM & Local SSD) Active KV blocks stay in high-bandwidth GPU memory (Tier 1), while warm KV blocks evicted during long-horizon sessions overflow into host CPU DRAM and local NVMe SSDs (Tier 2) via vLLM’s OffloadingConnector or SGLang's HiCache, allowing historical context to be fetched in milliseconds instead of recomputed from scratch.

System optimizations for multi-turn agentic workloads

When serving multi-turn coding and tool-use workloads like the AgentX trajectory dataset across rising concurrency levels, each layer in the serving stack contributes to the performance and latency improvements for multi-turn, long context traffic patterns of agentic workloads:

A note on reading these charts. The two configurations are not comparable to each other. NVIDIA Dynamo ran on A4X Max instances with 32 x NVIDIA GB300 NVL72GPUs; llm-d ran on G4 VMs with 8 x NVIDIA RTX PRO 6000 GPUs. Each chart shows the gain over a baseline on the same hardware. More replicas give the router more warm KV caches to hit and more room to split prefill from decode, so the uplift grows with the deployment. Both llm-d and NVIDIA Dynamo scale up and down to match the underlying infrastructure.

NVIDIA Dynamo optimized perf vs baseline deployment of Reflection's Beam

llm-d optimized perf vs baseline deployment of Reflection's Beam

Across both platforms, layering these optimizations shifts the Pareto frontier to deliver higher output throughput and faster per-user interactivity simultaneously:

Baseline deployment (Stateless round-robin routing). In a standard Kubernetes deployment without prefix awareness, consecutive turns from the same coding session land on different replicas, forcing constant prefill recomputation on historical context and causing throughput to plateau as concurrency scales.
KV-cache-aware & flow control routing. Enabling prefix-aware routing in NVIDIA Dynamo or llm-d’s Sticky EPP with turn-priority flow control keeps multi-turn agent trajectories pinned to the replica holding their warm KV cache, immediately cutting Time-to-First-Token (TTFT) latency and freeing up GPU compute, resulting in a significant increase in token throughput.
Host DRAM and Local SSD (LSSD) KV offloading. Offloading evicted KV blocks from GPU memory into host DRAM and local NVMe SSDs prevents cache thrashing when dozens of long-context coding sessions exceed on-device GPU memory capacity.
Disaggregated serving, speculative decoding, and KV pool tuning. Tuning hybrid KV cache memory allocation, enabling speculative decoding, and disaggregating prefill and decode workers isolates token generation from heavy prompt bursts while the draft model multiplies output throughput to keep per-agent token interactivity fast.

Get started and meet us at PyTorchCon and GTC Berlin

This blog explored how you can leverage system level optimizations to scale performance to serve Reflection's Beam family of models for agentic workloads. All of the Kubernetes manifests, router configurations, and benchmarking scripts from this post are open-source and ready to run on your own GKE cluster.

Deploy the optimized stack: Explore the day 0 guides for running Reflection’s Beam with llm-d and NVIDIA Dynamo in the AI-Hypercomputer/gpu-recipes repository on A4X Max and G4, and Model Garden in Gemini platform.
Download the weights: Grab the Apache 2.0 BF16, FP8, and NVFP4 checkpoints on Reflection’s Hugging Face page.
Visit us at the llm-d and PyTorch Conference in San Jose: If you are attending PyTorch Conference North America in San Jose this October, stop by the llm-d community sessions and the Google Cloud booth #. We will be walking through live demos of KV-cache-aware routing, P/D disaggregation, and KV cache tiering for agentic workloads.
Come see us at NVIDIA GTC Berlin: If you are attending NVIDIA GTC Berlin, come connect with us at our booth #3026, or our Google Cloud Hub at w3.hub: just a short 5 minute walk from the venue. Learn more about our sessions.

Introducing Google Cloud’s U4 compute: Enabling ultra-low latency trading

Wed, 07 Oct 2026 16:00:00 +0000

In capital markets, operational success is built on predictable performance and low latency, where even tiny variations in packet timing alter queue priority and trade execution. At the same time, both exchange venues and their participants face mounting constraints in traditional on-premises data centers — from power and physical rack space limits to lengthy hardware procurement cycles. Increasingly, global capital markets seek the speed and determinism of physical co-location combined with the dynamic scalability and automation of the cloud.

At Google Cloud Next ‘26, we announced the Ultra Low Latency (ULL) Solution, now generally available, providing high-frequency trading workflows that run in the cloud with an ultra-low latency network and agility. The ULL Solution includes the new U4 machine family, also generally available today.

The ULL Solution is based on three infrastructure pillars:

Hardware-level networking: Scaleable, hardware-based multicast data distribution for reliable market-data feeds
Advanced networking observability: Dynamic network traffic capture with hardware-level timing accuracy, facilitating consistent auditing, market replays, and absolute trade validation without impacting primary traffic performance
Deterministic high-performance compute: Processing of latency-critical execution tiers in a highly predictable, consistent amount of time, every single time

Taken together, the ULL Solution’s compute, storage, networking, and observability provide financial exchanges and market participants with a number of technical capabilities:

Bare metal performance: Dedicated bare metal compute provides direct access to physical host resources, minimizing jitter and delivering predictable, low-latency execution for market-data feeds and order routing.
High-performance storage options: Local Titanium SSDs handle real-time transaction and tick logging on the host, complemented by scalable Google Cloud Hyperdisk for persistent market data archives and analytics.
Physical traffic isolation: The ULL trading fabric’s redundant A/B multicast market feeds are accessed through two independent and dedicated Titanium adapters, while an independent third Titanium adapter offloads telemetry, management, and provides access to Google Cloud services.
Hardware-accelerated multicast distribution: The ULL network architecture supports hardware-level multicast feed ingestion. This allows participants to stream high-throughput market data directly to low-latency trading applications, bypassing traditional hypervisor-level virtual switches.
Accelerated packet processing: Support for OpenOnload and DPDK enables Linux user-space networking to deliver predictable unicast and multicast packet handling while minimizing application code changes.
Precision timing and UTC synchronization: Integration with Google Cloud’s Firefly clock synchronization system allows the solution to consistently achieve sub-10 nanosecond network-level timestamping and better synchronization to UTC than the sub-100 microsecond regulatory requirement for financial exchanges.
Built-in telemetry: 24/7 low-latency packet capture and seamless out-of-band packet brokering for regulatory compliance and real-time analytics helps ensure deep visibility without impacting primary traffic performance.
24-7 market ready: The solution is designed for continuous, round-the-clock trading readiness by isolating production workloads in a dedicated primary zone for live trading, while routine cloud maintenance and qualification testing occur in a secondary zone for updates and testing.

Compute in the ULL Solution is delivered by the new U4 machine family, which brings predictable performance and ultra-low latency compute in three specialized machine series: dual-socket bare metal instances with three physical NICs — U4P for exchange operators and U4C for market participants — alongside U4S high-performance VMs for operators, participants, and service providers.

Machine Series	CPU Platform	CPU Cores	Memory	NICs	Storage Options
U4P (Bare Metal)	Intel 5th Gen Xeon (Emerald Rapids)	120 Physical Cores	512 GB or 768 GB	3 Physical (1 Standard + 2 ULL)	Local Titanium SSD (12 TiB), Hyperdisk
U4C (Bare Metal)	Intel 5th Gen Xeon (Emerald Rapids)	120 Physical Cores	512 GB or 768 GB	3 Physical (1 Standard + 2 ULL)	Local Titanium SSD (12 TiB), Hyperdisk
U4S (VM)	Intel 6th Gen Xeon (Granite Rapids)	2 to 288 vCPUs	Up to 2,232 GB	Multi-vNIC (Up to 200 Gbps)	Local Titanium SSD (18 TiB), Hyperdisk

Machine Series

CPU Platform

CPU Cores

Memory

NICs

Storage Options

U4P

(Bare Metal)

Intel 5th Gen Xeon (Emerald Rapids)

120 Physical Cores

512 GB or 768 GB

3 Physical (1 Standard + 2 ULL)

Local Titanium SSD (12 TiB), Hyperdisk

U4C

(Bare Metal)

Intel 5th Gen Xeon (Emerald Rapids)

120 Physical Cores

512 GB or

768 GB

3 Physical (1 Standard + 2 ULL)

Local Titanium SSD (12 TiB), Hyperdisk

U4S

(VM)

Intel 6th Gen Xeon (Granite Rapids)

2 to 288 vCPUs

Up to 2,232 GB

Multi-vNIC (Up to 200 Gbps)

Local Titanium SSD (18 TiB), Hyperdisk

We developed the U4 machine family to enable the world’s most technically demanding markets to run within Google Cloud and benefit from cloud services and scale. An example of this is our ongoing collaboration with CME Group, through which we are migrating listed derivatives markets to Google Cloud. Here, the U4C and U4P bare metal instances deliver direct physical co-location latency parity, providing predictable low-latency clock precision, and native hardware-multicast feed ingestion. This architecture demonstrates that core exchange systems and trading strategies can run in the cloud with the speed, consistency, and control that financial markets require.

"Migrating the world’s leading derivatives marketplace to the cloud requires uncompromising performance, latency, and reliability. Google Cloud’s Ultra Low Latency Solution and the U4 instance families represent a breakthrough for financial market infrastructure. By combining deterministic, ultra-low latency networking and dedicated bare metal compute with the benefits of the cloud, market participants can execute and ingest market data and execute with the speed of traditional co-location and the agility of the cloud." - Pearce Peck-Walden, Managing Director Markets Engineering, CME Group

Powered by Google Cloud-native infrastructure

The ULL Solution is available in select private Google Cloud regions, where trading teams can leverage core cloud infrastructure benefits such as rapid automated resource provisioning, on-demand capacity scaling, and dynamic fleet management. Trading teams can execute ultra-low latency trades on a dedicated, isolated ULL network, and offload data streams over an independent network interface to Google Cloud services such as BigQuery and Gemini Enterprise.

For exchange participants managing tick-to-trade workflows or processing real-time market data, microsecond variations are critical. As bare metal instances, U4P and U4C machine series don’t add any virtualization overhead for latency-sensitive execution tiers. Leveraging Google Cloud's Titanium offload system architecture, these bare metal instances provide direct access to the host resources. Compute Engine instances enable users to provision dedicated hardware through standard Google Cloud APIs, orchestrate deployments with infrastructure as code, apply Cloud Next Generation Firewall (NGFW) policies, and collect rich telemetry.

The U4S VM series complements these bare metal offerings for applications such as pre-trade risk validation and real-time analytics. Deployed alongside U4P and U4C instances, these VMs shorten transit hops across the trading architecture while offering elastic scaling from 2 to 288 vCPUs and networking up to 100 Gbps.

“Our testing of the U4 instances validated that Google Cloud delivers the low latency and determinism required for our demanding exchange trading workloads. Having both bare metal and VM options allows us to evaluate the value of that performance relative to its cost, helping us align the right infrastructure to each of our trading strategies.” - Corbin Kidd, EVP/CTO, Prime Trading

"In our tick-to-trade performance testing, the U4C bare metal instance demonstrated exceptional speed, showing that cloud compute and ultra-low latency networking can comfortably satisfy microsecond trading demands. But, what sets the U4 series apart isn't just raw processing speed, it’s structural determinism. When we stress-tested Google Cloud's U4 bare metal family, the performance curve remained virtually flat, which confirms that these cloud compute layouts can now offer the strict determinism institutional market participants require." - Christopher Wilson, Global Head of Experience Modernization, 28Stone

Looking to the future, this low-latency architecture serves as the foundation for algorithmic trading, allowing firms to feed real-time markets directly into AI-driven trading models.

Storage and placement for trading workloads

The U4 family supports Google Cloud storage options and placement policies, helping trading teams record trades at speed and minimize network latency between machines:

Local Titanium SSD for fast logging: For real-time trade logging and data caching without slowing down execution, U4P and U4C provide up to 12 TiB of direct-attached NVMe SSDs, and U4S VMs scale up to 18 TiB.
Hyperdisk for data archives: For historical market data, backtesting models, and regulatory archives, you can attach Hyperdisk Balanced and Hyperdisk Extreme volumes across all U4 series, scaling up to 32 volumes and 512 TiB per instance.
Placement policies: To reduce physical network hops, compact placement policies keep related machines close together in the data center. Alternatively, spread placement policies place machines on separate racks to improve resiliency.

Getting started with the ULL Solution

With the ULL Solution, financial exchange operators, exchange participants, and trading service providers can execute trades with the speed and reliability they need today while positioning their businesses to leverage continuously evolving AI and infrastructure capabilities for the trading of tomorrow. The ULL Solution is available in select Google Cloud regions. To learn more, check out the public documentation, and reach out to our team to request access.

GKE CPU startup boost: Accelerate app starts without over-provisioning

Fri, 02 Oct 2026 16:00:00 +0000

Whether you’re launching microservices in response to sudden traffic spikes, deploying new software releases, or scaling up application replicas, pod startup time is critical to maintaining a fast, responsive user experience for applications running on Google Kubernetes Engine (GKE).

Yet, platform engineers and developers face a persistent dilemma: Applications often demand significantly more CPU power during startup than they do during steady-state operations. Sizing CPU requests for normal, steady-state usage leads to CPU throttling during launch, which can result in sluggish cold starts and readiness probe timeouts. On the flip side, over-provisioning baseline CPU requests to satisfy short-lived startup bursts wastes valuable compute resources, inflating infrastructure bills.

Today, we are excited to announce CPU startup boost for GKE in preview. Integrated directly into GKE's Vertical Pod Autoscaler (VPA), CPU startup boost dynamically elevates a container's CPU allocation during initialization and seamlessly scales it back to baseline steady-state levels once the application is ready - all without restarting your containers.

Why modern applications need extra CPU at boot time

When a new container launches, it may perform intensive initialization tasks before it begins serving user requests. Depending on your tech stack, the following startup workloads require substantial CPU cycles:

Java JVM applications: Frameworks like Spring Boot require high CPU burst capacity for class loading, classpath scanning, instantiating dependency injection containers, and running Just-in-Time (JIT) compilation.
Node.js servers: Apps parse JavaScript files, build complex module dependency trees (require/import), and execute V8 engine optimization and JIT compilation passes during initial execution.
Python and AI/ML microservices: These services spend initial cycles importing heavy libraries (such as PyTorch, NumPy, or LangChain), compiling .pyc bytecode, establishing ORM database schemas, and pre-loading cache structures.

If you size CPU requests strictly for steady-state performance, these initialization workloads experience CPU throttling on launch, delaying readiness probes. To prevent slow cold starts, teams frequently overprovision CPU requests. However, once the application stabilizes, those extra CPU resources sit idle, increasing your cloud spend without adding value.

How CPU startup boost can help

CPU Startup Boost solves this by giving your workloads temporary vCPU "boosts" during launch, and automatically returning them to baseline once initialization completes.

Key benefits:

Faster cold starts: Reduce application initialization times by up to 2x, accelerating auto-scaling responsiveness during unexpected traffic surges.
Optimized cloud spend: Right-size steady-state CPU requests to fit actual runtime needs rather than paying for idle startup headroom.
Zero pod restarts: Dynamic resource resizing happens live inside the running container.
Flexible policy controls: Apply simple pod-level multiplier factors (e.g., 2x CPU during startup) or define granular, container-specific rules for complex multi-container pods.

Under the hood: Kubernetes In-place Pod Resize

Historically, changing a pod's resource requests or limits required deleting and recreating the pod. This disruptive process triggered container restarts, cache invalidation, and node rescheduling overhead.

To fix that, CPU startup boost builds on Kubernetes In-place Pod Resize (IPPR).

Tracked under KEP-1287, IPPR introduced dynamic, in-place resource mutation. Introduced as Alpha in Kubernetes 1.27, promoted to Beta in v1.33, and graduating to General Availability (GA) in v1.35, IPPR allows the Kubernetes control plane and kubelet to update container CPU and memory requests on running pods without restarting the container process.

GKE leverages IPPR within the VPA to apply startup CPU boosts at pod admission and smoothly step them down post-readiness.

How CPU startup boost works (pod lifecycle overview)

CPU startup boost operates across three distinct phases:

Admission phase: When you deploy a pod, the VPA admission webhook intercepts the creation request. It calculates the elevated CPU request based on your policy (e.g., 2x multiplier or +2 vCPUs) and injects the boosted CPU request along with tracking annotations into the pod spec.
Startup phase: The pod is scheduled and initialized with the boosted CPU allocation. Your application completes class loading, JIT compilation, or module parsing at top speed without experiencing CPU throttling.
Unboosting phase: As soon as the pod's readinessProbe passes (plus any configured durationSeconds cooldown delay), the VPA updater issues an in-place resize request. The CPU request steps back down to your baseline level while the container continues running uninterrupted.

Prerequisites and availability

CPU startup boost is available today in preview on GKE:

GKE version: Version 1.36.0-gke.4447000 or later on Standard and Autopilot clusters.
Cluster Modes: Enabled natively on GKE Autopilot (VPA is active by default). On GKE Standard, simply ensure Vertical Pod Autoscaling (VPA) is enabled.
Workload Support: Works with standard Kubernetes controllers, including Deployments and StatefulSets.

Getting started: Configuring CPU startup boost

Configuring CPU startup boost is as simple as adding a startupBoost section to your VerticalPodAutoscaler manifest.

Example 1: Pod-level boost with fixed steady-state (`updateMode: "Off"`)

If you want to use VPA purely for startup boost while keeping steady-state CPU requests locked to your manifest definitions, set updateMode to "Off":

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: java-app-startup-boost\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: java-app\r\n updatePolicy:\r\n updateMode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 2\r\n durationSeconds: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd249764e90>)])]>

In this example, GKE doubles the container's CPU request during launch and holds the boosted allocation for 10 seconds after readiness probes pass before scaling back to baseline.

Example 2: Combining startup boost with continuous VPA auto-scaling

If you want GKE to boost CPU during launch and continuously optimize steady-state resources post-startup, set updateMode to "InPlaceOrRecreate":

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: nodejs-app-vpa\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: nodejs-service\r\n updatePolicy:\r\n updateMode: "InPlaceOrRecreate"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 3\r\n durationSeconds: 15'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd249767d90>)])]>

Example 3: Granular container-level boost

For pods running sidecars (such as logging agents or service mesh proxies) that do not require extra CPU on boot, target specific app containers:

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: app-container-boost\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: API-gateway\r\n updatePolicy:\r\n updateMode: "Off"\r\n resourcePolicy:\r\n containerPolicies:\r\n - containerName: "web-app"\r\n mode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Quantity"\r\n quantity: "2"\r\n durationSeconds: 5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd249767b10>)])]>

Verifying startup boost in your cluster

You can verify that GKE applied and downscaled the startup boost using kubectl:

1. Inspect pod annotations: Check for the vpaCpuStartupBoost tracking annotation:

code_block: <ListValue: [StructValue([('code', 'kubectl get pod <POD_NAME> -o yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd249765fd0>)])]>

Look for annotations indicating the original baseline and boosted CPU requests.

2. Monitor in-place resize events: Confirm that GKE downscaled the CPU request back to baseline after readiness:

code_block: <ListValue: [StructValue([('code', 'kubectl get events --field-selector reason=InPlaceResizedByVPA'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fd249766d10>)])]>

An event with reason=InPlaceResizedByVPA confirms successful in-place downscaling post-startup.

Best practices for production workloads

Pairing with Horizontal Pod Autoscaler (HPA): When using HPA alongside CPU startup boost, ensure a robust readinessProbe is defined and keep durationSeconds short (e.g., 0s–10s). This prevents HPA from falsely interpreting initialization CPU spikes as high steady-state load.
Handle traffic spikes with GKE capacity buffers API: By reducing the startup tax at scale, you can achieve higher workload density on fewer nodes to improve overall utilization. Consider adopting the GKE capacity buffers API to absorb sudden traffic surges with minimal operational overhead while maintaining strict SLOs.
GKE Autopilot resource ratios: On GKE Autopilot, remember that pods must maintain valid CPU-to-memory ratios. Ensure baseline memory allocations accommodate the boosted CPU ratio during startup.

Get started today

CPU startup boost gives GKE users the best of both worlds: lightning-fast cold starts for CPU-intensive workloads like Java, Node.js, and Python, paired with maximum resource efficiency and lower cloud costs.

Ready to accelerate your GKE workloads?

Explore the GKE CPU startup boost documentation.
Learn more about Vertical Pod Autoscaling on GKE.
Try CPU startup boost on your GKE Standard or Autopilot clusters running GKE 1.36.0-gke.4447000 or later!

What’s new in AI infrastructure and orchestration in September

Wed, 30 Sep 2026 16:00:00 +0000

We hereby declare September to be scalability month! As the world prepares for a surge of agentic fleets, we are shoring up our AI infrastructure and orchestration offerings to gracefully — and quickly — respond to that demand, all while maintaining workload isolation and security, and keeping costs in check. Read on to learn how these enhancements manifest across Google Cloud’s compute, network, storage, and orchestration offerings, plus new ways customers are using Google Cloud AI infrastructure, and third-party industry validation of our strategy.

Product, technology, and tools updates

Google Kubernetes Engine updates: The GKE team is all about improving the scalability of the platform, and in September, those improvements came in many shapes and sizes:

New feature: Need an execution runtime with higher density for your agentic workloads? We engineered the new open-source GKE Agent Substrate to run millions of sandboxes with 10x higher density than standard container runtimes. Agent Substrate also delivers sub-500ms resume operations at over 500 suspend/resume activations per second with a native zero-trust kernel and network isolation.
Product update: GKE now has scale-to-zero capabilities built-in. No need to configure complex components to scale your workloads down, thanks to the HPA with the Autoscaling Metric and support for KEP-2021, which do the job for you, out of the box. Read the blog to learn more.
Product update: Further, the GKE HPA (with the above-mentioned Autoscaling Metric) now lets you scale up and down based on custom PromQL metrics, in addition to standard metrics, allowing you to trigger workloads according to conditions that are meaningful and unique to your business. Read more here.
New feature: Yet another scalability feature is GKE Pod snapshots, which lets you save the running state of your workload, including CPU and GPU memory, and restore it on demand. According to internal tests, GKE Pod snapshots can reduce AI inference start-up by as much as 89%. Learn more here.
New migration tool: Finally, if you’ve always wanted to migrate your container workloads from AWS EKS to GKE but feared a daunting, high-friction engineering endeavor, we’ve just launched GKE agentic migration, a purpose-built agent plugin that replaces brittle, ad-hoc prompting with an AI-assisted migration pipeline protected by deterministic guardrails. Designed as a compilation of agent skills and a local Model Context Protocol (MCP) server, it uses AI to translate complex AWS EKS IaC and Kubernetes manifests directly into GKE landing zones. Get started with the onboarding guide.
Feature updates: Reinforcement learning (RL) and evaluation workloads are a beast: In a standard agentic RL loop, an LLM policy generates actions like code snippets on GPUs and executes them inside isolated CPU sandboxes to observe a reward signal. However, when scaling up this loop to support tens of thousands of parallel rollouts, infrastructure bottlenecks emerge, for instance idle accelerators, image cardinality, and a saturated control plane. To help, we developed GKE Agent Sandbox optimized for RL, plus an Agent Sandbox RL orchestration SDK and native integrations for popular RL gyms and harnesses. All are now generally available, and you can learn more here.

Storage updates: AI trains and creates lots of data, and that data has to live somewhere — in block storage systems, file systems, object stores and databases. We announced enhancements to our storage portfolio to help this critical layer roll with the agentic punches:

Product update: Filestore agent volumes offer high-performance, elastic, persistent file storage for agentic workloads. Thanks to its tight integration with GKE Agent Substrate and GKE Agent Sandbox, Filestore agent volumes automatically allocates and attaches a dedicated, isolated file workspace to GKE agent sandboxes in milliseconds. Request access to the preview here.
New product: If you run generative AI and RAG data layers — think Milvus, Pinecone, Qdrant, Vespa, Redis, and in-memory context caching — you may want to take a look at the M4N family of VMs, now GA, which offers the highest per-core IOPS and throughput of leading hyperscalers. Paired with Google Cloud's custom Titanium offload architecture and paired with Hyperdisk Extreme, M4N instances deliver up to 25,000 MiB/s (25 GiB/s) of aggregate host storage performance and up to 1 million IOPS.
New product: Another new Compute Engine product, Z4D, is GA, and a strong storage solution for AI/ML training and inference workloads. When configured as a bare metal instance, Z4D provides both the high local SSD (LSSD) capacity and low latency required by agentic microVMs, so you can run thousands of isolated sandboxes per host with native performance and efficiency. Learn about Z4D machines here.
Product update: Today’s AI training and inference pipelines create data faster than most storage management systems can keep up, creating challenges for teams trying to understand their storage estates. A new version of Storage Intelligence advisor makes it easier to answer the question: "What’s in my buckets?" and quickly identify unexpected changes. Then, enhanced batch operations let you automate bulk changes across your buckets — say, move storage classes, mass-delete stale or temporary data, or apply metadata, tagging, retention, or encryption changes. Learn about the latest in Storage Intelligence advisor here.
New product: Last but not least, a new version of AlloyDB for PostgreSQL brings together pioneering Google infrastructure — Colossus distributed file system, and Jupiter network — to power a new, no-compromises database architecture for the agentic era.

Practitioner guides and how-tos

How-to: Wish you could make GPUs and TPUs scattered around the globe behave as a single pool behind a single entry point? In this blog, we show you how to do just that. At the edge, the multi-cluster GKE Inference Gateway focuses on global, multi-region traffic distribution and high availability. Beneath that, the LLM-d router handles complex, memory-aware scheduling algorithms to keep utilization high. This architecture is deliberately runtime-, model-, and accelerator-agnostic, and in tests, routing traffic through the multi-cluster GKE Inference Gateway added less than 1% overhead.
Guide: Using or planning to use GKE on TPUs for AI model training or inference? Training massive Large Language Models (LLMs) or running high-throughput inference serving represents a significant investment in specialized AI hardware, such as Cloud TPUs and GPUs. To get the most out of every dollar spent, you need to understand workload lifecycle metrics in GKE. This detailed guide explains how to turn opaque cluster behaviors into actionable telemetry.

Customer and partner updates

GKE customer: Learn why gaming startup SeaVerse relies on GKE Agent Sandbox for its multi-tenant workloads, and how the platform helped it decrease its infrastructure costs by 60%.

Research, reports and deep-dives

In case you missed it, we’re also thrilled to share that Google has been named a leader, including achieving the highest score on either product or strategy, in three key analyst reports from Gartner and Forrester.

Google is a leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026: Highest overall score of any cloud provider!
Google named a Leader in 2026 Gartner® Magic Quadrant™ for Strategic Cloud Platform Services: Positioned furthest for “Completeness of Vision” of all vendors evaluated.
Google is a Leader in the 2026 Gartner Magic Quadrant for Container Management: Positioned highest in “Ability to Execute” of all vendors evaluated.
Google Cloud achieved a Gold rating in the latest SemiAnalysis ClusterMax 3.0 report, which evaluates the reliability, performance, support, pricing, and security of GPU providers globally. See the full report for more.

August 2026

Product, technology, and tools updates

Product update: Filestore, Google Cloud’s first-party, secure, scalable NFS file service, has emerged as a popular storage platform for AI and agentic workflows, and now, it’s even better suited to the task, with a new backend storage layer built directly on Colossus, Google’s foundational distributed storage system. This new backend lets you provision IOPS independently from storage capacity, and is deeply integrated with GKE. In AI environments, this can help you service so-called agentic swarms — large groups of agents that need to read and write to a common dataset — without a drop off in performance. For more, check out the blog post.
New feature: gVisor sandboxes are now available in distributed Ray clusters on GKE. In partnership with Anyscale, we introduced an experimental library for Ray that brings gVisor, Google’s open-source application kernel, directly into distributed Ray clusters. gVisor provides lightweight environments with stronger isolation than ordinary containers, plus fast startup times and low memory overhead. To try out these sandboxing capabilities on GKE, head over to the Ray sandboxing User Guide.
Product update: Looking for high-performance, easy-to-use infrastructure on which to run a personal AI agent, but don’t want to spend a lot of money? New Cloud Run instances are dedicated, singleton compute runtimes on Cloud Run that won’t shut down when the agent is idle. Better yet, the cost to run a Cloud Run instance with 1 vCPU and 1 GiB of memory continuously for 30 days is just $5.70.

Practitioner guides, documentation and how-tos

How-to guide: Big news in Model Context Protocol (MCP) land: As of the 2026-07-28 specification, the protocol core is “completely stateless. The handshake is gone. The initialize / initialized handshake (SEP-2575) and the logical Mcp-Session-Id header (SEP-2567) have been removed entirely. Instead, every request is now self-describing and independent.” Whoa. Learn more about the changes that the latest MCP specification brings, and more importantly, how to implement them, in this Google Developers blog.
Guide: Real-time AI systems make a mess of traditional network load balancing techniques. “Instead of handling isolated requests, the backend has to manage a continuous, live bidirectional stream. You’re dealing with a constant stream of audio chunks, transcripts, model outputs, and synthesized speech flowing back and forth simultaneously.” Things only get worse when the user gets involved. “The server has to immediately halt its current speech generation, pivot to update the context, maybe trigger a new tool, and start drafting a different response; this must be done without dropping the connection.” For a new approach to managing load in the AI era, read Scaling real-time AI agents with session-aware load balancing.
How-to: Learn how to build an elastic, scalable LLM inference platform on GKE, even with a mix of different GPU accelerators. The proposed architecture combines Capacity Advisor and Compute Advisor, plus high-performance storage like RunAI:model streamer or GCPFuse with parallel downloads. Get all the details here.
Documentation: The thing about hosts with GPUs or TPUs is that you can’t use live migration to update them, setting up a maintenance challenge. In this new docs page, learn how to update accelerator-equipped hosts according to your tolerance for downtime for your training and inference workloads.
Documentation: Advanced Compute Images, or ACIs, are standardized image stacks for AI/ML and HPC infrastructure, so you don’t need to manually build your own custom images. In this new docs page, learn how to create an ACI image using the Google Cloud CLI, console, or SchedMD's Slurm workload manager.
Guide: AI workloads are notoriously difficult to architect, resource-intensive, and bursty, which can also lead to scaling bottlenecks and large pools of underutilized — or misutilized — compute resources. A new blog outlines the three main ways to achieve dynamic capacity management in Google Cloud: 1) scheduling capacity for planned downtime; 2) maintaining automated fallback capacity for unplanned downtime; and 3) relying on GKE’s core orchestration capabilities to automate resource allocation.

Customer and partner updates

Business orchestration software provider UiPath was dealing with spiky workloads, and wanted more predictable costs. To get there, it re-architected its infrastructure, moving from isolated clusters to a shared Google Cloud GPU fleet that included both A3 VM instances (NVIDIA H100 GPUs) for training with G4 VM instances (NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs) for inference. You can read more about their architecture here.
Mirendil, an frontier AI lab focused on accelerating AI development, announced that it is using AI Hypercomputer with both TPUs and NVIDIA GPUs to support its model pre-training and post-training applications.
Replenit, a retail CRM provider, built its AI decision engine in Google Cloud, using BigQuery, Gemini Enterprise Agent Platform, and open-source Gemma models that it runs on Cloud TPUs. This latter combination provided Replenit with 90% lower pipeline costs than their previous cloud provider, the company reports. Read the full case study for more.
Malachyte architected its AI-powered e-commerce recommendation platform on top of Bigtable, Managed Service for Apache Kafka, Pub/Sub, Compute Engine, and last but not least, GKE. See how it all comes together in this blog.

July 2026

Product, technology, and tools updates

Product update: Google Cloud Managed Lustre is now GA, and available in four distinct performance tiers that deliver throughput ranging from 125 MB/s, 250 MB/s, 500 MB/s, to 1000 MB/s per TiB of capacity — with the ability to scale up to 8 PB of storage capacity. The Managed Lustre solution is powered by DDN’s EXAScaler, combining DDN's decades of leadership in high-performance storage with Google Cloud's expertise in cloud infrastructure.
Product update: C4N network and storage optimized VMs are now GA. C4N is our first network- and block-storage-optimized VM series built to eliminate data-transfer bottlenecks. Powered by 5th Gen Intel Xeon Scalable processors and built on Google's Titanium offloading hardware, it achieves 400 Gbps network bandwidth, 95 million packets per second (MPPS), and up to 25 GiB/s of block storage throughput when paired with Hyperdisk Extreme.
New feature: GKE Dataplane V2 up to 15K Nodes with Network Policies (GA). This capability enables standard GKE clusters to scale up to 15,000 nodes while maintaining full active Network Policy enforcement, supporting the massive infrastructure needs of large enterprise and AI/ML customers.
New feature: Co-operative time-slicing in llm-d. If you’re running reinforcement learning (RL) workloads, you can now interleave independent RL jobs onto shared physical hardware, increasing aggregate accelerator duty cycles from a ~40% baseline up to 70% without impacting model convergence or accuracy.
New AI security tool: Looking to secure your AI supply chain on GKE, deploy AI workloads safely, and cut down on shadow AI? We open-sourced k8s-aibom, a lightweight, unprivileged Kubernetes controller that continuously monitors container clusters to automatically detect running AI runtimes (like vLLM and Triton) and generate standard CycloneDX Machine Learning Bill of Materials (ML-BOMs). Check out the k8s-aibom project and get involved.

Practitioner guides and how-tos

How-to guide: On July 27, Google announced Day 0 support for Moonshot AI’s Kimi K3 2.8-trillion-parameter open-weight model, the day weights were released. Whichever your preferred deployment path — via Model Garden, custom orchestration, or GKE with llm-d recipes — this guide offers detailed step-by-step instructions to help you evaluate and pilot Kimi K3 in Google Cloud.
How-to guide: Google Kubernetes Engine (GKE) managed DRANET supports both GPUs and TPUs. There are several configurations to use this implementation, including standard cluster (where you have full control) and autopilot cluster (where Google does the heavy configs for you). Take a deeper dive in the hands-on lab, GKE Autopilot clusters with TPUs, GKE managed DRANET and Gemma 4.
How-to guide: Learn to run Ray on TPUs, not GPUs. In Part 1 of this two-part series, we discuss TPU slices (hint: Ray thinks of them as just another accelerator on which to schedule), then walk through Ray’s various AI libraries (Part 2).
How-to guide: Evaluate TPUs for sample workloads using a new microbenchmark suite that helps you accurately assess whether a device is achieving its theoretical performance specifications, and to identify specific performance gaps or architecture-specific bottlenecks. Dive in here.
How-to guide: Scale your agents without killing your budget. Learn how GKE orchestration can help you safely pack more agents onto a fixed compute footprint with GKE Agent Sandbox and Pod snapshots. Whether your goal is performance or cost optimization, we teach you how to turn the right dials for optimal agent efficiency.
Technical blueprint: Inside the optimization of Mistral 3 large inference on Ironwood. This blog outlines how one Google team optimized Mistral 3 large MoE model inference on Google’s Ironwood (TPU v7x), achieving a 1.5x performance gain. They did so with hybrid sharding, replacing linear VPU summations with tree reductions, optimizing GMM/MLA kernels, and adopting asynchronous scheduling. As a result, they boosted throughput by up to 48% while maintaining benchmark accuracy neutrality. Read the full blog here.

Research, reports and deep-dives

Report: Google was named a Leader in the inaugural GartnerⓇ Magic Quadrant™ for AI Infrastructure, positioned highest for ‘Ability to Execute’ and furthest for ‘Completeness of Vision’. Gartner called out Google’s proprietary scalable compute, integrated AI Hypercomputer architecture, and the scale of our AI compute capacity as key strengths. Download a copy here.
Report: We recently surveyed more than 1,400 senior IT leaders for our State of AI Infrastructure report, and a resounding pattern emerged: The gap between AI ambition and infrastructure reality is widening. In fact, 83% of organizations say they require infrastructure upgrades to support production-grade agentic AI. Read the accompanying blog to understand how adapting your infrastructure to meet the demands that agentic applications place on your systems will help you move from pilot to production.

June 2026

Product, technology and tool updates

Product update: Protecting sensitive data used with AI is a critical part of advanced and secure cloud infrastructure. Confidential Computing cryptographically protects data in use in hardware-based Trusted Execution Environments (TEEs) with verifiable data integrity, and is now available on the accelerator-optimized G4 machine series, featuring NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. Get started with Confidential G4 VMs and Confidential G4 GKE Nodes.
Developer resource: The new TPU Developer Hub is the place to go for model builders, optimizers, and developers to learn to unlock the full performance of Google Cloud TPUs. Read more in this blog.
New product: Scale your AI workloads with the new OpenTelemetry-Based TPU AI Telemetry Collector Agent. For the first time, you can route high-fidelity TPU hardware telemetry to Google Cloud Monitoring, Google Managed Prometheus, or your own self-hosted Grafana stack.

Practitioner guides and how-tos

How-to guide: Learn how to build high availability into an AI inference workload running on GKE Inference Gateway with TPUs, Cloud Storage FUSE and Dynamic Resource Allocation (DRA). This blog provides an overview, or you can get all the technical details in the hands-on codelab.
How-to guide: Did you know you can connect your AI agents to unstructured data in Cloud Storage via Model Context Protocol (MCP)? In this blog, learn about why would want to do that from three customer examples, then how to do it, choosing either a fully managed service, or a self-managed local server for more customization and control.

Research, reports and deep-dives

Report: According to an independent benchmark report, GKE Inference Gateway outperforms the next leading managed Kubernetes service with 15.7% higher throughput, 92.8% shorter wait times, and 62.6% lower inter-token latency. This performance can be attributed to its use of prefix caching, which optimizes LLM performance by storing the KV cache (activation states) of long, repetitive prompt prefixes. Learn more in the blog.
Architecture deep dive: A closer look at the cold start problem, this time for TPUs and GKE, and how the Run:ai Model Streamer can help change the dynamic.

Customer and partner updates

Customer win: Leveraging GKE, BigQuery, Cloud SQL, and Gemini Enterprise Agent Platform, Pager Health is eliminating operational fragmentation to deliver a simplified, personalized U.S. healthcare experience that transforms lives.
Customer win: Trustpilot, the customer review platform, built a high-volume streaming pipeline using fine-tuned Gemma models with Dataflow and Gemini Enterprise Agent Platform running on cost-optimized A2 VMs using A100 GPUs, as well as optimized version of vLLM maintained by Gemini Enterprise Agent Platform.

May 2026

Product, technology and tool updates

Product update: GKE Agent Sandbox is now generally available.
New open-source project: Agent Substrate is a new open-source project aimed at continuing to push the limits of agentic infrastructure density
New feature: Google AI Edge Portal, a solution for testing and benchmarking on-device machine learning (ML) at scale, now supports benchmarking and debugging on-device LLMs. Read more here.
Product deep dive: We went into depth about Cloud Storage Rapid, a new family of high-performance storage offerings for AI workloads. At launch, offerings include Rapid Bucket (formerly Rapid Storage), a high-performance zonal object storage offering, and Rapid Cache (formerly Anywhere Cache), which accelerates reads on-demand and colocates compute and data for workloads in existing buckets.

Research, reports and deep dives

Architecture deep dive: Google Global Infrastructure VP Bikash Koley and Engineering Fellow Arjun Singh provide a high-level overview of the challenges that AI workloads pose to network infrastructure, and discuss the deep enhancements we’ve made to our data center fabrics, WAN, and global networks to better support them.
Architecture deep dive: We unveiled a new cluster-level reliability model for developing frontier AI models on TPUs, ditching instance-level reliability

Customer and partner updates

Customer win: Visual media provider Imgix serves more than 8 billion images and videos from AI Hypercomputer equipped with G4 VMs powered by NVIDIA RTX PRO 6000 Blackwell GPUs.

Storage-optimized Z4D machine family, now GA, is designed for IO-intensive workloads

Mon, 28 Sep 2026 07:00:00 +0000

Today, we’re excited to announce the general availability of our next-generation Storage-optimized Z4D machine series in Google Compute Engine with both Virtual Machine (VM) and bare-metal instances.

We built Z4D for IO-intensive and business-critical workloads that require large local storage capacity and high storage performance, including SQL, NoSQL, KVrocks and vector databases, data analytics and data search. Powered by 5th Gen AMD EPYC processors (Turin) and paired with the latest enhancements in Titanium, Z4D provides up to 84,000 GiB of Local SSD (LSSD) storage. It improves the performance of these demanding workloads by up to 40% compared to the prior-generation Z3 instances, so you can increase your applications throughput while right-sizing your cloud investment. Z4D’s large LSSD capacity also makes it a strong storage solution for AI/ML training and inference workloads and running distributed parallel file systems at scale.

Z4D VMs and bare-metal instances

The Z4D VM portfolio lets you rightsize your infrastructure and scale your clusters to meet workloads requirements by providing large total local SSD capacity and high local SSD capacity per vCPU. Z4D offers two different VM types: the Z4D-highmem-standardlssd VM type, which includes seven VM shapes and offers 219 GiB of LSSD per vCPU. These VMs are optimized for data analytics (OLAP), and SQL databases like MySQL and Postgres. The Z4D-highmem-highlssd VM type includes seven different VM shapes, with 438 GiB of LSSD per vCPU and is optimized for distributed databases, data streaming, large parallel file systems and data search. In addition, you can easily scale your existing Z3-based workloads by expanding into Z4D clusters.

Z4D bare metal instances give you direct access to the physical hardware without a virtualization layer. This reduces latency for latency-sensitive workloads, custom hypervisors and workloads with specific licensing needs. Further, Z4D bare metal will be the very first AMD-based instance to support Nutanix Cloud Clusters (NC2), a hybrid multi-cloud platform that works across several cloud providers. Z4D bare-metal instances deliver the LSSD capacity and low latency that agentic AI architectures using microVMs require, allowing developers to run thousands of isolated sandboxes per host with native performance and efficiency.

In addition to 84,000 GiB of local SSD storage, Z4D VMs and bare metal instances offer up to 384 vCPUs and up to 3,072 GiB of memory. Z4D instances are based on Titanium SSDs, which offload local storage processing from CPU resources to deliver real-time data processing, low-latency, high-throughput storage performance and enhanced storage security. Z4D delivers up to 15,600K random read IOPS and up to 75,600 MiB/s sequential read throughput, improving the LSSD storage performance by up to 70% compared to Z3. Z4D also reduces write latency by up to 25% and improves mixed read-write IOPS by up to 30% without increasing the IO latency vs Z3. At the same time, Z4D instances provide the connectivity and storage performance that enterprise and AI/ML workloads need by doubling the networking throughput compared to Z3 and offering up to 400 Gbps of standard networking bandwidth.

What customers and partners are saying

“Elastic is committed to delivering best-in-class performance with the Elasticsearch Platform that powers observability, security, search, and AI solutions. Performance and cost efficiency are critical for teams running these workloads at scale and our initial testing of the new Z4D virtual machines shows up to 50% better indexing throughput compared to previous generation Z3 VMs. We look forward to bringing these benefits to Elasticsearch users deploying on Google Cloud.” - Yuvraj Gupta, Principal Product Manager, Elastic

"Migrating to the Z4D instance reduced our processing runtime by ~70% while reducing overall costs. This improvement enables Immunai to process large-scale immune data significantly faster and turn it into biological insights that support pharma companies in making better-informed decisions throughout drug discovery and development." - Guy Yachdav, Senior Director of Software Engineering, immumeai

"We are thrilled to expand our technical collaboration with Google Cloud and to deepen our strategic partnership with AMD to bring Nutanix Cloud Clusters (NC2) to the new Z4D bare metal instances. This marks a significant milestone for our customers, as NC2 on Z4D will be a first-of-its-kind offering — the very first AMD metal instance on which NC2 is supported. By uniting AMD's cutting-edge compute performance with Google Cloud's robust infrastructure and the Nutanix hybrid cloud platform, we are delivering unprecedented flexibility, scale, and choice to empower enterprise workloads." - Saveen Pakala, Vice President of Product Management, Nutanix

"Redis powers real-time data infrastructure and AI workloads for thousands of organizations worldwide. Flex extends that to larger datasets without all-RAM economics — local SSD handles the scale while memory provides the speed. We compared Google Cloud's new Z4D storage-optimized VMs to our current generation C3D instances using our Flex benchmark suite on the same flash-heavy workloads. The results were impressive: up to 4.3 times higher throughput and up to 77% lower latency on our smaller shapes. Z4D also sustained nearly 1.8 million operations per second at full RAM hit ratio. The more data we served from flash, the more that advantage grew — which is exactly the profile Flex is built for. Z4D gives us a clear path to deliver the same performance tier on a smaller footprint, and we're looking forward to expanding our testing as Z4D moves toward GA.” - Benjamin Renaud, CTO, Redis

“Shopify looks at what's best for our fleet, and Z4D gives us high CPU density alongside fast locally attached storage and fast networking. Shopify's user experience depends on how fast data can be served, and AI shopping agents query storefronts far more aggressively than people do. These shapes give us the throughput to keep up. We saw roughly 20% better throughput on Z4D than on Z3.” - Brad Dietrich, Distinguished Engineer, Shopify

"Google's Z4D VMs are a significant leap forward. In our testing we observed up to 60% better performance than previous Gen 2 VMs, and up to 36% better performance than Z3 VMs. With high local SSD density and strong cost-efficiency together with improved system reliability, Z4D gives Silk customers faster, more predictable performance for their most demanding workloads." - Adik Sokolovski, Chief R&D Officer, Silk

"Connecting AI with petabytes of fresh data means we're searching more than ever before. We're excited about the new Z4D instance types. Compared to Z3, they gave us a 40% throughput improvement on real query and indexing workloads — which directly translates to faster and cheaper web-scale search for our customers" - Ben Linsay, Engineer, turbopuffer

Enhanced maintenance experience

Both Z4D VMs and bare-metal instances make it easier for you to plan ahead and schedule maintenance operations at a time of your choosing by providing notice from the system several days in advance of a required maintenance. Z4D VMs further enhance the maintenance experience by allowing you to live-migrate an instance during maintenance events for VMs with 42,000 GiB or less of local SSD storage. Z4D VMs with 84,000 GiB of local SSD and Z4D bare metal instances are terminated and restarted while preserving your data through the planned maintenance events.

Support for Hyperdisk

Z4D VMs and bare metal support Hyperdisk, Google Cloud’s workload-optimized block storage that lets you optimize the performance for each workload by independently tuning the storage performance and capacity for each instance.

Specifically, they are compatible with Hyperdisk Balanced, Hyperdisk Throughput, and Extreme Hyperdisk storage for scalable, high-performance network-attached storage, supporting up to 512 TiB of capacity per instance. For general-purpose workloads, Hyperdisk Balanced, with up to 320K IOPS per instance, offers a mix of performance and cost-efficiency. Hyperdisk Extreme delivers ultra-low latency and supports up to 500K IOPS and 12,500 MiB/s throughput per Z4D VM and bare metal instance, making it well-suited for demanding database workloads.

Get started with Z4D today

Z4D VMs are available today in select regions worldwide and Z4D bare metal instances are in preview - reach out to your account team for additional information and access. To start using Z4D instances, select Z4D under the Storage-Optimized machine family when creating a new VM or GKE node pool in the Google Cloud console. Learn more at the Z4D machine series page. Contact your Google Cloud sales representative for more information on regional availability.

M4N VM family, now GA: Highest per-core IOPS and throughput for I/O and memory-bound workloads

Wed, 16 Sep 2026 16:00:00 +0000

As enterprise organizations scale mission-critical applications, storage I/O and memory access can become severe operational bottlenecks. Whether its Oracle databases, in-memory databases like SAP HANA, or high-throughput SQL Server clusters, EHR systems, and real-time big data analytics, memory-bound databases often force enterprises to over-provision compute cores (vCPUs) to get the RAM capacity and storage bandwidth they need, driving up costly third-party software licensing fees.

Today, we are thrilled to announce the general availability of the M4N machine series in Google Compute Engine, purpose-built for I/O intensive, high-memory workloads, the second offering in our network- and block-storage optimized VM family. Compared to similar offerings from other hyperscalers M4N provides the highest per-core IOPS and throughput for high-memory instances, and over 20% TCO reduction for Oracle databases.

M4N is also the industry’s first instance of network and block storage optimized with higher memory ratios (up to 26:1) and size (6TB). Powered by 5th Gen Intel® Xeon® Scalable processors and built on Google Cloud's custom Titanium offload architecture, M4N instances deliver up to 25,000 MiB/s (25 GiB/s) of aggregate host storage performance and up to 1 million IOPS when paired with Hyperdisk Extreme — doubling the block storage performance of current M4 instances.

M4N targets workloads that demand both extreme high-density RAM and uncompromising I/O performance, complementing our existing memory-optimized families (such as M1, M2, M3, M4, and X4) by solving specific storage and network bottlenecks for high-throughput enterprise applications.

Built for demanding workloads

Workload Category	Typical Applications	Why M4N Wins
Mission-critical enterprise DBs	Oracle, SAP HANA, SQL Server, IBM DB2, MySQL, PostgreSQL	Memory-to-core ratios (up to 26.57 GB/vCPU) paired with 25 GiB/s storage for rapid data ingestion, transaction logging, and zero-stall backup cycles.
Generative AI and RAG data layers	Milvus, Pinecone, Qdrant, Vespa, Redis, In-Memory Context Caching	Sub-millisecond similarity search across massive vector indexes in RAM, combined with 400 Gbps network bandwidth for distributed model retrieval.
Enterprise healthcare and ERP	Epic Systems (Operational Database), SAP ECC, SAP S/4HANA	Sustained I/O headroom that prevents query latency spikes during peak clinical/transactional hours.
Real-time analytics and EDA	Electronic Design Automation, Genomic Modeling, In-Memory OLAP	High memory capacity to load massive datasets entirely in RAM with maximum storage bandwidth for checkpoint dumps.

Optimizing Oracle licensing costs

Enterprise IT departments struggle with the rising cost of core-based software licensing. For workloads like Oracle database, licensing fees are typically calculated based on the number of vCPUs or physical cores assigned to the instance. Historically, this has forced a difficult trade-off: paying for more compute cores than necessary just to obtain the required amount of RAM and storage performance.

M4N changes this paradigm with its industry-leading high memory-to-vCPU ratio. By providing the highest per-core IOPS and throughput for high-memory instances of all the leading hyperscalers, M4N allows database administrators to:

Reduce TCO and licensing overhead: Stop over-provisioning of cores while meeting Oracle database performance density requirements, resulting in over 20% TCO reduction compared to similar offerings from leading hyperscalers.
Right-size infrastructure: Allocate the exact amount of compute power needed for the workload while still accessing massive memory pools.
Improve cache-hit ratios: With more memory available per core, larger portions of the database can reside in the system global area (SGA), reducing expensive I/O operations and further boosting efficiency.

What customers are saying

Early experiences with M4N show that workload-optimized infrastructure is the engine for transformation.

“Before M4N, meeting our demanding I/O requirements on Google Cloud often required over-provisioning our compute to achieve the necessary performance density. The new M4N instances solve this by delivering high throughput across the smaller to larger shapes.” - Sherri Trojan, Sr Principal Solution Architect, Sabre

"We are delighted to see Google Cloud introduce this next-generation high-performance infrastructure for mission-critical database workloads. The new compute platform demonstrates tremendous potential for enterprise Oracle deployments requiring scalability, resiliency, and performance. We are excited about what this innovation means for customers running Oracle workloads on Google Cloud.” - Bala Kuchibhotla, Co-Founder and CEO, Tessell

"With M4N, Google Cloud continues to push the boundaries of platform co-design. By combining 5th Gen Intel Xeon Scalable processors with Google's custom Titanium offload architecture, M4N delivers the extreme memory capacity, high memory bandwidth, and uncompromising I/O throughput required for the world’s most demanding mission-critical data environments." - Intel

What’s new: Scaling extreme data layers with M4N

M4N bridges two previously separate paradigms in cloud infrastructure: large memory footprints and extreme I/O performance. Engineered with custom Titanium offloads, M4N minimizes I/O bottlenecks without requiring infrastructure add-ons or compromises on memory density. Let’s take a look at how M4N fits into these environments.

1. Enabling high bandwidth data transfer

For workloads with large memory footprints, M4N provides:

Superior VM-to-VM bandwidth: Delivers up to 400 Gbps aggregate VM-to-VM network bandwidth and up to 50 Gbps single-flow bandwidth within the same VPC, unlocking non-blocking data exchange for distributed database clusters and real-time streaming data layers.
Enhanced internet and egress throughput: Enjoy up to 200 Gbps internet egress bandwidth and up to 48 MPPS packet processing performance.
High bandwidth out-of-the-box: Achieve full performance without needing to purchase or configure premium Tier_1 networking add-ons.

2. Dynamic storage performance with Hyperdisk

Paired with Google Cloud's next-generation storage portfolio, M4N with Hyperdisk lets you independently tune IOPS, throughput, and capacity:

Hyperdisk Extreme (HdX): Delivers up to 25 GiB/s aggregate block storage throughput and 1,000,000 IOPS—double the storage performance of standard M4. This is great for rapid database recovery, transactional checkpointing, and instant in-memory index reloads.
Hyperdisk Balanced (HdB): Scales up to 20 GiB/s throughput and 640,000 IOPS for cost-effective enterprise storage at scale.

M4N machine types and specifications

M4N instances are offered across three distinct memory-to-vCPU ratio tiers, scaling from 16 to 224 vCPUs and up to 5,952 GB of DDR5 RAM. M4N also offers predefined VM shapes across three distinct memory-to-vCPU ratios to match specific workload requirements, with support for Resource-based Committed Use Discounts (CUDs). Details here.

Get started today

The M4N instances are now available in select regions around the globe. To learn more about how the M4N family can enhance your memory- and I/O-bound applications and reduce your licensing costs, contact your account representative or explore the documentation.

Google is a leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026

Mon, 14 Sep 2026 16:00:00 +0000

We are excited to share that Google Cloud was named a Leader and received the highest score in the ‘current offering’ category in the Forrester Wave™: Public Cloud Platforms, Q3 2026 report, which examines the 10 most significant public cloud providers across 30 comprehensive criteria, Google also received the highest possible score in 23 out of 30 evaluation criteria, including, but not limited to vision, innovation, AI development services, database services, analytics services, containers and kubernetes services, modernization services, and security services. We believe Forrester’s recognition confirms our belief that to lead in the agentic era, you need a complete, integrated platform that’s engineered from the ground up, from silicon to systems to models.

Access the complimentary report: The Forrester Wave™: Public Cloud Platforms, Q3 2026.

Build on co-designed infrastructure proven in global enterprises

For over a decade, our infrastructure engineers, application developers, and AI researchers worked side by side to co-design infrastructure to power Gemini, Search, YouTube, Maps, and Gmail. We couldn't simply buy the platform and infrastructure we needed; we had to invent it. This led to the creation of everything from TPUs, the Transformer architecture, Kubernetes, Axion, and now Gemini.

In the agentic era, you need an integrated AI stack, where compute, orchestration software, modernization tools, and global networks operate together to give you more value from your investments — even if you’re not working at the frontiers of AI research. At Google Cloud, we’ve worked tirelessly to bring these breakthrough innovations to leading enterprises, startups, and frontier labs to help them achieve new levels of scale and efficiency, and we believe Forrester’s evaluation validates that strategy:

“Google Cloud’s vision is to enable the ‘agentic enterprise,’ and AI already permeates its platform, positioning the company to push further up the tech stack toward business users who increasingly shape AI adoption in the enterprise. Google Cloud is a good fit for enterprises seeking rapid technology innovation and a broad AI-enabled cloud platform.” - The Forrester Wave™: Public Cloud Platforms, Q3 2026 report

Run agents quickly on a secure, flexible platform

Most traditional infrastructure can’t keep pace with agents, and enterprises need a scalable alternative. But you don’t want a new, greenfield platform just for AI agents. Kubernetes is the proven industry standard for modern enterprise applications — from microservices and transactional databases to real-time LLM inference. We are evolving Google Kubernetes Engine (GKE) and our operations tooling so organizations can scale autonomous agents alongside traditional workloads on a single, proven platform.

Forrester gave Google Cloud the highest scores possible in Container and Kubernetes services, Serverless/FaaS services, and Operations management services, noting:

“Operators will find strong offerings in operations management as well as containers and Kubernetes services. Our evaluation did not identify significant capability gaps.”

Over the past three months, we’ve enhanced our infrastructure portfolio to help teams scale agentic workloads with enterprise predictability. Recent updates let you:

Safely execute untrusted agent code alongside traditional workloads with default-deny security using GKE Agent Sandbox (GA) and Cloud Run Sandboxes (preview), which provision lightweight, gVisor-isolated boundaries for your agent in under a second (and up to 300 sandboxes/sec per cluster).
Eliminate up to 90% of idle compute costs by serializing your container RAM state directly to Google Cloud Storage with GKE Pod Snapshots, allowing you to suspend idle agent sessions in ~100ms and resume them in ~280ms.
Cut time-to-first-token (TTFT) up to 70% and double cache-hit rates with predictive routing in GKE Inference Gateway, which uses a continuously trained ML model to make routing decisions based on real-time traffic data.

Ground your agents with real-time enterprise data

Agents are only as effective as the context that grounds them. Traditional distributed data topologies separate operational databases from analytical systems through fragmented, multi-hop pipelines. In the agentic era, this divide introduces multi-hop latency, stale context, and governance friction.

Our Agentic Data Cloud evolves the enterprise data platform from a static repository into a dynamic reasoning engine. It unifies transaction processing and analytical intelligence into an active system of action, providing the real-time context and deterministic responsiveness that autonomous workflows require. Google received 5/5 scores across the Database services, Analytics services, Data integration services, and Data Governance services criteria:

“Google Cloud’s traditional strength in database services and analytics drives strong performance, including multicloud and hybrid capabilities, along with an Agentic Data Cloud that bridges analytics and transactional systems.”

Over the past three months, we’ve introduced key capabilities to the Agentic Data Cloud to help customers unify their data estates:

Enable agents to query live financial and supply chain records without costly data movement using SAP BDC Connect for BigQuery (GA), which provides bi-directional, zero-copy data sharing between your SAP systems and BigQuery.
Map and infer business meaning across your entire data estate with Knowledge Catalog. You can now aggregate native context across your Google and partner data platforms, semantic models, and third-party catalogs, unifying them into a single, governed source of truth.
Access live data from Iceberg and BigQuery from the PostgreSQL data plane with Lakehouse federation. Perform live joins between AlloyDB's transactional data and historical insights in BigQuery or Iceberg without any data movement. You can also replicate data continuously to BigQuery and, importantly, to Iceberg tables directly from AlloyDB with Datastream.

The benchmark is set: Build what’s next on Google Cloud

We are honored that Forrester has named Google Cloud a Leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026. We believe this recognition validates decades of foundational research, disciplined full-stack co-design, and our commitment to building an open, reliable cloud.

The era of fragmented infrastructure has come to an end. Whether your organization is an AI research lab scaling models across one million accelerator chips, a global financial exchange settling trillions in clearing systems, or an enterprise empowering millions of users with autonomous workflows, Google Cloud delivers the performance, scale, security, and data foundation to build what’s next.

Take the next step in your cloud journey:

Download the full report: Read the complete analysis in The Forrester Wave™: Public Cloud Platforms, Q3 2026.

Google named a Leader in 2026 Gartner® Magic Quadrant™ for Strategic Cloud Platform Services

Thu, 03 Sep 2026 07:30:00 +0000

For the ninth consecutive year, Gartner® has named Google a Leader in the Gartner Magic Quadrant™ for Strategic Cloud Platform Services, positioned furthest for Completeness of Vision.

We believe this recognition reflects our longstanding dedication to helping customers build and scale their most demanding workloads reliably and securely on Google Cloud. As we enter the agentic era, we're accelerating their journeys with a dynamic infrastructure, and connecting enterprise apps, data and agents on a single, flexible platform for predictable cost and performance.

What’s driving this momentum? There are three major advantages that we feel set Google Cloud apart:

A co-designed, unified technology stack across custom silicon and hardware systems, open software and orchestration, frontier models and agentic applications.
A dynamic infrastructure that helps you securely connect and scale your users, data, apps, and agents everywhere.
Digital sovereignty with genuine choice, giving organizations total control over their data without sacrificing essential cloud functionality.

We are committed to helping our customers innovate and deliver at scale while giving them the flexibility, performance, and control they need. Let’s dive into three design principles that Google Cloud lives by as we continue to build and enhance our infrastructure:

1. Accelerate AI with a co-designed stack without lock-in

Google Cloud is the only provider to deliver a complete, first-party AI stack that is deeply co-designed from silicon to agentic applications. Our infrastructure team works with Google DeepMind researchers to co-design and optimize every layer of our technology stack. From custom silicon, like Google TPUs and Arm-based Google Axion processors, to Google Kubernetes Engine (GKE) and Gemini models, our system delivers exceptional performance and predictable costs.

Co-designing hardware and software creates massive operational efficiency, but it doesn't mean creating a closed ecosystem. We remain deeply committed to open source and open standards across every layer of the stack including frameworks like llm-d for distributed inference, benchmarking for open models with GKE Prism, and eliminating hardware lock-in with TorchTPU for PyTorch compatibility across TPUs and GPUs. You get the full power of a vertically co-designed stack while maintaining complete freedom across models, frameworks, and silicon. Combining all of these deeply integrated components means building an AI Hypercomputer, capable of exceptional scale, performance, and efficiency. This is the same infrastructure foundation chosen by nine of the top ten AI labs globally.

2. Scale quickly and economically with a dynamic infrastructure

Today, demand for AI resources is skyrocketing. Internally at Google, our data centers now process 3.2 quadrillion tokens monthly, roughly 7x more than last year¹. For enterprise leaders navigating this shift, scaling AI systems are notoriously difficult to architect, resource-intensive, and bursty, which can lead to scaling bottlenecks and large pools of underutilized compute.

Organizations need a dynamic infrastructure to automate capacity management, modernize business applications at their own pace, and securely connect data, apps, and agents to drive optimized global experiences.

To thrive at an agentic scale, you need infrastructure capable of operating as a single system. With Google Cloud, you can:

Kick-start your AI transformation using Gemini-powered tools to intelligently map and modernize core apps, turning static legacy systems into dynamic foundations for AI and agents.
Choose from a wide range of workload-optimized compute types and configurations. You can combine predefined and custom CPU shapes, NVIDIA GPUs, and Google custom silicon (TPUs and Axion CPUs), which are designed to deliver exceptional performance-per-dollar for AI and Enterprise workloads.
Connect your enterprise and AI infrastructure on a single, flexible control plane with Google Kubernetes Engine. This includes capacity management capabilities like Dynamic Workload Scheduler to preschedule capacity for planned events and dynamic resource allocation to define advanced rules that dictate how resources are consumed, helping to maximize utilization and reduce costs.
Simplify day two operations using Gemini Cloud Assist to proactively identify, troubleshoot, and resolve operational issues for your new agent-based workflows.
And finally, run your workloads across hybrid and multicloud environments with Cross-Cloud Interconnect, leveraging Google’s 10+ million kilometer private fiber backbone to deliver up to 40% higher performance than public internet routing and automated delivery in minutes².

By adopting a unified foundation of dynamic infrastructure, adaptive applications, and responsive systems, organizations can establish the resilient, high-performance infrastructure necessary to lead in this new technological frontier.

3. Embrace digital sovereignty with more choice and security

You shouldn’t have to compromise between modernization, frontier AI capabilities, and regulatory control. Sovereign Cloud from Google gives you access to Gemini and open-weight models across sovereign platforms with three flexible deployment options:

Data sovereignty and control: Retain complete control over your data’s location and cryptographic authority with Google Cloud Data Boundary. Manage your encryption keys outside Google infrastructure using External Key Management (EKM) with Key Access Justifications (KAJ), while enforcing precise geographic processing and storage boundaries across both Google Cloud and Google Workspace.
Local compliance and regional operations: Run your applications on physically and logically separated regional clouds operated exclusively by local partners, built on Google Cloud dedicated for European customers. In France, S3NS delivers PREMI3NS, providing a standalone sovereign cloud that has achieved the SecNumCloud 3.2 qualification from the French National Agency for the Security of Information Systems (ANSSI). Dedicated sovereign cloud operations operated by Thales are also coming soon to Germany.
On-premises and air-gapped flexibility: Bring Google Cloud capabilities directly to your on-premises environment via Google Distributed Cloud (GDC). GDC offers two distinct deployment modes: air-gapped, a fully-managed, self-contained environment operating with zero connectivity to the public internet for public sector, defense, and regulated enterprise workloads; and connected, allowing you to run workloads on your hardware locally while leveraging Google Cloud’s centralized control plane for unified management.

Accelerate your Cloud journey

Whether you're modernizing core enterprise systems, managing complex compliance requirements, or deploying autonomous AI agents, Google Cloud gives you the performance, scale, and freedom of choice to succeed.

Read the full 2026 Gartner Magic Quadrant for Strategic Cloud Platform Services or explore our AI Hypercomputer page to learn more.

^{1. Pichai, Sundar. "I/O 2026: Welcome to the Agentic Gemini Era." The Keyword, Google, 19 May 2026
2. During testing, network latency was more than 40% lower when traffic to a target traveled over the Cross-Cloud Network compared to when traffic to the same target traveled across the public internet.}

Dynamic capacity management for AI infrastructure

Wed, 26 Aug 2026 13:30:00 +0000

The internet connected billions of people and mobile devices, putting computers in every hand. Now, we’re in the middle of the next big technology shift, deploying millions of autonomous AI agents to work alongside employees and end users. Today, we announced new FinOps controls for Gemini Enterprise to help organizations manage project-level AI spend and eliminate token shock. But the sheer scale of the agentic era is placing new constraints at every layer of the stack, including infrastructure. AI workloads are notoriously difficult to architect, resource-intensive, and bursty, which can also lead to scaling bottlenecks and large pools of underutilized — or misutilized — compute resources.

Organizations need insights to help them extract more value from their infrastructure investments. In this blog, we outline best practices for dynamic capacity management — scheduling and utilization strategies to help you run enterprise and AI applications on a single, flexible foundation with predictable cost and performance. These capabilities are designed to augment our on-demand, Spot and committed use discount (CUD) consumption models, which provide flexible pricing and discounting for your workloads. Let’s jump in.

Here's a quick summary

Three ways you can implement dynamic capacity management:

Schedule capacity for planned events. Schedule mission-critical resources (GPUs, TPUs and select VM families) ahead of planned events using calendar mode, or optimize costs for batch jobs with flexible start times using flex-start mode in Dynamic Workload Scheduler. Once you obtain the capacity, those resources are guaranteed for the specified duration.
Maintain service continuity by creating a fallback plan for every application. Define automated, prioritized hardware fallback lists using managed instance groups (MIGs) so your apps automatically pivot to the next approved compute option when your preferred option isn’t available.
Automate your entire capacity management lifecycle on a single, adaptive control plane. Google Kubernetes Engine (GKE) provides an agent-native environment to orchestrate the entire process — from fallback lists using Custom ComputeClasses, to granular hardware slicing with dynamic resource allocation, so agents can rapidly spin up in secure sandboxes and containers while it dynamically reallocating resources on the fly.

Why architectural flexibility matters

Ninety percent of enterprises want to deploy agents within the next three years, but only 17% of IT leaders feel confident their current IT setup can handle the load. Because these workloads have unique performance needs, organizations are racing to adopt specialized infrastructure, including accelerators (GPUs, TPUs) and CPUs with customized compute, memory, and storage ratios. However, agents also require access to enterprise applications and databases — often at a volume and scale that vastly exceeds typical human usage. Handling the intense demands of both agents and the applications they interact with requires a dynamic infrastructure. Infrastructure teams can leverage custom-designed processors like Google’s Axion to meet these needs, but hardware isn’t a complete solution. They also need ways to use that infrastructure wisely, solving execution inefficiencies to enable more flexibility across the stack.

How to overcome infrastructure constraints

Achieving this kind of flexibility requires a two-pronged approach: securing resources for the demand you can predict, and building automation to respond to the demand you can't. Combining the two, you can preschedule capacity for planned events and your infrastructure can adapt to unexpected changes without manual intervention.

1. Schedule capacity for planned events

You can secure mission-critical capacity ahead of scheduled milestones, offline training, or anticipated demand surges using Dynamic Workload Scheduler. By scheduling the resources you need up front, you optimize your spend and ensure you get access to the compute resources you need. Dynamic Workload Scheduler supports hardware accelerators (TPUs and GPUs) and select CPUs with two distinct modes:

Flex-start mode: Use this for latency-tolerant workloads like batch processing, model training, or offline fine-tuning. Instead of requiring resources immediately, you submit a defined duration request and the system intelligently queues your job, provisioning the resources as soon as capacity becomes available. This maximizes cost-efficiency and drastically improves your ability to obtain high-demand accelerators.
Calendar mode: Use this for mission-critical, time-bound events like a major product launch, a scheduled migration, or a seasonal traffic surge. By specifying the exact start and end dates of your event, you create a future reservation. This guarantees the requested capacity will be available when the event begins.

2. Maintain service continuity by creating a fallback plan for every application

Not every spike in traffic is predictable. You also need to plan for unexpected traffic from, say, a breaking news cycle or a sudden market shift that drives a surge in user activity. To help your services get the resources they need without interruption, you need a fallback plan — an automated, prioritized sequence of acceptable hardware configurations. This strategy:

Decouples your workloads from a single VM shape, size, or configuration. This allows them to run without manual intervention if your preferred option is unavailable
Allows you to execute a progressive tech refresh by adopting the newest VM generations as your primary choice while keeping older generations as an automatic fallback option.

If you run non-containerized workloads on Google Compute Engine, you can dynamically manage capacity with instance flexibility in managed instance groups (MIGs) and bulk VM creation. Instance flexibility lets you specify multiple machine types for your VM instances rather than being limited to a single machine type.

How it works: If your preferred machine type is temporarily unavailable, the MIG automatically provisions a compatible alternative from your list based on real-time capacity. When combined with location flexibility — by specifying multiple zones your MIGs can search within a region — you can drastically improve your provisioning success rate. If your MIGs use Spot VMs, Compute Engine automatically integrates with Spot capacity signals to prioritize machine types that offer longer estimated uptimes and lower risk of pre-emption.

You can also extend instance flexibility to your block storage layer by setting baseline disk defaults and configuring disk overrides so your storage adapts when a VM falls back to a different machine type.

How it works: Most of the time you can simply rely on our default options, omitting ‘disk type’ from the instance template entirely. However, for data disks that will outlive their associated VMs, it’s possible to enable a fast, durable Hyperdisk across multiple VM generations.

While Compute Engine provides instance flexibility for organizations working with virtual machines, GKE goes a step further and automates the entire capacity lifecycle from a single control plane. With GKE custom ComputeClasses, platform teams can design multi-dimensional fallback lists, automatically combine different VM machine families, sizes, and ratios, scale across multiple zones, and shift between on-demand and Spot VMs. By using Dynamic Workload Scheduler as a capacity target, and custom ComputeClasses to define the policy and priority, you can fully automate the capacity management lifecycle.

How it works: Once you’ve set up ComputeClasses, GKE automatically detects when a preferred node configuration is unavailable and falls back to your pre-approved alternative options in order of priority. When active migration is enabled, GKE gracefully migrates workloads back to higher-priority node configurations as capacity becomes available. For short-lived disks such as boot disks, GKE dynamically picks the right defaults based on the instance family. However, for long-term disks that will outlive the VM, you can use Hyperdisk.

Another GKE feature, dynamic resource allocation, helps eliminate wasteful, all-or-nothing hardware assignments by letting developers define advanced rules that dictate how resources are consumed.

How it works: Instead of claiming an entire GPU or TPU, your application specifies its exact parameters — such as total memory or number of cores — and the system allocates the perfect slice of hardware, helping to maximize utilization and reduce costs.

Take the next step toward dynamic infrastructure

Scaling AI shouldn’t mean linearly scaling your infrastructure budget or accumulating more tech debt. As these examples show, the right tools can help you overcome constraints and dramatically alter the value you get from your compute investments. Here are three steps to get started:

Audit your workloads for immediate cost-savings: Identify any applications currently tightly coupled to a single VM family, machine type, or availability zone, and map out viable alternative hardware shapes. Look beyond your existing configurations to evaluate new compute options that might better serve or act as alternatives based on your workload-level objectives. Then use Compute Engine MIGs, bulk VM creation or GKE Custom ComputeClasses to adopt them automatically, integrating them into your fallback lists.
Commit to a minimum spend for deeply discounted prices: Receive automatic discounts for sustained use, or up to 63% off when you sign up for Compute flexible committed use discounts, where your discount is tied to the resources you use regardless of the specific machine type or location.
Engage your account team: Reach out to your Google Cloud account team to craft a tailored capacity management strategy and configure your automated fallback lists.

PQC in Plaintext: Google Cloud’s post-quantum cryptography roadmap

Tue, 11 Aug 2026 16:00:00 +0000

Securing infrastructure and services against a future cryptographically-relevant quantum computer has been a goal for Google for a decade, and we’ve dedicated ourselves to help developers by advancing open standards that can benefit everyone. As post-quantum cryptography (PQC) has matured, we’ve been rolling it out in our infrastructure for internal and customer-facing services.

Today, we're sharing our updated Google Cloud roadmap to migrate to PQC by 2029.

Our strategy: Secure by design

We’ve based our PQC migration strategy on the Google Quantum Threat Model, prioritizing protection across three key domains:

Mitigating Store Now, Decrypt Later (SNDL) risks: Protecting today's encrypted data from being harvested and decrypted by a future quantum computer.
Ensuring integrity against forgery: Strengthening digital signatures to prevent attackers from falsifying data and identity.
Enhancing foundational capabilities for cryptographic agility: Building flexible systems that can easily adopt new cryptographic standards with minimal engineering effort as cryptographic standards evolve.

We’re actively transitioning internal infrastructure and customer-facing services to PQC algorithms far ahead of regulatory deadlines.

We are also deploying PQC solutions across our Sovereign Cloud initiatives, such as Google Cloud Dedicated (GCD) and Google Distributed Cloud (GDC), in collaboration with our partners. Similarly, our strategy allows us to progress on integrating post-quantum protections across our AI services to secure the next generation of cloud workloads.

These efforts are fundamental pillars of our overarching strategy to achieve full post-quantum readiness across Google Cloud. As this landscape evolves, we will continue to refine and update our deployment schedules.

Visualization of our Google Cloud PQC roadmap. Our efforts converge in 2029, and extend beyond it.

We plan to achieve full PQC readiness by 2029, when our efforts converge. We anticipate continuing those efforts into the 2030s to support broader industry guidance and evolving global standards. These standards include CNSA 2.0 and the transition paths defined in NIST IR 8547, which anticipate the final deprecation of legacy, quantum-vulnerable algorithms between 2030 and 2035.

Immediate progress: 2026 milestones

Leadership in the quantum era requires deployment at global scale. We have achieved foundational milestones that provide immediate protection for our customers:

API endpoint readiness: Google Cloud API endpoints now offer quantum-safe key exchange, protecting incoming traffic from future decryption. These endpoints include google.com and *.googleapis.com, and both have implemented NIST-standardized ML-KEM (FIPS 203) in hybrid mode.
Load balancers PQC support: Application and proxy load balancers now support quantum-safe hybrid key exchange (X25519MLKEM768) for TLS 1.3. Initially available on an opt-in basis, this allows our customers to perform validation, while minimizing impacts to their existing applications.
Quantum-safe certificate experimentation at scale: We’re collaborating with the IETF PLANTS Working Group to produce a public key infrastructure (PKI) standard that minimizes impact to your operations teams. Chrome and Cloudflare have started experimenting with Merkle Tree Certificates to address challenges using PQC signatures for WebPKI, and we have been sharing insights with the standards working group.
Cloud KMS PQC algorithms: NIST standardized PQC algorithms (ML-KEM, ML-DSA, SLH-DSA) for your encryption and signing keys are now generally available.

The roadmap to 2029

We’ve established specific customer-centered journeys for Google Cloud to achieve quantum readiness that allow us to prioritize our quantum-safety initiatives. By adopting this risk-based approach, we focus on the core journeys our security experts have identified as most vulnerable to the potential impacts of quantum computing.

Risk-based prioritization for core quantum readiness user journeys.

These scenarios offer diverse platform perspectives to ensure global enablement across our services to meet you where you are.

For each risk domain, we provide a roadmap for key products and services organized by domain, although the services highlighted are not exhaustive lists. We project most services will meet their respective domain's target completion date, though specific product timelines may be adjusted if necessary to account for evolving engineering requirements and any third-party dependencies.

Domain 1: Store Now Decrypt Later (SNDL) mitigation

This domain focuses on addressing vulnerabilities in asymmetric encryption where a future cryptographically-relevant quantum computer (CRQC) could decrypt data captured today.

We’re enabling incremental progress for our customers based on their typical journeys.

Securing your customer workloads: Offer quantum-confidential TLS 1.3 handshakes for your Google Cloud services and configured load balancers to protect user sessions.
Securing administrator and developer flows: Protect the admin pathways used to manage your cloud environment against SNDL. This includes services such as Cloud VPN and Interconnect. For developers, these include client libraries, SDKs, and Tink, our open-source cryptographic library.
Securing data pipelines: Safeguard the confidentiality of data transfers for our analytics and storage platforms. PQC is essential to ensure that sensitive intellectual property and customer data flowing through these systems cannot be captured today and decrypted by a future quantum-capable adversary.

Roadmap
We are targeting these changes for 2027.

Journey	Benefits	Representative services
Store now decrypt later mitigation (End of 2027)
Securing your customer workloads	Quantum-safe ingress: Protects your cloud perimeter using standardized post-quantum algorithms.	Application and proxy load balancing [2026 (Completed)]
Securing admin and developer flows	Secure operations: Validates that your management and deployment stack meets emerging cryptographic standards.	Quantum-confidential ALTS [2025 (Completed)]
		API endpoints [2026 (Completed)]
		Cloud VPN, Cloud Interconnect, GCE OS Login, Cloud SDK, gCloud CLI, GKE service mesh, and client libraries [2026/2027]
Securing data pipelines	Confidential data transfers: Protect sensitive intellectual property and customer data against quantum attackers.	Cloud Storage SDK, Storage Transfer Service, BigQuery CLI, Data Transfer Service [2026/2027]

Domain 2: Integrity and non-repudiation

This domain addresses quantum-proofing of digital signatures and attestations to safeguard against forgery that could compromise data integrity and authenticity.

Securing the software supply chain: Ensure that only trusted, untampered images with quantum-resistant attestations run in production to help prevent a quantum attacker from altering builds. This includes services like Binary Authorization, Cloud Build, and Assured Open Source Software.
Issuing quantum-safe certificates: Transition the public key infrastructure (PKI) including our internal and external certificate authorities (CAs) to support ML-DSA certificates and where meaningful, SLH-DSA certificates. This transition will follow Internet Engineering Task Force (IETF) standardization efforts that are currently in development. We’re actively contributing to these efforts, and we’re also conducting several large-scale experiments:

Address large PQC signature sizes that can impact the performance of certificate chain validations through novel approaches like Merkle Tree Certificates for Web PKI.
Support ML-DSA/SLH-DSA (pure PQC)-based certificates in private CA solutions such as Certificate Authority Service (CAS).
Add quantum-authentication in addition to our internal traffic protocol ALTS that already supports PQC for confidentiality. You can learn more technical details on our approach to digital signatures and Public Key Infrastructure here.

Protecting identity and access: Ensure authentication mechanisms like service account keys and tokens (JWT/OAuth) are resistant to quantum forgery.

Roadmap
We are targeting completion of these milestones by 2028. We also are mindful of ongoing standardization efforts particularly in the field of certificates. Google is actively contributing to quantum-safe certificate standards, and we are committed to help the industry overall meet those deadlines.

Domain / Journey	Benefit	Representative services
Integrity and non-repudiation (End of 2028)
Securing the software supply chain and signature services	Quantum-safe software attestations: Prevents unauthorized build tampering by ensuring only trusted images run in production.	Binary Authorization, Access Approval (AXA) [2026]
		Assured OSS [2027]
Issuing quantum-safe certificates	Quantum-safe standardized trust: Safeguards the authenticity of your internal and external communications against quantum-calculated certificate forgery.	Quantum-authentic ALTS [2026/2027]
		Private CA (Certificate Authority Service) [2027]
		Google Trust Service: Merkle Tree Certificates [2028]
		Roll out of PQC certificates across Google Cloud products and infrastructure [2027/2028]
Protecting identity and access	Governed identity: Eliminates the risk of adversarial credential fabrication with NIST-standardized signatures for auditable integrity.	Cloud IAM [2028]
		Infra-wide rollout of quantum-safe authentication and access [2027/2028]

Domain 3: Foundations and key management

Cryptographic agility is the foundation of our PQC migration. Our ongoing investment in this area drives our end-to-end strategy for key management, libraries, and infrastructure changes.

Foundational key management and libraries: Enable NIST-approved algorithms through Cloud KMS and libraries like BoringSSL and Tink.

Note that Cloud KMS achieved general availability for the NIST standardized PQC algorithms (ML-KEM, ML-DSA, SLH-DSA), and is in the process of enabling quantum-safe key import.

Hardware-backed cryptographic services: Secure physical foundations using quantum-resistant roots of trust. This includes PQC as part of our Confidential Computing offerings and Cloud Hardware Security Module (HSM).
Key sovereignty and partner solutions: Enable PQC orchestration for Google Workspace Client-side Encryption (CSE) and External Key Managers (EKM). Collaborate with partners to support PQC on-premises key providers.

Roadmap
We are targeting completion of these milestones by 2028.

Domain / Journey	Benefit	Representative services
Foundations and key management (End of 2028)
Foundational key management and libraries	Standardized quantum-safe keys: Provides the NIST-approved building blocks to help migrate your applications.	ML-DSA and SLH-DSA in KMS, ML-KEM and Hybrids in KMS [2025 (completed)]
		Quantum-safe Key Import (BYOK) [2026]
Hardware-backed cryptographic services	Silicon rooted hardware: Anchors your security in quantum-safe hardware roots of trust.	Confidential Compute (including attestation and vTPM) [2028]

		Quantum-Safe Cloud HSM (FIPS 140-3 L3) [2028]
Key sovereignty and partner solutions	Cryptographic provenance: Provides control and provenance of your keys where you need them.	External Key Management [2028]
		Partner enablement (key providers and sovereignty solutions) [2028]

A shared responsibility for quantum safety

Security has long been a collaborative partnership with our customers.

Google’s responsibility — Security of the cloud: We manage the transition to a quantum-safe infrastructure, including our network and encryption in-transit, global front-ends, and the ALTS protocol.

This responsibility encompasses the end-to-end PQC transition of our servers, ensuring that the underlying hardware and operating systems are secured against quantum threats. We maintain hardware integrity through quantum-safe, open-source silicon foundations such as Caliptra v2.1, TPM 2.0 v185, and OpenTitan. The latter is the first open-source silicon root of trust and already supports quantum-secure boot.

While we are working toward our 2029 target, hardware transition to PQC involves both active replacement, where feasible, and natural equipment replacement cycles. Our phased approach ensures stability, though the timeline for some physical components may extend beyond 2029.

Customer’s responsibility — Security in the cloud: Organizations must manage their own applications, including updating client-side software to negotiate PQC handshakes and managing the lifecycle of your asymmetric keys.

In addition, you should update your Google Cloud service configurations with quantum-safe settings and policies.

Our path forward, together

Building momentum toward quantum readiness requires immediate, practical action. We recommend starting with these three steps:

Inventory: Identify your cryptographic resources (such as keys and certificates) using Cloud Asset Inventory and solutions such as Wiz’s cryptography and PQC readiness. When you map cryptographic resource usage across your organization, you can more accurately define and prioritize your migration backlog.
Update: Ensure your development and Site Reliability Engineering teams are using software that supports PQC algorithms such as BoringSSL, Chrome, and SDKs. This update ensures your internal workflows are prepared to negotiate quantum-safe connections by default as we enable them at the edge.
Validate: Test the behaviors of your existing application using our quantum-safe APIs and load balancers. Validating your workflows today will identify architectural bottlenecks before they impact your primary production environments.

Google Cloud is committed to managing the complexity of this transition so you can achieve your regulatory and compliance commitments, while focusing on innovation. We are just beginning to share our progress as we work to empower our customers to lead in the post-quantum landscape.

To learn more about our PQC approach, please visit our post-quantum cryptography (PQC) hub.

Accelerating automotive innovation with C4A-metal and Panasonic Automotive vSkipGen

Mon, 20 Jul 2026 16:00:00 +0000

As the automotive landscape accelerates toward software-defined vehicles, Cockpit Domain Controllers (CDCs) are becoming the core of next-generation in-cabin experiences. The ability to rapidly develop, test, and validate CDC software in a flexible, hardware-independent environment is critical for innovation and time-to-market. However, physical hardware constraints and the requirement for high-performance graphics present significant challenges for global development teams.

Panasonic Automotive’s vSkipGen™ addresses these challenges as a next-generation CDC virtualization platform, now validated on Google Cloud’s C4A-metal, our Axion bare-metal offering. By integrating Panasonic Automotive’s advanced Unified HMI™ remote GPU offload technology with support for Android Automotive OS (AAOS) and Android SDV, vSkipGen delivers a robust, cloud-native solution for cockpit software development and validation — empowering teams to innovate without hardware limitations.

At Google Cloud, we provide workload-optimized infrastructure to help ensure the right resources for every task. Similar to the entire Axion virtual machine family, C4A-metal instances are built on Google Cloud’s custom Arm-based Axion architecture. C4A-metal offers 96 vCPUs, two DDR5 memory configurations (384GB and 768GB), and up to 100Gbps of networking bandwidth. It also provides full support for Google Cloud Hyperdisk, including Balanced, Extreme, Throughput, and ML types. And like the rest of the bare metal portfolio, C4A-metal is powered by Titanium, a key component for multi-tier offloads and security that is foundational to our infrastructure.

High performance for demanding workloads

C4A-metal is particularly well-suited for complex tasks such as creating digital twins of vehicle cockpits where performance must accurately mirror real-world behavior. Traditionally, the transition to software-defined vehicles has relied on expensive and scarce physical prototypes; C4A-metal overcomes this by offering the high performance and hardware-level access of bare metal with the scalability of the cloud.

Panasonic Automotive leverages C4A-metal to bypass traditional hardware bottlenecks, enabling their teams to execute complex virtualization tasks and accelerate the development of next-generation cockpit software.

"Google Cloud’s Axion Bare Metal has been a game-changer for our vSkipGen™ platform. By providing scalable, high-performance Arm-based infrastructure, C4A-metal allows our teams to develop and test production-intent software in the cloud with behavior that closely matches target automotive hardware. This cloud-to-car bit parity reduces dependence on costly physical prototypes, improves validation efficiency, increases test coverage and accelerates time-to-market for next-generation cockpit platforms.” - Andrew Poliak, CTO, Panasonic Automotive Systems America.

By leveraging vSkipGen and Unified HMI on C4A-metal, automotive manufacturers can now build, test, and validate full AAOS stacks in a hardware-independent, cloud-native environment, moving from physical dependency to scalable digital twins.

Figure 1: Unified HMI solution overview

How vSkipGen works: Virtualizing the cockpit with Cuttlefish

Panasonic Automotive’s vSkipGen acts as a digital twin for physical CDC hardware. To provide a hardware-agnostic environment for Android virtual machines, vSkipGen uses components of Android Cuttlefish. At its core, vSkipGen leverages a cloud-optimized Virtual Machine Monitor (VMM) built on crosvm (the open-source, security-focused VMM originally developed for Chrome OS) which utilizes Linux KVM (Kernel-based Virtual Machine) for hardware-assisted virtualization. The VMM backend is implemented in Rust for enhanced security, scalability, and performance. By running the full stack on C4A-metal (see Figure 2), Panasonic lets developers boot a full AAOS image in the cloud, which behaves exactly like the software running in a physical vehicle.

The platform virtualizes all essential peripherals, such as the audio, GPU, sensors, cameras, Controller Area Network (CAN), Bluetooth, and Wi-Fi, using the VirtIO standard. This VirtIO-native approach allows developers to interact with the virtual devices exactly as they would with the physical hardware. Furthermore, vSkipGen seamlessly connects with automotive simulators and software-in-the-loop (SiL) environments for comprehensive scenario and edge-case validation, enabling teams to conduct software validation and run automated test suites without needing early access to physical prototypes.

Figure 2: vSkipGen Cockpit virtualization architecture

Figure 3: Remote GPU rendering flow

Accelerating graphics on the go with Unified HMI

High-performance graphics is central to the modern driving experience, but rendering it in a virtual environment can be challenging. Panasonic’s Unified HMI solves this by decoupling HMI rendering from specific hardware. A lightweight Unified HMI component operates outside the VM to offload OpenGL ES commands (the specific data being rendered) from the Cuttlefish instance to GPU-equipped compute resources on Google Cloud, which handle the workloads with hardware acceleration. The rendered UI is then streamed to any standard browser using low-latency WebRTC. This helps ensure that global development teams can experience high-fidelity visuals in real time, regardless of their location.

Unified HMI establishes a unified virtual display layer across multiple Electronic Control Units (ECUs) and virtual machines, allowing applications to render to different displays from anywhere within the system.

Benefits for software-defined vehicle development

With C4A-metal and Panasonic Automotive’s vSkipGen, manufacturers building software-defined vehicles can:

Build and validate AAOS-based software in the cloud using Cuttlefish before physical hardware is available
Use industry-standard VirtIO to emulate critical CDC devices for robust, production-grade validation
Stream interactive cockpit experiences to any browser to support distributed engineering teams
Run multiple isolated CDC instances in parallel to support large-scale automated testing and CI/CD pipelines
Reduce cost and environmental impact by minimizing the need for expensive physical hardware prototypes, supporting sustainable development practices
Enjoy a future-ready architecture built on open standards, crosvm, and Rust for enhanced security, performance, and long-term adaptability

Get started

C4A-metal is generally available worldwide; please refer to the public documentation for additional information. Panasonic Automotive’s vSkipGen with Unified HMI for Google Cloud will soon be available for evaluation access. To explore how these solutions can help you speed up cockpit software development, contact the team at vSkipGenSupport@panasonicautomotive.com.

_{Disclaimer
All trademarks, tradenames, and service marks used herein are the property of their respective owners.}

Three lessons in accelerating foundation model upgrades

Thu, 16 Jul 2026 16:00:00 +0000

Have you run into problems migrating your products from one model to the next?

Upgrading to the latest AI models is rarely simple. For engineering teams, model updates whether migrating to an entirely new model or updating to a newer checkpoint within the same model family, like moving from an earlier Gemini version to Gemini 3.5 — often require a slow and costly process of testing, proving quality, and manually evaluating new responses. For most engineering teams, upgrading to a new model checkpoint means months of manual toil to verify performance. And the industry is moving at breakneck pace – since 2023, we’ve announced six major model evolutions, bringing us to Gemini 3.5 today.

Our team at Google Cloud, Applied ML, has a goal to deliver transformative infrastructure and services that benefit both Google and our customers globally. As part of that, our team built an agentic workflow that completes model upgrades in hours instead of months.

In this blog, we’ll show you our approach and three lessons you can apply to accelerate your own foundation model upgrades using Gemini Enterprise Agent Platform — our new, comprehensive platform to build, scale, govern, and optimize agents – and Google Antigravity, our primary solution for developers using AI for coding and agent orchestration.

Three lessons in building a flexible agent system

To support different team needs, we had to rethink traditional automation and learned three key lessons along the way:

Lesson 1: Start with hands-on discovery. First, our engineers worked closely with product teams on real migration problems. This hands-on work helped us identify complex requirements and build our first guidelines for prompt optimization.
Lesson 2: Beware the rigidity of traditional automation. We turned these guidelines into a standard, automated workflow. While this version gave us some quick wins, we soon found that traditional automation was too rigid to handle different data formats and unique edge cases.
Lesson 3: Pivot to a flexible agent architecture. The real progress came when we rebuilt the tool using a flexible agent. Instead of forcing teams into a rigid process, the agent adapted to specific project needs, helping analyze data and test prompts dynamically with a high degree of adaptability.

How our partner teams cut migration time while boosting quality

Our partner team, which manages video translation and dubbing services, had an interesting challenge: their workflow required rewriting translated text so that the spoken duration matched the original video's pacing exactly, without altering the meaning. Historically, this strict constraint required maintaining a fine-tuned model. Their goal was to migrate to the latest out-of-the-box foundation model, guided purely by prompt engineering.

Using this agentic framework, the team provided their ground-truth dataset and baseline prompt. The system autonomously hill-climbed the prompt quality, migrating the service away from the custom stack

Make your own migration workflow with Agent Platform and Google Antigravity

These learnings can be applied by any engineering team looking to accelerate their own model upgrades. If your organization is struggling to keep pace with new foundational models, replacing manual toil with intelligent automation requires treating migration as an agentic workflow.

To build your own automated migration pipeline, follow these steps:

Deploy Autoraters: Pivot from manual human review to model-based Autoraters to evaluate the quality of a new checkpoint at scale and in a fraction of the time.
Build an agentic loop: You can use the Agent Development Kit within Gemini Enterprise Agent Platform to create your agent.
Automate the orchestration: To make the process even easier, leverage Antigravity to automate the underlying coding and agent orchestration and add in features such as loss reporting or headroom reports.

By shifting away from a manual, line-by-line engineering task, organizations can reduce infrastructural tech debt and confidently keep pace with the frontier of AI.

_{This work is the result of collaboration across Google. We thank key contributors: Anthony Green, Chris Lamb, Chungyen Li, Connie Huang, Elaine Han, Elena Erbiceanu Tener, Eugene Ie, Francesca Ciacchella, Igor Karpov, Jeanie Jung, Jose Menendez, Kiam Choo, Lina Sanders-Self, Longfei Shen, Martin Nikoltchev, Mason Ng, Matt Mancini, Paul Zhou, Pedram Oskouie, Samuel Smith, Tom Lawrie, Ye Tian, Zhen Lin}

C4N, now GA: Delivering cloud’s highest per vCPU network and block storage I/O for x86 workloads

Wed, 08 Jul 2026 20:00:00 +0000

September 15, 2026: C4N Instances with Titanium Local SSD (c4n-*-lssd) are now available in preview.

As organizations scale modern workloads — from high-throughput databases and network/security appliances to real-time analytics and AI/ML inference — network and block storage performance can quickly become a bottleneck. Standard virtual machines often struggle to balance compute efficiency with the high-volume data-transfer demands of these applications.

At Google Cloud Next ‘26, we announced C4N in preview, our first network- and block-storage-optimized Google Compute Engine instance that’s purpose-built to eliminate I/O bottlenecks for demanding enterprise applications, and today, it is generally available. Built on Google's custom-designed Titanium offload architecture, C4N instances offload network and storage tasks to dedicated hardware to unlock incredible performance and compute efficiency. C4N offers up to 400 Gbps of network bandwidth and a market-leading 95 million packets per second (MPPS) — nearly 33% higher network bandwidth per vCPU and 224% faster packet processing performance than comparable Intel-based offerings at other hyperscalers. This performance makes C4N a great fit for network-intensive applications such as virtual appliances (e.g., next-gen firewalls, virtual routers, load balancers, DDoS mitigation), large-scale data analytics, telco applications (5G UPF), distributed compute and CPU-based AI/ML workloads.

Paired with Hyperdisk Extreme, our high-performance block storage, C4N also delivers Compute Engine’s highest block storage performance, scaling up to 25 GiB/s of storage bandwidth and 1M IOPS — nearly 33% higher storage bandwidth and 39% more IOPS per vCPU versus comparable Intel-based offerings, making them a strong choice for large-scale databases, high-performance file systems, in-memory databases, and other workloads that benefit from high block storage performance.

Engineered specifically to deliver predictable, high-throughput I/O performance for networking, packets-per-second-bound and storage-optimized applications, C4N allows customers to scale network, storage, and compute resources more precisely to meet specific workload requirements, delivering significant TCO benefits by eliminating the need to over-provision resources just to meet I/O demands.

C4N is powered by 5th Gen Intel® Xeon® Scalable processors (code-named Emerald Rapids).

“Google Cloud’s introduction of C4N highlights how infrastructure innovation and a strong silicon foundation can help customers address increasingly data-intensive workloads. With Intel Xeon and Custom Infrastructure Processing Unit (IPU), C4N delivers the performance and efficiency needed for demanding network optimized environments.” – Srini Krishna, Intel Fellow, Data Center products, Intel

What’s new: Scaling massive data layers with C4N

Our network-optimized C4N instances are designed to deliver predictable, high-performance I/O at scale. By providing consistent bandwidth, packet-processing performance (PPS), and IOPS scaling across all VM shapes and sizes, C4N helps ensure your most demanding data workloads run reliably. To achieve this, we have built deep resiliency into every layer of our infrastructure — from the host and fabric layers to redundant top-of-rack (ToR) switches — delivering continuous performance for your applications.

Compared to general-purpose C4 VMs, the network-optimized C4N delivers significant performance gains across both network and block storage vectors.

Next-generation network performance

Superior VM-to-VM network bandwidth: Achieves up to 400 Gbps of VM-to-VM network bandwidth (an almost 4x increase in BW-per-vCPU over standard C4) and supports up to 50 Gbps single-flow bandwidth between C4N instances routed within the same VPC network. This provides non-blocking data delivery for high-throughput single-stream and multi-stream applications.
Enhanced VM-to-internet performance: Benefits from an 8x increase in internet egress network bandwidth, reaching up to 200 Gbps. It also features a nearly 32x increase in internet egress packet processing performance, scaling up to 48 MPPS.
Optimized I/O for smaller shapes: Keeps your cloud bill lean by delivering up to 25–50 Gbps of network bandwidth specifically for 2–16 vCPU shapes, great for accelerating I/O-bound tasks without needing to over-provision compute. Furthermore, these smaller shapes introduce predictable, steady-state baseline bandwidth limits to provide consistent performance at a lower cost.
Enhanced out-of-the-box networking: gVNIC interfaces on C4N now start with more Tx/Rx queues by default, scaling with vCPUs up to a maximum of 64 (in comparison to 16 queues on C4/C4D).
Shorter Google Cloud Storage transfer times: C4N VMs now offer up to a 2x increase in bandwidth to retrieve and store large volumes of data from Cloud Storage, boosting performance for analytics, AI/ML, and backup workloads.

Better yet, this performance is available out of the box, with no add-ons. Designed for high performance from the get-go, C4N offers maximum performance without needing to purchase or configure premium add-ons like Tier_1 networking.

Dynamic storage performance with Hyperdisk

The C4N instance family, when combined with Hyperdisk, can help dynamically tune storage performance, latency, and throughput independently of your compute instance sizing to deliver high block storage performance for your applications. C4N supports the complete Hyperdisk portfolio, including Hyperdisk Balanced, Balanced High Availability, Extreme, Throughput, and ML block storage options.

Hyperdisk Extreme: C4N with Hyperdisk Extreme provides low-latency, high-speed data access for modern databases and enterprise AI applications, with up to 25 GiB/s of block storage throughput and nearly 1M IOPS, a 2x increase in storage performance over C4. Also, exclusive to network optimized machine series such as C4N, we now offer Hyperdisk Extreme across all machine sizes — even down to the smallest 2 vCPU sizes.
Hyperdisk Balanced: Delivering the highest throughput and IOPS for general-purpose block storage in the Compute Engine portfolio, Hyperdisk Balanced on C4N scales up to 20 GiB/s of block storage throughput and nearly 640K IOPS. This makes it a highly cost-effective option for running storage-intensive applications at scale.

Together, C4N’s network and storage optimizations combine for tremendous impact in real-world applications:

Web serving: Up to 1.5x additional Nginx requests per second compared to C4 for typical web request sizes (100–300Kb), significantly boosting capacity for network-bound web applications
Databases: Up to 45% better queries per second (QPS) for MySQL when data resides primarily on disk than equivalent C4 VMs

What customers are saying

Industry leaders are already proving that workload-optimized infrastructure is the engine for transformation. Here is how our customers are leveraging the network-optimized power of C4N:

“5G Core workloads are inherently network-heavy, demanding high-throughput packet processing and deterministic latency that standard public cloud instances often struggle to maintain at scale. By leveraging the Google Cloud C4N compute family, we’ve found the ideal engine for Ericsson On-Demand. The C4N’s architectural focus on network-optimized compute allows our 5G Core-as-a-Service to reach unprecedented throughput levels — like our recent 1 Tbps milestone — while maintaining the carrier-grade reliability our customers expect. It’s no longer just about cloud-native; with C4N, we are delivering network-native performance in a public cloud environment.” - Eric Parsons, VP, Head of Ericsson On-Demand, Ericsson

“Teradata's Autonomous Knowledge Platform unifies production-grade AI, analytics, and data into a single integrated system — providing the context, governance, and performance backbone autonomous AI demands at scale. Customers rely on Teradata to run mission-critical, highly I/O-intensive workloads where performance and cost control directly determine value.

Google Cloud C4N instances are well suited for these demanding workloads, delivering strong price-performance and supporting more efficient, optimized deployments. By leveraging C4N on Google Cloud, Teradata Cloud can help customers accelerate from insight to action — scaling enterprise intelligence with confidence and driving greater impact from their data and AI investments” - Kevin Dougherty, Senior Director of Product Management, Core Platform, Teradata

“With the next-generation network and storage bandwidth of C4N VMs, Google Cloud NetApp Volumes will unlock new levels of performance to support our customers’ most demanding AI workloads. By collaborating to extend Google Cloud NetApp Volumes support for the C4N VM family, Google and NetApp are deepening our partnership to address real customer challenges. Together, we’re delivering data-in-place AI and analytics solutions that simplify architectures, maximize performance, and turn data into impact.” - Pravjit Tiwana, Senior Vice President and General Manager of Cloud Storage and Services, NetApp

"Most Compute Engine instances ship with a single high-speed network interface. The new C4N doubles the bandwidth potential with two 200 GbE interfaces. That architectural shift is significant. It means we can dedicate both networks entirely to storage traffic, doubling the available bandwidth for data-intensive workloads, and achieving 2x storage performance over the previous generation. The C4N was announced just weeks ago and is already active in Sycomp's test environment, ensuring our customers can evaluate the latest GCP capabilities without delay. Google Cloud’s published maximum hyperdisk balanced performance for the C4N is 20 GiB/s. In our tests, with three storage servers Sycomp achieved 58.5 GiB/s on read and 58.6 GiB/s on write, with ten C4N storage servers we achieved 195 GiB/s read and write — 97% of the theoretical ceiling with zero platform-specific tuning. That's a strong starting point, and there's measurable room to close the remaining gap through configuration work we can finetune. The C4N isn't just faster — it changes the price-performance equation for storage workloads on Google Cloud." - Scott Fadden, Senior HPC Solutions Architect, Sycomp

“At ClipperDB Technologies, our mission is to drive down the cost and drive up the performance of large-scale Spark analytics. Google Cloud’s C4N instances are the perfect compute engine for our fully native architecture. C4N’s substantial increase in network bandwidth per vCPU combined with large memory configurations and 5th Generation Intel Xeon processors align with ClipperDB’s precise parallel cloud-store prefetching and caching, concurrent dataflow native batch pipelines, streaming no-copy exchange, and cloud store checkpoint fault tolerance to radically accelerate and cost reduce Spark workloads with disaggregated Cloud Storage datalakes.

The results speak for themselves: across industry-standard TPC-DS benchmarks, ClipperDB+C4N delivered over 3x lower cost per query and up to 11x faster analytics, all while maintaining 100% Spark compatibility. We can’t wait to see customers dramatically improve their Spark workload price-performance with C4N coupled with Clipper DB Accelerator." - John Busch, CEO, ClipperDB Technologies

A deeper look at C4N shapes and specs

C4N instances are available in nine different sizes ranging from 2-192 vCPUs and up to 1.5 TB of DDR5 memory, offering predefined shapes in high-cpu, standard, and high-mem configurations. For applications that benefit from caching and high-speed, low-latency local storage, C4N VM instances are equipped with up to 12 TiB of latest Titanium SSDs. C4N with Local-SSD are in preview. For workloads that require direct access to the machine's resources (e.g., hypervisors, container platforms), where nested virtualization does not meet the workload’s performance requirements, or have special performance monitoring or licensing needs, we are introducing C4N bare metal shapes. Coming soon, these native bare metal shapes will offer the same network and storage I/O performance as their virtual machine counterparts. Google Cloud customers can use C4N instances with Compute Engine and Google Kubernetes Engine (GKE), with support for other services coming soon.

Name	vCPUs	Memory (GB)	Local Storage (GiB)	Network Bandwidth		Hyperdisk Extreme Bandwidth (MiB/s)	Hyperdisk Extreme IOPS
Name	vCPUs	Memory (GB)	Local Storage (GiB)	VM-VM (Gbps)	VM-Internet (Gbps)	Hyperdisk Extreme Bandwidth (MiB/s)	Hyperdisk Extreme IOPS
C4n-highcpu	2 - 192	4 - 384	N/A	25 - 400	7 - 200	1.000 - 25,000	80,000 - 1M
C4n-standard	2 - 192	7 - 720	N/A	25 - 400	7 - 200	1.000 - 25,000	80,000 - 1M
C4n-standard-lssd	4 - 192	15 - 720	375 - 12,000	30 - 400	7 - 200	1.000 - 25,000	100,000 - 1M
C4n-highmem	2 - 192	15 - 1,488	N/A	25 - 400	7 - 200	1.000 - 25,000	80,000 - 1M
C4n-highmem-lssd	4 - 192	31 - 1,488	375 - 12,000	30 - 400	7 - 200	1.000 - 25,000	100,000 - 1M

C4N machine series performance and specifications

How to get started

Whether you’re hosting heavy-duty distributed databases, running network virtualization appliances, or orchestrating large-scale data pipelines for AI, C4N is engineered to provide the throughput, scale, and efficiency your business demands. C4N instances are now generally available via on-demand, as Spot VMs, and via reservations. You can also take advantage of further cost savings by purchasing Committed Use Discounts (CUDs) or FlexCUDs in one- and three-year terms in the us-central1 (Iowa), us-east1 (South Carolina), us-east5 (Ohio), us-west1 (Oregon) and europe-west2 (London). For more information visit Network Optimized Machine Type.

Ready to establish a high-performance launchpad for innovation? Head straight to the Google Cloud console to spin up a C4N VM under the “Network Optimized” machine family. Stay up-to-date on regional availability by visiting our regions and zones page or contact your Google Cloud sales representative for more information.

Google Cloud named Leader in the 2026 Gartner® Magic Quadrant™ for AI Infrastructure

Wed, 08 Jul 2026 16:00:00 +0000

In the agentic era, AI is evolving from answering questions to reasoning and taking action. Companies who want to lead in this next phase of AI need computing infrastructure that’s designed and optimized for these new requirements, helping them innovate faster, deliver compelling user and customer experiences, and optimize for cost and energy efficiency — all at massive scale.

Today, we are pleased to announce that Google has been named a Leader in the inaugural Gartner^Ⓡ Magic Quadrant™ for AI Infrastructure, positioned highest for ‘Ability to Execute’ and furthest for ‘Completeness of Vision’. We believe their findings validate our dedication to solving these challenges internally and for our customers.

Read the full report: 2026 Gartner Magic Quadrant™ for AI Infrastructure

Building on the infrastructure foundation powering Gemini

Today’s model and serving architectures require a fundamental rethinking of how silicon and software interact. We realized early on that the platform we envisioned couldn’t be bought off the shelf — we had to invent it. For over a decade, our infrastructure engineers and Google DeepMind researchers have worked shoulder to shoulder to co-design the entire stack for Gemini, YouTube, and Search. We make those innovations, together with popular third party and open source software, available to our customers through Google Cloud. Today our integrated stack serves 9 out of 10 frontier AI labs; capital markets firms like Citadel Securities; and enterprises like Mercedes Benz.

At the hardware layer, Gartner recognized our commitment to custom silicon as a core strength. Earlier this year we shared two new advancements in custom silicon, our 8th generation TPUs, engineered to solve enterprise scaling and memory bottlenecks at a systems level:

TPU 8t, the training powerhouse: Purpose-built to optimize training timelines, TPU 8t packs 9,600 chips into a single superpod, delivering the high-density compute required for frontier models with nearly 3x the compute performance per pod over the previous generation.
TPU 8i, the inference engine: Engineered to handle the collaborative, iterative work of specialized agents, TPU 8i breaks the memory wall for real-time agentic workflows, with 288 GB of high-bandwidth memory and 384 MB of on-chip SRAM — 3x more than the previous generation — keeping a model's active working set entirely on-chip.

While our TPU platforms push the boundaries of what is possible, we know that one size doesn't fit all. Different customers have different workloads, different requirements, and different use cases. So, we also partner deeply with NVIDIA to deliver the latest accelerated computing platforms as highly performant, reliable and scalable services in Google Cloud. We will be among the first to deliver A5X instances based on the next-generation Vera Rubin platform when it becomes available later this year, enabling customer choice. We also work closely with NVIDIA to integrate GPUs into many Google Cloud software services to give our customers easier access to accelerated computing.

To enable even more flexibility, we continue to contribute to open-source projects across the orchestration, inference engines, and framework layers through llm-d and vLLM. We also recently announced TorchTPU, which gives PyTorch developers portability without complex code rewrites while maximizing the performance of their deployment.

Get more performance per dollar on AI Hypercomputer

As your infrastructure investment grows, you need to balance raw performance and cost to make AI applications economically viable. Taking a ‘buy now, integrate later’ approach to AI is becoming unsustainable. By combining pre-integrated hardware and open software frameworks that feature flexible consumption models, we deliver a unified system engineered for better performance per dollar across training, reinforcement learning, and inference.

Gartner recognized our integrated AI Hypercomputer as a core strength. This AI-optimized infrastructure is engineered to drastically improve your performance per dollar:

A massive compute cluster is only as effective as the storage system feeding it data. Google Cloud Managed Lustre, powered by our new C4NX instances and Hyperdisk Exapools, now delivers 10 TB/s of bandwidth — up to 20x faster than other hyperscalers — while Rapid Buckets transforms object storage with up to 20 million operations per second, helping ensuring large-scale training checkpoints and recoveries happen near-instantly.
Our Virgo Network provides a high-bandwidth scale-out fabric capable of connecting more than one million TPUs across multiple data center sites into a training cluster, or up to 960,000 GPUs across multiple sites without performance degradation — transforming globally distributed infrastructure into a unified supercomputer.
GKE Inference Gateway enables scaling models in production with near-zero latency by combining LLM-aware routing, caching, and the disaggregated serving capabilities of llm-d, increasing throughput by up to 40% while reducing serving costs up to 30%.

Run AI on a fluid infrastructure at virtually any scale

In the agentic era, infrastructure cannot be a rigid, static constraint. It must be an intelligent resource that adapts to the shifting priorities of your business, scaling up with demand and down to zero when agents are idle, with consistent, reliable performance. On AI Hypercomputer, you can:

Train smarter and faster, using Cluster Director and Google Kubernetes Engine to scale up to 130,000 nodes. At the same time, squeeze up to 97% productivity (Goodput) out of every accelerator using TPU 8t together with software co-designed with Google DeepMind and integrated open-source frameworks — from JAX to Pathways and Pallas.
Enable secure, low latency agent execution with GKE Agent Sandbox. Because agents need to scale, GKE Agent Sandbox can sense agent bursts and respond rapidly — provisioning up to 300 sandboxes per second per cluster, then instantly scale back when agents sit idle, optimizing compute costs.
Run distributed enterprise and AI workloads consistently across multicloud, edge, and on premises environments with Cross-Cloud Network and Cloud WAN. This approach delivers low-latency, policy-driven connectivity across Google’s private global backbone spanning over 10+ million kilometers of fiber and over 200 countries and territories, with up to 40% higher performance than public internet routing.

Take the next steps on your journey with AI Hypercomputer

From frontier models, to billion user applications, AI Hypercomputer gives you the purpose-built hardware, open software, and flexible consumption models you need to improve AI performance, cost, and developer productivity. We are honored to see decades of experience building scalable, affordable and reliable AI systems rewarded with a leadership position in Gartner’s research.

You can download a complimentary copy of the 2026 Gartner Magic Quadrant™ for AI Infrastructure on our website.

Report: 83% of organizations need to upgrade their infrastructure to support agentic AI

Tue, 07 Jul 2026 16:00:00 +0000

For years, enterprise AI has been synonymous with conversational AI — the customer service bots and digital assistants we interact with every day. But today, the market has shifted. We’ve officially moved from moving from AI that answers through simple chats, to AI that takes action, automated workflows, and executes complex tasks on its own. While this unlocks entirely new use cases, there’s a catch: it places significant stress on the underlying infrastructure we’ve relied on in the past.

We recently surveyed more than 1,400 senior IT leaders for our State of AI Infrastructure report, and a resounding pattern emerged: the gap between AI ambition and infrastructure reality is widening. In fact, 83% of organizations say they require infrastructure upgrades to support production-grade agentic AI.

Why? Because yesterday’s infrastructure simply wasn't built for agents that act autonomously.

In this blog, we lay out the core insights from our research on how leading organizations are rethinking their infrastructure to build resilient, fluid foundations. For more details and depth, we encourage you to download and read the full report.

Escape the “inference tax” with fluid compute

Agentic workloads introduce a new level of scale, where a single prompt can trigger hundreds of downstream actions, requiring massive context windows to be held in memory. Trying to run these continuous reasoning loops on legacy architecture is financially unsustainable. In fact, 62% of leaders are seeing a significant inference tax driven by data egress fees, storage bloat, and idle specialized hardware. Furthermore, 81% cite operational complexity as a hidden cost of scaling AI.

To fix this, organizations need fluid compute — the ability to dynamically match the right silicon to the right task while minimizing operational overheads.

For heavy training: Compute accelerators like our new TPU 8t deliver tremendous scale to train the world's most sophisticated models.
For low-latency inference: The TPU 8i, meanwhile, was purpose-built to maximize on-chip memory, so agents can think and react in real-time.
For orchestration: General-purpose compute powered by CPUs is emerging as a critical component for driving AI control plane operations. Using highly efficient, Arm-based processors like Google Axion, organizations can cost-effectively run reinforcement learning simulations and orchestrate agents.

Managing agent sprawl with centralized governance

Agents are designed to act autonomously — reading emails, querying databases, and executing workflows across your business. But as agentic AI scales, organizations are facing a new challenge: agent sprawl. How do you manage thousands of autonomous agents scattered across diverse platforms, without losing visibility and control?

It’s no surprise that 79% of tech leaders cite security, governance, and MLOps as their top challenge to scaling inference. In the agentic era, you need a mature governance strategy before you can innovate. This entails creating a centralized control plane that provides a single system of record for agent permissions, identity, and workflows.

Instead of patching together disparate tools, leading enterprises are relying on solutions like Agent Gateway to enforce enterprise-grade governance. Agent Gateway gives you the visibility you need to see exactly how agents are sharing data. It lets you define precise read/write scopes and maintain full audit trails of every interaction, and it provides human-in-the-loop oversight for when an agent needs approval before taking a critical action. This drive for unified, straightforward governance explains why 78% of organizations now source their gen AI solutions directly from their primary cloud partner — a 30 point increase from 2025.

A unified data layer

Agents perform reasoning, meaning they constantly run heavy queries across your organization. If your data is fragmented across silos, your AI is effectively flying blind.

To move from managing disconnected data to gathering unique and actionable business context, leaders are adopting a unified data layer. Using tools like Smart Storage — which automatically annotates unstructured data to make it searchable — and the Cross-Cloud Lakehouse, agents can natively read and understand data no matter where it lives, without needing custom pipelines or duplicated data.

Hybrid multicloud and digital sovereignty

The debate between public cloud and local computing is settled: hybrid is the destination. In fact, 52% of organizations now use a hybrid multicloud architecture.

For technology leaders, this shift is largely driven by digital sovereignty and data gravity. Indeed, 48% of leaders are prioritizing infrastructure with strict data residency controls. You need the flexibility to run AI where it complies with shifting local laws. Whether that’s leveraging the public cloud for broad compute, or bringing foundational models entirely on-premises via Google Distributed Cloud for air-gapped isolation, modern infrastructure must adapt to geopolitical realities, not the other way around.

AI at the edge

For technology leaders and infrastructure architects, relying on a strictly centralized cloud topology to process every agentic interaction is not a viable strategy. A staggering 90% of organizations now rank edge deployment as important for AI initiatives, with 72% describing it as extremely or very important.

Moving AI to the edge solves three issues:

The latency bottleneck: Real-time agents — especially those that rely on voice, video, or financial trading algorithms — can't afford the microsecond gap of a round-trip to a distant data center.
Operational resilience: If an internet connection drops, business can't stop. Edge deployment ensures that agents running in manufacturing plants, retail stores, or hospitals can continue functioning autonomously.
Sustaining cost-efficiency: Running always-on, continuous reasoning in the cloud is expensive. By utilizing highly optimized models on edge devices (like smartphones, IoT devices, or local warehouse servers), organizations shift the compute burden locally, drastically cutting variable per-token costs.

Breaking through the energy wall

Energy consumption used to be a sustainability metric reserved for annual reports. Today, it plays a crucial operational role. 91% of leaders now factor power consumption into their hardware selection, with 61% rating it as a primary or significant factor.

For technology leaders, power consumption presents a three-fold barrier to growth:

Grid scarcity: You simply cannot buy more power in certain regions, heavily limiting how much compute infrastructure can be provisioned.
Regulatory compliance: Energy efficiency is now a strict legal prerequisite to operate. For example, in Germany, new data centers must achieve a Power Usage Effectiveness (PUE) of 1.2 or lower. And Ireland now mandates that large data centers provide 100% on-site dispatchable generation to match their grid draw.
Infrastructure economics: Inefficient power envelopes drastically inflate the Total Cost of Ownership (TCO) of AI deployments. Accommodating high-power hardware requires massive capital expenditure (CapEx) for advanced cooling architectures, specialized rack designs, and facility upgrades.

To address the energy wall, technology leaders must treat energy as a strategic asset. One of the focus areas for optimization must shift to performance-per-watt. This is why co-designed silicon is becoming so important. For example, our new TPU 8t delivers nearly three times the performance of the prior generation while being up to twice as energy-efficient.

Unified, AI-optimized infrastructure

Ultimately, you cannot solve the challenges of tomorrow’s agentic systems with yesterday’s architecture. When engineering teams are forced to manually integrate heterogeneous compute, storage, and networking layers, organizations incur high operational overhead just to ensure basic interoperability.

To innovate quickly and cost-effectively, technology leaders are therefore moving toward holistic, unified systems.

This is the philosophy behind Google Cloud’s AI Hypercomputer. It’s an architecture where every layer is co-designed and co-engineered to work together. The custom silicon (TPUs, GPUs, CPUs) isn't designed in a silo; it's engineered alongside the ultra-high-bandwidth networking (Virgo Network), the storage (Managed Lustre, Hyperdisk), and the software orchestration layer (GKE).

Bridging the digital and physical worlds

When you embrace this co-designed, holistic approach, the results go far. With this level of scalable, fluid intelligence operating at the edge, we're entering the era of physical AI. A new generation of autonomous robots can sense, simulate, and navigate the physical world, practicing tasks millions of times in digital twin simulations on Google Cloud before they ever set foot in the real world. From performing complex industrial inspections to capturing cinematic videography, AI is now solving tangible problems in the real world.

Your blueprint for agentic AI

Adapting your infrastructure to meet the demands that agentic applications place on your systems will help you move from pilot to production. The organizations set to thrive in 2026 are embracing a unified foundation that is cost-efficient, resilient at the edge, optimized for autonomous action — and governed by default.

Ready to start? Download the State of AI Infrastructure report to explore the data behind our findings, and discover how your peers are already building for success.

Verifiable, private AI: Google Cloud expands Confidential Computing frontiers

Tue, 23 Jun 2026 16:00:00 +0000

Protecting sensitive data used with AI is a critical part of our commitment to providing advanced and secure cloud infrastructure. Confidential Computing cryptographically protects data in use in hardware-based Trusted Execution Environments (TEEs) with verifiable data integrity.

We are thrilled to share our latest Confidential Computing innovations across our hardware ecosystem that help further strengthen verifiable privacy in cloud AI deployments.

Confidential AI at global scale

By scaling our Confidential AI capabilities globally, we help ensure that AI inference and fine-tuning workloads can run with enforceable privacy guarantees.

Democratizing Confidential AI: Confidential G4 VMs with NVIDIA RTX PRO 6000 Blackwell GPUs in preview

We are excited to announce a landmark moment for accessible Confidential AI at global scale: Confidential VMs and Confidential GKE Nodes on the accelerator-optimized G4 machine series, featuring NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs.

What makes this a game-changer is its global scale and flexibility. Confidential G4 is available in every Google Cloud region that the standard G4 is available, across multiple consumption models including On Demand, Reservations, DWS Flex Start, and Spot/Preemptible.

"As organizations scale AI across multiple infrastructure environments, maintaining privacy and control over data and execution becomes increasingly challenging. Google Cloud Confidential G4 VMs powered by NVIDIA RTX PRO 6000 Blackwell GPUs are a meaningful addition to the expanding Confidential AI infrastructure ecosystem. As AI workflows now span agents, data sources, and infrastructure boundaries, Super Protocol provides a consistent Confidential AI operating model across Google Cloud Confidential VMs, other clouds, and on-premises environments — abstracting away confidential computing complexity and allowing teams to focus on AI outcomes," said Yulia Gontar, COO, Super Protocol.

Powered by 5th Generation AMD EPYC Turin CPUs leveraging AMD SEV, the G4 machine series with NVIDIA RTX PRO 6000 Blackwell GPUs activates robust hardware-based security. This architecture helps ensure that sensitive data is protected during processing inside the TEE, while also encrypting data as it travels between the CPU and GPU.

"GCP's Confidential G4 VM was the obvious choice for Vertebrae because privacy and security are non-negotiable for our customers. Our product processes sensitive work discussions, so we need to support hardware-signed attestation that both CPU and GPU are running in a trusted execution environment. Using confidential computing on Google Cloud lets us deliver the frontier of AI privacy in the cloud," said Andy Qin, CEO, Vertebrae.

With Confidential G4, you can unlock AI inference, fine-tuning, HPC, and use cases involving highly restricted data, sensitive models, or private prompts, all with minimal performance impact. Get started with Confidential G4 VMs and Confidential G4 GKE Nodes.

Enabling end-to-end private inference: Open-source Prompt Encryption SDKs

Even as we make Confidential AI accessible, we understand that protecting sensitive data in AI workloads goes beyond securing the model execution environment. The prompts and responses themselves can contain highly-confidential information. To provide cryptographic protection for the entire inference lifecycle, we are happy to announce the open-source launch of our Prompt Encryption SDKs, now available on GitHub.

This toolkit helps you establish an end-to-end secure channel for your AI inference workloads, ensuring that prompts are cryptographically protected from the moment they leave the client until they are processed in the TEE; model responses are similarly protected all the way back to the client.

Prompt and response encryption using Prompt Encryption SDK.

The Client SDK is integrated into the client application and works in tandem with the Server SDK integrated into the inference server running in the TEE. Once the SDKs have been used to establish an attested TLS session, the client can be confident that the server is running an authorized workload within a verified Confidential Computing environment.

The client app can then send encrypted prompts to the inference server, knowing that only this server will be able to decrypt and process it in the TEE. Once the server has a response ready, it sends it back via the same encrypted channel to the client app.

You can get started today with the GitHub repository and the Codelab.

Enabling Apple Private Cloud Compute on Google Cloud

Our commitment to privacy is deeply exemplified by our collaboration with Apple to expand Private Cloud Compute (PCC) on Google Cloud.

We are proud to collaborate with Apple to extend Apple’s privacy and security commitments to PCC on Google Cloud. Our platform supports Apple’s PCC privacy commitments with a layered security approach built upon Google Cloud’s infrastructure. This includes leveraging Google Cloud Confidential Computing with Intel TDX, NVIDIA Confidential Computing with NVIDIA Blackwell GPUs, our Titanium security architecture with the Titan chip, and a co-engineered open-source host stack to ensure verifiable transparency.

Together, these technologies help Apple PCC on Google Cloud meet stringent requirements for data protection and user privacy. To dive deeper into this collaboration, read our blog post: Powering the next era of Confidential AI.

Advancing confidential foundations

Google Cloud is committed to making Confidential Computing capabilities broadly available across our infrastructure. Our goal is to integrate hardware-based security features deeply into our foundational compute offerings, allowing customers to enhance data protection without compromising performance or operational flexibility.

Bringing Intel Trusted Domain Extensions (TDX) to the C4 machine series

Confidential VMs with Intel TDX on the C4 machine series will be available in preview soon.

Powered by the latest 6th Generation Intel Xeon processors, this integration offers a significant leap in compute density and performance for data-intensive workloads. By using Intel TDX, C4 instances create hardware-isolated Trust Domains (TDs) that protect sensitive applications and data from the underlying host and hypervisor.

This architecture provides confidentiality and privacy while enabling remote attestation so you can cryptographically verify the environment before processing sensitive data. Best of all, you can turn Confidential Computing on with a few clicks and no code changes.

Expanding Live Migration capabilities

Running mission-critical production environments requires high availability and continuous uptime, even during scheduled cloud maintenance.

Live Migration on C3D-based Confidential VMs is now generally available. This capability allows Google Cloud to perform planned hardware maintenance without interrupting workloads or exposing encrypted guest memory, ensuring seamless uptime for long-running confidential applications.

Enhancing trust and collaboration: Innovations in Confidential Space

Confidential Space is a Confidential Computing environment designed to enable secure multi-party computation and data sharing. It allows organizations to collaborate on sensitive data, such as for joint machine learning or data analytics, without revealing the data to each other or to Google Cloud.

“Google Cloud Confidential Space allows us to provide financial institutions with security guarantees similar to or better than an on-prem service," said Olivier Richaud, vice-president, Platforms and Site Reliability Engineering, Symphony. "Transitioning such security and privacy-sensitive customers to a cloud-based SaaS service would have been impossible without the power of Confidential Computing.”

A key design principle of Confidential Space is to remove the workload operator from the trust boundary, providing cryptographic assurance that only the authorized, attested workload can access the data.

“As AI systems increasingly act on behalf of consumers in financial services, trust in how data is processed becomes paramount. At Sahamati, we see Google Cloud Confidential Space as a foundational technology for enabling privacy-preserving AI in India’s Open Finance ecosystem, creating the trust needed for innovation while maintaining strong security and accountability guarantees,” said Kiran Gopinath, chief innovation officer, and Head, Sahamati Labs.

Our new advancements for Confidential Space provide greater flexibility and stronger assurances. Key updates include:

Independent Verification: Integration with Intel Trust Authority

We are pleased to announce that Intel Trust Authority (ITA) is now generally available as an independent attestation verifier service for Confidential Space.

This integration enables organizations to independently verify the integrity of the Confidential Space environment using Intel’s hardware-rooted attestation before encryption keys are released to workloads. By decoupling attestation verification from the cloud service provider, customers benefit from enhanced transparency, stronger assurance, and a more robust trust model.

"With Confidential Computing woven into our core infrastructure, Google Cloud and Intel are making hardware‑rooted security and independent attestation part of the default fabric of modern compute. From Intel TDX‑powered C4 Confidential VMs running production workloads, to Confidential Space with Intel Trust Authority — now generally available — enabling verifiable multi‑party collaboration, customers can now encrypt, verify, and scale their most sensitive AI and data workflows without rewriting applications or compromising performance, even in the most demanding regulatory environments,” said Anand Pashupathy, general manager and vice-president, Intel Product Assurance and Security (IPAS), Intel Corporation.

Accelerating secure collaboration: Confidential Space with H100 GPU support

To power secure multi-party AI and machine learning, Confidential Space support for NVIDIA Hopper GPUs is now generally available. This can help multiple parties pool their data for training and inference within a Confidential Space environment, using the power of Hopper GPUs, while ensuring that their individual data remains protected from other participants and from Google Cloud.

Confidential Space unlocks use cases like federated learning on sensitive datasets, and building joint models without centralizing data.

“Confidential GPU support in Google Cloud Confidential Space removes one of the biggest barriers to adopting secure AI: the tradeoff between protecting sensitive workloads and achieving production-grade performance," said Adi Hirschtein, VP Product, Duality. "For Duality customers in healthcare, financial services, and government, this enables federated learning, confidential AI, and encrypted RAG workflows to run on sensitive data at scale while keeping data and models protected throughout processing.”

Next steps

Confidential Computing is becoming an essential layer of cloud computing in the AI era. Explore our expanding portfolio of Confidential VMs, accelerated hardware, and open-source tools to see how you can enable secure collaboration and private AI innovation within your organization.

To learn more, join us at the Confidential Computing Summit on June 23 and 24, 2026.

SAP SAPPHIRE 2026: Google Cloud unveils unified agentic vision and massive compute scaling

Tue, 12 May 2026 19:00:00 +0000

In today's hyper-connected market, an enterprise's most valuable asset — mission-critical data — often remains trapped in legacy silos. For years, leadership teams have navigated a data pipeline dilemma, forced into a cycle of complex data movement that relies on slow, manual extraction processes. This fragmentation strips away essential business context, increases technical debt, and creates operational blindness.

Al is reshaping enterprise operations, but to move beyond simple optimization and actively transform core processes, organizations must be able to turn their vast data into tangible action. The true value of Al lies in its ability to bridge the gap between deep business insights and strong execution. To shift enterprises from a reactive posture to a state of predictive, real-time intelligence, SAP and Google Cloud are delivering a Unified Data Foundation. This deepening partnership connects critical business data directly to intelligent workflows, so that every insight effortlessly transitions from intent to action without disruption.

Here’s a breakdown of the key new features announced today at SAP SAPPHIRE to modernize the enterprise core and unlock true data value:

Open agent collaboration: Through expanded strategic partnerships, SAP is integrating new agentic capabilities into the SAP Business AI Platform. This establishes an open architectural framework, enabling bidirectional communication between SAP’s Joule agents and intelligent agents built on Google Cloud (such as Gemini Enterprise Agent Platform and Gemini).
SAP BDC Connect for BigQuery: The SAP Business Data Cloud (BDC) Connect for BigQuery — currently in private preview — enables customers to share their semantically rich SAP data directly into BigQuery. This establishes bidirectional, zero-copy, and zero-cost data access, allowing organizations to unify their data footprint without the complexity of moving or duplicating massive datasets.
50% larger memory instances: Breaking the previous 32TB memory limit of the X4 memory-optimized machine type, a new X5 series introduces massive 48TB configurations. This empowers the largest SAP HANA and RISE with SAP customers to easily scale up their mission-critical databases on a single node.
Sovereign Cloud with S3NS: SAP is partnering with S3NS to deploy its RISE private cloud on a SecNumCloud-qualified platform in France, enabling regulated organizations like Thales to securely transform their ERP environments.
Google SecOps for SAP: Google and SAP are partnering on agentic security workflows and threat detection for SAP applications. Available in preview, Google SecOps for SAP provides agentic AI security operations and empowers security teams to detect SAP-specific threats alongside their broader IT landscape.
Google Cloud Cortex Framework: Cortex Framework simplifies your journey from SAP to AI. Now in preview, these data product accelerators lower the risk and cost of building agentic solutions using BigQuery and Gemini.

What they're saying

Mercado Libre is the leading e-commerce and fintech business in Latin America with more than 100 million users, and Google Cloud’s new memory-optimized instances for SAP are having a big impact:

"We are pushing very hard to use AI capabilities to leverage the information we generate from BigQuery, and we are also using Gemini to empower our employees to be more productive following our migration to RISE. As our business has experienced unprecedented growth, ensuring our data infrastructure can keep pace with this AI-driven trajectory is critical. Google Cloud’s announcement of the new 48TB instances is a game-changer for us. It allows us to seamlessly scale our mission-critical databases on a single node, avoiding major application redesigns and ensuring our real-time operations continue without disruption as we scale." - Alejandro Bonsignore, Finance and People Systems Senior Manager, Mercado Libre

The agentic future: Making data active

The goal of these integrations is simple: to transform static records into autonomous, agentic workflows. Before Al can act with precision, it requires a comprehensive understanding of how your business runs. By utilizing the BDC connector to extend a unified foundation across the broader enterprise data estate, agents running on Gemini for Google Cloud and Gemini Enterprise Agent Platform can natively utilize this trusted data as part of their workflow.

Crucially, Cortex Framework accelerates this journey by moving beyond basic data consolidation to transform fragmented enterprise data silos into context-rich, high-fidelity data products. It establishes a trusted semantic layer that translates raw "database speak" into meaningful "business speak." This gives your organization the ability to make Al more reliable, accurate, and capable of taking decisive action across platforms.

Transforming data into autonomous action at scale means enterprise-grade governance remains paramount. Together, SAP and Google Cloud provide the holistic capabilities needed to govern Al responsibly across the entire organization. Grounding Gemini models in governed enterprise context directly mitigates Al hallucination risks and drives strong value. With this collaboration, your organization has the peace of mind that every agent operates securely, is grounded in trusted data, and remains fully accountable as it drives measurable business outcomes.

Learn more about the SAP and Google Cloud partnership.

Cluster-level reliability for trillion-parameter models on TPUs

Mon, 11 May 2026 16:30:00 +0000

Frontier AI models have redefined the unit of compute. At trillion-parameter scale, AI training requires thousands of interconnected components, orchestrated in industrial-scale deployments to operate as a single, massive entity.

Likewise, when it comes to reliability, aggregate infrastructure availability is what matters. Yet for almost two decades, instance-level reliability has been the cloud standard. Designed for microservices and horizontally scalable applications, instance-level reliability treats infrastructure as a collection of small independent units. This model is fundamentally inadequate for large-scale AI workloads.

We believe reliability must shift from an instance- to a cluster-level model.

For over a decade, Google has operated Tensor Processing Unit (TPU) clusters at scale, achieving reliability that meets the architectural requirements of modern AI workloads. In this blog, we’re presenting our cluster-level reliability framework for Google Cloud TPUs that focuses on collective performance at the superpod level, and one we use internally within Google to build the world’s most advanced AI models. This framework is the operational standard for TPUs in production today, and serves as the architectural blueprint for our recently announced eighth-generation TPUs.

Reliability for AI supercomputers

TPU superpods consist of thousands of chips arranged into cubes (64 TPUs), with high-speed Inter-Chip Interconnect (ICI) links connecting every chip within a cube and a dynamically configurable Optical Circuit Switch (OCS) network connecting all cubes to form a superpod.

For system-wide training progress, we must maximize the number of fully healthy cubes within a superpod. Because the performance of AI models relies on high-bandwidth, low-latency communication, every chip and ICI link within a cube must be operational for that unit to contribute to the training progress. Driven by these architectural realities, our cluster-level framework helps define how the industry can achieve reliability in the AI era, moving from instance-level reliability to availability of scale.

Deep dive: The mathematics of availability at scale

Instance-level reliability models are often deterministic, but industrial-scale AI deployments require a probabilistic approach over thousands of chips. In a traditional setup, you might track the Mean Time Between Failures (MTBF) of a single chip. However, at the scale of frontier AI, the cluster-level MTBF drops sharply as the number of components grows.

To visualize how quickly scaling can erode confidence, we can look at simple bounds like Markov’s inequality.

If we define X as the number of failed cubes, Markov’s inequality reminds us that as the expected number of failures E[X] increases with cluster size, the probability of staying below a strict failure threshold becomes increasingly difficult to guarantee without systemic architectural changes.

While Markov’s inequality provides a helpful rule of thumb for the risks at scale, we model the availability of scale using a binomial distribution of aggregate cluster health. For a superpod composed of n independent units (cubes), we define the probability of having at least k fully operational and interconnected cubes as the cumulative distribution of the success of n independent trials. To ensure a 95% confidence interval for training productivity, we solve for k where:

Where n represents the total cubes in a superpod and p represents the aggregate cube-level availability.

This model replaces the instance-level model with a topology-aware framework that mirrors actual performance requirements of large-scale training, ensuring that the larger block of compute is healthy and connected and can drive continuous training progress.

Scale of modern AI hardware

To demonstrate this new reliability model, we used Ironwood, Google’s generally available, seventh-generation TPU, and the custom silicon behind advanced models like Gemini and Nano Banana.

Pictured: Part of an Ironwood superpod, directly connecting 9,216 Ironwood TPUs in a single domain.

An Ironwood superpod is a dense, high-performance fabric consisting of 9,216 chips integrated into a single compute domain. It’s organized into 144 cubes, where each cube contains 64 chips. Within these cubes, ICI links create an extremely dense, all-to-all network fabric that provides massive bandwidth and low-latency connectivity for distributed operations within the cube. To form a superpod, 144 cubes are connected using OCS. For large jobs, capacity can be provisioned by interconnecting multiple cubes within a pod into one super-slice, or connecting multiple slices to form a multi-slice cluster. Cubes across multiple superpods can be connected over the datacenter network to run even larger workloads.

Using this model, we determine that the topological availability for an Ironwood superpod is 130 out of 144 cubes available for 95% of the month. This translates to a large compute block of 8,320 chips that are fully operational and interconnected via ICI and OCS, establishing a reliability model specifically optimized for hero jobs (the massive training runs of frontier AI).

The relationship between cluster size and its statistical availability is non-linear. By adjusting the required confidence level, we can identify the slice size that can be supported with statistical certainty. For researchers, this mapping provides a capacity availability curve. An organization with a workload that requires 99% availability for a mission-critical run can optimize their slice size to 125 cubes, while those pushing utmost scale can utilize 130 cubes at the 95% confidence interval.

Capacity availability curve for an Ironwood superpod (144 cubes)

This new reliability model maximizes the utility of the entire superpod through:

Full access: This model does not constrain capacity utilization; it focuses on the availability of fully healthy cubes. While a single chip or ICI failure results in the entire cube being classified as unhealthy, customers continue to have access to the remaining capacity within the cube. This makes most of the Ironwood superpod available for use while also optimizing the compute footprint for high-stakes, large-scale training.
Optimized resource usage: While the 130-cube model focuses primarily on large-scale training runs, the full superpod remains available for a heterogeneous mix of workloads. This allows researchers to utilize the remaining cubes for research experiments, inference, and dev/test workloads, maximizing the utility of the superpod without compromising the reliability of the main training run.

Our customers are using Ironwood at scale today and this model has empowered them to train their most demanding hero jobs.

Enhancing ML productivity

The goodput metric is the primary measure of ML productivity. Our new reliability standard provides the deterministic foundation for goodput and is engineered to maximize this metric for demanding hero jobs, so that the massive scale infrastructure required for frontier research is ready to perform as a single entity.

This model achieves high scheduling goodput, one of the three goodput metrics, by making the full set of resources available for massive-scale training runs. Combined with the software stack, this infrastructure-level availability helps deliver the high overall goodput. We achieve this through a three-layer reliability model:

Infrastructure: TPU superpods provide the capacity footprint to ensure the necessary scale is physically available and connected.
Frameworks: JAX and Pathways provide resilience, reconfiguring or hot-swapping around failed nodes to maintain forward progress without requiring a full restart.
Application: Fault-tolerance mechanisms like auto-checkpointing and multi-tier checkpointing preserve training state, so that lost progress is minimized in case of a failure.

Enabling the next generation of AI breakthroughs

The cluster-level reliability model marks the beginning of a new standard for the AI era, where an AI supercomputer is a dependable, industrial-scale engine for innovation. By aligning our reliability posture with the demands of frontier models, we’re enabling the next generation of AI breakthroughs to be faster, more reliable, and more predictable. Click here to learn more and get started with TPUs.

What’s new with compute: Scaling core and agentic workloads

Wed, 22 Apr 2026 12:00:00 +0000

At Google Cloud Next, we’re announcing a range of compute capabilities to enable your core general purpose and AI workloads for the agentic world with higher performance and lower costs.

Why it matters: IT leaders and builders are faced with balancing compute investments and resources between agentic AI and the general purpose use cases, including the web servers, databases, and enterprise applications that drive everyday customer experiences.

On one side, agents can place unpredictable demand on compute infrastructure, often scaling exponentially. A single user interaction can instantaneously kick off hundreds of concurrent, high-throughput, and low-latency tasks. On the other side, general-purpose workloads generate and hold the data required to fuel the agentic world. Relying on static and siloed infrastructure to run them can risk performance bottlenecks and spiraling costs, leaving your organization unable to respond to surges in demand.

Consider a global travel application where a simple vacation search instantly triggers a massive orchestration of agentic inventory checks, dynamic pricing models, and AI-driven personalized itineraries. Without a modern architecture, this sudden surge in demand can overwhelm the core booking database and bring business to a halt.

We address this with fluid compute, Google Cloud infrastructure that adapts to your general-purpose and agentic workflows, enabling both to win by flexing in performance, capacity, and scale, all in real time. This dynamic flexibility relies directly on the automated orchestration of Google Kubernetes Engine (GKE) and our new Agent Sandboxes to instantly provision secure, isolated execution environments at machine speed.

Let’s take a deeper look at the new compute capabilities announced at Next ‘26.

Run AI and general purpose workloads together

Agentic planning and reinforcement learning depend on highly fluid compute to process unpredictable bursts of autonomous tasks. Relying on static infrastructure to isolate agent-generated code can create severe provisioning delays and heavily inflate your cloud budget. You can remove these bottlenecks by adopting an adaptive cloud foundation. Leveraging GKE Agent Sandboxes empowers your teams to securely launch thousands of execution environments. Pairing these scalable sandboxes with efficient Google Axion processors helps your organization optimize total cost of ownership while fueling artificial intelligence innovation.

Here’s what’s new in Google Cloud compute launches and announcements:

Google Axion N4A is GA: Harness the agility of Google’s custom Arm-based Axion CPUs and achieve up to 2x better price-performance than comparable current-generation x86-based VMs for cost-sensitive workloads such as Java applications, scale-out web servers, and SaaS built by startups, enterprises and partners. Learn more here.
GKE Agent Sandbox, with Axion N4A for price performance, is GA. As the industry’s only native sandbox service among hyperscalers, GKE Agent Sandbox offers scalable and low-latency infrastructure designed for agents to safely execute untrusted code and tool calls without sacrificing performance. With Google Axion, you can build agents on leading infrastructure without compromising on cost or choice. GKE Agent Sandbox running on Google Axion N4A instances provides up to 30% better price-performance than the next leading hyperscale cloud provider. Try GKE Agent Sandbox here.
Google Axion C4A.metal, our first Axion bare metal instance, is in preview: C4A.metal instances power Android development, automotive simulation, CI/CD pipelines, security workloads, and custom hypervisors, without the performance overhead and complexity of nested virtualization. C4A.metal will be GA this summer; learn more here.
C4 instances offer expanded support for Intel Xeon 6 (Granite Rapids) across all shapes: Achieve high-performance for AI workloads like LLM inference and vector search by using Intel AMX with native FP16 support to increase throughput and reduce latency, offering 13% better price-performance versus comparable Intel Xeon 6-based VMs from another leading hyperscaler. C4 VMs are available with Intel Xeon 6 processors across all shapes. Learn more here.
Flexible CUDs expanded support is GA: Shift spend across regions and VM families while optimizing for TCO, with flexible committed use discounts, now with support for a wider range of VM families and services, including memory-optimized (M1-M4) and HPC-optimized (H3, H4D) VM families, as well as Cloud Run. Learn more here.

Here’s what customers are saying:

Unity: Unity is redefining the economics of real-time AI with Unity Vector. By migrating its on-demand feature processor workloads to Google Axion N4A instances, Unity achieved a 20% improvement in cost efficiency without sacrificing latency. As Unity Vector scales to meet increasing demand, the move to N4A instances ensures that Unity continues to deliver industry-leading performance at a sustainable cost.

Deutsche Börse: A leading German market infrastructure provider, Deutsche Börse migrated and modernized dozens of core financial applications onto Google Compute Engine VMs, including latest generation C4 and C4D instances, supporting latency-sensitive Oracle databases and post-trade processing at scale, and boosting release speed, operational agility, and resilience. This delivered the consistent performance they needed to process millions of financial transactions every day and they achieved 58% faster time to market and 33% lower TCO.

WP Engine: WP Engine powers millions of digital experiences where every millisecond matters. By running GKE clusters on C4D and N4D instances, WP Engine has seen up to a 60% reduction in latency for mobile-optimized REST APIs and up to 51% faster processing for data-rich application requests.

eDreams ODIGEO: Operating a high-volume, AI-powered travel platform where every millisecond dictates the customer experience, eDreams ODIGEO migrated its foundational Java-based ecommerce modules on GKE to Axion virtual machines. This immediately eliminated weeks of manual code optimization, delivered a massive 75% improvement in P95 latency with zero code changes, and unlocked price-performance to scale their global services far more cost-effectively than their legacy x86 infrastructure could.

Chainguard: Prioritizing absolute isolation for their foundational software build system, Chainguard deployed the new Axion C4A bare metal instances. This allowed them to establish a strong hypervisor security boundary for package builds, secure their development pipeline with architectural parity, and ensure robust protection, all without compromising build performance.

Run I/O and latency-sensitive workloads together

Both AI and core workloads depend on the ability to store, read, and move data as a single, high-performance operation. Traditionally, these stages are slowed by network and storage limits tethered to vCPU counts, which can starve AI models of the data they need to function. You can remove these constraints by leveraging accelerated Hyperdisk performance for rapid data access and high-performance networking for consistent transit. By allowing your data pipelines to scale independently of compute, your AI training and I/O-sensitive workloads have the dedicated bandwidth they need to remain stable under peak demand.

C4N is in preview: Running high-volume network applications such as concurrent mobile app requests and real-time inventory updates can risk bottlenecks during peak traffic. Maximize your throughput with C4N, featuring Titanium adapters that offload complex packet processing to deliver a market-leading 95 million packets per second — a 40% performance advantage for high-traffic network applications compared to other leading hyperscalers. Designed to rapidly transfer large datasets, C4N provides nearly 400 Gbps of VM-to-VM bandwidth, a 4x improvement in bandwidth-per-vCPU, and achieves an 8x increase in egress network bandwidth through internet gateways compared to C4 VMs. C4N with Hyperdisk Extreme also provides the low-latency, high-speed data access that modern databases and enterprise AI applications need, with 25 GiB/s of block storage throughput and nearly 1M IOPS. Sign-up here for C4N preview access.
M4N is in preview: Running memory-intensive databases can push organizations to overprovision compute cores (vCPU) to meet memory speeds, driving up software licensing fees. We introduced the new M4N series to solve this exact problem. Running Oracle workloads on M4N with Hyperdisk Extreme can reduce TCO by over 20%, enabling you to run Oracle more efficiently, with 26.57 GiB of RAM per vCPU for scale and on far fewer cores. Paired together, M4N with Hyperdisk Extreme delivers the highest per-core IOPS and throughput for high-memory instances across leading hyperscalers. Sign-up for the preview here.
Announcing Z4D: Optimize I/O-intensive workloads and remove network-based storage bottlenecks with new Z4D instances. By securing up to 84 TiB of high-performance local SSD directly on the node, organizations can process massive datasets for SQL, NoSQL, and vector databases. Z4D provides up to 400 Gbps of VM-to-VM bandwidth, matching both C4N and M4N. Z4D virtual machines and bare metal instances will be in preview soon.

Here is what customers are saying:

Ericsson: 5G Core workloads are inherently network-heavy, demanding high-throughput packet processing and deterministic latency that standard public cloud instances often struggle to maintain at scale. By leveraging the Google Cloud C4N, they’ve found the ideal choice for network performance to power Ericsson On-Demand. C4N’s architectural focus on network-optimized compute allows its 5G Core-as-a-Service to reach unprecedented throughput levels, like its recent 1 Tbps milestone, while maintaining the carrier-grade reliability its customers expect.

Teradata: Teradata’s Autonomous Knowledge Cloud enables the world’s largest enterprises to activate enterprise intelligence and turn trusted data into measurable business outcomes. Customers rely on Teradata to run mission‑critical, highly I/O‑intensive analytics at scale where performance and efficiency directly determine value. C4N instances are well suited for these demanding workloads, delivering strong price‑performance and supporting more efficient, optimized deployments. With C4N, Teradata can help customers accelerate insights, scale with confidence, and drive greater impact from their data and AI investments.

Handle demanding storage requirements

Foundational workloads such as web servers, applications, and databases hold the data required to fuel the agentic world. Siloing this critical information on rigid hardware creates bottlenecks that can completely stall enterprise modernization. Imagine a global retail brand running a holiday promotion, but the inventory database times out and drops customer requests because the legacy hardware couldn’t process the sudden flood of agentic queries.

Organizations require the highest performing database hosts backed by high performance IOPS and throughput per vCPU to ensure non-blocking data delivery. Moving these applications to modern cloud infrastructure dramatically improves total cost of ownership and operational throughput. Through strategic cloud migrations, customers can eliminate the architectural walls that stall modernization and unlock their data for AI. Here is what is new in fluid compute for throughput- and capacity-sensitive workloads:

Hyperdisk Balanced improvements. Hyperdisk Balanced enables fast and efficient block storage for general purpose workloads, including applications and relational databases. With Hyperdisk Balanced you can drive up to 2.4 GiB/s and 160K IOPS per volume, higher than general-purpose block storage offerings from other hyperscalers, all while achieving lower mean latency than alternatives. With Hyperdisk Balanced High Availability you can now achieve a 4x performance improvement for high availability databases like SQL Server or PostgreSQL by dynamically routing full disk performance to the active VM, removing the need to overprovision storage. Leverage zero-downtime encryption key rotation and consistency groups for instant snapshots, making it easier to stay more secure. With these capabilities, you can deliver lower TCO, higher performance, and workload resilience for your general-purpose workloads. Learn more here.
Hyperdisk ML performance improvements and Hyperdisk Exapools are GA: With 2 TiB/s of aggregate throughput (up from 1.2 TiB/s), Hyperdisk ML helps eliminate AI storage bottlenecks, offering more than 200x higher throughput per disk than competitive offerings, so your valuable accelerator clusters never sit idle. This allows you to maximize AI compute ROI while powering the next generation of intelligent agents. In addition, for large-scale training needs, Hyperdisk Exapools offer the highest aggregate block storage performance and capacity, per AI cluster, of any hyperscaler. Learn more about Hyperdisk ML and Exapools here and here.
Announcing Z4M: Access up to 168 TiB of local SSD coupled with up to 400 Gbps of network bandwidth, support for RDMA, and bare-metal shapes to run distributed parallel file systems and large-scale AI/ML workloads. Z4M will be integrated with Cluster Director with the option to be colocated with accelerators to provide fast and low-latency access to data. Z4M VMs and bare metal instances are expected to be in preview in Q3 2026.

Here is what customers are saying:

Shopify: During Black Friday weekend sales, Shopify processed over $14.6B and tracked 136 million packages for 81M buyers using its Shop App built on Compute Engine’s Z-series backed storage — without compromising speed or reliability.

HubX: Operating a massive portfolio of AI-powered mobile applications where rapid model loading dictates the user experience, HubX deployed Hyperdisk ML on GKE to eliminate severe I/O bottlenecks. Leveraging this specialized storage layer allowed HubX to support hundreds of concurrent readers and accelerate pod initialization times by 30x during peak traffic surges, drastically reducing idle accelerator costs and helping ensure their complex inference workloads scaled as expected.

Fluid infrastructure for the agentic era

Now, your foundational workloads and agents no longer need to compete for capacity or performance. With Google Cloud’s fluid compute, you get adaptive cloud infrastructure that prevents bottlenecks and enables both your foundational and AI workloads to collaborate and thrive.

Ready to get started? Head straight to the Google Cloud console to spin up a VM for your next big project. Or start planning your migration by checking out Migration Center's AI-powered toolsets to perform cost estimates, create a business case, and evaluate your modernization options.

Inside the eighth-generation TPU: An architecture deep dive

Wed, 22 Apr 2026 12:00:00 +0000

At Google, our TPU design philosophy has always been centered on three pillars: scalability, reliability, and efficiency. As AI models evolve from dense large language models (LLMs) to massive Mixture-of-Experts (MoEs) and reasoning-heavy architectures, the hardware must do more than just add floating point operations per second (FLOPS); it must evolve to meet the specific operational intensities of the latest workloads.

The rise of agentic AI requires infrastructure that can handle long context windows and complex sequential logic. At the same time, world models have emerged as a necessary evolution from current next-sequence-of-data architectures, which means newer agents are simulating future scenarios, anticipating consequences, and learning through "imagination" rather than risky trial-and-error. The eighth-generation TPUs (TPU 8t and TPU 8i) are our answer to these challenges, ensuring that every workload, from the first token of training to the final step of a multi-turn reasoning chain, is running on the most efficient path possible. They are built to efficiently train and serve world models like Google DeepMind’s Genie 3, enabling millions of agents to practice and refine their reasoning in diverse simulated environments.

TPU 8: Specialized by design

Recognizing that the infrastructure requirements for pre-training, post-training, and real-time serving have diverged, our eighth-generation TPUs introduce two distinct systems: TPU 8t and TPU 8i. These new systems are key components of Google Cloud's AI Hypercomputer, an integrated supercomputing architecture that combines hardware, software, and networking to power the full AI lifecycle. While both systems share the core DNA of Google’s AI stack and support the full AI lifecycle, each is built to address distinct bottlenecks and optimize efficiency for critical stages of development. Additionally, by integrating Arm-based Axion CPU headers across our eighth-generation TPU system, we’ve removed the host bottleneck caused by data preparation latency. Axion provides the compute headroom to handle complex data preprocessing and orchestration, so that TPUs stay fed and don’t stall.

TPU 8t: The pre-training powerhouse

Optimized for massive-scale pre-training and embedding-heavy workloads, TPU 8t utilizes our proven 3D torus network topology at an even larger scale of 9,600 chips in a single superpod. TPU 8t is designed for maximum throughput across hundreds of superpods, ensuring that training runs stay on schedule.

Here are some key advancements of TPU 8t over prior-generation TPUs:

The SparseCore advantage: Central to TPU 8t is the SparseCore, a specialized accelerator designed to handle the irregular memory access patterns of embedding lookups. While the Matrix Multiply Unit (MXU) handles matrix math, the SparseCore offloads data-dependent all-gather operations, amongst other collectives, preventing the zero-op bottlenecks that often plague general-purpose chips.
VPU/MXU overlap and balanced scaling: TPU 8t is designed to maximize provisioned FLOPs utilization. By implementing more balanced Vector Processing Unit (VPU) scaling, the architecture minimizes exposed vector operation time. This allows for better overlapping of quantization, softmax, and layernorms with the matrix multiplications in the MXU, helping the chip stay busy rather than waiting on sequential vector tasks.
Native FP4: TPU 8t introduces native 4-bit floating point (FP4) to overcome memory bandwidth bottlenecks, doubling MXU throughput while maintaining accuracy for large models even at lower-precision quantization. By reducing the bits per parameter, the platform minimizes energy-intensive data movement and allows larger model layers to fit within local hardware buffers for peak compute utilization.

Figure 1: TPU 8t ASIC block diagram

Virgo Network topology and up to 4x data center network increase: To support the massive data requirements of TPU 8t, we introduced Virgo Network. This new networking architecture enables up to 4x increased data center network (DCN) bandwidth on TPU 8t training over DCN. Virgo Network is a scale-out fabric designed for the extreme requirements of modern AI workloads. Built on high-radix switches that reduce network layers by allowing more ports per switch, it employs a flat, two-layer non-blocking topology. Compared with traditional datacenter networks, this significantly reduces latency by minimizing network tiers. It features a multi-planar design with independent control domains to connect TPU 8t chips. The TPU 8t racks also connect with the Jupiter north-south fabric to access compute and storage services. Together, this streamlined architecture delivers the massive bisection bandwidth and deterministic low latency necessary for enabling the world's largest training clusters with high availability.

With 2x scale-up bandwidth on the inter-chip interconnect (ICI) and up to 4x raw scale-out DCN bandwidth compared to the previous generation, TPU 8t drastically reduces data bottlenecks. Then, to further accelerate the development of frontier models, we scale distributed training beyond a single cluster. With JAX and Pathways, we can now scale to more than 1 million TPU chips in a single training cluster. Virgo Network can link over 134,000 TPU 8t chips with up to 47 petabits/sec of non-blocking bi-sectional bandwidth in a single fabric. This fabric delivers over 1.7K ExaFlops with near-linear scaling performance.

Figure 2: TPU 8t rack level connectivity to Virgo fabric

Faster storage access: We are introducing TPUDirect RDMA and TPU Direct Storage in TPU 8t. TPU Direct RDMA enables direct data transfers between the TPU's memory (HBM) and the Network Interface Cards (NICs), bypassing the host CPU and DRAM. This reduces latency and host system bottlenecks, increasing the effective bandwidth for TPU-to-TPU communication. Similarly, TPUDirect Storage bypasses CPU host bottlenecks by enabling direct memory access between the TPU and high-speed managed storage like 10T Lustre, effectively doubling the bandwidth for massive data transfers. This architecture allows the silicon to ingest training data at line rate, ensuring that the MXUs stay fully saturated even when processing large multimodal datasets.

By combining Managed Lustre 10T and TPUDirect Storage to route hundred-petabyte datasets directly to the silicon, TPU 8t prevents training delays caused by data ingestion bottlenecks. This delivers 10x faster storage access compared to training on seventh-generation Ironwood TPUs.

Figure 3: The top diagram shows the data transfer path without TPUDirect Storage. The bottom diagram shows TPU 8t data transfer with TPUDirect Storage between 2 TPU 8t chips and TPUDirect Storage with Managed 10T Lustre storage.

TPU 8i: The sampling and serving specialist

Optimized for post-training and high-concurrency reasoning, we designed TPU 8i with our highest on-chip SRAM, a new Collectives Acceleration Engine (CAE), and a new serving-optimized network topology called Boardfly.

Large on-chip SRAM: With 3x more on-chip SRAM over the previous generation, TPU 8i can host a larger KV Cache entirely on silicon, significantly reducing the idle time of the cores during long-context decoding.

Figure 4: TPU 8i ASIC block diagram

The Collectives Acceleration Engine (CAE): To solve the sampling bottleneck, TPU 8i uses the CAE, which aggregates results across cores with near-zero latency, specifically accelerating the reduction and synchronization steps required during auto-regressive decoding and "chain-of-thought" processing. For each TPU 8i chip, there are two Tensor Cores (TC) on-core dies and one CAE on the chiplet die, replacing four SparseCores (SCs) on core dies in previous-generation Ironwood TPU. By integrating a specialized CAE, TPU 8i further reduces the on-chip latency of collectives by 5x. Lower latency per collective operation means less time spent waiting, directly contributing to higher throughput required to run millions of agents concurrently.
Boardfly ICI topology: While the 3D torus allows connecting thousands of chips to be used in cohesion, a large mesh does have more hops between chips and higher all-to-all latencies. For 8i, we changed how the chips connect together in fully connected boards that are then aggregated into groups. Utilizing a high-radix design, we connect up-to 1,152 of these chips together, reducing the network diameter and the number of hops a data packet must take to cross the system. By slashing the hops required for all-to-all communication (the heart of MoE and reasoning models), Boardfly achieves up to a 50% improvement in latency for communication-intensive workloads.

Figure 5: TPU 8i hierarchical Boardfly topology building up from a building block of four fully connected chips into a fully connected group of eight boards, with 36 of such groups fully connected into a TPU 8i pod

Boardfly consists of the following elements, and its topology is hierarchical by nature:

Building Block (BB): Each tray forms a four-chip ring using internal ICI links, providing 16 external connections for broader networking.
Group (G): Eight boards are fully connected via copper cabling to create a localized group, utilizing 11 of the available external links for intra-group communication.
Pod structure: The final architecture scales to 36 groups (up to 1,024 active chips) linked through Optical Circuit Switches (OCS), ensuring a maximum latency of seven hops for any chip-to-chip communication.

Deep dive: The Boardfly vs. torus math

Why move away from the torus for TPU 8i? It comes down to network diameter.

In a 3D torus, nodes are arranged in a grid where each dimension wraps around like a ring. To reach the furthest possible chip in a 8 x 8 x 16 (1024-chip) configuration, a packet must traverse half the distance of each ring:

3D torus = 8/2(X) + 8/2(Y) + 16/2(Z) = 16 hops

While the torus is highly efficient for the neighbor-to-neighbor communication typical of dense training, it creates a latency tax for all-to-all communication patterns. In the era of reasoning models and MoE, where any chip may need to talk to any other chip to route a token, this hop count matters.

Boardfly’s high-radix topology is inspired by Dragonfly topology principles. By increasing the number of direct optical long-haul links between groups of boards, we flatten the network. For that same 1024-chip pod, Boardfly reduces the network diameter from 16 hops down to just seven.

This 56% reduction in network diameter translates directly to lower tail latency, so that the TPU 8i CAE isn't left waiting for data to arrive from across the pod.

Figure 6: A visual representation of the maximum seven-hop ICI network diameter via optical circuit switch on TPU 8i pod

TPU 8t and TPU 8i at a glance

Feature	TPU 8t	TPU 8i
Primary Workload	Large-scale pre-training	Sampling, serving, and reasoning
Network Topology	3D torus	Boardfly
Specialized Chip Features	SparseCore (Embeddings) & LLM Decoder Engine	CAE (Collectives Acceleration Engine)
HBM Capacity	216 GB	288 GB
On-Chip SRAM (Vmem)	128 MB	384 MB
Peak FP4 PFLOPs	12.6	10.1
HBM Bandwidth	6,528 GB/s	8,601 GB/s (~1.3x of TPU 8t)
CPU Header	Arm Axion	Arm Axion

Software enablement: A performance-first AI stack

Hardware is only as powerful as the software that drives it. The eighth generation of TPUs are built on the same performance-first stack we pioneered with the seventh-generation Ironwood TPUs, designed to make custom kernel development accessible without sacrificing the abstraction of high-level frameworks. This stack includes:

Pallas and Mosaic: We provide first-class support for Pallas, our custom kernel language that lets you write hardware-aware kernels in Python. This enables you to squeeze every drop of performance out of the TPU 8i CAE and the TPU 8t SparseCore.
Native PyTorch experience: We're thrilled to share that native PyTorch support for TPUs is now in preview. If you're currently building and serving models on PyTorch, we've made it easier than ever to start using TPUs. You can bring your existing models to our TPUs just as they are, complete with full support for the native features you rely on, such as Eager Mode.
Portability: The same JAX, PyTorch, or Keras code that runs on Ironwood scales to this generation. Accelerated Linear Algebra (XLA) handles the complex translation of the Boardfly topology and CAE synchronization behind the scenes, allowing you to focus on your model, not the interconnect.

Generation over generation: The performance leap

Our commitment to co-designing hardware and software continues to pay dividends. When compared to seventh-generation Ironwood TPU, the eighthgeneration TPUs deliver massive gains:

Training price-performance: TPU 8t delivers up to 2.7x performance-per-dollar improvement over Ironwood TPU for large-scale training.
Inference price-performance: TPU 8i delivers up to 80% performance-per-dollar improvement over Ironwood TPU, particularly at low-latency targets for large MoE models.
Energy efficiency: Both chips deliver up to 2x better performance-per-watt, critical for scaling the next generation of AI sustainably.

Looking ahead

To empower Google Cloud customers pioneering the next wave of innovation, we designed TPU 8t and TPU 8i as two distinct, specialized systems tailored to the multifaceted future demands of the AI lifecycle. TPU 8t and 8i are both purpose-built for the most demanding serving and training workloads, fully integrating with the AI Hypercomputer software stack: JAX, PyTorch, vLLM, XLA, and Pathways. This specialization and ground-up redesign, all in deep collaboration with Google Deepmind, delivers exceptional price-performance and power efficiency.

The modularity of our eighth-generation architecture provides a clear and unique roadmap for the future. Just as every major shift in the computing landscape has required infrastructure breakthroughs, so does the agentic era. Reasoning agents that plan, execute, and learn within continuous feedback loops cannot operate at peak efficiency on hardware that was originally optimized for traditional training or transactional inference; their operational intensity are fundamentally distinct. Our eighth-generation TPU infrastructure has evolved to meet these specific requirements head-on.

To learn more about the eighth-generation TPU family:

Compute

Day 0 support for Reflection’s Beam on Google Cloud: 5x faster perf with llm-d and NVIDIA Dynamo

Scaling inference requires system-level optimization

Model-level efficiency: Reflection’s Beam

System-level efficiency: AI Hypercomputer optimized serving

Inside the AI Hypercomputer inference architecture

System optimizations for multi-turn agentic workloads

Get started and meet us at PyTorchCon and GTC Berlin

Introducing Google Cloud’s U4 compute: Enabling ultra-low latency trading

Powered by Google Cloud-native infrastructure

Storage and placement for trading workloads

Getting started with the ULL Solution

GKE CPU startup boost: Accelerate app starts without over-provisioning

Why modern applications need extra CPU at boot time

How CPU startup boost can help

Under the hood: Kubernetes In-place Pod Resize

How CPU startup boost works (pod lifecycle overview)

Prerequisites and availability

Getting started: Configuring CPU startup boost

Example 1: Pod-level boost with fixed steady-state (updateMode: "Off")

Example 2: Combining startup boost with continuous VPA auto-scaling

Example 3: Granular container-level boost

Verifying startup boost in your cluster

Best practices for production workloads

Get started today

What’s new in AI infrastructure and orchestration in September

Product, technology, and tools updates

Practitioner guides and how-tos

Customer and partner updates

Research, reports and deep-dives

August 2026

Product, technology, and tools updates

Practitioner guides, documentation and how-tos

Customer and partner updates

July 2026

Product, technology, and tools updates

Practitioner guides and how-tos

Research, reports and deep-dives

June 2026

Product, technology and tool updates

Practitioner guides and how-tos

Research, reports and deep-dives

Customer and partner updates

May 2026

Product, technology and tool updates

Research, reports and deep dives

Customer and partner updates

Storage-optimized Z4D machine family, now GA, is designed for IO-intensive workloads

Z4D VMs and bare-metal instances

What customers and partners are saying

Enhanced maintenance experience

Support for Hyperdisk

Get started with Z4D today

M4N VM family, now GA: Highest per-core IOPS and throughput for I/O and memory-bound workloads

Built for demanding workloads

Optimizing Oracle licensing costs

What customers are saying

What’s new: Scaling extreme data layers with M4N

1. Enabling high bandwidth data transfer

2. Dynamic storage performance with Hyperdisk

M4N machine types and specifications

Get started today

Google is a leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026

Build on co-designed infrastructure proven in global enterprises

Run agents quickly on a secure, flexible platform

Ground your agents with real-time enterprise data

The benchmark is set: Build what’s next on Google Cloud

Google named a Leader in 2026 Gartner® Magic Quadrant™ for Strategic Cloud Platform Services

1. Accelerate AI with a co-designed stack without lock-in

2. Scale quickly and economically with a dynamic infrastructure

3. Embrace digital sovereignty with more choice and security

Accelerate your Cloud journey

Dynamic capacity management for AI infrastructure

Here's a quick summary

Why architectural flexibility matters

How to overcome infrastructure constraints

Take the next step toward dynamic infrastructure

PQC in Plaintext: Google Cloud’s post-quantum cryptography roadmap

Our strategy: Secure by design

Immediate progress: 2026 milestones

Example 1: Pod-level boost with fixed steady-state (`updateMode: "Off"`)