Infrastructure Runs on hardware you own Open weights, no per-token bill

AI hosting and infrastructure.

Most AI conversations start with which model. The more consequential question is where it runs — because that single decision settles data residency, unit cost, latency, vendor dependence and whether a security review takes two days or two quarters.

THE DECISION NOBODY MAKES DELIBERATELY

Almost every AI project defaults to a public API, because that is the fastest way to see something work. That default is often correct and it is almost never examined. It should be, because by the time a prototype has become a system, three things have quietly become true: every document you process has been transmitted to a third party, your cost scales linearly and permanently with usage, and your service availability is somebody else's operational problem.

None of those is automatically unacceptable. All three are decisions, and they deserve to be made rather than inherited. For a large number of organisations — regulated ones, ones with genuinely confidential corpora, ones running high sustained volume — a different answer is both cheaper and easier to defend.

The honest position is that there are five places your AI can run, they sit on a spectrum from convenient to controlled, and the right one depends on constraints we can work out with you in an afternoon. What follows is that spectrum, without a thumb on the scale — we build all five — and the hybrid of them — and the one that fits you is not the one that is most work for us.

THE FIVE PLACES IT CAN RUN

Public API

A hosted frontier model over the internet. Fastest to build, no hardware, best raw capability — and every request leaves your perimeter. The right answer for prototypes, low volume, and any workload where the data is not sensitive.

WHAT EACH ONE ACTUALLY COSTS YOU

	Public API	Your cloud	Private DC	On-premise	Air-gapped
Data leaves your control	Yes	Region-bound	No	No	No
Capital outlay	None	None	Rented	Yes	Yes
Cost scales with usage	Yes, forever	Yes, forever	No	No	No
Best available capability	✓	✓	—	—	—
Needs people to operate	No	Some	Yes	Yes	Yes
Survives a vendor deprecation	—	—	✓	✓	✓
Typical time to first pilot	Days	Weeks	Weeks	4–10 weeks	8–16 weeks

A structural comparison of deployment models, not of specific vendors. Timelines are the ranges we scope to, not measured client outcomes.

WHAT WE PROVIDE

Sizing and selection

Which model, on what hardware, for what concurrency — worked out from your actual workload rather than from a vendor's reference architecture. Often the workload needs less hardware than a vendor reference architecture suggests.

Build and integration

The serving stack, the retrieval layer, the routing gate, the observability, and the integration into the systems that hold your data. Delivered into your repositories and running on your infrastructure.

Operation or handover

We either run it or teach your team to. Both are legitimate; what is not legitimate is a system nobody but us can operate, which is why the handover documentation is part of the build rather than an afterthought.

EVERY INFRASTRUCTURE PAGE

INF.01 On-Premise AI Running models on hardware inside your own building, so no prompt, document or customer record ever leaves the premises. → INF.02 Private Data Centre Hosting Dedicated hardware in a colocation facility running your own model — single tenancy without buying a server room. → INF.03 Air-Gapped Deployment AI on a network with no route to the internet: how updates, evaluation and model delivery work without a connection. → INF.04 GPU Sizing & Cost What hardware a given model size actually needs, how to size for concurrency, and the arithmetic behind buy-versus-rent. → INF.05 Hybrid Model Routing Local models for sensitive or high-volume work, frontier APIs for the hard minority — and the gate that decides which. → INF.06 Deployment Options Compared Public API, private cloud, dedicated data centre, on-premise and air-gapped, compared on control, cost, latency and effort. → INF.07 The Business Case for Owning Your AI What self-hosting costs, at what volume it pays back, and the non-financial reasons it is chosen even when it does not. →

DESIGN TARGETS

BYTES LEAVING YOUR NETWORK

4–10 wk

TO FIRST ON-PREM PILOT

100%

CODE DELIVERED TO YOUR REPOS

PLATFORM LOCK-IN

Properties we design and build to, not measured client outcomes.

QUESTIONS

QUESTIONS — 5

Above a sustained volume, substantially — and below it, no. The crossover depends on your request volume, your model size and what you pay people, and it is arithmetic rather than opinion. We work it out explicitly on the business case page, including the lines usually left out of the comparison, which are hardware depreciation and operator time.

Some, and less every quarter. In our experience open-weight models now match hosted models on most routine production tasks; we measure this per workload rather than assume it. Where they lag is the hardest agentic and reasoning work, which is exactly the minority a hybrid routing gate sends to a frontier API. Framing it as all-or-nothing is what makes the decision look worse than it is.

Less than most vendors will quote you. The binding constraint is accelerator memory for the model you choose, then concurrency. A single well-specified node serves a lot of internal users. We size it before you procure anything, and the sizing frequently comes out below the vendor quote.

Your choice. We can run it under a support arrangement, or hand it over with the documentation and runbooks to operate it yourselves. The code and the infrastructure definitions are yours either way — there is no component that only we can maintain.

That is a different product from the one this section describes, and we would rather be clear about the distinction: what we build is infrastructure you own, in a location you control. If the requirement is that somebody else holds the hardware, a private data centre arrangement in your name is the honest version of that, and we set it up and operate it for you.

Keep reading

Data Residency & Sovereignty

On-Premise vs Cloud AI