Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb

Amazon SageMaker er en administrert tjeneste som gjør det enkelt å bygge, trene og distribuere maskinlæringsmodeller (ML). Dataforskere bruker SageMaker-treningsjobber for å enkelt trene ML-modeller; du trenger ikke å bekymre deg for å administrere dataressurser, og du betaler kun for den faktiske treningstiden. Datainntak er en integrert del av enhver treningspipeline, og SageMaker-opplæringsjobber støtter en rekke datalagrings- og inndatamoduser for å passe et bredt spekter av treningsarbeidsmengder.

Dette innlegget hjelper deg å velge den beste datakilden for din SageMaker ML treningsbruk. Vi introduserer datakildealternativene som SageMaker opplæringsjobber støtter innfødt. For hver datakilde og inndatamodus skisserer vi dens brukervennlighet, ytelsesegenskaper, kostnader og begrensninger. For å hjelpe deg med å komme raskt i gang, gir vi diagrammet et eksempel på beslutningsflyt som du kan følge basert på dine viktigste arbeidsbelastningsegenskaper. Til slutt utfører vi flere benchmarks for realistiske treningsscenarier for å demonstrere de praktiske implikasjonene på den totale treningskostnaden og ytelsen.

Innfødte SageMaker-datakilder og inndatamoduser

Å lese treningsdata enkelt og fleksibelt på en effektiv måte er en vanlig tilbakevendende bekymring for ML-trening. SageMaker forenkler datainntak med et utvalg av effektive datainntaksmekanismer med høy gjennomstrømning kalt datakilder og deres respektive inndatamoduser. Dette lar deg koble treningskode fra den faktiske datakilden, automatisk montere filsystemer, lese med høy ytelse, enkelt slå på datadeling mellom GPUer og instanser for å aktivere dataparallellisme, og automatisk blande data ved starten av hver epoke.

SageMaker-treningsinntaksmekanismen integreres naturlig med tre AWS-administrerte lagringstjenester:

  • Amazon enkel lagringstjeneste (Amazon S3) er en objektlagringstjeneste som tilbyr bransjeledende skalerbarhet, datatilgjengelighet, sikkerhet og ytelse.
  • Amazon FSx for Luster er en fullt administrert delt lagring med skalerbarheten og ytelsen til det populære Luster-filsystemet. Den er vanligvis knyttet til en eksisterende S3-bøtte.
  • Amazon elastisk filsystem (Amazon EFS) er et generellt, skalerbart og svært tilgjengelig delt filsystem med flere prisnivåer. Amazon EFS er serverløs og vokser og krymper automatisk når du legger til og fjerner filer.

SageMaker-trening lar treningsskriptet ditt få tilgang til datasett som er lagret på Amazon S3, FSx for Lustre eller Amazon EFS, som om det var tilgjengelig på et lokalt filsystem (via et POSIX-kompatibelt filsystemgrensesnitt).

Med Amazon S3 som datakilde kan du velge mellom filmodus, FastFile-modus og rørmodus:

  • Filmodus – SageMaker kopierer et datasett fra Amazon S3 til ML-forekomstlageret, som er vedlagt Amazon Elastic Block Store (Amazon EBS) volum eller NVMe SSD-volum, før treningsskriptet ditt starter.
  • FastFile-modus – SageMaker viser et datasett som ligger i Amazon S3 som et POSIX-filsystem på treningsforekomsten. Datasettfiler strømmes fra Amazon S3 på forespørsel ettersom treningsskriptet ditt leser dem.
  • Rørmodus – SageMaker strømmer et datasett som ligger i Amazon S3 til ML-treningsforekomsten som en Unix-pipe, som strømmer fra Amazon S3 på forespørsel mens treningsskriptet ditt leser dataene fra pipen.

Med FSx for Luster eller Amazon EFS som datakilde, monterer SageMaker filsystemet før treningsskriptet ditt starter.

Treningsinngangskanaler

