Turboaufladung für Llama 2 70B mit NVIDIA H100

Das Streben nach Leistung in Perplexitys Antwort-Engine treibt uns dazu an, die neueste Technologie einzusetzen, die NVIDIA und AWS zu bieten haben. In diesem Blog freuen wir uns, die Ergebnisse unserer neuesten Experimente zu teilen: einen Vergleich der Llama 2 70B-Inferenz über verschiedene Hardware- und Softwarekonfigurationen hinweg.

Unsere LLM-Inferenzplattform pplx-api basiert auf einem hochmodernen Stack, der von Open-Source-Bibliotheken angetrieben wird. Seit Beginn der öffentlichen Beta-Phase von pplx-api im Oktober haben wir uns den Herausforderungen der Skalierung gestellt und gelernt, wie wir unsere Konfiguration am besten abstimmen können, um eine massive Skalierung zu erreichen. Dies führte dazu, dass wir Experimente mit den folgenden Leitfragen durchgeführt haben:

Was ist der reine Leistungszuwachs durch die Umstellung unserer GPUs von NVIDIA A100 auf NVIDIA H100, während alle anderen Einstellungen gleich bleiben?

Wie hoch ist der Effizienzgewinn durch 8-Bit-Fließkomma-Quantisierung (fp8), für die die H100 native Unterstützung bietet? Wie hoch ist der Genauigkeitsverlust dieser Quantisierung?

Wie wirken sich Tensor-Parallelität und Batch-Größe auf Latenz und Token-Durchsatz aus?

Welche Konfiguration führt in Anbetracht dessen zum skalierbarsten Gleichgewicht zwischen Leistung und Kosteneffizienz?

Wir haben das folgende Experiment als eine Reihe lokaler Benchmarks durchgeführt, um Netzwerklatenz zu vermeiden.

Latenz: Die Gesamtzeit, die der Inferenz-Server benötigt, um seine vollständige Antwort zu generieren.

Durchsatz: Die Anzahl der Ausgabe-Token pro Sekunde und GPU, die der Inferenz-Server über alle Benutzer und Anfragen hinweg generieren kann.

Die folgenden Faktoren beeinflussen die wichtigen Metriken, daher haben wir sie über verschiedene Testläufe des Experiments hinweg konstant gehalten.

Die Leistung skaliert mit der Größe des LLM. Mehr Parameter erfordern mehr Berechnungen, was zu einer langsameren Inferenz führt. Zum Beispiel ist Llama 2 13B schneller als Llama 2 70B, wenn andere Einstellungen gleich sind. Wir bleiben in diesem Experiment bei Llama 2 70B, weil wir die Bereitstellung der leistungsfähigsten Open-Source-Modelle optimieren möchten.

Die Anzahl der Eingabe- und Ausgabe-Token in jedem Beispiel für Anfragen/Antwort-Paare kann die Leistungsmessungen beeinflussen. Im Allgemeinen dominiert die Generierung von Ausgabe-Token die Gesamtreaktionszeit. Wenn die Datenerfassung nur "Ja/Nein"-Antworten vom LLM hervorruft, ist die Antwort schneller im Vergleich zu Beispielen, bei denen das LLM Essays schreiben muss. Unser Datensatz besteht aus synthetischen Anfragen mit 1024 Eingabe-Token, die 512 Ausgabe-Token induzieren. Diese Verteilung wurde gewählt, um der beobachteten Verkehrsverteilung auf unserer öffentlichen Bereitstellung von Llama2 70B zu entsprechen.

NVIDIA TensorRT-LLM (Release v0.5.0) ist eine Open-Source-Bibliothek zur Optimierung der LLM-Inferenz. Sie wurde Ende 2023 veröffentlicht, synthetisiert viele Inferenz-Optimierungen von NVIDIA und bietet eine flexible Anpassungsschicht für die Schlüsselparameter dieses Experiments: Batch-Größe, Quantisierung und Tensor-Parallelität.

