Verbeter de prestaties van Falcon-modellen met Amazon SageMaker | Amazon-webservices

Wat is het optimale raamwerk en de optimale configuratie voor het hosten van grote taalmodellen (LLM's) voor tekstgenererende generatieve AI-toepassingen? Ondanks de overvloed aan opties voor het bedienen van LLM's, is dit een moeilijke vraag om te beantwoorden vanwege de omvang van de modellen, de variërende modelarchitecturen, prestatie-eisen van applicaties en meer. De Amazon Sage Maker Grote Model Inference (LMI)-container maakt het eenvoudig om LLM’s te bedienen door een groot aantal verschillende raamwerken en technieken samen te brengen die de inzet van LLM’s optimaliseren. De LMI-container heeft een krachtige serveerstapel genaamd DJL-bediening dat is agnostisch voor de onderliggende LLM. Het biedt configuratieparameters op systeemniveau die kunnen worden afgestemd om de beste prestaties van de hostinginfrastructuur voor een bepaalde LLM te verkrijgen. Het biedt ook ondersteuning voor recente optimalisaties zoals continue batching, ook wel iteratieve batching of rolling batching genoemd, wat aanzienlijke verbeteringen in de doorvoer oplevert.

In een eerdere posthebben we laten zien hoe u de LMI-container kunt gebruiken om de Falcon-modellenfamilie op SageMaker te implementeren. In dit bericht laten we zien hoe u de doorvoer en latentie van Falcon-40B kunt verbeteren met technieken zoals continue batching. We bieden ook een intuïtief inzicht in de configuratieparameters van de SageMaker LMI-container, waarmee u de beste configuratie voor uw praktijktoepassing kunt vinden.

Grondbeginselen van tekstgeneratieve inferentie voor LLM's

Laten we eerst eens kijken naar enkele basisbeginselen voor het uitvoeren van gevolgtrekkingen voor LLM's voor het genereren van tekst.

Voorwaartse pas, activeringen en de KV-cache

Gegeven een invoerreeks van tokens, worden ze uitgevoerd in a forward pass over alle lagen van de LLM (zoals Falcon) om het volgende token te genereren. A forward pass verwijst naar het proces waarbij invoergegevens door een neuraal netwerk worden doorgegeven om een ​​uitvoer te produceren. In het geval van tekstgeneratie omvat de voorwaartse doorgang het invoeren van een initiële kiem of context in het taalmodel en het genereren van het volgende teken of token in de reeks. Om een ​​reeks tekst te genereren, wordt het proces vaak iteratief uitgevoerd, wat betekent dat het voor elke stap of positie in de uitvoerreeks wordt herhaald. Bij elke iteratie genereert het model het volgende teken of token, dat onderdeel wordt van de gegenereerde tekst, en dit proces gaat door totdat de gewenste tekstlengte is gegenereerd.

Tekstgeneratie met taalmodellen zoals Falcon of GPT is dat wel autoregressive. Dit betekent dat het model één token tegelijk genereert, terwijl het de eerder gegenereerde tokens conditioneert. Met andere woorden: bij elke iteratie neemt het model de eerder gegenereerde tekst als invoer en voorspelt het volgende token op basis van die context. Zoals vermeld in vLLM: eenvoudige, snelle en goedkope LLM-presentatie met PagedAttentionIn dit autoregressieve decoderingsproces produceren alle invoertokens voor de LLM hun aandachtssleutel en waardetensoren, en deze tensoren worden in het GPU-geheugen bewaard om volgende tokens te genereren. Deze in de cache opgeslagen sleutel- en waardetensoren worden vaak de KV cache.

Fasen vooraf invullen en decoderen

In een autoregressief decoderingsproces, zoals dat wordt gebruikt bij het genereren van tekst met taalmodellen zoals Falcon, zijn er doorgaans twee hoofdfasen: de prefill fase en de decode fase. Deze fasen zijn cruciaal voor het genereren van samenhangende en contextueel relevante tekst.

De voorvulfase omvat het volgende:

• Initiële context – De prefill-fase begint met een initiële context of zaadtekst die door de gebruiker wordt aangeleverd. Deze initiële context kan een zin, een zinsnede of zelfs maar een enkel woord zijn. Het vormt het startpunt voor het genereren van tekst en biedt context voor wat daarna komt.
• Modelconditionering – De verstrekte context wordt gebruikt om het taalmodel te conditioneren. Het model neemt deze context als invoer en genereert het volgende token (woord of teken) in de reeks op basis van zijn begrip van de context.
• Token generatie – Het model genereert één token tegelijk en voorspelt wat er daarna in de tekst moet komen. Dit token wordt aan de context toegevoegd, waardoor deze effectief wordt uitgebreid.
• Iteratief proces – Het proces van het genereren van tokens wordt iteratief herhaald. Bij elke stap genereert het model een token, waarbij rekening wordt gehouden met de bijgewerkte context, die nu de tokens bevat die in eerdere stappen zijn gegenereerd.

De voorvulfase gaat door totdat aan een vooraf bepaalde stopvoorwaarde is voldaan. Deze voorwaarde kan een maximale lengte voor de gegenereerde tekst zijn, een specifiek token dat het einde van de tekst aangeeft, of andere criteria die door de gebruiker of de applicatie zijn ingesteld.

De decodeerfase omvat het volgende:

• Voltooiing – Na de invulfase beschikt u over een gedeeltelijk gegenereerde tekst die op een gegeven moment onvolledig of afgebroken kan zijn. De decodeerfase is verantwoordelijk voor het voltooien van de tekst, zodat deze coherent en grammaticaal correct wordt.
• Vervolg van het laatste token – In de decodeerfase vertrekt het model van het laatste token dat tijdens de prefill-fase is gegenereerd. Het gebruikt dit token als de initiële context en genereert het volgende token om de tekst voort te zetten.
• Iteratieve voltooiing – Net als in de prefill-fase is het proces van het genereren van tokens opnieuw iteratief. Het model genereert één token tegelijk, afhankelijk van de voorgaande tokens in de reeks.
• Stopconditie – De decodeerfase heeft ook een stopvoorwaarde, die dezelfde kan zijn als in de prefill-fase, zoals het bereiken van een maximale lengte of het tegenkomen van een end-of-text-token. Wanneer aan deze voorwaarde is voldaan, stopt het generatieproces.

De combinatie van de voorvul- en decoderingsfasen maakt het mogelijk dat autoregressieve modellen tekst genereren die voortbouwt op een initiële context en coherente, contextueel relevante en contextueel consistente tekstreeksen produceert.

Verwijzen naar Een gedistribueerd serveersysteem voor op transformatoren gebaseerde generatieve modellen voor een gedetailleerde uitleg van het proces.

Optimalisatie van de doorvoer met behulp van dynamische batching

Tot nu toe hebben we het slechts over één enkele input gehad. In de praktijk verwachten we dat we meerdere verzoeken die willekeurig binnenkomen van de applicatieclients gelijktijdig of op een gespreide manier kunnen afhandelen. Op de traditionele manier kan basisbatching worden gebruikt om de doorvoer en het gebruik van de computerbronnen van de GPU te vergroten. Batching is het effectief combineren van de numerieke representaties van meer dan één verzoek in een batch en het uitvoeren van parallelle runs van de autoregressieve voorwaartse passen. Deze intelligente batching gebeurt aan de serveerzijde. De DJLServing-server van SageMaker LMI kan worden geconfigureerd om meerdere verzoeken samen te voegen om ze parallel te verwerken door de volgende parameters in te stellen serveren.eigenschappen:

• max_batch_delay = 100 – De maximale vertraging voor batchaggregatie in milliseconden. De standaardwaarde is 100 milliseconden.
• seriegrootte = 32 – De dynamische batchgrootte. De standaardwaarde is 1.

Dit laat in principe zien dat DJLServing verzoeken voor 100 milliseconden per keer in de wachtrij plaatst, of als het aantal verzoeken dat in de wachtrij staat de opgegeven batch_size bereikt, wordt de batch gepland om naar de backend te worden uitgevoerd voor gevolgtrekking. Dit staat bekend als dynamic batching. Het is dynamisch omdat de batchgrootte tussen batches kan veranderen, afhankelijk van het aantal verzoeken dat in die tijdsduur is toegevoegd. Omdat verzoeken echter verschillende kenmerken kunnen hebben (sommige verzoeken kunnen bijvoorbeeld de vorm hebben van 20 tokens voor invoer en 500 tokens voor uitvoer, terwijl andere omgekeerd kunnen zijn, met 500 tokens voor invoer maar slechts 20 voor uitvoer), kunnen sommige verzoeken mogelijk voltooi de verwerking sneller dan andere in dezelfde batch. Dit kan resulteren in onderbenutting van de GPU tijdens het wachten tot alle in-flight-aanvragen in de batch de decoderingsfase hebben voltooid, zelfs als er nog meer verzoeken in de wachtrij staan ​​te wachten om te worden verwerkt. Het volgende diagram illustreert dit proces.

Optimalisatie van de doorvoer met behulp van continue batching

met continuous batching, ook gekend als iterative or rolling batching maken we gebruik van de verschillen tussen de prefill- en decodeerfasen. Om continue batching te activeren, biedt DJServing de volgende aanvullende configuraties volgens Sering.Properties:

• machine=MPI – We raden u aan de MPI-engine te gebruiken voor continue batchverwerking.
• optie.rolling_batch=auto of lmi-dist – We raden aan om auto te gebruiken, omdat hiermee in de toekomst automatisch het meest geschikte rolling batch-algoritme wordt gekozen, samen met andere optimalisaties.
• optie.max_rolling_batch_size=32 – Dit beperkt het aantal gelijktijdige verzoeken. De standaardwaarde is 32.

Bij continu batchen wacht de serveerstapel (DJLServing) niet tot alle in-flight verzoeken in een batch de decoderingsfase hebben voltooid. In plaats daarvan haalt het bij logische onderbrekingen (aan het einde van één iteratie in de decodeerfase) aanvullende verzoeken binnen die in de wachtrij wachten terwijl de huidige batch nog bezig is met verwerken (vandaar de naam rollende partij). Het voert deze controle uit op openstaande verzoeken aan het einde van elke iteratie van de decoderingsfase. Houd er rekening mee dat we voor elk verzoek de fase van vooraf invullen moeten uitvoeren, gevolgd door de fase van sequentiële decodering. Omdat we alle tokens vanaf de eerste prompt van een verzoek parallel kunnen verwerken voor de prefill-fase, pauzeren we telkens wanneer een nieuw verzoek wordt binnengehaald, tijdelijk de decodeerfase van in-flight-verzoeken van de batch - we slaan tijdelijk de KV-cache op en activeringen in het geheugen en voer de prefill-fase van de nieuwe verzoeken uit.

De grootte van deze cache kan worden geconfigureerd met de volgende optie:

Wanneer het vooraf invullen is voltooid, combineren we de nieuwe verzoeken en de oude gepauzeerde verzoeken in een nieuwe rollende batch, die parallel kan doorgaan met hun decoderingsfase. Houd er rekening mee dat de oude gepauzeerde verzoeken hun decoderingsfase kunnen voortzetten waar ze waren gebleven en dat de nieuwe verzoeken beginnen vanaf hun eerste nieuwe token.

Je hebt je misschien al gerealiseerd dat continu batchen een vrijwel vergelijkbare aanpak is waarmee we op natuurlijke wijze taken in ons dagelijks leven parallelliseren. Er komen op willekeurige tijdstippen berichten, e-mails en telefoonmeldingen (mogelijk nieuwe verzoeken) binnen (analoog aan meerdere verzoeken die op willekeurige, gespreide wijze binnenkomen voor GPU's). Dit gebeurt allemaal terwijl we bezig zijn met het voltooien van onze taken tijdens de vlucht: e-mails opstellen, coderen, deelnemen aan vergaderingen (analoog aan de huidige verwerkingstaken in de GPU's). Bij logische pauzes pauzeren we onze taken tijdens de vlucht en controleren we onze meldingen om te beslissen of er enige actie van onze kant vereist is, en als dat het geval is, voegen we deze toe aan onze taken tijdens de vlucht (real-life rolling batch), of plaats het op een takenlijst (de wachtrij).

Alles bij elkaar: hoe u moet nadenken over het geheugengebruik van GPU's

Het wordt aanbevolen om uw model te laden om te zien welke configuratie het meest kosteneffectief is voor uw zakelijke gebruik. Laten we, om meer inzicht te krijgen, de geheugenvoetafdruk van de GPU's visualiseren terwijl het model wordt geladen en terwijl opeenvolgende verzoeken in een rollende batch worden verwerkt. Laten we voor dit bericht aannemen dat we het Falcon-40B-model laden op een van de G5-instantietypen die zijn geïnstalleerd met NVIDIA A10G GPU's, elk met 24 GB geheugen. Houd er rekening mee dat een soortgelijk begrip van toepassing is op de p3-, p4- en p5-instancetypen, die worden geleverd bij de V100-, A100- en H100 GPU-series.

Het volgende is een overzicht van hoe u een geschatte waarde krijgt van het totale geheugen dat nodig is om Falcon-40B te bedienen:

• Model maat = Aantal modelparameters (40 miljard voor Falcon-40B) x 4 bytes per parameter (voor FP32) = 160 GB
• Geschatte totale hoeveelheid geheugen die nodig is om Falcon-40B te laden voor gevolgtrekking = Modelgrootte (=160 GB) + KV Cache (Attention Cache) (=*20 GB) + Extra geheugenoverhead door ML Frameworks (ongeveer 2 GB)

Als we voor Falcon-40B het model comprimeren door het te kwantiseren naar het gegevenstype bfloat16 (2 bytes), wordt de modelgrootte ongeveer 80 GB. Zoals u kunt zien is dit nog steeds groter dan het geheugen dat door één acceleratorapparaat wordt ondersteund, dus moeten we een modelpartitioneringstechniek (sharding) gebruiken met een speciaal tensor parallellisme (TP) benader en verdeel het model over meerdere acceleratorapparaten. Laten we aannemen dat we g5.24xlarge hebben gekozen, die 4 A10G GPU-apparaten heeft. Als we DJLServing (serving.properties) met het volgende configureren, kunnen we verwachten dat de 80 GB aan modelgewicht gelijkelijk over alle 4 GPU's wordt verdeeld:

met tensor_parallel_degree ingesteld op 4, wordt ongeveer 20 GB van het 24 GB GPU-geheugen (ongeveer 84%) al gebruikt, zelfs voordat een enkel verzoek is verwerkt. De resterende 16% van de GPU wordt gebruikt voor de KV-cache voor de inkomende verzoeken. Het is mogelijk dat voor uw bedrijfsscenario en de latentie- en doorvoervereisten 2 tot 3 GB van het resterende geheugen ruim voldoende is. Als dit niet het geval is, kunt u de instantiegrootte vergroten naar g5.48xlarge, die 8 GPU's heeft en tensor_parallel_degree gebruikt die is ingesteld op 8. In een dergelijk geval wordt slechts ongeveer 10 GB van het beschikbare 24 GB-geheugen van elke GPU gebruikt voor modelgewichten en we hebben ongeveer 60% van de resterende GPU voor de activeringen en KV-cache. Intuïtief kunnen we zien dat deze configuratie ons mogelijk een hogere doorvoercapaciteit biedt. Omdat we nu een grotere buffer hebben, kunnen we bovendien de buffer vergroten max_rolling_batch_prefill_tokens en max_rolling_batch_size parameters om de doorvoer verder te optimaliseren. Samen bepalen deze twee parameters de voorafgaande toewijzingen van de activeringsvoorvullingen en de KV-cache voor het model. Een groter getal voor deze twee parameters houdt verband met een grotere doorvoer, ervan uitgaande dat u voldoende buffer heeft voor de KV-cache in het GPU-geheugen.

Continue batchverwerking met PagedAttention

PagedAttention is een nieuw optimalisatie-algoritme ontwikkeld door UC Berkeley dat het continue batchingproces verbetert door ervoor te zorgen dat de aandachtscache (KV-cache) niet aaneengesloten is door geheugen toe te wijzen aan pagina's of blokken met een vaste grootte. Dit is geïnspireerd op virtueel geheugen en paging-concepten die door besturingssystemen worden gebruikt.

Volgens de vLLM Op papier wordt de aandachtscache van elke reeks tokens opgedeeld in blokken en via een bloktabel toegewezen aan fysieke blokken. Tijdens de berekening van aandacht kan een PagedAttention-kernel de bloktabel gebruiken om de blokken efficiënt uit het fysieke geheugen op te halen. Dit resulteert in een aanzienlijke vermindering van geheugenverspilling en zorgt voor een grotere batchgrootte, verhoogd GPU-gebruik en hogere doorvoer.

Prestatievergelijking

Om een ​​effectieve belastingtest van uw implementatieconfiguratie te garanderen, is het raadzaam om eerst het bedrijfsscenario te overwegen en de kenmerken van de invoer en uitvoer voor de op LLM gebaseerde toepassing duidelijk te definiëren. Als u bijvoorbeeld werkt aan een gebruiksscenario voor een samenvatting van een callcenter, kan de invoer bestaan ​​uit grotere tekst, zoals een chattranscriptie van 500 tokens tussen een medewerker van de klantenservice en een klant, maar de uitvoer kan relatief kleiner zijn, ongeveer 100 token. tokens, die een samenvatting van het transcript vertegenwoordigen. Aan de andere kant, als je werkt aan een scenario voor het genereren van code, kan de invoer zo kort zijn als 15 tokens, zoals "schrijf een efficiënte implementatie in Python voor het beschrijven van alle EC2-bronnen, inclusief paginering", maar de uitvoer kan veel zijn. groter, tot 500 tokens. Het is ook belangrijk om te overwegen of het bereiken van een lagere latentie of het maximaliseren van de doorvoer de topprioriteit is voor uw specifieke scenario.

Nadat u een uitgebreid inzicht heeft gekregen in het bedrijfsscenario, kunt u de optimale configuratie voor uw hostingomgeving analyseren en bepalen. In deze context omvat de hostingomgeving verschillende sleutelelementen, waaronder het instancetype en andere configuratieparameters zoals tensor_parallel_graad, max_rolling_batch_size, max_rolling_batch_prefill_tokens, en meer. Ons doel is om de meest effectieve configuratie te identificeren om onze vereisten op het gebied van responstijd, doorvoer en modeluitvoerkwaliteit te ondersteunen.

In onze analyse hebben we de prestaties gebenchmarkt om de voordelen van continue batchverwerking ten opzichte van traditionele dynamische batchverwerking te illustreren. We hebben de configuraties gebruikt die in de volgende tabel worden beschreven in serve.properties voor dynamische batching en iteratieve batching, met behulp van een LMI-container op SageMaker.

Dynamische batchverwerking	Continu batchen	Continue batchverwerking met PagedAttention
motor=Python optie.model_id=tiiuae/falcon-40b optie.tensor_parallel_degree=8 optie.dtype=fp16 batch_grootte=4 max_batch_delay=100 optie.trust_remote_code = waar	motor = MPI optie.model_id = {{s3_url}} optie.trust_remote_code = waar optie.tensor_parallel_degree = 8 optie.max_rolling_batch_size = 32 optie.rolling_batch = automatisch optie.dtype = fp16 optie.max_rolling_batch_prefill_tokens = 1024 optie.paged_attention = Onwaar	motor = MPI optie.model_id = {{s3_url}} optie.trust_remote_code = waar optie.tensor_parallel_degree = 8 optie.max_rolling_batch_size = 32 optie.rolling_batch = automatisch optie.dtype = fp16 optie.max_rolling_batch_prefill_tokens = 1024 optie.paged_attention = Waar

De twee configuraties zijn gebenchmarkt voor Falcon-40B met het FP16-gegevenstype geïmplementeerd op ml.g5.48xlarge in een aantal verschillende scenario's die toepassingen uit de echte wereld vertegenwoordigen:

• Een klein aantal invoertokens waarbij een groot aantal tokens wordt gegenereerd – In dit scenario werd het aantal invoertokens vastgesteld op 32 en werden er 128 nieuwe tokens gegenereerd

Batching-strategie	Doorvoer (tokens/sec)	Latentie p90 (sec)
Dynamische batchverwerking	5.53	58.34
Continu batchen	56.04	4.74
Continue batchverwerking met PagedAttention	59.18	4.76

• Een grote invoer waarbij een klein aantal tokens wordt gegenereerd – Hier stellen we het aantal invoertokens vast op 256 en vragen we de LLM om de invoer samen te vatten tot 32 tokens

Batching-strategie	Doorvoer (tokens/sec)	Latentie p90 (sec)
Dynamische batchverwerking	19.96	59.31
Continu batchen	46.69	3.88
Continue batchverwerking met PagedAttention	44.75	2.67

We kunnen zien dat continue batching met PagedAttention een doorvoerverbetering oplevert die 10 keer groter is in scenario 1 en 2.3 keer groter in scenario 2 vergeleken met het gebruik van dynamische batching op SageMaker bij gebruik van de LMI-container.

Conclusie

In dit bericht hebben we gekeken hoe LLM's geheugen gebruiken en uitgelegd hoe continue batching de doorvoer verbetert met behulp van een LMI-container op SageMaker. We hebben de voordelen van continue batching voor Falcon-40B met behulp van een LMI-container op SageMaker gedemonstreerd door benchmarkresultaten te tonen. De code vind je op de GitHub repo.

---

Over de auteurs

Abhi Shivaditya is een Senior Solutions Architect bij AWS en werkt samen met strategische wereldwijde bedrijfsorganisaties om de acceptatie van AWS-services op gebieden als kunstmatige intelligentie, gedistribueerde computers, netwerken en opslag te vergemakkelijken. Zijn expertise ligt in Deep Learning in de domeinen Natural Language Processing (NLP) en Computer Vision. Abhi helpt klanten bij het efficiënt inzetten van krachtige machine learning-modellen binnen het AWS-ecosysteem.

Dhawal Patel is een Principal Machine Learning Architect bij AWS. Hij heeft gewerkt met organisaties variërend van grote ondernemingen tot middelgrote startups aan problemen met betrekking tot gedistribueerde computing en kunstmatige intelligentie. Hij richt zich op Deep learning inclusief NLP en Computer Vision domeinen. Hij helpt klanten bij het bereiken van high-performance modelinferentie op SageMaker.

Pinak Panigrahi werkt samen met klanten om door machine learning aangedreven oplossingen te bouwen om strategische bedrijfsproblemen op AWS op te lossen. Als hij niet bezig is met machinaal leren, kan hij een wandeling maken, een boek lezen of naar sport kijken.

Abhi Sodhani bekleedt de functie van Senior AI/ML Solutions Architect bij AWS, waar hij gespecialiseerd is in het aanbieden van technische expertise en begeleiding op het gebied van generatieve AI- en ML-oplossingen aan klanten. Zijn primaire focus is om Digital Native Businesses te helpen bij het realiseren van het volledige potentieel van generatieve AI- en ML-technologieën, waardoor ze hun zakelijke doelstellingen effectief kunnen bereiken. Naast zijn professionele inspanningen vertoont Abhi een sterke passie voor intellectuele bezigheden zoals lezen, en houdt hij zich bezig met activiteiten die het fysieke en mentale welzijn bevorderen, zoals yoga en meditatie.

Qing Lan is een Software Development Engineer bij AWS. Hij heeft aan verschillende uitdagende producten in Amazon gewerkt, waaronder hoogwaardige ML-inferentieoplossingen en een hoogwaardig logsysteem. Het team van Qing lanceerde met succes het eerste miljard-parametermodel in Amazon Advertising met een zeer lage latentie vereist. Qing heeft diepgaande kennis over de optimalisatie van de infrastructuur en de versnelling van Deep Learning.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/