By mid-2026, on-premise AI inference has stopped being a pilot project and become core infrastructure: 78% of organisations now run their own inference stack rather than depending solely on public model APIs, according to IT Brief UK's May 2026 survey. For UK teams, that shift is less about novelty and more about control — over data residency, over cost per token, and over a foreign vendor's ability to pull the plug. This explainer breaks the private LLM stack into its real components — model weights, serving engine, GPU layer, gateway — and shows, with sourced 2026 figures, where the money and the risk actually sit. See how to calculate how many GPUs you'll need to run an LLM before committing capital.
View the data behind this chart
| Layer | Detail |
|---|---|
| Model weights & quantisation | Open-weight models in FP8 or Q4_K_M format |
| Serving engine | vLLM or TensorRT-LLM handling batching and cache |
| GPU compute | H200 or RTX PRO 6000 Blackwell accelerators |
| Networking & tiered storage | GPU-direct paths feeding data at speed |
| Orchestration & observability | Governance, monitoring and security controls |
Why UK enterprises are moving AI inference on-premise in 2026
The headline number from IT Brief UK's May 2026 research is stark: 78% of surveyed organisations now operate their own AI inference infrastructure, and only 8% rely exclusively on public AI services. The remaining majority run a deliberate mix of models and environments — which tells you on-premise inference is no longer an edge case, it's the operating norm for anyone with sensitive data.
TechRadar's July 2026 coverage frames this as a change in principle, not just posture: data sovereignty has moved from a compliance checkbox to a core architectural requirement baked into how systems are designed from day one. That shift was sharpened by a 2026 US Commerce Department directive that disabled foreign AI models for non-US users — a concrete demonstration of what industry commentators now call the 'kill-switch vulnerability' of depending on foreign-hosted models. For UK buyers, the lesson was blunt: a model you don't control the weights, runtime, or hosting jurisdiction for can be withdrawn without your consent.

