阿聯酋 AI 推理的 GPU TEE 機密運算指南

Residency says where your data sits. Confidential computing says who can read it while the model runs. Inference on a rented or colocated GPU in a UAE data centre gives you the first and not the second. Here is what a GPU TEE protects, what it costs, and what to demand from a vendor.

If a vendor tells you "your data stays in-country", they are answering a question about geography. They are not answering the question your risk register actually asks: who can see the data while it is being used? Confidential computing for AI inference in the UAE is the answer to that second question. It runs the model inside a hardware trusted execution environment (TEE) on the GPU itself, so the data centre operator, their engineers and anyone with hypervisor or management-plane access cannot read your prompts, your retrieval context or your model weights while they are in use. Between the prompt arriving and the answer leaving, that data otherwise sits in plaintext in server RAM and GPU memory. On a rented or colocated GPU in a UAE data centre, it is all in principle readable by the host.

The GPU TEE is the technology that closes this gap, and it is now practical: NVIDIA has shipped it since the H100, the tooling is public, and the measured overhead for inference sits in the low single digits on a well-configured stack. This article sets out what a GPU TEE protects, the stack to demand from a vendor, the performance numbers to budget for, and the answers that should already be in your procurement and due-diligence packs.

What does confidential computing for AI inference mean in the UAE?

Residency answers where. Confidentiality answers who.

Data residency is about where data is stored and processed. Confidentiality is about which people and processes can observe data in use. They are different controls, and in the UAE the second is now the harder of the two.

The regulatory backdrop pushes regulated organisations towards in-country processing but says much less about in-use confidentiality:

• UAE Central Bank outsourcing rules require banks to keep regulated data, including the master record, within the UAE, and set due-diligence expectations covering data centre location, encryption and access control. Health-sector rules point the same way.
• DIFC Regulation 10, part of the Data Protection Regulations enacted on 1 September 2023, governs the processing of personal data through autonomous and semi-autonomous systems, meaning AI. It drives an AI data protection impact assessment, a risk register and certification for high-risk processing, with enforcement and audit expectations running through 2026 (summary of the current enforcement position).
• In Saudi Arabia, SDAIA's personal data protection regime and the Regulation on Personal Data Transfer Outside the Kingdom make cross-border movement of personal data the exception rather than the rule.

None of this prevents the operator of your in-country GPU from reading your prompts. An AI DPIA or a Central Bank outsourcing assessment that stops at "the data centre is in Dubai" has answered the easy half of the question. When an auditor or counterparty asks "who inside the hosting arrangement can access this data, and how do you know?", residency alone has no answer. That is the gap a TEE fills.

What does a GPU TEE actually protect?

The NVIDIA H100 was the first GPU with hardware confidential computing, and the feature now spans the Hopper and Blackwell generations. When the GPU boots in CC-On mode, a chain of trust is established: the GPU firmware performs a secure, measured boot from an on-die hardware root of trust; the driver running inside a CPU confidential VM establishes an SPDM session with the GPU; and the GPU produces a cryptographically signed attestation report that you verify before trusting it. All data crossing the PCIe bus between the CPU TEE and the GPU passes through encrypted bounce buffers, and command buffers and kernels are encrypted and signed in transit. CUDA applications run unchanged, as NVIDIA documents in its H100 confidential computing technical blog.

Two details decide whether the control is real:

The CPU TEE is not optional. A GPU in CC mode is only meaningful when the driver runs inside a CPU confidential VM: Intel TDX (Emerald Rapids or Granite Rapids) or AMD SEV-SNP (Milan, Genoa or Turin). The NVIDIA Confidential Computing Deployment Guide (v7.1, April 2026) lists the supported combinations, including Blackwell single and multi-GPU modes and Hopper multi-GPU Protected PCIe mode. A vendor offering "GPU confidential computing" without a CPU TEE is offering the shell without the contents: prompts are still plaintext in host memory.

CC mode is a state you can check. Inside the confidential VM it is queryable:

nvidia-smi conf-compute -f    # CC status: ON
nvidia-smi conf-compute -e    # CC Environment: PRODUCTION
nvidia-smi conf-compute -q    # CPU CC Capabilities: AMD SEV-SNP or INTEL TDX

Protected: prompts, retrieval context, KV cache and model weights while in use, against the host, the hypervisor and anyone with physical or administrative access outside the measured TCB. Not protected: the GPU's HBM, which NVIDIA does not encrypt because it is deemed secure against everyday physical attack tools, and network transit, which remains your own TLS concern. The GPU also refuses work until attestation has passed and the ready state is set, which is the enforcement hook that makes the architecture auditable.

What should you ask a vendor for? Composite attestation, then gated key release

Attestation is where most deployments quietly fail. The pattern that actually delivers confidentiality has two gates, and both must be verified, not assumed.

Gate 1: composite attestation of CPU and GPU. The CPU TEE proves it is a genuine SEV-SNP or TDX confidential VM with the expected firmware. The GPU proves it is genuine NVIDIA silicon in CC mode with approved driver and VBIOS versions. NVIDIA's Remote Attestation Service (NRAS) is the primary verifier for the GPU side, with a local verifier for air-gapped deployments. The attestation quick start shows how little code this takes:

from nv_attestation_sdk import attestation

client = attestation.Attestation()
client.add_verifier(attestation.Devices.GPU,
                    attestation.Environment.REMOTE,
                    "https://nras.attestation.nvidia.com/v4/attest/gpu", "")
result = client.attest(client.get_evidence())
token = client.get_token()  # JWT with per-GPU claims

The token's claims are concrete and pin-able: driver version, VBIOS version, secure boot state, certificate revocation status. Your release policy should pin the ones you care about, so a driver upgrade changes the measurement and fails closed until you approve it.

Gate 2: attestation-gated key release. Model weights ship encrypted at rest (AES-256-GCM is the standard pattern), and the data encryption key is wrapped by a key encryption key held in an HSM-backed KMS. The KMS releases the key only to a workload that presents a passing attestation. Microsoft's confidential LLM inferencing tutorial documents the full build on an AMD SEV-SNP VM with an H100, including the Key Vault release policy:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://sharedeus2.eus2.attest.azure.net",
      "allOf": [
        { "claim": "x-ms-isolation-tee.x-ms-attestation-type", "equals": "sevsnpvm" },
        { "claim": "x-ms-isolation-tee.x-ms-compliance-status", "equals": "azure-compliant-cvm" }
      ]
    }
  ]
}

In that pattern the CPU evidence gates the KMS, and the GPU is verified in-guest before any key is used. The composition matters: no verified CPU measurements, no key; no verified GPU state, no model. A vendor that cannot walk you through both gates, with the evidence artefacts, is selling a feature flag, not a control.

What does confidential inference cost in performance?

The honest performance story is two-sided. Inside the GPU nothing changes: raw compute and HBM bandwidth are at par with non-confidential mode. The cost sits on the interconnect. NVIDIA measures the encrypted CPU to GPU path at roughly 4 GB/s, limited by CPU encryption performance, so workloads that are compute-heavy relative to data movement amortise well, while workloads that hammer host-to-device transfers or serve short, prefill-heavy exchanges pay more. NVIDIA's own published CC-mode overhead for LLM inference is in the low single digits, roughly 2 to 5%. Independent H100 measurements give you the range to plan against:

Three operational readings fall out of these numbers:

1. Sizing, not feasibility, is the issue. The TDX study's own guidance is to reserve 15 to 25% extra throughput capacity on Hopper-class single-GPU deployments and validate with your own traces, because the penalty is stable but the saturation knee arrives earlier: Qwen3-30B-A3B saturated at concurrency 32 in CC mode versus 40 without it.
2. Decode-heavy long-context serving degrades differently from raw compute. Inter-token latency moves a few percent; it is time to first token and aggregate prefill throughput that absorb the encrypted interconnect. Short, prefill-heavy exchanges are the worst case, and longer decode phases amortise the cost.
3. A datasheet percentage is not your number. Published low-single-digit overheads hold when the serving stack is tuned for CC mode. Measure TTFT, throughput and the saturation concurrency on your own prompt lengths and concurrency mix before you size the estate.

Worked example: a long-context assistant on colocated H100s in Dubai

