Nvidia H200 GPU: Architektur, Leistung und Cloud-Bereitstellungsleitfaden

Nvidia H200 GPU: Architektur, Leistung und Cloud-Bereitstellungsleitfaden

Die Nvidia H200 GPU ist ein Beschleuniger der Hopper-Generation für KI- und HPC-Workloads, bei denen Speicherkapazität, Speicherbandbreite und Multi-GPU-Topologie das Ergebnis maßgeblich beeinflussen. NVIDIA gibt 141 GB HBM3e-Speicher und 4,8 TB/s Speicherbandbreite pro H200 an. Das sind wichtige Ausgangspunkte – aber sie sagen für sich allein nicht aus, ob eine H200-Bereitstellung ein Latenzziel erfüllt, ein Modell plus KV-Cache aufnehmen kann oder effizient über einen Cloud-Knoten skaliert. NVIDIAs H200-Spezifikationen sind die Hardware-Referenz; dieser Leitfaden macht daraus einen Bereitstellungsprozess.

Für KI-Entwickler und ML-Infrastrukturteams lautet die praktische Entscheidung meist: Passen ein Modell, sein maximal aktiver Kontext und der Laufzeit-Overhead mit ausreichend Reserve auf eine GPU? Falls nicht: Kann der Workload innerhalb eines H200-Knotens mit hoher Bandbreite bleiben, bevor er das Netzwerk überqueren muss? Die Antwort sollte Formfaktor, Parallelisierungsplan und Abnahmetests bestimmen – nicht eine Schlagzeile zu Spitzen-TFLOPS.

Dies ist ein Architektur- und Bereitstellungsleitfaden, keine Preisliste. Wenn Sie Angebote oder stündliche Cloud-Tarife vergleichen, beginnen Sie mit unserem Preisleitfaden zur H200 GPU. Wenn es bei der Entscheidung speziell um H200 gegenüber H100 geht, lesen Sie den Vergleich H200 vs. H100.

Die kurze Antwort: Wann eine Nvidia H200 GPU gut geeignet ist

Wählen Sie eine Nvidia H200 GPU, wenn alle oder die meisten der folgenden Punkte zutreffen:

• Ihr Workload wird durch Modellspeicher, Wachstum des KV-Caches oder Speicherbandbreite eingeschränkt und nicht nur durch Rechenleistung.
• Sie benötigen mehr Spielraum für Long-Context-Inferenz oder parallele Anfragen, ohne das Modell sofort über mehrere Knoten aufzuteilen.
• Sie können die tatsächliche Cloud-Topologie validieren – SXM- oder PCIe/NVL-Formfaktor, Anzahl der GPUs pro Knoten und verfügbare Interconnects – statt „H200“ als vollständige Bereitstellungsspezifikation zu betrachten.
• Sie sind bereit, Time to First Token, Output-Token-Durchsatz, Tail-Latenz, GPU-Speicher und Warteschlangenbildung bei derselben Anfrageform zu messen, die Sie in der Produktion erwarten.
• Sie benötigen ausreichend Kontrolle über Serving-Software, Modellgewichte, Batching oder Datenlokalität, um den direkten Betrieb von GPU-Kapazität zu rechtfertigen.

Eine H200 ist nicht automatisch die beste Lösung für jede Anwendung der generativen KI. Wenn ein kleinerer Beschleuniger das Modell und seinen aktiven Kontext problemlos aufnehmen kann oder Ihr Produkt zwischen vielen gehosteten Modellen wechseln muss, ohne den GPU-Betrieb selbst zu verwalten, kann eine verwaltete Modell-API die einfachere Betriebsgrundlage sein. Entscheidend ist der Kosten- und Zuverlässigkeitsvergleich für den vollständig ausgeführten Workload bei Ihrem eigenen Traffic-Profil, nicht ein reiner Hardwarewert.

Nvidia H200 GPU-Architektur: Die Spezifikationen, die Bereitstellungsentscheidungen verändern

Die H200 verwendet NVIDIAs Hopper-Architektur. Hopper umfasst die Transformer Engine und NVLink der vierten Generation; NVIDIA positioniert diese Funktionen für Transformer-Workloads mit gemischter Präzision und Multi-GPU-Kommunikation. Die Übersicht zur Hopper-Architektur erläutert außerdem, warum die Server-Topologie wichtig ist, wenn Workloads über einen Beschleuniger hinausgehen.

Quelle: NVIDIA H200-Spezifikationen. NVIDIA weist darauf hin, dass einige veröffentlichte Leistungskennzahlen Sparsity verwenden; nutzen Sie diese Werte als Referenz für die Fähigkeiten, nicht als Zusage für den Produktionsdurchsatz.

Speicherkapazität ist eine Bereitstellungsvariable, keine Marketingzahl

Für das Serving von LLMs sollten Sie den HBM-Speicher anhand des vollständigen Working Sets planen:

erforderlicher GPU-Speicher ≈ Modellgewichte
                           + maximal aktiver KV-Cache
                           + Laufzeit-Workspaces
                           + Fragmentierungs- und Sicherheitsmarge

Der Modell-Checkpoint ist nur der erste Faktor. Eine Konfiguration, die erfolgreich geladen wird, bietet möglicherweise dennoch zu wenig Spielraum für das aktive Kontextfenster und die gleichzeitig zu bedienenden Sequenzen. Deshalb können die 141 GB HBM3e der H200 nützlich sein, selbst wenn ein Modell technisch auf eine Konfiguration der H100-Klasse passt: Sie geben der Bereitstellung mehr Spielraum, Batch-Größe, Kontextlänge und Parallelität gegen Latenz abzuwägen.

Notieren Sie vor der Kapazitätsreservierung diese Workload-Eingaben:

1. Modell, Gewichtsformat sowie Quantisierungs- oder Präzisionsmodus.
2. Maximale Eingabe-Tokens und maximal generierte Tokens für eine reale Anfrage.
3. Erwartete gleichzeitig aktive Sequenzen – nicht nur Anfragen pro Sekunde.
4. Latenz-SLOs, einschließlich Zeit bis zum ersten Token und Tail-Latenz.
5. Ob die Anwendung eine einzelne vollständige GPU, eine isolierte Partition oder eine Multi-GPU-Modellreplik benötigt.

Führen Sie die erste Dimensionierungsübung mit absichtlich schwierigen Prompts durch. Ein Test mit kurzen Prompts, der gut aussieht, kann den KV-Cache-Druck verbergen, der bei Kontextlängen in der Produktion auftritt.

Bandbreite und Topologie sind getrennte Prüfungen

Speicherbandbreite kann für autoregressives Decoding und speicherintensive Workloads mindestens genauso wichtig sein wie Rechenleistung. Sobald das Modell geshardet ist, ist auch die Inter-GPU-Bandbreite wichtig. Gehen Sie nicht davon aus, dass acht H200-GPUs einen einzigen gemeinsamen Speicherpool von 1.128 GB haben: Verteilte Serving-Software muss Tensoren platzieren und Aktivierungen über die tatsächlich verfügbaren Verbindungen austauschen.

NVIDIA beschreibt NVLink der vierten Generation als mit 900 GB/s bidirektionaler Bandbreite pro GPU in DGX- und HGX-Systemen, während NVSwitch die Acht-GPU-Domäne unterstützt. Deshalb verdient eine Ein-Knoten-Topologie eine separate Bewertung gegenüber einem Multi-Knoten-Cluster. Die Hopper-Architekturreferenz von NVIDIA ist die Quelle für die Interconnect-Fähigkeit; die Instanzdokumentation des Cloud-Anbieters ist die Quelle für die Topologie, die Sie tatsächlich erhalten.

H200 SXM vs. H200 NVL: Wählen Sie die Bereitstellungsform, bevor Sie die Instanz auswählen

„H200“ bezeichnet kein einzelnes Serverdesign. Zwei gängige Bereitstellungsformen haben unterschiedliche betriebliche Auswirkungen.

Beide Formfaktoren führen in der NVIDIA-Spezifikationstabelle 141 GB HBM3e und 4,8 TB/s Speicherbandbreite auf. Der entscheidende Unterschied bei einem Multi-GPU-Workload ist oft die Server- und Verbindungstopologie rund um diesen Speicher. Behandeln Sie das Topologiediagramm des Anbieters und eine Topologieprüfung innerhalb der Instanz als erforderliche Beschaffungsartefakte.

Eine Entscheidungs-Matrix von Workload zu Topologie

Verwenden Sie diese Matrix, um das erste Bereitstellungsexperiment festzulegen. Sie ist eine Ausgangshypothese, kein Ersatz für einen Benchmark.

Für verteilte Inferenz beschreibt die vLLM-Dokumentation denselben grundlegenden Ablauf: Verwenden Sie eine GPU, wenn das Modell darauf passt, Tensor-Parallelismus, wenn es auf einen Knoten passt, und fügen Sie Pipeline-Parallelismus hinzu, wenn es mehrere Knoten umfassen muss. Die genauen Flags und unterstützten Strategien hängen von der vLLM-Version und der Modellarchitektur ab; prüfen Sie daher Ihre installierte Version. Siehe die vLLM-Dokumentation zur verteilten Inferenz.

Cloud-Bereitstellungsleitfaden für Nvidia-H200-GPU-Workloads

Die sicherste Einführung erfolgt stufenweise. Jede Stufe beantwortet eine Frage, bevor Sie eine weitere Quelle für Variabilität hinzufügen.

1. Einen Workload-Vertrag erstellen

Definieren Sie den Testverkehr vor der Bereitstellung. Berücksichtigen Sie Modellversion, Präzision, Verteilungen der Eingabe- und Ausgabetoken, Parallelität, Service-Level-Ziele, geografische Platzierung, Datenanforderungen und eine Kostenbasis. Behalten Sie eine kleine feste Regressionsmenge sowie eine realistische Replay-Menge bei.

Dies verhindert einen häufigen Fehler: Hardware anhand eines synthetischen Durchsatztests zu vergleichen und dann festzustellen, dass die gewählte Konfiguration bei den langen Prompts oder den Tail-Latenzbedingungen versagt, die für die Anwendung relevant sind.

2. Den Knoten vor der Bereitstellung des Modellservers überprüfen

Identifizieren Sie nach dem Start der Instanz die physische Anordnung, statt sich auf ihren Produktnamen zu verlassen:

nvidia-smi topo -m
nvidia-smi topo -p2p n

NVIDIA empfiehlt diese Prüfungen bei der Diagnose von Topologie- und NVLink-Verhalten. Die NCCL-Anleitung zu Leistung und Tuning verweist außerdem auf nvbandwidth oder nvloom, um zu prüfen, ob die gemessene GPU-zu-GPU-Bandbreite dem erwarteten Hardwarepfad entspricht.

Dokumentieren Sie die Topologieausgabe im Bereitstellungs-Runbook. Dadurch wird eine spätere Leistungsregression nachvollziehbar: Sie können eine Anwendungsänderung von einer anderen PCIe-, NVLink- oder Netzwerkplatzierung unterscheiden.

3. Einen unterstützten GPU-Software-Stack installieren

Für Kubernetes benötigt der Cluster den NVIDIA-Treiber, einen Container-Laufzeitpfad und ein Anbieter-Device-Plugin, bevor Workloads eine GPU anfordern können. Nach der Installation des Device-Plugins stellt Kubernetes GPUs als benutzerdefinierte planbare Ressourcen bereit. Der Leitfaden zur GPU-Planung von Kubernetes erläutert das Ressourcenmodell sowie die Verwendung von Labels oder Affinität für gemischte Beschleunigerflotten.

Der GPU Operator von NVIDIA kann den Treiber, NVIDIA Container Toolkit, das Device-Plugin, DCGM Exporter und MIG Manager als abgestimmten Stack auf GPU-Workerknoten verwalten. Verwenden Sie die aktuelle Installationsdokumentation für den GPU Operator und bestätigen Sie, dass dessen Validator- und Operator-Pods fehlerfrei laufen, bevor Sie einen Modellserver einführen.

Eine minimale Ressourcenanforderung ist konzeptionell einfach:

resources:
  limits:
    nvidia.com/gpu: 4

In Kubernetes werden GPUs normalerweise in limits angegeben; wenn Sie zusätzlich eine GPU-Anforderung angeben, muss diese dem Limit entsprechen. Fügen Sie Knoten-Labels, Affinität, Taints und Workload-Klassen-Labels hinzu, damit ein latenzempfindlicher H200-Service nicht in einem unbeabsichtigten Beschleuniger-Pool eingeplant wird.

