An on-premise LLM, on hardware you control.
The model runs on GPUs you own or lease, in your data centre, connected to your identity provider, your logging and your change process. For data that can’t go to a public cloud.
What you get
Fits into the systems you already run.
A hardware specification
GPU type, count, memory and networking sized from measured throughput at your expected load.
Your identity provider
Single sign-on through SAML or OIDC, with access mapped to your existing groups.
Your logging
Requests, access and admin actions sent to your SIEM, under your retention rules.
Your change process
Model and software updates go through your change approvals, with test results attached.
A serving stack
Kubernetes with the GPU operator, or a simpler setup where your team prefers it. A standard API in front.
Runbook and recovery test
An operations runbook for your team and a disaster-recovery test before go-live.
How it works
From rack to production.
01
Review
Your data centre, network, identity, logging and change standards.
02
Specify
Hardware sized from measured throughput. If you already have GPUs, we tell you what they can serve.
03
Install
Serving stack, private endpoints and integrations, installed with your team.
04
Test
Your evaluation suite, load tests and a recovery test, with the results written up.
05
Run
Your team runs it with our runbook, or we support it with access granted per task.
Technical detail
What we install, and how we size it.
Platform
Kubernetes with the NVIDIA GPU operator, or bare-metal serving for small installations. Signed images and a software bill of materials.
Kubernetes · GPU operator · signed images · SBOM
Serving
vLLM or SGLang for most workloads, TensorRT-LLM where peak throughput on NVIDIA hardware matters. A standard API in front, so your applications don’t change if the model does.
vLLM · SGLang · TensorRT-LLM
Sizing
A 70B-parameter model needs about 140 GB for weights at 16-bit, 70 GB at FP8 and 35–40 GB at 4-bit, plus memory for each conversation in flight. We size from measured throughput at your expected load, and re-run your tests after any quantisation.
FP8 · AWQ · GPTQ
Who has access
No standing access for us.
Our engineers have no permanent access to your systems. When we need to work on them, access is granted just in time through your privileged-access tooling, and every session is logged by you.
Regulation
Built to support your obligations.
| Framework | What it asks | How we support it |
|---|---|---|
| MAS Technology Risk Management Guidelines | Controls for access, cryptography, resilience and third parties. | Our controls mapped to the relevant sections. |
| DORA Art. 28–30 | A register of ICT providers, exit strategies and mandatory contract terms. | Contract terms written for Art. 30, an exit plan and the data you need for your register. |
Questions
What infrastructure teams ask.
Can we use GPUs we already own?
Usually. We measure what they can serve at your load and tell you which models fit.
Does it need an internet connection?
Not to run. Updates can arrive through your normal patching route. If you need no connection at all, choose air-gapped.
Who operates it after go-live?
Your team, with our runbook, or us with access granted per task through your tools.
What we don’t promise
Some claims we won’t make.
- Hardware delivery dates. GPU lead times vary.
- That older GPUs can serve every model. We measure them and tell you what fits.
Your hardware, your rules.
Tell us what you run today. We’ll tell you what it can serve.