Take a Dubai-based insurer deploying a claims-summarisation assistant: a Qwen3-30B-class model on a colocated 8-GPU H100 node, prompts of a few thousand tokens of policy and claims text, outputs around a thousand tokens. The colocation provider's staff hold host access, which is precisely the threat a TEE addresses, and the model weights are commercially licensed, so they are encrypted at rest with the data encryption key wrapped in the insurer's HSM.

Sizing, using the TDX benchmark's single-GPU figures scaled across the node:

• Non-confidential baseline: about 994 tokens/s aggregate per GPU, so roughly 7,950 tokens/s for the node.
• CC mode: about 820 tokens/s per GPU, so roughly 6,560 tokens/s for the node.
• Peak-hour demand of 7,000 tokens/s fits the non-confidential node and does not fit the confidential node.

The insurer has three options, all arithmetic on the same 21% gap: run a second node during peak windows (more GPU-hours, but no queueing), accept that peak concurrency caps earlier (the knee at 32 instead of 40), or trim context length. None of them is a reason to skip confidentiality. All of them belong in the capacity plan before the pilot, not after the first month of queueing complaints.

Latency is the smaller problem: at the study's 5 requests/s, TTFT rises from roughly 395 ms to roughly 505 ms, which no internal user will notice. The operational surprises are elsewhere. The attestation handshake is a one-time startup event, so it adds nothing to per-request latency, but a confidential VM cannot simply reboot: the deployment guide notes that rebooting terminates the VM under CPU CC limitations, and the GPU scrubs its state on reset. Restarts are measured in minutes, so autoscaling and maintenance windows need designing around that. Driver persistence mode must be enabled or the SPDM session tears down and the GPU needs a full reset before it will work again. And every driver or VBIOS upgrade changes the attested measurements, so your release policy must be re-pinned deliberately, in a change window, rather than drifting with apt upgrade.

Finally, confidentiality only holds end to end: the application inside the enclave must not be quietly calling a third-party moderation, guardrail or embedding API, because that exports every prompt out of the TEE in plaintext. The enclave boundary is where your architecture review starts.

What do GPU TEEs not fix?

Two further limits deserve plain statement. First, model weight licensing is a contract question a TEE does not touch: running a model inside an enclave does not create rights the licence does not grant, and some provider licences restrict deployment context, tenancy or geography regardless of the hardware. Second, attestation introduces a dependency you must own: NRAS is an online NVIDIA service, with local verification available for air-gapped estates, and the revocation and reference-manifest data behind local verification can go stale. If your threat model includes a fully offline deployment, test that path specifically.

Which questions belong in the procurement pack?

When a provider claims "confidential AI" or "your data never leaves your control", these questions separate the two tiers:

What to do next

1. Split your AI estate into two tiers. Tier one: workloads where residency is sufficient. Tier two: workloads where prompts or weights are confidential (customer data, regulated data, proprietary models), which require a CPU TEE plus GPU CC mode, composite attestation and attestation-gated key release. Write the standard once and apply it in due diligence.
2. Benchmark before you size. Reserve 15 to 25% extra capacity on Hopper-class hardware as a planning heuristic, then measure TTFT and the saturation knee on your own prompt lengths. Budget for the interconnect, not for the compute.
3. Put the enclave in the compliance paperwork. An attestation report is exactly the kind of artefact an AI DPIA, a risk register or an outsourcing due-diligence file under DIFC Regulation 10 or Central Bank expectations is short of today. "We can show the enclave, and here is the evidence" is becoming a procurement differentiator in this region.
4. Review the application, not just the platform. Audit what the code inside the TEE calls out to, and pin TCB versions in a managed change process.

At Azrty we design, build and run this kind of AI infrastructure for organisations in the UAE: the GPU platform, the gateway in front of every model, and the access and control layer around both (AI infrastructure). For teams that need agents and models running on their own GPU servers, each workload in its own isolated space and all managed from one console, our Kuvryn AI platform is built for that shape of deployment. We are based in Dubai, and our own team does the deployment and the support.

If you take one thing from this article: next time a vendor says your data stays in-country, ask them who can see it while it is in use, and ask for the attestation evidence. The hardware can now answer that question. Whether your vendor's stack does is a different matter, and it is entirely checkable.

Originally published on Azrty.