4. Mit einem Serving-Test mit nur einer Variablen beginnen

Starten Sie ein Modellreplikat mit der kleinsten Topologie, die den Workload aufnehmen kann. Bei einer vLLM-Bereitstellung mit mehreren GPUs auf einem einzelnen Knoten sollte die Tensor-Parallelgröße der Anzahl der dem Replikat zugewiesenen GPUs entsprechen. Zum Beispiel:

vllm serve <model-identifier> \
  --tensor-parallel-size 4

Dies ist absichtlich ein Topologiebeispiel und kein Produktionsbefehl zum Kopieren und Ausführen. Fixieren Sie Container-Image, Treiber-/CUDA-Kompatibilität, Modellrevision, Tokenizer und Version der Serving-Engine in Ihrem eigenen Bereitstellungsmanifest. Ändern Sie dann jeweils nur eine Variable: Tensor-Parallelgröße, maximale Anzahl aktiver Sequenzen, Cache-Zuweisungsrichtlinie oder Replikatanzahl.

5. Prefill und Decode getrennt testen

Der Token-Durchsatz kann den Latenzpfad verbergen, den Ihre Benutzer erleben. Messen Sie mindestens:

• Zeit bis zum ersten Token für kurze und lange Eingabe-Prompts.
• Ausgabe-Token-Durchsatz nach dem ersten Token.
• P50-, P95- und P99-End-to-End-Latenz.
• Genutzter GPU-Speicher, Cache-Druck und Out-of-Memory-Ereignisse.
• Wartezeit in der Queue, Anfrageabbrüche, Wiederholungsversuche und Fehlerrate.

Die Nvidia H200 GPU kann eine eingeschränkte Bereitstellung verbessern, da ihr größerer, schnellerer Speicher mehr Spielraum für die Planung schafft. Allerdings kann nur der gemessene Anfrage-Mix zeigen, ob dieser Spielraum zu nutzbarer, benutzerseitiger Kapazität wird.

6. Wenn möglich, Replikate vor Knoten hinzufügen

Wenn ein H200-Knoten das Modell aufnehmen kann und die Latenzziele erfüllt, kann das Hinzufügen von Replikaten betrieblich einfacher sein als die Einführung eines zweiten Knotens. Sobald Sie mehrere Knoten nutzen, testen Sie zuerst den Netzwerk- und Kollektivpfad. Halten Sie bei Multi-Knoten-Inferenz Umgebung und Modellartefakte über alle Knoten hinweg konsistent; eine Abweichung bei Container, Treiber, Modellrevision oder Tokenizer kann wie ein Hardwareproblem aussehen.

Erzwingen Sie keine NCCL-Algorithmuseinstellungen, bevor Sie eine Topologie-Basislinie erfasst haben. Laut der NCCL-Dokumentation von NVIDIA ist die Standardauswahl topologiebewusst; manuelle Einstellungen sind eine Reaktion auf gemessenes Verhalten und kein Ersatz für Messungen.

7. Kapazität überwachen, bevor der Traffic gefährdet ist

DCGM Exporter kann GPU-Telemetriedaten für einen Kubernetes-Monitoring-Stack bereitstellen. NVIDIA dokumentiert ihn als Teil des vom GPU Operator verwalteten Stacks und bietet in seiner DCGM-Exporter-Dokumentation Installationsanleitungen für Prometheus-Umgebungen.

Erstellen Sie Dashboards, die den Zustand der Infrastruktur mit Service-Ergebnissen verknüpfen:

8. Ausfall- und Wartungsverhalten planen

Eine H200-Bereitstellung ist nur dann produktionsreif, wenn ein Wiederherstellungskonzept vorhanden ist. Testen Sie einen Replikat-Neustart, das Entleeren eines Knotens, das Neuladen des Modells, einen Kaltstart des Caches und eine Unterbrechung des vorgelagerten Netzwerks. Definieren Sie, was geschieht, wenn Kapazität vorübergehend nicht verfügbar ist: in die Warteschlange stellen, abwerfen, an ein kleineres Modell weiterleiten oder einen verwalteten API-Fallback verwenden. Die beste Option hängt von den Anforderungen des Produkts an Korrektheit und Latenz ab.

Leistung: Benchmarken Sie den Workload, nicht die Broschüre

