Infrastructure Single tenancy Hardware in your name Choice of jurisdiction

Private data centre.
Your own rack.

Between a public API and a server room in your building sits the option most organisations do not know they have: dedicated hardware in a professional facility, running weights you chose, under a contract in your name — single tenancy without becoming a data-centre operator.

WHAT IT IS, PRECISELY

You lease space, power and connectivity in a colocation facility. Inside that space sits hardware you own or lease directly — GPUs, storage, networking — running an open-weight model and the serving stack around it. The facility provides the building, the power, the cooling and the physical security. Nobody else's workload runs on your accelerators, and no other tenant shares your memory.

The distinction from cloud GPU rental is meaningful and frequently blurred by people selling the latter. A cloud GPU instance is a slice of somebody else's fleet, allocated to you for as long as you pay, on hardware that also serves others and in a control plane you do not own. A colocated machine is your machine. You know its serial number. You can specify who is permitted to touch it and you can require that access be logged. For a regulated organisation those distinctions are easier to evidence to an auditor than a shared-tenancy assurance.

The distinction from on-premise is equally clear. The hardware is not in your building, so someone else provides the power redundancy, the fire suppression, the cooling and the physical guarding — all of which are expensive to build and unglamorous to maintain. You get most of the control of on-premise without the capital project.

WHEN THIS IS THE RIGHT MIDDLE

No suitable space on site

A GPU node draws serious power and produces serious heat and noise. Many offices simply cannot host one, and retrofitting a room with the power and cooling to do so is a building project. Colocation solves that without a building project.

Jurisdiction is a requirement

You can choose the country and often the specific facility. For an organisation that has to state where its data physically sits — and increasingly to state which legal system can compel access to it — that is a direct answer rather than a regional label on a cloud console.

Single tenancy matters

Where the objection is to shared infrastructure rather than to remote infrastructure. Your model, your memory, your accelerators, no co-tenants — which answers a specific and common line of security questioning.

Resilience without redundancy at home

Professional facilities provide power redundancy, cooling and network diversity that would be disproportionate to build in an office. If the AI is load-bearing, that difference matters more than it sounds.

WHAT WE DO

STEP 01

Sizing

Model selection and hardware specification from your actual workload — concurrency, context length, latency target and growth. This decides everything downstream, so it is done properly rather than from a template.
STEP 02

Facility and procurement

Selecting a facility in the jurisdiction you need, specifying the hardware, and putting the contracts in your name. We advise; you own the relationship, because a supplier relationship held by your consultancy is a dependency you did not ask for.
STEP 03

Build

Racking, networking, the serving stack, private connectivity back to your network, retrieval layer and observability. Delivered as infrastructure-as-code into your repositories so it can be rebuilt without us.
STEP 04

Validation

Evaluation suite against your real tasks, load testing at your projected concurrency, failover behaviour, and the runbook for what happens when a card fails.
STEP 05

Operate or hand over

We run it under support, or your team does with the documentation we leave. Both paths are supported and the choice is reversible.

THE HONEST TRADE-OFFS

It is a commitment. Colocation contracts run in years and hardware is bought rather than rented. That is exactly what makes the cost predictable, and it is also what makes it wrong for anyone whose requirements might change fundamentally in six months. Prove the use case first, on an API, then commit.

Somebody has to go there occasionally. Rarely — remote hands services cover most of it — but hardware fails, and when it does a physical person is involved. Factor that into the operating model rather than discovering it during an incident.

It is not on-premise. The data is on your hardware but not in your building, and it crosses a network link to get there. We build that link as a private, encrypted connection, and for the overwhelming majority of requirements it is fine — but if the actual requirement is that data never traverses a wire you do not own, this option does not meet it and on-premise does.

QUESTIONS

QUESTIONS — 4

Ownership and tenancy. A cloud GPU is a slice of a shared fleet under someone else's control plane, billed by the hour and reallocated when you stop paying. A colocated machine is yours, single-tenant, with a serial number and a documented access list. For most workloads the cloud option is fine; where an auditor is going to ask who else could reach the hardware, it is not.

Yes, and we would encourage you to make it a deliberate choice rather than a default. The relevant question is not only where the building is but which legal system can compel access to what is inside it, which is covered on the data residency page.

You do, and the facility contract is in your name. We advise on specification and manage the build, but we do not sit between you and your infrastructure. If our engagement ends, nothing about your deployment changes.

Predictable rather than usage-linked, which is the point. The crossover volume depends on your workload and we calculate it explicitly rather than asserting it — the business case page sets out the method, including hardware depreciation and operator time.

Keep reading

Data Residency & Sovereignty

30-minute technical call · no deck