Multi-GPU-Benchmark: B200 vs. H200 vs. H100 vs. MI300X

Seit über zwei Jahrzehnten ist die Optimierung der Rechenleistung ein Eckpfeiler meiner Arbeit. Wir haben NVIDIA-B200, -H200, H100 und AMD-MI300X einem Benchmark unterzogen, um zu bewerten, wie gut sie für die Inferenz von Large Language Models (LLM) skalieren. Mit dem vLLM-Framework und dem Modell meta-llama/Llama-3.1-8B-Instruct haben wir Tests auf 1, 2, 4 und 8 GPUs durchgeführt.

Wir haben Durchsatz und Skalierungseffizienz analysiert, um zu veranschaulichen, wie jede GPU-Architektur parallelisierte, rechenintensive Arbeitslasten bewältigt.

Multi-GPU-Benchmark-Ergebnisse

Gesamtdurchsatz vs. GPU-Anzahl

• Gesamtdurchsatz (Tokens/Sekunde): Diese Metrik repräsentiert die reine Verarbeitungsleistung des gesamten Multi-GPU-Systems. Sie misst die Gesamtzahl der pro Sekunde verarbeiteten Eingabe- und Ausgabetokens und ist damit der wichtigste Indikator für die maximale Leistung bei einer gesättigten, Offline-Arbeitslast.

Um zu verstehen, wie wir die Punktzahl berechnet haben, siehe unsere Multi-GPU-Benchmark-Methodik.

Wichtige Leistungserkenntnisse:

Leistungsanalyse: Die NVIDIA H200 liefert den höchsten Durchsatz über alle getesteten Konfigurationen hinweg, mit 9-10 % Leistungsverbesserungen gegenüber H100. Das System erreicht eine Skalierungseffizienz von 99,8 % bei Dual-GPU-Konfigurationen, was auf eine nahezu optimale Ressourcennutzung hinweist.

AMD-MI300X-Leistungsmerkmale: Die AMD MI300X erreicht einen Single-GPU-Durchsatz von 18.752 Tokens pro Sekunde, was etwa 74 % der Leistung des H200 entspricht. Das System hält Skalierungseffizienzen von 95 % und 81 % für Zwei-GPU- bzw. Vier-GPU-Konfigurationen aufrecht.

Durchschnittliche Inferenzlatenz vs. GPU-Anzahl

• Durchschnittliche Inferenzlatenz (Millisekunden): Diese Metrik misst die durchschnittliche Zeit, die benötigt wird, um eine einzelne Anfrage von Anfang bis Ende zu verarbeiten. Geringere Latenz führt zu einer schnelleren, reaktionsschnelleren Erfahrung für Endbenutzer.

Wichtige Leistungserkenntnisse:

Latenz-Leistungsanalyse: Die NVIDIA B200 weist die niedrigsten Latenzmesswerte über alle bewerteten Konfigurationen hinweg auf und erreicht 2.40ms bei Acht-GPU-Implementierungen. Diese Leistungsmerkmale prädestinieren sie für Anwendungen, die minimale Reaktionszeiten erfordern, wie z. B. interaktive Echtzeitsysteme, bei denen eine Latenz von unter 3ms eine Designanforderung ist.

Beobachtungen zur Skalierungseffizienz: Die Analyse zeigt abnehmende Erträge bei der Latenzreduzierung, wenn die GPU-Anzahl über alle Plattformen hinweg zunimmt. Die größte Latenzreduzierung tritt beim Übergang von Single- auf Dual-GPU-Konfigurationen auf (plattformübergreifend etwa 50 %). Konfigurationen mit mehr als 4 GPUs zeigen zunehmend geringere Latenzverbesserungen.

Vergleichsanalyse H200 und H100: Die H200 weist auf allen Skalen eine um 5-8 % niedrigere Latenz als die H100 auf, wobei die absolute Differenz bei höherer GPU-Anzahl abnimmt (2.81ms gegenüber 2.86ms bei acht GPUs, eine Differenz von 0.05ms). Dieser marginale Leistungsunterschied deutet im Vergleich zu dem Preisunterschied von 41 % darauf hin, dass die H100 möglicherweise günstigere Kosten-Leistungs-Eigenschaften für latenzempfindliche Bereitstellungen bietet.

AMD-MI300X-Latenzmerkmale: Die MI300X weist über die getesteten Konfigurationen hinweg um 37-75 % höhere Latenzwerte als die H200 auf, was auf die derzeitigen Unterschiede in der Reife der Software-Stacks zwischen vLLM ROCm und CUDA-Implementierungen zurückzuführen sein könnte. Bei einer Skalierung mit acht GPUs erreicht die MI300X eine Latenz von 4.20ms, die trotz des Leistungsunterschieds gegenüber NVIDIA-Plattformen für zahlreiche Produktionsanwendungen akzeptabel bleibt.

Leistung vs. Preis: Eine Kosten-Effizienz-Analyse

Während rohe Leistungskennzahlen entscheidend sind, hängt die endgültige Entscheidung für jedes Unternehmen von der Kosteneffizienz ab. Um den Return on Investment (ROI) für jede Plattform zu analysieren, haben wir unsere Durchsatzergebnisse den On-Demand-Stundenpreisen von RunPod zum Testzeitpunkt gegenübergestellt. Dadurch können wir einen „Performance-pro-Dollar“-Wert berechnen, der zeigt, welches Setup die meiste Rechenleistung zu den niedrigsten Kosten bietet.

Hinweis: Alle Preisinformationen spiegeln die zum Zeitpunkt des Benchmarks (September 2025) auf der RunPod Cloud-Plattform verfügbaren On-Demand-Tarife wider und können sich ändern. Die Kosten werden zu Vergleichszwecken angegeben und enthalten keine Speicher- oder Netzwerkgebühren.

Wie wir den Durchsatz pro Dollar berechnet haben

Um dieses Diagramm zu erstellen, haben wir unsere rohen Leistungsdaten mit den Stundenkosten verrechnet. Die Berechnungsformel lautet:

• Datenaufbereitung: Für jeden Datenpunkt in unserer Ergebnistabelle haben wir die entsprechenden Stundenkosten für die jeweilige GPU-Konfiguration abgerufen (z. B. 4x H100 kostet $10,76).
• Berechnung: Anschließend haben wir die Formel angewendet, um den Wert throughput_per_dollar zu berechnen. Beispielsweise lieferte die H100 mit 1x GPU 23.243 Tokens/s bei Kosten von $2,69/Std., was zu einem Wert von 8.642 Tokens/s pro Dollar führt.

Dieser Effizienzwert bietet ein Entscheidungsinstrument und verschiebt die Fragestellung von „Was ist am schnellsten?“ zu „Was ist die cleverste Investition für unsere Arbeitslast?“

Was ist Multi-GPU-Skalierung?

Multi-GPU-Skalierung bezeichnet die Fähigkeit eines Systems, seine Leistung zu steigern, indem es eine einzelne große Aufgabe auf mehrere GPUs verteilt. Für die LLM-Inferenz kann dies durch Datenparallelität erreicht werden, wobei unabhängige Modellkopien auf jeder GPU ausgeführt werden und ein Load Balancer eingehende Anfragen auf alle Instanzen verteilt.

Im Idealfall würde die Verwendung von zwei GPUs die doppelte Leistung einer einzelnen GPU liefern (2x Beschleunigung). In der Realität werden die Leistungsgewinne jedoch durch CPU- und Systemengpässe, die Zeit, die das Host-System mit der Verwaltung mehrerer gleichzeitiger Prozesse verbringt, Speicherbandbreitenbeschränkungen und Ressourcenkonflikte begrenzt. Unser Benchmark misst, wie effizient jede Plattform diese Systembeschränkungen verwaltet – ein entscheidender Faktor für den Aufbau kosteneffizienter, leistungsstarker KI-Inferenzserver für kleine bis mittlere Modelle.

Was sind die Herausforderungen bei Multi-GPU-Skalierungstests?

Das Benchmarking von Multi-GPU-Systemen birgt besondere Herausforderungen, die Leistung erheblich beeinflussen können.

Kommunikationsaufwand und Interconnect-Engpässe

