Het schalen van el serving van fine-tuned LoRA models

In de wereld van AI-applicatiedeployment is het schalen van de serving van fine-tuned models uitgegroeid tot een cruciale uitdaging. Stel je een scenario voor: je bent een SaaS-startup die 500 klanten bedient met uiteenlopende Behoeften, waarvoor fine-tuned Language Model (LLM)-aanpassingen nodig zijn voor interne ondersteuning en gepersonaliseerde marketingcontent. Dit brengt de enorme taak met zich mee om ongeveer 1000 models te fine-tunen.

Om deze beperkingen aan te pakken, is er LoRA Finetuning—een techniek waarbij de core LLM wordt bevroren en selectief specifieke weights worden verfijnd om bijgewerkte data te verwerken. Deze aanpak, die efficiënt en schaalbaar is, werkt op een fractie van de originele parameters die zijn gedefinieerd door de LoRA Configuration.

De echte uitdaging ontstaat echter bij het effectief deployen van deze fine-tuned adapters.

Experiment-setup

Tal van open-source LLM serving frameworks werken actief aan het integreren van LoRA adapters serving, maar een volledige oplossing blijft een uitdaging. In dit experiment verkennen we LoRAX van Predibase, een veelbelovend framework dat de code lijkt te hebben gekraakt voor het efficiënt serven en schalen van LoRA adapters.

💡

Raadpleeg hun blog voor meer inzichten over LoRAX van Predibase: LoRAX - Serve 100s of Fine-tuned LLMs for the Cost of One

Belangrijkste kenmerken van LoRAX

LoRAX onderscheidt zich met drie fundamentele pijlers van implementatie:

1. Dynamic Adapter Loading: Maakt just-in-time loading van fine-tuned LoRA weights mogelijk, waardoor gelijktijdige requests runtime geen hinder ondervinden.
2. Tiered Weight Caching: Faciliteert het snel wisselen van LoRA adapters tussen requests en voorkomt out-of-memory-problemen door adapter weights te offloaden naar CPU en disk.
3. Continuous Multi-Adapter Batching: Maakt gebruik van een fair scheduling policy om de totale throughput van het systeem te optimaliseren, waarbij continuous batching-strategieën parallel worden uitgebreid over meerdere sets LoRA adapters.

Prestatie-evaluatie met LoRAX

In ons experiment hebben we de prestaties van LoRAX uitgebreid geëvalueerd bij het beheren van een grote reeks fine-tuned adapters met behulp van het TinyLlama LLM model. Gedurende onze experimenten hebben we de efficiëntie gemeten bij het verwerken van talrijke requests over meerdere adapters.

Vereisten voor LoRAX Setup

Om onze experimenten te herhalen, volg je deze vereisten om LoRAX op je server in te stellen:

docker run \
   --gpus all \
   --shm-size 1g \
   -p 8080:80 \
   -v $PWD/data:/data \
   ghcr.io/predibase/lorax:latest \
   --model-id TinyLlama/TinyLlama-1.1B-Chat-v0.6 # base model used for finetuning


Installeer daarnaast de LoRAX client voor inference calls door gebruik te maken van:

pip install lorax-client


Inference-inzichten

Het gebruik van LoRAX voor het serven van LoRA fine-tuned models bood duidelijke voordelen dankzij het vermogen om één GPU te gebruiken voor het base LLM model, terwijl elke adapter dynamisch per request wordt geladen. Deze dynamische aanpak—het inzetten van een enkele GPU en het on-the-fly laden van adapters—maakt LoRAX een optimale oplossing voor het serven van een groot aantal fine-tuned LoRA models.

Inference-codevoorbeeld:

from lorax import Client

client = Client("https://example.lorax.truefoundry.tech", timeout=10)
generated_text = client.generate(
   prompt,
   do_sample=False,
   max_new_tokens=10,
   adapter_id=adapter_id,
   adapter_source="local"
).generated_text


Onze experimentele resultaten toonden overtuigend de aanzienlijke voordelen aan van het gebruik van LoRAX voor het serven van fine-tuned LoRA models. Door dynamic adapter loading per request en een effectief gebruik van een enkele A100 GPU voor het base LLM model, wist LoRAX de prestaties opmerkelijk te optimaliseren.

Prestatie-inzichten

In onze recente experimenten met het dynamisch laden van 100 adapters, hebben we de prestatiekenmerken nauwkeurig onderzocht. De initiële latency die tijdens het eerste request werd waargenomen, werd voornamelijk veroorzaakt door de noodzaak om het base LLM model in het geheugen te laden. Vervolgrequests lieten echter een afname in latency zien dankzij het vermogen van LoRax om snel van adapters te wisselen en real-time merges uit te voeren voor voorspellingen.

Eerder hebben we het proces van het laden van LoRA fine-tuned models met HuggingFace PEFT besproken in onze blogs. Onze experimenten brachten echter aanzienlijke problemen met deze aanpak aan het licht:

1) Latency-stijging bij meer adapters in het GPU-geheugen:
Het voornaamste probleem deed zich voor toen we probeerden meer adapters in het GPU-geheugen te passen. Dit leidde tot een duidelijke piek in latency. Met elke extra adapter nam de latency aanzienlijk toe, wat de algehele prestaties beïnvloedde.

2) Beperkte capaciteit in het GPU-geheugen:
Een andere kritieke beperking was de eindige set adapters die binnen het GPU-geheugen kon worden geplaatst. Deze beperking belemmerde de schaalbaarheid en vormde een knelpunt bij het gelijktijdig verwerken van een groter aantal adapters.

Om de prestatieverschillen verder te illustreren, bekijken we de volgende vergelijkingen:

Verwerking van 70 Tokens en generatie van 10 Tokens op een A100 GPU:
HuggingFace PEFT: Latency varieerde van 400-450 ms.
LoRAX: Liet een gemiddelde latency van 170 ms zien.

Impact van adapters op latency:
HuggingFace PEFT: Het toevoegen van 1000 TinyLlama LoRA adapters aan het base LLM deed de latency stijgen naar 3500-4000 ms, wat een toename van ongeveer 700% betekent.
LoRAX: Latency bleef consistent onbeïnvloed door het aantal adapters dankzij het dynamische loading-mechanisme op de GPU, wat zorgt voor een stabiele latency, zelfs bij een hoger aantal models.

Samenvattend: hoewel HuggingFace PEFT modelaanpassing en adaptergebruik faciliteert, kampt het met prestatie-uitdagingen naarmate het aantal adapters toeneemt, wat met name de latency en schaalbaarheid beïnvloedt. LoRAX onderscheidt zich daarentegen door het vermogen om adapters dynamisch te laden en voorspellingen in real-time uit te voeren, wat zorgt voor consistente prestaties en schaalbaarheid, zelfs bij een aanzienlijk aantal LoRA fine-tuned models.

Conclusie

De kracht van LoRAX om efficiënt om te gaan met diverse fine-tuned LoRA models terwijl een consistent base model behouden blijft, is een goed teken voor bedrijven die op zoek zijn naar schaalbare AI-diensten die zijn afgestemd op individuele klantbehoeften.

Door gebruik te maken van de efficiënte adapter loading-strategieën van LoRAX, kunnen bedrijven hun diensten met vertrouwen schalen naar duizenden specifiek afgestemde fine-tuned LoRA models, en dat alles met behoud van een uniform base model.

Kortom, LoRAX blijkt een gamechanger te zijn in het serven van fine-tuned adapters en biedt een schaalbare en geoptimaliseerde oplossing voor bedrijven die uiteenlopende AI models effectief willen deployen.

TrueFoundry is een ML Deployment PaaS op Kubernetes om developer workflows te versnellen, terwijl ze alle flexibiliteit behouden bij het testen en deployen van models, met volledige beveiliging en controle voor het Infra-team. Via ons platform stellen we Machine Learning-teams in staat om models te deployen en monitoren binnen 15 minuten met 100% betrouwbaarheid, schaalbaarheid en de mogelijkheid om binnen seconden te rollbacken - waardoor ze kosten besparen en Models sneller naar productie brengen voor echte zakelijke waarderealisatie.