Optionality and Control Across AI Model Consumption Stages
- Amazon Bedrock, Microsoft Foundry, and Google Vertex AI each provide platform-native supervised fine-tuning for selected models, so tuning is available before any self-hosting stepAmazon (n.d.)Microsoft (n.d.)Google (n.d.)
- Tuned models stay inside platform serving constraints: Bedrock requires purchased Provisioned Throughput for customised models and Vertex deploys tuned Gemini models only to shared public endpointsAmazon (n.d.)Google (n.d.)
- Each platform documents a path for externally trained weights, through Bedrock Custom Model Import, the Foundry Fireworks integration, and Vertex custom weights in Preview, but regions and data terms differ, including a Foundry exclusion from EU Data Boundary commitmentsAmazon (n.d.)Microsoft (n.d.)Microsoft (n.d.)Google (n.d.)
- Imported-weight serving is best classed as managed-platform use with self-hosted-style weight control, and stages stack because one interface can address both catalogue and customer-owned modelsAmazon (n.d.)Github (n.d.)
- Trusting dynamic routing requires a workload-specific evaluation set, a human-validated judge, and calibrated thresholds, because public-benchmark savings and judge agreement above 80 percent come with documented biasesZheng et al. (2023)LMSYS (n.d.)Zou (2023)
- Retrieval and prompting should precede tuning for policy question answering and compliance checking, because two independent studies find retrieval beats fine-tuning for knowledge injectionOvadia et al. (2023)Soudani et al. (2024)
- Self-hosting break-even is set by cost per token at the margin, so halving assumed GPU throughput in an illustrative case moves break-even from near 14 billion to roughly 100 billion tokens per month, using invented inputsPan et al. (2025)Holtmann (2026)
- Independent cost evidence ranges from months to about five years to break even, and the optimistic consumer-GPU result excludes staff and redundancy, so no single threshold transfers between organisationsPan et al. (2025)Holtmann (2026)
Research Question
When an organisation progresses from Artificial Intelligence (AI) capabilities embedded in vendor subscriptions, through managed model platforms, to self-hosting model weights on infrastructure it controls, how do model choice, per-request selection, and operational and data controls change? Which capabilities become available at each stage, and does model tuning begin on managed platforms or require self-hosting?
Findings
(Populated from §6 Synthesis above.)
Executive Summary
Model tuning begins on managed platforms, not at self-hosting, because Amazon Bedrock, Microsoft Foundry, and Google Vertex AI each offer native fine-tuning, and self-hosting adds ownership of the weights and serving path rather than the ability to tune. The stages stack rather than replace one another, since imported weights can be served beside catalogue models through one interface and routing can bridge them. Self-hosting break-even is dominated by assumed throughput, utilisation, and price, with published estimates ranging from months to years. For banks and other financial entities, exit planning and model-risk validation apply to vendor services at every stage, and extraterritorial-access law raises the control needed over data paths, without mandating self-hosting. The primary uncertainty is that no named regulated organisation's self-hosting decision was verified.
Key Findings
- Amazon Bedrock, Microsoft Foundry, and Google Vertex AI each provide platform-native supervised fine-tuning for selected models, so tuning is available before any self-hosting step.
- Tuned models stay inside platform serving constraints: Bedrock requires purchased Provisioned Throughput for customised models and Vertex deploys tuned Gemini models only to shared public endpoints.
- Each platform documents a path for externally trained weights, through Bedrock Custom Model Import, the Foundry Fireworks integration, and Vertex custom weights in Preview, but regions and data terms differ, including a Foundry exclusion from EU Data Boundary commitments.
- Imported-weight serving is best classed as managed-platform use with self-hosted-style weight control, and stages stack because one interface can address both catalogue and customer-owned models.
- Trusting dynamic routing requires a workload-specific evaluation set, a human-validated judge, and calibrated thresholds, because public-benchmark savings and judge agreement above 80 percent come with documented biases.
- Retrieval and prompting should precede tuning for policy question answering and compliance checking, because two independent studies find retrieval beats fine-tuning for knowledge injection.
- Self-hosting break-even is set by cost per token at the margin, so halving assumed GPU throughput in an illustrative case moves break-even from near 14 billion to roughly 100 billion tokens per month, using invented inputs.
- Independent cost evidence ranges from months to about five years to break even, and the optimistic consumer-GPU result excludes staff and redundancy, so no single threshold transfers between organisations.
- Hybrid placement of cheap agent roles on self-hosted models and hard roles on APIs lowered per-task cost by up to 12 times in one study, which suggests partial self-hosting can capture savings before full break-even.
- For banks and other financial entities in the EU, US, and UK, exit planning under the Digital Operational Resilience Act and vendor-model validation under SR 11-7 and SS1/23 apply to vendor services at every stage, so these duties raise lock-in cost without requiring self-hosting.
- Data location alone does not settle jurisdictional exposure, because 18 U.S.C. 2713 reaches provider-held data wherever it is stored, so sovereignty depends on who operates the infrastructure.
- Open-weight licence obligations such as attribution, an acceptable use policy, and a 700 million monthly-user clause travel with the weights across managed import and self-hosting, and bespoke licences do not meet the Open Source Initiative definition.
Assumptions
Classification and extraction workloads are assumed to depend on stable formats rather than injected facts. That assumption is reasonable because small-model arguments focus on repetitive, scoped subtasks, but no fetched study tests these workloads in regulated settings.
Break-even inputs of 2 dollars per million tokens, 4 dollars per GPU-hour, 3,000 tokens per second, 40 percent utilisation, and 15,000 dollars monthly operations cost are illustrative values only. They are chosen to show the formula's sensitivity and are not observed prices from any vendor.
Subscription-stage selection limits are assumed to match the ladder item's description, because no subscription product documentation was fetched. The ladder item is the only prior source in this repository that characterises that stage.
Analysis
Vendor documentation was weighted as definitive for what each platform offers on the retrieval date and as silent on future availability. Peer-reviewed or preprint cost studies were weighted above vendor total-cost-of-ownership blogs, which were excluded as non-independent. The layered organisation item frames adaptation as a spectrum from prompting and retrieval to fine-tuning, and the platform evidence places the early part of that spectrum on managed platforms. The rival view that regulated firms should self-host by default is weakened because exit planning and validation duties apply equally to vendor services. The rival view that managed platforms always suffice is weakened by the Fireworks data-sharing terms and the EU Data Boundary exclusion for imported weights on Foundry. Whether sovereignty or cost drives self-hosting for a given firm cannot be settled here, because this item verifies the law and not any firm's decision. Competing drivers include latency, the capability gap between open-weight and frontier models, operations-staff capacity, and vendor contract terms, and the evidence gathered covers cost, capability tuning paths, and contract exit duties but not latency or measured capability gaps.
Risks, Gaps, and Uncertainties
- No named regulated organisation's self-hosting rationale was verified, because primary BNP Paribas pages were not retrievable and searches found no named case.
- Independent production cost evidence is limited to preprints with benchmark or consumer-hardware settings, and the worked break-even uses assumed inputs.
- Platform features change quickly and some paths are Preview or classic-documentation only, so regional availability should be rechecked before design decisions.
- Only one open-weight licence was read, so licensing conclusions may not extend to Apache 2.0 or other terms.
- Legal readings are engineering interpretations and not legal advice, and UK data-protection law after the 2025 reforms was not analysed.
Open Questions
- Which named regulated organisations have disclosed self-hosting for residency or sovereignty reasons?
- How do tuned small models compare with retrieval on regulated classification and extraction tasks in controlled studies?
- How do Apache 2.0 and other open-weight licences differ from the Llama licence in obligations on derivatives?
sources
Starting points from prior repository research:
- How Do Enterprise Artificial Intelligence (AI) Maturity Frameworks Map onto the Large Language Model (LLM) Consumption Ladder? : prior work on consumption stages, routing, and self-hosting economics.
- Layered Organisation Large Language Model: Feasibility and Architecture of Organisation-Customised LLMs : prior work on organisation-customised models and adaptation.
- Amazon Web Services (AWS) Bedrock capabilities : starting point for managed-platform capability evidence.
Managed-platform documentation (retrieved 2026-10-18):
- Amazon Bedrock Custom Models and Fine-Tuning Documentation
- Amazon Bedrock Provisioned Throughput Documentation
- Amazon Bedrock Custom Model Import Documentation
- Amazon Bedrock Cross-Region Inference Documentation
- Microsoft Foundry Fine-Tuning Overview
- Microsoft Foundry Models Sold Directly by Azure
- Microsoft Foundry Deployment Types
- Microsoft Foundry Deployments Overview
- Microsoft Foundry Import Custom Models with Fireworks
- Microsoft Foundry Fireworks Models Enablement
- Google Vertex AI Tuning Introduction
- Google Vertex AI Gemini Supervised Tuning
- Google Vertex AI Choose an Endpoint Type
- Google Vertex AI Deploy Models with Custom Weights
- Google Vertex AI Use Open Models
Cost, routing, and adaptation evidence:
- Pan et al. (2025) Cost-Benefit Analysis of On-Premise LLM Deployment
- Knoop and Holtmann (2026) Consumer Blackwell GPU Inference Economics
- Jiang et al. (2026) AgentCARD Heterogeneous Agent Teams
- Skurikhin et al. (2026) Tokenomics of Small Language Model Ensembles
- Chen, Zaharia and Zou (2023) FrugalGPT
- Ong et al. (2024) RouteLLM
- LMSYS RouteLLM Repository
- Zheng et al. (2023) Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
- Ovadia et al. (2023) Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs
- Soudani et al. (2024) Fine Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge
- Belcak et al. (2025) Small Language Models are the Future of Agentic AI
Statutes, regulator guidance, and licences:
- United States Code (2018) 18 U.S.C. 2713 Required Preservation and Disclosure of Communications and Records
- European Union (2022) Regulation 2022/2554 Digital Operational Resilience Act
- European Union (2023) Regulation 2023/2854 Data Act
- European Union (2016) Regulation 2016/679 General Data Protection Regulation
- Court of Justice of the European Union (2020) Case C-311/18 Schrems II
- European Union (2024) Regulation 2024/1689 Artificial Intelligence Act
- Board of Governors of the Federal Reserve System and Office of the Comptroller of the Currency (2011) SR 11-7 Supervisory Guidance on Model Risk Management
- Prudential Regulation Authority (2023) SS1/23 Model Risk Management Principles for Banks
- Meta (2024) Llama 3.3 Community License Agreement
- Open Source Initiative (2024) The Open Source AI Definition 1.0