Forbedre prisydelsen af ​​din modeltræning ved hjælp af Amazon SageMaker heterogene klynger

Dette indlæg er skrevet sammen med Chaim Rand fra Mobileye.

Visse arbejdsbyrder for maskinlæring (ML), såsom træning af computersynsmodeller eller forstærkningslæring, involverer ofte at kombinere den GPU- eller acceleratorintensive opgave med træning af neurale netværksmodeller med den CPU-intensive opgave med dataforbehandling, såsom billedforstærkning. Når begge typer opgaver kører på den samme instanstype, får dataforbehandlingen flaskehalse på CPU'en, hvilket fører til lavere GPU-udnyttelse. Dette problem bliver værre med tiden, da gennemstrømningen af ​​nyere generationer af GPU'er vokser i et stejlere tempo end CPU'ers.

For at løse dette problem har vi i juli 2022 lanceret heterogene klynger til Amazon SageMaker modeltræning, som giver dig mulighed for at starte træningsjob, der bruger forskellige instanstyper i et enkelt job. Dette gør det muligt at aflæse dele af dataforbehandlingspipelinen til computeroptimeret instanstyper, mens opgaven med deep neural network (DNN) fortsætter med at køre GPU eller accelereret databehandling forekomststyper. Vores benchmarks viser op til 46 % prisydelsesfordele efter at have aktiveret heterogene klynger i en CPU-bundet TensorFlow-computervisionsmodeltræning.

For et lignende tilfælde, mobileye, et selskab til udvikling af autonome køretøjsteknologier, havde dette at dele:

"Ved at flytte CPU-bundet deep learning computer vision model træning til at køre over flere instanstyper (CPU og GPU/ML acceleratorer), ved hjælp af en tf.data.service baseret løsning, vi har bygget, lykkedes det os at reducere tiden til at træne med 40 %, mens vi reducerede omkostningerne til at træne med 30 %. Vi er begejstrede for heterogene klynger, der giver os mulighed for at køre denne løsning på Amazon SageMaker."

— AI Engineering, Mobileye

I dette indlæg diskuterer vi følgende emner:

• Hvordan heterogene klynger hjælper med at fjerne CPU-flaskehalse
• Hvornår skal man bruge heterogene klynger og andre alternativer
• Referenceimplementeringer i PyTorch og TensorFlow
• Performance benchmark resultater
• Heterogene klynger hos Mobileye

AWS'er accelereret computerforekomst familie inkluderer acceleratorer fra AWS brugerdefinerede chips (AWS-inferens, AWS Trainium), NVIDIA (GPU'er), Og Gaudi acceleratorer fra Habana Labs (et Intel-firma). Bemærk, at vi i dette indlæg bruger udtrykkene GPU og accelerator i flæng.

Hvordan heterogene klynger fjerner flaskehalse i databehandling

Dataforskere, der træner modeller for dyb læring, sigter efter at maksimere træningsomkostningseffektiviteten og minimere træningstiden. For at opnå dette er et grundlæggende optimeringsmål at have høj GPU-udnyttelse, den dyreste og mest sparsomme ressource inden for Amazon Elastic Compute Cloud (Amazon EC2) forekomst. Dette kan være mere udfordrende med ML-arbejdsbelastninger, der kombinerer den klassiske GPU-intensive neurale netværksmodels frem- og tilbageudbredelse med CPU-intensive opgaver, såsom databehandling og forstærkning i computervision eller at køre en miljøsimulering i forstærkningslæring. Disse arbejdsbelastninger kan ende med at blive CPU-bundet, hvor mere CPU ville resultere i højere gennemløb og hurtigere og billigere træning, da eksisterende acceleratorer er delvist inaktive. I nogle tilfælde kan CPU-flaskehalse løses ved at skifte til en anden instanstype med et højere CPU:GPU-forhold. Der er dog situationer, hvor skift til en anden instanstype muligvis ikke er mulig på grund af instansfamiliens arkitektur, lagring eller netværksafhængigheder.

