SERVE
Inference API
Bring your fine-tuned model and get a production endpoint on UK GPUs. It speaks the OpenAI API, so your existing code works after one base-URL change.
Learn more
LON1 · London, UK — accepting deployments
Sovereign inference for your fine-tuned models.
Bring your fine-tuned weights. Get an autoscaling, OpenAI-compatible endpoint that contractually never leaves the UK — with the audit evidence your DPO needs.
$ pip install fohs
SERVING OPEN-WEIGHT MODELS FROM
01 · PLATFORM
Deploy it. Prove it. Check it.
Three products behind one base-URL change — point your client at api.fohs.ai and every response comes back receipted.
02 · RUNTIME
Production serving, UK-pinned.
01 · PLATFORM
Deploy it. Prove it. Check it.
Three products, one platform — for the engineer who ships it and the DPO who signs for it.
If your code speaks OpenAI, it already speaks FOHS. Point your client at api.fohs.ai — same request shape, same streaming, same SDKs.
- OpenAI-compatible endpoint — one base-URL change
- UK data-centre GPUs — autoscale 0→N, scale-to-zero
- A signed receipt on every response
- Anyone can verify at fohs.ai/verify — no account needed
HOW A DEPLOY WORKS
model in → UK endpoint out
01 · YOUR MODEL
Fine-tuned weights
hf.co/acme/triage-v3
or direct upload (safetensors)
or direct upload (safetensors)
deploy
02 · FOHS RUNTIME · LON1
UK data-centre GPUs
H100-80GB · autoscale 0→N
scale-to-zero when idle
scale-to-zero when idle
serve
03 · ENDPOINT
OpenAI-compatible API
api.fohs.ai/v1
keep your existing SDK
keep your existing SDK
region: uk-lon-1 · data residency: contractual, UK-only
billing: per GPU-minute
curl https://api.fohs.ai/v1/chat/completions \
-H "Authorization: Bearer $FOHS_API_KEY" \
-d '{
"model": "acme-triage-v3",
"messages": [{"role": "user", "content": "..."}]
}'
# response includes:
# "fohs_receipt": "req_8f3a...c21e"
from openai import OpenAI
import os
client = OpenAI(
base_url="https://api.fohs.ai/v1",
api_key=os.environ["FOHS_API_KEY"],
)
r = client.chat.completions.create(
model="acme-triage-v3",
messages=[{"role": "user", "content": "..."}],
)
# receipt: r.model_extra["fohs_receipt"]
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.fohs.ai/v1",
apiKey: process.env.FOHS_API_KEY,
});
const r = await client.chat.completions.create({
model: "acme-triage-v3",
messages: [{ role: "user", content: "..." }],
});
// receipt: r.fohs_receipt
every response → fohs_receipt: req_8f3a…c21e
verify a receipt
PROVE
Provenance Receipts
fohs_receipt: req_8f3a…c21e ✓Every response carries a signed record of where it was processed — model, site, data centre, timestamp. Evidence you can file, not a promise you have to trust.
Learn moreCHECK
Verify
Any receipt can be checked against our published keys at fohs.ai/verify — no account needed. Your auditor sees exactly what you see.
Learn more- Autoscale 0→N — billed per GPU-minute of actual serving
- Weights encrypted at rest — never shared, never trained on
- A signed, verifiable receipt on every request
autoscale
Zero to N, and back to zero
Replicas scale with traffic and shut down when idle. You're billed per GPU-minute of actual serving, not for a warm pool.
SIMULATE TRAFFIC
240 req/s
replicas 2 · 120 GPU-min/hr
custody
Your weights stay yours
Encrypted at rest in a UK data centre, used only to serve your endpoint. Never shared, never trained on.
provenance
SIGNED
Per-request receipts
Each response includes a signed record — model, GPU, operator, site, data centre, timestamp — verifiable at fohs.ai/verify.
03 · COMPLIANCE
Built for the person who signs the DPIA.
We provide the evidence; your DPO makes the call. No vendor promises where an attestation should be.
See the full compliance ledger04 · NETWORK
One endpoint. A growing network of UK data centres.
Every request — today and as the network grows — answers “where exactly did this run?” with a cryptographic signature.
03 · COMPLIANCE
Built for the person who signs the DPIA.
We provide the evidence; your DPO makes the call. No vendor promises where an attestation should be.
- Pre-filled DPIA inputs — data flows, subprocessors, residency
- UK-only processing written into the contract
- Cyber Essentials Plus underway; ISO 27001 on the roadmap
DPIA-ready
Pre-filled data-flow diagrams, subprocessor list, and residency attestation — the inputs your assessment actually asks for.
UK-pinned, contractually
UK-only processing is written into the contract — not a region dropdown you have to trust was set correctly.
Assurance roadmap
Cyber Essentials Plus underway; ISO 27001 and NHS DSPT on the published roadmap.
Continuity STANDBY
Dual UK supplier accounts; documented failover procedure.
04 · NETWORK
One endpoint. A growing network of UK data centres.
Every request — today and as the network grows — answers “where exactly did this run?” with a cryptographic signature.
- Serving today from LON1, London
- Every receipt names the operator and the site
- One endpoint as the network grows
Serving today
Your model serves from one UK site: LON1, London. Your team can be anywhere — UK jurisdiction is what you're buying, not where you have to be.
Failover
A second UK supplier is on standby with a documented failover procedure.
Receipts
Every request is receipted with exactly which site served it — the receipt names the operator and the site.
Roadmap
We treat sovereign compute as strategic infrastructure. The roadmap: a receipted network of independent UK operators — including renewable-powered modular sites — one endpoint, many UK sites.
Beyond the UK
A receipt names an operator, a site, and a signing key — nothing in that format is UK-specific. On the roadmap, a new jurisdiction means new sites under the same proof, pinned the same way — the UK is deployment one.
Run a UK data centre? Put your GPUs behind FOHS.
Talk to us
Ship your model to UK soil.
Your first deploy happens on the call — pay per GPU-minute, evidence included.
Book a demo
$ pip install fohs