Hoe Amazon Search M5 30% bespaarde op LLM-trainingskosten door AWS Trainium te gebruiken | Amazon-webservices

Amazon is al tientallen jaren een pionier op het gebied van machinaal leren (ML) en levert daarmee verrukkelijke ervaringen op voor zijn klanten. Vanaf het allereerste begin heeft Amazon ML gebruikt voor verschillende toepassingen, zoals boekaanbevelingen, zoeken en fraudedetectie. Net als in de rest van de industrie hebben Amazon-teams dankzij de vooruitgang op het gebied van versnelde hardware modelarchitecturen kunnen nastreven met behulp van neurale netwerken en deep learning (DL).

Het M5-programma binnen Amazon Search is eigenaar van de ontdekkingsleerstrategie voor Amazon en bouwt grootschalige modellen voor meertalig, multi-locaal, multi-entiteit, multitask en multimodaal, zoals tekst, afbeelding en video. Het M5-programma biedt universele inbedding en grootschalige basismodellen aan honderden ML-teams op Amazon, terwijl strikte controles op de kostenoptimalisatie worden gehandhaafd. Om dit te bereiken evalueert het M5-team regelmatig nieuwe technieken om de kosten te verlagen.

Net als veel ML-organisaties worden accelerators grotendeels gebruikt om DL-training en gevolgtrekking te versnellen. Toen AWS speciaal gebouwde accelerators lanceerde met de eerste release van AWS Inferentie in 2020 begon het M5-team dat snel Gebruik ze om productiewerklasten efficiënter in te zetten, waardoor zowel kosten worden bespaard als de latentie wordt verminderd. Vorig jaar lanceerde AWS zijn AWS Trainium versnellers, die de prestaties per prijs optimaliseren voor het ontwikkelen en bouwen van de volgende generatie DL-modellen. In dit bericht bespreken we hoe M5 de kosten voor het trainen van hun modellen met 30% kon verlagen, en delen we enkele van de best practices die we gaandeweg hebben geleerd.

Trainium-instanties

Met de vooruitgang op het gebied van speciaal gebouwde accelerators biedt Amazon ook overtuigende accelerators in de vorm van AWS Inferentia en Trainium. Zoals hun naam al aangeeft, zijn deze chips geoptimaliseerd om respectievelijk de behoeften van inferentie- en trainingswerklasten te overtreffen. Voor grootschalige training van funderingsmodellen die miljarden parameters in omvang bereiken, biedt Trainium Trn1- en Trn1n-instanties zijn ideale keuzes vanwege hun kenmerken. Trn1-instanties worden mogelijk gemaakt door de modernste technieken NeuronCore-v2, en beschikken over een ruime hoeveelheid acceleratorcomputers en geheugen. Trn1n-instances kunnen ook worden gekozen voor een grotere hoeveelheid netwerkbandbreedte (1,600 Gbs), en zijn dus bij uitstek geschikt voor performante training met kostenoptimalisatie in gedachten.

Om accelerators te gebruiken, heb je een softwarelaag nodig die deze ondersteunt. Met Trn- en Inf-chips kan de AWS Neuron-SDK ontgrendelt speciaal door Amazon gebouwde accelerators met behulp van PyTorch XLA. PyTorch XLA converteert de enthousiaste modus van PyTorch naar een luie modus, op grafieken gebaseerde implementatie. Deze grafieken worden vervolgens gebruikt en verder samengesteld voor gebruik met de versneller. Met PyTorch Neuron (onderdeel van de Neuron SDK) kunnen PyTorch-gebruikers hun modellen trainen op Trainium NeuronCores met een paar regels code.

Model en werklast

Het M5-team traint en implementeert fundamentele modellen en universele representaties om verschillende teams op Amazon te helpen bij het brengen van vreugde Amazon.com klanten. Eén zo'n model is een tekstencodermodel gevolgd door een meerlaags perceptron (MLP) met expliciete of impliciete functie-interacties gedefinieerd door de neurale netwerkarchitectuur met honderden miljoenen trainbare parameters. Dit model is getraind op miljarden tokens en wordt gebruikt om miljoenen insluitingen te genereren in een offline batch-inferentie-instelling. Deze inbedding is input voor een klantgerichte Amazon-dienst op niveau 1.

De infrastructuur voor de productiepijplijn maakt gebruik van AWS-batch Met Fair Share-wachtrijstrategieën, met behulp van een EFA-compatibel trn1.32xlarge cluster met meerdere knooppunten als rekenkracht voor modeltraining. Functioneel voert de productiepijplijn incrementele modeltraining, evaluatie van het getrainde model en offline batch-inferentie uit op het getrainde model, allemaal met behulp van PyTorch als de onderliggende DL-bibliotheek.

Doelen

Het verrassen van onze klanten is een van de belangrijkste uitgangspunten. Gezien het klantgerichte karakter van de pijplijn is het van cruciaal belang dat aan alle Service Level Agreements (SLA's) wordt voldaan zonder regressies. We hebben twee kritische acceptatiecriteria geïdentificeerd om onze bestaande GPU-productiepijplijn aan te passen en over te zetten naar Trainium:

• Model kwaliteit – De kwaliteit van onze modellen heeft een directe invloed op de klantervaring. We eisen dat er minder dan 0.1% verschil in modelkwaliteit mag zijn tussen GPU en Trainium.
• Trainingsdoorvoer – We trainen onze modellen periodiek iteratief om onze klanten de nieuwste ervaring te bieden. We vereisen dat modelconvergentie binnen een vooraf gedefinieerde periode (zoals één week) wordt bereikt om aan onze productie-SLA's te voldoen.

In de volgende paragrafen delen we onze reis om vanuit dit criterium terug te werken, en onze lessen ter ondersteuning van productieworkloads op Amazon-schaal.

Trainingsscript

Voordat we beginnen met modeltraining, moeten we wijzigingen aanbrengen in het trainingsscript om het XLA-compatibel te maken. Gezien de omvang van het model gebruiken we gedistribueerde data parallel (DDP) om het model te trainen. Met DDP kunnen we de doorvoer van modeltraining vergroten door het aantal machines dat wordt gebruikt om modeltraining uit te voeren, op te schalen, zonder enige codewijzigingen. We volgden de instructies in de Neuron PyTorch MLP-trainingshandleiding om XLA-specifieke constructies toe te voegen aan onze trainingsscripts. Deze codewijzigingen zijn eenvoudig te implementeren. Hier volgen enkele belangrijke technische lessen uit de oefening die de doorvoer van ons model aanzienlijk hebben verbeterd:

• Plaatsing van xm.mark_step() - xm.mark_step() compileert en voert de lui verzamelde berekeningsgrafieken uit. Aanroepen mark_step te vaak zal leiden tot een groter aantal kleine grafieken, terwijl het te weinig aanroepen ervan zal leiden tot weinig, maar grote grafieken. Afhankelijk van uw toepassing zal de doorvoer en implementatie van uw modeltraining variëren op basis van uw plaatsing van xm.mark_step(). Onze implementatie plaatst er één xm.mark_step() na een voorwaartse en achterwaartse pass, en één na de optimalisatiestap.
• Gegevenslader inpakken met XLA-lader voor multiprocessing-apparaten – Dit is een cruciale stap die gemakkelijk kan worden gemist. De multiprocessing-apparaatlader torch_xla.distributed.parallel_loader.MpDeviceLoader laadt trainingsgegevens op elk XLA-apparaat met opties om het laden van gegevens vooraf te laden en te overlappen met apparaatruns om de doorvoer te verbeteren. De apparaatlader wordt ook aangeroepen xm.mark_step() en kan daarom grafieken maken voor het laden van gegevens naar het apparaat vanaf de host.

Compilatie voor Trainium

Traditioneel omvat de modelontwikkelingscyclus met GPU's het aanbrengen van wijzigingen in het model of trainingsscript en het rechtstreeks uitvoeren ervan op het GPU-apparaat. Versnellers zoals Trainium die XLA gebruiken, vereisen een extra stap voordat modeltraining op de versneller kan worden uitgevoerd. XLA-berekeningsgrafieken kunnen alleen worden uitgevoerd nadat ze zijn gecompileerd. Over het algemeen zijn er twee manieren om deze compilatie uit te voeren: Ahead of Time (AOT), waarbij u eerst alle grafieken traceert en compileert en ze vervolgens uitvoert, of Just In Time (JIT), waarbij grafieken worden getraceerd, gecompileerd en uitgevoerd zoals ze zijn. worden aangetroffen. De Neuron SDK biedt beide kant-en-klaar. Meestal wordt eerst de AOT-compilatie uitgevoerd. Na deze compilatie worden vervolgens grafieken uitgevoerd. Als er nieuwe grafieken worden aangetroffen, roept de Neuron-runtime een JIT-compilatie aan voordat deze wordt uitgevoerd. Om AOT-compilatie uit te voeren, biedt de Neuron SDK neuron_parallel_compile, een compilatiehulpprogramma dat grafieken extraheert uit een proefuitvoering van het trainingsscript en een parallelle AOT-compilatie uitvoert.

Een belangrijk aspect van de AOT-compilatie is ervoor te zorgen dat er tijdens de training geen nieuwe berekeningsgrafieken worden gemaakt. Eén bron van nieuwe rekengrafieken (en dus hercompilaties) zijn de dynamische vormen van de trainingsbatches tijdens modeltraining. We ontdekten dat het gebruik van statische vormen en batches met een vaste grootte het compileren van trainingstijd elimineert en de trainingsdoorvoer aanzienlijk verbetert zonder enig effect op de nauwkeurigheid van het model. Door dergelijke beperkingen op te leggen aan de training, hebben we vastgesteld dat slechts 4 à 5 stappen van modeltraining, één stap van modelvalidatie en één keer controleren van het model nodig zijn om alle grafieken te traceren tijdens de AOT-compilatie. Het is belangrijk op te merken dat de Neuron SDK voortdurend evolueert en in de toekomst ook dynamische vormen zal ondersteunen.

Bovendien worden de samengestelde grafieken opgeslagen in de Neuron persistente cache op schijf of in een Amazon eenvoudige opslagservice (Amazon S3) bak. Dit is vooral handig voor productieworkloads waarbij de modelarchitectuur en trainingsconfiguratie niet veranderen. Daarom wordt de overhead van het compileren slechts één keer gemaakt. Het gebruik van de cache is net zo eenvoudig als het instellen van een omgevingsvlag:

export NEURON_COMPILE_CACHE_URL="s3://BUCKET/KEY"

De Neuron-compiler biedt er ook drie Optimalisatieopties op compilerniveau (O1, O2, O3) om de compilatietijd en de doorvoer van het model in evenwicht te brengen. O1 maakt kernoptimalisaties op de rekengrafiek mogelijk en minimaliseert de compilatietijd, O3 biedt een verbeterde doorvoer van het model ten koste van een hogere compilatietijd, en O2 (standaardoptie) is een balans tussen beide. Voor onze use case hebben we de O1-optimalisatie gebruikt en een vermindering van 86% in de compilatietijd waargenomen zonder verandering in de nauwkeurigheidsstatistieken van het model, terwijl we een vermindering van de doorvoer van ongeveer 5-7% hebben waargenomen vergeleken met de standaardoptimalisatie (O2). Afhankelijk van de gebruikssituatie kunt u verschillende optimalisatieniveaus kiezen.

Samenvattend hebben we de volgende vlaggen gebruikt voor compilatie:

NEURON_CC_FLAGS="--target trn1 --auto-cast all --auto-cast-type bf16 --model-type transformer --optlevel O1"

Compatibiliteit met checkpoints

Wanneer de compilatie succesvol is afgerond, kunnen we doorgaan met het trainen van onze modellen op Trainium. Zoals eerder vermeld, trainen we onze modellen stapsgewijs, wat betekent dat we een eerder getraind modelcontrolepunt laden en doorgaan met trainen met nieuwe gegevens. PyTorch en PyTorch XLA maken een naadloze overgang tussen versnellers mogelijk via checkpoint-interoperabiliteit. Dankzij de flexibiliteit om tussen GPU en Trainium te kunnen schakelen, konden we naadloos het vorige GPU-model laden en trainen op Trainium-machines. Dit was van cruciaal belang om ervoor te zorgen dat we ons model konden initialiseren met het beste, eerder getrainde model, zonder enige productieonderbreking of verlies aan modelnauwkeurigheid.

Omdat het GPU-model werd opgeslagen met behulp van standaard PyTorch-hulpprogramma's voor het opslaan van modellen, konden we het PyTorch-hulpprogramma voor het laden van controlepunten gebruiken om het GPU-model op Trainium-apparaten te laden.

Op GPU/CPU kunt u het model bijvoorbeeld opslaan met de volgende code:

torch.save(model.state_dict(), PATH)

Vervolgens laad je het model terug in Trainium:

import torch_xla.core.xla_model as xm
xla_device = xm.xla_device()
model = MyModel(*args, **kwargs)
model.load_state_dict(torch.load(PATH))
model.to(xla_device)

Op dezelfde manier kun je het model op Trainium opslaan met de volgende code:

import torch_xla.core.xla_model as xm
# automatically moves the data to CPU for the master device
xm.save(model.state_dict(), PATH) 

En laad het model terug op GPU/CPU:

model = MyModel(*args, **kwargs)
model.load_state_dict(torch.load(PATH))
model.to(device) # can be any device

Omdat we DDP gebruiken voor modeltraining, is het laden van modellen agnostisch ten opzichte van het aantal machines dat is gebruikt om het vorige controlepunt te trainen. Hierdoor kunnen we de Trn1-vloot horizontaal schalen zonder codewijzigingen of nadelige gevolgen voor de modeltraining. Deze op PyTorch gebaseerde controlepunten kunnen direct worden gebruikt of zelfs in een torch-script worden omgezet voor gebruiksscenario's voor gevolgtrekkingen op AWS Inferentia2 of andere versnellers.

Operationele stabiliteit

Het kan niet genoeg benadrukt worden dat het uitvoeren van werklasten in de productie vereist dat aan meerdere SLA's wordt voldaan. Voor ons gebruiksscenario is het, afgezien van de SLA's voor de modelkwaliteit en de trainingsdoorvoer, absoluut noodzakelijk dat de productiepijplijn operationeel stabiel is, wat betekent dat er minimale downtime en verstoringen zijn tijdens modeltraining, evaluatie en gevolgtrekking.

Net als bij de bestaande, op GPU gebaseerde pijplijn, hebben we talloze mechanismen toegevoegd om de pijplijn operationeel stabiel te maken. Voordat we met de modeltraining beginnen, voeren we meerdere gezondheidstests uit om de gezondheid van de machines te beoordelen. Deze tests omvatten doorgaans eenvoudige tensorbewerkingen om de gezondheid van de versnellers te verifiëren. We hebben gemerkt dat het voor gedistribueerde training belangrijk is om tests uit te voeren om ook de collectieve communicatie tussen instanties te verifiëren. Wij gebruikten de NCCOM-testsuite van de Neuron SDK om dit te bereiken, door een verscheidenheid aan bewerkingen uit te voeren, zoals all-gather, all-reduce en reduce-scatter.

Zelfs na het volgen van de suggesties die we hebben genoemd, hebben we geconstateerd dat tijdelijke problemen onvermijdelijk zijn in elke pijplijn, ongeacht de onderliggende versneller. Om veerkracht in elke trainingspijplijn op te bouwen, raden we aan mechanismen voor opnieuw proberen in te bouwen om deze potentiële problemen op te lossen. We gebruiken AWS Batch geautomatiseerde nieuwe pogingen om taken opnieuw uit te voeren waarbij tijdens de modeltraining een tijdelijke fout optreedt. Deze herstart kan kostbaar zijn als er tegen het einde van de training een fout optreedt. Om dit probleem tegen te gaan, hebben we onze trainingsscripts aangepast om een ​​eerder getraind modelcontrolepunt te laden en vanaf dat punt door te gaan met trainen. Met deze functionaliteit zijn we in staat om mislukte trainingstaken agressief opnieuw te starten met minimale overhead.

Met deze veerkrachtmechanismen konden we een succespercentage van 98.5% behalen voor onze workloads op Trn1, vergelijkbaar met het succespercentage van onze bestaande GPU-pijplijn.

Resultaten

Om de nauwkeurigheid van onze modellen te valideren, hebben we twee modellen van hetzelfde GPU-controlepunt geïnitialiseerd en één op Trainium en de andere op een vergelijkbare GPU getraind. Beide modellen werden getraind met dezelfde trainingshyperparameters. De dataset die wordt gebruikt voor de berekening van metrieken is een holdout-dataset en we evalueren de nauwkeurigheid van het model op deze dataset elke N globale stappen. De X-as is de globale stap en de Y-as is de nauwkeurigheid van het model. We hebben op elk punt in de volgende grafiek minder dan 0.1% verschil in de modelnauwkeurigheid waargenomen.

Om de kosteneffectiviteit van de modeltraining te evalueren, vergelijken we bovendien liever de wandkloktijd die nodig is om modelconvergentie te bereiken. Wij zijn van mening dat dit een praktischer beeld geeft van de kostenbesparingen in vergelijking met maatregelen zoals de kosten per token, behaalde FLOPS/dollar en andere factoren. Gezien de trainingstijd van trn1.32xl en vergelijkbaar Amazon Elastic Compute-cloud (Amazon EC2) hebben we vastgesteld dat Trainium tot 30% goedkopere kosten biedt voor het modelleren van convergentie.

Conclusie

Er zijn veel factoren waarmee u rekening moet houden bij het evalueren van verschillende accelerators voor uw DL-workloads. Enkele van de belangrijkste zijn modelkwaliteit, doorvoer, kosten en beschikbaarheid. Het is van het grootste belang ervoor te zorgen dat de kwaliteit en doorvoer van uw model niet worden opgeofferd op basis van de versneller die u kiest.

Dankzij onze samenwerking met het Annapurna Neuron-team heeft het Amazon Search M5-team tot 30% aan kosten kunnen besparen door naar Trainium te verhuizen. Het team kan Trainium gebruiken en modelkwaliteit en doorvoerpariteit bereiken met vergelijkbare versnellers op de markt. Checkpoint-interoperabiliteit en minimale codewijzigingen met ondersteuning voor XLA hebben ervoor gezorgd dat M5 kon kiezen tussen meerdere accelerators voor hun werklasten. Hierdoor heeft het M5-team kunnen profiteren van de grote rekenkracht van Trainium en accelerator-onafhankelijke oplossingen kunnen bouwen om Amazon.com-klanten tevreden te stellen. Vanuit operationeel oogpunt is Trainium in staat gebleken Tier-1-diensten op Amazon-schaal te ondersteunen. Het M5-team blijft meer werklasten naar Trainium verplaatsen om Amazon de beste modellen te bieden tegen de laagste kosten.

Samenvattend kan worden gezegd dat het M5-team kosteneffectieve ML-trainingen op productieniveau heeft kunnen uitvoeren door Trainium toe te voegen aan de vloot van versnellers. We moedigen u aan om Trainium en andere Neuron-apparaten zoals AWS Inferentia te bekijken om de voordelen te plukken van speciaal gebouwd Amazon-silicium voor ML-workloads. Ga eenvoudig aan de slag met een van de vele tutorials met verschillende modellen, zoals Lama 2, beschikbaar op Trainium.

Over de auteurs

Abhinanda Patni is Senior Software Engineer bij Amazon Search. Hij richt zich op het bouwen van systemen en tooling voor schaalbare gedistribueerde deep learning-training en realtime inferentie.

James Park is oplossingsarchitect bij Amazon Web Services. Hij werkt samen met Amazon.com om technologische oplossingen op AWS te ontwerpen, bouwen en implementeren, en heeft een bijzondere interesse in AI en machine learning. In zijn vrije tijd gaat hij graag op zoek naar nieuwe culturen, nieuwe ervaringen en blijft hij op de hoogte van de nieuwste technologische trends. Je kunt hem vinden op LinkedIn.

Jerry Mannil is een software-ingenieur bij Amazon Search. Hij werkt aan het verbeteren van de efficiëntie, robuustheid en schaalbaarheid van de gedistribueerde trainingsinfrastructuur.

Ken Su is een software-ingenieur bij Amazon Search. Hij werkt aan het verbeteren van de trainingsefficiëntie en de schaalbare gedistribueerde trainingsworkflow. Buiten het werk houdt hij van wandelen en tennis.

RJ is een ingenieur bij Amazon. Hij bouwt en optimaliseert systemen voor gedistribueerde systemen voor training en werkt aan het optimaliseren van de adoptie van systemen om de latentie voor ML Inference te verminderen. Buiten zijn werk onderzoekt hij het gebruik van generatieve AI voor het maken van voedselrecepten.

• 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/how-amazon-search-m5-saved-30-for-llm-training-cost-by-using-aws-trainium/