Confidential Computing auf der GPU: Voraussetzungen für H200 NVL und RTX PRO 6000 Server Edition

Confidential Computing auf der H200 NVL und der RTX PRO 6000

NVIDIA Confidential Computing auf der GPU unterstützen die H200 NVL und die RTX PRO 6000 Server Edition, beide nur im Single-GPU-Passthrough. NVIDIAs Release Notes zu den Trusted Computing Solutions für R595 TRD1 (RN-12817-001_v02, April 2026) führen „NVIDIA H200NVL“ und die „RTX PRO 6000 Blackwell Server Edition“ unter „Single GPU Passthrough (SPT CC)“, zusammen mit dem Rechenzentrumstreiber 595.58.03. Unter einem Multi-GPU-Modus erscheint keine der beiden Karten. Die Karte arbeitet in einer vertraulichen virtuellen Maschine (Confidential Virtual Machine, CVM) auf einem Host, dessen CPU AMD SEV-SNP oder Intel TDX bereitstellt, und sie nimmt erst Arbeit an, wenn der Gast ihren Bereitschaftszustand setzt, normalerweise nachdem er die Karte per Attestierung geprüft hat.

Confidential Computing schützt Code, Daten und Modellgewichte, während sie verarbeitet werden. NVIDIAs Whitepaper zu Secure AI mit Blackwell- und Hopper-GPUs (August 2025) nennt als Ziel, „den gesamten Anwendungscode und alle Daten in der VM-Instanz davor zu schützen, vom Host gelesen zu werden“; das umfasst das Betriebssystem des Hosts, den Hypervisor und die Personen, die beide administrieren. Die allgemeine Härtung des Servers behandelt unser Leitfaden zum Absichern eines GPU-Servers.

NVIDIAs Seite zu Confidential Containers, aktualisiert am 22. September 2026, nennt „NVIDIA H200“ für Single-GPU-Passthrough, ohne die Edition anzugeben. Die Release Notes nennen die NVL-Karte und führen das Board HGX H200 8-GPU in einer eigenen Zeile. Aus der Familie der RTX PRO 6000 führen die Release Notes nur die Server Edition, luftgekühlt und flüssigkeitsgekühlt; die Workstation Edition und die Max-Q Edition sind nicht aufgeführt.

Voraussetzungen: CPU-TEE, Firmware, Host und Gast

NVIDIAs Confidential Computing Deployment Guide (DU-12302-001_v7.1, April 2026) verlangt Intel-Prozessoren mit TDX und nennt dabei Emerald Rapids und Granite Rapids, oder AMD-Prozessoren mit SEV-SNP und nennt dabei Milan 7xx3, Genoa 9xx4 und Turin. Intel beschreibt TDX als hardwareisolierte virtuelle Maschinen, sogenannte Trust Domains, und laut AMD fügt SEV-SNP „einen starken Schutz der Speicherintegrität hinzu, um bösartige, hypervisorbasierte Angriffe verhindern zu helfen“. Das CPU-TEE schützt den Speicher der VM, und die GPU schützt den Workload auf ihrer Seite und verschlüsselt die Übertragungen zwischen CPU und GPU.

NVIDIA Trusted Computing Solutions Release Notes R595 TRD1 (April 2026), Confidential Computing Deployment Guide v7.1 (April 2026), Confidential Containers Supported Platforms (22. September 2026) und Dokumentation zur Attestierung (6. Oktober 2026), alle abgerufen am 10. Oktober 2026.

Der Guide stellt fest: „Das Setzen der CC-Modi für die GPUs ist nicht möglich, wenn der Host im Secure-Boot-Modus konfiguriert ist“. Der Modus wird daher bei der Inbetriebnahme gesetzt und danach mit nvidia-smi conf-compute -f geprüft, das „CC status: ON“ meldet. Außerdem warnt der Guide, dass wegen der Einschränkungen von Confidential Computing auf der CPU „ein Reboot-Befehl die VM beendet“, was für Wartungs-Runbooks zählt. Die Seite zu Confidential Containers nennt für ihren Kubernetes-Stack AMD Genoa und Milan sowie Intel Emerald Rapids und Granite Rapids; Hosts mit Turin sind also für VMs dokumentiert, auf dieser Seite aber nicht für Container.

Attestierung, bevor die GPU Arbeit annimmt

Der Deployment Guide definiert Attestierung als „den Vorgang, die GPU mit einer Challenge abzufragen, wobei Messwerte von der GPU erfasst und signiert werden und diese Messwerte mit bekannt guten, goldenen Referenzmesswerten verglichen werden.“ Bis das geschehen ist, gilt: „Die GPU nimmt keine Arbeit an, bis ein Nutzer einer enlightened CVM den ReadyState setzt.“ Ein erfolgreicher Attestierungslauf als root setzt den Bereitschaftszustand, und das tut auch nvidia-smi conf-compute -srs 1, das ihn ohne Attestierungslauf setzt. Ein Runbook, das den Bereitschaftszustand per Befehl setzt, überspringt also die Prüfung.

NVIDIA bietet zwei Wege der Prüfung. Der lokale Weg läuft innerhalb der CVM, und die Release Notes verlangen für den Single-GPU-Modus den Local GPU Verifier in Version 2.6.0 oder neuer. NVIDIAs Attestierungs-SDK für C++, das NVIDIA „den Nachfolger der Python-basierten Gast-Tools in nvTrust“ nennt, prüft lokal mit nvattest attest und --verifier local. Der entfernte Weg schickt die Nachweise an NRAS, das NVIDIA als „einen cloudbasierten Dienst“ beschreibt, „der die Integrität und Authentizität von NVIDIA-GPUs und -Plattformen überprüft“, und das sie mit Referenzwerten aus NVIDIAs RIM-Dienst abgleicht. NVIDIA fasst RIM, NRAS und OCSP unter seinen Clouddiensten zusammen, und die Seiten, die wir gelesen haben, sagen nicht, ob die Prüfung auf einem Host ohne Internetzugang funktioniert. Standorte ohne Internetanbindung sollten das zuerst klären.

Die Attestierung kann auch die Freigabe eines Geheimnisses steuern. Unser Leitfaden zum Absichern eines GPU-Servers beschreibt NVIDIAs Referenzarchitektur vom Juni 2026, in der Modellschlüssel nur gegen gültige Attestierungsnachweise freigegeben werden. Für Kubernetes richtet NVIDIAs Dokumentation zu Confidential Containers einen Trustee für die Entwicklung als Attestierungsdienst ein, „nur zur Evaluierung“, und verweist für den Produktivbetrieb auf die Upstream-Dokumentation von Confidential Containers.

Single-GPU-Modus: Auslegung für 500 bis 2.000 Nutzer

Single-GPU-Passthrough gibt jeder vertraulichen VM eine ganze Karte; ein Modell und sein KV-Cache müssen also in 141 GB auf einer H200 NVL oder in 96 GB auf einer RTX PRO 6000 passen. Die Release Notes schreiben, dass in diesem Modus „eine GPU für jede Confidential VM (CVM) durchgereicht werden kann“. Die Seite zu Confidential Containers ergänzt, dass alle GPUs des Hosts im Confidential-Modus sein und „einer virtuellen Maschine für Confidential Containers zugewiesen“ sein müssen; nach unserer Lesart betreibt ein Kubernetes-Knoten in diesem Stack also eine dieser Karten. Für vertrauliche VMs außerhalb von Kubernetes sagen die Dokumente, die wir gelesen haben, nicht, ob sich mehrere Single-GPU-CVMs einen Host teilen dürfen; dieser Leitfaden rechnet daher mit einer Karte je Host.

Das passt zu einem verbreiteten Aufbau für private Assistenten, einer Modellkopie je Karte hinter einem Load Balancer. Unser Leitfaden zu GPU-Servern für Banken und Versicherer rechnet 2.000 Mitarbeiter mit Beispielwerten auf rund 80 Anfragen in Bearbeitung in der Spitze um. Nach seiner Schätzung hält gpt-oss-120b bei 32K mit einem 16-Bit-Cache rund 19 Gespräche auf einer RTX PRO 6000 und rund 55 auf einer H200 NVL.

