iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AI companies run models they own or control not simply because they expect them to be more capable than outside models. Control can help them protect sensitive data, tailor a system to a particular task, manage latency and serving costs, and reduce dependence on a provider. But “owning a model” covers several different choices, from fine-tuning open weights to training a foundation model from scratch. Each brings different costs and benefits, and for many companies a mix of owned and hosted systems is more practical than owning everything.
What does it mean for an AI company to run its own model?
It can mean several things, and they are not interchangeable. A company might train a foundation model, adapt an existing model with its own data, run open weights on infrastructure it controls, use a private hosted endpoint, or own the serving and evaluation software around a model supplied by someone else. The key question is which layer the company needs to control—not whether every part of its AI stack is proprietary.
The Information Commissioner’s Office (ICO) notes that very few organisations build AI systems entirely in-house. Third-party frameworks and code libraries remain common even when a company employs its own machine-learning engineers. “Owned,” then, often means meaningful control over a particular part of the system, not independence from every supplier.
Five levels of control
- Train a foundation model: Build and train a broadly capable model, including the underlying weights. This offers substantial control but entails the most demanding development and operating work.
- Fine-tune existing weights: Adapt an existing model using specialised examples or proprietary data. This can target a domain or workflow without requiring the company to create a foundation model from scratch.
- Self-host open weights: Run model weights on infrastructure the company operates or controls. This puts more of deployment and capacity management in the company’s hands, while leaving it responsible for the skills and infrastructure needed to serve the model.
- Use a private hosted endpoint: Access a model through a hosted service configured for private use. The service provider still operates the underlying infrastructure, so the company should establish exactly where data goes and what controls apply.
- Use a public API: Send requests to an external provider’s model through an API. This can provide access to capable models without the company operating its own model-serving infrastructure.
A company can combine these levels—for example, use an external model for general requests and run a specialised model itself for sensitive or latency-critical tasks. The useful distinction is not “owned versus not owned” in the abstract, but what data, model behaviour, serving capacity, and operational decisions the company can actually control.
Why do AI companies build or control models instead of relying only on APIs?
Control can matter when data governance, customisation, responsiveness, serving economics, or strategic independence is central to the product. These gains are conditional: owning or locally deploying a model does not automatically make it safer, faster, better, or cheaper.
Keep sensitive data and model behaviour within tighter boundaries
Fine-tuning and use of AI systems can involve sensitive prompts, examples, evaluation data, and logs. The National Telecommunications and Information Administration (NTIA) says that controlling a model can give organisations more control over sensitive fine-tuning data and system biases; it also notes that API access may raise latency and privacy concerns. With a deployment the organisation controls, it may have more say over where data is processed and stored and which internal teams can access it.
That is a control advantage, not a privacy guarantee. An organisation still needs to examine its own storage, logging, access, retention, and security practices, as well as any third-party services used to run the system. The ICO warns that AI training and testing data may be copied, shared, and stored across contexts, and that third-party dependencies remain common even when organisations have their own machine-learning staff. A locally deployed model can still depend on outside infrastructure, software, chips, or data partners.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Adapt performance to a particular task
A general-purpose model may not be the best fit for a specialised workflow. Fine-tuning or adapting open weights with proprietary examples can help target a particular application. The OECD reports that API-gated systems can limit visibility, control, and room to differentiate, while semi-open or open-weight models can be adapted using proprietary data for targeted applications.
The advantage may lie less in the base model than in the system around it: a company’s workflow, specialised data, evaluation methods, and feedback from users. Those can help it identify where a model fails and improve how the product handles a recurring task. They do not ensure that a custom system will outperform an external model; that needs to be tested against the actual use case.
Manage latency, capacity, and serving costs
Inference—the process of using a trained model to generate outputs—has its own infrastructure and economic trade-offs. McKinsey describes decisions about where inference runs as a matter of economics, latency, and data control, and frames large-scale inference as a challenge of serving intelligence economically. A company that operates its serving stack can make more decisions about capacity and how its model, software, hardware, memory, and network work together.
In a description of its Jalapeño serving effort, OpenAI said it provided greater control over how its models run and over serving economics. The broader point is that serving performance depends on more than model weights: software and hardware choices can affect throughput, latency, energy efficiency, and cost. That kind of optimisation is most relevant when a company serves enough requests, or has sufficiently specific performance needs, to justify the effort.
Reduce dependence on a single provider
Relying on one external model provider can leave a product exposed to changes in pricing, quotas, policies, availability, or supported models. A provider may also deprecate a model that a product depends on. Having an alternative model or serving path can give a company more options when those changes occur.
This does not remove supply-chain dependence. The Bank for International Settlements (BIS) maps dependencies across hardware, cloud, data, foundation models, and applications, and highlights concentration, scale economies, and strategic behaviour. A company that controls its model may still depend on a small set of chip suppliers, cloud platforms, software libraries, or data sources. The aim is often to improve bargaining power or resilience at an important layer, not to eliminate every dependency.
Is running a model in-house cheaper than using an API?
Not necessarily. An API spreads the cost of training and operating a model across customers and can spare a company the expense of infrastructure and specialised staff. Self-hosting may become attractive for a particular workload, but the comparison must include the full cost of operating it—not only the price of a GPU or the cost per API request.
What ownership can cost
Building and operating a model can involve compute, electricity, data preparation, security, specialised engineering, software, and ongoing operations. Frontier model development is especially resource-intensive. A 2024 Nature report said computing used to train models increased roughly 300,000 times over six years—about eightfold per year. The same report estimated that Nvidia had a 70–90% share of state-of-the-art AI chips and an 88% share of GPUs in the figures it reported.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteNature also cited one case estimating 51,686 kWh to train a model, 7,571 kWh to fine-tune it, and 1 × 10-4 kWh for inference. These figures illustrate how training, fine-tuning, and individual inferences can have very different energy requirements. They are case estimates, not universal or current cost estimates for every model. Actual costs depend on the model, workload, hardware, utilisation, and deployment.
When a self-hosted workload may make economic sense
Compare options using the workload the business actually expects to serve. Include the following rather than comparing an API’s quoted request cost with hardware purchase price alone:
- Volume and utilisation: How many requests will the system serve, and how consistently will the capacity be used? Underused infrastructure can make fixed costs difficult to justify.
- Model and data work: Account for training or fine-tuning, licensing where applicable, and the work needed to prepare and maintain data.
- Serving infrastructure: Include accelerators, power, networking, and the software used to deploy and monitor the model.
- People and operations: Budget for staff who can manage performance, security, reliability, upgrades, and incidents.
- API alternatives: Compare against the real hosted-model options and expected usage, including the value of rapid capability upgrades and avoiding infrastructure work.
There is no single request-volume threshold at which self-hosting becomes cheaper: the answer depends on the workload and the costs above. Companies should measure representative tasks, model usage, and operational requirements before committing to a deployment. For most downstream firms, the OECD says, relying on upstream providers through APIs, plug-ins, or hosted platforms is more common than building their own models.
Which deployment approach fits which need?
The options differ in what the organisation controls and what it must operate. The table describes typical trade-offs, not guarantees: a private endpoint’s protections, for example, depend on the provider’s actual configuration and terms.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Approach | Capability and task fit | Cost and operating burden | Control and customisation | Main exposure |
|---|---|---|---|---|
| Train a foundation model | Can be developed for broad or specialised needs | Highest fixed investment in compute, data, staff, and operations | Greatest control over training and model development | Capital intensity, specialised talent needs, and concentrated input markets |
| Fine-tune or self-host open weights | Can target a domain or workflow using adapted weights | Requires infrastructure and technical skills; less work than training a foundation model from scratch, but still substantial | More control over adaptation, deployment, and evaluation | Infrastructure and skills requirements; dependencies on external components remain |
| Private hosted endpoint | Uses a provider-operated model through a private service | Reduces the need to operate serving infrastructure directly | Some access or configuration may be available; verify what is controllable | Dependence on provider practices, service availability, and terms |
| Public API | Provides access to an upstream provider’s model | Avoids running model infrastructure and can offer rapid capability upgrades | Less visibility and control over the model itself | Provider pricing, quotas, policies, outages, and model changes |
For any option, compare the same requirements rather than treating deployment labels as a verdict. Assess task performance, total cost, latency and reliability, data handling, customisation and observability, and the ability to switch if a provider or model changes.
Capability and task fit
Ask whether the workload needs a broadly capable frontier model or a system tuned to a narrower task. A general model accessed through an API can be a sensible choice when broad capability and quick access matter more than control over its weights. A specialised system may justify adaptation when the task, data, or workflow gives the organisation a reason to tailor behaviour. The relevant evidence is performance on representative tasks, not the assumption that either “frontier” or “custom” is automatically better.
Latency and reliability
Network distance, batching, and available capacity can affect response time; uptime and control of capacity matter to reliability. A self-operated service can give the company more control over capacity planning, but it also makes the company responsible for operating that service. An external provider may reduce that burden while leaving the company dependent on the provider’s service and policies.
Privacy, governance, and observability
Map where prompts, fine-tuning data, logs, and model weights are stored, who can access them, and how they are handled. Also establish how much the team can inspect, evaluate, and debug model behaviour. A deployment described as private should not be assumed to answer those questions: the organisation needs to understand the actual service arrangement and its own controls.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Switching risk and concentration
Consider what happens if a model is deprecated, quotas tighten, pricing changes, or an outage interrupts service. A second model or deployment path may provide flexibility, but portability requires engineering and evaluation work: different models may not respond identically to the same workflow. Control over one layer can reduce one dependency while leaving others intact.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why don’t all AI companies train their own models?
The costs and complementary assets favour organisations with substantial scale. Training advanced models requires more than weights and an algorithm: compute, data, power, software, specialist engineers, security, and the capacity to operate the system all matter. Nature’s reported growth in training compute and chip-concentration estimates illustrate why frontier development is difficult to reproduce at smaller scale.
Rank #4
Those fixed costs can make it more rational for a downstream company to buy access from an upstream provider than to build a model itself. Hosted models can make new capabilities available without requiring the customer to fund training and run serving infrastructure. The trade-off is less control and potential exposure to provider decisions. The OECD’s account that most downstream firms rely on upstream providers reflects this division of labour; it does not mean that those firms have no reason to own data, evaluation, fine-tuning, or selected inference systems.
Nor does a company that builds a model operate independently. The ICO’s account of common third-party frameworks and libraries, along with BIS’s map of supply-chain concentration, underscores how many layers can remain external. “Our own model” can be a useful shorthand, but it should not obscure who supplies the chips, cloud, code, data, or distribution on which the service depends.
Is a mixed model strategy the practical middle ground?
Often, yes. A company can use hosted APIs for tasks where rapid access to broad capability matters, and reserve self-hosted or adapted models for workloads where data control, tailored behaviour, latency, or serving economics justify the additional work. This approach avoids treating ownership as an all-or-nothing choice.
A practical design begins by separating workloads according to their requirements. For each one, the company can decide whether an external model is adequate, whether fine-tuning is useful, and whether the data or service needs justify local deployment. It should also plan how a workload can continue if a provider changes a model, limits access, or experiences an outage.
Questions to settle before moving a workload
- Which data and decisions need tighter control, and what specific deployment control would address that need?
- Does the workload require behaviour that can be achieved through prompts and workflow design, or is model adaptation necessary?
- What are the measured latency, reliability, and serving requirements for representative use?
- Can the organisation staff and secure the infrastructure, and maintain it as models and software change?
- What alternative model or service would keep the product usable if the primary provider changes terms or availability?
For local inference, a consumer GPU can illustrate how a smaller model might be run outside a provider’s public API, but it is not a substitute for the compute clusters needed to train frontier models. The deployment should match the model and workload; a hardware purchase by itself does not establish privacy, reliability, or lower total cost.
Frequently Asked Questions
Can a company own a model without training one from scratch?
Yes. It can adapt existing weights, run open weights on infrastructure it controls, or own parts of the serving and evaluation stack while relying on external components. Those choices provide different degrees of control and do not make the organisation independent of suppliers.
Free tools Windows power users keep installed
One-click scans. No signup required.
Does fine-tuning guarantee better results than a general model?
No. Fine-tuning can target a domain or workflow, but whether it improves a product depends on the task and the quality of the adaptation. Compare candidate systems on representative examples and monitor the failures that matter in the real workflow.
Can an API provider train on my company’s prompts?
That depends on the provider, service, configuration, and governing terms; it cannot be answered for every API with a blanket yes or no. Check the applicable data-use, retention, and access terms for the specific endpoint, and separately review what the organisation stores in its own logs.
What happens if an API model is discontinued?
The application may need to move to another model or service, and that can require changes to prompts, integrations, and evaluation. Maintaining a tested fallback and checking provider deprecation notices can reduce the chance that a model change becomes an unplanned product outage.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
