GCP

Gemini Pro preview in Vertex AI, Flash‑Lite rollout, and Cloud Run worker pools GA

Google previewed a Gemini Pro in Vertex AI and rolled Flash‑Lite into Vertex AI and the Gemini API. Cloud Run worker pools GA brings always‑on inference options.

September 13, 2026·3 min read·AI researched · AI written · AI reviewed

Cloud Run just crossed a boundary most platform teams assumed it wouldn't: it now offers an always‑on, pull‑based execution model that you operate like a managed worker fleet. Cloud Run worker pools reached GA this week, giving teams a first‑class, always‑running compute option for queue processors, background jobs, and — importantly — large‑scale AI inference. Combine that with Cloud Run instances (still Preview) for long‑lived, addressable workloads and Google has quietly widened Cloud Run from a request‑driven, scale‑to‑zero service into a spectrum that includes persistent, per‑instance compute.

That matters because it changes expectations for cost, telemetry, and trust boundaries. Until now Cloud Run's default mental model was ephemeral, stateless services where a misbehaving instance surfaces quickly and is cheap. Worker pools and instances are different: they give you density, predictable warm state, and lower latency for inference — but they also create a new operational surface that looks a lot like a managed server fleet. If you treat worker pools like old request‑driven Cloud Run, you will get surprised by cold‑start mitigation, stuck tasks, agent credentials persisted in memory, and different billing profiles.

Meanwhile, Google previewed a higher‑capability Gemini Pro model in Vertex AI and is rolling a lower‑latency Flash‑Lite variant into Vertex AI and the Gemini API via Google AI tooling. The product messaging is straightforward: higher‑capability models appear inside the managed Vertex AI stack for enterprise workflows, while Flash‑Lite targets high‑QPS use cases with lower latency and lower cost. Google is also pushing platform patterns for agentic workflows and calling out GKE‑based hardening for inference, using a set of protections it refers to as Model Armor.

The net effect: Google is aligning compute and model strategy. If you need low latency and high throughput inference, you now have overlapping options: Cloud Run worker pools (always‑on, managed), Cloud Run instances (addressable, long‑lived preview), and GKE with the Model Armor protections (hardened, opinionated inference). Choose based on control vs. convenience, not on whether "serverless" is the only label you use.

The security and billing story matters as much as the tech. Model Armor and the GKE play are overdue and the right call — hardened inference inside a cluster with mTLS, workload policy, and sidecar‑level protections is where serious customers will run sensitive models. But worker pools move a subset of that workload out of Kubernetes control planes and into Google‑managed primitives. Platform teams must therefore extend identity, network, and secrets controls to Cloud Run worker pools and instances, not just to GKE. Google also announced expanded billing flexibility for agent workloads and previewed delayed‑start pricing for Cloud Run jobs. That sounds like a cost win for asynchronous agents and batch scoring, but it's also a lever teams will abuse if they don't control scheduling and retention.

Opinion: this shift is overdue and sensible. Google is giving product teams primitives that better match modern AI patterns — persistent inference, agent orchestration, and hybrid serving. The problem is not the primitives; it's that many infra teams still assume Cloud Run == ephemeral HTTP. You'll need to treat Cloud Run like a first‑class fleet: observability for long‑lived tasks, identity boundaries for agents, and quota/billing alarms.

If you want a short next step, start by mapping your inference surface: which models need persistent warm state, which can tolerate Flash‑Lite accuracy/latency tradeoffs, and which require GKE‑level hardening. If you already run agent workloads, the new billing options and worker pools let you consolidate, but only if you refactor telemetry and secrets handling first.

Google's releases this week are less about adding point features and more about giving teams a continuum of execution and model options. Expect some workloads to migrate off Kubernetes for convenience — and expect new surprises when identity or cost controls lag. If your infra still treats Cloud Run as stateless, this is the update that should change your playbook.

Sources

geminivertex-aicloud-rungke
← All articles
GCP

GKE rapid channel 1.36.4-gke.1082000: default for new clusters; older rapid and alpha builds removed

New GKE rapid-channel clusters default to 1.36.4-gke.1082000; older rapid/alpha builds were removed. Pin cluster versions, audit CNI and topology billing ASAP.

Sep 11, 2026·3mgkekubernetes
GCP

Google Cloud: 50% Provisioned Throughput Credit for Gemini Flash Through 2026; GKE 1.37 in Rapid

Google Cloud gives a 50% Provisioned Throughput credit for Gemini Flash through Dec 31, 2026, and adds GKE 1.37 to the Rapid channel, changing TCO now.

Sep 10, 2026·3mgoogle-cloudgemini-api
GCP

Cloud Run Instances (Preview): long-lived, addressable workloads and per-instance pricing

Cloud Run Instances (Preview) expose long‑lived, addressable workloads with per‑instance billing (1 vCPU + 1 GiB steady cost). Rethink always‑on agents.

Sep 9, 2026·3mcloud-rungke