Når du starter en SageMaker-treningsjobb, kan du spesifisere opptil 20 administrerte inngangskanaler for opplæring. Du kan tenke på kanaler som en abstraksjonsenhet for å fortelle treningsjobben hvordan og hvor dataene som er gjort tilgjengelig for algoritmekoden skal leses fra en filsystembane (f.eks. /opt/ml/input/data/input-channel-name) på ML-forekomsten. De valgte opplæringskanalene fanges opp som en del av metadataene for treningsjobben for å muliggjøre en fullstendig modelllinjesporing for brukstilfeller som reproduserbarhet av treningsjobber eller modellstyringsformål.

For å bruke Amazon S3 som datakilde, definerer du en Treningsinngang for å spesifisere følgende:

  • Inndatamodusen din (Fil-, FastFile- eller Pipe-modus)
  • Distribusjon og stokker konfigurasjon
  • An S3DataType som en av tre metoder for å spesifisere objekter i Amazon S3 som utgjør datasettet ditt:
    • S3Prefix (alle objekter under S3-prefikset)
    • Manifestfil (en liste over S3-objekter)
    • Utvidet manifestfil (en liste over S3-objekter og deres respektive etiketter)

Alternativt, for FSx for Luster eller Amazon EFS, definerer du en FileSystemInput.

Følgende diagram viser fem treningsjobber, hver konfigurert med en annen datakilde og inngangsmoduskombinasjon:

Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Datakilder og inndatamoduser

De følgende delene gir et dypdykk i forskjellene mellom Amazon S3 (Filmodus, FastFile-modus og Pipe-modus), FSx for Lustre og Amazon EFS som SageMaker-inntaksmekanismer.

Amazon S3 filmodus

Filmodus er standard inndatamodus (hvis du ikke spesifiserte en eksplisitt), og den er enklere å bruke. Når du bruker dette inndataalternativet, laster SageMaker ned datasettet fra Amazon S3 til ML treningsforekomstlageret (Amazon EBS eller lokal NVMe avhengig av instanstypen) på dine vegne før modelltrening startes, slik at treningsskriptet kan lese datasettet fra det lokale filsystemet. I dette tilfellet må forekomsten ha nok lagringsplass til å passe hele datasettet.

Du konfigurerer datasettet for filmodus ved å gi enten et S3-prefiks, en manifestfil eller en utvidet manifestfil.

Du bør bruke et S3-prefiks når alle datasettfilene dine er plassert innenfor et vanlig S3-prefiks (undermapper er i orden).

Manifestfilen viser filene som utgjør datasettet ditt. Du bruker vanligvis et manifest når en dataforbehandlingsjobb sender ut en manifestfil, eller når datasettfilene dine er spredt over flere S3-prefikser. Et utvidet manifest er en JSON-linjefil, der hver linje inneholder en liste over attributter, for eksempel en referanse til en fil i Amazon S3, sammen med tilleggsattributter, for det meste etiketter. Brukstilfellene ligner på et manifest.

Filmodus er kompatibel med SageMaker lokal modus (starte en SageMaker treningsbeholder interaktivt på sekunder). For distribuert opplæring kan du dele datasettet på tvers av flere forekomster med ShardedByS3Key alternativet.

Nedlastingshastighet for filmodus avhenger av datasettstørrelse, gjennomsnittlig filstørrelse og antall filer. For eksempel, jo større datasettet er (eller jo flere filer det har), desto lengre er nedlastingsstadiet, der dataressursen til forekomsten forblir effektivt inaktiv. Når du trener med Spot Instances, lastes datasettet ned hver gang jobben gjenopptas etter et Spot-avbrudd. Datanedlasting finner vanligvis sted med omtrent 200 MB/s for store filer (for eksempel 5 minutter/50 GB). Hvorvidt denne oppstartskostnaden er akseptabel, avhenger først og fremst av den totale varigheten av treningsjobben din, fordi en lengre opplæringsfase betyr en forholdsmessig mindre nedlastingsfase.

Amazon S3 FastFile-modus

