How to host an LLM privately in a UAE data center

AI infrastructure & software

"Keep it in the UAE" is easy to say and hard to build. Here is how to host an LLM privately in a UAE data center, layer by layer: the GPU options, the sizing arithmetic, the config files and a control-to-component mapping against the PDPL.

Hosting an LLM privately in a UAE data center means the GPUs, the model server and the gateway all run inside the country, so prompts and responses never leave it. Concretely: in-country GPU capacity or your own rack, Kubernetes with hardware-level isolation between tenants, vLLM serving open-weight models, and one OpenAI-compatible gateway that routes by data class and denies egress to global APIs by default.

"Keep it in the UAE" is the sentence every CTO here has heard in a board meeting, usually followed by no detail at all. Do the GPUs have to sit in Dubai? Must the prompts never leave the country? Can a vendor's support engineer abroad see your data? Almost nobody publishes the full answer, so platform teams assemble one piecemeal: a GPU order here, an API contract there, and a compliance spreadsheet that says "local" and means nothing.

This article is the blueprint we use with clients. It covers an in-country GPU cluster on Kubernetes, an OpenAI-compatible gateway in front of both your own models and hosted in-region ones, hardware-level tenant isolation, and a control-to-component mapping against the PDPL. By the end you should be able to hand a diagram, a sizing calculation and a compliance table to your team and start building. Azrty is a UAE company based in Dubai, and our own team does this design, deployment and support work locally, which is why the regional detail below comes from primary sources rather than brochure copy.

What does hosting an LLM privately in a UAE data center mean in law?

Start with the law, because it is narrower and more sensible than most people assume. The PDPL, Federal Decree-Law No. 45 of 2021, applies to the processing of personal data by controllers and processors established in the UAE, and to anyone processing the personal data of people in the UAE. It does not apply to government entities, to data governed by separate sector rules such as health and banking, or to firms in the financial free zones, because DIFC and ADGM each have their own data protection regimes.

Two points matter for architecture:

1. The PDPL does not ban the cloud, and it does not ban non-UAE AI providers. Articles 22 and 23 allow transfers to jurisdictions with an adequate level of protection, or under contractual safeguards, consent or the other conditions listed there. Calling a model API hosted outside the country is lawful if you meet one of those routes and record it.
2. What the PDPL demands is deliberate, documented control. Article 7 puts the duty on the controller: technical and organisational measures appropriate to the risk, a record of processing activities that includes cross-border movement, and processors chosen with sufficient guarantees. Article 8 puts the same discipline on the processor: process only on documented instructions, erase data when the processing period ends, keep your own records, and demonstrate compliance when asked.

So the engineering goal is not "nothing leaves the country". It is: classification drives routing, routing is enforced by the platform, and every crossing of a border is a decision someone signed off and the system logged. That reframing turns the design from a fortress into a gateway with policy, which is cheaper and, in practice, more compliant, because people route around fortresses.

The reference architecture in one picture

        ┌────────────────────────────────────────────────────┐
        │      Applications, agents, chat UI, CI pipelines    │
        └──────────────────────────┬─────────────────────────┘
                                   │  OpenAI-compatible API
                                   ▼
        ┌────────────────────────────────────────────────────┐
        │      Gateway (FastLLM Proxy or LiteLLM Proxy)      │
        │  virtual keys, per-key and per-provider budgets,   │
        │  routing by data class, full request logs          │
        └──────────┬───────────────────────────┬─────────────┘
     PII-class traffic        non-sensitive or burst traffic
                   ▼                           ▼
   ┌──────────────────────────────┐   ┌──────────────────────────────┐
   │  Your GPU nodes (UAE rack or │   │  In-region hosted inference  │
   │  in-country GPU-as-a-Service)│   │  (UAE region endpoint)       │
   │  Kubernetes, NVIDIA MIG      │   │  capped by provider budget   │
   │  vLLM pod per model          │   └──────────────────────────────┘
   └──────────────────────────────┘
        Egress to global APIs: default denied, opt-in per team

Four layers, each with one decision to make: hardware and jurisdiction, cluster and tenant isolation, model serving, and the gateway. The rest of this article walks through them with specific products, configuration and numbers.

