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

Seit über zwei Jahrzehnten ist die Optimierung der Rechenleistung ein zentraler Bestandteil meiner Arbeit. Wir haben die Modelle B200, H200, H100 und MI300X von NVIDIA hinsichtlich ihrer Skalierbarkeit für die Inferenz großer Sprachmodelle (LLM) getestet. Mithilfe des vLLM-Frameworks und des Modells meta-llama/Llama-3.1-8B-Instruct führten wir Tests auf 1, 2, 4 und 8 GPUs durch.

Wir analysierten Durchsatz und Skalierungseffizienz, um zu veranschaulichen, wie die einzelnen GPU-Architekturen mit parallelisierten, rechenintensiven Arbeitslasten umgehen.

Multi-GPU-Benchmark-Ergebnisse

Gesamtdurchsatz vs. Anzahl der GPUs

• Gesamtdurchsatz (Tokens/Sekunde): Diese Kennzahl repräsentiert die reine Rechenleistung des gesamten Multi-GPU-Systems. Sie misst die Gesamtzahl der pro Sekunde verarbeiteten Eingabe- und Ausgabetokens und ist somit der wichtigste Indikator für maximale Leistung unter Volllast im Offline-Betrieb.

Um zu verstehen, wie wir die Punktzahl berechnet haben, sehen Sie sich unsere Multi-GPU-Benchmark-Methodik an.

Wichtigste Leistungserkenntnisse:

Leistungsanalyse : Die H200 (NVIDIA) bietet den höchsten Durchsatz aller getesteten Konfigurationen und eine um 9–10 % höhere Leistung als die H100. Das System erreicht eine Skalierungseffizienz von 99,8 % bei Dual-GPU-Konfigurationen, was auf eine nahezu optimale Ressourcennutzung hindeutet.

Leistungsmerkmale des MI300X : Der MI300X erreicht mit einer einzelnen GPU einen Durchsatz von 18.752 Token pro Sekunde, was etwa 74 % der Leistung des H200 entspricht. Das System behält Skalierungseffizienzen von 95 % bzw. 81 % für Konfigurationen mit zwei bzw. vier GPUs bei.

Durchschnittliche Inferenzlatenz im Verhältnis zur Anzahl der GPUs

• Durchschnittliche Inferenzlatenz (Millisekunden): Diese Kennzahl misst die durchschnittliche Zeit, die für die Verarbeitung einer einzelnen Anfrage von Anfang bis Ende benötigt wird. Eine geringere Latenz führt zu einer schnelleren und reaktionsfreudigeren Nutzererfahrung.

Wichtigste Leistungserkenntnisse:

Latenzleistungsanalyse : Die B200 (NVIDIA) weist die niedrigsten Latenzwerte aller getesteten Konfigurationen auf und erreicht mit acht GPUs 2,40 ms. Aufgrund dieser Leistungsmerkmale eignet sie sich für Anwendungen mit minimalen Reaktionszeiten, wie beispielsweise interaktive Echtzeitsysteme, bei denen eine Latenz unter 3 ms erforderlich ist.

Beobachtungen zur Skalierungseffizienz : Die Analyse zeigt, dass die Latenzreduzierung mit zunehmender GPU-Anzahl auf allen Plattformen abnimmt. Die größte Latenzreduzierung tritt beim Übergang von Einzel- zu Dual-GPU-Konfigurationen auf (plattformübergreifend ca. 50 %). Konfigurationen mit mehr als vier GPUs weisen zunehmend geringere Latenzverbesserungen auf.

Vergleichsanalyse von H200 und H100 : Die H200 weist über alle Skalierungen hinweg eine um 5–8 % geringere Latenz als die H100 auf, wobei der absolute Unterschied bei höherer GPU-Anzahl abnimmt (2,81 ms gegenüber 2,86 ms bei acht GPUs, ein Unterschied von 0,05 ms). Dieser geringfügige Leistungsunterschied im Vergleich zum Preisunterschied von 41 % deutet darauf hin, dass die H100 für latenzkritische Anwendungen ein günstigeres Preis-Leistungs-Verhältnis bieten könnte.

Latenzcharakteristika des MI300X : Der MI300X weist in den getesteten Konfigurationen 37–75 % höhere Latenzwerte als der H200 auf. Dies ist möglicherweise auf die unterschiedlichen Reifegrade der Software-Stacks von vLLM ROCm und CUDA zurückzuführen. Bei acht GPUs erreicht der MI300X eine Latenz von 4,20 ms, die trotz des Leistungsunterschieds zu anderen Plattformen für zahlreiche Produktionsanwendungen im akzeptablen Bereich liegt.

Leistung vs. Preis: Eine Kosten-Nutzen-Analyse

Obwohl die reinen Leistungskennzahlen entscheidend sind, hängt die letztendliche Entscheidung für jedes Unternehmen von der Kosteneffizienz ab. Um den Return on Investment (ROI) jeder Plattform zu analysieren, haben wir unsere Durchsatzergebnisse mit den On-Demand-Stundenpreisen von RunPod zum Testzeitpunkt verglichen. Dadurch können wir ein „Leistungs-pro-Dollar“-Verhältnis berechnen und so ermitteln, welche Konfiguration die höchste Rechenleistung zu den niedrigsten Kosten bietet.

Hinweis: Alle Preisangaben beziehen sich auf die zum Zeitpunkt der Benchmark-Analyse (September 2025) auf der RunPod Cloud-Plattform verfügbaren On-Demand-Tarife und können sich ändern. Die Kosten dienen Vergleichszwecken und beinhalten keine Speicher- oder Netzwerkgebühren.

Wie wir den Durchsatz pro Dollar berechnet haben

Um dieses Diagramm zu erstellen, haben wir unsere Rohdaten zur Leistung mit den stündlichen Kosten verglichen. Die Berechnungsformel lautet:

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

Dieser Effizienzwert dient als Entscheidungshilfe und verlagert die Diskussion von „Was ist am schnellsten?“ hin zu „Welche Investition ist für unser Arbeitsaufkommen am sinnvollsten?“

Was ist Multi-GPU-Skalierung?

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

Im Idealfall würde der Einsatz zweier GPUs die doppelte Leistung einer einzelnen GPU erzielen (2-fache Beschleunigung). In der Realität werden Leistungssteigerungen jedoch durch CPU- und Systemengpässe, die Zeit, die das Hostsystem für die Verwaltung mehrerer gleichzeitig laufender Prozesse benötigt, Speicherbandbreitenbeschränkungen und Ressourcenkonflikte begrenzt. Unser Benchmark misst, wie effizient jede Plattform diese Systembeschränkungen bewältigt – ein entscheidender Faktor für die Entwicklung kosteneffizienter, leistungsstarker KI-Inferenzserver für kleine bis mittelgroße Modelle.

Welche Herausforderungen ergeben sich bei Multi-GPU-Skalierungstests?

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

Kommunikationsaufwand und Verbindungsengpässe

Wird ein Modell auf mehrere GPUs verteilt, wird die Verbindung, beispielsweise NVLink oder Infinity Fabric, zu einem kritischen Leistungsengpass. Die Effizienz der Kommunikation zwischen den GPUs beeinflusst die Skalierbarkeit direkt. Übersteigt die Wartezeit auf Daten von einer anderen GPU die durch die Parallelisierung der Berechnung eingesparte Zeit, verringern sich die Leistungsgewinne. Dieser Effekt ist besonders ausgeprägt bei Modellen, die nicht groß genug sind, um die Rechenkapazität jeder GPU voll auszuschöpfen.

Reifegrad des Software-Ökosystems

Die Leistung hängt nicht allein von der Hardware ab. Der Software-Stack, einschließlich Treiber, Kommunikationsbibliotheken (wie NCCL für NVIDIA und RCCL für AMD) und der Inferenz-Engine (vLLM), spielt eine entscheidende Rolle. Wir haben festgestellt, dass die Leistung einer Plattform eng mit der Reife ihrer Softwareunterstützung verknüpft ist. Ein etabliertes Ökosystem wie CUDA (NVIDIA) profitiert oft von jahrelanger Feinabstimmung und Optimierung, was im Vergleich zu neueren Integrationen wie ROCm (AMD) selbst auf leistungsstarker Hardware zu einer überlegenen Skalierungseffizienz führen kann.

Plattformspezifische Optimierungen

Wie unsere Tests zeigten, erfordert optimale Leistung häufig plattformspezifische Konfigurationen. Ein generischer, universeller Ansatz kann zu irreführend niedriger Leistung führen. Das korrekte Docker-Image, die Umgebungsvariablen (z. B. die Aktivierung benutzerdefinierter AMD-Kernel) und sogar die Modelldatentypen (z. B. bfloat16 für Blackwell) sind entscheidend, um das volle Potenzial der Hardware auszuschöpfen. Dies macht faire Vergleiche zwischen verschiedenen Systemen zu einer erheblichen technischen Herausforderung.

Multi-GPU-Benchmark-Methodik

Wir haben die neuesten Hochleistungs-GPU-Architekturen der Versionen NVIDIA und AMD getestet, um ihre Skalierbarkeit zu bewerten. Unser Benchmark maß die Leistung von Einzel- und Multi-GPU-Konfigurationen (1x, 2x, 4x, 8x) mithilfe des Standard-Meta-Llama/Llama-3.1-8B-Instruct-Frameworks. ¹ Modell und das vLLM ² Inferenzmaschine.

Testumgebung und -prozess

