8.2 Choosing the Product & Deployment Strategy
Key Takeaways
- Google's training-method comparison lists AutoML and BigQuery ML as needing no data science expertise, while serverless training, training clusters, and Ray require you to write the training application.
- Managed Training Clusters reserve dedicated high-end accelerators (such as A100 or H100 GPUs) for large, long-running training with guaranteed capacity.
- Agent Platform Pipelines turns a successful product choice into a repeatable, orchestrated workflow rather than a one-off notebook run.
- Batch inference fits latency-tolerant scoring of large datasets without a deployed endpoint, while online inference needs a deployed endpoint for real-time requests.
- Edge deployment fits intermittent connectivity, strict on-device latency, or data that shouldn't leave the device.
Last updated: September 2026
Section 3.1 of the exam guide also asks you to choose the product (for example, Agent Platform AutoML, BigQuery ML, and Agent Platform Pipelines) and choose the deployment strategy. These are architecture decisions made before detailed training and serving design (Chapters 9-14).
Product Choice for Building the Model
| Product | Expertise needed | Control | Choose when |
|---|---|---|---|
| BigQuery ML | SQL, no data science expertise required | Moderate (model options, hyperparameter tuning) | Data in BigQuery, standard model types, SQL team, in-warehouse scoring |
| Agent Platform AutoML | None (codeless) | Limited (budget, early stopping, objective) | Image or tabular objectives, strong accuracy with minimal ML effort |
| Gemini / Model Garden (prompting or tuning) | Prompt design, evaluation | Moderate (prompts, tuning, grounding) | Language, vision, multimodal, and generative tasks |
| Agent Platform Serverless Training (custom training) | Build the training application | High (any framework, loss, architecture, machine type, container) | Custom models without managing infrastructure. Good for experiments and jobs that don't need guaranteed capacity |
| Managed Training Clusters | Build the training application | Highest (reserved accelerators, networking, storage) | Large, long-running, high-performance training that needs guaranteed capacity and fast job start |
| Ray on Agent Platform | Ray and Python | High (head and worker nodes, custom images, GPUs) | Distributed Python workloads spanning data processing, training, and tuning |
| Agent Platform Pipelines | Component packaging (KFP) | Orchestration layer on top of the above | Making any of these repeatable: data prep → train → evaluate → register → deploy |
Agent Platform Pipelines isn't a training algorithm. It orchestrates BigQuery ML, AutoML, custom training, and evaluation steps. Choose it when the requirement is repeatability, automation, lineage, or retraining, which is often the case once a prototype succeeds.
Decision sequence
- Can a pre-trained API or Gemini solve it? That's the least effort.
- Is the data structured and already in BigQuery, and does a standard model type fit? Use BigQuery ML.
- Is it an image or tabular objective, and the team wants the best accuracy with no code? Use AutoML.
- Does it need a custom architecture, loss, or framework? Use custom training (serverless first, or training clusters for large reserved-capacity jobs, or Ray for Ray-based code).
- Will it be retrained or promoted repeatedly? Wrap it in Agent Platform Pipelines.
Deployment Strategy
| Strategy | How predictions are delivered | Choose when | Google Cloud options |
|---|---|---|---|
| Batch inference | Score a large dataset on a schedule and write results | No real-time need: nightly propensity scores, weekly forecasts | Agent Platform Batch Inference (no endpoint needed), BigQuery ML ML.PREDICT, Gemini batch inference, Dataflow RunInference |
| Online inference | Synchronous request → response | User-facing apps, real-time decisions such as fraud checks | Agent Platform Endpoints (public, dedicated, or private), Cloud Run, GKE |
| Streaming inference | Score events continuously as they arrive | IoT alerts, clickstream personalization | Dataflow with RunInference or calls to an endpoint |
| In-database scoring | Predictions computed where data lives | Analysts consume results in SQL and BI | BigQuery ML (native or imported models, remote models) |
| Edge | Model runs on device | Offline or intermittent connectivity, ultra-low latency, data that must stay on device | AutoML Edge exports (TF Lite, Edge TPU, Core ML, TensorFlow.js), custom exported models |
| Hybrid | Precompute in batch, adjust online | Large catalogs with real-time context | Batch candidate generation plus online re-ranking |
Choosing between batch and online
- Freshness needed: if predictions can be up to a day old, batch is simpler and cheaper.
- Input availability: if key inputs only exist at request time (cart contents, current location), use online inference.
- Cost: online endpoints bill for provisioned replicas even when idle (unless scaled down), while batch jobs bill only while running.
- Volume pattern: very large volumes on a schedule strongly favor batch.
Cost Profile of Each Strategy
| Strategy | What you pay for | Cost trap |
|---|---|---|
| Batch inference | Compute while the job runs | Running batch jobs far more often than the business needs the scores |
| Online endpoint | Replicas (and accelerators) for as long as the model is deployed | Overprovisioned minimum replicas or idle GPU endpoints |
| BigQuery ML scoring | Query processing | Scoring full history every day instead of only new or changed rows |
| Gemini API | Tokens per request | Sending long, unchanged context on every call without caching |
| Edge | Device and app distribution effort | Shipping model updates too rarely, so edge models go stale |
Rollout Considerations Decided Up Front
- Versioning and rollback: register every model version (Chapter 13) so traffic can move back quickly.
- Safe rollout: plan a canary or A/B split on endpoints for online models.
- Monitoring: decide how you'll get ground truth and when drift monitoring starts (Chapter 19).
- Retraining triggers: schedule-based, performance-based, or drift-based (Chapter 17).
Worked Scenario
An insurer wants (a) a monthly customer-lapse score for its call-center campaign list, (b) instant fraud checks when a claim is submitted in the mobile app, and (c) photo damage assessment in rural areas with poor connectivity.
| Need | Product | Deployment strategy |
|---|---|---|
| Monthly lapse scores | BigQuery ML boosted tree | Batch: scheduled ML.PREDICT into a campaign table |
| Instant fraud check | Custom XGBoost via serverless custom training, orchestrated by Pipelines | Online: Agent Platform endpoint with autoscaling, canary rollouts |
| Damage photos offline | AutoML image classification (Edge model) | Edge: TF Lite model in the adjuster app, synced when connected |
Test Your Knowledge
A small analytics team with strong SQL skills and no Python experience needs weekly customer propensity scores from data already in BigQuery. Which product and deployment strategy fit best?
A
B
C
D
Test Your Knowledge
A research lab trains a 70-billion-parameter model for several weeks and can't afford to wait in accelerator queues between runs. Which Agent Platform training option fits best?
A
B
C
D
Test Your Knowledge
A retailer needs product recommendations shown on its website within 100 ms, but only the shopper's current cart is known at request time. Which deployment strategy fits?
A
B
C
D