Layer 1: GPUs in a UAE rack, rented or owned

In-country capacity is no longer the blocker it was two years ago. Sovereign cloud providers such as G42's Core42 sell GPU capacity by the hour inside UAE data centres, and colocation operators such as Khazna provide the floor space and power if you would rather own the metal. That is what makes this blueprint timely: you can buy jurisdiction without buying a building.

The misconception to kill in your next architecture review: on-premises is not a requirement of the PDPL. A GPU instance in a UAE data centre keeps every byte inside the country and satisfies residency demands from boards and sector regulators. Owning the metal is a choice, not an obligation.

Layer 2: Kubernetes, and where should the tenant boundary actually live?

Run the platform on Kubernetes with the NVIDIA GPU Operator and device plugin. The decision that matters for hardware-level tenant isolation is which GPU sharing mechanism you allow per node pool:

Config for a node pool that mixes both, using the device plugin's configuration file (which the GPU Operator exposes as a ConfigMap from version 1.11 onwards):

version: v1
flags:
  migStrategy: "mixed"          # expose MIG instances and whole GPUs
  failOnInitError: true
sharing:
  timeSlicing:
    resources:
      - name: nvidia.com/gpu
        replicas: 4             # dev pool only: four schedulable slots per card

With migStrategy: mixed, teams request nvidia.com/mig-1g.10gb for isolated serving, and the dev pool's time-sliced nvidia.com/gpu resource gives four schedulable slots per card. The scheduler keeps the two apart. Deploy it all from Git with Solder, our Kubernetes operator: it keeps clusters in line with the repository, handles approvals and drift detection, and rolls back on its own, which turns the cluster into an auditable artefact rather than a pile of imperative commands.

Layer 3: Model serving with vLLM

Serve open-weight models with vLLM as the first tier behind the gateway. Arabic capability makes the open-weight route genuinely viable in this region: the Jais family from MBZUAI, plus Qwen, gpt-oss and Llama variants, all deployable on your own instances. Typical arguments for a 14B-class model on one H100 80 GB:

command: ["vllm", "serve", "Qwen/Qwen2.5-14B-Instruct"]
args:
  - "--max-model-len=8192"
  - "--gpu-memory-utilization=0.90"
  - "--enable-prefix-caching"        # cached system prompts, a big win for assistants

The throughput figure you design against should be the one you measure. Run vllm bench serve at your real context lengths and concurrency: single-GPU throughput for a 14B-class model is in the low thousands of output tokens per second at realistic concurrency, and it falls as context grows. That measured number is what your capacity plan needs, not a vendor's best case.

Layer 4: One OpenAI-compatible gateway, two tiers of traffic

The gateway is the component most UAE teams are missing, and it is what makes a residency policy real. Every application speaks one OpenAI-compatible API; the gateway decides which backend each request may touch. We build this layer with our own FastLLM Proxy, an OpenAI-compatible gateway in front of your LLM servers and 80 hosted providers, with routing, budgets and access control in one place. The open-source equivalent is LiteLLM Proxy, and its request flow (virtual-key authentication, rate limits per key, user and team, a router with load balancing, retries and fallbacks, then provider translation) is the pattern to copy either way.

The config below puts the whole policy in one file: a private tier on your own GPUs, an in-region hosted tier behind a hard spend cap, and fallbacks that never leave the country.

model_list:
  # Tier 1: your GPUs, your data centre. PII-class traffic.
  - model_name: assistant-private
    litellm_params:
      model: openai/<your-served-model>          # the vLLM endpoint above
      api_base: http://vllm.assist.svc.cluster.local:8000/v1
      api_key: os.environ/VLLM_KEY

  # Tier 2: in-region hosted, for non-PII and burst traffic.
  - model_name: assistant-hosted
    litellm_params:
      model: openai/<in-region-model-id>         # a UAE-region hosted endpoint
      api_base: os.environ/IN_REGION_BASE_URL
      api_key: os.environ/IN_REGION_KEY

