Bedste praksis for Amazon SageMaker Training Managed Warm Pools

Amazon SageMaker Training Managed Warm Pools giver dig fleksibiliteten til at vælge at genbruge og holde på den underliggende infrastruktur i en brugerdefineret periode. Dette gøres samtidig med, at man bibeholder fordelen ved at overføre de udifferentierede tunge løft ved håndtering af computerforekomster til Amazon SageMaker Model træning. I dette indlæg skitserer vi de vigtigste fordele og smertepunkter, der behandles af SageMaker Training Managed Warm Pools, samt benchmarks og bedste praksis.

Oversigt over SageMaker Training Managed Warm Pools

SageMaker Model Training er en fuldt administreret funktion, der spinner instanser op for hvert job, træner en model, kører og derefter spinner instanser ned efter jobbet. Du bliver kun faktureret for varigheden af ​​jobbet ned til den anden. Denne fuldt administrerede funktion giver dig frihed til at fokusere på din maskinlæringsalgoritme (ML) og ikke bekymre dig om udifferentierede tunge løft som infrastrukturstyring, mens du træner dine modeller.

Denne mekanisme nødvendiggør en begrænset opstartstid for et træningsjob. Selvom denne opstartstid, også kendt som koldstarts starttid, er forholdsvis lav, kræver nogle af vores mest krævende kundebrugssager endnu lavere opstartstider, såsom under 20 sekunder. Der er to fremtrædende use cases, der har disse krav:

• Den første er aktiv ML-eksperimentering udført af dataforskere ved hjælp af Amazon SageMaker træningsplatform, især mens du træner store modeller, som GPT3, der kræver flere gentagelser for at komme til en produktionsklar tilstand.
• Den anden er den programmatiske lancering af et stort antal (i størrelsesordenen flere hundrede eller tusinder) af på hinanden følgende job på den samme slags instanser på en planlagt kadence. For eksempel parametersøgning eller inkrementel træning.

I sådanne tilfælde har hvert sekund, der bruges på overhead, ligesom opstartstiden for et træningsjob, en kumulativ effekt på alle disse job.

Med SageMaker Training Managed Warm Pools har dataforskere og ML-ingeniører mulighed for at tilvælge at holde SageMaker træningsinstanser eller multi-instansklynger varme i en forudbestemt og rekonfigurerbar tid (keep_alive_period_in_seconds) efter hvert træningsjob er afsluttet. Så selvom du pådrager dig en koldstartsstraf for det første træningsjob, der køres på en instans eller klynge, for alle de efterfølgende træningsjob, er instanserne allerede oppe at køre. Som et resultat vil disse efterfølgende træningsjob, der starter på en instans før keep_alive_period_in_seconds udløber pådrager sig ikke koldstarts opstartstiden overhead. Dette kan reducere opstartstiden for træningsjob til ca. mindre end 20 sekunder (P90).

Dataforskere og ML-ingeniører kan bruge SageMaker Training Managed Warm Pools til at holde enkelte eller flere instanser varme mellem træningskørsler til eksperimentering eller køre flere opgaver fortløbende på den samme enkelt- eller multi-instans klynge. Du betaler kun for varigheden af ​​træningsjobs og det rekonfigurerbare keep_alive_period_in_seconds ligesom alle andre steder, du angiver for hver enkelt forekomst.

Kort sagt, med SageMaker Training Managed Warm Pools får du en kombination af SageMaker-administrerede instansudnyttelse med muligheden for at tilmelde dig og levere kapacitet og selvadministrere udnyttelse i korte tidsintervaller. Disse intervaller kan konfigureres før et job, men hvis under keep_alive_period_in_seconds interval, du skal reducere eller øge det, kan du gøre det. Stiger til keep_alive_period_in_seconds kan udføres i intervaller på op til 60 minutter, med en maksimal periode for en instans eller klynge på 7 dage.

For at komme i gang med varme pools, først anmode om en forhøjelse af kvotegrænsen for varm pool, og angiv derefter keep_alive_period_in_seconds parameter når du starter et træningsjob.

benchmarks

Vi udførte benchmarking-tests for at måle jobstartforsinkelse ved hjælp af et 1.34 GB TensorFlow-billede, 2 GB data og forskellige træningsdatainputtilstande (Amazon FSx, Fast File Mode, File Mode). Testene blev kørt på tværs af en række forskellige instanstyper fra m4-, c4-, m5- og c5-familierne i us-east-2-regionen. Startforsinkelsen blev målt som tidspunktet for jobskabelse til starten af ​​det faktiske træningsjob på instanserne. De første job, der startede klyngen og skabte den varme pool, havde en startforsinkelse på 2-3 minutter. Denne højere latenstid skyldes den tid, det tager at klargøre infrastrukturen, downloade billedet og downloade dataene. De efterfølgende job, der brugte den varme pool-klynge, havde en startforsinkelse på cirka 20 sekunder for Fast File Mode (FFM) eller Amazon FSx og 70 sekunder for File Mode (FM). Dette delta er et resultat af, at FM kræver, at hele datasættet skal downloades fra Amazon S3 før jobbets start.

