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 Worker Pools GA — Pull-Based Background Workers for Pub/Sub & Queues

Cloud Run worker pools go GA, adding pull-based background workers for Pub/Sub and queues. Also note Gemini model previews, retirements, and GKE CNI changes.

Aug 24, 2026·3mcloud-runvertex-ai
GCP

Gemini Flash GA: Gemini API, Enterprise Agent Platform, and BigQuery in-database inference

Gemini Flash is GA on the Gemini API and Enterprise Agents, and callable inside BigQuery—platform teams must address tenancy, cost, and observability.

Aug 22, 2026·3mgemini-flashgemini-api
GCP

GKE 1.36: Autopilot Arm ComputeClasses (autopilot-arm, autopilot-arm-spot) for mixed Arm/x86 clusters

GKE 1.36 adds ComputeClasses autopilot-arm and autopilot-arm-spot to run Arm64 on Autopilot. Platform teams must handle multi-arch CI, builds and cost tracking.

Aug 21, 2026·3mgkeautopilot