Confidential Computing für LLMs: GPU-TEE, Attestation und der reale Overhead

„Die Daten bleiben in Deutschland." Diesen Satz hat jeder Einkäufer 2026 schon hundertmal gehört. Er beantwortet aber nicht die Frage, die in Ausschreibungen zunehmend wirklich gestellt wird: Wer kann während der Laufzeit auf den Speicher zugreifen, in dem gerade der Prompt eines Vorstandsmitglieds oder eine Patientenakte verarbeitet wird? Der Rechenzentrumsbetreiber mit Root-Rechten auf dem Hypervisor? Der Hersteller über einen Fernwartungszugang? Ein kompromittierter Kernel?

Confidential Computing beantwortet genau diese Frage – nicht mit einer Zusicherung, sondern mit einem kryptografisch prüfbaren Beweis. Für Inferenz auf GPUs ist die Technik seit der Hopper-Generation produktionsreif, seit Blackwell auch für Multi-GPU-Verbünde. Der Preis dafür ist real und lässt sich seit Mitte 2026 endlich beziffern. Dieser Artikel erklärt die Mechanik, ordnet die Messwerte ein und sagt, wann sich der Aufwand für einen mittelständischen Betreiber lohnt – und wann nicht.

Vom Standortversprechen zum Hardware-Beweis

Klassische Souveränitätsargumente arbeiten mit Zusicherungen: ein Standort in der EU, ein deutscher Vertragspartner, eine Auftragsverarbeitungsvereinbarung, ein ISO-27001-Zertifikat. Das sind organisatorische Kontrollen. Sie sind wichtig, aber sie haben eine gemeinsame Eigenschaft: Sie sind nicht zur Laufzeit überprüfbar. Ein Kunde kann nicht feststellen, ob auf dem Host gerade ein Debug-Kernel läuft, ob der Hypervisor gepatcht wurde oder ob jemand einen Speicherabzug der laufenden VM gezogen hat.

Ein Trusted Execution Environment dreht dieses Verhältnis um. Es liefert eine Aussage der Form: „Auf dieser Hardware, mit dieser Firmware-Version, in diesem Konfigurationszustand, läuft ein Speicherbereich, der gegen den Hypervisor und den Host-Administrator abgeschottet ist." Diese Aussage ist mit einem herstellersignierten Schlüssel versehen, der in Silizium verankert ist und nicht ausgelesen werden kann. Sie ist damit ein Beweis, keine Behauptung.

Genau diese Unterscheidung wird 2026 regulatorisch und in Ausschreibungen relevant. Wo Souveränitätsstufen definiert werden, die Schutz vor externer Abschaltbarkeit und vor Zugriff durch den Betreiber verlangen, ist ein GPU-TEE die einzige Antwort, die sich technisch prüfen lässt. Wer nur den Standort nennt, hat argumentativ nichts in der Hand.

Wie ein GPU-TEE funktioniert

Ein GPU-TEE ist kein einzelnes Feature, sondern eine Kette aus drei Bausteinen, die alle vorhanden sein müssen. Fällt einer aus, ist der Schutz wertlos.

Baustein 1: Die vertrauenswürdige VM auf CPU-Seite

Zuerst braucht es eine Confidential VM. Auf Intel-Seite leistet das Trust Domain Extensions (TDX), verfügbar ab den Xeon-Generationen Emerald Rapids und Granite Rapids. Auf AMD-Seite übernimmt SEV-SNP diese Rolle, unterstützt ab EPYC Milan (7xx3), Genoa (9xx4) und Turin. Der Arbeitsspeicher dieser VM wird transparent verschlüsselt, der Hypervisor sieht nur Chiffrat. SEV-SNP fügt zusätzlich Integritätsschutz hinzu, verhindert also nicht nur das Lesen, sondern auch das unbemerkte Manipulieren von Speicherseiten.

Baustein 2: Der verschlüsselte Transferkanal