Wir haben über 4 Konfigurationsachsen experimentiert: Tensor-Parallelität, GPU-Architektur, Quantisierung und maximale Batch-Größe. Diese Achsen sind miteinander verbunden, da sie jeweils einen Kompromiss in Bezug auf die kritische Engpassressource des GPU-Speichers darstellen.

Die Architektur der Hopper-GPU der neunten Generation (H100-HBM3-80GB / p5.48xlarge) bietet eine riesige Liste von Funktionen gegenüber ihrem Vorgänger, Ampere (A100-SXM4-80GB / p4de.24xlarge), einschließlich 2x-6x Rechenraten und fast 2x GPU-Speicherbandbreite. Die GPU-Speicherbandbreite ist eine kritische Metrik für die Inferenz, da ein primärer Latenzengpass bei den Matrixmultiplikationen der Inferenz darin besteht, Gigabytes an Modelldaten vom GPU-Speicher in Rechenregister zu laden. Basierend auf diesen Statistiken stellten wir die Hypothese auf, dass ein direkter Vergleich von NVIDIA H100 und A100 eine 2-fache Verbesserung sowohl bei der Latenz als auch beim Durchsatz aufweisen wird.

Ein weiterer wesentlicher Unterschied zwischen NVIDIA H100 und A100 besteht darin, dass der H100-Tensor-Kern nativ Unterstützung für 8-Bit-Fließkomma-Instruktionen (fp8) hinzufügt, was den Weg für weitere unten detaillierte Optimierungen ebnet. Deshalb verwenden wir fp8 und fp16 speziell für die H100.

Um den Speicher pro GPU in diesem Experiment konsistent zu halten, blieben wir bei Knoten mit 8x80GB GPU-Speicher sowohl für unsere NVIDIA A100 als auch für H100. Neben der Ermöglichung höherer Batch-Größen ist der GPU-Speicher wichtig, weil die Parameter des Modells während des Serverstarts für schnellen Zugriff in den GPU-Speicher geladen werden. Wenn zum Beispiel jeder der 70 Milliarden Parameter in unserem Modell eine 16-Bit-Fließkommazahl ist, dann ist das Modell etwa 140 GB groß, was nicht auf eine einzelne GPU passt. Daher die Notwendigkeit für Tensor-Parallelität, die wir unten erklären.

Tensor-Parallelität bezieht sich auf die Anzahl der GPU-Geräte, die zum Ausführen des Inferenz-Servers verbraucht werden. Wenn wir eine Anzahl von GPUs zuweisen, bündelt TensorRT-LLM deren Ressourcen, um uns zu helfen, das erforderliche Mindest-Speicherbudget für die Ausführung von Llama2 70B zu erreichen. Unsere Hypothese ist, dass eine geringere Tensor-Parallelität zu einer höheren Latenz führt (aufgrund weniger Ressourcen, die verbraucht werden, um jede Charge zu befriedigen), aber zu einem höheren Durchsatz pro GPU (aufgrund besserer Auslastung) im Vergleich zu einer höheren Tensor-Parallelität.

Quantisierung ist die Reduzierung der Präzision bei den Gewichten und Aktivierungen, die von neuronalen Netzwerken verwendet werden. Wir verwenden diese Technik, um den GPU-Speicherverbrauch zu halbieren, wenn wir von fp16 auf fp8 wechseln. Dies ermöglicht es, dasselbe Modell mit geringerem gesamten GPU-Speicherbedarf auszuführen, was eine geringere Tensor-Parallelität ermöglicht, was den Durchsatz erhöht.

Implementierungen der Quantisierung haben das Potenzial, die Genauigkeit zu verschlechtern. Daher haben wir die Genauigkeit für verschiedene Präzisionen bewertet, indem wir ihre Perplexity-Statistik verglichen haben, ein Maß dafür, wie gut das LLM jedes nächste Token in einem Satz auf dem WikiText-Korpus vorhersagt. Für 8-Bit-Fließkomma und 8-Bit-Gewicht mit 8-Bit-Aktivierung und SmoothQuant (w8a8 SQ) gab es keine signifikante Änderung der Perplexity (< 1%) im Vergleich zu fp16 auf WikiText, daher fühlten wir uns sicher, fortzufahren. Jedoch wies w4a16 eine wesentliche 7% Änderung der Perplexity auf, potenziell zurückzuführen auf die noch niedrigere Präzision und notwendige dynamische Konvertierungen zwischen int4 und fp16.

Parallelität durch Batching ist eine klassische Strategie, um Leistung aus einem ressourcenbeschränkten System zu quetschen. Durch die Verarbeitung mehrerer Anfragen in jedem Vorwärtspass durch das neuronale Netzwerk ist Batching dafür bekannt, den Durchsatz auf Kosten einer gewissen Latenz zu erhöhen. Batching verursacht auch einen höheren GPU-Speicherverbrauch, weil die Größe des KV-Cache, der den Aufmerksamkeitsmechanismus verwaltet, linear mit der Batch-Größe wächst.

Im Fall von Llama 2 70B (das 80 Schichten hat), fp16 mit Batch-Größe 32 für 4096 Kontextgröße, beläuft sich die Größe des KV-Cache auf beträchtliche 40 GB. Dies verhindert letztendlich, dass Llama 2 70B fp16, dessen Gewichte allein 140GB beanspruchen, bequem in den 160GB GPU-Speicher passt, der bei Tensor-Parallelität 2 (TP-2) verfügbar ist.

Wir haben kompatible Kombinationen der 4 Variablen des Experiments durchlaufen und präsentieren die aufschlussreichsten Trends unten.

Abbildung 1 - Die Latenz von Anfragen mit variierender Batch-Größe über fünf verschiedene Konfigurationen hinweg, alle mit Tensor-Parallelität 8, was die beste Latenz mit 8 verfügbaren GPUs liefert. Innerhalb jeder Konfiguration verdoppelt sich die Latenz im Allgemeinen, wenn die Batch-Größe von 1 auf 32 erhöht wird, und verdoppelt sich erneut von 32 auf 128. Bei ausreichend großen Batch-Größen halbiert H100 ungefähr die Latenz im Vergleich zu A100. A100 verwendet gemischte Präzision, da der Architektur die native Unterstützung für fp8 fehlt. w8a8 mit SmoothQuant (SQ) soll fp8 ähneln.

Die Latenzverbesserung durch Quantisierung liegt in der Größenordnung von 10%, wenn man H100 fp16 → fp8 und A100 fp16 → w8a8 mit SmoothQuant vergleicht. Die gemischte Präzision w4a16 schneidet jedoch bei niedrigen Batch-Größen tatsächlich besser und bei höheren Batch-Größen schlechter ab im Vergleich zu fp16. Dies kann auf eine Reihe von Faktoren zurückzuführen sein, einschließlich weniger optimierter Rechenkerne, Casting-Zeit zwischen int4 und fp16 sowie der Tatsache, dass w4a16 weiterhin 16-Bit-Fließkommazahlen für Aktivierungen verwendet, was zu keinen Einsparungen bei den Dimensionen des KV-Cache führt. Da w4a16 auch eine geringere Genauigkeit zeigte, schließen wir daraus, dass wir bei w8a8 SQ für A100s und fp8 für H100s bleiben sollten.

Abbildung 2 - Der Durchsatz über TP-8-Konfigurationen hinweg mit unterschiedlicher Architektur, Quantisierung und Batch-Größe. Für jede Architektur und Quantisierung wurde die Batch-Größe als die größte gewählt, die eine Latenzanforderung von 25600ms (20 Token pro Sekunde für 512 Token) erfüllte, damit wir Konfigurationen mit ähnlicher Latenz vergleichen können. Unter dieser Anforderung erreicht H100 mit BS-128 228% Durchsatz im Vergleich zu A100 BS-64 unter Verwendung derselben Quantisierung (fp16) und hat sogar eine geringere Antwortlatenz trotz der verdoppelten Batch-Größe. Quantisierung mit fp8 verbessert diesen Faktor auf 251%.

In unseren ersten beiden Abbildungen präsentieren wir nur Konfigurationen von TP-8. H100 erreicht 54% Latenz und 184% Durchsatz im Vergleich zu A100, wenn beide fp16 / BS-128 / TP-8 verwenden, was sich auf 49% Latenz und 202% Durchsatz verbessert, wenn fp8 auf H100 verwendet wird. Diese Leistungsverbesserung kann auf die Steigerungen der Rechenleistung und Speicherbandbreite zwischen H100 und A100 zurückgeführt werden. Bemerkenswert ist, dass der Unterschied bei niedrigeren Batch-Größen weniger ausgeprägt ist, wo die Auslastung möglicherweise geringer ist.

Während wir unsere Plattform aufbauen, wollen wir bestimmte Latenzanforderungen für unsere Benutzer einhalten und gleichzeitig den Durchsatz maximieren. Daher ist es sinnvoller, A100 vs. H100 nicht bei derselben Batch-Größe zu vergleichen, sondern deren Durchsatz nur unter Konfigurationen, in denen sie eine Latenzanforderung erfüllen. Wir haben eine Grenze bei 25600ms Latenz für die Fertigstellung der 512 Ausgabe-Token gesetzt und festgestellt, dass H100 / TP-8 / fp8 / BS-128 251% Durchsatz im Vergleich zu A100 / TP-8 / fp16 / BS-64 liefert, da es in der Lage ist, die doppelte Batch-Größe bei einer niedrigeren Latenz zu verarbeiten. Da die Quantisierung GPU-Speichereinsparungen bietet, müssen wir nun bewerten, wie Tensor-Parallelität eine nächste Ebene der Optimierung hinzufügen kann.

Abbildung 3 - Die Latenz über variierende Batch-Größen und Tensor-Parallelität für H100 fp8. Die Latenz verdoppelt sich im Allgemeinen, wenn die Batch-Größe von 1 auf 32 erhöht wird, und verdoppelt sich erneut von 32 auf 128. TP-2 ist konsistent etwa doppelt so langsam wie TP-8, wenn die Batch-Größen gleich sind. Eine Verdoppelung der Tensor-Parallelität bei gleichzeitiger Verdoppelung der Batch-Größe hält die Latenz relativ stabil, da die Anzahl der pro GPUs verarbeiteten Batches gleich bleibt.

Wenn es um Quantisierung und Architektur geht, gibt es klare Gewinner: H100 dominiert A100 und eine Quantisierung mit niedrigerer Präzision verbessert Speicherauslastung, Latenz und Durchsatz. Batch-Größe und Tensor-Parallelität stellen jedoch einen Kompromiss bei unseren wichtigen Metriken dar. Eine größere Batch-Größe optimiert für Durchsatz auf Kosten erhöhter Latenz und Speicherverbrauch. Andererseits erhöht eine höhere Tensor-Parallelität den gesamten Pool an verfügbarem Speicher und optimiert für Latenz, tauscht dies jedoch gegen Durchsatz aufgrund von Synchronisationskosten bei verteilter Matrixmultiplikation und durch das Belegen von mehr GPU-Ressourcen.

Abbildung 4 - Der Durchsatz über variierende Batch-Größen und Tensor-Parallelität für H100 fp8. Der höchste Durchsatz kommt von TP-2 BS-128, bei 460% im Vergleich zur Basislinie von A100/TP-8/fp16/BS-64. TP-2 BS-128 ist jedoch auch das langsamste Ergebnis in Abbildung 3.

Die durchsatzmaximierende Konfiguration unseres Experiments ist H100 / fp8 / TP-2 / BS-128, mit 767 Ausgabe-Token pro Sekunde pro GPU. Dies ist eine 460% Verbesserung gegenüber A100 / fp16 / TP-8 / BS-64. Sie geht jedoch auf Kosten einer verdoppelten Latenz - näher an 42000ms für 512 Ausgabe-Token -, daher ist sie möglicherweise als Produktionskonfiguration ungeeignet. Die Ergebnisse von TP-4 BS-128 (626 Tok/Sek/GPU bei 26188ms Antwortzeit) und TP-2 BS-32 (435 Tok/Sek/GPU bei 18821ms Antwortzeit) stellen möglicherweise bessere Kompromisse bei unseren wichtigen Metriken dar.

Unsere Ergebnisse zeigen, dass:

Wir erreichen 54% Latenz und 184% Durchsatz unter Verwendung von H100 im Vergleich zu A100 bei gleicher Konfiguration, was sich auf 49% bzw. 202% verbessert, wenn H100 seine native Unterstützung für fp8 nutzt.

Bei der Maximierung des Durchsatzes unter einer Latenzbeschränkung liefert H100 / fp8 / TP-8 / BS-128 251% Durchsatz im Vergleich zu A100 / fp16 / TP-8 / BS-64, da es den doppelten Batch mit einer höheren Geschwindigkeit verarbeiten kann.

Durch die Nutzung von H100 mit TP-2 mit fp8 können wir 373% des Durchsatzes von A100 / fp16 / TP-8 / BS-128 erreichen, bei weniger als einer 10% Erhöhung der Latenz.

Batch-Größe und Tensor-Parallelität stellen einen Kompromiss zwischen Durchsatz und Latenz für den Betreiber eines LLM-Inferenzsystems dar.

Diese Ergebnisse geben uns Zuversicht für einen vollständigen Übergang zu H100 GPUs in unserem bisher A100-betriebenen Hardware-Stack. Wir freuen uns, die von NVIDIA beworbenen Leistungszuwächse bestätigen zu können und freuen uns auf deren nächste Durchbrüche bei beschleunigter Hardware.

Unsere nächste Grenze für die Optimierung ist die Untersuchung der Genauigkeits- und Leistungsauswirkungen von strukturierter Sparsity und int4-Präzision, die den GPU-Speicher-Fußabdruck von Llama 2 70B erheblich reduzieren und bis zu 2-fache Verbesserungen bei der Latenz erzielen könnten. Wir sind gespannt darauf, die Reise der blitzschnellen Inferenz fortzusetzen und hoffen, unsere Benutzer zu befähigen, leistungsstarke Anwendungen auf unserer Plattform aufzubauen.

In naher Zukunft wird pplx-api Ratenbegrenzungen aufheben und weitere benutzerdefinierte Perplexity-LLMs anbieten, einschließlich eines internetgestützten LLM mit Fakten-Grounding.

Melden Sie sich für Perplexity Pro unter perplexity.ai/pro an. Erhalten Sie Zugang zu unserer hochmodernen pplx-api und nutzen Sie diese erweiterten Funktionen in Ihren Projekten. Entdecken Sie mehr über pplx-api in unserem Blog.

Sind Sie daran interessiert, die Zukunft der KI zu gestalten? Wir stellen ein! Werden Sie Teil eines Teams, das massiv skalierbare, generative LLM-Infrastruktur vorantreibt. Entdecken Sie Möglichkeiten bei Perplexity Careers.

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

Experimenteller Aufbau

Wichtige Metriken:

Konstanten:

KI-Modell

Eingabe-/Ausgabe-Token-Datensatz

Software-Version

Variablen

GPU-Architektur

Tensor-Parallelität

Quantisierung

Batch-Größe

Ergebnisse

Fazit

Was kommt als Nächstes

Autoren: