Cost Optimization Strategies in Vertex AI
The first bill shock I witnessed from Vertex AI came from a team running Workbench notebooks they had forgotten to stop over a long weekend. Four A100 GPU instances, 72 hours each, at roughly $3.67/hr per A100 — the unplanned bill was over $4,000. The model hadn't even trained yet. This is the reality of cloud ML platforms: costs are real-time, mistakes are expensive, and the platform's defaults are rarely optimized for frugality.
After auditing Vertex AI spending for several ML teams, I've identified a clear set of strategies that consistently cut costs by 40–70% without any degradation in throughput or model quality. Here they are, ranked by impact.
Strategy 1: Spot (Preemptible) VMs for Training
This is the single highest-impact cost optimization for most ML teams. Spot VMs on Google Cloud are spare capacity available at up to 91% discount compared to on-demand pricing. The trade-off: GCP can reclaim them with 30 seconds notice when capacity is needed elsewhere.
For ML training jobs, this trade-off is almost always acceptable because Vertex AI Custom Training has built-in checkpoint support. If a preemptible instance is reclaimed, the job resumes from the last checkpoint rather than from scratch.
from google.cloud import aiplatform
job = aiplatform.CustomTrainingJob(
display_name="fraud-detection-spot-training",
script_path="trainer/task.py",
container_uri="us-docker.pkg.dev/vertex-ai/training/pytorch-gpu.1-13:latest",
)
model = job.run(
machine_type="n1-standard-8",
accelerator_type="NVIDIA_TESLA_T4",
accelerator_count=1,
# KEY: Enable spot VMs for up to 91% cost reduction
base_output_dir="gs://my-bucket/training-output/",
replica_count=1,
boot_disk_type="pd-ssd",
boot_disk_size_gb=100,
# Preemptible configuration
scheduling={"timeout": "86400s"}, # 24hr max, checkpoint frequently!
# Use Reduction Server for multi-GPU: saves inter-GPU communication costs
)
# On A100 80GB:
# On-demand: $3.67/hr
# Spot: $0.33/hr -- 91% cheaper for identical hardware!
Checkpoint Frequently
With preemptible VMs, checkpoint every 15–30 minutes in your training loop. If preemption happens, you lose at most 30 minutes of compute. Use tf.train.CheckpointManager or PyTorch Lightning's built-in checkpointing. Store checkpoints to a GCS bucket — not local disk, which disappears on preemption.
Strategy 2: Endpoint Auto-Scaling to Zero
The default min_replica_count=1 on a Vertex AI Endpoint means you're paying for one machine 24/7, even at 3am when traffic is zero. For development and staging endpoints, setting min_replica_count=0 enables scale-to-zero — the endpoint shuts down entirely when idle and spins up fresh instances on demand.
# Development / Staging Endpoint: Scale to Zero
model.deploy(
endpoint=dev_endpoint,
machine_type="n1-standard-2",
min_replica_count=0, # Scale to zero when idle (NO idle cost!)
max_replica_count=3, # Burst up to 3 instances under load
traffic_percentage=100,
)
# Production Endpoint: Keep warm replicas
model.deploy(
endpoint=prod_endpoint,
machine_type="n1-standard-4",
min_replica_count=2, # Always-warm for low latency
max_replica_count=20, # Heavy burst capacity
traffic_percentage=100,
)
# Cost comparison for an n1-standard-4 instance:
# min=1: $0.19/hr * 24 * 30 = $136.80/month at 0% utilization
# min=0: $0/month at 0% utilization, $0.19/hr only when requests arrive
The trade-off is cold start latency: a scale-from-zero endpoint takes 60–120 seconds to provision a new instance. For development endpoints where occasional latency is acceptable, this pays for itself immediately.
Strategy 3: Right-Sizing Machine Types
A surprisingly common mistake: teams default to n1-standard-8 or n1-standard-16 for serving endpoints because those were the machine types used during training. Inference workloads frequently use radically less memory and compute than training.
Run a load test with realistic traffic, then check Cloud Monitoring for your endpoint's actual CPU and memory utilization. If it's consistently under 30% on n1-standard-4, drop to n1-standard-2. The cost difference compounds significantly at scale.
| Machine Type | vCPUs | RAM (GB) | $/hr | $/month (1 instance) |
|---|---|---|---|---|
| n1-standard-2 | 2 | 7.5 | $0.095 | $68 |
| n1-standard-4 | 4 | 15 | $0.190 | $137 |
| n1-standard-8 | 8 | 30 | $0.380 | $274 |
| n1-standard-16 | 16 | 60 | $0.760 | $547 |
Strategy 4: Commit to Sustained Use and CUDs
Google Cloud offers two commitment-based discounts:
- Sustained Use Discounts (SUDs): Automatic discounts applied when you use a VM for more than 25% of a month. At 100% usage, you get roughly 30% off the on-demand price with zero commitment.
- Committed Use Discounts (CUDs): 1-year or 3-year upfront commitments for specific machine families. 1-year CUDs provide about 37% discount; 3-year CUDs about 55%.
# Pricing math for a production Vertex AI endpoint
# n1-standard-4, min 2 replicas, running 24/7
# Without discounts
hourly_cost = 0.190 * 2 # $0.38/hr for 2 replicas
monthly_base = 0.38 * 24 * 30 # $273.60/month
# With Sustained Use Discount (automatic at 100% usage)
monthly_sud = monthly_base * 0.70 # ~30% discount = $191.52/month
# With 1-year CUD
monthly_cud = monthly_base * 0.63 # ~37% discount = $172.37/month
# With 3-year CUD
monthly_3yr = monthly_base * 0.45 # ~55% discount = $123.12/month
# Annual savings (3-yr CUD vs. on-demand):
annual_savings = (monthly_base - monthly_3yr) * 12
print("Annual savings with 3-yr CUD: ~$1,806/yr per endpoint")
Strategy 5: Gemini Token Optimization
For Gemini API calls through Vertex AI, you pay per token. Input tokens cost differently from output tokens, and the model tier determines the base rate. These four practices consistently reduce token costs by 30–50%:
# 1. Use context caching for long static prompts (Gemini 1.5+ feature)
from vertexai.preview.generative_models import GenerativeModel, CachedContent
import datetime
# Cache a long system prompt / knowledge base that doesn't change often
cached_content = CachedContent.create(
model_name="gemini-1.5-pro-002",
system_instruction="Your very long static knowledge base here...",
contents=your_static_document_list,
ttl=datetime.timedelta(hours=24), # Cache for 24 hours
)
# Subsequent requests hit the cache -- input tokens are cheaper!
model = GenerativeModel.from_cached_content(cached_content=cached_content)
response = model.generate_content("Question about the document...")
# 2. Right-size model: Use gemini-2.0-flash for simple tasks
# gemini-2.0-flash: ~10x cheaper than gemini-2.0-pro
# For classification, extraction, summarization: flash is sufficient
# 3. Set max_output_tokens to realistic ceilings
config = GenerationConfig(max_output_tokens=256) # Not 8192 for a one-line answer!
# 4. Use batch prediction for offline workloads (no per-request overhead)
batch_job = aiplatform.BatchPredictionJob.create(
job_display_name="overnight-batch-extraction",
model_name="gemini-1.5-flash",
instances_format="jsonl",
gcs_source="gs://my-bucket/input-requests.jsonl",
gcs_destination_prefix="gs://my-bucket/output/",
# Batch jobs get ~50% discount vs real-time endpoints
)
Strategy 6: Stop Workbench Notebooks When Not in Use
This sounds obvious, but it's the source of the largest unplanned bills I've seen. Workbench instances with attached GPUs charge even when idle. Set up an idle shutdown policy — Vertex AI Workbench supports automatic idle shutdown after a configurable duration:
# Create Workbench instance with idle shutdown gcloud workbench instances create my-notebook --project=my-project --location=us-central1-a --machine-type=n1-standard-4 --accelerator-type=NVIDIA_TESLA_T4 --accelerator-core-count=1 --idle-shutdown=true --idle-shutdown-timeout=60 # Auto-stop after 60 minutes of kernel idle # Or enforce team-wide via Organization Policy # Prevent users from creating notebooks without idle shutdown
Conclusion: The Optimization Checklist
Apply these six strategies systematically to reduce Vertex AI spending without workflow disruption:
- Enable Spot VMs for all training jobs with checkpoint frequencies ≤30 min
- Set
min_replica_count=0on dev/staging endpoints - Profile inference endpoint CPU/memory and right-size machine types
- Purchase CUDs for long-running production serving infrastructure
- Use Gemini Flash for classification/extraction tasks, Pro only for reasoning
- Enforce idle shutdown on all Workbench instances via org policy