FastFile-modus eksponerer S3-objekter via et POSIX-kompatibelt filsystemgrensesnitt, som om filene var tilgjengelige på den lokale disken til treningsforekomsten din, og strømmer innholdet deres på forespørsel når data forbrukes av treningsskriptet. Dette betyr at datasettet ditt ikke lenger trenger å passe inn i treningsforekomstens lagringsplass, og du trenger ikke vente på at datasettet skal lastes ned til treningsforekomsten før treningen kan starte.

For å lette dette, viser SageMaker alle objektmetadataene som er lagret under det spesifiserte S3-prefikset før treningsskriptet ditt kjøres. Disse metadataene brukes til å lage en skrivebeskyttet FUSE (filsystem i brukerområdet) som er tilgjengelig for treningsskriptet ditt via /opt/ml/data/training-channel-name. Oppføring av S3-objekter kjører så fort som 5,500 objekter per sekund uavhengig av størrelsen. Dette er mye raskere enn å laste ned filer på forhånd, slik tilfellet er med filmodus. Mens treningsskriptet kjører, kan det liste eller lese filer som om de var tilgjengelige lokalt. Hver leseoperasjon delegeres til FUSE-tjenesten, som fullfører GET-forespørsler til Amazon S3 for å levere det faktiske filinnholdet til den som ringer. Som et lokalt filsystem, behandler FastFile filer som byte, så det er agnostisk for filformater. FastFile-modus kan nå en gjennomstrømning på mer enn én GB/s når du leser store filer sekvensielt ved bruk av flere arbeidere. Du kan bruke FastFile til å lese små filer eller hente tilfeldige byteområder, men du bør forvente en lavere gjennomstrømming for slike tilgangsmønstre. Du kan optimere lesetilgangsmønsteret ditt ved å serialisere mange små filer til større filbeholdere, og lese dem sekvensielt.

FastFile støtter for øyeblikket kun S3-prefikser (ingen støtte for manifest og utvidet manifest), og FastFile-modus er kompatibel med SageMaker lokal modus.

Amazon S3 Pipe-modus

Pipe-modus er en annen strømmemodus som i stor grad er erstattet av den nyere og enklere å bruke FastFile-modusen.

Med Pipe-modus blir data forhåndshentet fra Amazon S3 med høy samtidighet og gjennomstrømning, og strømmet inn i Unix-navngitte FIFO-rør. Hvert rør kan bare leses av en enkelt prosess. En SageMaker-spesifikk utvidelse til TensorFlow praktisk integrerer Pipe-modus i den opprinnelige TensorFlow-datalasteren for streaming av tekst, TFRecords eller RecordIO filformater. Rørmodus støtter også administrert deling og stokking av data.

FSx for Luster

FSx for Luster kan skaleres til hundrevis av GB/s med gjennomstrømning og millioner av IOPS med filhenting med lav latens.

Når du starter en treningsjobb, monterer SageMaker filsystemet FSx for Luster til filsystemet for treningsforekomster, og starter deretter treningsskriptet ditt. Selve monteringen er en relativt rask operasjon som ikke avhenger av størrelsen på datasettet som er lagret i FSx for Lustre.

I mange tilfeller oppretter du et FSx for Luster-filsystem og koble den til en S3-bøtte og prefiks. Når de er koblet til en S3-bøtte som kilde, lastes filer dovent inn i filsystemet etter hvert som treningsskriptet ditt leser dem. Dette betyr at rett etter den første epoken av ditt første treningsløp, kopieres hele datasettet fra Amazon S3 til FSx for Luster-lagring (forutsatt at en epoke er definert som en enkelt full sveip tenkte treningseksemplene, og at den tildelte FSx for Glanslagring er stor nok). Dette muliggjør filtilgang med lav latens for alle påfølgende epoker og opplæringsjobber med samme datasett.