router_settings:
  fallbacks:
    - {"assistant-private": ["assistant-hosted"]}   # fail over, stay in-country
  provider_budget_config:
    openai:                                         # provider of the hosted tier
      budget_limit: 400                             # USD per period, your cap
      time_period: 30d

Two behaviours in that file do the compliance work. The fallback keeps availability high without sending PII abroad, because the hosted tier is itself in-region. The provider budget is a hard stop: once the hosted tier has cost $400 in the period, the router skips it and returns a 429 rather than quietly overspending, which is how per-key and per-team spend control gets enforced rather than merely reported. Per the LiteLLM architecture, budget and rate-limit checks run against a Redis-backed cache before the request reaches a provider, and logging and spend accounting happen after the response, so nothing extra sits in the request path.

At Azrty we run this stack, cluster to gateway to the applications on top, through our AI infrastructure service, with the platform layer provided by our own Kuvryn software: a self-hosted Kubernetes platform that shows each AI application with its parts and its health, and when something breaks, the reason why. That is the difference between a compliance story and an operable one.

Worked example: a 3,000-person group and its knowledge assistant

Take a mainland UAE group with 3,000 staff building an internal assistant over HR, finance and operations documents. Assume:

• 600 active users a day at 30 requests each: 18,000 requests a day
• 1,000 input and 400 output tokens per request: 18M input and 7.2M output tokens a day
• The peak hour carries about 12% of daily volume, with peak concurrency around 60 streams

Sizing the private tier. The peak hour is roughly 2,160 requests at 400 output tokens, so 864,000 output tokens an hour, or about 240 output tokens a second sustained, with short bursts several times that under concurrency. One H100 running a 14B-class model serves in the low thousands of tokens a second, so a single GPU covers the peak comfortably, but a single GPU is also a single point of failure. The answer is N+1: two H100-class instances, on one node or two.

Costing the private tier. Rent is where your provider's quote enters the arithmetic: two instances at 24/7 is 2 × your hourly rate × 730 hours. The point is the division at the end. Two dedicated GPUs divided by the 756M tokens a month this workload represents comes out several times the per-token price of in-region hosted inference. The GPUs reach parity only when they run near saturation; at pilot volumes they sit idle most of the day.

So do not buy GPUs for a pilot. Route by data class instead: the minority of traffic that contains personal data goes to the private tier (which can start as two rented in-country GPU instances, not a rack), while internal, non-personal and bursty traffic goes to the hosted in-region tier behind the provider budget. Scale the private tier when measured utilisation justifies it, and re-run these numbers at each step.

Which PDPL control maps to which component?

This is the table to put in front of your DPO and your auditors. Each row maps a duty in the PDPL text to a component in this blueprint.

The transfers row is the heart of it. Cross-border movement in this design is not an accident that happens inside an SDK; it is a YAML entry a named person reviewed, the gateway enforces, and the logs evidence.

What to do next

1. Classify, then size. Split planned AI traffic into PII-class and non-PII and estimate daily tokens for each. The example above is ten minutes of arithmetic, and it changes the hardware conversation.
2. Start with in-country GPU-as-a-Service, not a rack. Two rented H100-class instances in a UAE data centre cover the private tier for a 3,000-person organisation. Add metal when measured utilisation demands it.
3. Stand up the gateway before the second application. One OpenAI-compatible endpoint, per-key budgets, one default-deny egress policy. Every application you onboard after that inherits the residency controls.
4. Benchmark on your hardware. Run vllm bench serve at your real context lengths and concurrency before you commit to a sizing.
5. Write the PDPL mapping now, not at audit time. The table above is your template, and every claim in it should point at a config file in Git.

If you want this mapped to your organisation rather than to a reference architecture, that is what our AI infrastructure service does: we assess, design, build and run the platform layer, from GPUs and models on your own infrastructure to the gateway, delivered by our team in Dubai. The first conversation is about traffic, classification and numbers, not logos.

https://www.azrty.com/blog/how-to-host-an-llm-privately-in-a-uae-data-center

<a href="https://www.azrty.com/blog/how-to-host-an-llm-privately-in-a-uae-data-center">How to host an LLM privately in a UAE data center</a> (Azrty)