The AI Cost Question Nobody Asks: Who Owns the Hardware?

Enterprise AI inference costs become forecastable only when the capacity is fixed and owned. Metered inference prices every unit of work, so the bill tracks adoption, and a spend forecast is really a forecast of how much people will use something you are trying to make habitual. Owning the hardware turns that variable operating cost into a capital decision made once, in exchange for the capacity planning, headroom and refresh cycle you now run yourself.

• Metered inference makes success expensive: the better adoption goes, the more you owe.
• A per-token budget is a behavioural projection, not a cost line finance can hold.
• Rationing is the usual outcome, and it quietly kills the rollout you paid to build.
• Owned hardware fixes capacity at purchase, so usage becomes a utilisation figure, not an invoice.
• The honest cost of ownership is planning, headroom, operations and refresh.

Why does metered inference make success more expensive?

Metered inference charges per unit of work. Every summary, every retrieval, every agent step carries a charge, so the invoice is a direct function of how much the organisation uses the capability. A pilot confined to volunteers costs what those volunteers use. The same deployment on every desk is the outcome you wanted and the number nobody modelled.

That inverts the relationship between value and cost finance teams are used to. Elsewhere, wider adoption spreads a fixed cost over more people. Here volume is the variable, so the reward for a successful rollout is a larger bill.

Why is your token spend so hard to forecast?

Finance can forecast a lease or a depreciation schedule because the quantity is fixed in advance. A token forecast asks how much language an entire workforce will generate through something whose whole purpose is to become habitual, and wants the answer before anyone has formed the habit.

Second-order effects widen the range. Retrieval pulls large context into every call, and agentic patterns turn one human request into a chain of internal calls, so the multiplier between what a person asks for and what the meter counts is neither fixed nor visible from outside.

What does rationing AI usage cost you that the invoice never shows?

Faced with that variance, programmes reach for hard caps, per-team quotas and features quietly switched off. People learn the capability is not really there for ordinary work, save it for the occasional important task, and drift back. The deployment stays paid for, but the behaviour change dies. The workflows that would have justified the investment are exactly the high-volume, low-glamour ones rationed first.

What changes if you own the inference hardware?

Owned hardware turns a variable operating cost into a capital decision made once. You buy a fixed amount of capacity, depreciate it over a known life, and the marginal cost of another query is power, cooling and operations time you were already funding. Usage stops being a line item and becomes a utilisation figure.

That is what makes adoption safe to encourage: when a heavy month does not alter the invoice, you can put the capability in front of every team and measure value instead of defending spend.

This is the premise of a sovereign intelligence operating system. In Mickai, a capable model runs on hardware you own, over loopback only, with no outbound path by default. The metering surface is removed by the architecture rather than negotiated down, because nothing leaves the machine. Seats grant or revoke studios individually, so you still control who consumes the capacity you own.

What do you take on by running inference on your own hardware?

The trade is threefold. Capacity planning comes first: you size for peak concurrent demand rather than average, which means headroom that sits idle outside those peaks. Under-size it and people queue; over-size it and you depreciate silicon nobody is using. Refresh is second, because accelerators improve and workloads change shape. Third is the operational surface: firmware, drivers, thermals, spares and the people who look after them.

The compensation is that all three are planning problems with known shapes and slow clocks. A capacity plan can be wrong and corrected at the next increment. A metered bill that jumps cannot be corrected retrospectively, only rationed.

How do you choose between metered inference and owned capacity?

Start with the shape of the demand curve rather than a comparison of unit rates. Spiky, unpredictable, low-volume workloads suit metering, because elasticity is what you are buying. Steady, high-volume, business-hours workloads with a growing user base are the worst fit for metering and the strongest case for owned capacity.

Then ask the question the cost conversation usually skips: where is this data allowed to live? If the workload touches material that cannot leave the estate, the metered option was never really on the table.

Finally, insist on evidence you can audit. Deterministic engines produce every number, so identical inputs give identical results, and every consequential action is sealed into the Open Audit Record, an append-only, hash-chained log signed with FIPS 204 ML-DSA. The record is tamper-evident, which means interference is detectable by anyone who verifies, so long as the signing keys stay in your custody, and it verifies cold and offline with the operator public key alone.

Frequently asked questions

How do I forecast AI inference costs when I cannot predict usage?

You stop forecasting the usage and fix the capacity instead. Buying a known amount of compute changes the question from how much people will use this to how much of what you own was actually used. Utilisation is measured after the fact and corrected at the next increment.

Is owned hardware cheaper than metered inference?

That depends on your volume, your utilisation and your time horizon. The stronger argument is not cheaper, it is forecastable. Owned capacity leaves you with variance you control and can plan for, in power, operations and refresh, while metering gives you a bill that rises with the adoption you are working hard to create.

What happens if you outgrow the hardware you bought?

You add capacity or people queue. Both are visible and planned, and neither arrives as a surprise invoice. Sizing for peak concurrency rather than average demand leaves a margin, and utilisation reporting on your own machines signals the next increment before users feel the pressure.

Does keeping inference in-house mean accepting weaker capability?

It means a different set of trade-offs, not an automatic downgrade. A capable model on hardware you own, running over loopback only, handles drafting, private retrieval over your own documents, and routine document and analysis work. What changes is that you manage capacity rather than a billing relationship.

How can you test this before committing capital?

Measure first. Take a representative period of real workload, record the volume and concurrency profile, then model both paths against that curve rather than an illustrative example. We run a selective closed beta of Mickai at mickai.co.uk/beta for organisations that want to make that comparison on their own hardware, and not every applicant is accepted.