Vertex AI Model Garden has long been Google Cloud’s catalog for discovering and using Google, partner, and open models. In April 2026 Google renamed the wider generative-AI platform to Gemini Enterprise Agent Platform, and the current name is simply Model Garden on that platform. The older “Vertex AI Model Garden” term remains important because documentation, training material, search demand, and existing implementations still use it. Architects should understand the product by capability rather than by whichever name appears in an older diagram.
Within the AI on Google Cloud stack, Model Garden is the model-discovery and access layer, not a single deployment pattern. Candidates for the Generative AI Leader exam should be able to distinguish a Google-managed Gemini endpoint, a partner or open model exposed through Model as a Service, and a model that must be self-deployed onto Vertex/Agent Platform infrastructure. Those choices change pricing, scaling, lifecycle ownership, network design, and the amount of operational work the customer inherits.
Start with the model card, not the leaderboard
A Model Garden entry is useful because it describes more than a model name. The model card can expose the provider, supported modalities, serving options, regions, context limits, licensing or terms, and links to tuning or deployment workflows. That information is part of architecture. A model that wins a benchmark but cannot run in the required region, cannot meet the organization’s data requirements, or requires hardware the team cannot operate is not the best model for that workload.
This is why foundation model selection and routing should begin with the task and constraints. Accuracy, latency, context size, price, explainability, provider risk, and operational maturity all matter. Model Garden shortens discovery, but it does not remove the need for evaluation. Teams still need a representative test set and release criteria that reflect the application they are actually building.
Managed APIs and self-deployment transfer different responsibilities
Model as a Service provides serverless access to selected partner and open models. The platform handles the serving infrastructure, so the application team can call the model without provisioning accelerators or maintaining a serving stack. This is attractive for teams that want a familiar API surface, rapid experimentation, and consumption-based scaling. The trade-off is that the available model version, region, quotas, and commercial terms are defined by the service offering.
Self-deployed models move more control to the customer. Selected partner and open models can be deployed into the customer’s Google Cloud project, where the team chooses serving infrastructure and accepts more responsibility for capacity, endpoint configuration, upgrades, and cost. The operational considerations overlap with model serving for LLM applications: accelerator utilization, concurrency, cold starts, autoscaling behavior, request shape, and observability can dominate the real production experience even when model quality is excellent.
Availability is version-specific and changes over time
Model Garden is a living catalog. Models are added, promoted, deprecated, and retired. Google’s 2026 release notes show continuing changes across Gemini, Gemma, Anthropic, Mistral, GLM, and other offerings. An architecture therefore should never encode “Model Garden has model X” as a permanent fact. The durable statement is that Model Garden is the discovery surface and that each model version has a lifecycle that must be checked before production use.
Lifecycle management needs an owner. A team should know which applications call which model IDs, what the fallback or migration target is, and how a model change is validated. The same release discipline applies to prompts and retrieval configuration. Generative AI deployment and monitoring becomes much easier when the model version is an explicit deployment artifact rather than a console choice that nobody records.
Deployment style should follow workload economics
Serverless model access is usually attractive when demand is variable or when a team wants to avoid carrying idle accelerator capacity. Dedicated or self-deployed serving can become attractive when traffic is sustained, latency must be tightly controlled, a particular open model is required, or the organization needs more control over the runtime. The cheapest option on a price sheet may not be the cheapest option after utilization, engineering effort, support, and operational risk are included.
Infrastructure choice also affects failure modes. A managed API shifts scaling and hardware failure handling toward the provider, but quotas and service availability still matter. A self-deployed endpoint gives the customer more direct control, but now capacity shortages, model-server configuration, image maintenance, and accelerator placement become the customer’s problem. The decision resembles the broader Compute Engine, GKE, or Cloud Run operating-model choice: choose the layer of control the team is prepared to operate, not the one that looks most flexible on a diagram.
Open models add licensing and supply-chain questions
Open-weight models can increase portability and customization, but “open” is not a complete risk description. The organization still needs to review the model license, provider terms, permitted uses, provenance, security posture, and the trustworthiness of any container or dependency used for serving. A model can be technically deployable and still be inappropriate for a regulated or commercial use because the surrounding obligations do not match the project.
Model customization adds another layer. Fine-tuning, adapters, quantization, or a custom serving container can improve fit and cost, but they create artifacts that need versioning and validation. The resulting endpoint is no longer simply “the model from Model Garden.” It is the organization’s configured derivative and should be tracked like any other production release. That includes the training data or tuning set, base-model version, container image, inference parameters, and rollback path.
Model selection and embedding selection are separate decisions
Generative applications often use more than one model family. The model that generates the final answer may not be the model that creates embeddings, reranks documents, moderates content, or classifies a request. Model Garden can expose several of those capabilities, but architecture should avoid turning “pick one best model” into a global decision that every stage inherits.
Retrieval systems are a clear example. The embedding model controls how content is represented for similarity search, while the generation model interprets retrieved evidence. The considerations in embedding model selection therefore remain distinct from generation quality. Changing the generator may be easy; changing the embedding model can require rebuilding an index and re-evaluating retrieval quality across the corpus.
Access control should follow the model and the action
Model Garden simplifies discovery, but production access should still be constrained through project structure, IAM, service accounts, quotas, and approved deployment workflows. A developer being able to see a model card should not automatically mean every production application can invoke that model. Teams should explicitly authorize providers and model versions that meet legal, security, and budget requirements.
The Google Cloud ecosystem gives organizations several ways to isolate projects and service identities. Use those controls to separate experimentation from production. A sandbox can allow broad model evaluation, while a production project can restrict model access to reviewed versions and approved service accounts. This reduces the chance that a prototype quietly becomes a production dependency on a model that has not passed the organization’s evaluation or commercial review.
Evaluation should decide promotion, not familiarity
Teams naturally prefer models they already know, especially when a previous Gemini or partner model has worked well. That familiarity is useful but can become inertia. Model Garden lowers the cost of comparing alternatives, so an organization can periodically test whether another model offers better accuracy, latency, cost, or modality support for the same workload. The comparison should use stable datasets and metrics rather than a handful of memorable prompts.
Promotion should be treated like a software release. Record the candidate model ID, run offline evaluation, test safety and tool behavior, measure latency and cost under representative load, then introduce the model through a controlled deployment. If the application uses routing across multiple models, validate the router as part of the system rather than evaluating each model in isolation. Model Garden makes options visible; engineering discipline determines which option deserves production traffic.
A shortlist should therefore be tested against the application’s real workload before a model is promoted. The evaluation set should include ordinary requests, difficult edge cases, long-context examples, multilingual or domain-specific inputs where relevant, and the failure modes the team is least willing to accept. Quality should be read together with latency, token consumption, throughput limits, tool-use behavior, and operational constraints. A model that leads a public benchmark can still be the wrong production choice if it is slow on the application’s request shape or creates a materially harder security and deployment posture.
The same evaluation should be repeatable when a new model version appears. Keeping prompts, test cases, scoring rules, and acceptance thresholds under change control turns Model Garden exploration into a governed selection process rather than a one-time demo. That matters because model choice is not permanent: the best option can change as versions, prices, regions, quotas, and application requirements change.
Use Model Garden as a catalog with lifecycle discipline
The main value of Model Garden is not that it contains a large number of models. It is that it gives Google Cloud teams a structured place to discover models, understand supported serving paths, and move from evaluation toward deployment. The current catalog spans Google models, partner offerings, open models, managed API options, and self-deployment paths, and that breadth is useful only when the team can compare them against explicit requirements.
A sound architecture therefore connects Model Garden to an operating process: approved providers, evaluation datasets, deployment patterns, identity boundaries, cost controls, lifecycle monitoring, and migration plans. That turns model choice from a one-time preference into a managed dependency. The catalog will keep changing; the organization’s method for selecting and governing models should be designed to survive those changes.
