Aktiver raskere trening med Amazon SageMaker data parallellbibliotek | Amazon Web Services

Opplæring i store språkmodeller (LLM) har blitt stadig mer populært det siste året med lanseringen av flere offentlig tilgjengelige modeller som Llama2, Falcon og StarCoder. Kunder trener nå LLM-er av enestående størrelse fra 1 milliard til over 175 milliarder parametere. Trening av disse LLM-ene krever betydelige dataressurser og tid ettersom hundrevis til tusenvis av grafikkbehandlingsenheter (GPUer) må brukes for å håndtere dagens enorme opplæringsdatasett og modellstørrelser. En flaskehals i distribuert opplæring kan være GPU-kommunikasjon som håndteres av NVIDIA Collective Communication Library (NCCL). I noen stordistribuerte opplæringsjobber kan det brukes mer tid på kommunikasjon mellom GPU enn faktisk GPU-beregning. For å lindre flaskehalsen for GPU-kommunikasjon og muliggjøre raskere trening, Amazon SageMaker er glade for å kunngjøre en optimalisert AllGather-kollektiv operasjon som en del av SageMaker distributed data parallel library (SMDDP). AllGather er den mest brukte kollektive operasjonen i populære minneeffektive dataparallelliseringsløsninger som DeepSpeed ​​Zero Redundancy Optimizer (ZeRO) og Fullt delt dataparallelisme (FSDP), og det er den viktigste bidragsyteren til GPU-kommunikasjon overhead. I dette innlegget viser vi en oversikt på høyt nivå over hvordan SMDDP fungerer, hvordan du kan aktivere SMDDP i dine Amazon SageMaker-treningsskript, og ytelsesforbedringene du kan forvente.

Løsningsoversikt

Tradisjonell data parallell trening involverer replikering av en hel modell på tvers av flere GPUer, med hver modell som trener på forskjellige skjær av data fra datasettet. Under bakoverpasseringen beregnes et gjennomsnitt av gradienter blant GPU-arbeidere slik at hver modellreplika oppdateres med de samme gradientverdiene til tross for at de er trent med forskjellige datashards. Denne teknikken tillater mye raskere trening på enorme datasett ved å parallellisere forbruket av treningsdata. Noen av dagens store modeller (f.eks. Llama2 70B) er imidlertid altfor store til å passe helt inn i GPU-minnet, noe som gjør tradisjonell dataparallellisme ubrukelig. For å fortsette å høste fordelene av dataparallellisme samtidig som man overvinner begrenset GPU-minne, parallelle løsninger som DeepSpeed ​​ZeRO, PyTorch FSDP og Amazon SageMaker modell parallellisme bibliotek har vokst i popularitet.

I sønderdelt dataparallellisme, i stedet for å replikere hele modellen på GPU-arbeidere, blir modellparametrene, gradientene og optimaliseringstilstandene brutt opp og fordelt (dvs. sønderdelt) på tvers av GPUer i treningsjobben. For å utføre forover- og bakovergangsberegning, samles parametere fra shards på andre GPU-arbeidere for å danne ett eller flere modelllag. Etter at beregningen er utført, frigjøres disse lagene fra minnet for å tillate at neste sett med lag kan samles. Legg merke til at det finnes varianter av delt dataparallellisme der bare optimaliseringstilstandene og gradientene er delt, men ikke modellparametrene. AllGather brukes fortsatt i denne typen sharded data-parallellisme, men bare før forward pass-beregning for å samle modellparametere som har blitt oppdatert av forskjellige gradient- eller optimeringstilstandsshards fra andre GPU-arbeidere. Se de forskjellige DeepSpeed ​​ZeRO-etapper og SHARD_GRAD_OP FSDP-skjæringsstrategi for flere detaljer.

En AllGather-kollektiv operasjon utføres hver gang parametere fjernes – NCCL gir standard åpen kildekodeimplementering av denne rutinen. Som vist i det følgende, starter hver GPU-arbeider som er involvert i AllGather med en inngangsbuffer og ender opp med alle inngangsbufferne fra andre arbeidere sammenkoblet. Når AllGather brukes i fragmentert dataparallellisme, inneholder inngangsbufferne modellparameterskjærene og de store utgangsbufferne inneholder ett eller flere modelllag materialisert fra de andre shards.

Selv om NCCL vanligvis brukes for AllGather i distribuert trening, er dens underliggende lavnivåimplementering ikke skreddersydd for nettverksinfrastrukturen til Amazon Elastic Compute Cloud (Amazon EC2)-forekomster, og dermed kan ytelsen bremse ende-til-ende-trening. SMDDP-biblioteket er et kollektivt kommunikasjonsbibliotek for NVIDIA GPUer som fungerer som en drop-in-erstatning for NCCL og gir bedre ytelse for distribuerte treningsjobber med PyTorch. Spesielt gir SMDDP en optimalisert implementering av AllGather for p4d/p4de-forekomsttyper.

Siden kollektive operasjoner som AllGather blokkerer forover- og bakovergangsberegninger, vil raskere utførelse av disse operasjonene direkte oversettes til kortere ende-til-ende-treningstid uten bivirkninger på konvergens. Andre kollektive operasjoner som brukes sjeldnere i parallelltrening med sønderdelt data, håndteres ved å falle tilbake til NCCL.

walkthrough

AWS-optimalisert AllGather

AWS-optimalisert AllGather bruker følgende teknikker for å oppnå bedre ytelse på AWS-infrastruktur sammenlignet med NCCL:

1. Vi flytter data mellom instanser via Elastisk stoffadapter (EFA) nettverk med et alt-til-alle-kommunikasjonsmønster. EFA er AWS sin nettverksløsning med lav latens og høy gjennomstrømning, og et alt-til-alt-mønster for inter-node nettverkskommunikasjon er mer skreddersydd for egenskapene til EFA og AWS sin nettverksinfrastruktur ved å kreve færre pakkehopp sammenlignet med NCCLs ring eller tre kommunikasjonsmønster.
2. GDRCopy å koordinere lokal NVLink og EFA nettverkstrafikk. GDRCopy er et bibliotek som gir kommunikasjon med lav latens mellom CPU-prosesser og GPU CUDA-kjerner. Med denne teknologien er vi i stand til å pipelinere databevegelsen mellom noder og noder.
3. Redusert bruk av GPU-streaming multiprosessorer for å gi tilbake mer datakraft til modellering av kjerner. AWS P4d/P4de-forekomster er utstyrt med NVIDIA A100 GPUer som hver har 108 streaming multiprosessorer. Mens NCCL bruker opptil 24 streaming multiprosessorer for å utføre kollektiver, bruker SMDDP Collectives bare opptil ni streaming multiprosessorer. De lagrede streaming-multiprosessorene kan plukkes opp av modellberegningskjerner for raskere utførelse.

bruk

SMDDP-kollektiver integreres naturlig med PyTorch gjennom prosessgruppe abstraksjon i torch.distributed modul. En prosessgruppe definerer grensesnittene for vanlige kollektive operasjoner som AllGather, ReduceScatter, AllReduce osv. Brukere kan skrive generisk distribuert kode og deretter velge den underliggende backend, som gir implementeringen for disse operasjonene basert på dataenheten som brukes. CPU-treningsjobber bruker ofte gloo or mpi backend mens NVIDIA GPUer bruker nccl baksiden.

SMDDP-biblioteket kommer inn i bildet ved å registrere seg selv som en tilpasset backend i prosessgruppeabstraksjonen. Dette gjøres av importsetningen, som vises i følgende kodebiter. Deretter, når du velger backend for din GPU-baserte distribuerte treningsjobb, er det bare å bytte ut nccl med smddp. De smddp backend følger samme semantikk som nccl backend og støtter de samme treningsscenarioene.

DeepSpeed

import smdistributed.dataparallel.torch.torch_smddp
deepspeed.init_distributed(dist_backend="smddp") # replacing "nccl"

FSDP

import smdistributed.dataparallel.torch.torch_smddp
dist.init_process_group(backend="smddp")  # replacing "nccl"

benchmarks

Vi benchmerket frittstående AllGather-ytelse der den kollektive operasjonen kjøres isolert uten modelltrening. Nedenfor er et eksempelresultat på 32 p4d-forekomster som sammenligner NCCL og SMDDP AllGather. X-aksen representerer utdatastørrelsen til AllGather, og Y-aksen representerer nettverksutnyttelseshastigheten til p4ds 400 Gbps EFA-nettverk. De 4 undergrafene representerer de vanlige kommunikasjonsgruppemønstrene der vi har henholdsvis 1, 2, 4 og 8 rangeringer per p4d-instans som deltar i AllGather-operasjonen.

Disse mikrobenchmarkene viser at SMDDP overgår NCCL med to nøkkelegenskaper:

1. Toppytelsen til SMDDP (omtrent 90 % båndbreddeutnyttelse) er høyere enn for NCCL (omtrent 80 % båndbreddeutnyttelse) i alle konfigurasjoner.
2. SMDDP når toppytelsen ved mye mindre bufferstørrelser enn NCCL. Dette forbedrer spesielt treningshastighetene for mindre modeller eller når brukeren angir en liten AllGather-bufferstørrelse i DeepSpeed ​​(der AllGather-størrelsen ikke trenger å være lik lagstørrelsen).

Modelltreningsbenchmarks

I storskala treningsjobber der GPU-kommunikasjon er en betydelig flaskehals, kan SMDDP forbedre treningshastighetene markant, målt med modell TFLOPS/GPU.

Konfigurasjon			Ytelse
Modell/Opplæring	Cluster	Løsning for delt dataparallellisme	Modell TFLOPS/GPU med NCCL	Modell TFLOPS/GPU med SMDDP	% fort deg
13B Lama2 Sekvens lengde: 4096 Global batchstørrelse: 4M tokens	64 p4d.24xlarge noder (512 NVIDIA A100 GPUer)	PyTorch FSDP	97.89	121.85	24.40%
65B GPT-NeoX Sekvens lengde: 2048 Global batchstørrelse: 4M tokens	64 p4d.24xlarge noder (512 NVIDIA A100 GPUer)	DeepSpeed ​​ZeRO trinn 3*	99.23	108.66	9.50%

*EleutherAIs Megatron-DeepSpeed depot ble brukt. Tensorparallellisme ble også aktivert med en tensor-parallell grad på åtte.

Merk: Modell TFLOPS/GPU er basert på modell FLOPS-utnyttelsesberegningen definert i papiret her. og benchmark-tall andre steder kan sitere maskinvare TFLOPS/GPU som ytelsesmåling. Maskinvare TFLOPS/GPU kan tilnærmes som 4/3 x modell TFLOPS/GPU.

konklusjonen

I dette innlegget viste vi deg hvordan du kan øke hastigheten på parallelle treningsjobber med shard data på Amazon SageMaker med bare to linjer med kodeendring. Storskala distribuert opplæring blir stadig mer allestedsnærværende med fremveksten eller LLMs, men med denne skalaen kommer høye kostnader. Ved å redusere kommunikasjonsflaskehalsen mellom GPUer, hjelper SMDDP deg med å trene raskere i skala og spare på dataressurser. Du kan finne flere SMDDP-eksempler med parallellopplæring i sønderdelt data i Amazon SageMaker-eksempler GitHub-depot.

---

Om forfatterne

Apoorv Gupta er en programvareutviklingsingeniør ved AWS, med fokus på å bygge optimale dyplæringssystemer for AWS-infrastruktur og maskinvare. Han er interessert i distribuert databehandling, dyplæringssystemer og ML-akseleratorer. Utenom jobben liker Apoorv å reise, gå fotturer og videospill.

Karan Dhiman er programvareutviklingsingeniør ved AWS, basert i Toronto, Canada. Han er veldig lidenskapelig opptatt av maskinlæringsområdet og å bygge løsninger for å akselerere distribuerte, beregnede arbeidsbelastninger.

Ruhan Prasad er en programvareutviklingsingeniør hos AWS som jobber med å gjøre distribuert dyplæringstrening raskere, billigere og enklere å bruke på SageMaker. Utenom jobben liker Ruhan å spille tennis, reise og lage mat.

Zhaoqi Zhu er en Senior Software Development Engineer hos AWS, lidenskapelig opptatt av distribuerte systemer og lavnivåoptimaliseringer. Han liker å se fotballkamper mens han drikker (ikke-diett) brus.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/enable-faster-training-with-amazon-sagemaker-data-parallel-library/