I sådanne situationer skal du øge mængden af ​​CPU-kraft ved at blande instanstyper: instanser med GPU'er sammen med CPU. Sammenfattet resulterer dette i et samlet højere CPU:GPU-forhold. Indtil for nylig var SageMaker træningsjob begrænset til at have instanser af en enkelt valgt instanstype. Med SageMaker heterogene klynger kan dataforskere nemt køre et træningsjob med flere instanstyper, hvilket gør det muligt at aflaste nogle af de eksisterende CPU-opgaver fra GPU-instanserne til dedikerede computeroptimerede CPU-instanser, hvilket resulterer i højere GPU-udnyttelse og hurtigere og mere omkostnings- effektiv træning. Med den ekstra CPU-kraft kan du desuden få forbehandlingsopgaver, der traditionelt blev udført offline, som et indledende trin til, at træning bliver en del af dit træningsjob. Dette gør det hurtigere at iterere og eksperimentere over både dataforbehandling og DNN træningsantagelser og hyperparametre.

Overvej f.eks. en kraftfuld GPU-instanstype, ml.p4d.24xlarge (96 vCPU, 8 x NVIDIA A100 GPU'er), med et CPU:GPU-forhold på 12:1. Lad os antage, at dit træningsjob har brug for 20 vCPU'er for at forbehandle nok data til at holde en GPU 100 % udnyttet. Derfor, for at holde alle 8 GPU'er 100 % udnyttede, har du brug for en 160 vCPU'er instanstype. Men ml.p4d.24xlarge mangler 64 vCPU'er eller 40 %, hvilket begrænser GPU-udnyttelsen til 60 %, som vist til venstre i det følgende diagram. Ville det hjælpe at tilføje endnu en ml.p4d.24xlarge-instans? Nej, fordi jobbets CPU:GPU-forhold ville forblive det samme.

Med heterogene klynger kan vi tilføje to ml.c5.18xlarge (72 vCPU), som vist til højre i diagrammet. Den samlede netto vCPU i denne klynge er 210 (96+2*72), hvilket fører til et CPU:GPU-forhold på 30:1. Hver af disse computeroptimerede instanser vil blive aflastet med en dataforbehandling CPU-intensiv opgave og vil tillade effektiv GPU-udnyttelse. På trods af de ekstra omkostninger ved ml.c5.18xlarge tillader den højere GPU-udnyttelse hurtigere behandling og derfor højere prisydelsesfordele.

Hvornår skal man bruge heterogene klynger og andre alternativer

I dette afsnit forklarer vi, hvordan man identificerer en CPU-flaskehals, og diskuterer løsningen af ​​den ved hjælp af instanstypeopskalering vs. heterogene klynger.

Den hurtige måde at identificere en CPU-flaskehals på er at overvåge CPU og GPU udnyttelsesmålinger til SageMaker træningsjob i amazoncloudwatch. Du kan få adgang til disse visninger fra AWS Management Console inden for træningsjobsidens instansmetrics-hyperlink. Vælg de relevante metrics, og skift fra 5-minutters til 1-minutters opløsning. Bemærk, at skalaen er 100 % pr. vCPU eller GPU, så udnyttelsesgraden for en instans med 4 vCPU'er/GPU'er kan være så høj som 400%. Følgende figur er et sådant eksempel fra CloudWatch-metrics, hvor CPU er cirka 100 % udnyttet, hvilket indikerer en CPU-flaskehals, hvorimod GPU er underudnyttet.

For detaljeret diagnose, kør træningsjob med Amazon SageMaker Debugger at profilere ressourceudnyttelsesstatus, statistik og rammeoperationer ved at tilføje en profileringskonfiguration, når du konstruerer en SageMaker-estimator ved hjælp af SageMaker Python SDK. Når du har indsendt træningsjobbet, skal du gennemgå resultatet profileringsrapport for CPU-flaskehalse.

Hvis du konkluderer, at dit job kan drage fordel af et højere CPU:GPU-beregningsforhold, skal du først overveje at skalere op til en anden instanstype i samme instansfamilie, hvis en sådan er tilgængelig. Hvis du f.eks. træner din model på ml.g5.8xlarge (32 vCPU'er, 1 GPU), skal du overveje at skalere op til ml.g5.16xlarge (64 vCPU'er, 1 GPU). Eller, hvis du træner din model ved hjælp af multi-GPU-instans ml.g5.12xlarge (48 vCPU'er, 4 GPU'er), skal du overveje at skalere op til ml.g5.24xlarge (96 vCPU'er, 4 GPU'er). Der henvises til G5 forekomstfamiliespecifikation for flere detaljer.

Nogle gange er opskalering ikke en mulighed, fordi der ikke er nogen instanstype med et højere vCPU:GPU-forhold i den samme instansfamilie. Hvis du f.eks. træner modellen på ml.trn1.32xlarge, ml.p4d.24xlarge eller ml.g5.48xlarge, bør du overveje heterogene klynger til SageMaker modeltræning.

Udover at skalere op, vil vi gerne bemærke, at der er yderligere alternativer til en heterogen klynge, som NVIDIA DALI, som overfører billedforbehandling til GPU'en. For mere information, se Overvinde flaskehalse ved dataforbehandling med TensorFlow Data Service, NVIDIA DALI og andre metoder.

For at forenkle beslutningstagningen henvises til følgende rutediagram.

Sådan bruges SageMaker heterogene klynger

For at komme hurtigt i gang kan du springe direkte til TensorFlow- eller PyTorch-eksemplerne, som er en del af dette indlæg.

I dette afsnit leder vi dig igennem, hvordan du bruger en SageMaker heterogen klynge med et simpelt eksempel. Vi antager, at du allerede ved, hvordan du træner en model med SageMaker Python SDK og Estimator-klassen. Hvis ikke, henvises til Brug af SageMaker Python SDK før du fortsætter.

Forud for denne funktion initialiserede du træningsjobbets Estimator-klasse med InstanceCount og InstanceType-parametre, som implicit antager, at du kun har en enkelt instanstype (en homogen klynge). Med udgivelsen af ​​heterogene klynger introducerede vi det nye sagemaker.instance_group.InstanceGroup klasse. Dette repræsenterer en gruppe af en eller flere forekomster af en specifik forekomsttype, designet til at bære en logisk rolle (som databehandling eller neurale netværksoptimering. Du kan have to eller flere grupper og angive et brugerdefineret navn for hver forekomstgruppe, forekomsten type og antallet af forekomster for hver forekomstgruppe. For mere information, se Brug af SageMaker Python SDK , Brug af Low-Level SageMaker API'er.

Når du har defineret instansgrupperne, skal du ændre dit træningsscript for at læse SageMaker information om træningsmiljø der inkluderer heterogen klyngekonfiguration. Konfigurationen indeholder information såsom de aktuelle instansgrupper, de aktuelle værter i hver gruppe, og i hvilken gruppe den aktuelle vært bor med deres rangering. Du kan bygge logik i dit træningsscript for at tildele instansgrupperne til bestemte trænings- og databehandlingsopgaver. Derudover skal dit træningsscript tage sig af inter-instans gruppekommunikation eller distribuerede dataindlæsningsmekanismer (f.eks. tf.data.service i TensorFlow eller generisk gRPC klient-server) eller enhver anden ramme (f.eks. Apache Spark).

Lad os gennemgå et simpelt eksempel på at starte et heterogent træningsjob og læse miljøkonfigurationen under kørsel.

1. Når vi definerer og starter træningsjobbet, konfigurerer vi to instansgrupper, der bruges 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å indgangspunktets træningsscript (navngivet launcher.py), læser vi den heterogene klyngekonfiguration til, om instansen vil køre forbehandlingen eller DNN-koden:

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

Lad os med dette opsummere de opgaver SageMaker udfører på dine vegne, og de opgaver, som du er ansvarlig for.

SageMaker udfører følgende opgaver:

1. Angiv forskellige instanstyper i henhold til instansgruppedefinition.
2. Tilvejebring inputkanaler på alle eller specifikke instansgrupper.
3. Distribuer træningsscripts og afhængigheder til instanser.
4. Konfigurer en MPI-klynge på en specifik forekomstgruppe, hvis den er defineret.

Du er ansvarlig for følgende opgaver:

1. Rediger dit startoplæringsjobscript for at angive instansgrupper.
2. Implementer en distribueret datapipeline (f.eks. tf.data.service).
3. Rediger dit indgangsscript (se launcher.py i eksempelnotesbogen) for at være et enkelt indgangspunkt, der kører på alle forekomster, registrerer, hvilken forekomstgruppe den kører i, og udløser den relevante adfærd (såsom databehandling eller DNN-optimering).
4. Når træningsløkken er slut, skal du sikre dig, at din indgangspunktsproces afsluttes på alle instanser på tværs af alle instansgrupper. Dette er vigtigt, fordi SageMaker venter på, at alle forekomster er færdige med at behandle, før det markerer jobbet som afsluttet og stopper fakturering. Det launcher.py script i TensorFlow og PyTorch eksempel notesbøger giver en referenceimplementering af signaleringsdatagruppeforekomster, der skal afsluttes, når DNN-gruppeforekomster afslutter deres arbejde.

Eksempel på notesbøger til SageMaker heterogene klynger

I dette afsnit giver vi en oversigt over eksempel notesbøger til både TensorFlow og PyTorch ML frameworks. I notesbøgerne kan du finde implementeringsdetaljerne, gennemgange af, hvordan koden fungerer, kodestykker, som du kan genbruge i dine træningsscripts, flowdiagrammer og omkostningssammenligningsanalyse.

Bemærk, at du i begge eksempler ikke skal forvente, at modellen konvergerer på en meningsfuld måde. Vores hensigt er kun at måle datapipeline og neurale netværksoptimeringsgennemstrømning udtrykt i epoke/trintid. Du skal benchmarke med din egen model og dit eget datasæt for at producere prisydelsesfordele, der matcher din arbejdsbyrde.

Heterogen klynge ved hjælp af en tf.data.service baseret distribueret dataindlæser (TensorFlow)

Denne notesbog demonstrerer, hvordan man implementerer en heterogen klynge til SageMaker-træning ved hjælp af TensorFlow's tf.data.service baseret distribueret datapipeline. Vi træner en deep learning computer vision model Resnet50 der kræver CPU-intensive dataforøgelse. Det bruger Horvod for multi-GPU distribueret dataparallelisme.

Vi kører arbejdsbyrden i to konfigurationer: først som en homogen klynge, enkelt ml.p4d.24xlarge instans ved hjælp af en standard tf.data pipeline, der viser CPU-flaskehalse, der fører til lavere GPU-udnyttelse. I den anden kørsel skifter vi fra en enkelt instanstype til to instansgrupper ved hjælp af en SageMaker heterogen klynge. Denne kørsel aflaster noget af databehandlingen til yderligere CPU-instanser (ved hjælp af tf.data.service).

Vi sammenligner derefter de homogene og heterogene konfigurationer og finder de vigtigste prisydelsesfordele. Som vist i følgende tabel er det heterogene job (86ms/trin) 2.2 gange hurtigere at træne end det homogene job (192ms/trin), hvilket gør det 46 % billigere at træne en model.

Eksempel 1 (TF)	ml.p4d.24xl	ml.c5.18xl	Pris pr. time*	Gennemsnitlig trintid	Pris pr. trin	Pris Ydeevne Forbedring
homogen	1	0	$37.688	192 ms	$0.201	.
Heterogen	1	2	$45.032	86 ms	$0.108	46 %

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

Denne fremskyndelse er muliggjort ved at bruge den ekstra vCPU, leveret af datagruppen, og hurtigere forbehandling. Se den notesbog for flere detaljer og grafer.

Heterogen klynge ved hjælp af en gRPC klient-server baseret distribueret dataindlæser (PyTorch)

Denne notesbog demonstrerer et eksempel på en arbejdsbelastning ved hjælp af en heterogen klynge til SageMaker-træning ved hjælp af en gRPC-klientserverbaseret distribueret dataindlæser. Dette eksempel bruger en enkelt GPU. Vi bruger PyTorch-modellen baseret på følgende officielt MNIST eksempel. Træningskoden er blevet ændret til at være tung på dataforbehandling. Vi træner denne model i både homogene og heterogene klyngetilstande og sammenligner prisydelse.

I dette eksempel antog vi, at arbejdsbyrden ikke kan drage fordel af flere GPU'er og er afhængig af en specifik GPU-arkitektur (NVIDIA V100). Vi kørte både homogene og heterogene uddannelsesjob og fandt vigtige prisfordele, som vist i følgende tabel. Det heterogene job (1.19s/trin) er 6.5 gange hurtigere at træne end det homogene job (0.18s/trin), hvilket gør det 77% billigere at træne en model.

Eksempel 2 (PT)	ml.p3.2xl	ml.c5.9xl	Pris pr. time*	Gennemsnitlig trintid	Pris pr. trin	Pris Ydeevne Forbedring
homogen	1	0	$3.825	1193 ms	$0.127	.
Heterogen	1	1	$5.661	184 ms	$0.029	77 %

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

Dette er muligt, fordi vi med et højere CPU-antal kunne bruge 32 dataindlæserarbejdere (sammenlignet med 8 med ml.p3.2xlarge) til at forbehandle dataene og holdt GPU tæt på 100 % brugt med hyppige intervaller. Se den notesbog for flere detaljer og grafer.

Heterogene klynger hos Mobileye

Mobileye, en Intel-virksomhed, udvikler Advanced Driver Assistance Systems (ADAS) og autonome køretøjsteknologier med det mål at revolutionere transportindustrien, gøre vejene sikrere og redde liv. Disse teknologier aktiveres ved hjælp af sofistikerede computersynsmodeller (CV), der trænes ved hjælp af SageMaker på store mængder data, der er lagret i Amazon Simple Storage Service (Amazon S3). Disse modeller bruger state-of-the-art deep learning neurale netværksteknikker.

Vi bemærkede, at for en af ​​vores CV-modeller var CPU-flaskehalsen primært forårsaget af tung dataforbehandling, der førte til underudnyttede GPU'er. Til denne specifikke arbejdsbyrde begyndte vi at se på alternative løsninger, evaluerede distribuerede datapipeline-teknologier med heterogene klynger baseret på EC2-instanser og kom med referenceimplementeringer for begge TensorFlow , PyTorch. Frigivelsen af ​​SageMaker heterogene klynge giver os mulighed for at køre denne og lignende arbejdsbelastninger på SageMaker for at opnå forbedrede prisydelsesfordele.

Overvejelser

Med lanceringen af ​​den heterogene klyngefunktion tilbyder SageMaker meget mere fleksibilitet i at blande og matche instanstyper inden for dit træningsjob. Overvej dog følgende, når du bruger denne funktion:

• Den heterogene klyngefunktion er tilgængelig gennem SageMaker PyTorch , TensorFlow rammeestimator klasser. Understøttede rammer er PyTorch v1.10 eller nyere og TensorFlow v2.6 eller nyere.
• Alle instansgrupper deler det samme Docker-billede.
• Alle instansgrupper deler det samme træningsscript. Derfor bør dit træningsscript modificeres for at registrere, hvilken instansgruppe det tilhører, og fork-løb i overensstemmelse hermed.
• Træningsinstansernes værtsnavne (f.eks. alog-1, algo-2 og så videre) er tilfældigt tildelt og angiver ikke, hvilken instansgruppe de tilhører. For at få instansens rolle anbefaler vi at få dens instansgruppemedlemskab under kørsel. Dette er også relevant ved gennemgang af logs ind CloudWatch, fordi logstrømmens navn [training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp] har værtsnavnet.
• En distribueret træningsstrategi (normalt en MPI-klynge) kan kun anvendes på én instansgruppe.
• SageMaker Administreret varme pools og SageMaker Lokal tilstand kan på nuværende tidspunkt ikke bruges med heterogen klyngetræning.

Konklusion

I dette indlæg diskuterede vi, hvornår og hvordan man bruger den heterogene klyngefunktion i SageMaker-træning. Vi demonstrerede en prisforbedring på 46 % i forhold til en brugscase i den virkelige verden og hjalp dig hurtigt i gang med distribueret dataindlæser (tf.data.service og gRPC klient-server) implementeringer. Du kan bruge disse implementeringer med minimale kodeændringer i dine eksisterende træningsscripts.

For at komme i gang, prøv vores eksempel notesbøger. For at lære mere om denne funktion, se Træn ved hjælp af en heterogen klynge.

---

Om forfatterne

Gili Nachum er en senior AI/ML Specialist Solutions Architect, der arbejder som en del af EMEA Amazon Machine Learning-teamet. Gili brænder for udfordringerne ved at træne deep learning-modeller, og hvordan maskinlæring ændrer verden, som vi kender den. I sin fritid nyder Gili at spille bordtennis.

Hrushikesh Gangur er en hovedløsningsarkitekt for AI/ML startups med ekspertise inden for både ML Training og AWS Networking. Han hjælper startups inden for Autonomous Vehicle, Robotics, CV, NLP, MLOps, ML Platform og Robotics Process Automation-teknologier med at drive deres forretning effektivt og effektivt på AWS. Før han kom til AWS, erhvervede Hrushikesh 20+ års brancheerfaring primært omkring cloud- og dataplatforme.

Gal Oshri er Senior Product Manager på Amazon SageMaker-teamet. Han har 7 års erfaring med at arbejde med maskinlæringsværktøjer, rammer og tjenester.

Chaim Rand er en maskinlæringsalgoritmeudvikler, der arbejder med deep learning og computervisionsteknologier til løsninger til autonome køretøjer hos Mobileye, en Intel-virksomhed. Tjek hans blogs.