LLAMA 2 Model-Benchmarks zur Leistungsbewertung verstehen

In diesem Artikel benchmarken wir die Leistung von LLama2-7B aus der Perspektive von Latenz, Kosten und Anfragen pro Sekunde. Dies hilft uns zu beurteilen, ob das Modell basierend auf den geschäftlichen Anforderungen eine gute Wahl sein kann. Bitte beachten Sie, dass wir in diesem Artikel die qualitative Leistung nicht abdecken - es gibt verschiedene Methoden zum Vergleichen von LLMs, die hier zu finden sind.

Modell: Llama2-7B

In diesem Blog haben wir das Modell Llama-2-7B von NousResearch gebenchmarkt. Dies ist eine vorkonfigurierte/pre-trainierte Version von Llama-2 mit 7 Milliarden Parametern.

‍

NousResearch/Llama-2-7b-hf · Hugging Face

Wir befinden uns auf einer Reise, um künstliche Intelligenz durch Open Source und Open Science voranzubringen und zu demokratisieren.

‍

Meta hat die Llama 2-Familie großer Sprachmodelle (LLMs) entwickelt und öffentlich freigegeben, eine Sammlung vorkonfigurierter und feingetunter generativer Textmodelle in einer Größenordnung von 7 Milliarden bis 70 Milliarden Parametern.

Mit dem LLAMA 2 Model gebenchmarkte Metriken: Bewertung von Leistungskennzahlen

1. Anfragen pro Sekunde (RPS): Anfragen pro Sekunde, die das Modell verarbeitet. Bei höherer RPS steigt in der Regel die Latenz.
2. Latenz: Wie viel Zeit wird benötigt, um eine Inference-Anfrage abzuschließen?
3. Wirtschaftlichkeit: Welche Kosten sind mit der Bereitstellung eines LLM verbunden?

Anwendungsfälle & Bereitstellungsmodi mit LLAMA 2: Szenarien evaluieren

Die Schlüsselfaktoren, anhand derer wir gebenchmarkt haben, sind:

GPU-Typ:

1. A100 40GB GPU
2. A10  24GB GPU

Prompt-Länge:

1. 1500 Input-Token, 100 Output-Token (Ähnlich wie bei Retrieval Augmented Generation Anwendungsfällen)
2. 50 Input-Token, 500 Output-Token (Generierungsintensive Anwendungsfälle)

Benchmarking-Setup mit LLAMA 2: Testumgebungen konfigurieren

Für das Benchmarking haben wir locust verwendet, ein Open-Source-Lasttest-Tool. Locust funktioniert durch das Erstellen von Usern/Workern, die Anfragen parallel senden. Zu Beginn jedes Tests können wir die Number of Users und Spawn Rate festlegen. Hier geben die Number of Users die maximale Anzahl von Benutzern an, die gleichzeitig erzeugt/ausgeführt werden können, während die Spawn Rate angibt, wie viele Benutzer pro Sekunde erzeugt werden.

In jedem Benchmarking-Test für eine Deployment-Konfiguration haben wir bei 1 Benutzer begonnen und die Number of Users schrittweise erhöht, bis wir einen stetigen Anstieg der RPS sahen. Während des Tests haben wir auch die response times (in ms) und total requests per second aufgetragen.

In jeder der 2 Deployment-Konfigurationen haben wir den Hugging Face text-generation-inference Modell-Server mit version=0.9.4 verwendet. Im Folgenden sind die Parameter aufgeführt, die an das text-generation-inference Image für verschiedene Modellkonfigurationen übergeben wurden:

‍

‍

Hier ist das Evaluierungs-Framework für die Angebotsvorlage

Kriterium	Was sollten Sie evaluieren?	Priorität	TrueFoundry
Einheitliche API & Routing
Einheitlicher OpenAI-kompatibler Endpunkt	Ist die Gateway-API kompatibel mit den OpenAI-Formaten /v1/chat/completions und /v1/responses, was einen konsistenten Zugriff über verschiedene Modelle hinweg über eine standardisierte Schnittstelle ermöglicht?	Erforderlich	✅ Unterstützt: OpenAI-kompatibler Endpunkt über alle Anbieter hinweg.
Anbieter- und Modellabdeckung	Unterstützt es führende Anbieter wie OpenAI, Azure OpenAI, Amazon Bedrock, Anthropic, Gemini, Groq sowie selbst gehostete Modelle?	Erforderlich	✅ Unterstützt: 1000+ LLMs über gehostete und selbst gehostete Anbieter hinweg.
Geschwindigkeit des Modell-Onboardings	Wie schnell können neue Modelle (OpenAI-kompatibel und Nicht-Standard-APIs) ohne Codeänderungen hinzugefügt werden?	Erforderlich	✅ Unterstützt: konfigurationsgesteuertes Onboarding innerhalb von Minuten.
Multimodale Unterstützung	Unterstützt das Gateway Text, Vision, Audio, Bildgenerierung und Embeddings über eine einzige Schnittstelle?	Abhängig vom Anwendungsfall	✅ Unterstützt: Chat, Embeddings, Bilder, Audio, Rerank und Realtime-APIs.
Routing, Lastverteilung, Fallback	Können Anfragen nach Modell, Anbieter, Latenz, Priorität, Gewichtung, Region und Fehlerstatus mit automatischen Wiederholungsversuchen geroutet werden?	Erforderlich	✅ Unterstützt: Lastverteilung, Fallbacks, gewichtetes und latenzbasiertes Routing.
Modellwechsel ohne Codeänderung	Wird der Modellwechsel über Header oder Konfiguration unterstützt, ohne den Client-Code zu ändern?	Erforderlich	✅ Unterstützt: header- und konfigurationsbasierter Modellwechsel.

AI Gateway Evaluierungs-Checkliste

Ein praktischer Leitfaden für Plattform- & Infra-Teams

Zusammenfassung der Benchmarking-Ergebnisse: Zusammenfassung der LLAMA 2-Erkenntnisse

Latenz, RPS und Kosten

Wir berechnen die beste Latenz basierend auf dem Senden von nur einer Anfrage zur Zeit. Um den Durchsatz zu erhöhen, senden wir Anfragen parallel an das LLM. Der maximale Durchsatz ist der Fall, in dem das Modell in der Lage ist, die eingehenden Anfragen ohne erhebliche Verschlechterung der Latenz zu verarbeiten.

Token pro Sekunde

LLMs verarbeiten Input-Token und die Generierung unterschiedlich – daher haben wir die Verarbeitungsrate für Input-Token und Output-Token getrennt berechnet.

Detaillierte Ergebnisse: Eingehende LLAMA 2-Analyse

A10 24GB GPU (1500 Input- + 100 Output-Token)

In den obigen Diagrammen können wir beobachten, dass die beste Antwortzeit (bei 1 Benutzer) 4.1 seconds beträgt. Wir können die Anzahl der Benutzer erhöhen, um mehr Traffic an das Modell zu senden – wir sehen, wie der Durchsatz bis zu 0.9 RPS steigt, ohne dass die Latenz erheblich abfällt. Über 0.9 RPS hinaus steigt die Latenz drastisch an, was bedeutet, dass sich Anfragen in einer Warteschlange stauen.

A10 24GB GPU (50 Input- + 500 Output-Token)

In den obigen Diagrammen können wir beobachten, dass die beste Antwortzeit (bei 1 Benutzer) 15 seconds beträgt. Wir können die Anzahl der Benutzer erhöhen, um mehr Traffic an das Modell zu senden – wir sehen, wie der Durchsatz bis zu 0.9 RPS steigt, ohne dass die Latenz erheblich abfällt. Über 0.9 RPS hinaus steigt die Latenz drastisch an, was bedeutet, dass sich Anfragen in einer Warteschlange stauen.

A100 40GB GPU (1500 Input- + 100 Output-Token)

In den obigen Diagrammen können wir beobachten, dass die beste Antwortzeit (bei 1 Benutzer) 2 seconds beträgt. Wir können die Anzahl der Benutzer erhöhen, um mehr Traffic an das Modell zu senden – wir sehen, wie der Durchsatz bis zu 3.6 RPS steigt, ohne dass die Latenz erheblich abfällt. Über 3.6 RPS hinaus steigt die Latenz drastisch an, was bedeutet, dass sich Anfragen in einer Warteschlange stauen.

A100 40GB GPU (50 Input- + 500 Output-Token)

In den obigen Diagrammen können wir beobachten, dass die beste Antwortzeit (bei 1 Benutzer) 8.5 seconds beträgt. Wir können die Anzahl der Benutzer erhöhen, um mehr Traffic an das Modell zu senden – wir sehen, wie der Durchsatz bis zu 3.5 RPS steigt, ohne dass die Latenz erheblich abfällt. Über 3.5 RPS hinaus steigt die Latenz drastisch an, was bedeutet, dass sich Anfragen in einer Warteschlange stauen.

Hoffentlich ist dies nützlich für Sie, um zu entscheiden, ob LLama7B zu Ihrem Anwendungsfall passt und welche Kosten beim Hosten von Llama7B zu erwarten sind.