Välj den bästa datakällan för ditt Amazon SageMaker-utbildningsjobb

Amazon SageMaker är en hanterad tjänst som gör det enkelt att bygga, träna och distribuera modeller för maskininlärning (ML). Dataforskare använder SageMaker-utbildningsjobb för att enkelt träna ML-modeller; du behöver inte oroa dig för att hantera beräkningsresurser, och du betalar bara för den faktiska träningstiden. Datainmatning är en integrerad del av varje utbildningspipeline, och SageMakers utbildningsjobb stöder en mängd olika datalagrings- och inmatningslägen för att passa ett brett utbud av träningsbelastningar.

Det här inlägget hjälper dig att välja den bästa datakällan för ditt användningsfall för SageMaker ML-träning. Vi introducerar alternativen för datakällor som SageMaker utbildningsjobb stöder inbyggt. För varje datakälla och inmatningsläge beskriver vi dess användarvänlighet, prestandaegenskaper, kostnad och begränsningar. För att hjälpa dig komma igång snabbt tillhandahåller vi diagrammet med ett exempel på beslutsflöde som du kan följa baserat på dina viktigaste arbetsbelastningsegenskaper. Slutligen utför vi flera riktmärken för realistiska träningsscenarier för att visa de praktiska konsekvenserna för den totala utbildningskostnaden och prestanda.

Inbyggda SageMaker-datakällor och inmatningslägen

Att läsa träningsdata enkelt och flexibelt på ett presterande sätt är ett vanligt återkommande problem för ML-träning. SageMaker förenklar datainmatning med ett urval av effektiva dataintagsmekanismer med hög genomströmning som kallas datakällor och deras respektive inmatningslägen. Detta gör att du kan koppla bort träningskoden från den faktiska datakällan, automatiskt montera filsystem, läsa med hög prestanda, enkelt slå på datadelning mellan GPU:er och instanser för att möjliggöra dataparallellism och automatisk blanda data i början av varje epok.

SageMakers träningsintagsmekanism integreras naturligt med tre AWS-hanterade lagringstjänster:

• Amazon enkel lagringstjänst (Amazon S3) är en objektlagringstjänst som erbjuder branschledande skalbarhet, datatillgänglighet, säkerhet och prestanda.
• Amazon FSx för Luster är en helt hanterad delad lagring med skalbarhet och prestanda som det populära filsystemet Luster. Den är vanligtvis kopplad till en befintlig S3-skopa.
• Amazon Elastic File System (Amazon EFS) är ett generellt, skalbart och mycket tillgängligt delat filsystem med flera prisnivåer. Amazon EFS är serverlöst och växer och krymper automatiskt när du lägger till och tar bort filer.

SageMaker-träning låter ditt träningsskript komma åt datauppsättningar lagrade på Amazon S3, FSx for Lustre eller Amazon EFS, som om det vore tillgängligt på ett lokalt filsystem (via ett POSIX-kompatibelt filsystemgränssnitt).

Med Amazon S3 som datakälla kan du välja mellan filläge, snabbfilläge och rörläge:

• Filläge – SageMaker kopierar en datauppsättning från Amazon S3 till ML-instanslagringen, som är en bifogad Amazon Elastic Block Store (Amazon EBS) volym eller NVMe SSD-volym, innan ditt träningsskript startar.
• FastFile-läge – SageMaker exponerar en datauppsättning som finns i Amazon S3 som ett POSIX-filsystem på träningsinstansen. Datauppsättningsfiler strömmas från Amazon S3 på begäran när ditt träningsskript läser dem.
• Rörläge – SageMaker strömmar en datauppsättning som finns i Amazon S3 till ML-utbildningsinstansen som en Unix-pipe, som strömmar från Amazon S3 på begäran när ditt träningsskript läser data från pipen.

Med FSx for Luster eller Amazon EFS som datakälla monterar SageMaker filsystemet innan ditt träningsskript startar.

