Which should we choose?

The maker's service for most work, a cloud vendor's when it makes the purchase approvable inside an existing relationship, and your own machines when the material genuinely cannot leave or the volume is steady and heavy. Those three reasons cover most real decisions, and only the last is primarily about cost.

Does self-hosting mean better privacy?

It means the material stays on infrastructure you control, which answers one question decisively and creates others about who maintains, patches and secures it. Whether that is an improvement depends on how well you would do those things, which is worth an honest answer before it becomes the reason for the decision.

Does the cloud vendor have the same models?

Usually, and increasingly on the same day, because makers now launch across the major clouds simultaneously. What differs is the far end: each platform sets its own retirement schedule, so a model the maker has withdrawn can still be running on a cloud you use. Check the platform's own model table rather than the maker's.

Glossary

Model hosting

Model hosting is where a model actually runs: on the maker's own service, on a cloud vendor's infrastructure, or on machines you control.

In plain terms

A model has to run on hardware somewhere, and there are three broad answers to whose. The company that made it, a cloud provider offering it alongside everything else you rent from them, or your own machines. The model can be identical in all three and almost everything around it differs: what you pay for, what you are responsible for, and who can answer a question about where the data went.

Why it matters

Because the choice is usually made for reasons that have nothing to do with the model and everything to do with what an organisation can approve, support and answer questions about. A team comparing capabilities is comparing the part that stays the same across all three options, while the things a review will actually ask about, where the material is processed, what is retained and who is accountable when something goes wrong, change entirely with the host.

How it works

The maker's own service is the default and the simplest. You pay for what you use, they run the hardware, and new versions appear without you doing anything. What you give up is control over timing and location, and what you avoid is every operational concern, which for most organisations is the right trade for most work.

A cloud vendor's version of the same model sits between the extremes and is chosen for reasons that are rarely about the model. It brings the model inside an existing commercial relationship, an existing security review and an existing bill, which is frequently what makes it approvable when the direct route is not. Availability then follows that platform's schedule rather than the maker's: new models increasingly arrive everywhere at once, and older ones often outlast their retirement elsewhere.

Availability can also be interrupted for reasons that belong to neither the maker nor the platform. Where an export control, a licensing dispute or a regulator suspends a model, it goes from every surface at once, and a buyer who chose one cloud over another for resilience finds that the choice bought nothing against that particular event. It is worth knowing which risks the hosting decision actually addresses and which it leaves exactly where they were.

Your own machines mean the material never leaves, and the cost changes shape entirely. Instead of a meter there is hardware, electricity and somebody's attention, all of which are paid whether or not anybody is using it. That suits steady heavy use and suits occasional use badly, which is the single most reliable thing to say about the economics.

Utilisation is what decides between a meter and fixed costs, and it is the calculation most often done optimistically. Hardware sitting idle overnight and at weekends is still being paid for, so a comparison against a per-use rate has to be made against realistic occupancy rather than peak capacity. Where demand is spiky the meter usually wins by a wide margin.

Who runs it, and what moves with the choice

Drawing this as a spectrum matters because the debate is usually conducted as though there were two options and a principle at stake. In practice the middle mark is where a large number of organisations land, and they land there for a reason that has nothing to do with the model: the purchase fits inside a commercial relationship and a security review that already exist, which can be the difference between a tool being approvable this quarter and not at all. Reading the picture from right to left also corrects the commonest error in the conversation, which is treating the right-hand end as the cautious choice. It is the choice that transfers every operational responsibility to you, and it is only the safer option if you would discharge those responsibilities better than the alternative would.

Seen in the wild

Running an open-weight model on your own machine, where nothing leaves and the cost is equipment rather than usage.
Ollama
Loading and running models locally with a desktop application, which is the same arrangement without the command line.
LM Studio
Reaching hosted models from several providers through one interface, where hosting is somebody else's concern entirely.
OpenRouter

Common misconceptions

People assume

Self-hosting is cheaper.

In fact

It is cheaper per unit at high steady utilisation and more expensive at low or spiky utilisation, because the hardware is paid for while idle. The comparison has to use realistic occupancy rather than peak, and it has to include the attention of whoever keeps it running, which is the item most often left out.

People assume

The model is the same, so the choice is only commercial.

In fact

The weights may be identical and the surroundings are not. Version currency, region, retention, limits and who can answer a question about an incident all change with the host, and those are usually what a review is actually asking about.

Telling them apart

Model hosting vs Self-hosted

Model hosting

The whole question of where a model runs, including somebody else's infrastructure.

Self-hosted

One answer to it: your own.

Self-hosting is a point on this spectrum, not the opposite of it.

Questions

Which should we choose?: The maker's service for most work, a cloud vendor's when it makes the purchase approvable inside an existing relationship, and your own machines when the material genuinely cannot leave or the volume is steady and heavy. Those three reasons cover most real decisions, and only the last is primarily about cost.
Does self-hosting mean better privacy?: It means the material stays on infrastructure you control, which answers one question decisively and creates others about who maintains, patches and secures it. Whether that is an improvement depends on how well you would do those things, which is worth an honest answer before it becomes the reason for the decision.
Does the cloud vendor have the same models?: Usually, and increasingly on the same day, because makers now launch across the major clouds simultaneously. What differs is the far end: each platform sets its own retirement schedule, so a model the maker has withdrawn can still be running on a cloud you use. Check the platform's own model table rather than the maker's.

Key takeaways

Three answers: the maker's service, a cloud vendor's, or your own machines.
Utilisation decides between a meter and fixed costs; idle hardware is still paid for.
The model can be identical while everything around it differs.
A cloud vendor is often chosen to make the purchase approvable, not for the model.
Each platform sets its own model schedule, so check its table rather than the maker's.