NVIDIA veröffentlicht Material zu Fähigkeiten und Benchmarks für die H200, einschließlich der Aussage einer höheren LLM-Inferenzleistung in ausgewählten Vergleichen. Diese Ergebnisse sind nützlich, um zu verstehen, was der Beschleuniger ermöglichen kann, stellen jedoch keine Zusage für ein bestimmtes Modell, eine bestimmte Kontextlänge, Quantisierung, Serving-Stack oder Cloud-Topologie dar. Das H200-Datenblatt sollte zusammen mit seinen Testbedingungen und Fußnoten gelesen werden.

Halten Sie für einen aussagekräftigen H200-Vergleich diese Variablen konstant:

1. Modellrevision, Tokenizer, Präzision und Quantisierung.
2. Verteilung von Prompt- und Ausgabe-Token.
3. Parallelität und Richtlinie für die Zulassungssteuerung.
4. Tensor-/Pipeline-Parallelitätslayout und tatsächliche Hardwaretopologie.
5. Versionen von Serving-Engine und CUDA/NCCL.
6. Methode zur SLA-Messung, einschließlich Aufwärmphase und Cache-Zustand.
7. Cloud-Preiseinheit und Nicht-GPU-Kosten wie Speicher, Egress, CPU und Betrieb.

Dieser Testplan ist wertvoller als ein allgemeiner Vergleich von „Token pro Sekunde“, da er zeigt, ob die Nvidia H200 GPU ein kundenorientiertes SLO oder die Kosten pro abgeschlossener Anfrage verändert.

Checkliste für die H200-Bereitstellung

Verwenden Sie diese Checkliste als Freigabekriterium für einen neuen H200-Workload.

• [ ] Dokumentieren Sie Modell, Präzision, maximale Kontextlänge, Ausgabelänge und Zielparallelität.
• [ ] Berechnen Sie ein Speicherbudget für Gewichte, KV-Cache, Laufzeit-Arbeitsspeicher und eine Sicherheitsmarge.
• [ ] Bestätigen Sie, ob die zugewiesene H200 SXM oder NVL ist, und erfassen Sie nvidia-smi topo -m.
• [ ] Überprüfen Sie die Kompatibilität von Treiber, CUDA, Container, Framework und Serving-Engine.
• [ ] Fordern Sie die vorgesehene GPU-Anzahl mit Platzierungsbeschränkungen im Orchestrator an.
• [ ] Führen Sie vor dem Laden des Modells einen CUDA-/Operator-Zustandstest aus.
• [ ] Führen Sie vor der Akzeptanz eines Multi-GPU-Ergebnisses eine Validierung der Topologie und der kollektiven Bandbreite durch.
• [ ] Messen Sie Traffic mit kurzem und langem Kontext getrennt.
• [ ] Verfolgen Sie TTFT, Ausgabe-Token-Durchsatz, P95-/P99-Latenz, Wartezeit, Fehler und GPU-Speicher.
• [ ] Testen Sie ein Szenario mit Neustart, Knotenentleerung und Kapazitätsreduzierung.
• [ ] Vergleichen Sie das Ergebnis mit einer Baseline einer verwalteten Modell-API bei gleichem Workload und SLO.
• [ ] Speichern Sie die Topologie, Benchmark-Konfiguration und Kostenannahmen zusammen mit der Bereitstellungsentscheidung.

Wann eine Modell-API die bessere Wahl für die Cloud-Bereitstellung ist

Der direkte Betrieb der Nvidia H200 GPU gibt Ihnen Kontrolle über Modellgewichte, Serving-Konfiguration, Datenplatzierung und Kapazität. Er erhöht jedoch auch den Aufwand für Kapazitätsplanung, Topologievalidierung, Observability und Wiederherstellung. Wenn diese Kontrollen keinen wesentlichen Produktvorteil schaffen, sollte der Vergleich ehrlich bleiben: Bewerten Sie eine verwaltete Modell-API anhand derselben Metriken für Qualität, Latenz, Verfügbarkeit und abgeschlossene Workloads.

