Mehr-GPU-Benchmark: B200 vs H200 vs H100 vs MI300X
Seit über zwei Jahrzehnten ist die Optimierung der Rechenleistung ein Eckpfeiler meiner Arbeit. Wir haben die GPUs von NVIDIA (B200, H200, H100) und AMD (MI300X) getestet, um zu bewerten, wie gut sie sich für die Inferenz von Large Language Models (LLM) skalieren lassen. Mit dem vLLM-Framework und dem Modell meta-llama/Llama-3.1-8B-Instruct führten wir Tests mit 1, 2, 4 und 8 GPUs durch.
Wir analysierten den Durchsatz und die Skalierungseffizienz, um zu veranschaulichen, wie jede GPU-Architektur parallelisierte, rechenintensive Workloads bewältigt.
Ergebnisse des Mehr-GPU-Benchmarks
Gesamtdurchsatz vs. GPU-Anzahl
- Gesamtdurchsatz (Tokens/Sekunde): Diese Metrik repräsentiert die reine Rechenleistung des gesamten Mehr-GPU-Systems. Sie misst die Gesamtzahl der pro Sekunde verarbeiteten Eingabe- und Ausgabetokens und ist damit der wichtigste Indikator für die maximale Leistung unter einer gesättigten, Offline-Workload.
Um zu verstehen, wie wir die Punktzahl berechnet haben, lesen Sie unsere Methodik für Mehr-GPU-Benchmarks.
Wichtige Leistungserkenntnisse:
Leistungsanalyse: Die NVIDIA H200 liefert in allen getesteten Konfigurationen den höchsten Durchsatz, mit Leistungsverbesserungen von 9-10 % gegenüber dem H100. Das System erreicht eine Skalierungseffizienz von 99,8 % bei Dual-GPU-Konfigurationen, was eine nahezu optimale Ressourcennutzung anzeigt.
Leistungseigenschaften von AMD MI300X: Die AMD MI300X erreicht einen Single-GPU-Durchsatz von 18.752 Tokens pro Sekunde, was etwa 74 % der Leistung der H200 entspricht. Das System behält Skalierungseffizienzen von 95 % und 81 % für Zwei-GPU- und Vier-GPU-Konfigurationen bei.
Durchschnittliche Inferenz-Latenz vs. GPU-Anzahl
- Durchschnittliche Inferenz-Latenz (Millisekunden): Diese Metrik misst die durchschnittliche Zeit, die für die Verarbeitung einer einzelnen Anfrage von Anfang bis Ende benötigt wird. Eine niedrigere Latenz führt zu einer schnelleren und reaktionsschnelleren Erfahrung für Endbenutzer.
Wichtige Leistungserkenntnisse:
Latenzleistungsanalyse: Die NVIDIA B200 weist in allen bewerteten Konfigurationen die niedrigsten Latenzmessungen auf und erreicht 2,40 ms bei Acht-GPU-Implementierungen. Diese Leistungseigenschaften machen sie für Anwendungen geeignet, die minimale Reaktionszeiten erfordern, wie z. B. Echtzeit-Interaktionssysteme, bei denen eine Latenz von unter 3 ms eine Designanforderung ist.
Beobachtungen zur Skalierungseffizienz: Die Analyse zeigt abnehmende Erträge bei der Latenzreduzierung, wenn die GPU-Anzahl auf allen Plattformen steigt. Die größte Latenzreduzierung tritt beim Übergang von Single- zu Dual-GPU-Konfigurationen auf (ca. 50 % über alle Plattformen). Konfigurationen mit mehr als 4 GPUs zeigen zunehmend geringere Latenzverbesserungen.
Vergleichsanalyse H200 und H100: Die H200 weist in allen Maßstäben eine 5-8 % niedrigere Latenz als die H100 auf, wobei der absolute Unterschied bei höheren GPU-Anzahlen abnimmt (2,81 ms gegenüber 2,86 ms bei acht GPUs, ein Unterschied von 0,05 ms). Dieser marginale Leistungsunterschied, im Vergleich zum Preisunterschied von 41 %, legt nahe, dass die H100 für latenzsensitive Bereitstellungen günstigere Kosten-Leistungs-Eigenschaften bieten könnte.
Latenzeigenschaften von AMD MI300X: Die MI300X weist in den getesteten Konfigurationen Latenzwerte auf, die 37-75 % höher sind als bei der H200, was auf aktuelle Unterschiede in der Reife der Software-Stack zwischen vLLM ROCm- und CUDA-Implementierungen zurückzuführen sein könnte. Bei einer Acht-GPU-Skala erreicht die MI300X eine Latenz von 4,20 ms, die trotz des Leistungsunterschieds zu NVIDIA-Plattformen für zahlreiche Produktionsanwendungen innerhalb akzeptabler Parameter bleibt.
Leistung vs. Preis: Eine Kosten-Nutzen-Analyse
Während reine Leistungsmetriken entscheidend sind, hängt die endgültige Entscheidung für jede Organisation von der Kosteneffizienz ab. Um die Rendite einer Investition (ROI) für jede Plattform zu analysieren, haben wir unsere Durchsatzergebnisse gegen die stündlichen On-Demand-Preise von RunPod zum Zeitpunkt des Tests abgeglichen. Dies ermöglicht es uns, eine „Leistung pro Dollar"-Punktzahl zu berechnen und aufzudecken, welches Setup die meiste Rechenleistung zum niedrigsten Preis bietet.
Hinweis: Alle Preisinformationen spiegeln die On-Demand-Raten wider, die auf der RunPod Cloud-Plattform zum Zeitpunkt des Benchmarks (September 2025) verfügbar waren, und unterliegen Änderungen. Die Kosten dienen dem Vergleich und beinhalten keine Speicher- oder Netzwerkgebühren.
Wie wir den Durchsatz pro Dollar berechnet haben
Um diesen Graphen zu erstellen, haben wir unsere Rohleistungsdaten gegen die Stundenkosten verarbeitet. Die Berechnungsformel lautet:
- Datenvorbereitung: Für jeden Datenpunkt in unserer Ergebnistabelle haben wir die entsprechenden Stundenkosten für die spezifische GPU-Konfiguration abgerufen (z. B. kosten 4x H100 10,76 $).
- Berechnung: Wir haben dann die Formel angewendet, um den Wert throughput_per_dollar zu berechnen. Zum Beispiel lieferte die H100 bei 1x GPU 23.243 Tokens/s bei Kosten von 2,69 $/h, was zu einer Punktzahl von 8.642 Tokens/s pro Dollar führte.
Diese Effizienzpunktzahl bietet ein Entscheidungshilfsmittel, das die Diskussion von „Welches ist am schnellsten?" zu „Welche ist die klügste Investition für unseren Workload?" verschiebt.
Was ist Mehr-GPU-Skalierung?
Mehr-GPU-Skalierung bezieht sich auf die Fähigkeit eines Systems, seine Leistung zu steigern, indem eine einzelne große Aufgabe auf mehrere GPUs verteilt wird. Für die LLM-Inferenz kann dies durch Datenparallelismus erreicht werden, bei dem unabhängige Kopien des Modells auf jeder GPU ausgeführt werden, wobei ein Load Balancer eingehende Anfragen auf alle Instanzen verteilt.
Idealerweise würde die Verwendung von zwei GPUs die doppelte Leistung einer einzelnen GPU liefern (2-fache Beschleunigung). In der Realität sind Leistungsgewinne jedoch durch CPU- und Systemengpässe begrenzt, die Zeit, die das Host-System mit der Verwaltung mehrerer gleichzeitiger Prozesse verbringt, Einschränkungen der Speicherbandbreite und Ressourcenkonkurrenz. Unser Benchmark misst, wie effizient jede Plattform diese Systemebene-Einschränkungen verwaltet, ein kritischer Faktor für den Aufbau kosteneffektiver, hochleistungsfähiger KI-Inferenzserver für kleine bis mittlere Modelle.
Was sind die Herausforderungen bei Mehr-GPU-Skalierungstests?
Das Benchmarking von Mehr-GPU-Systemen stellt einzigartige Herausforderungen dar, die die Leistung erheblich beeinträchtigen können.
Kommunikationsaufwand und Interconnect-Engpässe
Wenn ein Modell auf GPUs aufgeteilt wird, wird der Interconnect, wie z. B. NVIDIAs NVLink oder AMDs Infinity Fabric, zu einem kritischen Leistungsengpass. Die Effizienz der Inter-GPU-Kommunikation wirkt sich direkt auf die Skalierung aus. Wenn die Zeit, die für das Warten auf Daten von einer anderen GPU aufgewendet wird, die Zeit übersteigt, die durch die Parallelisierung der Berechnung gespart wird, werden Leistungsgewinne abnehmen. Dieser Effekt ist besonders ausgeprägt bei Modellen, die nicht groß genug sind, um die Rechenkapazität jeder GPU vollständig zu sättigen.
Reife des Software-Ökosystems
Die Leistung ist nicht ausschließlich eine Funktion der Hardware. Der Software-Stack, einschließlich Treibern, Kommunikationsbibliotheken (wie NCCL für NVIDIA und RCCL für AMD) und der Inferenz-Engine (vLLM), spielt eine monumentale Rolle. Wir haben festgestellt, dass die Leistung einer Plattform tief mit der Reife ihrer Software-Unterstützung verbunden ist. Ein etabliertes Ökosystem wie NVIDIAs CUDA profitiert oft von Jahren der Feinabstimmung und Optimierung, was zu einer überlegenen Skalierungseffizienz im Vergleich zu neueren Integrationen wie AMDs ROCm führen kann, selbst auf leistungsfähiger Hardware.
Plattformspezifische Optimierungen
Wie unsere Tests zeigten, erfordert die Erreichung optimaler Leistung oft plattformspezifische Konfigurationen. Die Verwendung eines generischen „One-Size-Fits-All"-Ansatzes kann zu irreführend niedriger Leistung führen. Das richtige Docker-Image, Umgebungsvariablen (z. B. Aktivierung benutzerdefinierter AMD-Kernel) und sogar Modelldatentypen (z. B. bfloat16 für Blackwell) sind entscheidend, um das wahre Potenzial der Hardware freizulegen. Dies macht faire „Apfel-zu-Apfel"-Vergleiche zu einer erheblichen technischen Herausforderung.
Als bevorzugte Quelle hinzufügenMethodik für Mehr-GPU-Benchmarks
Wir haben die neuesten Hochleistungs-GPU-Architekturen von NVIDIA und AMD getestet, um ihre Skalierungsfähigkeiten zu bewerten. Unser Benchmark maß die Leistung von Single- und Mehr-GPU-Konfigurationen (1x, 2x, 4x, 8x) unter Verwendung des Standardmodells meta-llama/Llama-3.1-8B-Instruct1 und der Inferenz-Engine vLLM2 .
Testumgebung und -prozess
- Plattform: Alle Benchmarks wurden auf RunPod Cloud ausgeführt, um konsistenten Hardwarezugriff zu gewährleisten.
- Inferenz-Engine: vLLM (vllm bench throughput Tool) wurde als standardisierte Engine verwendet.
- Modell: meta-llama/Llama-3.1-8B-Instruct.
- Datensatz: ShareGPT Vicuna-Datensatz (25.000 Prompts) zur Simulation einer konversationellen Workload.
- Strategie: Datenparallelismus; jeder Mehr-GPU-Test führte eine unabhängige vLLM-Instanz auf jeder GPU aus. Die gesamte Prompt-Last wurde gleichmäßig auf die Instanzen verteilt, die gleichzeitig ausgeführt wurden, um eine lastausgeglichene Produktionsumgebung zu simulieren. Dieser Ansatz eliminiert die Inter-GPU-Kommunikation (NVLink/PCIe) als Engpass und verlagert Leistungslimiter auf das Host-System (CPU, RAM).
- Automatisierung: Benutzerdefinierte Bash-Skripte wurden verwendet, um die Umgebungseinrichtung, Testausführung, Ressourcenüberwachung (nvidia-smi, rocm-smi) und Ergebniszusammenführung zu automatisieren.
Plattformspezifische Konfigurationen
Die Erreichung optimaler Leistung erforderte maßgeschneiderte Konfigurationen für jede Architektur.
NVIDIA-Plattformen (H100, H200, B200)
- Basis-Image: runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
- vLLM-Installation:
- H100/H200 (Hopper): Standardinstallation über pip install vllm.
- B200 (Blackwell): vLLM wurde aus dem Quellcode kompiliert (pip install -e .), um die native Unterstützung für die neue Architektur zu aktivieren und „no kernel image"-Fehler zu beheben.
- Wichtige Parameter:
- Kritische Umgebungsvariable:
AMD-Plattform (MI300X)
- Basis-Image: rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
- vLLM-Installation: Keine Installation erforderlich, da die optimierte Version im Image enthalten war.
- Wichtige Parameter & Optimierungen: Umfangreiche Abstimmung identifizierte die folgenden Nicht-Standard-Einstellungen als kritisch für die Erreichung des maximalen Durchsatzes:
- AMD-spezifische Umgebungsvariablen:
- Gerätesichtbarkeit: ROCR_VISIBLE_DEVICES wurde anstelle des Äquivalents von CUDA verwendet, um Instanzen bestimmten GPUs zuzuweisen.
Phasen der Benchmark-Ausführung
Jeder Benchmark-Lauf folgte einem Drei-Phasen-Ausführungsprotokoll, um genaue und reproduzierbare Ergebnisse zu gewährleisten:
Phase 1: Warmup
Vor jedem Test der Mehr-GPU-Konfiguration führten wir eine dedizierte Warmup-Phase durch, um Kaltstarteffekte zu eliminieren:
- Dauer: 100 Prompts verarbeitet auf GPU 0
- Zweck: Modellladen, KV-Cache-Initialisierung und CUDA/ROCm-Kernel-Kompilierung
- Ausgabe: Verworfen (nicht in Messungen enthalten)
- Plattformspezifisches Verhalten:
- NVIDIA (CUDA): Kernel-Kompilierung und CUDA-Graph-Optimierung (~30-60 Sekunden)
- AMD (ROCm): Kernel-Kompilierung und optionales TunableOp-Tuning (variiert je nach
PYTORCH_TUNABLEOP_ENABLED-Einstellung)
Phase 2: Initialisierung der GPU-Überwachung
Gleichzeitig mit der Benchmark-Ausführung starteten wir dedizierte Überwachungsprozesse für jede GPU:
- Abtastrate: 1-Sekunden-Intervalle
- Erhobene Metriken: GPU-Auslastung, Speichernutzung, Temperatur, Stromverbrauch
- Tools:
nvidia-smi(NVIDIA) oderrocm-smi(AMD) - Ausgabe: CSV-Protokolle für die Nachanalyse
Phase 3: Parallele Benchmark-Ausführung
Nach Abschluss des Warmup wurden alle GPU-Instanzen gleichzeitig gestartet:
- Jede GPU verarbeitete einen gleichen Anteil der 25.000 Gesamtprompts
- Alle Instanzen starteten innerhalb derselben Sekunde, um Lastausgleich in der Produktion zu simulieren
- Gesamtdurchsatz wird als Summe aller GPU-Ausgaben gemessen
- Ausführungszeit gemessen vom Start der ersten Instanz bis zum Abschluss der letzten Instanz
Auswirkungen der Tests auf die reale Leistung
Unsere Tests zeigten, dass kleinere Konfigurationsfehler zu erheblichen, irreführenden Leistungsergebnissen führen können. Die folgende Tabelle veranschaulicht die Auswirkungen plattformspezifischer Fehlkonfigurationen:
Fazit
Für das Serving von Modellen der Klasse 8B-13B ist Datenparallelismus eine hocheffiziente Strategie. Die Wahl der Hardware hängt von den spezifischen Bereitstellungsprioritäten ab.
Für Workloads, bei denen Kosteneffizienz eine primäre Überlegung ist, bietet die NVIDIA H100 günstige Eigenschaften und balanciert Leistungsmetriken, Anschaffungskosten und vorhersehbares Skalierungsverhalten.
Wenn die Maximierung des Durchsatzes das Hauptziel ohne Budgetbeschränkungen ist, weist die NVIDIA H200 die höchsten Leistungsmessungen unter den bewerteten Plattformen auf.
Die AMD MI300X weist bemerkenswerte Eigenschaften für langfristige Bereitstellungsstrategien und AMD-basierte Infrastrukturumgebungen auf. Leistungsverbesserungen werden durch Software-Optimierungsiterationen erwartet, und die erhebliche VRAM-Kapazität der Plattform ermöglicht die Aufnahme größerer Modellarchitekturen.
Die NVIDIA B200 zeigt in dieser spezifischen Workload-Konfiguration Einschränkungen, mit CPU-bedingten Leistungseinschränkungen und suboptimaler Kosteneffizienz. Die Architektur scheint besser für Implementierungen geeignet zu sein, die große Modelle mit Tensor-Parallelismus-Strategien verwenden.
Weiterführende Literatur
Entdecken Sie weitere KI-Hardware-Forschung, wie zum Beispiel:
- Top 20 KI-Chip-Hersteller: NVIDIA & seine Konkurrenten
- Cloud-GPUs für Deep Learning: Verfügbarkeit & Preis/Leistung
- Beste 10 Serverless-GPU-Clouds & 14 kosteneffektive GPUs
- GPU-Concurrency-Benchmark
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{dogan2026,
author = {Dogan, Sedat and Sarı, Ekrem},
title = {{Mehr-GPU-Benchmark: B200 vs H200 vs H100 vs MI300X}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/multi-gpu}},
note = {AIMultiple. Abgerufen am 30. Juni 2026}
}
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.