Llama 2 Benchmarks Begrijpen voor Prestatie-evaluatie

In dit artikel benchmarken we de prestaties van Llama2-7B vanuit het perspectief van latentie, kosten en requests per seconde. Dit helpt om te evalueren of dit een goede keuze is op basis van je zakelijke vereisten. Houd er rekening mee dat we de kwalitatieve prestaties in dit artikel niet behandelen - er zijn verschillende methoden om LLM's te vergelijken die je hier kunt vinden.

Model: Llama2-7B

In deze blog hebben we het Llama-2-7B-model van NousResearch gebenchmarkt. Dit is een voorgeplande versie van Llama-2 met 7 miljard parameters.

‍

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

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

‍

Meta heeft de Llama 2-familie van Large Language Models (LLM's) ontwikkeld en openbaar gemaakt, een verzameling voorgeplande en ge-fine-tunede generatieve tekstmodellen variërend in schaal van 7 miljard tot 70 miljard parameters.

Metrieken Gebenchmarkt met LLAMA 2 Model: Beoordeling van Belangrijke KPI's

1. Requests per seconde (RPS): Het aantal requests per seconde dat het model verwerkt. Bij een hogere RPS neemt de latentie meestal toe.
2. Latentie: Hoeveel tijd kost het om een inference-verzoek te voltooien?
3. Kostenstructuur: Wat zijn de kosten die gepaard gaan met het hosten van een LLM?

Use Cases & Deployment-modi met LLAMA 2: Scenario's Evalueren

De belangrijkste factoren waarop we hebben gebenchmarkt zijn:

GPU-type:

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

Promptlengte:

1. 1500 Input-tokens, 100 Output-tokens (Vergelijkbaar met Retrieval Augmented Generation use cases)
2. 50 Input-tokens, 500 Output-tokens (Generatie-intensieve use cases)

Benchmark-opzet met LLAMA 2: Testomgevingen Configureren

Voor het benchmarken hebben we locust gebruikt, een open-source load-testing tool. Locust werkt door users/workers aan te maken om parallel verzoeken te sturen. Aan het begin van elke test kunnen we de Number of Users en Spawn Rate instellen. Hier geeft Number of Users het maximale aantal gebruikers aan dat gelijktijdig kan worden opgestart/uitgevoerd, terwijl Spawn Rate aangeeft hoeveel gebruikers er per seconde worden opgestart.

In elke benchmarktest voor een deployment-configuratie zijn we gestart vanaf 1 gebruiker en hebben we de Number of Users geleidelijk verhoogd totdat we een gestage toename van de RPS zagen. Tijdens de test hebben we ook de response times (in ms) en total requests per second in kaart gebracht.

In elk van de 2 deployment-configuraties hebben we de huggingface text-generation-inference model-server gebruikt met version=0.9.4. De volgende parameters zijn doorgegeven aan het text-generation-inference image voor verschillende modelconfiguraties:

‍

‍

Hier is het Evaluatie-framework voor Proposal Template

Criterium	Wat moet je evalueren?	Prioriteit	TrueFoundry
Geünificeerde API & Routing
Geünificeerd OpenAI-compatibel eindpunt	Is de gateway-API compatibel met de OpenAI /v1/chat/completions en /v1/responses formaten, wat consistente toegang biedt over verschillende modellen via een gestandaardiseerde interface?	Must have	✅ Ondersteund: OpenAI-compatibel eindpunt voor alle providers.
Provider- en modeldekking	Ondersteunt het vooraanstaande providers zoals OpenAI, Azure OpenAI, Amazon Bedrock, Anthropic, Gemini, Groq, plus self-hosted modellen?	Must have	✅ Ondersteund: 1000+ LLM's bij gehoste en self-hosted providers.
Snelheid van model-onboarding	Hoe snel kunnen nieuwe modellen (OpenAI-compatibel en niet-standaard API's) worden toegevoegd zonder code- aanpassingen?	Must have	✅ Ondersteund: onboarding via configuratie binnen enkele minuten.
Multimodale ondersteuning	Ondersteunt de gateway tekst, vision, audio, afbeeldingsgeneratie en embeddings via één enkele interface?	Afhankelijk van use case	✅ Ondersteund: chat, embeddings, afbeeldingen, audio, rerank en realtime API's.
Routing, load balancing, fallback	Kunnen verzoeken worden gerouteerd op basis van model, provider, latentie, prioriteit, gewicht, regio en foutstatus met automatische retries?	Must have	✅ Ondersteund: load balancing, fallbacks, routing op basis van gewicht en latentie.
Wisselen van model zonder code-aanpassing	Wordt het wisselen van model ondersteund via headers of configuratie zonder de clientcode te wijzigen?	Must have	✅ Ondersteund: modelwisseling via headers en configuratie.

AI Gateway Evaluatie-checklist

Een praktische gids gebruikt door platform- & infra-teams

Samenvatting Benchmarkresultaten: LLAMA 2 Bevindingen Samengevat

Latentie, RPS en Kosten

We berekenen de beste latentie op basis van het verzenden van slechts één verzoek tegelijk. Om de doorvoer te verhogen, sturen we verzoeken parallel naar de LLM. De maximale doorvoer is de situatie waarin het model de invoerverzoeken kan verwerken zonder aanzienlijke verslechtering van de latentie.

Tokens Per Seconde

LLM's verwerken input-tokens en generatie anders - daarom hebben we de verwerkingssnelheid van input-tokens en output-tokens afzonderlijk berekend.

Gedetailleerde Resultaten: Diepgaande LLAMA 2 Analyse

A10 24GB GPU (1500 input + 100 output tokens)

In de bovenstaande grafieken kunnen we zien dat de Beste Responstijd (bij 1 gebruiker) 4.1 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien de doorvoer toenemen tot 0.9 RPS zonder een aanzienlijke daling van de latentie. Boven 0.9 RPS neemt de latentie drastisch toe, wat betekent dat verzoeken in de wachtrij komen te staan.

A10 24GB GPU (50 input + 500 output tokens)

In de bovenstaande grafieken kunnen we zien dat de Beste Responstijd (bij 1 gebruiker) 15 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien de doorvoer toenemen tot 0.9 RPS zonder een aanzienlijke daling van de latentie. Boven 0.9 RPS neemt de latentie drastisch toe, wat betekent dat verzoeken in de wachtrij komen te staan.

A100 40GB GPU (1500 input + 100 output tokens)

In de bovenstaande grafieken kunnen we zien dat de Beste Responstijd (bij 1 gebruiker) 2 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien de doorvoer toenemen tot 3.6 RPS zonder een aanzienlijke daling van de latentie. Boven 3.6 RPS neemt de latentie drastisch toe, wat betekent dat verzoeken in de wachtrij komen te staan.

A100 40GB GPU (50 input + 500 output tokens)

In de bovenstaande grafieken kunnen we zien dat de Beste Responstijd (bij 1 gebruiker) 8.5 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien de doorvoer toenemen tot 3.5 RPS zonder een aanzienlijke daling van de latentie. Boven 3.5 RPS neemt de latentie drastisch toe, wat betekent dat verzoeken in de wachtrij komen te staan.

Hopelijk is dit nuttig voor je om te bepalen of Llama7B geschikt is voor jouw use case en welke kosten je kunt verwachten bij het hosten van Llama7B.