Dit valg af inputtilstand for træningsdata påvirker opstartstiden, selv med varme pools. Vejledning om, hvilken inputtilstand der skal vælges, findes i afsnittet om bedste praksis senere i dette indlæg.

Følgende tabel opsummerer jobstartforsinkelsen P90 for forskellige inputtilstande for træningsdata.

Dataindtastningstilstand	Startforsinkelse P90 (sekunder)
	Første job	Warm Pool Jobs (andet job og fremefter)
FSx	136	19
Hurtig filtilstand	143	21
Filtilstand	176	70

Bedste praksis for brug af varme pools

I det følgende afsnit deler vi nogle bedste fremgangsmåder ved brug af varme pools.

Hvornår skal du bruge varme pools?

Varme pools anbefales i følgende scenarier:

• Du eksperimenterer interaktivt og tuner dit manuskript over en række korte jobs.
• Du kører din egen specialfremstillede, storskala hyperparameteroptimering (f.eks. Syne Tune).
• Du har en batchproces, der kører et stort antal (i størrelsesordenen flere hundrede eller tusinder) af på hinanden følgende job på den samme slags forekomster på en daglig eller ugentlig kadence. For eksempel at træne en ML-model pr. by.

Varme pools anbefales ikke, når det er usandsynligt, at nogen vil genbruge den varme pool, før den udløber. For eksempel et enkelt længerevarende job, der kører via en automatiseret ML-pipeline.

Minimer opstartstiden for jobopstart i varm pooltræning

Træningsopgaver, der genbruger en varm pool, starter hurtigere end det første job, der skabte den varme pool. Dette skyldes at holde ML-forekomsterne kørende mellem job med en cachelagret træningscontainer Docker-billede for at springe over at trække containeren fra Amazon Elastic Container Registry (Amazon ECR). Men selv når du genbruger en varm pool, forekommer visse initialiseringstrin for alle job. Optimering af disse trin kan reducere din jobstarttid (både første og efterfølgende job). Overvej følgende:

• Indtastningstilstand for træningsdata kan påvirke opstartstiden – Administrerede træningsdatainputkanaler genskabes for hvert træningsjob, hvilket bidrager til latens for jobstart. Så at udføre indledende eksperimenter over et mindre datasæt vil give mulighed for hurtigere opstartstid (og hurtigere træningstid). Til senere forsøgsstadier, når der er behov for et stort datasæt, kan du overveje at bruge en inputtilstandstype, der har minimal eller fast initialiseringstid. For eksempel kopierer FILE input-tilstand hele datasættet fra Amazon Simple Storage Service (Amazon S3) til træningsinstansen, hvilket er tidskrævende for store datasæt (selv med varme pools). Hurtig filtilstand er bedre egnet til lavere opstartsforsinkelse, fordi kun S3-objektmetadata skal læses fra Amazon S3, før arbejdsbyrden kan starte. Det Amazon FSx til Luster eller Amazon Elastic File System (Amazon EFS) filsystem input-tilstand, har en fast initialiseringstid uanset antallet af filer i filsystemet, hvilket er en fordel, når man arbejder med et stort datasæt.
  For mere information om, hvordan du vælger en inputkanal, se Vælg den bedste datakilde til dit Amazon SageMaker-uddannelsesjob.
• Reducer runtime installation af pakker – Enhver softwareinstallation, der finder sted under containeropstart, for eksempel Pythons pip eller operativsystem apt-get, vil øge træningsjob-latensen. Minimering af denne opstartsforsinkelse kræver en afvejning mellem fleksibiliteten og enkelheden ved runtime-installationer i forhold til installation på containerbyggetidspunktet. Hvis du bruger din egen Docker-container med SageMaker, se Tilpasning af din egen Docker-container til at arbejde med SageMaker. Hvis du stoler på forudbyggede SageMaker container billeder, skal du forlænge en præbygget container og eksplicit administrere disse containere. Overvej dette, hvis dine runtime-installationer øger startforsinkelsen markant.
• Undgå at opdatere dit Docker-billede ofte – Hvis du bruger din egen Docker-container med SageMaker, så prøv at undgå at opdatere den hver gang, du kører. Hvis Docker-billedet ændres mellem jobafsendelserne, vil den varme pool blive genbrugt, men opstartsprocessen bliver nødt til at trække containerbilledet igen fra Amazon ECR i stedet for at genbruge et cachelagret containerbillede. Hvis Docker-billedet skal opdateres, skal du begrænse opdateringerne til det sidste Docker-lag for at drage fordel af Docker-lags caching. Ideelt set bør du fjerne Dockerfile-indholdet, der sandsynligvis vil ændre sig over iterationer, såsom hyperparameter, datasætdefinitioner og selve ML-koden. For at gentage ML-kode uden at skulle genopbygge Docker-billeder med hver ændring, kan du adoptere det rammebeholderparadigme, der anbefales i SageMaker Training Toolkit. Hvis du gerne vil udvikle en rammebeholder med din egen kode, skal du henvise til denne Amazon SageMaker tutorial.

Del varme pools mellem flere brugere

