INF.01
On-Premise AI
Running models on hardware inside your own building, so no prompt, document or customer record ever leaves the premises.
Open pageHosting & Infrastructure · 8 pages
AI hosting & infrastructure.
Where your AI runs is a decision most projects inherit rather than make. We build all five places it can run, and the hybrid of them, and we will say which one fits your constraints — including when it is the public API.
Introduction transcript. Client: Where should our AI actually live? Qubi: Somewhere that fits. Let’s check the map. Qubi: Your servers, a private cloud, or a public API. Sometimes a mix. Client: And if our data has to stay here? Qubi: That comes first. We design the route around it. Qubi: A sensible home for your system.
At a glance
Five places. One decision.
- 01 The default
- Most AI projects start on a public API because it is the fastest way to see something work. That is often right, and it is rarely examined once a prototype becomes a system.
- 02 What it commits you to
- Every document sent to a third party, a cost that scales with usage for as long as the system runs, and availability that is someone else’s operational problem.
- 03 The five places
- Public API, your own cloud account, a private data centre, on-premise and air-gapped, from convenient to controlled. The usual answer is a hybrid of them.
- 04 Who operates it
- Either we run it, or we hand it over with the documentation to operate it yourselves. The code and infrastructure definitions are yours either way.
THE DECISION NOBODY MAKES DELIBERATELY
Make it on purpose.
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.
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.
Three things, quietly true
-
01
Every document you process has been transmitted to a third party.
-
02
Your cost scales linearly and permanently with usage.
-
03
Your service availability is somebody else’s operational problem.
The five places
From convenient to controlled.
Five places an AI system can run, from convenient to controlled. Pick a stop to see what it commits you to.
01 · Fastest to build
Public API
A hosted frontier model over the internet. No hardware, best raw capability — and every request leaves your perimeter. Right for prototypes, low volume, and data that is not sensitive.
No hardware to buy
Best raw capability
Every request leaves your perimeter
Right for prototypes, low volume, and data that is not sensitive
02 · Residency resolved
Your own cloud account
The same class of model consumed inside your own cloud tenancy and region, through Bedrock, Vertex or Azure. Procurement is often faster because the paperwork exists — but it is still not your hardware.
The same class of model, inside your tenancy and region
Through Bedrock, Vertex or Azure
Procurement is often faster because the paperwork exists
Still not your hardware
03 · Single tenancy
Private data centre
Dedicated hardware in a colocation facility running your own model. Physical control without building a server room. The middle option most organisations do not know exists.
Dedicated hardware in a colocation facility
Your own model, with physical control
No server room to build
The middle option most organisations do not know exists
04 · Behind your firewall
On-premise
Hardware in your building, on your network. No prompt, document or customer record crosses the boundary — because there is no path for it to take.
Hardware in your building, on your network
No prompt, document or customer record crosses the boundary
Because there is no path for it to take
05 · No route out
Air-gapped
On-premise with no route to the internet at all. Updates and models arrive by controlled media. The most demanding to operate, and for some environments the only permitted option.
On-premise with no route to the internet at all
Updates and models arrive by controlled media
The most demanding to operate
For some environments, the only permitted option
The usual answer
Hybrid. Most mature deployments end up here.
Sensitive and high-volume work on your own hardware, the hard minority routed to a frontier API with the sensitive parts removed.
Hybrid model routing →WHAT EACH ONE ACTUALLY COSTS YOU
What each place costs you.
Compare your options
| Criterion | 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 | Yes | Yes | No | No | No |
| Needs people to operate | No | Some | Yes | Yes | Yes |
| Survives a vendor deprecation | No | No | Yes | Yes | Yes |
| Typical time to first pilot | Days | Weeks | Weeks | 4–10 weeks | 8–16 weeks |
WHAT WE PROVIDE
Sizing, build, and then who runs it.
-
01
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 the reference suggests.
-
02
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.
-
03
Operation or handover
We either run it or teach your team to. Both are legitimate; a system nobody but us can operate is not, which is why the handover documentation is part of the build.
EVERY INFRASTRUCTURE PAGE
Every infrastructure page.
-
-
INF.02
Private Data Centre Hosting
Dedicated hardware in a colocation facility running your own model — single tenancy without buying a server room.
Open page -
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.
Open page -
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.
Open page -
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.
Open page -
INF.06
Deployment Options Compared
Public API, private cloud, dedicated data centre, on-premise and air-gapped, compared on control, cost, latency and effort.
Open page -
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.
Open page
- Building software since
- 2006
- Based in
- Barcelona
- Model stance
- Agnostic
- Code ownership
- Yours
Facts about how we work, not measured client outcomes.
Questions
What people ask before they host it themselves.
Is self-hosting actually cheaper?
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.
Do we lose capability by running our own model?
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.
What hardware do we need to buy?
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.
Who operates it once it is built?
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.
Can you host it for us at your premises?
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.
Hire your first
AI employee.
Tell us the job you would hand over if you trusted a machine with it. In one 30-minute call we will tell you whether it should, what it would take — and if it should not, we will say so.
Pick the job — the form arrives ready for it
Qubi Your guideInfrastructure guide
01 / 12
Shall I show you around?
Explore with Qubi
