H200 GPU: Architektur, Leistung und Leitfaden für Cloud-Bereitstellung

H200 GPU: Architektur, Leistung und Leitfaden für Cloud-Bereitstellung

Die NVIDIA H200 GPU ist ein Rechenzentrumsbeschleuniger der Hopper-Generation, dessen entscheidendes Bereitstellungsmerkmal der Speicher ist: 141 GB HBM3e und 4,8 TB/s Speicherbandbreite pro GPU. Das verändert die Planung für Inferenz mit langem Kontext, große Batches und speichergebundene HPC-Workloads – macht Kapazitätsplanung oder Cloud-Validierung jedoch nicht überflüssig.

Dieser Leitfaden erläutert, was die H200 GPU ist, worin sich H200 SXM und H200 NVL unterscheiden, wann sie für einen Workload geeignet ist und wie Sie eine Cloud-Bereitstellung validieren, bevor Sie sich für eine größere Flotte entscheiden. Er vermeidet bewusst volatile Momentaufnahmen von Anbieterpreisen. Verwenden Sie die folgende Checkliste mit der Ihnen verfügbaren exakten Region, dem Maschinentyp, der Topologie und dem Vertrag.

Die Kurzantwort

Wählen Sie eine H200 GPU, wenn Ihr Workload durch GPU-Speicherkapazität oder -bandbreite begrenzt ist und Sie das umgebende System validieren können – nicht nur den Beschleuniger. Für einen Modellserver mit einer einzelnen GPU bedeutet das, nachzuweisen, dass Modellgewichte, Runtime-Workspace und KV-Cache mit ausreichender Reserve hineinpassen. Für Training oder Serving mit mehreren GPUs bedeutet es, das GPU-zu-GPU-Fabric und gegebenenfalls das Netzwerk zwischen den Knoten zu validieren.

Die H200 GPU ist kein universelles Upgrade. Wenn Anfragen kurz sind, Batch-Größen gering sind oder der Workload durch CPU, Speicher oder Netzwerk begrenzt wird, verändert ihr zusätzlicher Speicher möglicherweise nicht das entscheidende Ergebnis. Beginnen Sie mit einer Workload-Beschreibung und testen Sie anschließend einen repräsentativen Trace.

H200-GPU-Spezifikationen: Was Ihren Bereitstellungsplan verändert

NVIDIA führt die H200 als GPU mit Hopper-Architektur, 141 GB HBM3e-Speicher und 4,8 TB/s Speicherbandbreite auf. Sie ist als H200 SXM und H200 NVL verfügbar, mit denselben zentralen Speicherwerten, aber unterschiedlichen Formfaktoren, Leistungsrahmen und Skalierungsoptionen. Die von NVIDIA veröffentlichten Spitzenwerte der Tensor Cores sind zum Vergleich von Produktkonfigurationen nützlich, stellen jedoch keine Zusage für den Anwendungsdurchsatz dar: Die Werte enthalten angegebene Testbedingungen und Annahmen zur Sparsity. Prüfen Sie die aktuellen H200-Produktspezifikationen, bevor Sie eine SKU auswählen.

Dies sind vom Anbieter veröffentlichte Angaben, die NVIDIA auf seiner Produktseite als vorläufig kennzeichnet. Behandeln Sie sie als Konfigurationsgrundlage und überprüfen Sie dann die exakte Cloud-SKU und ihre Topologie in der Umgebung, in der Sie arbeiten werden.

Warum HBM3e für LLM-Inferenz wichtig ist

Beim LLM-Serving wird GPU-Speicher nicht nur durch Modellgewichte belegt. Eine nützliche Kapazitätsgleichung für eine erste Abschätzung lautet:

required GPU memory = weights + runtime workspace + KV cache at p95 context and concurrency + operational headroom

Die H200 GPU kann attraktiv sein, wenn der KV-Cache zum begrenzenden Faktor wird: Längere Prompts, mehr gleichzeitige Sequenzen oder ein größerer Batch können ihn jeweils vergrößern. Der zusätzliche HBM beseitigt das Risiko eines Out-of-Memory-Fehlers nicht, da Cache-Richtlinien, Allocator-Verhalten, Quantisierung, Modellparallelität und Traffic-Muster weiterhin relevant sind. Für Bereitstellungen mit langem Kontext sollten Sie diese Entscheidung mit einem Plan für KV-Cache-Offloading und -Tiering verbinden, statt anzunehmen, dass mehr lokaler Speicher die vollständige Lösung ist.