Flatkey kann eine solche Baseline für Teams sein, die offizielle Modell-APIs testen oder über sie routen müssen, ohne separate Provider-Integrationen zu pflegen. Die Produktübersicht beschreibt einen API-Schlüssel und ein Guthaben über Modelle und Tools hinweg; die richtige Wahl ist diejenige, die Ihre Workload-Anforderungen mit dem geringsten unnötigen operativen Aufwand erfüllt. Entdecken Sie Flatkeys Modellkatalog oder holen Sie sich einen API-Schlüssel, wenn eine geroutete API besser zum Workload passt als dedizierte GPU-Kapazität.

Häufig gestellte Fragen

Wie hoch ist die Speicherkapazität einer Nvidia H200 GPU?

NVIDIA gibt 141 GB HBM3e-Speicher pro H200 GPU mit einer Speicherbandbreite von 4,8 TB/s an. Dies gilt pro Beschleuniger; daher benötigen Sie weiterhin einen verteilten Serving-Plan, wenn das Modell und der aktive Cache den nutzbaren Spielraum einer einzelnen GPU überschreiten.

Ist die H200 hauptsächlich eine Inferenz-GPU oder eine Trainings-GPU?

Die H200 ist sowohl für KI- als auch für HPC-Workloads positioniert. Unterscheiden Sie bei der Bereitstellungsplanung die Workload statt des Labels: LLM-Serving mit langem Kontext, Fine-Tuning, verteiltes Training und wissenschaftliches Rechnen stellen unterschiedliche Anforderungen an Speicher, Kommunikation und Scheduling. Benchmarken Sie das Framework und die Topologie, die Sie tatsächlich betreiben werden.

Was ist der Unterschied zwischen H200 SXM und H200 NVL?

Es handelt sich um unterschiedliche H200-Formfaktoren und Wege der Serverintegration. NVIDIA führt SXM-Systeme mit NVLink-Konnektivität in HGX-ähnlichen Konfigurationen mit 4 oder 8 GPUs auf, während H200 NVL ein Dual-Slot-PCIe-Formfaktor mit dokumentierten Bridge-Optionen ist. Prüfen Sie die tatsächliche Topologie des Cloud-Anbieters, bevor Sie von einem gleichwertigen Multi-GPU-Verhalten ausgehen.

Kann ich eine H200-Workload auf Kubernetes ausführen?

Ja, sofern der Cluster über einen kompatiblen NVIDIA-Treiber, einen Container-Runtime-Pfad und ein Device-Plugin verfügt. Kubernetes plant GPUs als erweiterte Ressourcen, und der NVIDIA GPU Operator kann den GPU-Software-Stack und Telemetriekomponenten verwalten. Validieren Sie die Node-Labels, die GPU-Ressourcenanforderung, den Zustand des Operators und SLOs auf Anwendungsebene, bevor Sie Produktions-Traffic senden.

Sollte ich die H200 statt der H100 wählen?

Wählen Sie anhand des Engpasses. Die größere HBM3e-Kapazität und die höhere dokumentierte Speicherbandbreite der H200 können für speicherbeschränktes Serving wertvoll sein, aber eine H100 kann eine kleinere Workload möglicherweise dennoch mit besserer operativer oder kommerzieller Eignung erfüllen. Vergleichen Sie identische Formfaktoren und führen Sie dieselbe Workload durch beide Konfigurationen aus. Unser Leitfaden H200 vs. H100 bietet den Entscheidungsrahmen.

Halten Sie die Bereitstellungsentscheidung reproduzierbar

Die Architektur der H200 ist überzeugend, wenn Speicher und Topologie die eigentlichen Einschränkungen sind. Machen Sie die Entscheidung für die Nvidia H200 GPU reproduzierbar, indem Sie den Workload-Vertrag, den Speicherplan, die Hardwaretopologie, die Softwareversionen und die Ergebnisse der Lasttests gemeinsam speichern. Diese Dokumentation ermöglicht es dem nächsten Engineer zu erklären, warum die Bereitstellung funktioniert – und zu erkennen, was sich geändert hat, falls sie nicht mehr funktioniert.

Lesen Sie für die nächsten Planungsschritte den Leitfaden zur GPU-Cluster-Architektur für das Design von Compute, Netzwerk, Speicher und Control Plane und nutzen Sie anschließend den Leitfaden zur vLLM-Multi-GPU-Inferenz für die Einrichtung von Tensor- und Pipeline-Parallelität.