LLM's schalen en deployen

Het op schaal deployen van open-source Large Language Models (LLM's) met waarborging van betrouwbaarheid, lage latency en kostenefficiëntie kan een uitdagende taak zijn. Gebaseerd op onze uitgebreide ervaring met het bouwen van LLM-infrastructuur en het succesvol uitrollen hiervan voor onze klanten, heb ik een overzicht samengesteld van de belangrijkste uitdagingen die men in dit proces tegenkomt.

Belangrijkste uitdagingen bij het deployen van LLM's

Vind de meest optimale manier om één instantie van het model te hosten

Er zijn meerdere opties voor modelservers om LLM's te hosten en verschillende configuratieparameters die u kunt afstemmen voor de beste prestaties voor uw use case. TGI, VLLM en OpenLLM zijn enkele van de meest gebruikte frameworks voor het hosten van deze LLM's. Een gedetailleerde analyse vindt u in deze blog. Om het juiste framework voor uw hosting te kiezen, is het belangrijk om de prestaties van deze frameworks voor uw specifieke use case te benchmarken en degene te kiezen die hier het beste bij past. Bovendien beschikken deze frameworks over hun eigen instelbare parameters waarmee u de beste benchmarkresultaten kunt behalen.

Vinden van een vloot aan GPU's

GPU's zijn duur en schaars. Er zijn diverse GPU-cloudproviders, variërend van grote cloudplatformen zoals AWS, GCP en Azure tot kleinschaligere cloudproviders zoals Runpod, Fluidstack, Paperspace en Coreweave. Er zit veel variatie in de prijzen en het aanbod van elk van deze providers. Ook blijft betrouwbaarheid een aandachtspunt bij sommige van de nieuwere GPU-cloudproviders.

Betrouwbaarheid waarborgen

In de praktijk is dit lastiger dan het klinkt. Uit onze ervaring met het draaien van LLM's in productie blijkt dat u voorbereid moet zijn op vreemde, eenmalige bugs in modelservers die uw proces kunnen laten hangen, waardoor alle requests een timeout krijgen. Het is zeer belangrijk om goede procesmanagers en readiness/liveness probes in te stellen, zodat de modelservers kunnen herstellen van fouten of het verkeer naadloos kan overschakelen van een ongezonde naar een gezonde instantie.

Hoge doorvoer garanderen bij een lage latency

Tijdens het benchmarken is het cruciaal om de afweging te bepalen tussen latency en doorvoer. Naarmate het aantal gelijktijdige requests naar het model toeneemt, zal de latency tot op een bepaald punt licht stijgen, waarna deze drastisch verslechtert. Het vinden van de juiste balans tussen latency, doorvoer en kosten kan tijdrovend en foutgevoelig zijn. We hebben enkele blogs gepubliceerd met dergelijke benchmarks voor Llama7B en Llama13B.

Benchmarking van Llama-2-70B

Deze blog behandelt de Llama-2-70B benchmarks - waar een model in blinkt en op welke gebieden het moeite heeft. Neem weloverwogen beslissingen over de praktische deployment ervan.

TrueFoundry Blog Truefoundry

‍

Benchmarking van Falcon-40B

Deze blog behandelt Falcon-40B-Instruct benchmarks - waar een model in blinkt en op welke gebieden het moeite heeft. Neem weloverwogen beslissingen over de praktische deployment ervan.

TrueFoundry Blog Truefoundry

‍

Zorg voor een snelle opstarttijd van het model

LLM-modellen zijn enorm groot - variërend van tientallen tot 100 GB. Het kan veel tijd kosten om het model te downloaden zodra de modelserver gereed is, en het vervolgens van de schijf naar het geheugen te laden. Het is essentieel dat u het model op schijf cached, zodat u het model niet opnieuw hoeft te downloaden als het proces herstart. Om netwerkkosten te besparen is het bovendien beter om het model één keer te downloaden en de schijf te delen tussen meerdere replica's, in plaats van dat elke replica het model herhaaldelijk via het internet downloadt.

Autoscaling instellen

Autoscaling is ingewikkeld bij LLM-hosting vanwege de lange opstarttijd van een nieuwe replica. Als de belasting erg piekgevoelig is, moeten we de infrastructuur meestal dimensen op basis van het maximale aantal replica's - maar als de piek op vaste tijden van de dag wordt verwacht, werkt tijdsgebaseerde autoscaling erg goed.

Hoe neemt u LLM's in productie?

1. Begin met het benchmarken van de LLM met verschillende modelservers, GPU's en parameters om te zien waar u de beste prestaties behaalt. Idealiter beschikt u over benchmarkgegevens vergelijkbaar met wat we in deze blog voor Llama7B laten zien.
2. U kunt modellen instellen op meerdere GPU's op Kubernetes of op bare-metal instanties. Wij raden idealiter Kubernetes aan, omdat u alle health checks, routing en failover er gratis bij krijgt.
3. Plaats het model op een gedeeld volume zoals EFS, zodat modellen niet herhaaldelijk gedownload hoeven te worden, en koppel het volume aan alle pods.
4. Stel monitoring en alerting in op de instanties.
5. Zorg idealiter voor een laag die de tokens telt voor elk request, aangezien het zo eenvoudiger is om het patroon van het inkomende verkeer te begrijpen.
6. Observeer het verkeerspatroon en pas de autoscaling-policy hierop aan.
7. Gebruik een mix van spot- en on-demand-instanties om de kosten te verlagen.

Architectuur voor het op schaal hosten van LLM's

We begonnen met de bovenstaande aanpak, maar zijn al snel gemigreerd naar de onderstaande architectuur, waarmee we LLM's kunnen hosten tegen zeer lage kosten en met een hoge betrouwbaarheid.

In essentie maken we meerdere GPU-pools aan bij verschillende cloudproviders in verschillende regio's. We gebruiken gewoonlijk spot-instanties als het gaat om AWS, GCP of Azure, of on-demand nodes van de kleinere cloudproviders. We plaatsen er ook een queue tussen die alle requests opvangt. De verschillende GPU-pools verwerken de opdrachten uit de queue en sturen de respons terug naar de queue, van waaruit de HTTP-respons naar de gebruiker wordt gestuurd. Enkele voordelen van deze architectuur:

1. Hoge betrouwbaarheid met spot-instanties: Doordat we de belasting verdelen over spot-instanties van meerdere cloudproviders en regio's, is de kans dat alle spot-instanties tegelijk uitvallen extreem klein. Elk van de pools kan schalen om de belasting op te vangen wanneer er één pool uitvalt.
2. Queue biedt extra betrouwbaarheid bij hoge belasting: Een HTTP-dienst zal 503-fouten gaan retourneren bij plotselinge pieken. Dankzij de queue ertussen zijn we in staat om piekbelastingen op te vangen - er is een lichte toename in latency voor de requests tijdens de piek, maar ze mislukken niet. Het toevoegen van de queue veroorzaakt een totale latency van zo'n 10-20 ms, wat prima is voor LLM-inference use cases, aangezien de totale inference-latency in de orde van seconden ligt.
3. Kostenverlaging: Dit helpt de kosten drastisch te verlagen in vergelijking met het hosten van LLM's op on-demand-instanties - hieronder maken we een gedetailleerde vergelijking van de kosten.
4. Gedetailleerde analyses: De LLM gateway-laag helpt ons bij het berekenen van gedetailleerde analyses over de inkomende requests en kan ook de tokenverdeling over de requests berekenen. We kunnen de requests ook gaan loggen om finetuning op een later moment mogelijk te maken.
5. Geen afhankelijkheid van één cloudprovider: Deze architectuur stelt ons in staat om eenvoudig onze ene GPU-provider te vervangen door een andere als we ergens een betere prijs vinden, zonder enige downtime. En mocht er één provider uitvallen, dan zorgen de andere pools ervoor dat het systeem soepel blijft draaien!

Kostenverlaging voor het hosten van LLM's

Laten we uitgaan van een scenario waarin we een LLM hosten met 10 requests per seconde op het piekmoment en gemiddeld 7 requests per seconde. Stel dat we via benchmarking vaststellen dat één A100 80GB GPU-machine 0,5 RPS kan verwerken. Laten we er ook van uitgaan dat het verkeer gedurende 12 uur per dag hoger is (ongeveer 9-10 RPS) en lager gedurende de overige 12 uur van de dag (7-8 RPS).

Op basis van bovenstaande gegevens kunnen we het aantal benodigde GPU-machines bepalen voor de piekperiode van 12 uur en de dalperiode van 12 uur:

Piekperiode van 12 uur: 20 GPU's
Dalperiode van 12 uur: 15 GPU's

We vergelijken de kosten van het draaien van de LLM op SageMaker, het naïef hosten op on-demand machines in AWS, GCP en Azure, en het gebruik van onze eigen architectuur met autoscaling.

Kosten van hosten op SageMaker (regio us-east-1):

Kosten van een machine met 8 A100 80GB GPU's (ml.p4de.24xlarge) -> $ 47,11 per uur

We hebben 2 machines nodig tijdens daluren en 3 machines tijdens piekuren.

Totale maandelijkse kosten: $ 85K

Kosten van rechtstreeks hosten op AWS-nodes:

Kosten van een machine met 8 A100 80GB GPU's (p4de.24xlarge) -> $ 40,966 per uur

We hebben 2 machines nodig tijdens daluren en 3 machines tijdens piekuren:

Totale maandelijkse kosten: $ 73K

Kosten van hosten op TrueFoundry

Door gebruik te maken van spot-instanties en andere GPU-providers slagen we erin de gemiddelde GPU-prijs terug te brengen naar $ 2,5 per uur. Uitgaande van 15 GPU's tijdens daluren en 20 GPU's tijdens piekuren, worden de totale kosten:

$ 2,5 * (15*12 + 20*12) * 30 (dagen per maand) = $ 31K

Zoals we kunnen zien, zijn we in staat om dezelfde LLM te hosten tegen bijna 30% van de prijs van SageMaker, met behoud van een hoge betrouwbaarheid. Het bouwen en onderhouden van deze architectuur vraagt echter de nodige inspanning. TrueFoundry kan helpen dit voor u te hosten of het op uw eigen cloudaccount in te richten zonder gedoe, terwijl u tegelijkertijd op de kosten bespaart.