• Plattform : Alle Benchmarks wurden auf RunPod Cloud ausgeführt, um einen konsistenten Hardwarezugriff zu gewährleisten .
• Inferenzmaschine : Als standardisierte Maschine wurde vLLM (vllm bench throughput tool) verwendet.
• Modell : meta-llama/Llama-3.1-8B-Instruct.
• Datensatz : ShareGPT Vicuna-Datensatz (25.000 Eingabeaufforderungen) zur Simulation einer Konversationslast.
• Strategie : Datenparallelität; jeder Multi-GPU-Test führte eine unabhängige vLLM-Instanz auf jeder GPU aus. Die gesamte Eingabelast wurde gleichmäßig auf die Instanzen verteilt, die gleichzeitig ausgeführt wurden, um eine lastverteilte Produktionsumgebung zu simulieren. Dieser Ansatz eliminiert die Kommunikation zwischen den GPUs (NVLink/PCIe) als Flaschenhals und verlagert die Leistungsbegrenzung auf das Hostsystem (CPU, RAM).
• Automatisierung : Zur Automatisierung der Umgebungseinrichtung, der Testausführung, der Ressourcenüberwachung (nvidia-smi, rocm-smi) und der Ergebnisaggregation wurden benutzerdefinierte Bash-Skripte verwendet.

Plattformspezifische Konfigurationen

Um eine 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 Fehler vom Typ „no kernel image“ zu beheben.
• Wichtige Parameter :

• Kritische Umweltvariable :

Plattform AMD (MI300X)

• Basis-Image : rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
• vLLM-Installation : Eine Installation war nicht erforderlich, da die optimierte Version im Image enthalten war.
• Wichtige Parameter & Optimierungen : Umfangreiche Optimierungstests haben die folgenden, nicht standardmäßigen Einstellungen als entscheidend für die Erzielung eines maximalen Durchsatzes identifiziert:

• AMD-spezifische Umgebungsvariablen :

• Gerätesichtbarkeit : Zur Zuordnung von Instanzen zu bestimmten GPUs wurde ROCR_VISIBLE_DEVICES anstelle des CUDA-Äquivalents verwendet.

Benchmark-Ausführungsphasen

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

Phase 1: Aufwärmen

Vor jedem Multi-GPU-Konfigurationstest führten wir eine separate Aufwärmphase durch, um Kaltstarteffekte auszuschließen:

• Dauer: 100 Eingabeaufforderungen wurden auf GPU 0 verarbeitet.
• Zweck: Laden von Modellen, Initialisierung des KV-Caches und CUDA/ROCm-Kernelkompilierung
• Ausgabe: Verworfen (nicht in die Messungen einbezogen)
• Plattformspezifisches Verhalten:
  • NVIDIA (CUDA): Kernel-Kompilierung und CUDA-Graphoptimierung (~30-60 Sekunden)
  • AMD (ROCm): Kernel-Kompilierung und optionale TunableOp-Optimierung (variiert je nach Einstellung PYTORCH_TUNABLEOP_ENABLED)

Phase 2: Initialisierung der GPU-Überwachung

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

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

Phase 3: Parallele Benchmark-Ausführung

Nach Abschluss der Aufwärmphase wurden alle GPU-Instanzen gleichzeitig gestartet:

• Jede GPU verarbeitete einen gleichen Anteil der insgesamt 25.000 Eingabeaufforderungen.
• Alle Instanzen wurden innerhalb derselben Sekunde gestartet, um die Lastverteilung in der Produktionsumgebung zu simulieren.
• Der Gesamtdurchsatz wird als Summe aller GPU-Ausgaben gemessen.
• Die Ausführungszeit wurde vom Start der ersten Instanz bis zum Abschluss der letzten Instanz gemessen.

Auswirkungen der Tests auf die reale Leistung

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

Weiterführende Literatur

Erkunden Sie weitere Forschungsarbeiten im Bereich KI-Hardware, wie zum Beispiel:

• Die 20 größten Hersteller von KI-Chips: NVIDIA und ihre Wettbewerber
• Cloud-GPUs für Deep Learning: Verfügbarkeit und Preis/Leistung
• Die 10 besten serverlosen GPU-Clouds und 14 kostengünstige GPUs
• GPU-Parallelitäts-Benchmark

Referenzlinks

1.

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

2.

https://docs.vllm.ai/en/latest/

Sedat Dogan

CTO

Folgen auf

Sedat ist ein führender Experte für Technologie und Informationssicherheit mit Erfahrung in Softwareentwicklung, Web-Datenerfassung und Cybersicherheit. Sedat: – Verfügt über 20 Jahre Erfahrung als White-Hat-Hacker und Entwicklungsexperte mit umfassenden Kenntnissen in Programmiersprachen und Serverarchitekturen. – Berät Führungskräfte und Vorstandsmitglieder von Unternehmen mit hohem Datenverkehr und geschäftskritischen Technologieanwendungen wie Zahlungsinfrastruktur. – Besitzt neben seiner technischen Expertise auch ausgeprägtes betriebswirtschaftliches Verständnis.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten