GCP

Google Cloud Run GPUs GA: serverless GPU scale without quota choreography

Google Cloud Run GPUs are GA: attach GPUs to serverless instances and scale from zero to large fleets. Platform teams must rethink inference and cost controls.

July 22, 2026·3 min read·AI researched · AI written · AI reviewed

Cloud Run will now attach GPUs to serverless instances and scale them from zero to thousands in seconds — and you don't have to beg for quotas before you hit production. That's the part that should make platform teams rewrite parts of their inference architecture today.

This isn't a small convenience feature. Allowing GPUs on an autoscaling, scale-to-zero platform with reduced quota choreography flips the trade-offs between serverless and Kubernetes/VM-based serving. For teams running Gemini Pro previews or other multimodal models, the path from prototype to production just got shorter: AI Studio includes a deploy-to-Cloud Run flow, and Cloud Run can serve models on available GPU capacity without the same manual quota choreography in many cases.

The serverless GPU pivot

Cloud Run GPUs GA promises fast scale to large numbers of GPU-backed containers and reduces the prior operational step of manual quota requests in many workflows. In practice that means platform teams can deploy stateless GPU inference containers the same way they deploy HTTP microservices: push an image, set concurrency and instance spec, and let Cloud Run autoscale. If your workload truly fits the Cloud Run model — stateless instances, short-lived requests, and modest GPU memory per container — this will save substantial ops complexity.

That said, "instant" isn't magic. Large multimodal agents with hundreds of GBs of pinned state still belong on GKE or VM fleets. What Cloud Run gives you is predictability and speed for a large class of inference: compact models, sharded microservices, adapters, and agent components that are horizontally scalable. The one-click bridge from AI Studio to Cloud Run makes that frictionless. Expect teams to split inference surfaces: low-latency, horizontally scaled endpoints on Cloud Run; stateful, high-capacity serving on GKE or dedicated GPU pools.

Cost, governance, and the new accounting model

Google has also announced changes to billing defaults that enable Committed Use Discount (CUD) sharing behavior for eligible billing accounts. This is a material shift for cross-project cost allocation — discounts that formerly sat with a single project can now be applied across a billing account unless account owners change the setting.

Call this the accounting equivalent of "no quota requests": platform teams need to own cost governance. If you don't pin CUD sharing to your organizational policy, discounts can reflow across projects in ways that break allocation, chargebacks, and showback models. Review billing accounts and update billing governance now; this is not a nice-to-have tweak, it's a change that will alter monthly cost reports.

Tooling nudges: GKE checks and Gemini Pro preview

On the Kubernetes side, GKE and related cluster validation tooling have improved accelerator and node auto-provisioning validations and offer better cluster health checks. Those validations will catch many misconfigurations that would otherwise surface only under GPU pressure. If you run hybrid GPU fleets (Cloud Run + GKE), add these checks to your CI and policy gates — they matter.

Meanwhile, Gemini Pro previews are available across Vertex AI, AI Studio, and the Gemini API. The combination is clear: Google wants model development, experimentation, and serving to live inside the same ecosystem, and Cloud Run is now a first-class option for delivery.

This is the right call — but it's also disruptive

Removing quota friction and enabling one-click deployments is the right developer experience move. The alternative was messy, fragile quota choreography and ad-hoc VM fleets. But platform engineers who treat Cloud Run GPUs like a free pass will get burned: uncontrolled autoscaling of GPU-backed endpoints can blow budgets and create unexpected load on shared cluster tooling.

If your team runs inference at scale, start by: (1) auditing billing account CUD settings, (2) adding strict autoscaling and concurrency caps to GPU services, and (3) folding GKE/cluster validation checks into CI. And mentally separate what belongs on Cloud Run (stateless, scale-out inference) from what needs GKE (large memory/affinity, complex GPU topology).

Final bite: Google just lowered the barrier to putting GPUs behind HTTP endpoints. That will accelerate experimentation and push more real traffic to serverless GPUs. Platform teams who standardize controls now — not later — will get the productivity upside without the cost surprise.

Sources

cloud-rungeminigcp-billinggkevertex-ai
← All articles
GCP

Gemini Pro preview, Cloud Run Worker Pools GA, and network-optimized VMs for GKE

Gemini Pro preview on Vertex AI, Cloud Run Worker Pools GA, and a network-optimized VM family for GKE give GCP building blocks for agent-first serverless AI.

Jul 26, 2026·3mgeminicloud-run-worker-pools
GCP

Gemini Pro preview in Vertex AI and public APIs: what platform teams must do

Google broadened Gemini 3.1 Pro access to Vertex AI and APIs, widening developer surfaces and forcing platform teams to treat model access like infrastructure.

Jul 25, 2026·3mvertex-aigemini
GCP

Cloud Run worker pools GA: pull-based, non-HTTP workers as a first-class resource

Cloud Run worker pools are GA for pull-based, non-HTTP workloads, providing a serverless primitive for background/batch jobs that changes scaling and cost.

Jul 23, 2026·3mcloud-rungke