Beste praksis for Amazon SageMaker Training Managed Warm Pools

Amazon SageMaker Training Managed Warm Pools gir deg fleksibiliteten til å velge å gjenbruke og holde på den underliggende infrastrukturen i en brukerdefinert periode. Dette gjøres samtidig som man opprettholder fordelen ved å overføre de udifferensierte tunge løftene ved å administrere dataforekomster til Amazon SageMaker modellopplæring. I dette innlegget skisserer vi de viktigste fordelene og smertepunktene som behandles av SageMaker Training Managed Warm Pools, samt benchmarks og beste praksis.

Oversikt over SageMaker Training Managed Warm Pools

SageMaker Model Training er en fullstendig administrert funksjon som spinner opp forekomster for hver jobb, trener en modell, kjører og spinner ned forekomster etter jobben. Du blir bare fakturert for varigheten av jobben ned til den andre. Denne fullstendig administrerte funksjonen gir deg friheten til å fokusere på maskinlæringsalgoritmen (ML) og ikke bekymre deg for udifferensierte tunge løft som infrastrukturadministrasjon mens du trener modellene dine.

Denne mekanismen krever en begrenset oppstartstid for en treningsjobb. Selv om dette oppstartstidspunktet, også kjent som kaldstart oppstartstid, er ganske lav, krever noen av våre mest krevende kundebrukstilfeller enda lavere oppstartstid, for eksempel under 20 sekunder. Det er to fremtredende brukstilfeller som har disse kravene:

• Den første er aktiv ML-eksperimentering av dataforskere som bruker Amazon SageMaker treningsplattform, spesielt mens du trener store modeller, som GPT3, som krever flere iterasjoner for å komme til en produksjonsklar tilstand.
• Den andre er den programmatiske lanseringen av et stort antall (i størrelsesorden flere hundre eller tusenvis) av påfølgende jobber på samme type forekomster på en planlagt tråkkfrekvens. For eksempel parametersøk eller inkrementell trening.

For slike brukstilfeller har hvert sekund brukt på overhead, som oppstartstiden for en treningsjobb, en kumulativ effekt på alle disse jobbene.

Med SageMaker Training Managed Warm Pools har dataforskere og ML-ingeniører muligheten til å velge å holde SageMaker-treningsforekomster eller multi-instansklynger varme i en forhåndsdefinert og rekonfigurerbar tid (keep_alive_period_in_seconds) etter at hver treningsjobb er fullført. Så selv om du pådrar deg en kaldstartstraff for den første treningsjobben som kjøres på en forekomst eller klynge, for alle de påfølgende treningsjobbene, er forekomstene allerede oppe og går. Som et resultat vil disse påfølgende treningsjobbene som starter på en forekomst før keep_alive_period_in_seconds utløper pådrar seg ikke oppstartstiden for kaldstart. Dette kan redusere treningsjobbens oppstartstid til omtrent mindre enn 20 sekunder (P90).

Dataforskere og ML-ingeniører kan bruke SageMaker Training Managed Warm Pools for å holde enkelt- eller flere forekomster varme mellom treningskjøringer for eksperimentering eller kjøre flere jobber etter hverandre på samme enkelt- eller multiinstansklynge. Du betaler kun for varigheten av treningsjobber og det rekonfigurerbare keep_alive_period_in_seconds som alle andre steder du spesifiserer for hver enkelt forekomst.

I hovedsak, med SageMaker Training Managed Warm Pools, får du en kombinasjon av SageMaker-administrerte instansutnyttelse med muligheten til å melde seg på og levere kapasitet og selvadministrerende utnyttelse i korte tidsintervaller. Disse intervallene kan konfigureres før en jobb, men hvis under keep_alive_period_in_seconds intervall, må du redusere eller øke det, du kan gjøre det. Øker til keep_alive_period_in_seconds kan gjøres i intervaller på opptil 60 minutter, med en maksimal periode for en forekomst eller klynge på 7 dager.

For å komme i gang med varme bassenger, først be om en økning i kvotegrensen for varme bassenger, spesifiser deretter keep_alive_period_in_seconds parameter når du starter en treningsjobb.

benchmarks

Vi utførte benchmarking-tester for å måle ventetiden ved oppstart av jobb ved å bruke et 1.34 GB TensorFlow-bilde, 2 GB data og forskjellige inndatamoduser for treningsdata (Amazon FSx, Fast File Mode, File Mode). Testene ble kjørt på tvers av en rekke instanstyper fra m4-, c4-, m5- og c5-familiene i us-east-2-regionen. Oppstartsforsinkelsen ble målt som tidspunktet for jobbskaping til starten av den faktiske treningsjobben på forekomstene. De første jobbene som startet klyngen og opprettet det varme bassenget hadde en oppstartsforsinkelse på 2–3 minutter. Denne høyere ventetiden skyldes tiden det tar å klargjøre infrastrukturen, laste ned bildet og laste ned dataene. De påfølgende jobbene som brukte den varme bassengklyngen hadde en oppstartsforsinkelse på omtrent 20 sekunder for Fast File Mode (FFM) eller Amazon FSx, og 70 sekunder for File Mode (FM). Dette deltaet er et resultat av at FM krever at hele datasettet lastes ned fra Amazon S3 før jobbstart.

Ditt valg av inndatamodus for treningsdata påvirker oppstartstiden, selv med varme bassenger. Veiledning om hvilken inndatamodus du skal velge, finner du i avsnittet om beste praksis senere i dette innlegget.

Følgende tabell oppsummerer jobbstartforsinkelsen P90 for forskjellige inndatamoduser for treningsdata.

Datainndatamodus	Oppstartsforsinkelse P90 (sekunder)
	Første jobb	Warm Pool Jobs (andre jobb og utover)
FSx	136	19
Rask filmodus	143	21
Filmodus	176	70

Beste praksis for bruk av varme bassenger

I den følgende delen deler vi noen beste fremgangsmåter når du bruker varme bassenger.

Når bør du bruke varme bassenger?

Varme bassenger anbefales i følgende scenarier:

• Du eksperimenterer interaktivt og justerer manuset ditt over en rekke korte jobber.
• Du kjører din egen skreddersydde, storskala hyperparameteroptimalisering (f.eks. Syne Tune).
• Du har en batchprosess som kjører et stort antall (i størrelsesorden flere hundre eller tusenvis) av påfølgende jobber på samme type forekomster på en daglig eller ukentlig kadens. For eksempel å trene en ML-modell per by.

Varme bassenger anbefales ikke når det er usannsynlig at noen vil gjenbruke det varme bassenget før det utløper. For eksempel en enkelt lang jobb som går via en automatisert ML-pipeline.

Minimer oppstartstiden for treningsjobber for varmt basseng

Treningsjobber som gjenbruker et varmt basseng starter raskere enn den første jobben som skapte det varme bassenget. Dette skyldes at ML-forekomstene kjører mellom jobber med en bufret opplæringsbeholder Docker-bilde for å hoppe over å trekke beholderen fra Amazon Elastic Container Registry (Amazon ECR). Men selv ved gjenbruk av et varmt basseng, forekommer visse initialiseringstrinn for alle jobber. Optimalisering av disse trinnene kan redusere oppstartstiden for jobben (både første og etterfølgende jobber). Vurder følgende:

