

Geschrieben von
KI-Team
Veröffentlicht am
17.11.2023
Einführung
Das Streben nach Leistung im Antwort-Engine von Perplexity treibt uns dazu, die neueste Technologie von NVIDIA und AWS zu übernehmen. In diesem Blog sind wir begeistert, die Ergebnisse unserer neuesten Experimente zu teilen: ein Vergleich der Llama 2 70B-Inferenz über verschiedene Hardware- und Softwareeinstellungen.
Unsere LLM-Inferenzplattform, pplx-api, basiert auf einem hochmodernen Stack, der von Open-Source-Bibliotheken unterstützt wird. Seit dem öffentlichen Beta-Start von pplx-api im Oktober haben wir uns mit Skalierungsherausforderungen beschäftigt und gelernt, wie wir unsere Konfiguration am besten abstimmen können, um eine massive Skalierung zu erreichen. Dies führte uns dazu, Experimente mit den folgenden Leitfragen durchzuführen:
Was ist der rohe Leistungsgewinn beim Wechsel unserer GPUs von NVIDIA A100 zu NVIDIA H100, wobei alle anderen Einstellungen gleich bleiben?
Was ist der Effizienzgewinn der 8-Bit-Fließkomma (fp8) Quantisierung, für die H100 native Unterstützung bietet? Was ist die Genauigkeitskosten dieser Quantisierung?
Wie beeinflussen Tensorparallelismus und Batchgröße Latenz und Token-Durchsatz?
Unter Berücksichtigung des Obigen, welche Konfiguration führt zu der am meisten skalierbaren Balance von Leistung und Kosten-Effizienz?
Experimentelles Setup
Wir haben das folgende Experiment als eine Reihe von lokalen Benchmarks durchgeführt, um Netzwerklatenz zu vermeiden.
Key Metrics
Latenz: Die gesamte Zeit, die der Inferenzserver benötigt, um seine vollständige Antwort zu generieren.
Durchsatz: Die Anzahl der Ausgabetokens, pro Sekunde, pro GPU, die der Inferenzserver über alle Benutzer und Anfragen hinweg generieren kann.
Konstanten
Die folgenden Faktoren würden die Key Metrics beeinflussen, daher haben wir sie in verschiedenen Durchgängen des Experiments konstant gehalten.
AI Modell
Die Leistung skaliert mit der Größe des LLM. Mehr Parameter erfordern mehr Berechnungen, was zu einer langsameren Inferenz führt. Beispielsweise ist Llama 2 13B schneller als Llama 2 70B, wenn andere Einstellungen gleich sind. Wir bleiben bei Llama 2 70B in diesem Experiment, weil wir danach streben, für die leistungsstärksten Open-Source-Modelle zu optimieren.
Eingabe-/Ausgabe-Token-Dataset
Die Menge der Eingabe- und Ausgabetokens in jedem Probe-Anfrage-/Antwort-Paar kann die Leistungsmessungen beeinflussen. Im Allgemeinen dominiert die Erzeugung von Ausgabetokens die Gesamtantwortzeit. Wenn das Sampling von Daten nur „Ja/Nein“-Antworten vom LLM hervorruft, dann ist die Antwort schneller im Vergleich zu Samples, die das LLM dazu auffordern, Essays zu schreiben. Unser Datensatz besteht aus synthetischen Anfragen mit 1024 Eingabetokens, die 512 Ausgabetokens hervorrufen. Diese Verteilung wurde ausgewählt, um der beobachteten Verteilung des Verkehrs auf unserem öffentlichen Einsatz von Llama2 70B zu entsprechen.
Software-Version
NVIDIA TensorRT-LLM (Release v0.5.0) ist eine Open-Source-Bibliothek zur Optimierung der LLM-Inferenz. Ende 2023 veröffentlicht, synthetisiert es NVIDIAs viele Inferenzoptimierungen und bietet eine flexibele Anpassungsebene für die Schlüsselparameter dieses Experiments: Batchgröße, Quantisierung und Tensorparallelismus.
Variablen
Wir haben über 4 Achsen der Konfiguration experimentiert: Tensorparallelismus, GPU-Architektur, Quantisierung und maximale Batchgröße. Diese Achsen sind miteinander verbunden, da sie jeweils einen Kompromiss in Bezug auf die kritische Engpassressource des GPU-Speichers darstellen.
GPU-Architektur
Die neunte Generation der Hopper (H100-HBM3-80GB / p5.48xlarge
) GPU-Architektur bietet im Vergleich zu ihrem Vorgänger, Ampere (A100-SXM4-80GB / p4de.24xlarge
), eine riesige Liste von Funktionen, einschließlich 2x-6x Rechenraten und fast 2x GPU-Speicherbandbreite. Die GPU-Speicherbandbreite ist eine wichtige Kennzahl für die Inferenz, da ein primärer Latenzengpass bei den Matrixmultiplikationen der Inferenz vom Laden von Gigabytes an Modellaten aus dem GPU-Speicher in die Rechenregister kommt. Basierend auf diesen Daten gingen wir davon aus, dass ein Apfel-zu-Apfel-Vergleich von NVIDIA H100 und A100 eine Verdoppelung sowohl beim Latenz- als auch beim Durchsatzverbesserung zeigen würde.
Ein weiterer wichtiger Unterschied zwischen der NVIDIA H100 und A100 ist, dass der H100-Tensor-Kern native Unterstützung für 8-Bit-Fließkomma(fp8)-Instruktionen hinzufügt, was die Tür zu weiteren Optimierungen öffnet, die unten detailliert beschrieben werden. Deshalb verwenden wir speziell für den H100 fp8 und fp16.
Um den Speicher pro GPU in diesem Experiment durchgängig zu halten, haben wir uns an Knoten mit 8x80GB GPU-Speicher sowohl für unsere NVIDIA A100s als auch H100s gehalten. Zusätzlich zur Ermöglichung höherer Batchgrößen ist GPU-Speicher wichtig, weil die Parameter des Modells während des Serverstarts in den GPU-Speicher geladen werden, um einen schnellen Zugriff zu haben. Beispielsweise, wenn jeder der 70 Milliarden Parameter in unserem Modell eine 16-Bit-Fließkommazahl ist, dann ist das Modell ungefähr 140GB groß, was nicht auf eine einzelne GPU passt. Daher die Notwendigkeit für Tensorparallelismus, den wir unten erklären.
Tensorparallelismus
Tensorparallelismus bezieht sich auf die Anzahl von GPU-Geräten, die zur Ausführung des Inferenzservers verbraucht werden. Wenn wir eine Anzahl von GPUs zuweisen, fasst TensorRT-LLM deren Ressourcen zusammen, um uns zu helfen, das Minimum erforderliche Speicherbudget für die Ausführung von Llama2 70B zu erreichen. Unsere Hypothese ist, dass ein niedrigerer Tensorparallelismus eine höhere Latenz zur Folge hat (aufgrund von weniger verbrauchten Ressourcen, um jede Charge zu befriedigen), aber einen höheren Durchsatz pro GPU (aufgrund besserer Ausnutzung) im Vergleich zu höherem Tensorparallelismus.
Quantisierung
Quantisierung ist die Reduktion der Präzision in den Gewichten und Aktivierungen, die von neuronalen Netzwerken verwendet werden. Wir verwenden diese Technik, um den GPU-Speichernverbrauch zu halbieren, wenn wir von fp16 auf fp8 umschalten. Dies macht es möglich, das gleiche Modell mit einem niedrigeren Gesamt-GPU-Speichernverbrauch zu betreiben, wobei ein niedrigerer Tensorparallelismus ermöglicht wird, der den Durchsatz steigert.
Implementierungen der Quantisierung haben das Potenzial, die Genauigkeit zu verschlechtern. Daher haben wir die Genauigkeit für verschiedene Präzisionen bewertet, indem wir ihre Verwirrungsstatistik verglichen, ein Maß dafür, wie gut das LLM jedes nächste Token in einem Satz vorhersagt, am WikiText Korpus. Für 8-Bit-Fließkomma und 8-Bit-Gewicht mit 8-Bit-Aktivierung und SmoothQuant (w8a8 SQ) gab es keine signifikante Veränderung in der Verwirrung (< 1%) im Vergleich zu fp16 auf WikiText, daher fühlten wir uns zuversichtlich, fortzufahren. W4a16 zeigte jedoch eine beträchtliche 7%-Veränderung in der Verwirrung, die möglicherweise auf die noch niedrigere Präzision und die notwendigen dynamischen Umwertungen zwischen int4 und fp16 zurückzuführen ist.
Batchgröße
Parallelismus durch Batching ist eine klassische Strategie, um Leistung aus einem ressourcenbeschränkten System herauszuholen. Durch die Verarbeitung mehrerer Anfragen in jedem Durchgang durch das neurale Netzwerk ist bekannt, dass Batching den Durchsatz auf Kosten einer gewissen Latenz erhöht. Batching verursacht auch einen höheren GPU-Speicherverbrauch, da die Größe des KV-Caches, der den Aufmerksamkeitsmechanismus verwaltet, linear mit der Batchgröße wächst.

Im Falle von Llama 2 70B (welches 80 Schichten hat), fp16 mit Batchgröße 32 für 4096 Kontextgröße, ist die Größe des KV-Caches erheblich 40 GB. Dies verhindert, dass Llama 2 70B fp16, dessen Gewichte alleine 140GB beanspruchen, bequem in den 160GB GPU-Speicher bei einem Tensorparallelismus 2 (TP-2) passen.
Ergebnisse
Wir haben durch die kompatiblen Kombinationen der 4 Variablen des Experiments gefegt und präsentieren die aufschlussreichsten Trends unten.

Abbildung 1 - Die Latenz von Anfragen mit unterschiedlicher Batchgröße in fünf verschiedenen Konfigurationen, alle mit Tensorparallelismus 8, die die beste Latenz bei 8 verfügbaren GPUs liefert. Bei jeder Konfiguration verdoppelt sich die Latenz im Allgemeinen, wenn die Batchgröße von 1 → 32 erhöht wird, und verdoppelt sich noch einmal von 32 → 128. Bei ausreichend großen Batchgrößen halbiert H100 ungefähr die Latenz im Vergleich zu A100. A100 verwendet gemischte Präzision, da die Architektur keine native Unterstützung für fp8 hat. W8a8 mit SmoothQuant (SQ) soll fp8 ähneln.
Die Latenzverbesserung der 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 hingegen leistet bei niedrigen Batchgrößen besser und bei höheren Batchgrößen schlechter im Vergleich zu fp16. Dies könnte auf eine Reihe von Faktoren zurückzuführen sein, einschließlich weniger optimierter Rechenkerne, Gießzeit zwischen int4 und fp16 und der Tatsache, dass w4a16 immer noch 16-Bit-Fließkommazahlen für Aktivierungen verwendet, was zu keiner Einsparung in den Abmessungen des KV-Caches führt. Da w4a16 auch niedrigere Genauigkeit demonstriert, schließen wir daraus, dass wir bei w8a8 SQ für A100s und fp8 für H100s bleiben sollten.

Abbildung 2 - Der Durchsatz über die TP-8-Konfigurationen mit verschiedenen Architekturen, Quantisierung und Batchgröße. Für jede Architektur und Quantisierung wurde die Batchgröße als die größte gewählt, die eine Latenzanforderung von 25600ms (20 Tokens pro Sekunde für 512 Tokens) ehrt, sodass wir Konfigurationen mit ähnlichem Latenzen vergleichen. Unter dieser Anforderung erreicht H100 mit BS-128 einen 228%-Durchsatz im Vergleich zu A100 BS-64 mit derselben Quantisierung (fp16) und hat sogar eine niedrigere Antwortlatenz trotz der verdoppelten Batchgröß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 Verbesserung der Leistung kann auf Zuwächse in Rechenleistung und Speicherbandbreite zwischen H100 und A100 zurückgeführt werden. Bemerkenswerterweise ist die Differenz weniger ausgeprägt unter niedrigeren Batchgrößen, wo die Ausnutzung möglicherweise geringer sein kann.
Während wir unsere Plattform aufbauen, möchten wir bestimmte Latenzanforderungen für unsere Benutzer ehren, während wir den Durchsatz maximieren. Daher ist es für uns eigentlich sinnvoller, ihren Durchsatz nur unter Konfigurationen zu vergleichen, die eine Latenzanforderung erfüllen. Wir haben einen Cut-off bei 25600ms Latenz für die Fertigstellung der 512 Ausgabetokens festgestellt und gefunden, dass H100 / TP-8 / fp8 / BS-128 einen 251%-Durchsatz im Vergleich zu A100 / TP-8 / fp16 / BS-64 liefert, da es die doppelte Batchgröße bei einer niedrigeren Latenz verarbeiten kann. Angesichts der GPU-Speichereinsparungen durch die Quantisierung:Längere Antwortzeiten - möglicherweise ungeeignet für eine Produktionskonfiguration. Die Ergebnisse von TP-4 BS-128 (626 tok/sec/gpu bei 26188ms Antwortzeit) und TP-2 BS-32 (435 tok/sec/gpu bei 18821ms Antwortzeit) können bessere Kompromisse in unseren Schlüsselmetriken darstellen.
Schlussfolgerung
Unsere Ergebnisse zeigen, dass:
Wir erreichen 54% Latenz und 184% Durchsatz mit H100 im Vergleich zu A100 bei derselben Konfiguration, was sich auf 49% bzw. 202% verbessert, wenn H100 seinen nativen Unterstützung für fp8 nutzt.
Bei der Maximierung des Durchsatzes unter Berücksichtigung einer Latenzbeschränkung, liefert H100 / fp8 / TP-8 / BS-128 einen 251%-Durchsatz im Vergleich zu A100 / fp16 / TP-8 / BS-64, da es die doppelte Batchgröße bei höherer Geschwindigkeit verarbeiten kann.
Unter Ausnutzung von H100 mit TP-2 mit fp8 können wir 373% den Durchsatz von A100 / fp16 / TP-8 / BS-128 erreichen, mit einer weniger als 10%-igen Zunahme der Latenz.
Batchgröße und Tensorparallelismus stellen einen Kompromiss zwischen Durchsatz und Latenz für den Betreiber eines LLM-Inferenzsystems dar.
Diese Ergebnisse machen uns zuversichtlich über
Einführung
Das Streben nach Leistung im Antwort-Engine von Perplexity treibt uns dazu, die neueste Technologie von NVIDIA und AWS zu übernehmen. In diesem Blog sind wir begeistert, die Ergebnisse unserer neuesten Experimente zu teilen: ein Vergleich der Llama 2 70B-Inferenz über verschiedene Hardware- und Softwareeinstellungen.
Unsere LLM-Inferenzplattform, pplx-api, basiert auf einem hochmodernen Stack, der von Open-Source-Bibliotheken unterstützt wird. Seit dem öffentlichen Beta-Start von pplx-api im Oktober haben wir uns mit Skalierungsherausforderungen beschäftigt und gelernt, wie wir unsere Konfiguration am besten abstimmen können, um eine massive Skalierung zu erreichen. Dies führte uns dazu, Experimente mit den folgenden Leitfragen durchzuführen:
Was ist der rohe Leistungsgewinn beim Wechsel unserer GPUs von NVIDIA A100 zu NVIDIA H100, wobei alle anderen Einstellungen gleich bleiben?
Was ist der Effizienzgewinn der 8-Bit-Fließkomma (fp8) Quantisierung, für die H100 native Unterstützung bietet? Was ist die Genauigkeitskosten dieser Quantisierung?
Wie beeinflussen Tensorparallelismus und Batchgröße Latenz und Token-Durchsatz?
Unter Berücksichtigung des Obigen, welche Konfiguration führt zu der am meisten skalierbaren Balance von Leistung und Kosten-Effizienz?
Experimentelles Setup
Wir haben das folgende Experiment als eine Reihe von lokalen Benchmarks durchgeführt, um Netzwerklatenz zu vermeiden.
Key Metrics
Latenz: Die gesamte Zeit, die der Inferenzserver benötigt, um seine vollständige Antwort zu generieren.
Durchsatz: Die Anzahl der Ausgabetokens, pro Sekunde, pro GPU, die der Inferenzserver über alle Benutzer und Anfragen hinweg generieren kann.
Konstanten
Die folgenden Faktoren würden die Key Metrics beeinflussen, daher haben wir sie in verschiedenen Durchgängen des Experiments konstant gehalten.
AI Modell
Die Leistung skaliert mit der Größe des LLM. Mehr Parameter erfordern mehr Berechnungen, was zu einer langsameren Inferenz führt. Beispielsweise ist Llama 2 13B schneller als Llama 2 70B, wenn andere Einstellungen gleich sind. Wir bleiben bei Llama 2 70B in diesem Experiment, weil wir danach streben, für die leistungsstärksten Open-Source-Modelle zu optimieren.
Eingabe-/Ausgabe-Token-Dataset
Die Menge der Eingabe- und Ausgabetokens in jedem Probe-Anfrage-/Antwort-Paar kann die Leistungsmessungen beeinflussen. Im Allgemeinen dominiert die Erzeugung von Ausgabetokens die Gesamtantwortzeit. Wenn das Sampling von Daten nur „Ja/Nein“-Antworten vom LLM hervorruft, dann ist die Antwort schneller im Vergleich zu Samples, die das LLM dazu auffordern, Essays zu schreiben. Unser Datensatz besteht aus synthetischen Anfragen mit 1024 Eingabetokens, die 512 Ausgabetokens hervorrufen. Diese Verteilung wurde ausgewählt, um der beobachteten Verteilung des Verkehrs auf unserem öffentlichen Einsatz von Llama2 70B zu entsprechen.
Software-Version
NVIDIA TensorRT-LLM (Release v0.5.0) ist eine Open-Source-Bibliothek zur Optimierung der LLM-Inferenz. Ende 2023 veröffentlicht, synthetisiert es NVIDIAs viele Inferenzoptimierungen und bietet eine flexibele Anpassungsebene für die Schlüsselparameter dieses Experiments: Batchgröße, Quantisierung und Tensorparallelismus.
Variablen
Wir haben über 4 Achsen der Konfiguration experimentiert: Tensorparallelismus, GPU-Architektur, Quantisierung und maximale Batchgröße. Diese Achsen sind miteinander verbunden, da sie jeweils einen Kompromiss in Bezug auf die kritische Engpassressource des GPU-Speichers darstellen.
GPU-Architektur
Die neunte Generation der Hopper (H100-HBM3-80GB / p5.48xlarge
) GPU-Architektur bietet im Vergleich zu ihrem Vorgänger, Ampere (A100-SXM4-80GB / p4de.24xlarge
), eine riesige Liste von Funktionen, einschließlich 2x-6x Rechenraten und fast 2x GPU-Speicherbandbreite. Die GPU-Speicherbandbreite ist eine wichtige Kennzahl für die Inferenz, da ein primärer Latenzengpass bei den Matrixmultiplikationen der Inferenz vom Laden von Gigabytes an Modellaten aus dem GPU-Speicher in die Rechenregister kommt. Basierend auf diesen Daten gingen wir davon aus, dass ein Apfel-zu-Apfel-Vergleich von NVIDIA H100 und A100 eine Verdoppelung sowohl beim Latenz- als auch beim Durchsatzverbesserung zeigen würde.
Ein weiterer wichtiger Unterschied zwischen der NVIDIA H100 und A100 ist, dass der H100-Tensor-Kern native Unterstützung für 8-Bit-Fließkomma(fp8)-Instruktionen hinzufügt, was die Tür zu weiteren Optimierungen öffnet, die unten detailliert beschrieben werden. Deshalb verwenden wir speziell für den H100 fp8 und fp16.
Um den Speicher pro GPU in diesem Experiment durchgängig zu halten, haben wir uns an Knoten mit 8x80GB GPU-Speicher sowohl für unsere NVIDIA A100s als auch H100s gehalten. Zusätzlich zur Ermöglichung höherer Batchgrößen ist GPU-Speicher wichtig, weil die Parameter des Modells während des Serverstarts in den GPU-Speicher geladen werden, um einen schnellen Zugriff zu haben. Beispielsweise, wenn jeder der 70 Milliarden Parameter in unserem Modell eine 16-Bit-Fließkommazahl ist, dann ist das Modell ungefähr 140GB groß, was nicht auf eine einzelne GPU passt. Daher die Notwendigkeit für Tensorparallelismus, den wir unten erklären.
Tensorparallelismus
Tensorparallelismus bezieht sich auf die Anzahl von GPU-Geräten, die zur Ausführung des Inferenzservers verbraucht werden. Wenn wir eine Anzahl von GPUs zuweisen, fasst TensorRT-LLM deren Ressourcen zusammen, um uns zu helfen, das Minimum erforderliche Speicherbudget für die Ausführung von Llama2 70B zu erreichen. Unsere Hypothese ist, dass ein niedrigerer Tensorparallelismus eine höhere Latenz zur Folge hat (aufgrund von weniger verbrauchten Ressourcen, um jede Charge zu befriedigen), aber einen höheren Durchsatz pro GPU (aufgrund besserer Ausnutzung) im Vergleich zu höherem Tensorparallelismus.
Quantisierung
Quantisierung ist die Reduktion der Präzision in den Gewichten und Aktivierungen, die von neuronalen Netzwerken verwendet werden. Wir verwenden diese Technik, um den GPU-Speichernverbrauch zu halbieren, wenn wir von fp16 auf fp8 umschalten. Dies macht es möglich, das gleiche Modell mit einem niedrigeren Gesamt-GPU-Speichernverbrauch zu betreiben, wobei ein niedrigerer Tensorparallelismus ermöglicht wird, der den Durchsatz steigert.
Implementierungen der Quantisierung haben das Potenzial, die Genauigkeit zu verschlechtern. Daher haben wir die Genauigkeit für verschiedene Präzisionen bewertet, indem wir ihre Verwirrungsstatistik verglichen, ein Maß dafür, wie gut das LLM jedes nächste Token in einem Satz vorhersagt, am WikiText Korpus. Für 8-Bit-Fließkomma und 8-Bit-Gewicht mit 8-Bit-Aktivierung und SmoothQuant (w8a8 SQ) gab es keine signifikante Veränderung in der Verwirrung (< 1%) im Vergleich zu fp16 auf WikiText, daher fühlten wir uns zuversichtlich, fortzufahren. W4a16 zeigte jedoch eine beträchtliche 7%-Veränderung in der Verwirrung, die möglicherweise auf die noch niedrigere Präzision und die notwendigen dynamischen Umwertungen zwischen int4 und fp16 zurückzuführen ist.
Batchgröße
Parallelismus durch Batching ist eine klassische Strategie, um Leistung aus einem ressourcenbeschränkten System herauszuholen. Durch die Verarbeitung mehrerer Anfragen in jedem Durchgang durch das neurale Netzwerk ist bekannt, dass Batching den Durchsatz auf Kosten einer gewissen Latenz erhöht. Batching verursacht auch einen höheren GPU-Speicherverbrauch, da die Größe des KV-Caches, der den Aufmerksamkeitsmechanismus verwaltet, linear mit der Batchgröße wächst.

Im Falle von Llama 2 70B (welches 80 Schichten hat), fp16 mit Batchgröße 32 für 4096 Kontextgröße, ist die Größe des KV-Caches erheblich 40 GB. Dies verhindert, dass Llama 2 70B fp16, dessen Gewichte alleine 140GB beanspruchen, bequem in den 160GB GPU-Speicher bei einem Tensorparallelismus 2 (TP-2) passen.
Ergebnisse
Wir haben durch die kompatiblen Kombinationen der 4 Variablen des Experiments gefegt und präsentieren die aufschlussreichsten Trends unten.

Abbildung 1 - Die Latenz von Anfragen mit unterschiedlicher Batchgröße in fünf verschiedenen Konfigurationen, alle mit Tensorparallelismus 8, die die beste Latenz bei 8 verfügbaren GPUs liefert. Bei jeder Konfiguration verdoppelt sich die Latenz im Allgemeinen, wenn die Batchgröße von 1 → 32 erhöht wird, und verdoppelt sich noch einmal von 32 → 128. Bei ausreichend großen Batchgrößen halbiert H100 ungefähr die Latenz im Vergleich zu A100. A100 verwendet gemischte Präzision, da die Architektur keine native Unterstützung für fp8 hat. W8a8 mit SmoothQuant (SQ) soll fp8 ähneln.
Die Latenzverbesserung der 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 hingegen leistet bei niedrigen Batchgrößen besser und bei höheren Batchgrößen schlechter im Vergleich zu fp16. Dies könnte auf eine Reihe von Faktoren zurückzuführen sein, einschließlich weniger optimierter Rechenkerne, Gießzeit zwischen int4 und fp16 und der Tatsache, dass w4a16 immer noch 16-Bit-Fließkommazahlen für Aktivierungen verwendet, was zu keiner Einsparung in den Abmessungen des KV-Caches führt. Da w4a16 auch niedrigere Genauigkeit demonstriert, schließen wir daraus, dass wir bei w8a8 SQ für A100s und fp8 für H100s bleiben sollten.

Abbildung 2 - Der Durchsatz über die TP-8-Konfigurationen mit verschiedenen Architekturen, Quantisierung und Batchgröße. Für jede Architektur und Quantisierung wurde die Batchgröße als die größte gewählt, die eine Latenzanforderung von 25600ms (20 Tokens pro Sekunde für 512 Tokens) ehrt, sodass wir Konfigurationen mit ähnlichem Latenzen vergleichen. Unter dieser Anforderung erreicht H100 mit BS-128 einen 228%-Durchsatz im Vergleich zu A100 BS-64 mit derselben Quantisierung (fp16) und hat sogar eine niedrigere Antwortlatenz trotz der verdoppelten Batchgröß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 Verbesserung der Leistung kann auf Zuwächse in Rechenleistung und Speicherbandbreite zwischen H100 und A100 zurückgeführt werden. Bemerkenswerterweise ist die Differenz weniger ausgeprägt unter niedrigeren Batchgrößen, wo die Ausnutzung möglicherweise geringer sein kann.
Während wir unsere Plattform aufbauen, möchten wir bestimmte Latenzanforderungen für unsere Benutzer ehren, während wir den Durchsatz maximieren. Daher ist es für uns eigentlich sinnvoller, ihren Durchsatz nur unter Konfigurationen zu vergleichen, die eine Latenzanforderung erfüllen. Wir haben einen Cut-off bei 25600ms Latenz für die Fertigstellung der 512 Ausgabetokens festgestellt und gefunden, dass H100 / TP-8 / fp8 / BS-128 einen 251%-Durchsatz im Vergleich zu A100 / TP-8 / fp16 / BS-64 liefert, da es die doppelte Batchgröße bei einer niedrigeren Latenz verarbeiten kann. Angesichts der GPU-Speichereinsparungen durch die Quantisierung:Längere Antwortzeiten - möglicherweise ungeeignet für eine Produktionskonfiguration. Die Ergebnisse von TP-4 BS-128 (626 tok/sec/gpu bei 26188ms Antwortzeit) und TP-2 BS-32 (435 tok/sec/gpu bei 18821ms Antwortzeit) können bessere Kompromisse in unseren Schlüsselmetriken darstellen.
Schlussfolgerung
Unsere Ergebnisse zeigen, dass:
Wir erreichen 54% Latenz und 184% Durchsatz mit H100 im Vergleich zu A100 bei derselben Konfiguration, was sich auf 49% bzw. 202% verbessert, wenn H100 seinen nativen Unterstützung für fp8 nutzt.
Bei der Maximierung des Durchsatzes unter Berücksichtigung einer Latenzbeschränkung, liefert H100 / fp8 / TP-8 / BS-128 einen 251%-Durchsatz im Vergleich zu A100 / fp16 / TP-8 / BS-64, da es die doppelte Batchgröße bei höherer Geschwindigkeit verarbeiten kann.
Unter Ausnutzung von H100 mit TP-2 mit fp8 können wir 373% den Durchsatz von A100 / fp16 / TP-8 / BS-128 erreichen, mit einer weniger als 10%-igen Zunahme der Latenz.
Batchgröße und Tensorparallelismus stellen einen Kompromiss zwischen Durchsatz und Latenz für den Betreiber eines LLM-Inferenzsystems dar.
Diese Ergebnisse machen uns zuversichtlich über
Einführung
Das Streben nach Leistung im Antwort-Engine von Perplexity treibt uns dazu, die neueste Technologie von NVIDIA und AWS zu übernehmen. In diesem Blog sind wir begeistert, die Ergebnisse unserer neuesten Experimente zu teilen: ein Vergleich der Llama 2 70B-Inferenz über verschiedene Hardware- und Softwareeinstellungen.
Unsere LLM-Inferenzplattform, pplx-api, basiert auf einem hochmodernen Stack, der von Open-Source-Bibliotheken unterstützt wird. Seit dem öffentlichen Beta-Start von pplx-api im Oktober haben wir uns mit Skalierungsherausforderungen beschäftigt und gelernt, wie wir unsere Konfiguration am besten abstimmen können, um eine massive Skalierung zu erreichen. Dies führte uns dazu, Experimente mit den folgenden Leitfragen durchzuführen:
Was ist der rohe Leistungsgewinn beim Wechsel unserer GPUs von NVIDIA A100 zu NVIDIA H100, wobei alle anderen Einstellungen gleich bleiben?
Was ist der Effizienzgewinn der 8-Bit-Fließkomma (fp8) Quantisierung, für die H100 native Unterstützung bietet? Was ist die Genauigkeitskosten dieser Quantisierung?
Wie beeinflussen Tensorparallelismus und Batchgröße Latenz und Token-Durchsatz?
Unter Berücksichtigung des Obigen, welche Konfiguration führt zu der am meisten skalierbaren Balance von Leistung und Kosten-Effizienz?
Experimentelles Setup
Wir haben das folgende Experiment als eine Reihe von lokalen Benchmarks durchgeführt, um Netzwerklatenz zu vermeiden.
Key Metrics
Latenz: Die gesamte Zeit, die der Inferenzserver benötigt, um seine vollständige Antwort zu generieren.
Durchsatz: Die Anzahl der Ausgabetokens, pro Sekunde, pro GPU, die der Inferenzserver über alle Benutzer und Anfragen hinweg generieren kann.
Konstanten
Die folgenden Faktoren würden die Key Metrics beeinflussen, daher haben wir sie in verschiedenen Durchgängen des Experiments konstant gehalten.
AI Modell
Die Leistung skaliert mit der Größe des LLM. Mehr Parameter erfordern mehr Berechnungen, was zu einer langsameren Inferenz führt. Beispielsweise ist Llama 2 13B schneller als Llama 2 70B, wenn andere Einstellungen gleich sind. Wir bleiben bei Llama 2 70B in diesem Experiment, weil wir danach streben, für die leistungsstärksten Open-Source-Modelle zu optimieren.
Eingabe-/Ausgabe-Token-Dataset
Die Menge der Eingabe- und Ausgabetokens in jedem Probe-Anfrage-/Antwort-Paar kann die Leistungsmessungen beeinflussen. Im Allgemeinen dominiert die Erzeugung von Ausgabetokens die Gesamtantwortzeit. Wenn das Sampling von Daten nur „Ja/Nein“-Antworten vom LLM hervorruft, dann ist die Antwort schneller im Vergleich zu Samples, die das LLM dazu auffordern, Essays zu schreiben. Unser Datensatz besteht aus synthetischen Anfragen mit 1024 Eingabetokens, die 512 Ausgabetokens hervorrufen. Diese Verteilung wurde ausgewählt, um der beobachteten Verteilung des Verkehrs auf unserem öffentlichen Einsatz von Llama2 70B zu entsprechen.
Software-Version
NVIDIA TensorRT-LLM (Release v0.5.0) ist eine Open-Source-Bibliothek zur Optimierung der LLM-Inferenz. Ende 2023 veröffentlicht, synthetisiert es NVIDIAs viele Inferenzoptimierungen und bietet eine flexibele Anpassungsebene für die Schlüsselparameter dieses Experiments: Batchgröße, Quantisierung und Tensorparallelismus.
Variablen
Wir haben über 4 Achsen der Konfiguration experimentiert: Tensorparallelismus, GPU-Architektur, Quantisierung und maximale Batchgröße. Diese Achsen sind miteinander verbunden, da sie jeweils einen Kompromiss in Bezug auf die kritische Engpassressource des GPU-Speichers darstellen.
GPU-Architektur
Die neunte Generation der Hopper (H100-HBM3-80GB / p5.48xlarge
) GPU-Architektur bietet im Vergleich zu ihrem Vorgänger, Ampere (A100-SXM4-80GB / p4de.24xlarge
), eine riesige Liste von Funktionen, einschließlich 2x-6x Rechenraten und fast 2x GPU-Speicherbandbreite. Die GPU-Speicherbandbreite ist eine wichtige Kennzahl für die Inferenz, da ein primärer Latenzengpass bei den Matrixmultiplikationen der Inferenz vom Laden von Gigabytes an Modellaten aus dem GPU-Speicher in die Rechenregister kommt. Basierend auf diesen Daten gingen wir davon aus, dass ein Apfel-zu-Apfel-Vergleich von NVIDIA H100 und A100 eine Verdoppelung sowohl beim Latenz- als auch beim Durchsatzverbesserung zeigen würde.
Ein weiterer wichtiger Unterschied zwischen der NVIDIA H100 und A100 ist, dass der H100-Tensor-Kern native Unterstützung für 8-Bit-Fließkomma(fp8)-Instruktionen hinzufügt, was die Tür zu weiteren Optimierungen öffnet, die unten detailliert beschrieben werden. Deshalb verwenden wir speziell für den H100 fp8 und fp16.
Um den Speicher pro GPU in diesem Experiment durchgängig zu halten, haben wir uns an Knoten mit 8x80GB GPU-Speicher sowohl für unsere NVIDIA A100s als auch H100s gehalten. Zusätzlich zur Ermöglichung höherer Batchgrößen ist GPU-Speicher wichtig, weil die Parameter des Modells während des Serverstarts in den GPU-Speicher geladen werden, um einen schnellen Zugriff zu haben. Beispielsweise, wenn jeder der 70 Milliarden Parameter in unserem Modell eine 16-Bit-Fließkommazahl ist, dann ist das Modell ungefähr 140GB groß, was nicht auf eine einzelne GPU passt. Daher die Notwendigkeit für Tensorparallelismus, den wir unten erklären.
Tensorparallelismus
Tensorparallelismus bezieht sich auf die Anzahl von GPU-Geräten, die zur Ausführung des Inferenzservers verbraucht werden. Wenn wir eine Anzahl von GPUs zuweisen, fasst TensorRT-LLM deren Ressourcen zusammen, um uns zu helfen, das Minimum erforderliche Speicherbudget für die Ausführung von Llama2 70B zu erreichen. Unsere Hypothese ist, dass ein niedrigerer Tensorparallelismus eine höhere Latenz zur Folge hat (aufgrund von weniger verbrauchten Ressourcen, um jede Charge zu befriedigen), aber einen höheren Durchsatz pro GPU (aufgrund besserer Ausnutzung) im Vergleich zu höherem Tensorparallelismus.
Quantisierung
Quantisierung ist die Reduktion der Präzision in den Gewichten und Aktivierungen, die von neuronalen Netzwerken verwendet werden. Wir verwenden diese Technik, um den GPU-Speichernverbrauch zu halbieren, wenn wir von fp16 auf fp8 umschalten. Dies macht es möglich, das gleiche Modell mit einem niedrigeren Gesamt-GPU-Speichernverbrauch zu betreiben, wobei ein niedrigerer Tensorparallelismus ermöglicht wird, der den Durchsatz steigert.
Implementierungen der Quantisierung haben das Potenzial, die Genauigkeit zu verschlechtern. Daher haben wir die Genauigkeit für verschiedene Präzisionen bewertet, indem wir ihre Verwirrungsstatistik verglichen, ein Maß dafür, wie gut das LLM jedes nächste Token in einem Satz vorhersagt, am WikiText Korpus. Für 8-Bit-Fließkomma und 8-Bit-Gewicht mit 8-Bit-Aktivierung und SmoothQuant (w8a8 SQ) gab es keine signifikante Veränderung in der Verwirrung (< 1%) im Vergleich zu fp16 auf WikiText, daher fühlten wir uns zuversichtlich, fortzufahren. W4a16 zeigte jedoch eine beträchtliche 7%-Veränderung in der Verwirrung, die möglicherweise auf die noch niedrigere Präzision und die notwendigen dynamischen Umwertungen zwischen int4 und fp16 zurückzuführen ist.
Batchgröße
Parallelismus durch Batching ist eine klassische Strategie, um Leistung aus einem ressourcenbeschränkten System herauszuholen. Durch die Verarbeitung mehrerer Anfragen in jedem Durchgang durch das neurale Netzwerk ist bekannt, dass Batching den Durchsatz auf Kosten einer gewissen Latenz erhöht. Batching verursacht auch einen höheren GPU-Speicherverbrauch, da die Größe des KV-Caches, der den Aufmerksamkeitsmechanismus verwaltet, linear mit der Batchgröße wächst.

Im Falle von Llama 2 70B (welches 80 Schichten hat), fp16 mit Batchgröße 32 für 4096 Kontextgröße, ist die Größe des KV-Caches erheblich 40 GB. Dies verhindert, dass Llama 2 70B fp16, dessen Gewichte alleine 140GB beanspruchen, bequem in den 160GB GPU-Speicher bei einem Tensorparallelismus 2 (TP-2) passen.
Ergebnisse
Wir haben durch die kompatiblen Kombinationen der 4 Variablen des Experiments gefegt und präsentieren die aufschlussreichsten Trends unten.

Abbildung 1 - Die Latenz von Anfragen mit unterschiedlicher Batchgröße in fünf verschiedenen Konfigurationen, alle mit Tensorparallelismus 8, die die beste Latenz bei 8 verfügbaren GPUs liefert. Bei jeder Konfiguration verdoppelt sich die Latenz im Allgemeinen, wenn die Batchgröße von 1 → 32 erhöht wird, und verdoppelt sich noch einmal von 32 → 128. Bei ausreichend großen Batchgrößen halbiert H100 ungefähr die Latenz im Vergleich zu A100. A100 verwendet gemischte Präzision, da die Architektur keine native Unterstützung für fp8 hat. W8a8 mit SmoothQuant (SQ) soll fp8 ähneln.
Die Latenzverbesserung der 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 hingegen leistet bei niedrigen Batchgrößen besser und bei höheren Batchgrößen schlechter im Vergleich zu fp16. Dies könnte auf eine Reihe von Faktoren zurückzuführen sein, einschließlich weniger optimierter Rechenkerne, Gießzeit zwischen int4 und fp16 und der Tatsache, dass w4a16 immer noch 16-Bit-Fließkommazahlen für Aktivierungen verwendet, was zu keiner Einsparung in den Abmessungen des KV-Caches führt. Da w4a16 auch niedrigere Genauigkeit demonstriert, schließen wir daraus, dass wir bei w8a8 SQ für A100s und fp8 für H100s bleiben sollten.

Abbildung 2 - Der Durchsatz über die TP-8-Konfigurationen mit verschiedenen Architekturen, Quantisierung und Batchgröße. Für jede Architektur und Quantisierung wurde die Batchgröße als die größte gewählt, die eine Latenzanforderung von 25600ms (20 Tokens pro Sekunde für 512 Tokens) ehrt, sodass wir Konfigurationen mit ähnlichem Latenzen vergleichen. Unter dieser Anforderung erreicht H100 mit BS-128 einen 228%-Durchsatz im Vergleich zu A100 BS-64 mit derselben Quantisierung (fp16) und hat sogar eine niedrigere Antwortlatenz trotz der verdoppelten Batchgröß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 Verbesserung der Leistung kann auf Zuwächse in Rechenleistung und Speicherbandbreite zwischen H100 und A100 zurückgeführt werden. Bemerkenswerterweise ist die Differenz weniger ausgeprägt unter niedrigeren Batchgrößen, wo die Ausnutzung möglicherweise geringer sein kann.
Während wir unsere Plattform aufbauen, möchten wir bestimmte Latenzanforderungen für unsere Benutzer ehren, während wir den Durchsatz maximieren. Daher ist es für uns eigentlich sinnvoller, ihren Durchsatz nur unter Konfigurationen zu vergleichen, die eine Latenzanforderung erfüllen. Wir haben einen Cut-off bei 25600ms Latenz für die Fertigstellung der 512 Ausgabetokens festgestellt und gefunden, dass H100 / TP-8 / fp8 / BS-128 einen 251%-Durchsatz im Vergleich zu A100 / TP-8 / fp16 / BS-64 liefert, da es die doppelte Batchgröße bei einer niedrigeren Latenz verarbeiten kann. Angesichts der GPU-Speichereinsparungen durch die Quantisierung:Längere Antwortzeiten - möglicherweise ungeeignet für eine Produktionskonfiguration. Die Ergebnisse von TP-4 BS-128 (626 tok/sec/gpu bei 26188ms Antwortzeit) und TP-2 BS-32 (435 tok/sec/gpu bei 18821ms Antwortzeit) können bessere Kompromisse in unseren Schlüsselmetriken darstellen.
Schlussfolgerung
Unsere Ergebnisse zeigen, dass:
Wir erreichen 54% Latenz und 184% Durchsatz mit H100 im Vergleich zu A100 bei derselben Konfiguration, was sich auf 49% bzw. 202% verbessert, wenn H100 seinen nativen Unterstützung für fp8 nutzt.
Bei der Maximierung des Durchsatzes unter Berücksichtigung einer Latenzbeschränkung, liefert H100 / fp8 / TP-8 / BS-128 einen 251%-Durchsatz im Vergleich zu A100 / fp16 / TP-8 / BS-64, da es die doppelte Batchgröße bei höherer Geschwindigkeit verarbeiten kann.
Unter Ausnutzung von H100 mit TP-2 mit fp8 können wir 373% den Durchsatz von A100 / fp16 / TP-8 / BS-128 erreichen, mit einer weniger als 10%-igen Zunahme der Latenz.
Batchgröße und Tensorparallelismus stellen einen Kompromiss zwischen Durchsatz und Latenz für den Betreiber eines LLM-Inferenzsystems dar.
Diese Ergebnisse machen uns zuversichtlich über
Share this article
UNTERNEHMEN
LABS
UNTERNEHMEN
LABS
UNTERNEHMEN
LABS