Når du arbejder med et stort team af dataforskere, kan du dele varme pools, der har matchende jobkriterier, såsom det samme AWS identitets- og adgangsstyring (IAM) rolle eller containerbillede.

Lad os se på et eksempel på en tidslinje. Bruger-1 starter et træningsjob, der afslutter og resulterer i en ny varm pool oprettet. Når bruger-2 starter et træningsjob, vil jobbet genbruge den eksisterende varme pool, hvilket resulterer i en hurtig jobstart. Mens bruger-2's job kører med den varme pool i brug, vil der blive oprettet en anden varm pool, hvis en anden bruger starter et træningsjob.

Denne genbrugsadfærd hjælper med at reducere omkostningerne ved at dele varme pools mellem brugere, der starter lignende job. Hvis man vil undgå at dele varme bassiner mellem brugerne, så må brugernes job ikke have matchende jobkriterier (de skal f.eks. bruge en anden IAM-rolle).

Giv brugerne besked om færdiggørelse af opgaven

Når du bruger varme pools til eksperimenter, anbefaler vi, at du giver brugerne besked, når deres job er fuldført. Dette giver brugerne mulighed for at genoptage eksperimenter, før den varme pool udløber eller stoppe den varme pool, hvis den ikke længere er nødvendig. Du kan også automatisk udløser notifikationer ved Amazon Eventbridge.

Yderligere værktøjer til hurtig eksperimentering og fejlfinding af træningsjob

Med varme pools kan du starte et job på mindre end 20 sekunder. Nogle scenarier kræver interaktive eksperimenter og fejlfinding i realtid. Den åbne kildekode SageMaker SSH Helper bibliotek giver dig mulighed for at gå ind i en SageMaker-træningsbeholder og udføre fjernudvikling og fejlfinding.

Konklusion

Med SageMaker Training Managed Warm Pools kan du holde dine modeltræningshardware-instanser varme efter hvert job i en bestemt periode. Dette kan reducere startforsinkelsen for et modeltræningsjob med op til 8x. SageMaker Training Managed Warm Pools er tilgængelige i alle offentlige AWS-regioner, hvor SageMaker Model Training er tilgængelig.

For at komme i gang, se Træn ved hjælp af SageMaker Managed Warm Pools.

---

Om forfatterne

Dr. Romi Datta  er en Senior Manager for Product Management i Amazon SageMaker-teamet med ansvar for træning, behandling og featurebutik. Han har været i AWS i over 4 år, og han har haft flere lederroller inden for produktledelse i SageMaker, S3 og IoT. Før AWS arbejdede han i forskellige produktledelses-, ingeniør- og operationelle lederroller hos IBM, Texas Instruments og Nvidia. Han har en MS og Ph.D. i Electrical and Computer Engineering fra University of Texas i Austin og en MBA fra University of Chicago Booth School of Business.

Arun Nagarajan er en Principal Engineer med Amazon SageMaker-teamet med fokus på trænings- og MLOps-områderne. Han har været sammen med SageMaker-teamet fra lanceringsåret og nydt at bidrage til forskellige områder i SageMaker, herunder realtids-inferens og Model Monitor-produkter. Han kan lide at udforske udendørs i Pacific Northwest-området og bestige bjerge.

Amy dig er Software Development Manager hos AWS SageMaker. Hun fokuserer på at samle et team af softwareingeniører for at opbygge, vedligeholde og udvikle nye muligheder i SageMaker Training-platformen, der hjælper kunder med at træne deres ML-modeller mere effektivt og nemt. Hun har en passion for ML og AI-teknologi, især relateret til image og vision fra sine kandidatstudier. I sin fritid elsker hun at arbejde med musik og kunst sammen med sin familie.

Sifei Li er softwareingeniør i Amazon AI, hvor hun arbejder på at bygge Amazon Machine Learning Platforms og var en del af lanceringsteamet for Amazon SageMaker. I sin fritid kan hun lide at spille musik og læse.

Jenna Zhao er softwareudviklingsingeniør hos AWS SageMaker. Hun brænder for ML/AI-teknologi og har fokuseret på at bygge SageMaker Training platform, der gør det muligt for kunderne hurtigt og nemt at træne machine learning-modeller. Uden for arbejdet nyder hun at rejse og tilbringe tid med sin familie.

Paras Mehra er Senior Product Manager hos AWS. Han er fokuseret på at hjælpe med at opbygge Amazon SageMaker Training and Processing. I sin fritid nyder Paras at bruge tid med sin familie og cykle rundt i Bay Area. Du kan finde ham på LinkedIn.

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.

Olivier Cruchant er en Machine Learning Specialist Solutions Architect hos AWS, baseret i Frankrig. Olivier hjælper AWS-kunder – fra små startups til store virksomheder – med at udvikle og implementere maskinlæringsapplikationer i produktionskvalitet. I sin fritid nyder han at læse forskningsartikler og udforske vildmarken med venner og familie.

Emily Webber sluttede sig til AWS lige efter SageMaker lancerede, og har forsøgt at fortælle verden om det lige siden! Ud over at bygge nye ML-oplevelser for kunder, nyder Emily at meditere og studere tibetansk buddhisme.