• Inndatamodus for treningsdata kan påvirke oppstartstiden – Inndatakanaler for administrerte opplæringsdata gjenskapes for hver treningsjobb, noe som bidrar til ventetiden for jobbstart. Så å gjøre innledende eksperimenter over et mindre datasett vil gi raskere oppstartstid (og raskere treningstid). For senere stadier av eksperimentering, når et stort datasett er nødvendig, bør du vurdere å bruke en inndatamodustype som har minimal eller fast initialiseringstid. For eksempel kopierer FILE-inndatamodus hele datasettet fra Amazon enkel lagringstjeneste (Amazon S3) til treningsforekomsten, noe som er tidkrevende for store datasett (selv med varme bassenger). Fast File Mode er bedre egnet for lavere oppstartsforsinkelse fordi bare S3-objektmetadata må leses fra Amazon S3 før arbeidsbelastningen kan starte. De Amazon FSx for Lustereller Amazon elastisk filsystem (Amazon EFS) filsysteminndatamodus, har en fast initialiseringstid uavhengig av antall filer i filsystemet, noe som er fordelaktig når du arbeider med et stort datasett.
  For mer informasjon om hvordan du velger en inngangskanal, se Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb.
• Reduser kjøretidsinstallasjon av pakker – Enhver programvareinstallasjon som finner sted under oppstart av container, for eksempel Pythons pip eller operativsystem apt-get, vil øke ventetiden for treningsjobben. Å minimere denne oppstartsforsinkelsen krever en avveining mellom fleksibiliteten og enkelheten til kjøretidsinstallasjoner kontra installasjon på containerbyggetidspunktet. Hvis du bruker din egen Docker-beholder med SageMaker, se Tilpasse din egen Docker-beholder til å fungere med SageMaker. Hvis du stoler på forhåndsbygde SageMaker-beholderbilder, må du utvide en forhåndsbygd container og eksplisitt administrere disse beholderne. Vurder dette hvis kjøretidsinstallasjonene øker oppstartsforsinkelsen betydelig.
• Unngå å oppdatere Docker-bildet ditt ofte – Hvis du bruker din egen Docker-beholder med SageMaker, prøv å unngå å oppdatere den hver gang du kjører. Hvis Docker-bildet endres mellom jobbinnsendingene, vil det varme bassenget bli gjenbrukt, men oppstartsprosessen må hente beholderbildet på nytt fra Amazon ECR i stedet for å gjenbruke et bufret beholderbilde. Hvis Docker-bildet må oppdateres, begrenser du oppdateringene til det siste Docker-laget for å dra nytte av Docker-lagbufring. Ideelt sett bør du fjerne Dockerfile-innholdet som sannsynligvis vil endre seg over iterasjoner, som hyperparameter, datasettdefinisjoner og selve ML-koden. For å iterere på ML-kode uten å måtte gjenoppbygge Docker-bilder med hver endring, kan du ta i bruk rammebeholderparadigmet som foreslås i SageMaker Training Toolkit. Hvis du vil utvikle en rammebeholder med din egen kode, se denne Amazon SageMaker-opplæring.

Del varme bassenger mellom flere brukere

Når du jobber med et stort team av dataforskere, kan du dele varme bassenger som har samsvarende jobbkriterier, slik som det samme AWS identitets- og tilgangsadministrasjon (IAM) rolle eller beholderbilde.

La oss se på et eksempel på en tidslinje. Bruker-1 starter en treningsjobb som fullfører og resulterer i et nytt varmt basseng opprettet. Når bruker-2 starter en treningsjobb, vil jobben gjenbruke det eksisterende varme bassenget, noe som resulterer i en rask oppstart av jobben. Mens bruker-2s jobb kjører med det varme bassenget i bruk, hvis en annen bruker starter en treningsjobb, vil det opprettes et nytt varmt basseng.

Denne gjenbruksatferden bidrar til å redusere kostnadene ved å dele varme bassenger mellom brukere som starter lignende jobber. Hvis du vil unngå å dele varme bassenger mellom brukere, så må ikke brukernes jobber ha samsvarende jobbkriterier (de må for eksempel bruke en annen IAM-rolle).

Varsle brukere når jobben er fullført

Når du bruker varme bassenger for eksperimentering, anbefaler vi å varsle brukere når jobben deres er fullført. Dette tillater brukere å gjenoppta eksperimentering før det varme bassenget utløper eller stoppe det varme bassenget hvis det ikke lenger er nødvendig. Du kan også automatisk utløse varsler gjennom Amazon EventBridge.

