Forbedre prisytelsen til modelltreningen din ved å bruke Amazon SageMaker heterogene klynger

Dette innlegget er skrevet sammen med Chaim Rand fra Mobileye.

Visse arbeidsbelastninger for maskinlæring (ML), for eksempel trening av datasynsmodeller eller forsterkende læring, involverer ofte å kombinere den GPU- eller akseleratorintensive oppgaven med opplæring i nevrale nettverksmodeller med den CPU-intensive oppgaven med dataforbehandling, som bildeforstørrelse. Når begge typer oppgaver kjører på samme forekomsttype, får dataforbehandlingen flaskehals på CPU, noe som fører til lavere GPU-utnyttelse. Dette problemet blir verre med tiden ettersom gjennomstrømmingen til nyere generasjoner GPU-er vokser i et brattere tempo enn CPU-er.

For å løse dette problemet, i juli 2022, vi lansert heterogene klynger for Amazon SageMaker modellopplæring, som lar deg starte opplæringsjobber som bruker forskjellige instanstyper i en enkelt jobb. Dette gjør det mulig å avlaste deler av dataforbehandlingsrørledningen til dataoptimalisert forekomsttyper, mens DNN-oppgaven (Deep Neural Network) fortsetter å kjøre GPU eller akselerert databehandling instanstyper. Våre benchmarks viser opptil 46 % prisytelsesfordel etter å ha aktivert heterogene klynger i en CPU-bundet TensorFlow datasynsmodellopplæring.

For et lignende brukstilfelle, mobileye, et utviklingsselskap for autonome kjøretøyteknologier, hadde dette å dele:

"Ved å flytte CPU-bundet dyplæringsmodelltrening for datasyn til å kjøre over flere instanstyper (CPU- og GPU/ML-akseleratorer), ved å bruke en tf.data.service basert løsning vi har bygget, klarte vi å redusere treningstiden med 40 %, samtidig som kostnadene for å trene ble redusert med 30 %. Vi er glade for heterogene klynger som lar oss kjøre denne løsningen på Amazon SageMaker.»

— AI Engineering, Mobileye

I dette innlegget diskuterer vi følgende emner:

• Hvordan heterogene klynger hjelper til med å fjerne CPU-flaskehalser
• Når du skal bruke heterogene klynger og andre alternativer
• Referanseimplementeringer i PyTorch og TensorFlow
• Resultatreferanseresultater
• Heterogene klynger ved Mobileye

AWS akselerert databehandlingsforekomst familien inkluderer akseleratorer fra egendefinerte AWS-brikker (AWS slutning, AWS Trainium), NVIDIA (GPU), Og Gaudi akseleratorer fra Habana Labs (et Intel-selskap). Merk at i dette innlegget bruker vi begrepene GPU og akselerator om hverandre.

Hvordan heterogene klynger fjerner flaskehalser i databehandling

Dataforskere som trener dyplæringsmodeller har som mål å maksimere treningskostnadseffektiviteten og minimere treningstiden. For å oppnå dette er et grunnleggende optimaliseringsmål å ha høy GPU-utnyttelse, den dyreste og mest knappe ressursen innen Amazon Elastic Compute Cloud (Amazon EC2) forekomst. Dette kan være mer utfordrende med ML-arbeidsbelastninger som kombinerer den klassiske GPU-intensive nevrale nettverksmodellens forover- og bakoverforplantning med CPU-intensive oppgaver, for eksempel databehandling og utvidelse i datasyn eller å kjøre en miljøsimulering i forsterkningslæring. Disse arbeidsbelastningene kan ende opp med å være CPU-bundet, der å ha mer CPU vil resultere i høyere gjennomstrømning og raskere og billigere trening ettersom eksisterende akseleratorer er delvis inaktive. I noen tilfeller kan CPU-flaskehalser løses ved å bytte til en annen forekomsttype med høyere CPU:GPU-forhold. Det er imidlertid situasjoner der det ikke er mulig å bytte til en annen forekomsttype på grunn av forekomstfamiliens arkitektur-, lagrings- eller nettverksavhengigheter.