H200 SXM oder H200 NVL: Wählen Sie die Topologie, nicht nur die Karte

Der Formfaktor ist eine Bereitstellungsentscheidung.

• H200 SXM eignet sich für HGX-H200- und NVIDIA-zertifizierte Systemdesigns mit vier oder acht GPUs. Sie ist in der Regel der richtige Ausgangspunkt, wenn ein Workload ein eng gekoppeltes Multi-GPU-System benötigt und die Anwendung häufig Daten zwischen GPUs austauscht.
• H200 NVL ist ein luftgekühltes PCIe-Design mit Dual-Slot. NVIDIA führt Konfigurationen mit 2- oder 4-Wege-NVLink-Bridge auf, während Partner- und zertifizierte Systeme bis zu acht GPUs enthalten können. Schließen Sie nicht daraus, dass jeder Server mit acht GPUs denselben direkten GPU-zu-GPU-Pfad bietet; prüfen Sie die tatsächliche Topologie und benchmarken Sie die kollektiven Operationen, die Ihre Runtime verwendet.
• Unabhängige Replikate benötigen nicht automatisch das am engsten gekoppelte Fabric. Wenn jedes Replikat seine eigenen Anfragen bedient, priorisieren Sie Kapazität, Verfügbarkeit, Host-Ressourcen und eine klare Scheduling-Grenze, bevor Sie für eine Topologie bezahlen, die der Workload nicht nutzt.

NVIDIA dokumentiert die H200-MIG-Kapazität, aber behandeln Sie die Modi zur GPU-Freigabe nicht als austauschbar. In Kubernetes erstellt MIG hardwareisolierte GPU-Instanzen, während Time Slicing Arbeit verschachtelt und keine Speicher- oder Fehlerisolation zwischen Replikaten bietet. Der Sharing-Leitfaden für GPU Operator erläutert den Kompromiss und seine Monitoring-Grenzen.

Für einen ausführlicheren Kaufvergleich siehe H200 vs. H100. Dieser Vergleich ist für die Entscheidung hilfreich; diese Seite ist der Bereitstellungsleitfaden, sobald H200 der Kandidat ist.

Wann eine H200 GPU die richtige Wahl ist

Eine H200 GPU ist in der Regel einen Test wert, wenn eine dieser Einschränkungen in der Produktion tatsächlich besteht:

1. Speichergebundene LLM-Inferenz. Ihre p95-Kontextlänge oder Parallelität schöpft das praktische Speicherbudget aus, bevor die Rechenleistung vollständig genutzt wird.
2. Bandbreitensensitive KI oder HPC. Das Profiling zeigt, dass der Job wesentlich Zeit damit verbringt, auf Speicherbewegungen zu warten, statt einfach die Tensor-Core-Rechenleistung auszulasten.
3. Ein größerer arbeitsspeicherresidenter Working Set. Sie benötigen mehr Platz für ein Modell, Retrieval-Kontext, Batch, Cache oder eine wissenschaftliche Datenstruktur, ohne sofort eine weitere GPU hinzuzufügen.
4. Eng gekoppelte Multi-GPU-Workloads. Sie können ein System im H200-SXM/HGX-Stil nutzen und haben Hinweise darauf, dass die Anwendung von dessen Fabric profitiert.
5. Eine Anforderung an kontrollierte Partitionierung. Sie haben einen klaren Grund, die aufgeführten MIG-Konfigurationen zu verwenden, sowie ein dazu passendes Scheduler- und Kostenverrechnungsmodell.

Treffen Sie die Auswahl einer H200 GPU nicht allein anhand der Modellparameteranzahl. Eine Parameteranzahl sagt wenig über Präzision, Runtime-Workspace, KV-Cache-Richtlinie, maximalen Kontext, Batch-Form und Verfügbarkeitsreserve aus. Sie sagt auch nichts über den Engpass bei Host-CPU, RAM, Speicher oder Netzwerk aus, der einen Cloud-Workload dominieren kann.

Erstellen Sie einen H200-Kapazitätsplan, bevor Sie eine Cloud-GPU mieten

Verwenden Sie diesen einseitigen Überblick, bevor Sie eine Instanz erstellen oder einen Cluster-Node-Pool anfordern.

Der Wert dieses Überblicks liegt darin, dass eine schlechte Eignung früh sichtbar wird. Beispielsweise kann eine Ein-GPU-Konfiguration aufgrund von p95-Kontext- und Cache-Druck scheitern, selbst wenn ein synthetischer Test mit kurzen Prompts hervorragend aussieht. Umgekehrt kann eine Multi-GPU-Konfiguration unterperformen, wenn sie über eine Fabric verteilt ist, die von der Runtime nicht effizient genutzt wird.

Cloud-Bereitstellung: ein gestaffeltes H200-GPU-Runbook

1. Die genaue Cloud-Konfiguration bestätigen

Fragen Sie den Anbieter oder das Plattformteam nach dem genauen Beschleunigerformfaktor, der GPU-Anzahl, der CPU/RAM-Zuweisung, lokalem und persistentem Speicher, Netzwerkeigenschaften und der GPU-Topologie. Halten Sie die Antwort im Bereitstellungsticket fest. „H200“ allein reicht nicht als Information für eine Multi-GPU-Leistungserwartung aus.

Validieren Sie diese Details vor der Kapazitätsreservierung in einem kurzlebigen Pilotprojekt:

• H200 SXM oder H200 NVL
• GPU-Anzahl und die Ausgabe von nvidia-smi topo -m
• ob die Instanz exklusiv, partitioniert oder zeitlich aufgeteilt ist
• Treiber-, CUDA-, Container-Runtime- und Framework-Versionen
• verfügbarer Host-RAM, CPU-Kerne, Speicherdurchsatz und Netzwerkpfad
• Zeiten für Image-Pull, Modelldownload, Checkpoint und Neustart

2. Einen unterstützten Softwarepfad installieren

Für eine Kubernetes-Bereitstellung kann NVIDIA’s GPU Operator den NVIDIA-Treiber, das Container Toolkit, das Device Plugin, GPU Feature Discovery, DCGM-basiertes Monitoring und zugehörige Komponenten verwalten. Der offizielle Installationsleitfaden weist auf die Konsistenz des Node-Betriebssystems hin, wenn der Operator Treiber verwaltet, sowie auf Voraussetzungen für Container-Runtime und Namespace-Sicherheit. Befolgen Sie die aktuelle Installationsanleitung für den GPU Operator, anstatt eine veraltete Chart-Version zu kopieren.

Eine Erstinstallation folgt diesem Muster; ersetzen Sie die Version durch eine, die Sie anhand Ihrer Cluster- und Treiberrichtlinie validiert haben:

helm install --wait gpu-operator \
  -n gpu-operator --create-namespace \
  oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
  --version=<validated-operator-version>

Validieren Sie nach der Installation die Operator-Pods und den Status von ClusterPolicy, bevor Sie den ersten Workload übermitteln. Der Operator-Leitfaden zeigt auch, wie Sie bestätigen können, dass Nodes eine zuweisbare Ressource nvidia.com/gpu melden.

3. Scheduling explizit machen

Beginnen Sie mit einer exklusiven Anforderung für eine vollständige GPU, sofern Sie nicht bewusst für einen Sharing-Modus konzipiert haben:

resources:
  limits:
    nvidia.com/gpu: 1

Verwenden Sie ein plattformverwaltetes Node-Pool-Label oder einen Cloud-Selector, um verifizierte H200-Nodes anzusteuern; kodieren Sie kein Produktlabel aus einem Beispielcluster fest. Kubernetes dokumentiert das GPU-Scheduling über Device Plugins und erweiterte Ressourcen, einschließlich des obigen Musters für Ressourcenlimits. Lesen Sie die Kubernetes-Dokumentation zum GPU-Scheduling für den aktuellen Vertrag.

Wenn Sie MIG aktivieren, drainen oder cordonen Sie zunächst die betreffenden Nodes. NVIDIA weist darauf hin, dass Änderungen des MIG-Modus oder der Geometrie erfordern, dass sich keine Benutzer-Workloads auf den GPUs befinden, und in einigen Cloud-Umgebungen einen Neustart erfordern können. Prüfen Sie das MIG-Verfahren des GPU Operator, bevor Sie Partitionsänderungen als Online-Vorgang behandeln.

4. Einen einfachen Workload, dann Ihren tatsächlichen Workload nachweisen

Führen Sie drei Gates in dieser Reihenfolge aus:

1. Plattform-Gate: Treiber und CUDA werden geladen; der Scheduler erkennt die erwartete Anzahl an GPUs; der Container kann einen CUDA-Kontext erstellen.
2. Fabric-Gate: Die Topologie entspricht dem vorgesehenen Design; Multi-GPU-Runtimes werden initialisiert und schließen einen repräsentativen Collective-Test ab.
3. Anwendungs-Gate: Eine Wiedergabe repräsentativer Prompts, Batch-Größen, Kontextlängen, Checkpoint-Muster oder Simulationseingaben erreicht das erforderliche Latenz-, Durchsatz- und Fehlerziel.

Das dritte Gate ist das Entscheidungsgate. Ein generischer Benchmark kann Ihnen zeigen, dass die GPU funktioniert; er kann Ihnen nicht sagen, ob Ihre Traffic-Verteilung, Ihr Model-Server und Ihre Cache-Richtlinie funktionieren.

Leistung vor der Skalierung validieren

Erstellen Sie Abnahmetests rund um den erwarteten Engpass und prüfen Sie dann das Ergebnis, das die Annahme widerlegen kann.

NVIDIA DCGM trennt passive Zustandsüberwachung von aktiver Diagnose. Seine Diagnose-Workflows können Bereitstellungs-, Speicher-, PCIe-, NVLink-, Compute-, Leistungs-, Temperatur- und Kommunikationspfade prüfen, verbrauchen jedoch Ressourcen und können mit Produktionsarbeit in Konflikt geraten. Drainen Sie die Nodes oder planen Sie ein Wartungsfenster ein, bevor Sie eine invasive Diagnose ausführen. Verwenden Sie die aktuelle Diagnoseanleitung von DCGM, um die geeignete Teststufe auszuwählen.

Verfolgen Sie für LLM-Services sowohl Anwendungs- als auch Infrastruktur-Signale:

• p50/p95-Zeit bis zum ersten Token und Inter-Token-Latenz
• akzeptierte Ausgabetokens pro Sekunde und abgeschlossene Anfragen pro Sekunde
• Warteschlangentiefe, Abbrüche, Wiederholungsversuche und Fehlerrate
• zugewiesener gegenüber reserviertem GPU-Speicher, GPU-Auslastung, Stromverbrauch und Temperatur
• Cache-Treffer-/Offload-Verhalten und cachebezogene Fehler
• Host-CPU-Auslastung, RAM-Druck, Modell-/Checkpoint-I/O und Netzwerklatenz

Wenn sich eine Metrik verbessert, während sich eine andere verschlechtert, skalieren Sie noch nicht. Eine höhere Tokenrate bei steigender p95-Latenz oder mehr Wiederholungsversuchen kann für den kundenseitigen Dienst eine Verschlechterung bedeuten.

Kosten nach abgeschlossener Arbeit optimieren, nicht nach stündlicher GPU-Zeit

Die Preise für Cloud-H200-GPUs variieren je nach Region, Reservierungslaufzeit, Hostkonfiguration und Verfügbarkeit, sodass eine statische Preistabelle schnell veraltet. Verwenden Sie stattdessen eine Arbeitslast-Einheit, die Leerlaufzeit und fehlgeschlagene Arbeit sichtbar macht:

fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead

cost per completed request = fully loaded hourly cost / completed requests per hour

cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000

Berechnen Sie dies für den Traffic-Mix, mit dem Sie starten möchten, nicht für eine Demo mit maximalem Durchsatz. Berücksichtigen Sie Kapazität für Failover, Modellladen, Checkpoints und Wartung. Ein detaillierteres Modell finden Sie unter Kosten selbst gehosteter LLMs pro Million Tokens.

Es gibt außerdem eine Grundsatzfrage: Müssen Sie die Laufzeitumgebung betreiben, oder benötigen Sie zuverlässigen Zugriff auf Modellausgaben? Wenn Sie benutzerdefinierte Kernel, eine bestimmte Laufzeitumgebung, dedizierte Datenlokalität oder kontrollierte Hardwareexperimente benötigen, kann ein Cloud-H200-GPU-Pilotprojekt gerechtfertigt sein. Wenn Sie primär eine Modell-API benötigen, vergleichen Sie vor einer Festlegung auf Infrastruktur den Betriebsaufwand mit dem API-Weg. Der Leitfaden zur GPU-Server-Bereitstellung und der Leitfaden für Kubernetes-GPU-Cluster können helfen, diese Grenze explizit zu machen.

Checkliste für die H200-GPU-Bereitstellung

Bevor Sie eine H200-Bereitstellung als einsatzbereit bezeichnen, überprüfen Sie Folgendes:

• [ ] Exakter H200-Formfaktor, GPU-Anzahl und Topologie dokumentiert
• [ ] Speicherbudget bei p95-Kontext und erwarteter Parallelität getestet
• [ ] Kompatibilität von Treiber, CUDA, Framework und Container-Image validiert
• [ ] Integrität von GPU Operator/Device Plugin bestätigt, wenn Kubernetes verwendet wird
• [ ] Scheduler stellt die erwartete nvidia.com/gpu-Kapazität bereit
• [ ] Multi-GPU-Kollektivtest besteht auf der Produktionstopologie
• [ ] Repräsentativer Lasttest erfüllt TTFT-, Latenz-, Durchsatz- und Fehlerziele
• [ ] DCGM-Integrität und geeignete Diagnosen im Wartungsfenster sind Teil des Runbooks
• [ ] Speicher-, Netzwerk-, Modelllade-, Checkpoint- und Neustartpfade sind gemessen
• [ ] Kosten werden pro abgeschlossener nutzbringender Einheit berechnet, einschließlich Leerlauf- und Wiederherstellungskapazität

Häufig gestellte Fragen

Wie viel Speicher hat eine H200-GPU?

NVIDIA gibt für H200 SXM und H200 NVL jeweils 141 GB HBM3e-Speicher und 4,8 TB/s Speicherbandbreite an. Bestätigen Sie die genaue SKU und Systemkonfiguration beim Anbieter, da sich Kartenformfaktor und Interconnect unterscheiden. Die H200-Spezifikationen von NVIDIA sind die Quelle der Zahlen in diesem Leitfaden.

Ist eine H200-GPU für LLM-Inferenz besser als eine H100?

Das kann sie sein, insbesondere wenn Speicherkapazität oder Speicherbandbreite die Arbeitslast begrenzen. Die praktische Antwort hängt von Modellpräzision, Kontextlänge, KV-Cache-Verhalten, Parallelität, Serving-Laufzeitumgebung und Systemtopologie ab. Vergleichen Sie die Arbeitslast anhand eines repräsentativen Trace; betrachten Sie einen Anbieter-Benchmark nicht als Ersatz für das SLO Ihres Dienstes. Im Vergleich H200 vs. H100 finden Sie ein Entscheidungsrahmenwerk für die Hardware.

Sollte ich H200 SXM oder H200 NVL wählen?

Treffen Sie die Auswahl ausgehend von der Topologie. H200 SXM eignet sich für eng gekoppelte Multi-GPU-Konfigurationen im HGX-Stil. H200 NVL ist eine luftgekühlte PCIe-Option mit 2- oder 4-Wege-NVLink-Bridge-Konfigurationen. Prüfen Sie Topologie, Host und Kommunikationsmuster der Arbeitslast, statt allein anhand des Speichers zu wählen.

Unterstützt die H200-GPU MIG?

NVIDIA führt für H200 SXM und H200 NVL bis zu sieben MIG-Instanzen auf, mit unterschiedlich angegebenen Speichergrößen pro Instanz. Verwenden Sie MIG, wenn Sie hardwaregestützte Speicher- und Fehlerisolation benötigen. Ersetzen Sie es nicht durch Time Slicing, wenn diese Isolationseigenschaften erforderlich sind.

Wie viele H200-GPUs benötige ich?

Beginnen Sie mit der kleinsten Konfiguration, die einen repräsentativen Test für Speicher, Latenz, Durchsatz und Wiederherstellung besteht. Fügen Sie GPUs nur hinzu, wenn das Speicherbudget, die Anzahl der Replikate oder der validierte Parallelisierungsplan dies erfordern. Eine höhere GPU-Anzahl ohne eine Fabric-bewusste Arbeitslast kann Kosten und Betriebsaufwand erhöhen, ohne das kundenseitige Ergebnis zu verbessern.

Mit einem validierten H200-GPU-Pilotprojekt beginnen

Die richtige H200-GPU-Bereitstellung ist ein gemessenes System: Beschleunigerspeicher, Topologie, Scheduler, Laufzeitumgebung, Datenpfad, Observability und Wirtschaftlichkeit der Arbeitslast müssen zusammenpassen. Beginnen Sie mit einem instrumentierten Pilotprojekt, spielen Sie realistischen Traffic erneut ab, dokumentieren Sie die Fehlermodi und skalieren Sie erst, wenn die Evidenz den nächsten Kapazitätsschritt unterstützt.

Quellen

• NVIDIA H200 GPU-Spezifikationen
• Installationsanleitung für NVIDIA GPU Operator
• Dokumentation zur Kubernetes-GPU-Planung
• NVIDIA-DCGM-Diagnosedokumentation