Evaluierung der LLM-Inferenz-Performance auf Red Hat OpenShift AI

Das Feld der generativen künstlichen Intelligenz (KI) hat sich im letzten Jahr rasant weiterentwickelt. Mit der zunehmenden Leistungsfähigkeit generativer LLMs (Large Language Models) greifen Unternehmen vermehrt auf die Funktionen dieser Modelle zurück, um ihre geschäftliche Anforderungen zu erfüllen. Die Ausführung von LLMs bringt jedoch hohe Rechenanforderungen mit sich. Daher ist es entscheidend, dass sie auf einer leistungsfähigen und zuverlässigen Plattform bereitgestellt werden, um eine kosteneffiziente Nutzung der zugrunde liegenden Hardware, insbesondere von GPUs, zu ermöglichen.

In diesem Artikel werden die Methodik und die Ergebnisse von Performance-Tests der Llama-2-Modelle vorgestellt, die auf dem in Red Hat OpenShift AI enthaltenen Modellbereitstellungs-Stack eingesetzt werden. OpenShift AI ist eine flexible, skalierbare MLOps-Plattform mit Tools zum Entwickeln, Bereitstellen und Verwalten von KI-gestützten Anwendungen. Auf Basis von Open Source-Technologien bietet es bewährte und konsistente Operations-Features, mit denen Teams experimentieren, Modelle bereitstellen und innovative Apps präsentieren können.

Der Modellbereitstellungs-Stack

Der Software-Stack für die Modellbereitstellung basiert auf KServe, OpenShift Serverless und OpenShift Service Mesh. Zur Ausführung der Llama-2-Modelle haben wir auch Caikit und text-generation-inference-service (TGIS) verwendet, obwohl OpenShift AI auch OpenVINO unterstützt und die Möglichkeit bietet, andere benutzerdefinierte Runtimes modular zu verwenden. Der NVIDIA GPU Operator verwaltet GPUs und macht sie verfügbar, damit der TGIS-Container (Text Generation Inference Server) sie verwenden kann.

Abbildung 1. Interaktionen zwischen Komponenten und Benutzer-Workflow im KServe/Caikit/TGIS-Stack

Durch die Nutzung von OpenShift Serverless und OpenShift Service Mesh bietet KServe viele innovative Funktionen für die KI-Modell-Inferenz. Diese Komponenten spiegeln die Komplexität wider, die mit Netzwerken, Servicekonfiguration, automatischer Skalierung und Zustandsprüfungen für die Bereitstellung von Produktionsmodellen einhergeht.

Mit dem Caikit-Toolkit können Nutzende Modelle über mehrere entwicklungsfreundliche APIs verwalten. Caikit bietet standardmäßige HTTP- und gRPC-Schnittstellen (Remote Procedure Call), mit denen wir verschiedene Basismodelle abfragen können. Die Anfragen werden dann an den Inferenzservice TGIS weitergeleitet.

TGIS ist eine frühe Abspaltung des TGIS-Toolkits von Hugging Face. Es bietet mehrere wichtige Funktionen, mit denen die Performance der Bereitstellung von LLMs optimiert wird, wie etwa kontinuierliche Batch-Verarbeitung, dynamische Batch-Verarbeitung, Tensorparallelität (Modellfragmentierung), Unterstützung für die Funktion torch.compile in PyTorch 2 und mehr.

Der NVIDIA GPU Operator automatisiert die Verwaltung verschiedener Softwarekomponenten, die für die Provisionierung und Verwendung von NVIDIA-GPUs in OpenShift erforderlich sind. Dazu gehören der Treiber-Container, das Geräte-Plugin, der DCVM-Metrikexporter (Data Center GPU Manager) und mehr. Der DCVM-Metrikexporter lässt uns mit der Monitoring-Pometheus-Instanz in OpenShift GPU-Metriken wie Speicherauslastung und Streaming-Multiprozessor-Auslastung (SM) analysieren.

Methoden für Performance-Tests bei LLMs

Bei der Bewertung der Performance von LLMs interessieren uns die klassischen Messwerte für Latenz und Durchsatz. Die End-to-End-Latenz der Anfragen an ein LLM hängt jedoch von mehreren Faktoren ab und kann daher stark variieren. Der wichtigste Aspekt ist die Länge der Ausgabe, da LLMs Text Token für Token generieren. Aus diesem Grund messen wir die Latenz in erster Linie als Latenz pro Token oder „Time per Output Token“ (TPOT).

Token sind Texteinheiten, die ein Wort oder eine Untergruppe von Zeichen darstellen. Wenn ein LLM Text verarbeitet, wird dieser zunächst in Token konvertiert. Das genaue Schema, das beim Zuordnen von Text und Token verwendet wird, variiert von Modell zu Modell. Den Token werden numerische Darstellungen zugewiesen und sie werden in Paketen angeordnet, die in das Modell eingespeist und vom Modell ausgegeben werden.

Ein weiterer Faktor, der sich auf die Gesamtlatenz der Anfragen auswirkt, ist die „Prefill“-Zeit. Dies ist die Zeit, die für die Verarbeitung der Eingabe-Prompt-Token benötigt wird, bevor das Modell den ersten neuen Token generiert. Ein dritter wichtiger Faktor für die Gesamtlatenz der Anfrage ist die Warteschlangenzeit. In Fällen, in denen der Inferenzservice Anfragen aufgrund von Hardwareeinschränkungen, wie GPU-Arbeitsspeicher, nicht schnell genug verarbeiten kann, um mit der eingehenden Datenlast Schritt zu halten, müssen einige Anfragen in einer Warteschlange warten, bevor sie verarbeitet werden. Aufgrund dieser Faktoren ist die „Time to First Token“ (TTFT) eine gängige Metrik für die Messung der LLM-Performance. TTFT ist besonders relevant für Use Cases wie Chatbots, bei denen die Token während der Generierung gestreamt und angezeigt werden.

Ähnlich wie die Latenz variiert auch der Durchsatz stark, wenn er als Anfragen pro Sekunde gemessen wird, je nach Anzahl der in den Anfragen generierten Token. Daher messen wir den Gesamtdurchsatz in Form der Gesamtanzahl der Token, die pro Sekunde von allen Nutzenden, die das Modell abfragen, generiert werden.

Belastungstests mit llm-load-test

Wir haben ein Open Source-Tool namens llm-load-test entwickelt, um die Modelle, die auf dem Modellbereitstellungs-Stack von OpenShift AI ausgeführt werden, einem Belastungstest zu unterziehen. Das in Python geschriebene Tool verwendet ghz, ein gRPC-Tool für Belastungstests. Wir haben in ghz die Option hinzugefügt, die Antwort und die Worker-Thread-ID für jede Anfrage in der Testausgabe zu speichern.

Neben den in ghz angebotenen Funktionen ermöglicht uns llm-load-test, in jeder Instanz parallel zum Eingabe-Dataset mehrere ghz-Prozesse in zufälliger Reihenfolge auszuführen. Dadurch können wir viele verschiedene Nutzende simulieren, die das Modell gleichzeitig mit unterschiedlichen Prompts abfragen. llm-load-test kann die Ergebnisse nach einem Experiment auch direkt in einen S3-Bucket hochladen und die Ausgabeobjekte mit den entsprechenden Metadaten für die Ausführung markieren.

Eingabe-Dataset

Sie können die Eingabe-Prompts in llm-load-test für den Belastungstest mit einer JSON-Datei konfigurieren. Wir haben ein Dataset mit 32 Eingaben aus dem OpenOrca-Dataset mit unterschiedlichen Eingabe-/Ausgabelängen für die Experimente ausgewählt, die wir durchgeführt haben, um die in diesem Blog-Beitrag vorgestellten Ergebnisse zu generieren. Die längste Eingabe in unseren Testdaten umfasste 1688 Token und die längste Ausgabe 377 Token. Abbildung 2 zeigt die Verteilung der Eingabe-/Ausgabelängen im Test-Dataset.

Abbildung 2. Tokenlänge des Test-Datasets

Es ist wichtig, verschiedene Eingabe- und Ausgabegrößen zu verwenden, um die kontinuierliche und dynamische Batch-Verarbeitung von TGIS in einem realistischen Szenario zu testen. Neuere Modelle unterstützen mittlerweile sehr große Kontextlängen von mehr als 4.000, was besonders für Anwendungsfälle wie Retrieval-Augmented Generation (RAG) wichtig ist. Aus diesem Grund beabsichtigen wir, unser Dataset für den Belastungstest zu vergrößern, um in Zukunft größere Eingabelängen einzuschließen.

Performance-Ergebnisse von llama-2 auf OpenShift AI in AWS

Die folgenden Performance-Messungen wurden mit einem selbstverwalteten IPI-OpenShift-Cluster (Installer-Provisioned Infrastructure) erfasst, der auf AWS installiert war. Wir haben den OpenShift AI-Operator installiert und ServingRuntime- und InferenceService-Objekte erstellt, um die Bereitstellung des Modells mit Kserve, Caikit und TGIS zu ermöglichen.

In Tabelle 1 sind die Testergebnisse von 4 Kombinationen aus Modell- und AWS-Instanztypen zusammengefasst:

Tabelle 1. Überblick über die Testkonfigurationen

In jeder Konfiguration haben wir mehrere vierminütige Belastungstests mit llm-load-test und einer unterschiedlichen Anzahl nebenläufiger Threads durchgeführt (den Nebenläufigkeitsparameter finden Sie in den folgenden Abbildungen). In jedem Test sendet jeder nebenläufige Thread fortlaufend jeweils eine Anfrage, sobald er die Antwort der vorherigen Anfrage erhält.

Als visuelles Beispiel für ein Experiment zeigt Abbildung 3 unten ein Diagramm der Gesamtlatenz jeder Anfrage während der Dauer des Tests. Die Farbe der einzelnen Punkte repräsentiert die Tokenlänge, um zu visualisieren, wie eng die Tokenlänge mit der gesamten Anfragesausgabe verknüpft ist.

Abbildung 3. Gesamtlatenz aller Anfragen während der Dauer eines Belastungstests

Wir haben die TGIS-Protokolle geparst, um die Gesamtlatenz der einzelnen Anfragen zu ermitteln, und den Durchsatz berechnet, indem wir die Gesamtzahl der während des Belastungstests generierten Token durch die Testdauer (240 Sekunden) dividiert haben.

Abbildung 4 zeigt die Latenz und den Durchsatz, die beim Belastungstest llama-2-7b auf der Instanz g5.2xlarge mit verschiedenen Einstellungen für nebenläufige Belastungstests gemessen wurden. In diesem Fall steigt der Durchsatz, wenn die Nebenläufigkeit des Belastungstests auf etwa 20 Threads erhöht wird. Aufgrund von GPU-Speichereinschränkungen der Instanz g5.2xlarge kann TGIS nicht mehr als etwa 20 Anfragen (abhängig von der Eingabe-/Ausgabelänge der Anfragen) gleichzeitig in einem Batch speichern.

Abbildung 4. Überblick über die Latenzzeiten und Durchsätze für Llama-2-7b auf g5.2xlarge

Das Diagramm in Abbildung 5 zeigt die Latenz und den Durchsatz, die beim Belastungstest llama-2-13B auf der Instanz g5.12xlarge gemessen wurden. In diesem Fall ist die Mindestlatenz pro Token zu Beginn bei g5.2xlarge niedriger ist als beim 7B-Modell und der Durchsatz kann durchaus auf mindestens 30 nebenläufige Anfragen skaliert werden, obwohl das Modell größer ist und die Instanz über denselben GPU-Typ verfügt. Dies liegt an den erheblichen Performance-Vorteilen, die die Verwendung von Tensorparallelität zur Verteilung des Modells auf die 4 GPUs bietet.

Abbildung 5. Überblick über die Latenzzeiten und Durchsätze für Llama-2-13b auf g5.12xlarge

Abbildung 6 zeigt die Latenz und den Durchsatz, die beim Belastungstest llama-2-70b auf der Instanz g5.48xlarge gemessen wurden. In diesem Fall ist die Latenz pro Token durchweg höher als in den vorherigen Konfigurationen. Modelle wie llama-2-70B stellen erhebliche Hardwareanforderungen dar. Die 8xA10G-GPUs verfügen über 192 GB VRAM, von denen der Großteil nur erforderlich ist, um die 70-B-Parameter mit einer 16-Bit-Präzision in den Speicher zu laden (70 B × 16 Bit = etwa 140 GB). Abhängig von Ihren Performance-Anforderungen benötigen Sie unter Umständen noch mehr Rechenleistung, etwa bei den p4d.24xlarge-Instanzen.

Abbildung 6. Überblick über die Latenzzeiten und Durchsätze für Llama-2-70b auf g5.48xlarge

Abbildung 7 zeigt die Latenz und den Durchsatz, die beim Belastungstest llama-2-70b auf der Instanz p4d.24xlarge gemessen wurden. Mit dieser Instanz können wir im Vergleich zur Instanz g5.48xlarge eine viel geringere Latenz bei gleicher Anzahl an Nutzenden aufrechterhalten. Selbst bei einer Nebenläufigkeit von bis zu 30 wird der Durchsatz weiter skaliert, wenn die Nebenläufigkeit des Belastungstests zunimmt.

Abbildung 7. Überblick über die Latenzzeiten und Durchsätze für Llama-2-70b auf p4d.24xlarge

Kostenberechnungen

Wir können die Kosten für das Generieren von 1 Million Token anhand der gemessenen Kosten für Durchsatz und Instanztyp schätzen. In der folgenden Tabelle werden diese Schätzungen unter Verwendung des gemessenen Durchsatzes für die Ergebnisse zusammengefasst, die wir mit einer Nebenläufigkeitslast von 10 erfasst haben.

Tabelle 2. Zusammenfassung der Ergebnisse für die einzelnen Konfigurationen mit berechneten CPM-Token (Cost per Million).

Zukünftige Aufgaben

Diese Ergebnisse sind eine kleine Momentaufnahme der Tests, die wir im PSAP-Team (Performance and Scale for AI Platforms) von Red Hat durchführen. Zusammen mit Performance-Tests für andere Aspekte von OpenShift AI analysieren wir auch weiterhin aktiv die Performance und Skalierbarkeit des Modellbereitstellungs-Stacks. Wir hoffen, in Zukunft weitere Ergebnisse durch das Testen von anderen Modellen, der automatischen Skalierung von Modell-Replikaten auf Basis des Datenverkehrs und mehr veröffentlichen zu können.

Wir werden llm-load-test weiterentwickeln und hoffen, bald einige neue Funktionen hinzufügen zu können, darunter:

• Die Möglichkeit, TTFT und TPOT für Streaming-Anfragen zu messen
• Pluginfähige/modulare Schnittstellen zur Abfrage der Modelle hinter verschiedenen APIs, darunter HTTP- und gRPC-Schnittstellen
• Eine Aufwärmphase und die Möglichkeit, zu validieren, ob das Modell geladen ist und ohne Fehler reagiert
• Komplexere Belastungsmuster, beispielsweise eine zufällige Poisson-Ereignisrate

Fazit

Unsere Performance-Tests von Llama-2-Modellen auf OpenShift AI bieten einen Überblick über die Latenz, den Durchsatz und die Kosten, die sich durch die Ausführung von LLMs in verschiedenen Konfigurationen ergeben. Für das 7 B-Modell war beispielsweise die Instanz g5.2xlarge am kostengünstigsten, aber der Wechsel zu g5.12xlarge kann für einige Use Cases aufgrund der Tensorparallelität und der damit einhergehenden erheblichen Latenz- und Durchsatzverbesserungen von Vorteil sein. Das Ausführen der größeren Modelle sollte zu einer höheren Ausgabequalität führen, erfordert jedoch mehr GPU-Arbeitsspeicher, was mit höheren Kosten verbunden ist.

OpenShift AI bietet eine leistungsfähige und anpassbare Modelllösung für Unternehmen, die die Komplexität der Bereitstellung generativer LLMs bewältigen müssen. Die Flexibilität der Plattform wird vielen unterschiedlichen Anforderungen gerecht, unabhängig davon, ob ein Unternehmen Modellqualität, Latenz, Durchsatz oder Kosten priorisiert. Testen Sie die Bereitstellung des Modells Ihrer Wahl auf OpenShift AI, um die Vorteile für Ihren spezifischen Use Case kennenzulernen.