Benchmarking van Llama-2-13B

In dit artikel benchmarken we de prestaties van LLama2-13B vanuit het perspectief van latency, kosten en requests per seconde. Dit helpt ons te beoordelen of het een goede keuze kan zijn op basis van de bedrijfsvereisten. Houd er rekening mee dat we in dit artikel niet ingaan op de kwalitatieve prestaties - er zijn verschillende methoden om LLMs te vergelijken, die u hier kunt vinden.

Model: Llama2-13B

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

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

We zijn op een reis om kunstmatige intelligentie te bevorderen en te democratiseren via open source en open wetenschap.

‍

Meta heeft de Llama 2-familie van Large Language Models (LLMs) ontwikkeld en publiekelijk uitgebracht, een verzameling van pre-trained en fine-tuned generatieve tekstmodellen variërend in schaal van 7 miljard tot 70 miljard parameters.

Te benchmarken metrieken

1. Requests per seconde (RPS): Het aantal requests per seconde dat het model verwerkt. Bij een hogere RPS neemt de latency meestal toe.
2. Latency: Hoeveel tijd is er nodig om een inference-request te voltooien?
3. Economie: Wat zijn de kosten verbonden aan het implementeren van een LLM?

Gebruiksscenario's & deployment-modi gebenchmarkt

De belangrijkste factoren waarop we hebben gebenchmarkt zijn:

GPU-type:

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

Promptlengte:

1. 1500 input-tokens, 100 output-tokens (Vergelijkbaar met Retrieval Augmented Generation-gebruiksscenario's)
2. 50 input-tokens, 500 output-tokens (Generatie-intensieve gebruiksscenario's)

Benchmarking-setup

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

In elke benchmarkingtest voor een deployment-configuratie begonnen we bij 1 gebruiker en verhoogden we de Number of Users geleidelijk totdat we een gestage toename in de RPS zagen. Tijdens de test hebben we ook de response times (in ms) en total requests per second uitgezet in grafieken.

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

‍

‍

Samenvatting benchmarkingresultaten

Latency, RPS en kosten

We berekenen de beste latency op basis van het versturen van slechts één request tegelijk. Om de doorvoer te verhogen, sturen we requests parallel naar de LLM. De maximale doorvoer is de situatie waarin het model de inkomende requests kan verwerken zonder aanzienlijke verslechtering van de latency.

Tokens per seconde

LLMs verwerken input-tokens en generatie op een andere manier - daarom hebben we de verwerkingssnelheid van input-tokens en output-tokens afzonderlijk berekend.

Gedetailleerde resultaten

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

In de bovenstaande grafieken kunnen we observeren dat de beste responstijd (bij 1 gebruiker) 4.5 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien dat de doorvoer toeneemt tot 0.8 RPS zonder dat de latency noemenswaardig afneemt. Boven 0.8 RPS neemt de latency drastisch toe, wat betekent dat requests in een wachtrij terechtkomen.

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

In de bovenstaande grafieken kunnen we observeren dat de beste responstijd (bij 1 gebruiker) 17 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien dat de doorvoer toeneemt tot 0.6 RPS zonder dat de latency noemenswaardig afneemt. Boven 0.6 RPS neemt de latency drastisch toe, wat betekent dat requests in een wachtrij terechtkomen.

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

In de bovenstaande grafieken kunnen we observeren dat de beste responstijd (bij 1 gebruiker) 3.3 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien dat de doorvoer toeneemt tot 1.4 RPS zonder dat de latency noemenswaardig afneemt. Boven 1.4 RPS neemt de latency drastisch toe, wat betekent dat requests in een wachtrij terechtkomen.

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

In de bovenstaande grafieken kunnen we observeren dat de beste responstijd (bij 1 gebruiker) 13 seconds is. We kunnen het aantal gebruikers verhogen om meer verkeer naar het model te sturen - we zien dat de doorvoer toeneemt tot 1.2 RPS zonder dat de latency noemenswaardig afneemt. Boven 1.2 RPS neemt de latency drastisch toe, wat betekent dat requests in een wachtrij terechtkomen.

Hopelijk is dit nuttig voor u om te bepalen of LLama2-13B geschikt is voor uw gebruiksscenario en welke kosten u kunt verwachten bij het hosten van LLama2-13B.