GCP

BigQuery: Gemini 'flash' and 'flash-lite' models now GA in Generative AI functions

Gemini 'flash' and 'flash-lite' models are GA in BigQuery Generative AI across US, EU and global regions — teams must rethink cost, locality and governance.

August 11, 2026·3 min read·AI researched · AI written · AI reviewed

BigQuery just became a much easier place to run Gemini models. Google announced GA support for gemini-3.1-flash-lite and gemini-3.5-flash across the us, eu, and global multi-regions, and both are available to use in BigQuery's generative AI functions.

This is the sharp edge of two trends colliding: cloud providers stuffing inference into data warehouses, and customers wanting fewer hops between large datasets and models. Practically, it means you can call a flash-class Gemini model from a SQL query or a BigQuery function without stitching together Vertex AI endpoints, data movement jobs, or extra networking. That's latency and operational complexity removed — and cost and governance problems pushed into BigQuery.

Why this matters

'the flash' models are the higher-capacity, lower-latency option; 'flash-lite' is the smaller, cheaper sibling. Having both available in BigQuery lets teams pick a price/latency point inline with query workloads. For event-driven analytics or interactive BI (think answers embedded in dashboards), that reduces end-to-end response times in a way external model hosting rarely matches.

But make no mistake: this is not just convenience. When model execution lives inside BigQuery, model invocation shows up on query bills, not your Vertex or custom inference ledger. If your finance or platform teams haven't instrumented BigQuery for model usage, you will start seeing surprise spikes on the data warehouse bill. In short: this is the right move technically, but it's going to punish teams that treat BigQuery as "just SQL storage."

Cloud Run moves and the non-HTTP reality

Parallel product moves this week underscore another platform shift. The Cloud Functions-to-Cloud Run migration/upgrade tool reached GA, giving a supported migration path from first-gen Functions to Cloud Run. Cloud Run worker pools are also GA — a proper resource type for pull-based, non-HTTP workloads.

These updates acknowledge reality: serverless is no longer only request/response. Pull-based workers and migration tooling reduce the incentive to bolt custom runners for background AI preprocessing or model ingestion. If your AI platform relied on ad-hoc VM fleets or container runtimes to glue data and models, Cloud Run's worker model is the straightforward replacement.

Billing changes you can't ignore

Google quietly toggled a meaningful billing-policy default: resource-based committed use discount (CUD) sharing moves from disabled to enabled for new billing accounts and many eligible existing accounts without active CUDs. That's a big administrative change. For finance teams, enabling resource-based CUD sharing by default will often improve utilization and reduce waste — and it will silently change who benefits from committed discounts across projects.

Release notes also carried operational billing tweaks: an App Topology API billing change and adjustments to ML volume throughput minimums when volumes are attached to many instances. Small changes for each product, but collectively they change cost calculations for ML infra at scale.

What platform teams should actually do (short list)

  • Treat BigQuery as an inference endpoint: add model-invocation metering and alerting tied to budget allocations. Dont rely on labels alone.
  • Re-evaluate quota and locality guardrails: models in global vs us/eu affect data residency and egress assumptions.
  • Update your migration plan if you run legacy Cloud Functions: the GA upgrade/migration tool removes a lot of friction.

Final take

Google's packaging of Gemini into BigQuery is overdue and inevitable. It's the sensible UX for analysts and product teams who want models close to data. But convenience changes the economics and trust boundaries: expect central platform teams to get paged not because a model failed, but because a dashboard query invoked a flash model and consumed three days of committed spend in an hour. If you run an internal AI platform, your next sprint should be about observability and budget fences, not new inference endpoints.

For more on Cloud Run's direction with worker pools and resource-based sharing, see the previous coverage of Cloud Run worker pools GA and Cloud Run managed workers and CUD sharing.

Sources

google-cloudbigquerygeminicloud-rungcp-billing
← All articles
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
GCP

Cloud Run adds NVIDIA L4 GPU support; Cloud Functions-to-Cloud Run upgrade tool GA

Cloud Run adds NVIDIA L4 GPU support with managed drivers; a Cloud Functions-to-Cloud Run upgrade tool is GA—simplifying serverless GPU inference migrations.

Sep 8, 2026·3mgcpcloud-run
GCP

GKE 1.36: Dataplane V2 Emits CNI cniVersion 1.1.0 — Upgrade Risk for CNI Plugins

Dataplane V2 in GKE 1.36 emits CNI configs with cniVersion 1.1.0. Plugins lacking 1.1.0 semantics can fail to set up pod networking during upgrades — validate.

Sep 6, 2026·3mgkekubernetes