Self-hosted AI versus a cloud subscription: what the total cost comparison actually includes

A council or regulated SME comparing a cloud AI subscription against running an open-weight model on its own hardware will usually start by comparing two numbers: the subscription's monthly fee, and the hardware's purchase price. That comparison is not measuring the same thing on both sides, and it is the single most common mistake in this kind of procurement decision.

What a cloud subscription's price actually includes

A cloud AI subscription's fee is close to a genuine total cost, because the vendor has bundled almost everything into it: the compute itself, the electricity to run it, the hardware's depreciation and eventual replacement, security patching, model updates, and a support line when something breaks. This is exactly what a subscription model is for, and it is a real and legitimate reason organisations choose it. The comparison only goes wrong when this bundled, near-total price gets compared against the other side's unbundled, partial price.

What "free" open-weight software does not include

An open-weight model's licence typically costs nothing. That is where the "free" framing usually stops being accurate for an organisational deployment, as distinct from an individual trying a small model on a personal laptop.

• Hardware. Running a genuinely useful model at organisational scale, for more than one person at a time, generally needs purpose-bought or leased server-grade hardware, a real capital or ongoing lease cost that a subscription's monthly fee already absorbs on the other side of the comparison.
• Electricity. Hardware running continuously has a real, ongoing power cost. It is rarely large enough to change a decision on its own, but it belongs in the total, not left out because it doesn't arrive as a separate line item the way a subscription invoice does.
• Staff time. Someone has to maintain the deployment: apply security patches, update the model when a better one is released, monitor for problems, and fix things when they break. This is the cost most often left out of a first-pass comparison, and it is frequently the largest one, because it is a recurring cost of skilled time rather than a one-off purchase.
• The absence of a support line. When a cloud vendor's service has a problem, there is usually a support contract to call. A self-hosted deployment's support is whatever the organisation has built or bought separately, which is either a real cost (paying a systems integrator) or a real risk (having no support at all).

None of this means self-hosting is a bad choice. It means the comparison has to put a number, even a rough one, against every item on both sides before concluding which one actually costs less for a specific organisation's actual usage pattern.

Where the two paths cross over

The crossover point between "cloud is cheaper" and "self-hosted is cheaper" is almost always about usage volume, not about either option being intrinsically better. A cloud subscription's per-request or per-token pricing scales with usage: light, occasional use stays cheap, and heavy, constant use can become expensive quickly. A self-hosted deployment's biggest costs, the hardware and the staff time, are largely fixed regardless of how much the model is actually used once it's running. That means the same two options can have completely different relative costs depending purely on how heavily an organisation actually uses AI, which is exactly the number worth estimating honestly before comparing anything else.

There is a middle path worth naming plainly: paying a specialist vendor to support a self-hosted deployment. This adds a support cost back onto the self-hosted side of the comparison, but it can still leave data and compute under the organisation's own control, which is the actual reason many regulated organisations consider self-hosting in the first place, rather than cost alone. Our piece on digital sovereignty's economics covers that control-versus-cost trade-off in more general terms.

A short list of what to actually estimate

Before comparing a cloud subscription's quote against a self-hosted option, a fair comparison needs a rough number for each of these, on both sides:

• Expected usage volume over a realistic time horizon, since this decides which side of the crossover point an organisation actually sits on.
• Hardware capital or lease cost, sized to that actual usage, not to a worst-case peak that rarely occurs.
• The realistic staff time required to maintain a self-hosted deployment, priced at what that time actually costs the organisation, not treated as free because it doesn't generate a separate invoice.
• What happens if usage grows significantly: does the cloud subscription's cost grow linearly, in steps, or does the self-hosted hardware need replacing sooner than planned.
• The cost, in time and disruption, of switching away from whichever option is chosen, if it turns out to be the wrong one in two years.

A procurement decision made on the sticker price alone, in either direction, is not actually comparing costs. It is comparing which side happened to bundle more of the real cost into a number that's easy to see.

Disclosure

Common Fortune is a Mickai publication. Mickai builds AI systems designed to run on an organisation's own hardware, a self-hosted approach, and sells AI-readiness advice at mickai.co.uk/ai-readiness. Naming this here is a disclosure, not a claim of neutrality; the cost categories set out above apply regardless of which vendor or approach an organisation ultimately chooses. Trust Agent, under the same ownership, offers free courses including one on running open-weight models on your own hardware.