Self-Host DeepSeek on Confidential GPUs: TEE Inference 2026

Every time DeepSeek, Llama, or Qwen ships a new release, the same pattern plays out on Hacker News and r/LocalLLaMA. Someone declares: "great, now we can self-host this and finally have private inference, no more sending data to OpenAI." Hundreds of upvotes follow. And the threat model implied by "private" in that sentence is often the wrong one.

I run an infrastructure company that serves regulated buyers, law firms, clinics, fintech compliance teams, and I have answered the same question many times: why "we self-host DeepSeek on our cloud account" is not what their data protection officer actually asked for. This piece is the long-form answer. It is not an anti-open-source piece. I love open weights. They solve a real problem. They just do not solve the one most people think they solve.

The Five Things People Mean By "Self-Hosted"

Before we can argue about whether self-hosting gives you privacy, we have to agree on what self-hosting is. In conversations with buyers I now refuse to use the word without a qualifier. The taxonomy that matters in 2026:

# What "self-hosted" actually means in 2026.
# A short, brutal taxonomy.

LEVELS = {
    "saas":            "OpenAI / Anthropic. The vendor processes your prompts.",
    "byo-cloud":       "vLLM on your cloud account. You rely on the provider's controls, with no proof you can check.",
    "byo-rented-gpu":  "vLLM on a rented H200. The operator's hypervisor can read memory.",
    "self-host":       "Your hardware, your DC. You see memory.",
    "confidential":    "TDX-attested VM. The host's software can't read memory; physical access is out of scope.",
}

# A "self-hosted DeepSeek" on rented GPUs is byo-rented-gpu:
# not the same threat model as either bare metal or confidential.

The uncomfortable observation is that a common "self-hosted" setup is not bare metal in your own data centre. It is byo-rented-gpu: a vLLM container on a rented H200 from a marketplace provider. From a privacy regulator's perspective, you have replaced the model vendor with the machine's operator: someone else can still reach the data.

The Three Trust Boundaries Open Weights Don't Fix

Open-weight models remove the model provider as a trust boundary: you no longer have to trust OpenAI or Anthropic not to log, train against, or silently swap your model. That is a real win. But it leaves three boundaries in place that most teams handwave past:

1. The hypervisor. When your vLLM pod boots inside a hosted VM, the cloud operator's hypervisor sits between your guest kernel and the silicon. On a standard VM it can read every page of guest RAM. Encryption at rest does not apply mid-flight: the moment the OS touches a tokenizer buffer, plaintext lives in physical memory.
2. The privileged operator. Even on bare metal in a colocated cage, the datacenter staff with physical access can extract DRAM via cold boot, attach a debugger to the host, or simply wait for a misconfigured Kubernetes secret. The whole point of renting compute is that someone else has root on the box. Confidential computing removes the software part of this boundary; physical access stays outside its threat model (see the limits below).
3. The GPU PCIe bus. CPU memory might be encrypted (with TDX or SEV-SNP), but without confidential computing on the GPU, the data sent over PCIe to the H200 is plaintext. A bus analyzer on a malicious or seized server reads tokens, KV cache entries, and weights in flight without touching the CPU at all.

The bus threat is the one NVIDIA's own white paper describes: protocol analyzers "physically connected between the host and the target device, quietly recording all activity". None of these boundaries is fixed by upgrading from Llama-3.1 to Llama-3.3, by switching from vLLM to SGLang, or by adding TLS between your services.

What Actually Fixes It

The combination that closes the software side of all three is unromantically named: Intel TDX + NVIDIA Confidential Computing on Hopper/Blackwell. In English:

• Intel TDX creates a trust domain, a VM whose private memory is encrypted with "a CPU-generated, unique, and ephemeral AES-XTS 128-bit key" that software on the host cannot read (Intel white paper). The hypervisor, the host kernel and the cloud operator see ciphertext.
• NVIDIA Confidential Computing covers the GPU. The NVIDIA driver in the VM and the GPU encrypt everything that crosses PCIe, with 256-bit AES-GCM, through bounce buffers that hold only ciphertext. Inside the GPU, "hardware access controls protect plaintext data; GPU memory encryption is not the protection mechanism" (NVIDIA threat model). The GPU proves its state with its own attestation, separate from the TDX quote.
• Not TEE-IO. Intel's trusted device I/O, with PCIe TDISP and IDE, is a different mechanism, and our VMs do not use it: what it would change.

From the application layer, little changes. NVIDIA says CUDA applications should run without changes once the system is set up and the GPU attested, so vLLM, SGLang, TGI and TensorRT-LLM generally run as they are inside the TDX guest. We have seen one exception, vLLM's V2 model runner on our H100 VM, with a one-variable workaround (our vLLM write-up).

Deploying DeepSeek-V3.2 Behind That Stack

Two paths exist. You can build it yourself: rent a TDX-enabled host, install Intel's DCAP attestation libraries, configure the kernel command line, set up quote verification, and check that the GPU firmware matches what NVIDIA shipped. It is real work.

Or you can do it in a handful of commands:

# Bring up an open-weights model inside an attested TDX Confidential VM, vLLM-style.
# The host's software cannot read the VM's memory; NVIDIA's confidential mode encrypts
# transfers to the GPU and keeps GPU memory off-limits to the host (access controls).

# 1. Deploy (register an ed25519 key first with POST /api/volt/ssh-keys). One hour is
#    charged upfront, the unused part is refunded on release.
#    Live SKUs: GET https://voltagegpu.com/api/confidential/vm/tiers
curl -sSf -X POST https://voltagegpu.com/api/confidential/vm/deploy \
  -H "Authorization: Bearer $VOLTAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"vllm-tee","resource_name":"h200-small","hardstop_hours":1}'

# 2. SSH in (poll GET /api/volt/pods until ssh_ready), start your own vLLM there, then
#    generate both proofs on a challenge you choose BEFORE you point your traffic at it.
#    The image ships without pip: install it first.
curl -sS https://bootstrap.pypa.io/get-pip.py | python3 - --user --break-system-packages
python3 -m pip install --user --break-system-packages "voltage-verify[attest]>=0.2.1"
export PATH=$HOME/.local/bin:$PATH
voltage-verify manifest --challenge auto -o manifest.json
sudo env PATH=$PATH PYTHONPATH=$(python3 -c 'import site;print(site.getusersitepackages())') \
  voltage-verify attest --manifest manifest.json --mode single-gpu -o bundle.json

# 3. On your own machine, verify against Intel and NVIDIA, not against us.
pip install "voltage-verify>=0.2.1"
voltage-verify verify bundle.json --challenge <the challenge printed above>

If you don't need your own server, the OpenAI-compatible VoltageGPU Inference API serves deepseek-ai/DeepSeek-V3.2-TEE among its models (our pricing feed listed 10 TEE models on 27 October 2026). The models run in Intel TDX trust domains at our inference provider. Our relay forwards your request: it records the model and the token counts for billing, and sees the request in transit, so we do not claim we cannot see it.

To check the hardware, GET /v1/attestation?model=<model>&nonce=<64 hex characters> returns, for each instance serving the model, an Intel TDX quote and the NVIDIA GPU evidence, bound to the nonce you chose. That shows the instances are genuine TDX guests with GPUs in confidential mode. It does not show that a given answer came from one of them, or which code they run.

When True Bare-Metal Self-Host Is Still The Right Answer

I am not arguing nobody should self-host. There are real cases where bare-metal in your own DC is the correct answer:

• Air-gapped national-security workloads where any external connection is forbidden by classification rules.
• Enormous, steady-state workloads where you have already amortized the GPU capex and operations cost, and any confidential-computing overhead would matter at your scale.
• Accelerators that confidential computing does not cover, such as some FPGA pipelines.

For other regulated AI workloads, legal, healthcare, fintech, HR-tech, compliance, renting confidential capacity spares you building the attestation chain yourself, and produces evidence you can check.

What It Costs in Performance

We have not measured the overhead of confidential computing on our VMs, so here is what NVIDIA publishes. In its August 2023 description of the H100, CPU-to-GPU bandwidth in confidential mode is "limited by CPU encryption performance, which we currently measure at roughly 4 GBytes/sec", while the GPU's compute engines and memory bandwidth work as in non-confidential mode (NVIDIA blog).

In practice, the cost falls on what moves between the CPU and the GPU: loading weights at startup, large batches, offloaded KV cache. Generation that stays on the GPU is not affected by NVIDIA's account. Measure your own workload before you rely on a number, including ours: we will publish one only once we have measured it.

What This Doesn't Solve (Pratfall, Honest Edition)

Confidential inference is the floor, not the ceiling. The limits:

• It does not turn a bad model into a safe one. If DeepSeek decides to produce a confabulated medical recommendation, encrypting the memory does not change the output. Model evals and human oversight remain your job.
• It does not cover physical attacks. Intel writes that TDX "does not defend against replay of memory through physical attacks", and NVIDIA puts invasive probing of the GPU package out of scope. In September 2026 researchers showed such an attack on confidential VMs: what DDRop means.
• Side-channel attacks are still a research frontier. Speculative execution, power analysis, and microarchitectural timing attacks against confidential enclaves are an active academic field. Intel and NVIDIA push patches; the threat model is "not perfect" rather than "solved." For nation-state-grade adversaries, layered defense remains necessary.
• Open-weight licensing still applies. DeepSeek-V3.2 and Llama-3.3 each have their own license terms (commercial use clauses, derivative restrictions). TDX does not waive those. Read the license.

Who Should Read This Twice

• Platform engineers and ML infra leads who built a self-hosted LLM gateway in 2024-2025 and now have to defend it against an internal audit.
• Security engineers writing the AI threat model section of their ISO 42001 or SOC 2 documentation.
• Founders of vertical AI products in regulated sectors who keep getting asked "can the model provider see the data?" in vendor onboarding.

Two starting points if you want to go deeper: our Intel TDX deep-dive for the architecture, and the EU AI Act August 2026 piece for the regulatory side.

FAQ