Du kan også forhåndslast filer inn i filsystemet før du starter treningsjobben, noe som lindrer kaldstarten på grunn av lat lasting. Det er også mulig å kjøre flere opplæringsjobber parallelt som betjenes av det samme FSx for Luster-filsystemet. For å få tilgang til FSx for Lustre, må treningsjobben din kobles til en VPC (se VPCConfig-innstillinger), som krever DevOps-oppsett og involvering. For å unngå dataoverføringskostnader bruker filsystemet én enkelt tilgjengelighetssone, og du må spesifisere denne tilgjengelighetssone-IDen når du kjører treningsjobben. Fordi du bruker Amazon S3 som langsiktig datalagring, anbefaler vi at du distribuerer FSx for Luster med Scratch 2-lagring, som et kostnadseffektivt, kortsiktig lagringsvalg for høy gjennomstrømning, og gir en baseline på 200 MB/s og en serie på opptil 1300 MB/s per TB med klargjort lagring.

Med ditt FSx for Luster-filsystem konstant i gang, kan du starte nye treningsjobber uten å vente på at et filsystem skal opprettes, og du trenger ikke å bekymre deg for kaldstarten i løpet av den aller første epoken (fordi filer fortsatt kan bli bufret i filsystemet FSx for Luster). Ulempen i dette scenariet er den ekstra kostnaden forbundet med å holde filsystemet i gang. Alternativt kan du opprette og slette filsystemet før og etter hver treningsjobb (sannsynligvis med skriptet automatisering for å hjelpe), men det tar tid å initialisere et FSx for Luster-filsystem, som er proporsjonalt med antall filer det har (f. for eksempel tar det omtrent en time å indeksere omtrent 2 millioner objekter fra Amazon S3).

Amazon EFS

Vi anbefaler å bruke Amazon EFS hvis treningsdataene dine allerede ligger i Amazon EFS på grunn av brukstilfeller ved siden av ML-trening. For å bruke Amazon EFS som datakilde, må dataene allerede ligge i Amazon EFS før opplæring. SageMaker monterer det angitte Amazon EFS-filsystemet til treningsforekomsten, og starter deretter treningsskriptet ditt. Når du konfigurerer Amazon EFS-filsystemet, må du velge mellom standard ytelsesmodus for generell bruk, som er optimert for ventetid (bra for små filer), og modus for maksimal I/O-ytelse, som kan skaleres til høyere nivåer av samlet gjennomstrømning og operasjoner per sekund (bedre for treningsjobber med mange I/O-arbeidere). For å lære mer, se Bruk av riktig ytelsesmodus.

I tillegg kan du velge mellom to målte gjennomstrømningsalternativer: bursting throughput, og provisioned throughput. Bursting-gjennomstrømning for et 1 TB-filsystem gir en grunnlinje på 150 MB/s, samtidig som den kan eksplodere til 300 MB/s i en tidsperiode på 12 timer om dagen. Hvis du trenger høyere grunnlinjegjennomstrømning, eller opplever at du går tom for burst-kreditter for mange ganger, kan du enten øke størrelsen på filsystemet eller bytte til klargjort gjennomstrømning. I klargjort gjennomstrømning betaler du for ønsket baseline-gjennomstrømning opptil maksimalt 3072 MB/s lest.

Treningsjobben din må kobles til en VPC (se VPCConfig-innstillinger) for å få tilgang til Amazon EFS.

Velge den beste datakilden

Den beste datakilden for treningsjobben din avhenger av arbeidsbelastningskarakteristikker som datasettstørrelse, filformat, gjennomsnittlig filstørrelse, opplæringsvarighet, sekvensielt eller tilfeldig datalaster-lesemønster, og hvor raskt modellen din kan konsumere treningsdataene.

Følgende flytskjema gir noen retningslinjer for å hjelpe deg i gang:
Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Når du skal bruke Amazon EFS

Hvis datasettet ditt primært er lagret på Amazon EFS, kan det hende du har en forbehandlings- eller merknadsapplikasjon som bruker Amazon EFS for lagring. Du kan enkelt kjøre en opplæringsjobb konfigurert med en datakanal som peker til Amazon EFS-filsystemet (for mer informasjon, se Fremskynde opplæringen på Amazon SageMaker ved bruk av Amazon FSx for Luster og Amazon EFS-filsystemer). Hvis ytelsen ikke er fullt så god som du forventet, sjekk optimaliseringsalternativene dine med Amazon EFS ytelsesguide, eller vurder andre inndatamoduser.

Bruk filmodus for små datasett

Hvis datasettet er lagret på Amazon S3 og det totale volumet er relativt lite (for eksempel mindre enn 50–100 GB), kan du prøve å bruke filmodus. Overheaden ved å laste ned et datasett på 50 GB kan variere basert på det totale antallet filer (for eksempel ca. 5 minutter hvis de er delt inn i 100 MB-skår). Hvorvidt denne oppstartskostnaden er akseptabel, avhenger først og fremst av den totale varigheten av treningsjobben din, fordi en lengre opplæringsfase betyr en forholdsmessig mindre nedlastingsfase.

Serialisere mange små filer sammen

Hvis datasettstørrelsen er liten (mindre enn 50–100 GB), men består av mange små filer (mindre enn 50 MB), øker nedlastingskostnadene for filmodus, fordi hver fil må lastes ned individuelt fra Amazon S3 til treningsforekomstvolum. For å redusere denne overheaden, og for å øke hastigheten på datagjennomgang generelt, bør du vurdere å serialisere grupper av mindre filer til færre større filbeholdere (som 150 MB per fil) ved å bruke filformater som f.eks. TFRekord for TensorFlow, WebDataset for PyTorch, eller RecordIO for MXNet. Disse formatene krever at datalasteren itererer gjennom eksempler sekvensielt. Du kan fortsatt stokke dataene dine ved å tilfeldig omorganisere listen over TFRecord-filer etter hver epoke, og ved å tilfeldig prøve data fra en lokal shuffle-buffer (se følgende TensorFlow eksempel).

Når skal du bruke FastFile-modus

For større datasett med større filer (mer enn 50 MB), er det første alternativet å prøve FastFile-modus, som er enklere å bruke enn FSx for Luster fordi det ikke krever å opprette et filsystem eller koble til en VPC. FastFile-modus er ideell for store filbeholdere (mer enn 150 MB), og kan også gjøre det bra med filer på mer enn 50 MB. Fordi FastFile-modus gir et POSIX-grensesnitt, støtter den tilfeldig lesing (lesing av ikke-sekvensielle byteområder). Dette er imidlertid ikke det ideelle brukstilfellet, og gjennomstrømningen din vil sannsynligvis være lavere enn med de sekvensielle avlesningene. Men hvis du har en relativt stor og beregningsintensiv ML-modell, kan FastFile-modus fortsatt være i stand til å mette den effektive båndbredden til treningsrørledningen og ikke resultere i en I/O-flaskehals. Du må eksperimentere og se. Heldigvis er det like enkelt å bytte fra filmodus til FastFile (og tilbake) som å legge til (eller fjerne) input_mode='FastFile' parameter mens du definerer inngangskanalen din ved å bruke SageMaker Python SDK:

sagemaker.inputs.TrainingInput(S3_INPUT_FOLDER, input_mode='FastFile') 

Ingen annen kode eller konfigurasjon trenger å endres.

Når du skal bruke FSx for Luster

Hvis datasettet ditt er for stort for filmodus, eller har mange små filer (som du ikke kan serialisere enkelt), eller du har et tilfeldig lesetilgangsmønster, er FSx for Luster et godt alternativ å vurdere. Filsystemet skaleres til hundrevis av GB/s med gjennomstrømning og millioner av IOPS, noe som er ideelt når du har mange små filer. Men som allerede diskutert tidligere, vær oppmerksom på kaldstartproblemene på grunn av lat lasting, og kostnadene ved å sette opp og initialisere FSx for Luster-filsystemet.

Kostnadshensyn

For de fleste ML-treningsjobber, spesielt jobber som bruker GPUer eller spesialbygde ML-brikker, er mesteparten av kostnadene for å trene ML-treningsinstansens fakturerbare sekunder. GB lagring per måned, API-forespørsler og klargjort gjennomstrømning er tilleggskostnader som er direkte knyttet til datakildene du bruker.

Lagring GB per måned

Lagring GB per måned kan være betydelig for større datasett, for eksempel videoer, LiDAR-sensordata og AdTech sanntidsbudlogger. For eksempel å lagre 1 TB i Amazon S3 Intelligent-Tiering Frequent Access Tier koster $23 per måned. Å legge til FSx for Luster-filsystemet på toppen av Amazon S3 resulterer i ekstra kostnader. For eksempel, å lage et 1.2 TB filsystem av SSD-støttet Scratch 2-type med datakomprimering deaktivert koster ytterligere $168 per måned ($140/TB/måned).

Med Amazon S3 og Amazon EFS betaler du bare for det du bruker, noe som betyr at du blir belastet i henhold til den faktiske datasettstørrelsen. Med FSx for Lustre belastes du av den tildelte filsystemstørrelsen (minimum 1.2 TB). Når du kjører ML-forekomster med EBS-volumer, belastes Amazon EBS uavhengig av ML-forekomsten. Dette er vanligvis en mye lavere kostnad sammenlignet med kostnadene ved å kjøre instansen. For eksempel, å kjøre en ml.p3.2xlarge-forekomst med et 100 GB EBS-volum i 1 time koster $3.825 for forekomsten og $0.02 for EBS-volumet.

API-forespørsler og klargjort gjennomstrømningskostnad

Mens treningsjobben din går gjennom datasettet, lister og henter den filer ved å sende Amazon S3 API-forespørsler. For eksempel er hver million GET-forespørsler priset til $0.4 (med Intelligent-Tiering-klassen). Du bør ikke forvente noen dataoverføringskostnader for båndbredde inn og ut av Amazon S3, fordi trening foregår i en enkelt tilgjengelighetssone.

Når du bruker en FSx for Luster som er koblet til en S3-bøtte, påløper du Amazon S3 API-forespørselskostnader for å lese data som ennå ikke er bufret i filsystemet, fordi FSx For Luster prokserer forespørselen til Amazon S3 (og bufrer resultatet ). Det er ingen direkte forespørselskostnader for FSx for Luster selv. Når du bruker et FSx for Luster-filsystem, unngå kostnader for dataoverføring på tvers av tilgjengelighetssone ved å kjøre treningsjobben koblet til den samme tilgjengelighetssonen som du klargjorde filsystemet i. Amazon EFS med klargjort gjennomstrømning legger til en ekstra kostnad for mer enn GB per måned.

Ytelsescasestudie

For å demonstrere treningsytelseshensynene nevnt tidligere, utførte vi en serie benchmarks for en realistisk brukstilfelle i datasynsdomenet. Benchmark (og takeaways) fra denne delen er kanskje ikke aktuelt for alle scenarier, og påvirkes av ulike forhåndsbestemte faktorer vi brukte, for eksempel DNN. Vi kjørte tester for 12 kombinasjoner av følgende:

  • Inndatamoduser – FSx for Lustre, Fil-modus, FastFile-modus
  • Datasettstørrelse – Mindre datasett (1 GB), større datasett (54 GB)
  • Filstørrelse – Mindre filer (JPG, ca. 39 KB), Større filer (TFRecord, ca. 110 MB)

For denne casestudien valgte vi de mest brukte inngangsmodusene, og derfor utelot Amazon EFS og Pipe-modus.

Referansemålene for casestudier ble utformet som ende-til-ende SageMaker TensorFlow-treningsjobber på en ml.p3.2xlarge enkelt-GPU-forekomst. Vi valgte den anerkjente ResNet-50 som vår ryggradsmodell for klassifiseringsoppgaven og Caltech-256 som det mindre treningsdatasettet (som vi replikerte 50 ganger for å lage dets større datasettversjon). Vi utførte treningen for en epoke, definert som en enkelt full sveip trodde treningseksemplene.

