Devansh Kamlani
I have spent the last several years helping enterprises figure out the most uncomfortable question in modern AI architecture: how much of this should sit inside our own data centre, and how much belongs in someone else’s. Every executive I speak with assumes the answer is binary, when in fact the answer is almost always hybrid. The interesting work happens at the seams, where private inference clusters meet public foundation-model APIs, where edge devices handshake with regional cloud regions, and where data residency rules collide with the economics of GPU scarcity.
Hybrid On-Prem and Cloud AI Architectures: When & Why
In this article I want to share what I have learned about designing hybrid on prem cloud ai architectures that actually survive contact with regulators, finance teams and SRE on-call rotations. I will walk through the drivers that push organisations into hybrid topologies, the patterns that keep showing up in regulated industries, the open-source and commercial tools worth knowing, and the decision matrix I use when a client asks “should this workload run on our metal or in the cloud?”.
If you are an architect modernising a bank, an insurer, a hospital network or a government department, the design choices in this piece will feel familiar. If you are coming from a pure cloud-native background, I hope this gives you a sharper appreciation for why “lift everything to the cloud” is rarely the right answer when sensitive data and regulated workloads are in scope.
Why hybrid AI matters in 2026
I remember being told, around 2019, that the cloud would eat everything. For traditional web workloads that prediction has largely held. For AI, the picture is more nuanced. Foundation models exploded in size at the same time that data sovereignty rules tightened across Europe, the Gulf and parts of Asia. The result is that organisations cannot simply send all their data to a hyperscaler region in another country, but they also cannot afford to train and host every model themselves.
Hybrid is now the dominant posture for enterprise AI. Gartner, Forrester and the analyst circuit all report that more than seventy per cent of regulated organisations are running at least one workload in a hybrid configuration. From my own consulting practice, I would put the figure higher in financial services and healthcare.
The point of hybrid is not to hedge bets. It is to put each workload in the environment where its constraints are best satisfied.
The architects who do this well treat the hybrid boundary as a deliberate design decision, not as a temporary state on the way to full cloud migration. That mindset shift is what this article is really about.
The four drivers that force hybrid decisions
When I sit down with a new client, I work through four drivers in order. They almost always map to a hybrid pattern by the end of the conversation.
- Data residency and sovereignty. Personal data, health records, financial transactions and government documents often cannot legally leave a country or even a region within a country.
- Latency. Inference for trading desks, industrial control loops and clinical decision support sometimes needs sub-fifty-millisecond responses that a cross-region API call cannot deliver.
- Cost predictability. Steady, high-volume inference at scale can be cheaper on owned hardware than on per-token APIs once you cross a usage threshold.
- Strategic control. Some boards simply will not accept a single-vendor dependency for a workload that defines a competitive advantage.
I order them like this because residency is a hard constraint, latency is a measurable physical constraint, cost is a model you can build and control is a board-level preference. Hard constraints win first.
A useful exercise is to score each candidate workload one to five against each driver. Workloads scoring high on residency and latency almost always end up on-prem or in a sovereign region. Workloads scoring high only on cost can often be parked on a managed API until the maths shifts.
Data residency and sovereignty in practice
Data residency sounds simple until you start drafting an architecture. The complications come from secondary flows: training data, telemetry, prompt logs, fine-tuning datasets and vector embeddings all count as data, and all are subject to the same rules as the underlying records.
I worked with a European insurer last year that initially assumed they could send anonymised claims to a US-based LLM. After review, their legal team concluded that the embeddings themselves constituted personal data under GDPR because they could potentially be inverted. We moved the embedding model on-prem and kept only de-identified text snippets crossing the border. That single decision restructured the entire architecture.
The patterns that emerge are:
| Sovereignty requirement | Typical architecture |
|---|---|
| Data must not leave country | On-prem or in-country sovereign cloud for storage, retrieval, embeddings |
| Data may leave region but not jurisdiction | EU or UK regional cloud with strict egress controls |
| Public data only | Managed APIs with prompt sanitisation |
| Government-grade classification | Air-gapped on-prem with no internet egress |
A subtle point: residency does not always require on-prem. Sovereign clouds, including AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty and Google’s Sovereign Controls, are increasingly viable for organisations that want regulatory comfort without the operational burden of running their own GPUs.
Latency, throughput and the physics of inference
Latency is the driver architects most often underestimate. A round trip from London to a US East region is roughly eighty milliseconds before any model work happens. For a chat interface this is fine. For a real-time fraud-scoring API attached to a payments rail, it is fatal.
When I model latency for hybrid systems, I break the end-to-end budget into network round trip, model loading, prefill, decode and post-processing. For a seven-billion-parameter model serving streaming tokens, an on-prem deployment behind the application can routinely hit time-to-first-token under one hundred milliseconds. A cloud API call from a distant region rarely beats two hundred milliseconds even with warm connections.
Throughput is a different conversation. Cloud APIs scale horizontally by abstracting GPU capacity; you pay per token and the provider handles the bursty allocations. On-prem clusters require capacity planning that anticipates peak concurrent requests, and I usually advise running at seventy per cent peak utilisation to leave headroom for failures.
For workloads where both latency and throughput matter, I lean toward a hybrid pattern: an on-prem inference cluster for steady-state production and burst capacity into the cloud for spikes.
Cost models for hybrid AI
The economics of hybrid AI are misunderstood almost everywhere I look. Cloud APIs feel cheap at low volume because they are. They become expensive at high, predictable volume because you are paying a margin on someone else’s amortised GPU.
I build cost models around three numbers: cost per million tokens, cost per concurrent user, and cost per query. The first is the public price, the second forces you to think about peak concurrency, and the third grounds the conversation in business outcomes.
A worked example from a recent engagement:
| Deployment | Volume | Monthly cost |
|---|---|---|
| Managed API (GPT-4 class) | 500M tokens | around 7,500 GBP |
| Managed API (GPT-4 class) | 5B tokens | around 75,000 GBP |
| On-prem cluster (4x H100) | up to 8B tokens | around 28,000 GBP amortised |
| Hybrid (on-prem base, cloud burst) | 5B tokens with 20 per cent burst | around 35,000 GBP |
The hybrid model wins above roughly 2 billion tokens per month for this client. Below that, the managed API was cheaper because amortising even a small cluster is brutal at low utilisation. The crossover point is the most important number in your cost model.
Architecture pattern: cloud bursting for training
Training is the canonical case for cloud bursting. I rarely see enterprises with enough sustained training demand to justify owning more than a modest GPU pool, and even then, fine-tuning a large foundation model usually requires capacity they do not have.
The pattern looks like this:
- Curate and pre-process training data on-prem, where the raw records live.
- De-identify, encrypt and stage data into an object store in the chosen cloud region.
- Run training on a managed cloud service, often on a reserved GPU pool or spot capacity.
- Pull artefacts back on-prem for evaluation, deployment and registry.
The hardest part is governance of the data that briefly lives in the cloud. I usually insist on customer-managed keys, dedicated VPC, and deletion attestations. I have never seen a regulator accept “the cloud provider promised to delete it” without further evidence.
Architecture pattern: edge inference with cloud control plane
Edge inference is increasingly common in retail, manufacturing, defence and healthcare. The pattern places small, quantised models close to where the data is generated, while a cloud or central control plane handles updates, monitoring, evaluation and policy.
I have helped retailers deploy three-billion-parameter vision-language models to in-store devices, and energy companies push fine-tuned models onto offshore platforms with intermittent connectivity. In every case the design pivots on the same questions: how do you push updates safely, how do you collect telemetry without leaking sensitive data, and how do you roll back when a deployment misbehaves.
edge_deployment:
model: llama-3.2-3b-instruct-q4
runtime: ollama
update_channel: stable
telemetry:
sample_rate: 0.05
redact: [pii, ssn, customer_id]
fallback:
on_failure: previous_version
on_drift: cloud_route
A robust edge stack will also include a cloud fallback for queries the local model cannot answer with sufficient confidence.
Architecture pattern: private cloud plus public LLM
This is the pattern I see most often in financial services and healthcare. The organisation runs its own retrieval, embedding and vector storage on-prem, but routes the final generative call to a public LLM API for the highest-quality answers.
The trick is at the prompt boundary. Architects need a sanitisation layer that strips, masks or tokenises sensitive fields before any data crosses to the public API. Many enterprises wrap this in a prompt-firewall service, which logs and audits every outbound call.
The hybrid prompt boundary is the new perimeter. Treat it like a firewall, with the same rigour around rule changes, logging and review.
I keep a small library of regular expressions and named-entity recognisers ready for this purpose. None of them are perfect, which is why most clients also enforce a contractual prohibition on the provider retaining data for training.
Self-hosted inference stack: vLLM, TGI, Ollama and Triton
When clients decide to self-host, the stack choices have consolidated nicely. The four runtimes I reach for are vLLM for high-throughput server deployments, Hugging Face Text Generation Inference (TGI) for hosted production with good tooling, Ollama for developer experience and edge deployments, and NVIDIA Triton when the workload mixes LLMs with classical models on shared hardware.
A short cheat sheet:
- vLLM. Best throughput per GPU for transformer LLMs, mature batching, strong open-source community.
- TGI. Good production defaults, integrates with Hugging Face Hub, includes a built-in tokeniser server.
- Ollama. Easiest developer experience, ideal for edge nodes and small clusters, less efficient at high concurrency.
- Triton. Multi-model, multi-framework, used heavily in regulated environments with mixed workloads.
I usually pair the runtime with a router (LiteLLM, KubeAI or a custom layer) so applications can address logical model names rather than physical endpoints. That abstraction is invaluable when you swap out a runtime or migrate between hardware generations.
Networking, identity and the hybrid control plane
The boring part of hybrid AI is also where most architectures fail. Networking, identity and the control plane are what stop a hybrid deployment from collapsing into two parallel single-environment deployments that nobody can operate.
I push every client to standardise on:
- A single identity provider (typically Entra ID, Okta or Ping) federated across cloud and on-prem.
- A service mesh or zero-trust network fabric that treats on-prem and cloud workloads as equally untrusted.
- A central observability stack that ingests metrics, logs and traces from both environments.
- A single policy engine, increasingly OPA or Cedar, that evaluates access decisions identically wherever the workload runs.
The control plane should be designed to survive a partial outage of either environment. If your on-prem control plane breaks during a cloud incident, your hybrid posture has just become a single point of failure.
Regulated industry case studies
Three short examples from my own work, anonymised.
A European bank wanted to deploy an LLM-driven assistant for relationship managers. Customer data could not leave the country. We built a private inference cluster on-prem for embeddings and a small open-weight LLM, with optional routing to a public API for non-customer queries. The router enforced PII redaction at the boundary.
A UK hospital trust wanted to summarise clinical notes. We deployed a fine-tuned Llama model on-prem with a Triton runtime, integrated with their existing electronic health record system. Evaluation and audit pipelines ran in the cloud against synthetic data so the team could iterate without exposing real records.
A Middle Eastern government wanted a sovereign chatbot for citizen services. We deployed a sovereign cloud region with dedicated hardware, on-prem fallback for outage scenarios, and a strict ban on cross-border traffic for any data classified above public.
In every case the right answer was hybrid, but the shape of the hybrid was entirely different. There is no template that survives contact with sector-specific regulation.
The hybrid decision matrix I use
I keep a one-page matrix on hand for these conversations. It looks roughly like this:
| Factor | On-prem leans | Cloud leans |
|---|---|---|
| Data classification | Confidential or above | Public or internal |
| Steady token volume | Above 2B/month | Below 500M/month |
| Latency SLA | Below 100 ms TTFT | Above 300 ms acceptable |
| Regulatory pressure | High | Low |
| In-house GPU expertise | Strong | Weak |
| Workload variability | Predictable | Spiky |
Workloads that score on-prem on three or more rows almost always end up there. Workloads that score cloud on three or more rows belong on a managed API. Mixed scores are where the interesting hybrid designs live.
Security trade-offs you cannot ignore
The security story is not as simple as “on-prem is safer”. On-prem gives you control but transfers the burden of patching, network segmentation and physical security to your team. Cloud transfers some of that burden to the provider but introduces multi-tenancy, shared services and a much larger attack surface for misconfiguration.
I treat the trade-off as three questions:
- Who can read the model weights, and how do you prove they have not been exfiltrated?
- Who can read the prompts and completions, and how do you prove the audit logs are tamper-evident?
- Who can change the deployment, and how do you ensure changes are reviewed against a stable baseline?
For most regulated clients, the answer involves on-prem model weights, encrypted prompt storage with KMS-managed keys, and a deployment pipeline guarded by both human approval and automated policy checks.
Anti-patterns and lessons learned
A few patterns I have learned to avoid the hard way.
- Two parallel architectures. If your on-prem and cloud stacks share nothing, you have two systems to operate, not one hybrid system. Push for shared identity, observability and policy from day one.
- Hand-built routing. Bespoke “is the prompt sensitive?” classifiers tend to be brittle and unaudited. Prefer policy engines and explicit allow-lists.
- Ignoring inference cost drift. On-prem clusters underutilised at midnight are still expensive. Build a routing layer that lets cloud workloads borrow on-prem capacity off-peak.
- Treating egress as free. Cloud egress charges and inter-region traffic can dwarf inference cost when prompts and contexts grow.
The lesson is the same one I keep repeating to teams: the hybrid posture only works if you design the interface between environments more carefully than either environment in isolation.
