Förbättra prisprestandan för din modellträning med Amazon SageMaker heterogena kluster

Det här inlägget är skrivet tillsammans med Chaim Rand från Mobileye.

Vissa arbetsbelastningar för maskininlärning (ML), som att träna datorseendemodeller eller förstärkningsinlärning, innebär ofta att man kombinerar den GPU- eller acceleratorintensiva uppgiften för utbildning av neurala nätverksmodeller med den CPU-intensiva uppgiften dataförbearbetning, som bildförstärkning. När båda typerna av uppgifter körs på samma instanstyp, blir dataförbehandlingen flaskhalsad på CPU, vilket leder till lägre GPU-användning. Det här problemet blir värre med tiden eftersom genomströmningen av nyare generationer av GPU:er växer i en brantare takt än processorernas.

För att lösa detta problem, i juli 2022, lanserades heterogena kluster för Amazon SageMaker modellutbildning, som gör att du kan starta utbildningsjobb som använder olika instanstyper i ett enda jobb. Detta tillåter avlastning av delar av dataförbehandlingspipeline till datoroptimerad instanstyper, medan uppgiften DNN (Deep Neural Network) fortsätter att köras GPU eller accelererad datoranvändning instanstyper. Våra riktmärken visar upp till 46 % prisprestandafördelar efter att ha aktiverat heterogena kluster i en CPU-bunden TensorFlow datorseende modellutbildning.

För ett liknande användningsfall, mobilye, ett utvecklingsföretag för autonom fordonsteknik, hade detta att dela:

"Genom att flytta CPU-bunden djupinlärning av datorseendemodeller till att köra över flera instanstyper (CPU och GPU/ML-acceleratorer), med hjälp av en tf.data.service baserad lösning vi har byggt, lyckades vi minska tiden att träna med 40 % samtidigt som vi minskade kostnaden för att träna med 30 %. Vi är glada över heterogena kluster som tillåter oss att köra den här lösningen på Amazon SageMaker.”

— AI Engineering, Mobileye

I det här inlägget diskuterar vi följande ämnen:

• Hur heterogena kluster hjälper till att ta bort CPU-flaskhalsar
• När ska man använda heterogena kluster och andra alternativ
• Referensimplementeringar i PyTorch och TensorFlow
• Prestanda benchmark resultat
• Heterogena kluster vid Mobileye

AWS accelererad beräkningsinstans familjen inkluderar acceleratorer från AWS anpassade chips (AWS slutledning, AWS Trainium), NVIDIA (GPUs), Och Gaudi acceleratorer från Habana Labs (ett Intel-företag). Observera att i det här inlägget använder vi termerna GPU och accelerator omväxlande.

Hur heterogena kluster tar bort flaskhalsar i databehandling

Dataforskare som tränar modeller för djupinlärning strävar efter att maximera utbildningens kostnadseffektivitet och minimera träningstiden. För att uppnå detta är ett grundläggande optimeringsmål att ha högt GPU-utnyttjande, den dyraste och mest knappa resursen inom Amazon Elastic Compute Cloud (Amazon EC2) instans. Detta kan vara mer utmanande med ML-arbetsbelastningar som kombinerar den klassiska GPU-intensiva neurala nätverksmodellens fortplantning framåt och bakåt med CPU-intensiva uppgifter, såsom databearbetning och förstärkning i datorseende eller att köra en miljösimulering i förstärkningsinlärning. Dessa arbetsbelastningar kan sluta vara CPU-bundna, där mer CPU skulle resultera i högre genomströmning och snabbare och billigare träning eftersom befintliga acceleratorer är delvis inaktiva. I vissa fall kan CPU-flaskhalsar lösas genom att byta till en annan instanstyp med ett högre CPU:GPU-förhållande. Det finns dock situationer där det kanske inte är möjligt att byta till en annan instanstyp på grund av instansfamiljens arkitektur, lagring eller nätverksberoende.

I sådana situationer måste du öka mängden CPU-kraft genom att blanda instanstyper: instanser med GPU:er tillsammans med CPU. Sammantaget resulterar detta i ett totalt sett högre CPU:GPU-förhållande. Tills nyligen var SageMakers utbildningsjobb begränsade till att ha instanser av en enda vald instanstyp. Med SageMaker heterogena kluster kan dataforskare enkelt köra ett träningsjobb med flera instanstyper, vilket gör det möjligt att ladda ner några av de befintliga CPU-uppgifterna från GPU-instanserna till dedikerade datoroptimerade CPU-instanser, vilket resulterar i högre GPU-användning och snabbare och mer kostnad effektiv träning. Dessutom, med den extra CPU-kraften, kan du få förbearbetningsuppgifter som traditionellt gjordes offline som ett preliminärt steg för att träningen ska bli en del av ditt träningsjobb. Detta gör det snabbare att iterera och experimentera över både dataförbearbetning och DNN-träningsantaganden och hyperparametrar.

Tänk till exempel på en kraftfull GPU-instans, ml.p4d.24xlarge (96 vCPU, 8 x NVIDIA A100 GPU) med ett CPU:GPU-förhållande på 12:1. Låt oss anta att ditt träningsjobb behöver 20 vCPU:er för att förbehandla tillräckligt med data för att behålla en GPU till 100 %. Därför, för att behålla alla 8 GPU:er till 100 %, behöver du en instans av 160 vCPU:er. Emellertid saknar ml.p4d.24xlarge 64 vCPU:er, eller 40 %, vilket begränsar GPU-användningen till 60 %, som visas till vänster i följande diagram. Skulle det hjälpa att lägga till ytterligare en ml.p4d.24xlarge-instans? Nej, eftersom jobbets CPU:GPU-förhållande skulle förbli detsamma.

Med heterogena kluster kan vi lägga till två ml.c5.18xlarge (72 vCPU), som visas till höger i diagrammet. Den totala netto vCPU i detta kluster är 210 (96+2*72), vilket leder till ett CPU:GPU-förhållande på 30:1. Var och en av dessa beräkningsoptimerade instanser kommer att laddas av med en CPU-intensiv uppgift för förbearbetning av data, och kommer att tillåta effektivt GPU-användning. Trots den extra kostnaden för ml.c5.18xlarge tillåter det högre GPU-utnyttjandet snabbare bearbetning och därmed högre prisfördelar.

När ska man använda heterogena kluster och andra alternativ

I det här avsnittet förklarar vi hur man identifierar en CPU-flaskhals och diskuterar hur man löser den med hjälp av instanstypsskala upp kontra heterogena kluster.

Det snabba sättet att identifiera en CPU-flaskhals är att övervaka CPU och GPU användningsmått för SageMaker utbildningsjobb i amazoncloudwatch. Du kan komma åt dessa vyer från AWS Management Console inom träningsjobbsidans instansmätningshyperlänk. Välj relevant statistik och växla från 5-minuters till 1-minuters upplösning. Observera att skalan är 100 % per vCPU eller GPU, så utnyttjandegraden för en instans med 4 vCPU:er/GPU:er kan vara så hög som 400%. Följande figur är ett sådant exempel från CloudWatch-statistik, där CPU är ungefär 100 % utnyttjad, vilket indikerar en CPU-flaskhals, medan GPU är underutnyttjad.

För detaljerad diagnos, kör träningsjobben med Amazon SageMaker Debugger för att profilera resursanvändningsstatus, statistik och ramverksoperationer genom att lägga till en profilkonfiguration när du konstruerar en SageMaker-estimator med SageMaker Python SDK. När du har skickat in utbildningsjobbet, granska resultatet profileringsrapport för CPU-flaskhalsar.

Om du drar slutsatsen att ditt jobb skulle kunna dra nytta av ett högre CPU:GPU-beräkningsförhållande, överväg först att skala upp till en annan instanstyp i samma instansfamilj, om en sådan finns tillgänglig. Om du till exempel tränar din modell på ml.g5.8xlarge (32 vCPUs, 1 GPU), överväg att skala upp till ml.g5.16xlarge (64 vCPUs, 1 GPU). Eller, om du tränar din modell med multi-GPU-instanser ml.g5.12xlarge (48 vCPU, 4 GPU), överväg att skala upp till ml.g5.24xlarge (96 vCPUs, 4 GPUs). Referera till G5 instansfamiljespecifikation för mer information.

Ibland är uppskalning inte ett alternativ, eftersom det inte finns någon instanstyp med ett högre vCPU:GPU-förhållande i samma instansfamilj. Om du till exempel tränar modellen på ml.trn1.32xlarge, ml.p4d.24xlarge eller ml.g5.48xlarge bör du överväga heterogena kluster för SageMaker modellträning.

Förutom att skala upp, vill vi notera att det finns ytterligare alternativ till ett heterogent kluster, som NVIDIA DALI, som laddar bort bildförbehandling till GPU:n. För mer information, se Övervinna flaskhalsar vid dataförbehandling med TensorFlow Data Service, NVIDIA DALI och andra metoder.

För att förenkla beslutsfattandet, se följande flödesschema.

Hur man använder SageMaker heterogena kluster

För att komma igång snabbt kan du direkt hoppa till TensorFlow- eller PyTorch-exemplen som tillhandahålls som en del av det här inlägget.

I det här avsnittet går vi igenom hur du använder ett SageMaker heterogena kluster med ett enkelt exempel. Vi antar att du redan vet hur man tränar en modell med SageMaker Python SDK och Estimator-klassen. Om inte, se Använder SageMaker Python SDK innan du fortsätter.

Före den här funktionen initierade du träningsjobbets Estimator-klass med InstanceCount och InstanceType-parametrar, som implicit antar att du bara har en enda instanstyp (ett homogent kluster). Med lanseringen av heterogena kluster introducerade vi det nya sagemaker.instance_group.InstanceGroup klass. Detta representerar en grupp av en eller flera instanser av en specifik instanstyp, utformade för att bära en logisk roll (som databehandling eller neurala nätverksoptimering. Du kan ha två eller flera grupper och ange ett anpassat namn för varje instansgrupp, instansen typ och antalet instanser för varje instansgrupp. För mer information, se Använder SageMaker Python SDK och Använder SageMaker API:er på låg nivå.

När du har definierat instansgrupperna måste du ändra ditt träningsskript för att läsa SageMaker information om träningsmiljö som inkluderar heterogen klusterkonfiguration. Konfigurationen innehåller information såsom aktuella instansgrupper, aktuella värdar i varje grupp och i vilken grupp den aktuella värden finns med sin rankning. Du kan bygga logik i ditt träningsskript för att tilldela instansgrupperna till vissa tränings- och databearbetningsuppgifter. Dessutom måste ditt träningsskript ta hand om gruppkommunikation mellan instanser eller distribuerade dataladdningsmekanismer (till exempel, tf.data.service i TensorFlow eller generisk gRPC klient-server) eller något annat ramverk (till exempel, Apache Spark).

Låt oss gå igenom ett enkelt exempel på att starta ett heterogent träningsjobb och läsa miljökonfigurationen under körning.

1. När vi definierar och startar träningsjobbet, konfigurerar vi två instansgrupper som används som argument till SageMakers estimator:

   from sagemaker.instance_group import InstanceGroup
   data_group = InstanceGroup("data_group", "ml.c5.18xlarge", 2)
   dnn_group = InstanceGroup("dnn_group", "ml.p4d.24xlarge", 1)
   
   from sagemaker.pytorch import PyTorch
   estimator = PyTorch(...,
       entry_point='launcher.py',
       instance_groups=[data_group, dnn_group]
   )

2. På startpunktens träningsskript (namn launcher.py), läser vi den heterogena klusterkonfigurationen till om instansen kommer att köra förbearbetningen eller DNN-koden:

   from sagemaker_training import environment
   env = environment.Environment()
   if env.current_instance_group == 'data_group': ...;

Låt oss med detta sammanfatta de uppgifter SageMaker gör för din räkning, och de uppgifter som du ansvarar för.

SageMaker utför följande uppgifter:

1. Tillhandahåll olika instanstyper enligt instansgruppens definition.
2. Tillhandahålla ingångskanaler på alla eller specifika instansgrupper.
3. Distribuera utbildningsskript och beroenden till instanser.
4. Ställ in ett MPI-kluster på en specifik instansgrupp, om den har definierats.

Du ansvarar för följande arbetsuppgifter:

1. Ändra ditt jobbskript för att börja träna för att ange instansgrupper.
2. Implementera en distribuerad datapipeline (t.ex. tf.data.service).
3. Ändra ditt ingångsskript (se launcher.py i exemplet anteckningsboken) för att vara en enda ingångspunkt som körs på alla instanser, upptäcker vilken instansgrupp den körs i och utlöser relevant beteende (som databehandling eller DNN-optimering).
4. När träningsslingan är över måste du se till att din startpunktsprocess avslutas på alla instanser över alla instansgrupper. Detta är viktigt eftersom SageMaker väntar på att alla instanser ska slutföra bearbetningen innan det markerar jobbet som färdigt och slutar fakturera. De launcher.py skript i TensorFlow och PyTorch exempel anteckningsböcker tillhandahåller en referensimplementering av signaleringsdatagruppinstanser som ska avslutas när DNN-gruppinstanser avslutar sitt arbete.

Exempel på anteckningsböcker för SageMaker heterogena kluster

I det här avsnittet ger vi en sammanfattning av exempel anteckningsböcker för både TensorFlow och PyTorch ML ramverk. I anteckningsböckerna kan du hitta implementeringsdetaljer, genomgångar om hur koden fungerar, kodavsnitt som du kan återanvända i dina träningsskript, flödesdiagram och kostnadsjämförelseanalys.

Observera att i båda exemplen bör du inte förvänta dig att modellen konvergerar på ett meningsfullt sätt. Vår avsikt är endast att mäta datapipeline och neurala nätverksoptimeringsgenomströmning uttryckt i epok/stegtid. Du måste jämföra med din egen modell och datauppsättning för att producera prisprestandafördelar som matchar din arbetsbelastning.

Heterogent kluster som använder en tf.data.service-baserad distribuerad dataladdare (TensorFlow)

Denna anteckningsbok visar hur man implementerar ett heterogent kluster för SageMaker-utbildning med TensorFlows tf.data.service baserad distribuerad datapipeline. Vi tränar en datorseendemodell för djupinlärning Resnet50 som kräver CPU-intensiv dataökning. Det använder Horvod för distribuerad dataparallellism med flera GPU.

Vi kör arbetsbelastningen i två konfigurationer: först som ett homogent kluster, en enda ml.p4d.24xlarge-instans med en standard tf.data pipeline som visar CPU-flaskhalsar som leder till lägre GPU-användning. I den andra körningen byter vi från en enda instanstyp till två instansgrupper med hjälp av ett SageMaker heterogent kluster. Denna körning avlastar en del av databehandlingen till ytterligare CPU-instanser (med tf.data.service).

Vi jämför sedan de homogena och heterogena konfigurationerna och hittar viktiga prisfördelar. Som visas i följande tabell är det heterogena jobbet (86ms/steg) 2.2 gånger snabbare att träna än det homogena jobbet (192ms/steg), vilket gör det 46% billigare att träna en modell.

Exempel 1 (TF)	ml.p4d.24xl	ml.c5.18xl	Pris per timme*	Genomsnittlig stegtid	Kostnad per steg	Förbättring av prisprestanda
Homogen	1	0	$37.688	192 ms	$0.201	.
heterogena	1	2	$45.032	86 ms	$0.108	46%

* Pris per timme är baserat på us-east-1 SageMaker prissättning på begäran

Denna snabbhet är möjlig genom att använda den extra vCPU, som tillhandahålls av datagruppen, och snabbare förbearbetning. Se den anteckningsbok för mer detaljer och grafer.

Heterogent kluster som använder en gRPC-klientserverbaserad distribuerad dataladdare (PyTorch)

Denna anteckningsbok demonstrerar ett exempel på arbetsbelastning med ett heterogent kluster för SageMaker-utbildning med en gRPC-klientserverbaserad distribuerad dataladdare. Det här exemplet använder en enda GPU. Vi använder PyTorch-modellen baserat på följande officiellt MNIST-exempel. Träningskoden har modifierats för att vara tung för förbearbetning av data. Vi tränar denna modell i både homogena och heterogena klusterlägen och jämför prisprestanda.

I det här exemplet antog vi att arbetsbelastningen inte kan dra nytta av flera GPU: er och är beroende av en specifik GPU-arkitektur (NVIDIA V100). Vi körde både homogena och heterogena utbildningsjobb och hittade viktiga prisfördelar, som visas i följande tabell. Det heterogena jobbet (1.19s/steg) är 6.5 gånger snabbare att träna än det homogena jobbet (0.18s/steg), vilket gör det 77% billigare att träna en modell.

Exempel 2 (PT)	ml.p3.2xl	ml.c5.9xl	Pris per timme*	Genomsnittlig stegtid	Kostnad per steg	Förbättring av prisprestanda
Homogen	1	0	$3.825	1193 ms	$0.127	.
heterogena	1	1	$5.661	184 ms	$0.029	77%

* Pris per timme är baserat på us-east-1 SageMaker prissättning på begäran

Detta är möjligt eftersom vi med ett högre CPU-antal kunde använda 32 dataladdare (jämfört med 8 med ml.p3.2xlarge) för att förbearbeta data och höll GPU nära 100 % utnyttjad med frekventa intervall. Se den anteckningsbok för mer detaljer och grafer.

Heterogena kluster vid Mobileye

Mobileye, ett Intel-företag, utvecklar Advanced Driver Assistance Systems (ADAS) och autonoma fordonsteknologier med målet att revolutionera transportindustrin, göra vägarna säkrare och rädda liv. Dessa tekniker är möjliga med hjälp av sofistikerade datorseende (CV)-modeller som tränas med SageMaker på stora mängder data som lagras i Amazon enkel lagringstjänst (Amazon S3). Dessa modeller använder state-of-the-art tekniker för djupinlärning av neurala nätverk.

Vi märkte att för en av våra CV-modeller orsakades CPU-flaskhalsen främst av tung dataförbehandling som ledde till underutnyttjade GPU:er. För den här specifika arbetsbelastningen började vi titta på alternativa lösningar, utvärderade distribuerade datapipeline-tekniker med heterogena kluster baserade på EC2-instanser och kom med referensimplementeringar för båda TensorFlow och PyTorch. Utgivningen av SageMaker heterogena kluster tillåter oss att köra denna och liknande arbetsbelastningar på SageMaker för att uppnå förbättrade prisprestandafördelar.

Överväganden

Med lanseringen av den heterogena klusterfunktionen erbjuder SageMaker mycket mer flexibilitet när det gäller att blanda och matcha instanstyper inom ditt träningsjobb. Tänk dock på följande när du använder den här funktionen:

• Den heterogena klusterfunktionen är tillgänglig via SageMaker PyTorch och TensorFlow ramberäkningsklasser. Ramverk som stöds är PyTorch v1.10 eller senare och TensorFlow v2.6 eller senare.
• Alla instansgrupper delar samma Docker-bild.
• Alla instansgrupper delar samma träningsskript. Därför bör ditt träningsskript modifieras för att upptäcka vilken instansgrupp det tillhör och fork körs därefter.
• Träningsinstansernas värdnamn (till exempel alog-1, algo-2 och så vidare) tilldelas slumpmässigt och anger inte vilken instansgrupp de tillhör. För att få instansens roll rekommenderar vi att du skaffar medlemskap i instansgruppen under körning. Detta är också relevant vid granskning av inloggningar CloudWatch, eftersom loggströmmens namn [training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp] har värdnamnet.
• En distribuerad utbildningsstrategi (vanligtvis ett MPI-kluster) kan endast tillämpas på en instansgrupp.
• SageMaker Hanterade varma pooler och SageMaker Lokalt läge kan för närvarande inte användas med heterogen klusterutbildning.

Slutsats

I det här inlägget diskuterade vi när och hur man använder den heterogena klusterfunktionen i SageMaker-träning. Vi visade en 46 % förbättring av prisprestanda i ett verkligt användningsfall och hjälpte dig komma igång snabbt med distribuerad dataladdare (tf.data.service och gRPC klient-server) implementeringar. Du kan använda dessa implementeringar med minimala kodändringar i dina befintliga träningsskript.

För att komma igång, prova vår exempel anteckningsböcker. För att lära dig mer om den här funktionen, se Träna med hjälp av ett heterogent kluster.

---

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.

Hrushikesh Gangur är en huvudlösningsarkitekt för AI/ML-startups med expertis inom både ML Training och AWS Networking. Han hjälper startups inom Autonomous Vehicle, Robotics, CV, NLP, MLOps, ML Platform och Robotics Process Automation-teknologier att driva sin verksamhet effektivt och effektivt på AWS. Innan Hrushikesh började med AWS förvärvade han 20+ års branscherfarenhet, främst kring moln- och dataplattformar.

Gal Oshri är Senior Product Manager på Amazon SageMaker-teamet. Han har 7 års erfarenhet av att arbeta med maskininlärningsverktyg, ramverk och tjänster.

Chaim Rand är en maskininlärningsalgoritm som arbetar med djupinlärning och datorseendeteknologier för lösningar för autonoma fordon hos Mobileye, ett Intel-företag. Kolla in hans bloggar.