De følgende grafene viser den totale fakturerbare tiden for SageMaker-opplæringsjobbene for hvert referansescenario. Den totale jobbtiden i seg selv består av nedlasting, opplæring og andre stadier (som oppstart av container og opplasting av trente modellartefakter til Amazon S3). Kortere fakturerbare tider gir raskere og billigere opplæringsjobber.

Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

La oss først diskutere Scenario A og Scenario C, som praktisk demonstrerer ytelsesforskjellen mellom inndatamoduser når datasettet består av mange små filer.

Scenario A (mindre filer, mindre datasett) avslører at treningsjobben med filsystemet FSx for Luster har den minste fakturerbare tiden. Den har den korteste nedlastingsfasen, og treningsfasen er like rask som filmodus, men raskere enn FastFile. FSx for Luster er vinneren i denne enkle epoketesten. Når det er sagt, vurder en lignende arbeidsmengde, men med flere epoker – den relative overheaden til filmodus på grunn av nedlastingsstadiet reduseres etter hvert som flere epoker legges til. I dette tilfellet foretrekker vi filmodus for dens brukervennlighet. I tillegg kan det hende du finner ut at å bruke filmodus og betale for 100 ekstra fakturerbare sekunder er et bedre valg enn å betale for og klargjøre et FSx for Luster-filsystem.

Scenario C (mindre filer, større datasett) viser FSx for Luster som den raskeste modusen, med bare 5,000 sekunders total fakturerbar tid. Den har også det korteste nedlastingsstadiet, fordi montering av FSx for Luster-filsystemet ikke avhenger av antall filer i filsystemet (1.5 millioner filer i dette tilfellet). Nedlastingskostnadene til FastFile er også små; den henter kun metadata for filene som ligger under det spesifiserte S3-bøtteprefikset, mens innholdet i filene leses under treningsstadiet. Filmodus er den tregeste modusen, og bruker 10,000 3 sekunder på å laste ned hele datasettet på forhånd før du starter treningen. Når vi ser på treningsstadiet, viser FSx for Luster og File-modus lignende utmerket ytelse. Når det gjelder FastFile-modus, når du streamer mindre filer direkte fra Amazon SXNUMX, blir overheaden for å sende en ny GET-forespørsel for hver fil betydelig i forhold til den totale varigheten av filoverføringen (til tross for bruk av en svært parallell datalaster med forhåndshentingsbuffer). Dette resulterer i en samlet lavere gjennomstrømning for FastFile-modus, som skaper en I/O-flaskehals for treningsjobben. FSx for Luster er den klare vinneren i dette scenariet.

Scenario B og D vis ytelsesforskjellen på tvers av inndatamoduser når datasettet består av færre større filer. Lesing sekvensielt ved bruk av større filer resulterer vanligvis i bedre I/O-ytelse fordi det tillater effektiv buffering og reduserer antallet I/O-operasjoner.

Scenario B (større filer, mindre datasett) viser lignende treningsfasetid for alle moduser (vitner om at treningen ikke er I/O-bundet). I dette scenariet foretrekker vi FastFile-modus fremfor filmodus på grunn av kortere nedlastingsfase, og foretrekker FastFile-modus fremfor FSx for Luster på grunn av brukervennligheten til førstnevnte.