I slike situasjoner må du øke mengden CPU-kraft ved å blande instanstyper: instanser med GPUer sammen med CPU. Oppsummert resulterer dette i et generelt høyere CPU:GPU-forhold. Inntil nylig var SageMaker opplæringsjobber begrenset til å ha forekomster av en enkelt valgt forekomsttype. Med SageMaker heterogene klynger kan dataforskere enkelt kjøre en treningsjobb med flere forekomsttyper, noe som gjør det mulig å overføre noen av de eksisterende CPU-oppgavene fra GPU-forekomstene til dedikerte dataoptimaliserte CPU-forekomster, noe som resulterer i høyere GPU-utnyttelse og raskere og mer kostnads- effektiv trening. Med den ekstra CPU-kraften kan du dessuten få forhåndsbehandlingsoppgaver som tradisjonelt ble utført offline som et foreløpig trinn for å bli en del av treningsjobben din. Dette gjør det raskere å iterere og eksperimentere over både dataforbehandling og DNN-treningsantakelser og hyperparametre.

Vurder for eksempel en kraftig GPU-forekomsttype, ml.p4d.24xlarge (96 vCPU, 8 x NVIDIA A100 GPUer), med et CPU:GPU-forhold på 12:1. La oss anta at treningsjobben din trenger 20 vCPUer for å forhåndsbehandle nok data til å holde én GPU 100 % utnyttet. Derfor, for å beholde alle 8 GPUer 100 % utnyttet, trenger du en 160 vCPU-forekomsttype. Imidlertid mangler ml.p4d.24xlarge 64 vCPUer, eller 40 %, noe som begrenser GPU-utnyttelsen til 60 %, som vist til venstre i følgende diagram. Vil det hjelpe å legge til en annen ml.p4d.24xlarge-instans? Nei, fordi jobbens CPU:GPU-forhold forblir det samme.

Med heterogene klynger kan vi legge til to ml.c5.18xlarge (72 vCPU), som vist til høyre i diagrammet. Netto total vCPU i denne klyngen er 210 (96+2*72), noe som fører til et CPU:GPU-forhold på 30:1. Hver av disse dataoptimaliserte forekomstene vil bli lastet av med en dataforbehandling CPU-intensiv oppgave, og vil tillate effektiv GPU-utnyttelse. Til tross for ekstrakostnadene til ml.c5.18xlarge, tillater den høyere GPU-utnyttelsen raskere prosessering, og derfor høyere prisytelsesfordeler.

Når du skal bruke heterogene klynger og andre alternativer

I denne delen forklarer vi hvordan du identifiserer en CPU-flaskehals, og diskuterer hvordan vi løser den ved å bruke oppskalering av forekomsttype vs. heterogene klynger.

Den raske måten å identifisere en CPU-flaskehals på er å overvåke CPU og GPU utnyttelsesberegninger for SageMaker treningsjobber i Amazon CloudWatch. Du kan få tilgang til disse visningene fra AWS-administrasjonskonsoll i treningsjobbsidens hyperkobling for forekomstberegninger. Velg de relevante beregningene og bytt fra 5-minutters til 1-minutters oppløsning. Merk at skalaen er 100 % per vCPU eller GPU, så utnyttelsesgraden for en forekomst med 4 vCPUer/GPUer kan være så høy som 400 %. Følgende figur er et slikt eksempel fra CloudWatch-målinger, der CPU er omtrent 100 % brukt, noe som indikerer en CPU-flaskehals, mens GPU er underutnyttet.

For detaljert diagnose, kjør treningsjobbene med Amazon SageMaker Debugger for å profilere ressursutnyttelsesstatus, statistikk og rammeverksoperasjoner, ved å legge til en profileringskonfigurasjon når du konstruerer en SageMaker-estimator ved å bruke SageMaker Python SDK. Etter at du har sendt inn opplæringsjobben, se gjennom resultatet profileringsrapport for CPU-flaskehalser.

Hvis du konkluderer med at jobben din kan ha nytte av et høyere CPU:GPU-beregningsforhold, bør du først vurdere å skalere opp til en annen forekomsttype i samme forekomstfamilie, hvis en er tilgjengelig. Hvis du for eksempel trener modellen din på ml.g5.8xlarge (32 vCPUer, 1 GPU), bør du vurdere å skalere opp til ml.g5.16xlarge (64 vCPUer, 1 GPU). Eller, hvis du trener modellen din ved å bruke multi-GPU-instanser ml.g5.12xlarge (48 vCPUer, 4 GPUer), vurder å skalere opp til ml.g5.24xlarge (96 vCPUer, 4 GPUer). Referere til G5 forekomstfamiliespesifikasjon for flere detaljer.

Noen ganger er oppskalering ikke et alternativ, fordi det ikke finnes noen forekomsttype med høyere vCPU:GPU-forhold i samme forekomstfamilie. Hvis du for eksempel trener modellen på ml.trn1.32xlarge, ml.p4d.24xlarge eller ml.g5.48xlarge, bør du vurdere heterogene klynger for SageMaker modelltrening.

I tillegg til å skalere opp, vil vi merke at det er flere alternativer til en heterogen klynge, som NVIDIA DALI, som laster av bildeforbehandling til GPUen. For mer informasjon, se Overvinne flaskehalser ved dataforbehandling med TensorFlow Data Service, NVIDIA DALI og andre metoder.

For å forenkle beslutningstaking, se følgende flytskjema.

Hvordan bruke SageMaker heterogene klynger

For å komme raskt i gang kan du hoppe direkte til TensorFlow- eller PyTorch-eksemplene gitt som en del av dette innlegget.

I denne delen leder vi deg gjennom hvordan du bruker en SageMaker heterogen klynge med et enkelt eksempel. Vi antar at du allerede vet hvordan du trener en modell med SageMaker Python SDK og Estimator-klassen. Hvis ikke, se Bruker SageMaker Python SDK før du fortsetter.

Før denne funksjonen initialiserte du treningsjobbens Estimator-klasse med InstanceCount og InstanceType-parametere, som implisitt antar at du bare har en enkelt forekomsttype (en homogen klynge). Med utgivelsen av heterogene klynger introduserte vi det nye sagemaker.instance_group.InstanceGroup klasse. Dette representerer en gruppe av én eller flere forekomster av en bestemt forekomsttype, designet for å ha en logisk rolle (som databehandling eller nevrale nettverksoptimalisering. Du kan ha to eller flere grupper, og spesifisere et tilpasset navn for hver forekomstgruppe, forekomsten type og antall forekomster for hver forekomstgruppe. For mer informasjon, se Bruker SageMaker Python SDK og Bruke SageMaker API-er på lavt nivå.

Etter at du har definert forekomstgruppene, må du endre treningsskriptet ditt for å lese SageMaker informasjon om treningsmiljø som inkluderer heterogen klyngekonfigurasjon. Konfigurasjonen inneholder informasjon som gjeldende forekomstgrupper, gjeldende verter i hver gruppe, og i hvilken gruppe den nåværende verten befinner seg med sin rangering. Du kan bygge logikk i treningsskriptet ditt for å tilordne forekomstgruppene til visse opplærings- og databehandlingsoppgaver. I tillegg må treningsskriptet ditt ta seg av gruppekommunikasjon mellom instanser eller distribuerte datainnlastingsmekanismer (f.eks. tf.data.service i TensorFlow eller generisk gRPC klient-server) eller et annet rammeverk (f.eks. Apache Spark).

La oss gå gjennom et enkelt eksempel på lansering av en heterogen treningsjobb og lesing av miljøkonfigurasjonen under kjøring.

1. Når vi definerer og starter opplæringsjobben, konfigurerer vi to forekomstgrupper som brukes som argumenter til SageMaker-estimatoren:

   from sagemaker.instance_group import InstanceGroup
   data_group = InstanceGroup("data_group", "ml.c5.18xlarge", 2)
   dnn_group = InstanceGroup("dnn_group", "ml.p4d.24xlarge", 1)
   
   from sagemaker.pytorch import PyTorch
   estimator = PyTorch(...,
       entry_point='launcher.py',
       instance_groups=[data_group, dnn_group]
   )

2. På opplæringsskriptet for inngangspunktet (navngitt launcher.py), leser vi den heterogene klyngekonfigurasjonen for å se om forekomsten vil kjøre forhåndsbehandlingen eller DNN-koden:

   from sagemaker_training import environment
   env = environment.Environment()
   if env.current_instance_group == 'data_group': ...;

La oss med dette oppsummere oppgavene SageMaker gjør på dine vegne, og oppgavene du er ansvarlig for.

SageMaker utfører følgende oppgaver:

1. Angi forskjellige forekomsttyper i henhold til forekomstgruppedefinisjonen.
2. Tilveiebringe inngangskanaler på alle eller spesifikke forekomstgrupper.
3. Distribuer opplæringsskript og avhengigheter til forekomster.
4. Sett opp en MPI-klynge på en spesifikk forekomstgruppe, hvis definert.

Du har ansvar for følgende oppgaver:

1. Endre startopplæringsjobbskriptet for å spesifisere forekomstgrupper.
2. Implementer en distribuert datapipeline (f.eks. tf.data.service).
3. Endre inngangspunktskriptet (se launcher.py i eksempelnotisboken) for å være et enkelt inngangspunkt som vil kjøre på alle forekomstene, oppdage hvilken forekomstgruppe den kjører i, og utløse den relevante atferden (som databehandling eller DNN-optimalisering).
4. Når treningssløyfen er over, må du sørge for at inngangspunktprosessen avsluttes på alle forekomster på tvers av alle forekomstgrupper. Dette er viktig fordi SageMaker venter på at alle forekomstene er ferdige med behandlingen før den markerer jobben som fullført og stopper fakturering. De launcher.py skriptet i TensorFlow- og PyTorch-eksempelnotatbøkene gir en referanseimplementering av signaleringsdatagruppeforekomster som skal avsluttes når DNN-gruppeforekomster fullfører arbeidet.

Eksempel på notatbøker for SageMaker heterogene klynger

I denne delen gir vi et sammendrag av eksempel notatbøker for både TensorFlow- og PyTorch ML-rammeverk. I notatbøkene kan du finne implementeringsdetaljene, gjennomganger om hvordan koden fungerer, kodebiter som du kan bruke på nytt i treningsskriptene dine, flytdiagrammer og kostnadssammenligningsanalyse.

Merk at i begge eksemplene bør du ikke forvente at modellen konvergerer på en meningsfull måte. Vår hensikt er kun å måle datapipeline og nevrale nettverksoptimeringsgjennomstrømning uttrykt i epoke/trinn-tid. Du må benchmarke med din egen modell og datasett for å produsere prisytelsesfordeler som samsvarer med arbeidsmengden din.

Heterogen klynge som bruker en tf.data.service-basert distribuert datalaster (TensorFlow)

Dette bærbare demonstrerer hvordan man implementerer en heterogen klynge for SageMaker-trening ved å bruke TensorFlows tf.data.service basert distribuert datapipeline. Vi trener en dyplæringsmodell for datasyn Resnett50 som krever CPU-intensiv dataforsterkning. Det bruker Horvod for multi-GPU distribuert dataparallellisme.

Vi kjører arbeidsmengden i to konfigurasjoner: først som en homogen klynge, enkelt ml.p4d.24xlarge forekomst, ved bruk av en standard tf.data pipeline som viser CPU-flaskehalser som fører til lavere GPU-utnyttelse. I den andre kjøringen bytter vi fra en enkelt instanstype til to instansgrupper ved å bruke en SageMaker heterogen klynge. Denne kjøringen avlaster noe av databehandlingen til ytterligere CPU-forekomster (ved hjelp av tf.data.service).

Vi sammenligner deretter de homogene og heterogene konfigurasjonene og finner viktige fordeler med prisytelse. Som vist i tabellen nedenfor, er den heterogene jobben (86ms/steg) 2.2 ganger raskere å trene enn den homogene jobben (192ms/steg), noe som gjør det 46 % billigere å trene en modell.

Eksempel 1 (TF)	ml.p4d.24xl	ml.c5.18xl	Pris per time*	Gjennomsnittlig trinntid	Kostnad per trinn	Pris Ytelsesforbedring
homogen	1	0	$37.688	192 ms	$0.201	.
Heterogen	1	2	$45.032	86 ms	$0.108	46%

* Pris per time er basert på us-east-1 SageMaker on-demand-priser

Denne hastigheten er gjort mulig ved å bruke den ekstra vCPUen, levert av datagruppen, og raskere forhåndsbehandling. Se bærbare for flere detaljer og grafer.

Heterogen klynge som bruker en gRPC-klientserverbasert distribuert datalaster (PyTorch)

Dette bærbare demonstrerer en prøvearbeidsbelastning ved bruk av en heterogen klynge for SageMaker-trening ved bruk av en gRPC-klientserverbasert distribuert datalaster. Dette eksemplet bruker en enkelt GPU. Vi bruker PyTorch-modellen basert på følgende offisielt MNIST-eksempel. Opplæringskoden er endret for å være tung på dataforbehandling. Vi trener denne modellen i både homogene og heterogene klyngemoduser, og sammenligner prisytelse.

I dette eksemplet antok vi at arbeidsbelastningen ikke kan dra nytte av flere GPUer, og at den er avhengig av en spesifikk GPU-arkitektur (NVIDIA V100). Vi kjørte både homogene og heterogene opplæringsjobber, og fant viktige prisytelsesfordeler, som vist i tabellen nedenfor. Den heterogene jobben (1.19s/steg) er 6.5 ganger raskere å trene enn den homogene jobben (0.18s/steg), noe som gjør det 77 % billigere å trene en modell.

Eksempel 2 (PT)	ml.p3.2xl	ml.c5.9xl	Pris per time*	Gjennomsnittlig trinntid	Kostnad per trinn	Pris Ytelsesforbedring
homogen	1	0	$3.825	1193 ms	$0.127	.
Heterogen	1	1	$5.661	184 ms	$0.029	77%

* Pris per time er basert på us-east-1 SageMaker on-demand-priser

Dette er mulig fordi med et høyere CPU-antall, kunne vi bruke 32 datainnlastingsarbeidere (sammenlignet med 8 med ml.p3.2xlarge) for å forhåndsbehandle dataene og holdt GPU nær 100 % brukt med hyppige intervaller. Se bærbare for flere detaljer og grafer.

Heterogene klynger ved Mobileye

Mobileye, et Intel-selskap, utvikler Advanced Driver Assistance Systems (ADAS) og autonome kjøretøyteknologier med mål om å revolusjonere transportindustrien, gjøre veiene tryggere og redde liv. Disse teknologiene er aktivert ved hjelp av sofistikerte datasyn (CV)-modeller som er trent opp ved hjelp av SageMaker på store datamengder lagret i Amazon enkel lagringstjeneste (Amazon S3). Disse modellene bruker state-of-the-art teknikker for dyp læring av nevrale nettverk.

Vi la merke til at for en av våre CV-modeller var CPU-flaskehalsen primært forårsaket av tung dataforbehandling som førte til underutnyttede GPUer. For denne spesifikke arbeidsmengden begynte vi å se på alternative løsninger, evaluerte distribuerte datapipeline-teknologier med heterogene klynger basert på EC2-instanser, og kom opp med referanseimplementeringer for begge tensorflow og PyTorch. Utgivelsen av SageMaker heterogene klynge lar oss kjøre denne og lignende arbeidsbelastninger på SageMaker for å oppnå forbedrede prisytelsesfordeler.

betraktninger

Med lanseringen av den heterogene klyngefunksjonen tilbyr SageMaker mye mer fleksibilitet når det gjelder å blande og matche instanstyper i treningsjobben din. Tenk imidlertid på følgende når du bruker denne funksjonen:

• Den heterogene klyngefunksjonen er tilgjengelig gjennom SageMaker PyTorch og tensorflow rammeberegningsklasser. Støttede rammeverk er PyTorch v1.10 eller nyere og TensorFlow v2.6 eller nyere.
• Alle forekomstgrupper deler det samme Docker-bildet.
• Alle forekomstgrupper deler det samme treningsskriptet. Derfor bør treningsskriptet ditt modifiseres for å oppdage hvilken forekomstgruppe det tilhører og gaffelløper deretter.
• Opplæringsforekomstene vertsnavn (for eksempel alog-1, algo-2 og så videre) er tilfeldig tildelt, og indikerer ikke hvilken forekomstgruppe de tilhører. For å få forekomstens rolle anbefaler vi å få medlemskap i forekomstgruppen under kjøring. Dette er også relevant ved gjennomgang av pålogginger CloudWatch, fordi loggstrømmens navn [training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp] har vertsnavnet.
• En distribuert opplæringsstrategi (vanligvis en MPI-klynge) kan bare brukes på én forekomstgruppe.
• SageMaker Administrerte varme bassenger og SageMaker Lokal modus kan foreløpig ikke brukes med heterogen klyngetrening.

konklusjonen

I dette innlegget diskuterte vi når og hvordan du kan bruke den heterogene klyngefunksjonen til SageMaker-trening. Vi demonstrerte en prisytelsesforbedring på 46 % på en brukssak i den virkelige verden og hjalp deg raskt i gang med distribuert datalaster (tf.data.service og gRPC klient-server) implementeringer. Du kan bruke disse implementeringene med minimale kodeendringer i dine eksisterende opplæringsskript.

For å komme i gang, prøv vår eksempel notatbøker. For å lære mer om denne funksjonen, se Tren ved hjelp av en heterogen klynge.

---

Om forfatterne

Gili Nachum er en senior AI/ML Specialist Solutions Architect som jobber som en del av EMEA Amazon Machine Learning-teamet. Gili er lidenskapelig opptatt av utfordringene med å trene dyplæringsmodeller, og hvordan maskinlæring endrer verden slik vi kjenner den. På fritiden liker Gili å spille bordtennis.

Hrushikesh Gangur er en hovedløsningsarkitekt for AI/ML-startups med ekspertise innen både ML Training og AWS Networking. Han hjelper startups innen Autonomous Vehicle, Robotics, CV, NLP, MLOps, ML Platform og Robotics Process Automation-teknologier med å drive virksomheten sin effektivt og effektivt på AWS. Før han begynte i AWS, skaffet Hrushikesh 20+ års bransjeerfaring, hovedsakelig rundt sky- og dataplattformer.

Gal Oshri er senior produktsjef i Amazon SageMaker-teamet. Han har 7 års erfaring med maskinlæringsverktøy, rammeverk og tjenester.

Chaim Rand er en maskinlæringsalgoritmeutvikler som jobber med dyplæring og datasynsteknologier for løsninger for autonome kjøretøy hos Mobileye, et Intel-selskap. Sjekk ut hans blogger.