Zwischen CPU-TEE und GPU liegt PCIe – und PCIe ist per se ein offener Bus. Im CC-Modus werden deshalb alle Daten, die zwischen dem geschützten Hauptspeicher und dem GPU-Speicher wandern, über verschlüsselte Bounce-Buffer geleitet. Jeder Transfer von Modellgewichten, jeder Prompt-Tensor, jedes Ausgabe-Token durchläuft eine Ver- und Entschlüsselung. Das ist die Stelle, an der der Leistungsverlust entsteht – dazu gleich mehr.

Baustein 3: Der geschützte GPU-Kontext

Auf der GPU selbst wird der VRAM-Bereich der vertraulichen Arbeitslast gegen Zugriffe von außen abgeriegelt. Weder der Hypervisor noch andere VMs noch ein Debugger auf dem Host können den Ausführungskontext auslesen. Möglich macht das ein dedizierter Sicherheitsprozessor auf dem GPU-Die, der Firmware misst, Schlüssel verwaltet und Reports signiert. Genau deshalb können Ampere-Karten wie die A100 kein Confidential Computing: Ihnen fehlt dieser Baustein schlicht in der Hardware. Wer eine GPU-Beschaffung mit CC-Anspruch plant, muss mindestens auf Hopper einsteigen.

Der CC-Modus ist dabei kein Laufzeitschalter, sondern eine persistente Firmware-Einstellung. Gesetzt wird sie mit nvidia_gpu_tools.py --set-cc-mode=on (alternativ off oder devtools) samt anschließendem GPU-Reset. Die Einstellung überlebt Reboots und Power-Cycles. Wichtig für die Planung: Confidential Computing und Protected PCIe schließen sich pro GPU gegenseitig aus, man muss sich also pro Karte entscheiden. Und devtools ist ein reiner Debug-Modus ohne vollständigen Schutz – in Produktion hat er nichts verloren.

Remote Attestation praktisch umgesetzt

Verschlüsselung allein nützt wenig, wenn niemand prüft, ob sie überhaupt aktiv ist. Diese Prüfung leistet Remote Attestation, und sie ist der eigentlich interessante Teil der Architektur – weil sie den Beweis erzeugt, den ein Auditor oder ein Kunde sehen will.

Der Ablauf im Betrieb sieht so aus:

1. Report anfordern: Der Sicherheitsprozessor der GPU erzeugt einen signierten Attestation-Report. Er enthält den Firmware-Hash, den CC-Status, die Hardware-Identität der Karte und eine vom Prüfer vorgegebene Nonce, die Replay-Angriffe ausschließt.
2. Report verifizieren: Der Report wird gegen sogenannte Reference Integrity Measurements geprüft – Referenzwerte für Treiber und VBIOS, die der Hersteller veröffentlicht. Laut Anbieterdokumentation läuft das typischerweise über den NVIDIA Remote Attestation Service, der ein signiertes JWT mit Feldern wie driver_rim_validated und vbios_rim_validated zurückliefert, ergänzt um eine OCSP-Zertifikatsprüfung. Der komplette Durchlauf dauert nach Angaben aus der Praxis rund ein bis drei Sekunden pro Instanzstart.
3. Freigabe erteilen: Erst wenn die Prüfung besteht, gibt der Key-Management-Dienst die Schlüssel für die Modellgewichte und die Datenquellen frei. Vorher liegen beide nur verschlüsselt vor.
4. ReadyState setzen: Der entscheidende Mechanismus steht im NVIDIA Deployment Guide unmissverständlich: „The GPU will not accept any work until an enlightened CVM user sets the ReadyState." Ohne bestandene Attestierung nimmt die Karte also schlicht keine Arbeit an. Gesetzt wird der Zustand mit nvidia-smi conf-compute -srs 1, geprüft mit nvidia-smi conf-compute -f, was bei aktivem Schutz CC status: ON ausgibt.
5. Protokollieren: Report-Hash, Zeitstempel, Prüfergebnis und GPU-Seriennummer gehören in ein manipulationsgeschütztes Log. Das ist der Auditnachweis, der in der Prüfung tatsächlich zählt – ein Screenshot einer Konfigurationsseite ist keiner.