1. Fünf Hosts mit je einer RTX PRO 6000 Server Edition, jede Karte in einer CVM mit einer Kopie von gpt-oss-120b, halten rund 95 Gespräche, mehr als die Spitze von 80. Ein sechster Host hält die 95, während einer für ein Treiberupdate oder wegen eines Fehlers ausfällt.
2. Zwei Hosts mit je einer H200 NVL halten rund 110, und ein dritter hält die 110, wenn ein Host ausfällt.

Modelle, die mehrere Karten brauchen, etwa DeepSeek-V3.2 auf acht H200 NVL, haben auf diesen Karten keinen dokumentierten Confidential-Modus, und die Release Notes führen keinen Confidential-Modus auf, der die NVLink-Bridges der H200 NVL nutzt. Die Multi-GPU-Modi der Release Notes umfassen nur HGX-Baseboards: die Boards mit B200 und B300 sowie Hopper-Boards mit 8 GPUs im Modus Protected PCIe, in dem „die Kommunikation zwischen GPUs über den NVLink- oder NVSwitch-Interconnect nicht verschlüsselt ist“.

Wir bauen KI-Server nach Auftrag mit Karten vom Typ H200 NVL oder RTX PRO 6000 Server Edition und Prozessoren AMD EPYC oder Intel Xeon. Nennen Sie uns die Modelle, die in vertraulichen VMs laufen müssen, und wie viele Anfragen jedes davon in der Spitze bedient.

Funktionen, die im Confidential-Modus wegfallen

NVIDIAs Secure AI Operations Guide (DU-12609-001_v01, November 2025) stellt fest: „NVIDIA Secure AI unterstützt die folgenden Funktionen nicht“, und führt die Minor-Version-Kompatibilität von CUDA, die Vorwärtskompatibilität von CUDA, GPUDirect RDMA, CBL, Multi-Process Service (MPS) und Multi-Instance GPU (MIG) auf. Die H200 NVL lässt sich sonst in bis zu sieben MIG-Instanzen teilen und die RTX PRO 6000 in bis zu vier, eine Karte im Confidential-Modus bedient aber eine VM als Ganzes. Embedding-, Reranking- und Sprachmodelle, die sich eine per MIG partitionierte Karte teilen würden, laufen auf Servern außerhalb des vertraulichen Bereichs.

Der Deployment Guide setzt den Modus je Karte, während die Seite zu Confidential Containers feststellt: „Nur einen Teil der GPUs eines Knotens für Confidential Computing zu konfigurieren, wird nicht unterstützt.“ In NVIDIAs Kubernetes-Stack laufen vertrauliche Workloads daher auf eigenen Servern. Ohne Vorwärtskompatibilität muss die CUDA-Version in jedem Container zum Gasttreiber passen, und unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt, wie Zweige und CUDA-Releases zusammengehören. Das TRD-Release legt einen validierten Treiber fest, 595.58.03, während der Production Branch zu späteren Builds wie 595.91.07 weitergegangen ist; prüfen Sie deshalb vor dem Update eines vertraulichen Hosts NVIDIAs Kompatibilitätsmatrix für Secure AI, die VBIOS, CUDA-Treiber und Confidential-Computing-Modus je Karte aufführt.

Was Confidential Computing schützt und was nicht

NVIDIA-Whitepaper Secure AI with Blackwell and Hopper GPUs (WP-12554-001_v1.3, August 2025), Confidential Computing Deployment Guide v7.1 und Release Notes R595 TRD1, abgerufen am 10. Oktober 2026.

