You open the Google Cloud console, type a prompt into a Gemini model, and it answers in about a second. Behind that single call sits a catalog of more than 200 models and three completely different ways to run any of them. Pick the wrong one and you end up paying for idle accelerators, or shipping data out of a network you meant to keep sealed. This part is about that catalog, Model Garden, and the platform it lives in, Vertex AI, so the choice stops being an accident.

What Vertex AI actually is

Vertex AI is the single managed platform on Google Cloud for the whole model lifecycle: discover a model, test it, tune it, deploy it, and monitor it in production. Before Vertex, those steps lived in separate products and you stitched them together yourself. Now they share one API surface, one set of IAM permissions, one billing view. For generative AI specifically, Vertex gives you access to Gemini and the rest of the catalog, plus the plumbing around them, retrieval, grounding, evaluation, and tuning, that later parts cover one at a time.

One naming note, because it will confuse you otherwise. At Google Cloud Next in April 2026, Google began presenting much of this surface under the name Gemini Enterprise Agent Platform, with an agent-first framing on top of the same Vertex AI capabilities. The APIs, the SDK, and the resource names you will type are still Vertex AI. I use Vertex AI throughout this series because that is what the docs and the gcloud commands still say. If you see the newer name in the console, it is the same platform underneath.

How Model Garden groups its models

Model Garden is the catalog inside Vertex AI: a single searchable library of over 200 models with a card for each one. A model card tells you what the model does, how it is licensed, which access paths it supports, and lets you open it in a playground before you write a line of code. The models fall into three groups by who built them, and the group tends to decide how you will run it.

Gemini is Google’s family of multimodal models, meaning they take text, images, audio, video, and PDFs as input. Within the family, Flash is the smaller, cheaper, faster tier and Pro is the larger, higher-reasoning tier. Gemma is Google’s open-weight family you can download and run anywhere. The partner models matter more than people expect: Claude and others are first-class citizens in the catalog, billed on your Google Cloud invoice, so you are not forced onto Gemini to stay inside one contract and one security boundary. If you came from AWS, this is the same idea as the Bedrock model catalog, with a wider open-model bench.

Reading a model card before you commit

Every model in the catalog has a card, and the card is where you settle the questions that decide whether the model even fits, long before you write code. Four fields carry most of the weight. The license tells you whether you can use the model commercially and whether self-hosting needs a paid agreement through Marketplace; skip this and you can ship something you have no right to ship. The supported regions tell you where the model can actually run, which matters the moment you have a data-residency rule, because a model that only serves from one region is not an option in a locked-down project. The context window, the amount of text the model can read at once, decides whether your documents fit in a single call or need chunking, a topic Part 12 handles in detail. And the input types tell you whether the model is text-only or takes images, audio, and video too.

The card also carries a playground on most models, so you can paste a real prompt and see the answer before committing a line of code or a cent of engineering time. I use it as a fast filter. Take three candidate models, run five of your actual hard prompts through each playground, and two of the three usually fall out on quality or refusal behaviour before any integration work starts. That saves days. What the card cannot tell you is how the model behaves on your traffic at your volume, so treat the playground as a screen, not a verdict, and confirm the real numbers with an evaluation run later in the series. Read the card first. It is the cheapest step in the whole process.

Which access path should you pick?

This is the decision that actually costs money, so slow down here. Model-as-a-Service, MaaS, means Google runs the model for you on shared, serverless infrastructure and bills you per token. You provision nothing. Self-deploy means you stand the model up on a dedicated Vertex AI endpoint, a set of machines with accelerators attached that you rent by the hour, running inside your own project and VPC network. The first path is elastic and cheap at low volume. The second gives you fixed cost, fixed latency, and traffic that never leaves your network.

The break-even is about utilization, not preference. A serverless call bills only when it runs. A dedicated endpoint bills every hour it exists, whether or not a request arrives. So the honest question is: will the endpoint stay busy? If your traffic is bursty and your daily token count is low, MaaS wins and it is not close. Once you are pushing a model hard for most of the day, the per-hour rate on a self-deployed endpoint can undercut per-token pricing, and you get a latency floor you control.

Calling a Gemini model from the SDK

The managed path is the one you should reach for first, and it is a few lines. Install the Google Gen AI SDK, point the client at Vertex by passing vertexai=True with your project and region, then call generate_content. The same client shape works for partner MaaS models by swapping the model id, which is the point: one SDK, one auth path, many models.

# pip install google-genai
from google import genai

client = genai.Client(
    vertexai=True,
    project='my-gcp-project',
    location='us-central1',
)

resp = client.models.generate_content(
    model='gemini-2.5-flash',
    contents='Summarise VPC Service Controls in two sentences.',
)
print(resp.text)

Expected output is a two-sentence summary printed to your terminal, returned in roughly a second. The common failure on a fresh project is a 403 permission error, which almost always means the Vertex AI API is not enabled or your identity lacks the aiplatform.endpoints.predict permission. Enable the API, grant the Vertex AI User role, and rerun. A second frequent failure is a model id that does not exist in your chosen region; the error names the model, and the fix is to check the model card for regional availability.

Self-deploying an open model to your VPC

When a rule says the model must run inside your network, or when your load is heavy and steady enough to beat per-token pricing, you self-deploy. Model Garden has a one-click Deploy button on eligible cards, and the same action is available from the command line so you can put it in a pipeline. For open models the deploy is direct. For proprietary partner models you self-host, you first buy a commercial license through Google Cloud Marketplace, then deploy the same way. Either way the endpoint runs in your project, and it respects VPC Service Controls, so sensitive traffic stays inside the perimeter you already drew.

# Deploy an open model from Model Garden to a dedicated endpoint
gcloud ai model-garden models deploy 
    --model='google/gemma@gemma-3-27b-it' 
    --region='us-central1' 
    --project='my-gcp-project'

# Then call your own endpoint id, not a shared MaaS route.

Expected result is a new endpoint that reports as deploying, then ready after several minutes while machines and the accelerator come up. The failure mode that catches people is quota: a fresh project often has zero quota for the GPU or TPU type the model needs, and the deploy sits pending or fails outright. Check accelerator quota in the region before you deploy, and request an increase early because approval is not instant. The exact model reference format and supported machine types are on the model card, so read it rather than guessing the flags.

Start on MaaS, self-deploy only when a rule forces it

Here is the recommendation, not a shrug. Begin every generative project on the managed API or MaaS. It costs you nothing when idle, it answers in about a second, and it lets you compare Gemini against Claude and an open model with one SDK and one bill. Move a workload to a self-deployed endpoint only when a concrete reason pushes you there: a data-residency or in-VPC rule the serverless path cannot meet, sustained volume where the per-hour rate clearly beats per-token, or a latency floor you must own. Those are real reasons and they do occur. What is not a reason is a vague wish for control, because control here is paid for in node-hours and on-call time.

One more caution. Do not confuse Vertex AI Model Garden with the consumer Gemini API in Google AI Studio; they overlap in models but differ in billing, quotas, and enterprise controls, and Part 5 of this series draws that line in full. For now, pick your path on this project deliberately, then open the model card for the one Gemini tier you will start with and send the SDK snippet above. If it prints a summary, you have the managed path working, and everything later in the series builds on top of that call.

References

• Model Garden, Google Cloud
• Vertex AI managed models for MaaS, overview
• Self-deploy proprietary models in your VPC, Google Cloud blog
• Google Gen AI SDK, overview

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts