Hvordan Amazon Search M5 sparede 30 % til LLM-uddannelsesomkostninger ved at bruge AWS Trainium | Amazon Web Services

I årtier har Amazon været banebrydende og fornyet maskinlæring (ML) og bragt dejlige oplevelser til sine kunder. Fra de tidligste dage har Amazon brugt ML til forskellige brugssager såsom boganbefalinger, søgning og afsløring af svindel. I lighed med resten af ​​industrien har fremskridtene inden for accelereret hardware gjort det muligt for Amazon-teams at forfølge modelarkitekturer ved hjælp af neurale netværk og deep learning (DL).

M5-programmet inden for Amazon Search ejer opdagelseslæringsstrategien for Amazon og bygger modeller i stor skala på tværs af flersprogede, multi-lokale, multi-entiteter, multitask og multimodale såsom tekst, billede og video. M5-programmet har tjent universelle indlejringer og storskala-fundamentmodeller til hundredvis af ML-teams på tværs af Amazon, mens de har bevaret streng kontrol over omkostningsoptimering. For at opnå dette evaluerer M5-teamet regelmæssigt nye teknikker for at reducere omkostningerne.

Som mange ML-organisationer bruges acceleratorer i vid udstrækning til at accelerere DL-træning og inferens. Da AWS lancerede specialbyggede acceleratorer med den første udgivelse af AWS-inferens i 2020 begyndte M5-teamet hurtigt at bruge dem til mere effektivt at implementere produktionsarbejdsbelastninger, hvilket sparer både omkostninger og reducerer latens. Sidste år lancerede AWS sin AWS Trainium acceleratorer, som optimerer ydeevnen pr. omkostning til udvikling og bygning af næste generations DL-modeller. I dette indlæg diskuterer vi, hvordan M5 var i stand til at reducere omkostningerne til at træne deres modeller med 30 %, og deler nogle af de bedste praksisser, vi lærte undervejs.

Trainium tilfælde

Med fremskridt inden for specialbyggede acceleratorer tilbyder Amazon også overbevisende acceleratorer i form af AWS Inferentia og Trainium. Som deres navne antyder, er disse chips optimeret til at overstige behovene for henholdsvis inferens og træningsarbejdsbelastninger. Til storstilet træning af fundamentmodeller, der når milliarder af parametre i størrelse, Trainium Trn1 og Trn1n forekomster er ideelle valg på grund af deres egenskaber. Trn1-forekomster er drevet af det nyeste NeuronCore-v2, og har en rigelig mængde acceleratorberegning og hukommelse. Trn1n-instanser kan også vælges til en større mængde netværksbåndbredde (1,600 Gbs), så de er velegnede til performant træning med omkostningsoptimering i tankerne.

For at bruge acceleratorer skal du bruge et softwarelag til at understøtte dem. Med Trn- og Inf-chips er AWS Neuron SDK låser op for Amazon specialbyggede acceleratorer ved hjælp af PyTorch XLA. PyTorch XLA konverterer PyTorchs ivrige tilstand til grafbaseret implementering i lazy mode. Disse grafer bruges derefter og kompileres yderligere til brug med acceleratoren. PyTorch Neuron (en del af Neuron SDK) gør det muligt for PyTorch-brugere at træne deres modeller på Trainium NeuronCores med nogle få linjer kode.

Model og arbejdsmængde

M5-teamet træner og implementerer grundlæggende modeller og universelle repræsentationer for at hjælpe forskellige teams på tværs af Amazon med at bringe glæde til Amazon.com kunder. En sådan model er en tekstkodermodel efterfulgt af en flerlagsperceptron (MLP) med eksplicitte eller implicitte egenskabsinteraktioner defineret af den neurale netværksarkitektur med hundredvis af millioner af parametre, der kan trænes. Denne model er trænet på milliarder af tokens og bruges til at generere millioner af indlejringer i en offline batch-inferensindstilling. Disse indlejringer er input til en kundevendt tier-1 Amazon-tjeneste.

Infrastrukturen til produktionsrørledningen bruger AWS batch med fair share-køstrategier, ved at bruge en EFA-aktiveret multi-node trn1.32xlarge cluster som beregning for modeltræning. Funktionelt udfører produktionspipelinen inkrementel modeltræning, evaluering af trænet model og offline batch-inferens på den trænede model, alt ved hjælp af PyTorch som det underliggende DL-bibliotek.

Mål

At glæde vores kunder er en af ​​de vigtigste grundsætninger. I betragtning af pipelinens kundevendte karakter er det afgørende, at alle serviceniveauaftaler (SLA'er) overholdes uden regression. Vi identificerede to kritiske acceptkriterier for at tilpasse vores eksisterende GPU-produktionspipeline og overføre den til Trainium:

• Model kvalitet – Kvaliteten af ​​vores modeller har direkte indflydelse på kundeoplevelsen. Vi kræver, at der skal være mindre end 0.1 % forskel i modelkvalitet mellem GPU og Trainium.
• Træningsgennemstrømning – Vi træner periodisk vores modeller iterativt for at give vores kunder den nyeste oplevelse. Vi kræver, at modelkonvergens skal opnås inden for en foruddefineret periode (såsom 1 uge) for at opfylde vores produktions-SLA'er.

I de følgende afsnit deler vi vores rejse med at arbejde baglæns fra dette kriterium, og vores erfaringer med at understøtte Amazon-skala produktionsarbejdsbelastninger.

Træningsmanuskript

Før vi starter med modeltræning, skal vi lave ændringer i træningsscriptet for at gøre det XLA-kompatibelt. I betragtning af modellens størrelse bruger vi distribueret data parallel (DDP) til at træne modellen. DDP giver os mulighed for at øge gennemstrømningen af ​​modeltræning ved at opskalere antallet af maskiner, der bruges til at køre modeltræning, uden nogen kodeændringer. Vi fulgte instruktionerne i Neuron PyTorch MLP træningsvejledning at tilføje XLA-specifikke konstruktioner i vores træningsscripts. Disse kodeændringer er ligetil at implementere. Følgende er nogle væsentlige tekniske erfaringer fra øvelsen, der i høj grad forbedrede vores modelgennemstrømning:

• Placering af xm.mark_step() - xm.mark_step() kompilerer og kører de dovent indsamlede beregningsgrafer. Påberåber sig mark_step for mange gange vil føre til et større antal små grafer, hvorimod at kalde det for få gange vil føre til få, men store grafer. Afhængig af din ansøgning vil gennemløbet og implementeringen af ​​din modeluddannelse variere baseret på din placering af xm.mark_step(). Vores implementering placerer en xm.mark_step() efter en fremadgående og baglæns pasning, og en efter optimeringstrinnet.
• Dataindlæserindpakning med XLA multiprocessing enhedsindlæser - Dette er et kritisk skridt, som nemt kan overses. Indlæseren af ​​multiprocessenhed torch_xla.distributed.parallel_loader.MpDeviceLoader indlæser træningsdata på hver XLA-enhed med muligheder for at forudindlæse og overlappe dataindlæsning med enhedskørsler for at forbedre gennemstrømningen. Enhedsindlæseren påberåber sig også xm.mark_step() og er derfor i stand til at bygge grafer til dataindlæsning til enhed fra vært.

Kompilering til Trainium

Traditionelt involverer modeludviklingscyklussen med GPU'er at foretage ændringer i modellen eller træningsscriptet og køre det direkte på GPU-enheden. Acceleratorer som Trainium, der bruger XLA, kræver et ekstra trin, før modeltræning kan køres på speederen. XLA-beregningsgrafer kan kun køres, efter at de er blevet kompileret. Generelt er der to måder at udføre denne kompilering på: Ahead of Time (AOT), hvor du sporer og kompilerer alle grafer først og derefter kører dem, eller Just In Time (JIT), hvor grafer spores, kompileres og køres som de er stødt på. Neuron SDK leverer begge disse ud af æsken. Typisk udføres AOT-kompilering først. Grafer køres derefter efter denne kompilering. Hvis der stødes på nye grafer, kalder Neuron runtime en JIT-kompilering, før de køres. For at udføre AOT-kompilering giver Neuron SDK neuron_parallel_compile, et kompileringsværktøj, der udtrækker grafer fra en prøvekørsel af træningsscriptet og udfører parallel AOT-kompilering.

Et vigtigt aspekt af AOT-kompilering er at sikre, at der ikke oprettes nye beregningsgrafer i løbet af træningen. En kilde til nye beregningsgrafer (og derfor genkompileringer) er dynamiske former for træningspartierne under modeltræning. Vi fandt ud af, at brug af statiske former og batches i fast størrelse eliminerer træningstidskompileringer og forbedrer træningsgennemstrømningen markant uden nogen indvirkning på modellens nøjagtighed. Ved at håndhæve sådanne begrænsninger på træning, observerede vi, at kun 4-5 trin af modeltræning, et trin i modelvalidering og kontrol af modellen én gang er påkrævet for at spore alle graferne under AOT-kompilering. Det er vigtigt at bemærke, at Neuron SDK konstant udvikler sig og i fremtiden også vil understøtte dynamiske former.

Desuden gemmes de kompilerede grafer i Neuron Persistent Cache på disk eller i en Amazon Simple Storage Service (Amazon S3) spand. Dette er især nyttigt for produktionsarbejdsbelastninger, hvor modelarkitektur og træningskonfiguration ikke ændres. Derfor afholdes overhead af kompilering kun én gang. Brug af cachen er så simpelt som at indstille et miljøflag:

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

Neuron-kompileren giver også tre optimeringsmuligheder på kompilatorniveau (O1, O2, O3) for at balancere kompileringstid og modelkørsel. O1 muliggør kerneoptimeringer på beregningsgrafen og minimerer kompileringstiden, O3 giver forbedret modelkørsel på bekostning af højere kompileringstid, og O2 (standardindstilling) er en balance mellem de to. Til vores brugssag brugte vi O1-optimeringen og observerede en reduktion på 86 % i kompileringstid uden ændring af modelnøjagtighedsmetrikker, mens vi observerede en reduktion på cirka 5-7 % i gennemløbet sammenlignet med standardoptimeringen (O2). Afhængigt af use casen kan du vælge forskellige niveauer af optimering.

For at opsummere brugte vi følgende flag til kompilering:

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

Checkpoint kompatibilitet

Når kompileringen er gennemført, kan vi fortsætte med at træne vores modeller på Trainium. Som tidligere nævnt træner vi trinvist vores modeller, hvilket betyder, at vi indlæser et tidligere trænet modelkontrolpunkt og fortsætter træningen med nye data. PyTorch og PyTorch XLA muliggør problemfri overgang mellem acceleratorer gennem kontrolpunkters interoperabilitet. At have fleksibiliteten til at flytte mellem GPU og Trainium gjorde det muligt for os problemfrit at indlæse den tidligere GPU-model og træne på Trainium-maskiner. Dette var afgørende for at sikre, at vi kan initialisere vores model med den bedst trænede model uden produktionsnedetid eller tab i modelnøjagtighed.

Fordi GPU-modellen blev gemt ved hjælp af standard PyTorch-modellagringsværktøjer, var vi i stand til at bruge PyTorch checkpoint loading-værktøjet til at indlæse GPU-modellen på Trainium-enheder.

For eksempel på GPU/CPU kan du gemme modellen med følgende kode:

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

Så indlæser du modellen tilbage på 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)

På samme måde kan du gemme modellen på Trainium med følgende kode:

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

Og indlæs modellen tilbage på GPU/CPU:

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

Faktisk, fordi vi bruger DDP til modeltræning, er modelbelastningen agnostisk for antallet af maskiner, der blev brugt til at træne det forrige kontrolpunkt. Dette giver os mulighed for horisontalt at skalere Trn1-flåden uden kodeændringer eller negative effekter på modeltræning. Disse PyTorch-baserede kontrolpunkter kan bruges direkte eller endda fakkel-scripts til tilfælde af slutninger på AWS Inferentia2 eller andre acceleratorer.

Driftsstabilitet

Det kan ikke understreges nok, at kørsel af arbejdsbelastninger i produktionen kræver, at flere SLA'er overholdes. For vores anvendelsestilfælde er det, bortset fra SLA'erne for modelkvalitet og træningsgennemstrømning, bydende nødvendigt, at produktionspipelinen er driftsstabil, hvilket betyder minimal nedetid og afbrydelser under modeltræning, evaluering og konklusioner.

Som med den eksisterende GPU-baserede pipeline tilføjede vi adskillige mekanismer for at gøre pipelinen driftsstabil. Før vi starter modeltræning, kører vi adskillige sanitetstests for at vurdere maskinernes sundhed. Disse tests omfatter generelt simple tensoroperationer for at verificere acceleratoranordningernes sundhed. Vi har observeret, at for distribueret træning er det vigtigt at køre test for også at verificere kollektiv kommunikation mellem instanser. Vi brugte NCCOM test suite fra Neuron SDK for at opnå dette ved at køre en række operationer såsom alt-saml, alt-reducer og reducer-spredning.

Selv efter at have fulgt de forslag, vi har nævnt, har vi observeret, at forbigående problemer er uundgåelige i enhver pipeline, uanset den underliggende accelerator. For at opbygge modstandsdygtighed i enhver træningspipeline anbefaler vi at indbygge genforsøgsmekanismer for at løse disse potentielle problemer. Vi bruger AWS Batch automatiserede genforsøg at prøve job igen, der støder på en forbigående fejl under modeltræning. Disse genstarter kan være dyre, hvis der opstår en fejl mod slutningen af ​​træningen. For at imødegå dette problem har vi tilpasset vores træningsscripts til at indlæse et tidligere trænet modelkontrolpunkt og fortsætte træningen fra det tidspunkt. Med denne funktionalitet er vi i stand til aggressivt at genstarte mislykkede træningsjob med minimal overhead.

Med disse robusthedsmekanismer på plads var vi i stand til at opnå 98.5 % succesrater for vores arbejdsbelastninger på Trn1, hvilket kan sammenlignes med vores eksisterende GPU-pipeline-succesrater.

Resultater

For at validere nøjagtigheden af ​​vores modeller initialiserede vi to modeller fra det samme GPU-kontrolpunkt og trænede den ene på Trainium og den anden på en sammenlignelig GPU. Begge modeller blev trænet med de samme træningshyperparametre. Datasættet, der bruges til beregning af metrik, er et holdout-datasæt, og vi evaluerer modellens nøjagtighed på dette datasæt for hvert N globale trin. X-aksen er det globale trin, og Y-aksen er modellens nøjagtighed. Vi observerede mindre end 0.1 % forskel i modelnøjagtigheden på hvert punkt i den følgende graf.

For at evaluere omkostningseffektiviteten af ​​modeltræningen foretrækker vi desuden at sammenligne vægurets tid det tager at nå modelkonvergens. Vi mener, at dette giver et mere praktisk overblik over omkostningsbesparelser sammenlignet med mål som pris pr. token, opnåede FLOPS/dollar og andre faktorer. I betragtning af træningstiden for trn1.32xl og sammenlignelig Amazon Elastic Compute Cloud (Amazon EC2) tilfælde har vi observeret, at Trainium tilbyder op til 30 % billigere omkostninger til modelkonvergens.

Konklusion

Der er mange faktorer at overveje, når du evaluerer forskellige acceleratorer til dine DL-arbejdsbelastninger. Nogle af de vigtigste er modelkvalitet, gennemløb, omkostninger og tilgængelighed. Det er altafgørende at sikre, at din models kvalitet og gennemløb ikke ofres baseret på den accelerator, du vælger.

Takket være vores partnerskab og samarbejde med Annapurna Neuron-teamet har Amazon Search M5-teamet været i stand til at spare op til 30 % i omkostninger ved at flytte til Trainium. Teamet er i stand til at bruge Trainium og opnå modelkvalitet og gennemløbsparitet med sammenlignelige acceleratorer på markedet. Checkpoint-interoperabilitet og minimale kodeændringer med understøttelse af XLA har givet M5 mulighed for at vælge mellem flere acceleratorer til deres arbejdsbelastning. Dette har gjort det muligt for M5-teamet at drage fordel af Trainiums store regnekraft og bygge acceleratoragnostiske løsninger for at glæde Amazon.com-kunder. Fra et operationelt synspunkt har Trainium vist sig i stand til at understøtte tier-1-tjenester på Amazon-skala. M5-teamet fortsætter med at flytte flere arbejdsmængder til Trainium for at levere de bedste modeller til Amazon til de laveste omkostninger.

Sammenfattende har M5-teamet været i stand til at udføre omkostningseffektiv ML-træning i produktionskvalitet ved at tilføje Trainium til flåden af ​​acceleratorer. Vi opfordrer dig til at tage et kig på Trainium og andre Neuron-enheder som AWS Inferentia for at høste fordelene ved specialbygget Amazon-silicium til ML-arbejdsbelastninger. Kom nemt i gang med en af ​​de mange tutorials med forskellige modeller, f.eks Llama 2, tilgængelig på Trainium.

Om forfatterne

Abhinandan Patni er senior softwareingeniør hos Amazon Search. Han fokuserer på at bygge systemer og værktøjer til skalerbar distribueret deep learning-træning og realtidsslutning.

James Park er Solutions Architect hos Amazon Web Services. Han arbejder sammen med Amazon.com om at designe, bygge og implementere teknologiløsninger på AWS og har en særlig interesse for kunstig intelligens og maskinlæring. I fritiden nyder han at opsøge nye kulturer, nye oplevelser og holde sig ajour med de nyeste teknologitrends. Du kan finde ham på LinkedIn.

Jerry Mannil er softwareingeniør hos Amazon Search. Han arbejder på at forbedre effektiviteten, robustheden og skalerbarheden af ​​den distribuerede træningsinfrastruktur.

Ken Su er softwareingeniør hos Amazon Search. Han arbejder på at forbedre træningseffektiviteten og skalerbar distribueret træningsworkflow. Uden for arbejdet kan han godt lide at vandre og tennis.

RJ er ingeniør hos Amazon. Han bygger og optimerer systemer til distribuerede systemer til træning og arbejder på at optimere adoptionssystemer for at reducere latens for ML Inference. Uden for arbejdet udforsker han brugen af ​​Generative AI til at bygge madopskrifter.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• Kilde: https://aws.amazon.com/blogs/machine-learning/how-amazon-search-m5-saved-30-for-llm-training-cost-by-using-aws-trainium/