Scenario D (større filer, større datasett) viser relativt like totale fakturerbare tider for alle tre modusene. Nedlastingsfasen for filmodus er lengre enn for FSx for Luster og FastFile. Filmodus laster ned hele datasettet (54 GB) fra Amazon S3 til treningsforekomsten før treningsstadiet starter. Alle tre modusene bruker lik tid i treningsfasen, fordi alle modusene kan hente data raskt nok og er GPU-bundet. Hvis vi bruker ML-forekomster med ekstra CPU- eller GPU-ressurser, for eksempel ml.p4d.24xlarge, øker den nødvendige data-I/O-gjennomstrømningen for å mette dataressursene. I disse tilfellene kan vi forvente at FastFile og FSx for Luster vellykket skalerer gjennomstrømningen (FSx for Luster-gjennomstrømning avhenger imidlertid av størrelsen på det klargjorte filsystemet). Evnen til filmodus til å skalere gjennomstrømningen avhenger av gjennomstrømmingen til diskvolumet som er koblet til forekomsten. For eksempel er Amazon EBS-støttede forekomster (som ml.p3.2xlarge, ml.p3.8xlarge og ml.p3.16xlarge) begrenset til en maksimal gjennomstrømning på 250 MB/s, mens lokale NVMe-støttede forekomster (som ml. g5.* eller ml.p4d.24xlarge) kan romme en mye større gjennomstrømning.

For å oppsummere, tror vi FastFile er vinneren for dette scenariet fordi det er raskere enn filmodus, og like raskt som FSx for Lustre, men likevel enklere å bruke, koster mindre og kan enkelt skalere opp gjennomstrømmingen etter behov.

I tillegg, hvis vi hadde et mye større datasett (flere TB i størrelse), ville filmodus brukt mange timer på å laste ned datasettet før treningen kunne starte, mens FastFile kunne begynne å trene betydelig raskere.

Ta med din egen datainntak

Den opprinnelige datakilden til SageMaker passer til de fleste, men ikke alle mulige ML-treningsscenarier. Situasjonene når du kanskje trenger å se etter andre datainntaksalternativer kan inkludere å lese data direkte fra et tredjeparts lagringsprodukt (forutsatt at en enkel og rettidig eksport til Amazon S3 ikke er mulig), eller å ha et sterkt krav til samme opplæring skript for å kjøre uendret på både SageMaker og Amazon Elastic Compute Cloud (Amazon EC2) eller Amazon Elastic Kubernetes-tjeneste (Amazon EKS). Du kan løse disse tilfellene ved å implementere datainntaksmekanismen din i opplæringsskriptet. Denne mekanismen er ansvarlig for å lese datasett fra eksterne datakilder inn i opplæringsforekomsten. For eksempel TFRecordDataset av TensorFlow-ene tf.data bibliotek kan lese direkte fra Amazon S3-lagring.

Hvis datainntaksmekanismen din trenger å ringe noen AWS-tjenester, for eksempel Amazon Relational Database Service (Amazon RDS), sørg for at AWS identitets- og tilgangsadministrasjon (IAM) rollen til treningsjobben din inkluderer de relevante IAM-retningslinjene. Hvis datakilden ligger i Amazon Virtual Private Cloud (Amazon VPC), må du kjøre treningsjobben koblet til samme VPC.

Når du administrerer datasettinntak selv, kan ikke SageMaker-linjesporing automatisk logge datasettene som brukes under trening. Vurder derfor alternative mekanismer, som treningsjobbkoder eller hyperparametre, for å fange opp relevante metadata.

konklusjonen

Å velge riktig SageMaker treningsdatakilde kan ha stor innvirkning på hastigheten, brukervennligheten og kostnadene ved å trene ML-modeller. Bruk det medfølgende flytskjemaet for å komme raskt i gang, observere resultatene og eksperimentere med ytterligere konfigurasjon etter behov. Husk fordelene, ulempene og begrensningene til hver datakilde, og hvor godt de passer til treningsjobbens individuelle krav. Ta kontakt med en AWS-kontakt for mer informasjon og assistanse.


Om forfatterne

Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.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.

Velg den beste datakilden for din Amazon SageMaker-opplæringsjobb PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.Dr. Alexander Arzhanov er en AI/ML Specialist Solutions Architect basert i Frankfurt, Tyskland. Han hjelper AWS-kunder med å designe og distribuere ML-løsningene deres i EMEA-regionen. Før han begynte i AWS, forsket Alexander på opprinnelsen til tunge elementer i universet vårt og ble lidenskapelig opptatt av ML etter å ha brukt det i sine store vitenskapelige beregninger.

Tidstempel:

Mer fra AWS maskinlæring