Wenn ein Modell auf mehrere GPUs aufgeteilt wird, wird der Interconnect wie NVIDIA-NVLink oder AMD-Infinity Fabric zu einem kritischen Leistungsengpass. Die Effizienz der Inter-GPU-Kommunikation wirkt sich direkt auf die Skalierung aus. Wenn die Zeit, die mit dem Warten auf Daten von einer anderen GPU verbracht wird, die durch die Parallelisierung der Berechnung eingesparte Zeit übersteigt, werden die Leistungsgewinne abnehmen. Dieser Effekt ist besonders ausgeprägt bei Modellen, die nicht groß genug sind, um die Rechenkapazität jeder einzelnen GPU vollständig auszulasten.

Reife des Software-Ökosystems

Die Leistung hängt nicht nur von der Hardware ab. Der Software-Stack, einschließlich Treibern, Kommunikationsbibliotheken (wie NCCL für NVIDIA und RCCL für AMD) und der Inferenz-Engine (vLLM), spielt eine enorme Rolle. Wir haben festgestellt, dass die Leistung einer Plattform eng mit der Reife ihrer Software-Unterstützung verbunden ist. Ein etabliertes Ökosystem wie NVIDIA-CUDA profitiert oft von jahrelangem Fine-Tuning und Optimierung, was zu einer überlegenen Skalierungseffizienz im Vergleich zu neueren Integrationen wie AMD-ROCm führen kann, selbst auf leistungsfähiger Hardware.

Plattformspezifische Optimierungen

Wie unsere Tests gezeigt haben, erfordert das Erreichen optimaler Leistung oft plattformspezifische Konfigurationen. Ein generischer „One-size-fits-all“-Ansatz kann zu irreführend niedriger Leistung führen. Das richtige Docker-Image, Umgebungsvariablen (z. B. das Aktivieren benutzerdefinierter AMD-Kernel) und sogar Modelldatentypen (z. B. bfloat16 für Blackwell) sind entscheidend, um das wahre Potenzial der Hardware freizusetzen. Dies macht faire „Apple-zu-Apple“-Vergleiche zu einer erheblichen technischen Herausforderung.

Multi-GPU-Benchmark-Methodik

Wir haben die neuesten Hochleistungs-GPU-Architekturen von NVIDIA und AMD getestet, um ihre Skalierungsfähigkeiten zu bewerten. Unser Benchmark hat die Leistung von Single- und Multi-GPU-Konfigurationen (1x, 2x, 4x, 8x) mit dem Standardmodell meta-llama/Llama-3.1-8B-Instruct¹ Modell und die vLLM² Inferenz-Engine.

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.
• Dataset: ShareGPT Vicuna dataset (25.000 Prompts), um eine konversationelle Arbeitslast zu simulieren.
• Strategie: Datenparallelität; jeder Multi-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 lastverteilte Produktionsumgebung zu simulieren. Dieser Ansatz eliminiert die Inter-GPU-Kommunikation (NVLink/PCIe) als Engpass und verlagert die Leistungsbegrenzer auf das Host-System (CPU, RAM).
• Automatisierung: Es wurden benutzerdefinierte Bash-Skripte verwendet, um die Einrichtung der Umgebung, die Testausführung, die Ressourcenüberwachung (nvidia-smi, rocm-smi) und die Ergebnisaggregation zu automatisieren.

Plattformspezifische Konfigurationen

Um optimale Leistung zu erzielen, waren maßgeschneiderte Konfigurationen für jede Architektur erforderlich.

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 native Unterstützung für die neue Architektur zu ermöglichen und „No kernel image“-Fehler zu beheben.
• Schlüsselparameter:

• Kritische Umgebungsvariable:

AMD-Plattform (MI300X)

• Basis-Image: rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
• vLLM-Installation: Es war keine Installation erforderlich, da die optimierte Version bereits im Image enthalten war.
• Schlüsselparameter & Optimierungen: Umfangreiche Abstimmungen haben die folgenden nicht standardmäßigen Einstellungen als entscheidend für das Erreichen des maximalen Durchsatzes identifiziert:

• AMD-spezifische Umgebungsvariablen:

• Sichtbarkeit der Geräte: ROCR_VISIBLE_DEVICES wurde anstelle des CUDA-Äquivalents verwendet, um Instanzen bestimmten GPUs zuzuweisen.

Benchmark-Ausführungsphasen

Jeder Benchmark-Lauf folgte einem dreiphasigen Ausführungsprotokoll, um genaue und reproduzierbare Ergebnisse zu gewährleisten:

Phase 1: Warmup

Vor jedem Test mit Multi-GPU-Konfigurationen haben wir eine dedizierte Aufwärmphase durchgeführt, um Kaltstarteffekte zu vermeiden:

• Dauer: 100 Prompts wurden auf GPU 0 verarbeitet
• Zweck: Laden des Modells, Initialisierung des KV-Cache sowie Kompilierung der CUDA-/ROCm-Kernel
• Ausgabe: Verworfen (nicht in den Messungen enthalten)
• Plattformspezifisches Verhalten:
  • NVIDIA (CUDA): Kernel-Kompilierung und CUDA-Graph-Optimierung (~30-60 Sekunden)
  • AMD (ROCm): Kernel-Kompilierung und optionale TunableOp-Abstimmung (variiert je nach Einstellung PYTORCH_TUNABLEOP_ENABLED)

Phase 2: GPU-Überwachungsinitialisierung

Parallel zur Benchmark-Ausführung haben wir für jede GPU dedizierte Überwachungsprozesse gestartet:

• Abtastrate: Intervalle von 1 Sekunde
• Erfasste Metriken: GPU-Auslastung, Speichernutzung, Temperatur, Stromverbrauch
• Tools: nvidia-smi (NVIDIA) oder rocm-smi (AMD)
• Ausgabe: CSV-Protokolle für die Nachanalyse

Phase 3: Parallele Benchmark-Ausführung

Nach Abschluss des Aufwärmens wurden alle GPU-Instanzen gleichzeitig gestartet:

• Jede GPU verarbeitete einen gleichen Anteil der 25.000 Gesamtprompts
• Alle Instanzen wurden innerhalb derselben Sekunde gestartet, um eine Produktions-Lastverteilung zu simulieren
• Gesamtdurchsatz wird als Summe aller GPU-Ausgaben gemessen
• Ausführungszeit gemessen vom Start der ersten Instanz bis zum Abschluss der letzten Instanz

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Praktische Leistungsauswirkungen der Tests

Unsere Tests haben gezeigt, dass geringfügige Konfigurationsfehler zu erheblichen, irreführenden Leistungsergebnissen führen können. Die folgende Tabelle veranschaulicht die Auswirkungen plattformspezifischer Fehlkonfigurationen:

Weiterführende Literatur

Entdecken Sie weitere KI-Hardware-Forschung, z. B.:

• Top 30 Cloud-GPU-Anbieter & ihre GPUs
• GPU-Nebenläufigkeits-Benchmark
• Top 25+ KI-Chiphersteller: NVIDIA & seine Wettbewerber

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  = {{Multi-GPU-Benchmark: B200 vs. H200 vs. H100 vs. MI300X}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Abgerufen am 21. September 2026}
}

Änderungsprotokoll

2 Aktualisierungen

2025

1. 8. Okt

   Das Dataset im Abschnitt „Multi-GPU-Benchmark-Ergebnisse“ wurde aktualisiert.

2. 6. Okt

   Die Metrik „Anfragen pro Sekunde“ wurde aus dem Abschnitt „Gesamtdurchsatz vs. GPU-Anzahl“ entfernt.

Referenzlinks

1.

meta-llama/Llama-3.1-8B-Instruct · Hugging Face

2.

vLLM easy, fast, and cheap LLM serving for everyone

Sedat Dogan

CTO

Folgen auf

Sedat ist eine Führungskraft im Bereich Technologie und Informationssicherheit mit 20 Jahren Erfahrung in Softwareentwicklung, Netzwerkinfrastruktur und Cybersicherheit. Sedat:
- Verfügt über 20 Jahre Erfahrung als White-Hat-Hacker und Entwicklungsguru mit umfassender Expertise in Programmiersprachen und Serverarchitekturen.
- Ist Beiratsmitglied bei einer VC, die in frühphasige Technologieunternehmen investiert, und bei Ödeal, einer regionalen digitalen Zahlungsplattform, die 125.000 Händler bedient.
- Hat die technologische Infrastruktur und Cybersicherheit von sieben nationalen Wahlen geleitet und wurde von globalen Technologieführern wie Twitter in die Hall of Fame für Cybersicherheit aufgenommen.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenwissenschaftler bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten