Vælg den bedste datakilde til dit Amazon SageMaker-uddannelsesjob

Amazon SageMaker er en administreret tjeneste, der gør det nemt at bygge, træne og implementere maskinlæringsmodeller (ML). Dataforskere bruger SageMaker træningsjob til nemt at træne ML-modeller; du behøver ikke bekymre dig om at administrere computerressourcer, og du betaler kun for den faktiske træningstid. Dataindtagelse er en integreret del af enhver træningspipeline, og SageMaker træningsjob understøtter en række forskellige datalagrings- og inputtilstande, der passer til en bred vifte af træningsopgaver.

Dette indlæg hjælper dig med at vælge den bedste datakilde til din SageMaker ML træningsbrug. Vi introducerer de datakilders muligheder, som SageMaker-uddannelsesjob understøtter indbygget. For hver datakilde og inputtilstand skitserer vi dens brugervenlighed, ydeevnekarakteristika, omkostninger og begrænsninger. For at hjælpe dig hurtigt i gang giver vi diagrammet et eksempel på beslutningsflow, som du kan følge baseret på dine vigtigste arbejdsbyrdekarakteristika. Til sidst udfører vi adskillige benchmarks for realistiske træningsscenarier for at demonstrere de praktiske konsekvenser for de samlede træningsomkostninger og præstationer.

Indbyggede SageMaker-datakilder og inputtilstande

At læse træningsdata let og fleksibelt på en effektiv måde er en almindelig tilbagevendende bekymring for ML-træning. SageMaker forenkler dataindtagelse med et udvalg af effektive dataindtagelsesmekanismer med høj kapacitet kaldet datakilder og deres respektive inputtilstande. Dette giver dig mulighed for at afkoble træningskode fra den faktiske datakilde, automatisk montere filsystemer, læse med høj ydeevne, nemt aktivere datasharding mellem GPU'er og instanser for at aktivere dataparallelisme og automatisk blande data i starten af ​​hver epoke.

SageMaker-træningsindtagelsesmekanismen integreres naturligt med tre AWS-administrerede lagertjenester:

• Amazon Simple Storage Service (Amazon S3) er en objektlagringstjeneste, der tilbyder brancheførende skalerbarhed, datatilgængelighed, sikkerhed og ydeevne.
• Amazon FSx til Luster er et fuldt administreret delt lager med skalerbarheden og ydeevnen fra det populære Luster-filsystem. Det er normalt knyttet til en eksisterende S3-spand.
• Amazon Elastic File System (Amazon EFS) er et skalerbart og meget tilgængeligt delt filsystem til generelle formål med flere prisniveauer. Amazon EFS er serverløs og vokser og krymper automatisk, når du tilføjer og fjerner filer.

SageMaker-træning giver dit træningsscript adgang til datasæt gemt på Amazon S3, FSx for Lustre eller Amazon EFS, som om det var tilgængeligt på et lokalt filsystem (via en POSIX-kompatibel filsystemgrænseflade).

Med Amazon S3 som datakilde kan du vælge mellem filtilstand, hurtigfiltilstand og rørtilstand:

• Filtilstand – SageMaker kopierer et datasæt fra Amazon S3 til ML-instanslageret, som er en vedhæftet Amazon Elastic Block Store (Amazon EBS) volumen eller NVMe SSD volumen, før dit træningsscript starter.
• FastFile-tilstand – SageMaker afslører et datasæt, der findes i Amazon S3, som et POSIX-filsystem på træningsinstansen. Datasætfiler streames fra Amazon S3 efter behov, efterhånden som dit træningsscript læser dem.
• Rørtilstand – SageMaker streamer et datasæt, der ligger i Amazon S3, til ML-træningsinstansen som en Unix-pipe, der streamer fra Amazon S3 efter behov, mens dit træningsscript læser dataene fra pipen.

Med FSx for Luster eller Amazon EFS som datakilde monterer SageMaker filsystemet før dit træningsscript starter.

Træning af inputkanaler

Når du starter et SageMaker-træningsjob, kan du angive op til 20 administrerede træningsinputkanaler. Du kan tænke på kanaler som en abstraktionsenhed til at fortælle træningsjobbet, hvordan og hvor de data, der er gjort tilgængelige for algoritmekoden, skal læses fra en filsystemsti (f.eks. /opt/ml/input/data/input-channel-name) på ML-instansen. De udvalgte træningskanaler fanges som en del af træningsjob-metadataene for at muliggøre en komplet modelafstamningssporing til brugstilfælde, såsom reproducerbarhed af træningsjob eller modelstyringsformål.

For at bruge Amazon S3 som din datakilde, definerer du en Træningsinput at specificere følgende:

• Din inputtilstand (Fil-, FastFile- eller Pipe-tilstand)
• Distribution , blander konfiguration
• An S3DataType som en af ​​tre metoder til at specificere objekter i Amazon S3, der udgør dit datasæt:
  • S3Prefix (alle objekter under S3-præfikset)
  • Manifest fil (en liste over S3-objekter)
  • Udvidet 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 træningsjob, der hver er konfigureret med en forskellig datakilde og inputtilstandskombination:

Datakilder og inputtilstande

De følgende afsnit giver et dybt dyk ned i forskellene mellem Amazon S3 (Filtilstand, FastFile-tilstand og Pipe-tilstand), FSx for Lustre og Amazon EFS som SageMaker-indtagelsesmekanismer.

Amazon S3 filtilstand

Filtilstand er standardindtastningstilstanden (hvis du ikke eksplicit har angivet en), og den er mere ligetil at bruge. Når du bruger denne inputmulighed, downloader SageMaker datasættet fra Amazon S3 til ML-træningsinstanslageret (Amazon EBS eller lokalt NVMe afhængigt af instanstypen) på dine vegne, før du starter modeltræning, så træningsscriptet kan læse datasættet fra det lokale filsystem. I dette tilfælde skal instansen have nok lagerplads til at passe til hele datasættet.

Du konfigurerer datasættet til filtilstand ved at angive enten et S3-præfiks, en manifestfil eller en udvidet manifestfil.

Du bør bruge et S3-præfiks, når alle dine datasætfiler er placeret inden for et fælles S3-præfiks (undermapper er okay).

Manifestfilen viser de filer, der består af dit datasæt. Du bruger typisk et manifest, når et dataforbehandlingsjob udsender en manifestfil, eller når dine datasætfiler er spredt over flere S3-præfikser. Et udvidet manifest er en JSON-linjefil, hvor hver linje indeholder en liste over attributter, såsom en reference til en fil i Amazon S3, sammen med yderligere attributter, for det meste etiketter. Dens anvendelsestilfælde ligner dem for et manifest.

Filtilstand er kompatibel med SageMaker lokal tilstand (starter en SageMaker træningsbeholder interaktivt på få sekunder). For distribueret træning kan du dele datasættet på tværs af flere forekomster med ShardedByS3Key valgmulighed.

Filtilstands downloadhastighed afhænger af datasætstørrelse, gennemsnitlig filstørrelse og antal filer. For eksempel, jo større datasættet er (eller jo flere filer det har), desto længere er downloadfasen, hvor instansens computerressource forbliver reelt inaktiv. Når du træner med Spot Instances, downloades datasættet, hver gang jobbet genoptages efter en Spot-afbrydelse. Dataoverførsel foregår typisk med cirka 200 MB/s for store filer (f.eks. 5 minutter/50 GB). Hvorvidt denne startoverhead er acceptabel afhænger primært af den samlede varighed af dit træningsjob, fordi en længere træningsfase betyder en forholdsmæssigt mindre downloadfase.

Amazon S3 FastFile-tilstand

FastFile-tilstand afslører S3-objekter via en POSIX-kompatibel filsystemgrænseflade, som om filerne var tilgængelige på den lokale disk i din træningsinstans, og streamer deres indhold efter behov, når data forbruges af træningsscriptet. Dette betyder, at dit datasæt ikke længere behøver at passe ind i træningsinstansens lagerplads, og du behøver ikke vente på, at datasættet bliver downloadet til træningsforekomsten, før træningen kan starte.

For at lette dette oplister SageMaker alle objektmetadata, der er gemt under det angivne S3-præfiks, før dit træningsscript kører. Disse metadata bruges til at oprette en skrivebeskyttet FUSE (filsystem i brugerrum) der er tilgængelig for dit træningsscript via /opt/ml/data/training-channel-name. At liste S3-objekter kører så hurtigt som 5,500 objekter i sekundet uanset deres størrelse. Dette er meget hurtigere end at downloade filer på forhånd, som det er tilfældet med filtilstand. Mens dit træningsscript kører, kan det liste eller læse filer, som om de var tilgængelige lokalt. Hver læseoperation delegeres til FUSE-tjenesten, som proxyer GET-anmodninger til Amazon S3 for at levere det faktiske filindhold til den, der ringer. Som et lokalt filsystem behandler FastFile filer som bytes, så det er agnostisk over for filformater. FastFile-tilstand kan nå en kapacitet på mere end én GB/s, når du læser store filer sekventielt ved brug af flere arbejdere. Du kan bruge FastFile til at læse små filer eller hente tilfældige byte-intervaller, men du bør forvente en lavere gennemstrømning for sådanne adgangsmønstre. Du kan optimere dit læseadgangsmønster ved at serialisere mange små filer til større filbeholdere og læse dem sekventielt.

FastFile understøtter i øjeblikket kun S3-præfikser (ingen understøttelse af manifest og augmented manifest), og FastFile-tilstand er kompatibel med SageMaker lokal tilstand.

Amazon S3 Pipe-tilstand

Pipe-tilstand er en anden streaming-tilstand, der stort set er erstattet af den nyere og nemmere at bruge FastFile-tilstand.

Med Pipe-tilstand hentes data på forhånd fra Amazon S3 med høj samtidighed og gennemstrømning og streames til Unix-navngivne FIFO-rør. Hvert rør kan kun læses ved en enkelt proces. En SageMaker-specifik udvidelse til TensorFlow bekvemt integrerer Pipe-tilstand i den indbyggede TensorFlow-dataindlæser til streaming af tekst, TFRecords eller RecordIO filformater. Pipe-tilstand understøtter også administreret sharding og blanding af data.

FSx for Luster

FSx for Luster kan skaleres til hundredvis af GB/s gennemstrømning og millioner af IOPS med filhentning med lav latens.

Når du starter et træningsjob, monterer SageMaker FSx for Luster-filsystemet til træningsinstansens filsystem og starter derefter dit træningsscript. Selve monteringen er en relativt hurtig operation, der ikke afhænger af størrelsen af ​​datasættet, der er gemt i FSx for Lustre.

I mange tilfælde opretter du et FSx for Luster-filsystem og link det til en S3-spand og præfiks. Når de er knyttet til en S3-bøtte som kilde, indlæses filer dovent i filsystemet, efterhånden som dit træningsscript læser dem. Det betyder, at lige efter den første epoke af dit første træningsløb, kopieres hele datasættet fra Amazon S3 til FSx for Luster-lagring (forudsat at en epoke defineres som en enkelt fuld sweep tænkte træningseksemplerne, og at den allokerede FSx for Glanslageret er stort nok). Dette muliggør filadgang med lav latens for alle efterfølgende epoker og træningsjob med det samme datasæt.

Du kan også forudindlæs filer i filsystemet inden træningsjobbet påbegyndes, hvilket afhjælper koldstarten pga. doven læsning. Det er også muligt at køre flere træningsjob parallelt, der betjenes af det samme FSx for Luster-filsystem. For at få adgang til FSx for Lustre skal dit træningsjob oprette forbindelse til en VPC (se VPCConfig-indstillinger), hvilket kræver DevOps-opsætning og involvering. For at undgå omkostninger til dataoverførsel bruger filsystemet en enkelt tilgængelighedszone, og du skal angive dette tilgængelighedszone-id, når du kører træningsjobbet. Fordi du bruger Amazon S3 som din langsigtede datalagring, anbefaler vi, at du implementerer din FSx for Luster med Scratch 2-lagring, som et omkostningseffektivt, kortsigtet lagervalg til høj gennemstrømning, der giver en baseline på 200 MB/s og en burst på op til 1300 MB/s pr. TB klargjort lagerplads.

Med dit FSx for Luster-filsystem konstant kørende, kan du starte nye træningsjob uden at vente på, at et filsystem bliver oprettet, og du behøver ikke bekymre dig om koldstarten i løbet af den allerførste epoke (fordi filer stadig kan cachelagres i FSx for Luster-filsystemet). Ulempen i dette scenarie er de ekstra omkostninger forbundet med at holde filsystemet kørende. Alternativt kan du oprette og slette filsystemet før og efter hvert træningsjob (sandsynligvis med scriptet automatisering til hjælp), men det tager tid at initialisere et FSx for Luster-filsystem, som er proportionalt med antallet af filer, det indeholder (f. for eksempel tager det cirka en time at indeksere cirka 2 millioner objekter fra Amazon S3).

Amazon EFS

Vi anbefaler at bruge Amazon EFS, hvis dine træningsdata allerede findes i Amazon EFS på grund af brugssager udover ML-træning. For at bruge Amazon EFS som datakilde skal dataene allerede ligge i Amazon EFS inden træning. SageMaker monterer det angivne Amazon EFS-filsystem til træningsinstansen og starter derefter dit træningsscript. Når du konfigurerer Amazon EFS-filsystemet, skal du vælge mellem standardtilstanden General Purpose ydeevne, som er optimeret til latency (god til små filer), og Max I/O-ydeevnetilstand, som kan skaleres til højere niveauer af aggregeret gennemløb og operationer pr. sekund (bedre til træningsjob med mange I/O-arbejdere). For at lære mere, se Brug af den rigtige ydelsestilstand.

Derudover kan du vælge mellem to målte gennemløbsmuligheder: bursting-gennemløb og klargjort gennemløb. Bursting-gennemstrømning for et 1 TB filsystem giver en baseline på 150 MB/s, mens det er i stand til at eksplodere til 300 MB/s i en tidsperiode på 12 timer om dagen. Hvis du har brug for højere baseline-gennemstrømning, eller finder dig selv ved at løbe tør for burst-kreditter for mange gange, kan du enten øge størrelsen på filsystemet eller skifte til klargjort gennemløb. I provisioned throughput betaler du for den ønskede baseline-gennemstrømning op til maksimalt 3072 MB/s læst.

Dit træningsjob skal oprette forbindelse til en VPC (se VPCConfig-indstillinger) for at få adgang til Amazon EFS.

Valg af den bedste datakilde

Den bedste datakilde til dit træningsjob afhænger af arbejdsbelastningskarakteristika som datasætstørrelse, filformat, gennemsnitlig filstørrelse, træningsvarighed, sekventielt eller tilfældigt dataindlæser-læsemønster, og hvor hurtigt din model kan forbruge træningsdataene.

Følgende rutediagram giver nogle retningslinjer, der kan hjælpe dig i gang:

Hvornår skal man bruge Amazon EFS

Hvis dit datasæt primært er gemt på Amazon EFS, har du muligvis en forbehandlings- eller annotationsapplikation, der bruger Amazon EFS til opbevaring. Du kan nemt køre et træningsjob konfigureret med en datakanal, der peger på Amazon EFS-filsystemet (for mere information, se Fremskynd træningen på Amazon SageMaker ved at bruge Amazon FSx til Luster og Amazon EFS filsystemer). Hvis ydeevnen ikke er helt så god, som du forventede, skal du tjekke dine optimeringsmuligheder med Amazon EFS præstationsguide, eller overvej andre inputtilstande.

Brug filtilstand til små datasæt

Hvis datasættet er gemt på Amazon S3, og dets samlede volumen er relativt lille (f.eks. mindre end 50-100 GB), prøv at bruge filtilstand. Overheaden ved at downloade et datasæt på 50 GB kan variere baseret på det samlede antal filer (f.eks. ca. 5 minutter, hvis de er opdelt i 100 MB-shards). Hvorvidt denne startoverhead er acceptabel afhænger primært af den samlede varighed af dit træningsjob, fordi en længere træningsfase betyder en forholdsmæssigt mindre downloadfase.

Serialisering af mange små filer sammen

Hvis din datasætstørrelse er lille (mindre end 50-100 GB), men består af mange små filer (mindre end 50 MB), vokser download-overhead for filtilstand, fordi hver fil skal downloades individuelt fra Amazon S3 til mængde af træningsinstanser. For at reducere denne overhead og for at fremskynde datagennemgangen generelt, overveje at serialisere grupper af mindre filer til færre større filbeholdere (såsom 150 MB pr. fil) ved at bruge filformater som f.eks. TFRecord til TensorFlow, WebDataset for PyTorch, eller RecordIO til MXNet. Disse formater kræver, at din dataindlæser gentager eksemplerne sekventielt. Du kan stadig blande dine data ved tilfældigt at omarrangere listen over TFRecord-filer efter hver epoke og ved tilfældigt at udtage data fra en lokal blandebuffer (se følgende TensorFlow eksempel).

Hvornår skal man bruge FastFile-tilstand

For større datasæt med større filer (mere end 50 MB), er den første mulighed at prøve FastFile-tilstand, som er mere ligetil at bruge end FSx for Luster, fordi det ikke kræver at oprette et filsystem eller oprette forbindelse til en VPC. FastFile-tilstand er ideel til store filcontainere (mere end 150 MB), og kan også klare sig godt med filer på mere end 50 MB. Fordi FastFile-tilstand giver en POSIX-grænseflade, understøtter den tilfældige læsninger (læsning af ikke-sekventielle byte-intervaller). Dette er dog ikke den ideelle anvendelse, og din gennemstrømning ville sandsynligvis være lavere end med de sekventielle læsninger. Men hvis du har en relativt stor og beregningsintensiv ML-model, kan FastFile-tilstand muligvis stadig mætte den effektive båndbredde af træningspipelinen og ikke resultere i en I/O-flaskehals. Du bliver nødt til at eksperimentere og se. Heldigvis er det lige så nemt at skifte fra filtilstand til FastFile (og tilbage) som at tilføje (eller fjerne) input_mode='FastFile' parameter, mens du definerer din inputkanal ved hjælp af SageMaker Python SDK:

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

Ingen anden kode eller konfiguration skal ændres.

Hvornår skal man bruge FSx til Luster

Hvis dit datasæt er for stort til filtilstand eller har mange små filer (som du ikke nemt kan serialisere), eller du har et tilfældigt læseadgangsmønster, er FSx for Luster en god mulighed at overveje. Dens filsystem skalerer til hundredvis af GB/s af gennemløb og millioner af IOPS, hvilket er ideelt, når du har mange små filer. Men som allerede diskuteret tidligere, skal du være opmærksom på koldstartsproblemerne på grund af doven indlæsning og omkostningerne ved opsætning og initialisering af FSx for Luster-filsystemet.

Omkostningsovervejelser

For størstedelen af ​​ML-træningsjob, især job, der bruger GPU'er eller specialbyggede ML-chips, er de fleste af omkostningerne ved at træne ML-træningsinstansens fakturerbare sekunder. Storage GB pr. måned, API-anmodninger og klargjort gennemløb er ekstra omkostninger, der er direkte forbundet med de datakilder, du bruger.

Storage GB om måneden

Storage GB pr. måned kan være betydelig for større datasæt, såsom videoer, LiDAR-sensordata og AdTech-budgivningslogfiler i realtid. For eksempel opbevaring af 1 TB i Amazon S3 Intelligent-Tiering Frequent Access Tier koster $23 om måneden. Tilføjelse af FSx for Luster-filsystemet oven på Amazon S3 resulterer i ekstra omkostninger. For eksempel at oprette et 1.2 TB filsystem af SSD-støttet Scratch 2-type med datakomprimering deaktiveret koster yderligere $168 pr. måned ($140/TB/måned).

Med Amazon S3 og Amazon EFS betaler du kun for det, du bruger, hvilket betyder, at du bliver opkrævet i henhold til den faktiske datasætstørrelse. Med FSx for Lustre bliver du opkrævet af den leverede filsystemstørrelse (minimum 1.2 TB). Når du kører ML-instanser med EBS-volumener, debiteres Amazon EBS uafhængigt af ML-instansen. Dette er normalt en meget lavere omkostning sammenlignet med omkostningerne ved at køre instansen. For eksempel koster det at køre en ml.p3.2xlarge instans med en 100 GB EBS-volumen i 1 time 3.825 USD for instansen og 0.02 USD for EBS-volumen.

API-anmodninger og leveringsomkostninger

Mens dit træningsjob knaser gennem datasættet, lister og henter det filer ved at sende Amazon S3 API-anmodninger. For eksempel er hver million GET-anmodninger prissat til $0.4 (med Intelligent-Tiering-klassen). Du skal ikke forvente nogen dataoverførselsomkostninger for båndbredde ind og ud af Amazon S3, fordi træningen foregår i en enkelt tilgængelighedszone.

Når du bruger en FSx for Luster, der er knyttet til en S3-bucket, pådrager du dig Amazon S3 API-anmodningsomkostninger for at læse data, der endnu ikke er cachelagret i filsystemet, fordi FSx For Luster proxerer anmodningen til Amazon S3 (og cacher resultatet ). Der er ingen direkte anmodningsomkostninger for FSx for Luster selv. Når du bruger et FSx for Luster-filsystem, skal du undgå omkostninger til dataoverførsel på tværs af tilgængelighedszoner ved at køre dit træningsjob forbundet til den samme tilgængelighedszone, som du klargjorde filsystemet i. Amazon EFS med klargjort gennemløb tilføjer en ekstra omkostning til consdier ud over GB om måneden.

Performance casestudie

For at demonstrere de træningspræstationsovervejelser, der er nævnt tidligere, udførte vi en række benchmarks for en realistisk use case i computer vision-domænet. Benchmark (og takeaways) fra dette afsnit er muligvis ikke anvendeligt til alle scenarier og påvirkes af forskellige forudbestemte faktorer, som vi brugte, såsom DNN. Vi kørte test for 12 kombinationer af følgende:

• Inputtilstande – FSx til Lustre, File mode, FastFile mode
• Datasæt størrelse – Mindre datasæt (1 GB), større datasæt (54 GB)
• Filstørrelse – Mindre filer (JPG'er, ca. 39 KB), Større filer (TFRecord, ca. 110 MB)

Til dette casestudie valgte vi de mest udbredte inputtilstande og udelod derfor Amazon EFS og Pipe mode.

Casestudiets benchmarks blev designet som end-to-end SageMaker TensorFlow træningsjob på en ml.p3.2xlarge single-GPU instans. Vi valgte den berømte ResNet-50 som vores rygradsmodel for klassificeringsopgaven og Caltech-256 som det mindre træningsdatasæt (som vi gentog 50 gange for at skabe dets større datasætversion). Vi udførte træningen i en epoke, defineret som en enkelt fuld sweep tænkte træningseksemplerne.

Følgende grafer viser den samlede fakturerbare tid for SageMaker-uddannelsesjob for hvert benchmarkscenario. Selve den samlede jobtid består af download, træning og andre stadier (såsom containeropstart og upload af trænede modelartefakter til Amazon S3). Kortere faktureringstider giver hurtigere og billigere uddannelsesjob.

Lad os først diskutere Scenario A og Scenario C, som bekvemt demonstrerer ydeevneforskellen mellem inputtilstande, når datasættet består af mange små filer.

Scenario A (mindre filer, mindre datasæt) afslører, at træningsjob med filsystemet FSx for Luster har den mindste fakturerbare tid. Den har den korteste downloadfase, og dens træningsfase er lige så hurtig som filtilstand, men hurtigere end FastFile. FSx for Luster er vinderen i denne enkelt epoke test. Når det er sagt, så overvej en lignende arbejdsbyrde, men med flere epoker - den relative overhead af filtilstand på grund af downloadfasen falder, efterhånden som flere epoker tilføjes. I dette tilfælde foretrækker vi filtilstand for dens brugervenlighed. Derudover vil du måske opdage, at brug af filtilstand og betaling for 100 ekstra fakturerbare sekunder er et bedre valg end at betale for og klargøre et FSx for Luster-filsystem.

Scenario C (mindre filer, større datasæt) viser FSx for Luster som den hurtigste tilstand med kun 5,000 sekunders samlet fakturerbar tid. Det har også den korteste downloadfase, fordi montering af FSx for Luster-filsystemet ikke afhænger af antallet af filer i filsystemet (1.5 millioner filer i dette tilfælde). Overheadomkostningerne til at downloade FastFile er også små; den henter kun metadata af filerne, der ligger under det angivne S3-bucket-præfiks, mens indholdet af filerne læses under træningsfasen. Filtilstand er den langsomste tilstand, der bruger 10,000 sekunder på at downloade hele datasættet på forhånd, inden træningen påbegyndes. Når vi ser på træningsstadiet, viser FSx for Luster og File-tilstand lignende fremragende præstationer. Med hensyn til FastFile-tilstand, når mindre filer streames direkte fra Amazon S3, bliver overheaden for afsendelse af en ny GET-anmodning for hver fil betydelig i forhold til den samlede varighed af filoverførslen (på trods af brug af en meget parallel dataindlæser med forudhentningsbuffer). Dette resulterer i en samlet lavere gennemstrømning for FastFile-tilstand, som skaber en I/O-flaskehals for træningsjobbet. FSx for Luster er den klare vinder i dette scenarie.

Scenarier B og D vis ydeevneforskellen på tværs af inputtilstande, når datasættet består af færre større filer. Læsning sekventielt ved brug af større filer resulterer typisk i bedre I/O-ydeevne, fordi det tillader effektiv buffering og reducerer antallet af I/O-operationer.

Scenario B (større filer, mindre datasæt) viser lignende træningsfasetid for alle tilstande (vidner om, at træningen ikke er I/O-bundet). I dette scenarie foretrækker vi FastFile-tilstand frem for filtilstand på grund af kortere download-fase, og foretrækker FastFile-tilstand frem for FSx for Luster på grund af den brugervenlige førstnævnte.

Scenarie D (større filer, større datasæt) viser relativt ens samlede fakturerbare tider for alle tre tilstande. Downloadfasen af ​​filtilstand er længere end den for FSx for Luster og FastFile. Filtilstand downloader hele datasættet (54 GB) fra Amazon S3 til træningsinstansen, før træningsstadiet påbegyndes. Alle tre tilstande bruger samme tid i træningsfasen, fordi alle tilstande kan hente data hurtigt nok og er GPU-bundne. Hvis vi bruger ML-instanser med yderligere CPU- eller GPU-ressourcer, såsom ml.p4d.24xlarge, vokser den nødvendige data-I/O-gennemstrømning til at mætte computerressourcerne. I disse tilfælde kan vi forvente, at FastFile og FSx for Luster succesfuldt skalerer deres gennemstrømning (fsx for Luster-gennemstrømning afhænger dog af den klargjorte filsystemstørrelse). Filtilstandens evne til at skalere dens gennemløb afhænger af gennemløbet af den diskvolumen, der er knyttet til instansen. For eksempel er Amazon EBS-støttede instanser (som ml.p3.2xlarge, ml.p3.8xlarge og ml.p3.16xlarge) begrænset til en maksimal gennemstrømning på 250 MB/s, hvorimod lokale NVMe-støttede instanser (som ml. g5.* eller ml.p4d.24xlarge) kan rumme et meget større gennemløb.

For at opsummere, mener vi, at FastFile er vinderen for dette scenarie, fordi det er hurtigere end filtilstand og lige så hurtigt som FSx for Lustre, men alligevel mere ligetil at bruge, koster mindre og nemt kan skalere sin gennemstrømning op efter behov.

Derudover, hvis vi havde et meget større datasæt (flere TB'er i størrelse), ville filtilstand bruge mange timer på at downloade datasættet, før træningen kunne starte, hvorimod FastFile kunne begynde at træne betydeligt hurtigere.

Medbring din egen dataindtagelse

SageMakers oprindelige datakilde passer til de fleste, men ikke alle mulige ML-træningsscenarier. De situationer, hvor du muligvis skal lede efter andre muligheder for dataindtagelse, kan omfatte læsning af data direkte fra et tredjepartslagringsprodukt (forudsat at en nem og rettidig eksport til Amazon S3 ikke er mulig), eller at have et stærkt krav om den samme træning script til at køre uændret på både SageMaker og Amazon Elastic Compute Cloud (Amazon EC2) eller Amazon Elastic Kubernetes Service (Amazon EKS). Du kan løse disse tilfælde ved at implementere din dataindtagelsesmekanisme i træningsscriptet. Denne mekanisme er ansvarlig for at læse datasæt fra eksterne datakilder ind i træningsinstansen. For eksempel TFRecordDataset af TensorFlow'erne tf.data bibliotek kan læse direkte fra Amazon S3-lager.

Hvis din dataindtagelsesmekanisme skal ringe til nogen AWS-tjenester, som f.eks Amazon Relationel Database Service (Amazon RDS), sørg for, at AWS identitets- og adgangsstyring (IAM) rolle for dit træningsjob omfatter de relevante IAM-politikker. Hvis datakilden ligger i Amazon Virtual Private Cloud (Amazon VPC), skal du køre dit træningsjob forbundet til den samme VPC.

Når du selv administrerer datasætindtagelse, kan SageMaker lineage tracking ikke automatisk logge de datasæt, der bruges under træning. Overvej derfor alternative mekanismer, såsom træning af jobtags eller hyperparametre, for at fange dine relevante metadata.

Konklusion

At vælge den rigtige SageMaker træningsdatakilde kan have en dybtgående effekt på hastigheden, brugervenligheden og omkostningerne ved at træne ML-modeller. Brug det medfølgende flowchart til at komme hurtigt i gang, observere resultaterne og eksperimentere med yderligere konfiguration efter behov. Husk fordele, ulemper og begrænsninger ved hver datakilde, og hvor godt de passer til dit træningsjobs individuelle krav. Kontakt en AWS-kontakt for yderligere information og assistance.

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.

Dr. Alexander Arzhanov er en AI/ML Specialist Solutions Architect baseret i Frankfurt, Tyskland. Han hjælper AWS-kunder med at designe og implementere deres ML-løsninger på tværs af EMEA-regionen. Før han kom til AWS, forskede Alexander i oprindelsen af ​​tunge grundstoffer i vores univers og voksede passioneret omkring ML efter at have brugt det i sine store videnskabelige beregninger.

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://aws.amazon.com/blogs/machine-learning/choose-the-best-data-source-for-your-amazon-sagemaker-training-job/