Google CloudProfessional Agentic Architect2026-093.1 Designing and building agentic workflows in code
Evaluate model sourcing options
Completed by the knowledge check
Learning objective
Evaluate model sourcing across self-hosted versus software as a service (SaaS) and open-source software (OSS) versus proprietary options. This lesson focuses on where a model runs and what rights come with it, not on choosing a model size.
Core idea
Treat model sourcing as two independent decisions:
- Hosting axis: Who owns the inference-serving operational responsibility?
- Rights axis: What artifacts and legal rights does the model license provide?
The axes create four valid combinations:
| Rights model | Managed API (SaaS or MaaS) | Self-hosted |
|---|---|---|
| Open source or open weight | A provider serves the model; you consume its API | You deploy the available artifacts under their license |
| Proprietary | A provider serves a model whose internals and rights remain controlled | You deploy under a commercial license, which might still prohibit weight export |
For example, Google Cloud offers open models through a managed Model as a Service (MaaS) API and through self-deployment. It also supports self-deployed proprietary partner models. See Model Garden serving options and its self-deployed model overview.
Do not use one axis as a shortcut for the other. Self-hosted does not mean open source, and SaaS does not mean proprietary.
How it works
Self-hosted means that your organization controls and is accountable for the serving deployment, whether it runs on-premises or in your cloud project. A cloud provider can still manage parts of the underlying platform. You choose more of the compute, serving runtime, scaling policy, network path, and model version. You also own more work: capacity planning, accelerator utilization, patching, model loading, monitoring, failover, and incident response.
SaaS or MaaS means that a provider operates the endpoint and exposes an API. For example, Vertex AI MaaS provides serverless access without requiring the customer to provision or manage inference infrastructure. This can shorten time to production and handle variable demand, but the provider controls the service lifecycle, supported locations, quotas, interfaces, and available model versions. See Open model serving options.
Open source AI is more demanding than access to weights. The Open Source Initiative (OSI) definition requires freedoms to use, study, modify, and share, plus access to the preferred form for modification. For machine learning, that form includes model parameters, relevant code, and sufficient training-data information. Open weight only means that learned parameters are available; training code and data details might not be. See the Open Source AI Definition 1.0.
Proprietary models are governed by vendor-controlled terms and may expose only an API, or they may be licensed for self-deployment. Therefore, inspect the license rather than relying on labels such as open, community, or free. Check commercial use, redistribution, derivative-model, hosted-service, acceptable-use, attribution, and termination terms. The Gemma Terms of Use, for example, define hosted distribution and impose redistribution notices and use restrictions.
Key distinctions and trade-offs
| Criterion | SaaS or MaaS tendency | Self-hosted tendency |
|---|---|---|
| Data and control | Verify retention, training use, logging, regions, and subprocessors in service terms | Control the network and data path; still secure logs, storage, administrators, and dependencies |
| Operations | Provider manages serving infrastructure and much of scaling | Team manages runtime, accelerators, scaling, upgrades, availability, and observability |
| Economics | Consumption pricing often fits low, bursty, or uncertain traffic | Infrastructure and operations can fit steady, well-utilized demand |
| Portability | API integration is easy, but model behavior and lifecycle remain provider-dependent | Exportable weights and portable runtimes can improve exit options; proprietary weights may still be non-exportable |
| Security and compliance | Inherit provider controls, but verify them for the exact model, feature, and region | Gain deployment control while accepting more security and audit responsibility |
Compare total cost per successful task, not only token price or accelerator price. Include licenses, idle capacity, engineering, monitoring, upgrades, retries, and availability. The economic break-even point depends on actual traffic and utilization; it is not a universal request-volume threshold.
Data privacy also depends on the exact service contract. For example, Google states that it does not use Vertex AI customer data to train or fine-tune models without permission, but its documentation also lists retention scenarios such as abuse monitoring and caching. See Vertex AI and zero data retention. Likewise, supported controls such as data residency, customer-managed encryption keys, VPC Service Controls, and Access Transparency vary by feature. Verify the current matrix in Security controls for generative AI.
Finally, sourcing does not determine model quality. Evaluate the exact model, version, prompt, tools, and serving configuration on workload-specific cases. Google Cloud recommends translating business goals into quality and performance metrics and evaluating workload-specific latency, volume, connectivity, skills, and economics in its AI and ML performance guidance.
Architecture / decision scenario
A regulated claims agent processes personal data in one approved region. Two candidates pass the same task-quality and latency evaluation: a proprietary managed API and an open-weight model on a self-hosted endpoint.
The managed API contract supports the required region, retention policy, access controls, and audit evidence. Traffic is bursty and the team has no inference operations staff. The architect chooses the managed API because it satisfies the hard compliance constraints and reduces operational load. Where the service supports explicit model versions, the team selects one. It keeps an evaluation suite for upgrades and isolates the provider-specific API behind an internal model adapter.
If the contract did not meet the data boundary, or if the agent had to run disconnected, SaaS would be eliminated before cost comparison. Self-hosting the open-weight model would then be justified only after legal review of its actual license and confirmation that the team can meet availability and security requirements.
Common exam traps
- Treating self-hosted and open source as synonyms.
- Calling a model OSS merely because its weights can be downloaded.
- Assuming self-hosting automatically makes data secure or compliant.
- Assuming an enterprise SaaS API uses prompts for training without checking its contract, retention exceptions, and controls.
- Comparing token price with accelerator price while ignoring utilization and operational labor.
- Choosing by a public benchmark instead of an application-specific evaluation.
- Assuming an API wrapper guarantees portability between models with different behavior, limits, and tool-use semantics.
What to remember
- Separate the hosting decision from the rights and licensing decision.
- Apply hard legal, data-boundary, and connectivity constraints before cost optimization.
- Compare total cost, operational responsibility, and exit options.
- Treat open weight as distinct from OSI-defined open source AI.
- Evaluate quality and performance on the exact workload and configuration.
Knowledge check
A vendor offers an open-weight model through a managed inference API. The team wants to classify its operational responsibility before comparing costs. Which classification is correct?
Two serving options meet quality and data controls. Demand is bursty and the team has no inference-operations staff. Which consideration favors a managed API?
A self-hosted proposal compares accelerator cost with API token charges but excludes idle capacity, upgrades, and on-call labor. What comparison is needed?
References
- Google Cloud, Open model serving options
- Google Cloud, Overview of self-deployed models
- Google Cloud, Vertex AI and zero data retention
- Google Cloud, Security controls for generative AI
- Google Cloud Architecture Center, AI and ML performance optimization
- Open Source Initiative, Open Source AI Definition 1.0
- Google AI for Developers, Gemma Terms of Use