Ytterligere verktøy for rask eksperimentering og feilsøking av treningsjobber

Med varme bassenger kan du starte en jobb på mindre enn 20 sekunder. Noen scenarier krever interaktiv eksperimentering og feilsøking i sanntid. Åpen kildekode SageMaker SSH Helper-bibliotek lar deg gå inn i en SageMaker treningsbeholder og utføre ekstern utvikling og feilsøking.

konklusjonen

Med SageMaker Training Managed Warm Pools kan du holde modellene dine varme etter hver jobb i en spesifisert periode. Dette kan redusere oppstartsforsinkelsen for en modelltreningsjobb med opptil 8 ganger. SageMaker Training Managed Warm Pools er tilgjengelig i alle offentlige AWS-regioner der SageMaker Model Training er tilgjengelig.

For å komme i gang, se Tren med SageMaker Managed Warm Pools.

---

Om forfatterne

Dr. Romi Datta  er seniorleder for produktledelse i Amazon SageMaker-teamet med ansvar for opplæring, prosessering og funksjonsbutikk. Han har vært i AWS i over 4 år, og hatt flere lederroller for produktledelse i SageMaker, S3 og IoT. Før AWS jobbet han i ulike produktledelses-, ingeniør- og operative lederroller hos IBM, Texas Instruments og Nvidia. Han har en MS og Ph.D. i elektro- og datateknikk fra University of Texas i Austin, og en MBA fra University of Chicago Booth School of Business.

Arun Nagarajan er en hovedingeniør med Amazon SageMaker-teamet med fokus på trenings- og MLOps-områdene. Han har vært med SageMaker-teamet fra lanseringsåret, og likte å bidra til forskjellige områder i SageMaker, inkludert sanntidsslutning og Model Monitor-produktene. Han liker å utforske utendørs i Pacific Northwest-området og klatre i fjell.

Amy du er Software Development Manager hos AWS SageMaker. Hun fokuserer på å samle et team av programvareingeniører for å bygge, vedlikeholde og utvikle nye muligheter til SageMaker Training-plattformen som hjelper kundene med å trene ML-modellene sine mer effektivt og enkelt. Hun har en lidenskap for ML og AI-teknologi, spesielt relatert til image og visjon fra hovedstudiene. På fritiden elsker hun å jobbe med musikk og kunst sammen med familien.

Sifei Li er programvareingeniør i Amazon AI hvor hun jobber med å bygge Amazon Machine Learning Platforms og var en del av lanseringsteamet for Amazon SageMaker. På fritiden liker hun å spille musikk og lese.

Jenna Zhao er programvareutviklingsingeniør hos AWS SageMaker. Hun er lidenskapelig opptatt av ML/AI-teknologi og har fokusert på å bygge SageMaker Training-plattform som gjør det mulig for kunder å raskt og enkelt trene maskinlæringsmodeller. Utenom jobben liker hun å reise og tilbringe tid med familien.

Paras Mehra er senior produktsjef i AWS. Han er fokusert på å hjelpe med å bygge Amazon SageMaker Training and Processing. På fritiden liker Paras å tilbringe tid med familien og sykle rundt i Bay Area. Du kan finne ham på Linkedin.

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.

Olivier Cruchant er en maskinlæringsspesialist løsningsarkitekt ved AWS, basert i Frankrike. Olivier hjelper AWS-kunder – fra små startups til store bedrifter – med å utvikle og distribuere maskinlæringsapplikasjoner i produksjonsgrad. På fritiden liker han å lese forskningsartikler og utforske villmarken med venner og familie.

Emily Webber ble med i AWS like etter at SageMaker ble lansert, og har prøvd å fortelle verden om det siden den gang! Utenom å bygge nye ML-opplevelser for kunder, liker Emily å meditere og studere tibetansk buddhisme.