Das Whitepaper schließt „aufwendige physische Angriffe“ und „Denial-of-Service-Angriffe“ aus und nennt als einzigen Angriff auf die Verfügbarkeit außerhalb des Bedrohungsmodells „einen, bei dem ein bösartiger Hypervisor den Zugriff auf eine CVM verhindert.“ Der Host kann einen vertraulichen Workload also anhalten, aber nicht lesen. Ein Nutzer mit gültigem Zugang, eine Prompt Injection oder ein Fehler im Serving-Code wirkt innerhalb der vertrauenswürdigen VM; Zugriffskontrolle und Protokollierung am Gateway bleiben daher so notwendig wie auf jedem anderen Server. Der DevTools-Modus gibt Leistungszähler „für die Nutzung durch Entwickler“ frei, deshalb laufen Produktivhosts in CC-On.

Auswirkungen auf die Leistung in veröffentlichten Tests

Die NVIDIA-Dokumente, die wir gelesen haben, nennen keine Zahlen zum Overhead. Ein Preprint auf arXiv (2409.03992, eingereicht am 6. September 2024, Fassung vom 5. November 2024) hat eine H100 NVL auf einem Host mit AMD SEV-SNP und eine H200 NVL auf einem Host mit Intel TDX mit vLLM v0.5.4 getestet. Es ließ Llama 3.1 8B, ein 14B-Modell und Llama 3.1 70B in 4 Bit laufen, jeweils auf einer GPU. Sein Abstract meldet für die meisten typischen LLM-Anfragen, dass „der Overhead unter 7 % bleibt“, mit „nahezu null Overhead“ bei größeren Modellen und längeren Sequenzen.

Die Autoren führen die Einbuße vor allem auf „CPU-GPU-Datenübertragungen über PCIe“ zurück, und das Paper nennt einen durchschnittlichen Overhead unter 9 Prozent. Diese Läufe nutzten die Software von 2024, nicht den Treiber R595 oder ein aktuelles vLLM-Release. NVIDIAs Operations Guide ergänzt, dass OpenSSL ab 3.5.0 AVX512 für schnellere Verschlüsselung nutzt und dass Architekturen auf Basis von Bounce Buffern „am meisten profitieren“. Veröffentlichte Zahlen für die RTX PRO 6000 Server Edition im Confidential-Modus haben wir nicht gefunden; planen Sie deshalb einen Testlauf auf dem gelieferten Server, bevor Sie Nutzerzahlen festlegen.

Banken, Gesundheitsdaten und gehostete Server

Confidential Computing betrifft die Frage, ob diejenigen, die den Host betreiben, den Workload lesen können. Diese Frage stellt sich für eine Bank, deren Verschlüsselungsleitlinie nach DORA auch die Verschlüsselung verwendeter Daten umfasst, soweit erforderlich (Delegierte Verordnung (EU) 2024/1774, Artikel 6 Absatz 2 Buchstabe b), für ein Krankenhaus, das Modelle auf Patientenakten betreibt, und für jedes Unternehmen, dessen GPU-Server in einem Rechenzentrum stehen, das andere administrieren. Unser Leitfaden zum privaten LLM in einem EU-Rechenzentrum vergleicht Colocation und dediziertes Hosting, und unser Artikel zu CLOUD Act und EU-Datenresidenz erklärt, dass eine VM auf den Hosts eines Anbieters ohne Confidential Computing von diesen Hosts entschlüsselt wird, während sie läuft. Ob eine bestimmte Vorschrift Confidential Computing verlangt, ist eine rechtliche Bewertung, die der Rechtsabteilung des Unternehmens obliegt.

Wir liefern beide Karten in nach Auftrag gebauten Servern, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Beschreiben Sie im Formular unten, wo die Server stehen werden und wer die Hosts administriert.

Was wir liefern

Wir bauen KI-Server nach Auftrag mit der H200 NVL oder der RTX PRO 6000 Blackwell Server Edition, den beiden Karten unseres Sortiments, die NVIDIA für Confidential Computing führt, auf Plattformen mit AMD EPYC oder Intel Xeon, ausgelegt je Workload. Jeder Server wird montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente und Lieferung in die ganze EU. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime. Das gesamte Kartensortiment, einschließlich L40S und L4 für Workloads außerhalb des vertraulichen Bereichs, steht auf unserer Seite zu professionellen GPUs.

FAQ