Der architektonische Gewinn: Die Freigabe der Modellgewichte ist an einen prüfbaren Maschinenzustand gekoppelt, nicht an eine Rolle oder ein Passwort. Wer die Firmware manipuliert, den CC-Modus abschaltet oder einen Debug-Treiber lädt, bekommt schlicht keine Schlüssel mehr. Das ist ein qualitativ anderes Sicherheitsversprechen als jede Zugriffsmatrix.

Der gemessene Overhead: 11 bis 28 Prozent

Jahrelang kursierte in Anbieter-Blogs die Zahl „2 bis 5 Prozent Overhead". Sie ist auf den offiziellen NVIDIA-Seiten nicht belegbar – dort steht qualitativ „near-native performance". Seit 2026 gibt es endlich unabhängige Messungen, und die zeichnen ein differenzierteres Bild.

Der Preprint arXiv:2607.19353 („Benchmarking Confidential GPU Inference on NVIDIA H100 under Intel TDX", Wei Wang, Abdul Hyee Waqas, Burns Smith) vergleicht Normalbetrieb und CC-Modus auf einer einzelnen NVIDIA H100 80GB in einer Intel-TDX-Confidential-VM. Testaufbau: Google Cloud a3-highgpu-1g, 26 vCPUs, Ubuntu 24.04, NVIDIA-Treiber 580. Getestet wurden Mistral-7B v0.1 (dicht) und Qwen3-30B-A3B (Mixture-of-Experts).

Messgröße	Mistral-7B v0.1	Qwen3-30B-A3B
Time-to-First-Token	279,56 → 340,64 ms	394,61 → 504,35 ms
TTFT-Aufschlag	+21,8 %	+27,8 %
Globaler Durchsatz	1.458,65 → 1.239,26 tok/s	993,80 → 820,31 tok/s
Durchsatzverlust	−17,7 %	−21,1 %
Durchsatz pro Anfrage	28,50 → 25,18 tok/s (−13,2 %)	50,20 → 43,85 tok/s (−14,5 %)

Über die getesteten Nebenläufigkeitsstufen liegt die Durchsatzlücke im Closed-Loop-Betrieb bei 11,5 bis 20,2 Prozent. Absolutwerte aus der HTML-Fassung des Papers sind in der Tabelle mit angegeben, weil sie die relativen Zahlen einordbar machen.

Warum die Spanne allein irreführend wäre

Diese Zahlen gelten für einen sehr spezifischen Aufbau: eine einzelne H100 80GB, Intel TDX, Single-GPU ohne NVLink-Verbund, feste Anfragerate. Sie sind kein Universalwert. Zwei weitere Messreihen kommen zu deutlich niedrigeren Ergebnissen:

• arXiv:2409.03992 (Hopper-Benchmark) misst für typische LLM-Anfragen unter 7 Prozent Durchsatz-Overhead: Llama-3.1-8B 6,85 %, Phi-3-14B-128k 4,58 %, Llama-3.1-70B −0,13 %, also praktisch null. Mit dynamischem Batching sinkt der QPS-Overhead auf 3,22 %. Der Sequenzlängeneffekt beim 8B-Modell: 7,16 % bei bis zu 100 Token, 6,90 % bis 500 Token, 6,65 % bei 501 bis 1.500 Token.
• arXiv:2509.18886 („Confidential LLM Inference: Performance and Cost Across CPU and GPU TEEs", 23.09.2025, Llama2 in 7B/13B/70B) nennt für H100-CC 4 bis 8 Prozent Durchsatzeinbuße, abnehmend mit Batch- und Eingabegröße. Reine CPU-TEEs mit Intel TDX/SGX und AMX bleiben demnach unter 10 Prozent Durchsatz- und 20 Prozent Latenz-Overhead.

Die Erklärung für die Spreizung liefert dieselbe Literatur. Wörtlich aus arXiv:2409.03992: „the main bottleneck lies in the CPU-GPU I/O, particularly when data is exchanged via PCIe" und „TTFT has a higher overhead compared with ITL, indicating the bottleneck is likely introduced by the I/O instead of the computation happening inside the TEE". Der Overhead entsteht also nicht in der Berechnung auf der GPU, sondern beim Hin- und Herschaufeln über den verschlüsselten Bus. Wer wenige Token pro Transfer bewegt, zahlt relativ viel; wer große Batches und lange Sequenzen fährt, amortisiert die Kosten.

Was das für die GPU-Dimensionierung heißt

Die Autoren von arXiv:2607.19353 formulieren eine Planungsempfehlung, die sich direkt in eine Beschaffungsentscheidung übersetzen lässt: „Reserve 15-25% additional throughput capacity as an initial planning heuristic for similar single-H100 deployments, then validate with workload-specific traces." Übersetzt: 15 bis 25 Prozent Reservekapazität als Startwert einplanen, danach mit echten Workload-Traces nachmessen.

Für die Praxis bedeutet das drei Dinge:

• Der Aufschlag gehört ins Angebot, nicht in die Fußnote. Wer eine vertrauliche Inferenzplattform für 1.500 Token pro Sekunde auslegt, plant mit CC realistisch 1.800 bis 1.900 Token pro Sekunde Rohleistung. Bei einem Vier-GPU-Knoten kann das die fünfte Karte bedeuten – oder eben den Wechsel auf die nächstgrößere Kartenklasse.
• Pauschalfaktoren sind gefährlich. Ein MoE-Modell mit kurzen Prompts und ein dichtes 70B-Modell mit 4k-Kontext reagieren völlig unterschiedlich. Messen Sie die Sättigungskurve pro Modell und pro Nebenläufigkeitsstufe, bevor Sie bestellen.
• Batching ist die wirksamste Gegenmaßnahme. Weil der Engpass die I/O ist, drückt jede Maßnahme, die pro Transfer mehr Arbeit bündelt, den relativen Overhead. Dynamisches Batching, längere Kontexte und Continuous Batching in vLLM oder TensorRT-LLM zahlen im CC-Modus doppelt ein.

Zur Einordnung der Latenz: Ein TTFT-Anstieg von 280 auf 341 Millisekunden ist für einen internen Chat-Assistenten in der Regel unbemerkbar. Für eine synchron eingebundene API in einem Bestellprozess mit 200-Millisekunden-SLA ist er dagegen ein K.-o.-Kriterium. Die Entscheidung für oder gegen ein GPU-TEE ist deshalb immer eine Anwendungsfall-Entscheidung, nie eine reine Infrastrukturentscheidung.

Hardware-Auswahl von Hopper bis Rubin

Die maßgebliche Quelle für die Hardwarefrage ist der Deployment Guide for Confidential Computing von NVIDIA (DU-12302-001, Version 7.1, April 2026). Er unterscheidet klar nach Generation und Betriebsmodus:

Generation	Single-GPU-CC	Multi-GPU
Ampere (A100 und älter)	nicht unterstützt	nicht unterstützt
Hopper (H100, H200)	ja	Protected PCIe (NVLink-Verkehr nicht verschlüsselt)
Blackwell (B200)	ja	ja, mit verschlüsseltem NVLink/NVSwitch-Fabric
Blackwell (RTX PRO 6000)	ja	nicht gelistet
Rubin (Vera Rubin NVL72)	ja	Rack-Ebene über NVLink und NVLink-C2C

Die Entwicklungslinie ist damit klar: Die erste Generation auf Hopper bringt Single-GPU-Confidential-Computing plus Protected PCIe für Multi-GPU-Betrieb – wobei der NVLink-Verkehr dort noch nicht verschlüsselt ist. Die zweite Generation auf Blackwell ergänzt echtes Multi-GPU-CC mit verschlüsseltem NVLink- und NVSwitch-Fabric, per Firmware-Release für HGX B200 freigeschaltet. Die dritte Generation dehnt das Konzept mit Rubin auf Rack-Ebene aus; NVIDIA beschreibt Confidential Computing inzwischen ausdrücklich als „now in its third generation with the NVIDIA Rubin architecture" und stellt für Vera Rubin NVL72 „near-unencrypted performance to rack-scale" in Aussicht.

Auf CPU-Seite gilt: Intel mit TDX (Emerald Rapids, Granite Rapids) oder AMD mit SEV-SNP (Milan 7xx3, Genoa 9xx4, Turin). Als getestete Betriebssystemkombination nennt der Guide Host Ubuntu 25.04 oder 25.10 und Guest Ubuntu 24.04 LTS. Wer eine bestehende Plattform auf CC umstellen will, prüft also drei Dinge parallel: GPU-Generation, CPU-Generation und OS-Stand. In der Praxis scheitert es überraschend oft am dritten Punkt.

Zur Verfügbarkeit jenseits eigener Hardware: Google Cloud bietet a3-highgpu-1g als Confidential VM mit Intel TDX und NVIDIA Confidential Computing allgemein verfügbar an, unter anderem in europe-west4-c (Niederlande); Multi-Node-Cluster werden dort nicht unterstützt. Azure führt die NCCadsH100v5-Serie mit AMD EPYC der 4. Generation, SEV-SNP und H100, Guest-Image Ubuntu 22.04, ohne Resizing-Möglichkeit. Für einen Souveränitätsanspruch, der auch den Betreiber ausschließen soll, ist die Cloud-Variante allerdings nur ein Zwischenschritt – der Hyperscaler bleibt Herr über Firmware-Updates und Verfügbarkeit.

Wann sich der Aufwand lohnt

Confidential Computing kostet Geld, Durchsatz und Betriebskomplexität. Es lohnt sich nicht überall. Die entscheidende Frage lautet: Ist der Betreiber der Hardware auch der Eigentümer der Daten?

Klare Fälle für ein GPU-TEE

• Auftragsverarbeitung: Ein Dienstleister betreibt Inferenz für Kundendaten. Das TEE liefert dem Kunden den technischen Nachweis, dass der Dienstleister selbst nicht mitlesen kann – ein Argument, das jede AVV stärkt.
• Konzernverbünde mit unterschiedlichen Rechtsräumen: Eine gemeinsame GPU-Plattform, auf der Tochtergesellschaften mit divergierenden Datenschutzanforderungen arbeiten. Attestierung ersetzt hier die politisch schwierige Diskussion über gegenseitiges Vertrauen.
• KRITIS und regulierte Branchen: Wo Nachweispflichten über die Wirksamkeit technischer Maßnahmen bestehen, ist ein signierter Attestation-Report ein deutlich besseres Prüfartefakt als eine Betriebsdokumentation.
• Colocation und fremde Rechenzentren: Sobald die Hardware physisch nicht in Ihrer Kontrolle steht, ist der Hypervisor-Administrator ein reales Bedrohungsmodell.
• Ausschreibungen mit explizitem Nachweiserfordernis: Wenn ein Vergabekriterium technischen Schutz vor Betreiberzugriff verlangt, gibt es zu Attestierung keine Alternative.

Fälle, in denen es verzichtbar ist

Steht der Server im eigenen, physisch kontrollierten Rack, gehört die Hardware Ihnen, und Ihre Administratoren sind ohnehin die Dateneigentümer – dann adressiert ein GPU-TEE ein Bedrohungsmodell, das Sie gar nicht haben. Der Angreifer, gegen den es schützt, ist der privilegierte Betreiber. Sind Sie das selbst, verlagern Sie mit CC nur Komplexität, ohne Risiko zu senken. In diesem Szenario bringen Netzsegmentierung, konsequente Rechtevergabe, verschlüsselte Datenträger, ein sauberes Backup-Konzept und Audit-Logging pro eingesetztem Euro deutlich mehr. Eine klassische On-Premise-Installation im eigenen Serverraum ist ohne CC nicht automatisch schlechter geschützt – sie hat nur ein anderes Bedrohungsmodell.

Ebenfalls wichtig für die Erwartungshaltung: Ein GPU-TEE schützt die Vertraulichkeit während der Verarbeitung. Es schützt nicht gegen einen Nutzer, der über einen legitimen Zugang zu viele Daten abfragt, nicht gegen Prompt Injection, nicht gegen die Rekonstruktion von Trainingsdaten aus Modellausgaben. Für die letztgenannte Klasse braucht es andere Werkzeuge – etwa Differential Privacy beim Training oder strikte Ausgabefilter. Confidential Computing und Datenminimierung sind komplementär, nicht substituierbar.

Und schließlich der nüchterne Blick auf den Engpass: Der Hauptkostenfaktor bleibt die CPU-GPU-I/O über PCIe. Solange Architekturen Daten in kleinen Portionen über diesen Kanal bewegen, bleibt der Overhead spürbar. Jede Optimierung, die Transfers bündelt oder ganz vermeidet – größere Batches, längere Kontexte, KV-Cache-Wiederverwendung, Prefix-Caching – ist im CC-Modus wertvoller als im Normalbetrieb. Das ist die vielleicht wichtigste Betriebserkenntnis aus den 2026er Messreihen.

Wenn Sie prüfen wollen, ob Ihr Anwendungsfall ein GPU-TEE tatsächlich braucht oder ob eine sauber segmentierte Air-Gapped-Installation die günstigere Antwort ist: Wir rechnen beide Varianten mit Ihren realen Lastprofilen durch, inklusive Messung der Sättigungskurve auf Ihrer Modellauswahl.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primaerquellen geprüft.

1. arXiv 2607.19353
2. arXiv 2607.19353v1
3. export.arxiv.org query
4. arXiv 2409.03992v2
5. arXiv 2509.18886
6. docs.nvidia.com cc deployment guide snp
7. NVIDIA confidential computing
8. docs.cloud.google.com supported configurations
9. learn.microsoft.com gpu options
10. corvex.ai confidential computing meets nvidia hgxtm b200 secure ai without the performance
11. spheron.network confidential gpu computing nvidia tee encrypted vram

Häufig gestellte Fragen zu Confidential Computing

Brauche ich Confidential Computing, wenn der Server im eigenen Keller steht?

Meist nicht. Der Mehrwert entsteht dort, wo der Betreiber der Hardware nicht der Dateneigentümer ist – bei Auftragsverarbeitung, Konzernverbünden, Colocation oder in Ausschreibungen, die einen technischen Nachweis verlangen.

Wie hoch ist der Leistungsverlust wirklich?

Das hängt stark vom Aufbau ab. Eine Einzel-H100 unter Intel TDX mit fester Anfragerate verliert laut arXiv:2607.19353 zwischen 17,7 und 21,1 Prozent globalen Durchsatz, die Time-to-First-Token steigt um 21,8 bis 27,8 Prozent. Zwei andere Messreihen (arXiv:2409.03992 und arXiv:2509.18886) kommen bei größeren Batches und dichter Rechenlast auf unter 7 beziehungsweise 4 bis 8 Prozent. Planen Sie konservativ mit den höheren Werten und messen Sie Ihren eigenen Workload nach.

Welche GPUs unterstützen Confidential Computing?

Laut NVIDIA Deployment Guide for Confidential Computing (DU-12302-001 v7.1, April 2026) unterstützt Hopper Confidential Computing für einzelne GPUs sowie Protected PCIe für Multi-GPU-Betrieb. Blackwell unterstützt Confidential Computing im Single- und Multi-GPU-Modus, explizit gelistet sind B200 und RTX PRO 6000. Ampere und ältere Generationen können es nicht, ihnen fehlt der On-Die-Sicherheitsprozessor. Auf CPU-Seite sind Intel TDX (Emerald Rapids, Granite Rapids) oder AMD SEV-SNP (Milan, Genoa, Turin) Voraussetzung.

Ersetzt Attestation eine Auftragsverarbeitungsvereinbarung?

Nein. Attestation ist ein technischer Nachweis über den Systemzustand und ergänzt die vertragliche Ebene. Die DSGVO-Pflichten zu Auftragsverarbeitung, Zweckbindung und Löschkonzept bleiben bestehen.