Defining the private LLM stack: model, engine, GPU, gateway
On-premise AI inference, precisely defined, means running the model weights, the inference runtime, the data infrastructure, and the serving APIs entirely inside an environment you control — not a third-party's cloud account, per OneSource Cloud's June 2026 architecture guidance. Nothing about the inference path leaves your perimeter.
In practice, the stack has five layers: the model weights themselves (usually quantised open-weight models), a serving engine that turns those weights into an API, a GPU compute layer that actually executes the maths, a networking and storage layer that feeds the GPUs fast enough to keep them busy, and an orchestration and observability layer that governs and monitors the whole thing. OneSource Cloud describes this as dedicated GPU clusters, high-performance AI networking, tiered storage with GPU-direct paths, and a serving stack, all sitting under one governance layer — which is the practical checklist any UK infrastructure architect should be working from.
For a first pilot, a practical sequence follows that same five-layer logic: start with a single quantised model — a 7B model at Q8 needs just 8-9GB of VRAM, low enough to trial on a single GPU — served through vLLM for its PagedAttention efficiency, sitting behind a gateway that enforces which data can leave the perimeter. Validate the orchestration and observability layer before scaling GPU count, and build in the MLOps, data engineering and infrastructure architecture skills the stack needs early, given 97% of UK businesses report critical AI skills gaps. Only then extend to the hybrid pattern — sensitive workloads on-premise, general queries routed elsewhere — that most organisations land on in production.
GPU sizing for 2026: VRAM, quantisation and hardware choices
VRAM is the single biggest constraint on local LLM deployment, and quantisation is the lever that controls it. A model held at FP16 precision needs roughly 2 bytes per parameter; quantised to Q4_K_M, that drops to roughly 0.5 bytes per parameter — a fourfold reduction, per VRLA Tech's June 2026 analysis. That's why a 70B-parameter model, which would be unworkable at full precision on most single GPUs, needs only around 40GB of VRAM once quantised to Q4_K_M. A 7B model at Q8 quantisation needs just 8-9GB.
On the hardware side, two GPUs currently anchor most UK private-stack decisions. The NVIDIA RTX PRO 6000 Blackwell, with 96GB of ECC GDDR7 and 1.8TB/s of bandwidth, is widely regarded as the optimal single-GPU choice for production vLLM serving. The NVIDIA H200 goes further, with 141GB of HBM3e memory and up to 4.8TB/s of bandwidth, making it the choice for multi-GPU clusters serving larger models or higher concurrent load. Before buying either, it's worth learning to understand the VRAM requirements for an LLM against your actual context lengths and batch sizes, since KV cache and activation memory add on top of the base model footprint.
What it actually costs: on-prem vs cloud/API economics
Hard sterling pricing for enterprise-grade AI GPUs is still scarce in the UK market — most suppliers quote in USD. As a benchmark, an 8-GPU H200 server for direct purchase starts around $300,000-$500,000, while renting H200 capacity by the hour runs $2.50-$10.60 per GPU-hour depending on provider and commitment, according to Octagon AI's 2026 pricing data. That gap is the entire on-prem-vs-cloud decision in two numbers: CapEx-heavy ownership versus OpEx-flexible rental.
Power matters too. A comparable data-centre GPU, the NVIDIA H100 SXM5, draws up to 700W at full load — multiply that across an 8-GPU chassis plus cooling overhead and the electricity bill becomes a real budget line, particularly against a backdrop where global data-centre electricity demand is projected to reach between 565 TWh (Gartner) and over 1,000 TWh (other estimates) in 2026. Against that, the payoff case is compelling: AI Hive's 2026 analysis finds on-premise inference can run at up to 18x lower cost per million tokens than frontier model APIs — but only once utilisation is high enough to absorb the upfront hardware spend. Before sizing a cluster, it's worth working through a detailed model to compare the costs of self-hosting an LLM versus using cloud GPU rental for your specific workload.
UK regulation and the sovereignty imperative
UK GDPR and data residency expectations are the baseline reason many organisations start looking at on-premise inference in the first place, but 2026 added a sharper edge: the demonstrated kill-switch vulnerability of foreign-hosted models means version-pinned, open-weight deployments on sovereign infrastructure have gone from 'nice to have' to imperative for anything regulators, boards, or customers would call sensitive.
Sector-specific rules compound this for regulated industries — financial services and healthcare organisations layer their own regulator expectations on top of GDPR, which typically pushes them further toward keeping inference inside a controlled perimeter rather than trusting it to a third-party API, even a UK-hosted one. This is consistent with the broader picture: over 95% of UK firms now consider private and sovereign AI important, and data sovereignty and security are cited by 52.6% of AI decision-makers as a top barrier to adoption — which is really a barrier to trusting someone else's infrastructure, not to AI itself.
View the data behind this chart
| 7B model (Q8… | 70B model (Q4_K_… | |
|---|---|---|
| VRAM required | GB9 | GB40 |
Hybrid architectures: splitting workloads sensibly
The 78%/8%/mixed split from IT Brief UK isn't an accident — it reflects a deliberate hybrid strategy most organisations land on once they've actually run inference in production. Two patterns dominate. First: sensitive data and regulated workloads stay on-premise, while lower-sensitivity, general-purpose queries route to a private cloud or managed environment. Second: retrieval-augmented generation (RAG) over proprietary documents runs on-premise, where the sensitive corpus lives, while a general-knowledge base model handled via API covers everything that doesn't touch confidential data.
Both patterns are a response to the same pressure: 88% of organisations report facing AI-related security challenges as these systems become embedded in daily operations, per IT Brief UK. A gateway layer that enforces which requests can leave the perimeter — and which must stay — is what turns a hybrid intention into an enforceable architecture rather than a policy document nobody follows.
Staffing the stack: UK skills reality
The infrastructure argument for on-premise inference is only half the story; the other half is who runs it. TopTenAIAgents.co.uk's 2026 research found 97% of UK businesses report critical AI skills gaps — a figure that should give any board pause before committing to a fully self-managed stack. Running a private LLM stack in production means covering MLOps engineering (deploying and monitoring the serving engine), data engineering (feeding the GPU-direct storage layer), and infrastructure architecture (sizing, networking, orchestration) — roles that are scarce and in demand across the UK market.
This is precisely why the orchestration and observability layer matters so much, and why many organisations lean on managed on-premise deployment support rather than building every skill in-house from scratch. If you're starting from zero, a practical guide to building your first on-premise AI cluster is the more realistic entry point than trying to replicate a hyperscaler's MLOps team internally.
Overcoming operational challenges and the outlook
Two serving engines dominate the practical choice at the GPU layer. vLLM, built around PagedAttention memory management, is the widely adopted default for maximising GPU utilisation and concurrency. TensorRT-LLM, NVIDIA's own framework, trades some flexibility for raw speed — Davies Meyer's May 2026 benchmarking found it delivers 2-3x faster inference than vLLM on the same hardware for Llama 3 70B on H100, using FP8/INT8 quantisation, in-flight batching, paged KV-cache, and tensor parallelism across GPUs.
Neither engine solves governance on its own — that's the job of the orchestration and observability layer, and it's the layer most likely to be under-resourced given the 88% security-challenge figure above. The broader market context suggests this investment is being taken seriously: the global AI platforms market, of which the UK is a significant contributor, is forecast to grow from $109.9 billion in 2025 to $181.3 billion in 2026, per The Futurum Group — a trajectory that points toward on-premise and sovereign infrastructure becoming standard procurement, not exception.
Sources
Every figure in this article traces to the sources below.
- •OneSource Cloud — private LLM deployment architecture and stack definition
- •IT Brief UK — 2026 survey on inference infrastructure and security challenges
- •TechRadar — data sovereignty as an architectural principle
- •VRLA Tech — quantisation and VRAM requirements
- •VRLA Tech — RTX PRO 6000 Blackwell for production vLLM serving
- •Wecent — NVIDIA H200 specifications and pricing
- •Yotta Labs — vLLM and PagedAttention
- •Davies Meyer — TensorRT-LLM performance benchmarking
- •The Futurum Group — global AI platforms market size 2025-2026
- •PromptQuorum — VRAM requirements for 70B and 7B models
View the data behind this chart
| Cost Model | Data Location | Typical Use Case | |
|---|---|---|---|
| On-prem H200 purchase | $300k-500k (8-GPU) | Fully on-prem | High-volume steady load |
| Cloud GPU rental… | $2.50-$10.60/GPU-hr | Third-party cloud | Bursty variable loads |
| Frontier model API | Up to 18x higher/token | Vendor-hosted, offshore | Non-sensitive use only |