Träning ingångskanaler

När du startar ett SageMaker-utbildningsjobb kan du ange upp till 20 hanterade ingångskanaler för träning. Du kan tänka på kanaler som en abstraktionsenhet för att berätta för träningsjobbet hur och var de data som görs tillgängliga för algoritmkoden ska kunna läsas från en filsystemsökväg (till exempel, /opt/ml/input/data/input-channel-name) på ML-instansen. De utvalda utbildningskanalerna fångas upp som en del av träningsjobbets metadata för att möjliggöra en fullständig modelllinjespårning för användningsfall som reproducerbarhet av utbildningsjobb eller modellstyrningsändamål.

För att använda Amazon S3 som din datakälla definierar du en TrainingInput för att specificera följande:

• Ditt inmatningsläge (File-, FastFile- eller Pipe-läge)
• Fördelning och blanda konfiguration
• An S3DataType som en av tre metoder för att ange objekt i Amazon S3 som utgör din datauppsättning:
  • S3Prefix (alla objekt under S3-prefixet)
  • Manifestfil (en lista över S3-objekt)
  • Förstärkt manifestfil (en lista över S3-objekt och deras respektive etiketter)

Alternativt, för FSx för Luster eller Amazon EFS, definierar du en FileSystemInput.

Följande diagram visar fem träningsjobb, var och en konfigurerad med olika datakälla och inmatningslägeskombinationer:

Datakällor och inmatningslägen

Följande avsnitt ger en djupdykning i skillnaderna mellan Amazon S3 (Filläge, FastFile-läge och Pipe-läge), FSx för Lustre och Amazon EFS som SageMaker-intagsmekanismer.

Amazon S3 filläge

Filläge är standardinmatningsläget (om du inte uttryckligen angav ett), och det är enklare att använda. När du använder det här inmatningsalternativet laddar SageMaker ned datamängden från Amazon S3 till ML-träningsinstanslagringen (Amazon EBS eller lokal NVMe beroende på instanstyp) för din räkning innan modellträning startas, så att träningsskriptet kan läsa datasetet från det lokala filsystemet. I det här fallet måste instansen ha tillräckligt med lagringsutrymme för att passa hela datamängden.

Du konfigurerar datasetet för filläge genom att tillhandahålla antingen ett S3-prefix, en manifestfil eller en utökad manifestfil.

Du bör använda ett S3-prefix när alla dina datauppsättningsfiler finns inom ett vanligt S3-prefix (undermappar är okej).

Manifestfilen listar filerna som utgör din datauppsättning. Du använder vanligtvis ett manifest när ett dataförbearbetningsjobb avger en manifestfil, eller när dina datauppsättningsfiler är spridda över flera S3-prefix. Ett utökat manifest är en JSON-linjefil, där varje rad innehåller en lista med attribut, till exempel en referens till en fil i Amazon S3, tillsammans med ytterligare attribut, mestadels etiketter. Dess användningsfall liknar det för ett manifest.

Filläget är kompatibelt med SageMaker lokalt läge (starta en SageMaker träningsbehållare interaktivt på några sekunder). För distribuerad utbildning kan du dela datauppsättningen över flera instanser med ShardedByS3Key alternativ.

Filläges nedladdningshastighet beror på datauppsättningsstorlek, genomsnittlig filstorlek och antal filer. Till exempel, ju större datauppsättningen är (eller ju fler filer den har), desto längre är nedladdningsstadiet, under vilket instansens beräkningsresurs i praktiken förblir inaktiv. När du tränar med Spot-instanser laddas datasetet ner varje gång jobbet återupptas efter ett Spot-avbrott. Vanligtvis sker datanedladdning med cirka 200 MB/s för stora filer (till exempel 5 minuter/50 GB). Huruvida denna startoverhead är acceptabel beror främst på den totala varaktigheten av ditt träningsjobb, eftersom en längre utbildningsfas innebär en proportionellt mindre nedladdningsfas.

Amazon S3 FastFile-läge

FastFile-läget exponerar S3-objekt via ett POSIX-kompatibelt filsystemgränssnitt, som om filerna var tillgängliga på den lokala disken i din träningsinstans, och strömmar deras innehåll på begäran när data konsumeras av träningsskriptet. Detta innebär att din datauppsättning inte längre behöver passa in i träningsinstansens lagringsutrymme, och du behöver inte vänta på att datauppsättningen laddas ner till träningsinstansen innan träningen kan starta.

För att underlätta detta listar SageMaker all objektmetadata som lagras under det angivna S3-prefixet innan ditt träningsskript körs. Denna metadata används för att skapa en skrivskyddad FUSE (filsystem i användarutrymme) som är tillgängligt för ditt träningsskript via /opt/ml/data/training-channel-name. Att lista S3-objekt går så snabbt som 5,500 3 objekt per sekund oavsett deras storlek. Detta är mycket snabbare än att ladda ner filer i förväg, vilket är fallet med filläge. Medan ditt träningsskript körs kan det lista eller läsa filer som om de vore tillgängliga lokalt. Varje läsoperation delegeras till FUSE-tjänsten, som proxar GET-förfrågningar till Amazon SXNUMX för att leverera det faktiska filinnehållet till den som ringer. Precis som ett lokalt filsystem behandlar FastFile filer som byte, så det är agnostiskt för filformat. FastFile-läget kan nå en genomströmning på mer än en GB/s när du läser stora filer sekventiellt med flera arbetare. Du kan använda FastFile för att läsa små filer eller hämta slumpmässiga byteintervall, men du bör förvänta dig en lägre genomströmning för sådana åtkomstmönster. Du kan optimera ditt läsåtkomstmönster genom att serialisera många små filer till större filbehållare och läsa dem sekventiellt.

FastFile stöder för närvarande endast S3-prefix (inget stöd för manifest och utökat manifest), och FastFile-läget är kompatibelt med SageMaker lokalt läge.

Amazon S3 Pipe-läge

Pipe-läge är ett annat streaming-läge som till stor del ersätts av det nyare och enklare att använda FastFile-läget.

Med Pipe-läge förhämtas data från Amazon S3 med hög samtidighet och genomströmning, och strömmas in i Unix-namngivna FIFO-pipes. Varje rör kan endast läsas av en enda process. En SageMaker-specifik tillägg till TensorFlow bekvämt integrerar Pipe-läge i den inbyggda TensorFlow-dataladdaren för strömmande text, TFRecords eller RecordIO filformat. Pipe-läge stöder även hanterad sönderdelning och blandning av data.

FSx för Luster

FSx for Luster kan skalas till hundratals GB/s genomströmning och miljontals IOPS med låg latens filhämtning.

När du startar ett träningsjobb monterar SageMaker filsystemet FSx for Luster till filsystemet för träningsinstanser och startar sedan ditt träningsskript. Att montera i sig är en relativt snabb operation som inte beror på storleken på datamängden lagrad i FSx för Lustre.

I många fall skapar du ett FSx för Luster-filsystem och länka den till en S3-hink och prefix. När de är länkade till en S3-bucket som källa, laddas filer in i filsystemet när ditt träningsskript läser dem. Detta innebär att direkt efter den första epoken av din första träningskörning kopieras hela datamängden från Amazon S3 till FSx för Luster-lagring (förutsatt att en epok definieras som ett enda helsvep tänkte träningsexemplen, och att den tilldelade FSx för Glansförvaring är tillräckligt stor). Detta möjliggör filåtkomst med låg latens för alla efterföljande epoker och utbildningsjobb med samma datauppsättning.

Du kan också förladda filer i filsystemet innan träningsjobbet påbörjas, vilket lindrar kallstarten på grund av slö belastning. Det är också möjligt att köra flera utbildningsjobb parallellt som betjänas av samma FSx for Luster-filsystem. För att komma åt FSx for Lustre måste ditt träningsjobb anslutas till en VPC (se VPCConfig-inställningar), vilket kräver DevOps-installation och medverkan. För att undvika kostnader för dataöverföring använder filsystemet en enda tillgänglighetszon och du måste ange detta tillgänglighetszon-ID när du kör träningsjobbet. Eftersom du använder Amazon S3 som din långsiktiga datalagring rekommenderar vi att du distribuerar din FSx for Luster med Scratch 2-lagring, som ett kostnadseffektivt, kortsiktigt lagringsval för hög genomströmning, vilket ger en baslinje på 200 MB/s och en skur på upp till 1300 MB/s per TB lagringsutrymme.

Med ditt FSx for Luster-filsystem ständigt igång kan du starta nya träningsjobb utan att vänta på att ett filsystem ska skapas, och behöver inte oroa dig för kallstarten under den allra första epoken (eftersom filer fortfarande kan cachelagras i filsystemet FSx för Luster). Nackdelen i det här scenariot är den extra kostnad som är förknippad med att hålla filsystemet igång. Alternativt kan du skapa och ta bort filsystemet före och efter varje träningsjobb (förmodligen med skriptautomation till hjälp), men det tar tid att initiera ett FSx for Luster-filsystem, vilket är proportionellt mot antalet filer som det innehåller (för till exempel tar det ungefär en timme att indexera cirka 2 miljoner objekt från Amazon S3).

Amazon EFS

Vi rekommenderar att du använder Amazon EFS om din träningsdata redan finns i Amazon EFS på grund av användningsfall förutom ML-träning. För att använda Amazon EFS som datakälla måste data redan finnas i Amazon EFS innan utbildningen påbörjas. SageMaker monterar det specificerade Amazon EFS-filsystemet till träningsinstansen och startar sedan ditt träningsskript. När du konfigurerar Amazon EFS-filsystemet måste du välja mellan standardprestandaläget för allmänna ändamål, som är optimerat för latens (bra för små filer), och läget Max I/O-prestanda, som kan skalas till högre nivåer av aggregerad genomströmning och operationer per sekund (bättre för utbildningsjobb med många I/O-arbetare). För att lära dig mer, se Använder rätt prestandaläge.

Dessutom kan du välja mellan två uppmätta genomströmningsalternativ: bursting throughput och provisioned throughput. Burstgenomströmning för ett 1 TB filsystem ger en baslinje på 150 MB/s, samtidigt som den kan sprängas till 300 MB/s under en tidsperiod på 12 timmar om dagen. Om du behöver högre baslinjegenomströmning, eller finner att du får slut på burst-krediter för många gånger, kan du antingen öka storleken på filsystemet eller byta till provisionerad genomströmning. I provisionerad genomströmning betalar du för önskad baslinjegenomströmning upp till maximalt 3072 MB/s läsning.

Ditt utbildningsjobb måste anslutas till en VPC (se VPCConfig-inställningar) för att komma åt Amazon EFS.

Att välja den bästa datakällan

Den bästa datakällan för ditt träningsjobb beror på arbetsbelastningsegenskaper som datauppsättningsstorlek, filformat, genomsnittlig filstorlek, utbildningslängd, sekventiell eller slumpmässig dataladdarens läsmönster och hur snabbt din modell kan konsumera träningsdata.

Följande flödesschema ger några riktlinjer som hjälper dig att komma igång:

När ska man använda Amazon EFS

Om din datauppsättning huvudsakligen lagras på Amazon EFS kan du ha en förbearbetnings- eller anteckningsapplikation som använder Amazon EFS för lagring. Du kan enkelt köra ett träningsjobb konfigurerat med en datakanal som pekar på Amazon EFS-filsystemet (för mer information, se Snabbare utbildning på Amazon SageMaker med Amazon FSx för Luster och Amazon EFS-filsystem). Om prestandan inte är riktigt så bra som du förväntade dig, kontrollera dina optimeringsalternativ med Amazon EFS prestandaguide, eller överväg andra inmatningslägen.

Använd filläge för små datamängder

Om datauppsättningen lagras på Amazon S3 och dess totala volym är relativt liten (till exempel mindre än 50–100 GB), prova att använda filläge. Kostnaden för att ladda ner en datauppsättning på 50 GB kan variera beroende på det totala antalet filer (till exempel cirka 5 minuter om de är uppdelade i 100 MB-skärvor). Huruvida denna startoverhead är acceptabel beror främst på den totala varaktigheten av ditt träningsjobb, eftersom en längre utbildningsfas innebär en proportionellt mindre nedladdningsfas.

Serialisera många små filer tillsammans

Om din datauppsättningsstorlek är liten (mindre än 50–100 GB), men består av många små filer (mindre än 50 MB), växer nedladdningskostnaderna för filläge, eftersom varje fil måste laddas ner individuellt från Amazon S3 till träningsinstansvolym. För att minska denna omkostnad, och för att påskynda dataöverföring i allmänhet, överväg att serialisera grupper av mindre filer till färre större filbehållare (som 150 MB per fil) genom att använda filformat som t.ex. TFRekord för TensorFlow, WebDataset för PyTorch, eller RecordIO för MXNet. Dessa format kräver att din dataladdare upprepar exemplen sekventiellt. Du kan fortfarande blanda dina data genom att slumpmässigt ändra ordningen på listan med TFRecord-filer efter varje epok och genom att slumpmässigt sampla data från en lokal shuffle-buffert (se följande TensorFlow exempel).

När ska man använda FastFile-läget

För större datauppsättningar med större filer (mer än 50 MB) är det första alternativet att prova FastFile-läget, som är enklare att använda än FSx för Luster eftersom det inte kräver att man skapar ett filsystem eller ansluter till en VPC. FastFile-läget är idealiskt för stora filbehållare (mer än 150 MB) och kan också göra bra med filer över 50 MB. Eftersom FastFile-läget tillhandahåller ett POSIX-gränssnitt, stöder det slumpmässiga läsningar (läsning av icke-sekventiella byte-intervall). Detta är dock inte det idealiska användningsfallet, och din genomströmning skulle förmodligen vara lägre än med de sekventiella läsningarna. Men om du har en relativt stor och beräkningsintensiv ML-modell kan FastFile-läget fortfarande mätta den effektiva bandbredden för träningspipelinen och inte resultera i en I/O-flaskhals. Du måste experimentera och se. Lyckligtvis är det lika enkelt att byta från filläge till FastFile (och tillbaka) som att lägga till (eller ta bort) input_mode='FastFile' parameter när du definierar din ingångskanal med SageMaker Python SDK:

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

Ingen annan kod eller konfiguration behöver ändras.

När ska man använda FSx för Luster

Om din datauppsättning är för stor för filläge, eller har många små filer (som du inte kan serialisera lätt), eller om du har ett slumpmässigt läsåtkomstmönster, är FSx for Luster ett bra alternativ att överväga. Dess filsystem skalas till hundratals GB/s genomströmning och miljontals IOPS, vilket är idealiskt när du har många små filer. Men, som redan diskuterats tidigare, var uppmärksam på kallstartsproblemen på grund av lat laddning och omkostnader för att installera och initiera FSx for Luster-filsystemet.

Kostnadsöverväganden

För de flesta ML-utbildningsjobb, särskilt jobb som använder GPU:er eller specialbyggda ML-chips, är den största delen av kostnaden för att träna ML-utbildningsinstansens fakturerbara sekunder. Storage GB per månad, API-förfrågningar och provisionerad genomströmning är extra kostnader som är direkt kopplade till de datakällor du använder.

Lagring GB per månad

Lagring GB per månad kan vara betydande för större datauppsättningar, som videor, LiDAR-sensordata och AdTech budgivningsloggar i realtid. Till exempel att lagra 1 TB i Amazon S3 Intelligent-Tiering Frequent Access Tier kostar $23 per månad. Att lägga till filsystemet FSx for Luster ovanpå Amazon S3 resulterar i extra kostnader. Att till exempel skapa ett 1.2 TB filsystem av SSD-stödd Scratch 2-typ med datakomprimering inaktiverad kostar ytterligare $168 per månad ($140/TB/månad).

Med Amazon S3 och Amazon EFS betalar du bara för det du använder, vilket innebär att du debiteras enligt den faktiska datasetstorleken. Med FSx for Lustre debiteras du av den tillhandahållna filsystemets storlek (minst 1.2 TB). När du kör ML-instanser med EBS-volymer debiteras Amazon EBS oberoende av ML-instansen. Detta är vanligtvis en mycket lägre kostnad jämfört med kostnaden för att driva instansen. Till exempel, att köra en ml.p3.2xlarge-instans med en 100 GB EBS-volym i 1 timme kostar 3.825 USD för instansen och 0.02 USD för EBS-volymen.

API-förfrågningar och provisionerad genomströmningskostnad

Medan ditt träningsjobb går igenom datamängden listar och hämtar det filer genom att skicka Amazon S3 API-förfrågningar. Till exempel är varje miljon GET-förfrågningar prissatt till $0.4 (med klassen Intelligent-Tiering). Du bör inte förvänta dig några dataöverföringskostnader för bandbredd in och ut från Amazon S3, eftersom utbildningen sker i en enda tillgänglighetszon.

När du använder en FSx for Luster som är länkad till en S3-bucket, ådrar du dig Amazon S3 API-begärankostnader för att läsa data som ännu inte är cachad i filsystemet, eftersom FSx For Luster proxar begäran till Amazon S3 (och cachar resultatet ). Det finns inga direkta förfrågningskostnader för FSx för Luster själv. När du använder ett FSx for Luster-filsystem undviker du kostnader för dataöverföring i kors-tillgänglighetszoner genom att köra ditt träningsjobb kopplat till samma tillgänglighetszon som du tillhandahållit filsystemet i. Amazon EFS med provisionerad genomströmning lägger till en extra kostnad för consdier utöver GB per månad.

Fallstudie av prestanda

För att demonstrera övervägandena om träningsprestanda som nämnts tidigare utförde vi en serie riktmärken för ett realistiskt användningsfall i datorseendedomänen. Riktmärket (och takeaways) från det här avsnittet kanske inte är tillämpligt på alla scenarier och påverkas av olika förutbestämda faktorer som vi använde, som DNN. Vi körde tester för 12 kombinationer av följande:

• Inmatningslägen – FSx för Lustre, Filläge, FastFile-läge
• Datasättstorlek – Mindre datauppsättning (1 GB), större datauppsättning (54 GB)
• Filstorlek – Mindre filer (JPG, cirka 39 KB), Större filer (TFRecord, cirka 110 MB)

För denna fallstudie valde vi de mest använda inmatningslägena och utelämnade därför Amazon EFS och Pipe-läge.

Benchmarks för fallstudien utformades som heltäckande SageMaker TensorFlow-utbildningsjobb på en ml.p3.2xlarge single-GPU-instans. Vi valde den berömda ResNet-50 som vår ryggradsmodell för klassificeringsuppgiften och Caltech-256 som den mindre träningsdatauppsättningen (som vi replikerade 50 gånger för att skapa dess större datauppsättningsversion). Vi utförde träningen under en epok, definierad som ett enda helsvep tänkte träningsexemplen.

Följande diagram visar den totala fakturerbara tiden för SageMaker-utbildningsjobben för varje benchmarkscenario. Den totala jobbtiden i sig består av nedladdning, utbildning och andra stadier (såsom containerstart och uppladdning av tränade modellartefakter till Amazon S3). Kortare faktureringstider leder till snabbare och billigare utbildningsjobb.

Låt oss först diskutera Scenario A och Scenario C, som bekvämt visar prestandaskillnaden mellan inmatningslägen när datamängden består av många små filer.

Scenario A (mindre filer, mindre datauppsättning) avslöjar att träningsjobbet med filsystemet FSx for Luster har den minsta fakturerbara tiden. Den har den kortaste nedladdningsfasen och träningsfasen är lika snabb som filläge, men snabbare än FastFile. FSx for Luster är vinnaren i detta enda epoktest. Med det sagt, överväg en liknande arbetsbelastning men med flera epoker – den relativa omkostnaden för filläget på grund av nedladdningsstadiet minskar när fler epoker läggs till. I det här fallet föredrar vi filläge för att det är lätt att använda. Dessutom kanske du upptäcker att att använda filläge och betala för 100 extra fakturerbara sekunder är ett bättre val än att betala för och tillhandahålla ett FSx for Luster-filsystem.

Scenario C (mindre filer, större datauppsättning) visar FSx för Luster som det snabbaste läget, med endast 5,000 1.5 sekunders total fakturerbar tid. Den har också den kortaste nedladdningsfasen, eftersom monteringen av filsystemet FSx for Luster inte beror på antalet filer i filsystemet (3 miljoner filer i det här fallet). Nedladdningskostnaderna för FastFile är också små; den hämtar bara metadata för filerna som finns under det angivna S10,000-bucket-prefixet, medan innehållet i filerna läses under träningsstadiet. Filläget är det långsammaste läget och spenderar 3 XNUMX sekunder på att ladda ner hela datasetet i förväg innan träningen påbörjas. När vi tittar på träningsstadiet visar FSx för Luster och File-läge liknande utmärkta prestanda. När det gäller FastFile-läget, när mindre filer strömmas direkt från Amazon SXNUMX, blir overheaden för att skicka en ny GET-begäran för varje fil betydande i förhållande till den totala varaktigheten av filöverföringen (trots att man använder en mycket parallell dataladdare med förhämtningsbuffert). Detta resulterar i en generellt lägre genomströmning för FastFile-läget, vilket skapar en I/O-flaskhals för träningsjobbet. FSx for Luster är den klara vinnaren i detta scenario.

Scenarierna B och D visa prestandaskillnaden mellan inmatningslägen när datauppsättningen består av färre större filer. Läsning sekventiellt med hjälp av större filer resulterar vanligtvis i bättre I/O-prestanda eftersom det möjliggör effektiv buffring och minskar antalet I/O-operationer.

Scenario B (större filer, mindre datauppsättning) visar liknande träningsskedetid för alla lägen (vittnar om att träningen inte är I/O-bunden). I det här scenariot föredrar vi FastFile-läge framför filläge på grund av kortare nedladdningssteg, och föredrar FastFile-läge framför FSx för Luster på grund av den enkla användningen av den förra.

Scenario D (större filer, större datauppsättning) visar relativt likartade totala fakturerbara tider för alla tre lägen. Nedladdningsfasen för filläge är längre än den för FSx för Luster och FastFile. Filläge laddar ner hela datasetet (54 GB) från Amazon S3 till träningsinstansen innan träningsstadiet påbörjas. Alla tre lägen spenderar liknande tid i träningsfasen, eftersom alla lägen kan hämta data tillräckligt snabbt och är GPU-bundna. Om vi ​​använder ML-instanser med ytterligare CPU- eller GPU-resurser, såsom ml.p4d.24xlarge, ökar den nödvändiga data-I/O-genomströmningen för att mätta beräkningsresurserna. I dessa fall kan vi förvänta oss att FastFile och FSx för Luster framgångsrikt skalar sin genomströmning (fsx för Luster-genomströmning beror dock på storleken på det provisionerade filsystemet). Förmågan i filläge att skala dess genomströmning beror på genomströmningen av diskvolymen som är ansluten till instansen. Till exempel är Amazon EBS-stödda instanser (som ml.p3.2xlarge, ml.p3.8xlarge och ml.p3.16xlarge) begränsade till en maximal genomströmning på 250 MB/s, medan lokala NVMe-stödda instanser (som ml. g5.* eller ml.p4d.24xlarge) kan rymma en mycket större genomströmning.

För att sammanfatta tror vi att FastFile är vinnaren för det här scenariot eftersom det är snabbare än filläge och lika snabbt som FSx för Lustre, men ändå enklare att använda, kostar mindre och kan enkelt skala upp sin genomströmning efter behov.

Dessutom, om vi hade en mycket större datamängd (flera TB i storlek), skulle filläget spendera många timmar på att ladda ner datamängden innan träningen kunde starta, medan FastFile kunde börja träna betydligt snabbare.

Ta med din egen dataintag

SageMakers inbyggda datakälla passar de flesta men inte alla möjliga ML-träningsscenarier. De situationer då du kan behöva leta efter andra dataintagsalternativ kan inkludera att läsa data direkt från en tredjepartslagringsprodukt (förutsatt att en enkel och snabb export till Amazon S3 inte är möjlig), eller att ha ett starkt krav på samma utbildning skriptet körs oförändrat på både SageMaker och Amazon Elastic Compute Cloud (Amazon EC2) eller Amazon Elastic Kubernetes-tjänst (Amazon EKS). Du kan ta itu med dessa fall genom att implementera din datainmatningsmekanism i träningsskriptet. Denna mekanism är ansvarig för att läsa datauppsättningar från externa datakällor till träningsinstansen. Till exempel TFRecordDataset av TensorFlow tf.data bibliotek kan läsa direkt från Amazon S3-lagring.

Om din datainmatningsmekanism behöver anropa någon AWS-tjänster, som t.ex Amazon Relational Databas Service (Amazon RDS), se till att AWS identitets- och åtkomsthantering (IAM) roll för ditt utbildningsjobb inkluderar relevanta IAM-policyer. Om datakällan finns i Amazon Virtual Private Cloud (Amazon VPC), måste du köra ditt träningsjobb kopplat till samma VPC.

När du själv hanterar datauppsättning, kan inte SageMakers härstamningsspårning automatiskt logga de datauppsättningar som används under träningen. Överväg därför alternativa mekanismer, som träningsjobbtaggar eller hyperparametrar, för att fånga din relevanta metadata.

Slutsats

Att välja rätt SageMaker träningsdatakälla kan ha en djupgående effekt på hastigheten, användarvänligheten och kostnaden för att träna ML-modeller. Använd det medföljande flödesschemat för att komma igång snabbt, observera resultaten och experimentera med ytterligare konfiguration vid behov. Tänk på fördelarna, nackdelarna och begränsningarna för varje datakälla och hur väl de passar ditt utbildningsjobbs individuella krav. Kontakta en AWS-kontakt för mer information och hjälp.

Om författarna

Gili Nachum är en senior AI/ML Specialist Solutions Architect som arbetar som en del av EMEAs Amazon Machine Learning-team. Gili brinner för utmaningarna med att träna modeller för djupinlärning och hur maskininlärning förändrar världen som vi känner den. På fritiden tycker Gili om att spela bordtennis.

Dr Alexander Arzhanov är en AI/ML Specialist Solutions Architect baserad i Frankfurt, Tyskland. Han hjälper AWS-kunder att designa och distribuera sina ML-lösningar över hela EMEA-regionen. Innan han gick med i AWS forskade Alexander om ursprunget till tunga grundämnen i vårt universum och blev passionerad för ML efter att ha använt det i sina storskaliga vetenskapliga beräkningar.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://aws.amazon.com/blogs/machine-learning/choose-the-best-data-source-for-your-amazon-sagemaker-training-job/