De seneste år har vist en fantastisk vækst i deep learning neurale netværk (DNN'er). Denne vækst kan ses i mere præcise modeller og endda åbne nye muligheder med generativ AI: store sprogmodeller (LLM'er), der syntetiserer naturligt sprog, tekst-til-billede-generatorer og mere. Disse øgede kapaciteter af DNN'er kommer med omkostningerne ved at have massive modeller, der kræver betydelige beregningsressourcer for at blive trænet. Distribueret træning løser dette problem med to teknikker: dataparallelisme og modelparallelisme. Dataparallelisme bruges til at skalere træningsprocessen over flere noder og arbejdere, og modelparallelisme opdeler en model og tilpasser dem over den udpegede infrastruktur. Amazon SageMaker distribueret træning job giver dig mulighed for med et klik (eller et API-kald) at oprette en distribueret computerklynge, træne en model, gemme resultatet til Amazon Simple Storage Service (Amazon S3), og luk klyngen ned, når du er færdig. SageMaker har desuden løbende fornyet sig i det distribuerede træningsrum ved at lancere funktioner som f.eks heterogene klynger og distribuerede træningsbiblioteker for dataparallelisme , modelparallelisme.
Effektiv træning i et distribueret miljø kræver justering af hyperparametre. Et almindeligt eksempel på god praksis, når du træner på flere GPU'er, er at gange batch- (eller mini-batch) størrelse med GPU-nummeret for at bevare den samme batchstørrelse pr. GPU. Men justering af hyperparametre påvirker ofte modelkonvergens. Derfor skal distribueret træning balancere tre faktorer: fordeling, hyperparametre og modelnøjagtighed.
I dette indlæg udforsker vi effekten af distribueret træning på konvergens og hvordan man bruger det Amazon SageMaker Automatisk Model Tuning at finjustere modelhyperparametre til distribueret træning ved hjælp af dataparallelisme.
Kildekoden nævnt i dette indlæg kan findes på GitHub repository (en m5.xlarge instans anbefales).
Skaler træningen ud fra et enkelt til distribueret miljø
Dataparallelisme er en måde at skalere træningsprocessen til flere computerressourcer og opnå hurtigere træningstid. Med dataparallelisme opdeles data mellem beregningsknuderne, og hver node beregner gradienterne baseret på deres partition og opdaterer modellen. Disse opdateringer kan udføres ved hjælp af en eller flere parameterservere på en asynkron, en-til-mange eller alle-til-alle måde. En anden måde kan være at bruge en AllReduce-algoritme. For eksempel kommunikerer hver knude i ring-all-reduce-algoritmen kun med to af sine naboknuder, hvorved de samlede dataoverførsler reduceres. For at lære mere om parameterservere og ring-allreduce, se Lancering af TensorFlow-distribueret træning nemt med Horovod eller Parameter Servers i Amazon SageMaker. Med hensyn til datapartitionering, hvis der er n beregne noder, så skal hver node få en delmængde af dataene, cirka 1/n i størrelse.
For at demonstrere effekten af at udskalere træning på modelkonvergens, kører vi to simple eksperimenter:
Hver modeltræning kørte to gange: på en enkelt instans og fordelt på flere instanser. Til den distribuerede DNN-uddannelse gange vi for at udnytte de distribuerede processorer fuldt ud mini-batchstørrelsen med antallet af instanser (fire). Følgende tabel opsummerer opsætningen og resultaterne.
Problektype | Billedklassificering | Binær klassifikation | ||
Model | DNN | XGBoost | ||
Instans | ml.c4.xlarge | ml.m5.2xstor | ||
Datasæt |
(Mærket billeder) |
Direkte marketing (tabel, numeriske og vektoriserede kategorier) |
||
Valideringsmetrik | Nøjagtighed | AUC | ||
Epoker/Runder | 20 | 150 | ||
Antal forekomster | 1 | 4 | 1 | 3 |
Distributionstype | N / A | Parameter server | N / A | AlleReducer |
Træningstid (minutter) | 8 | 3 | 3 | 1 |
Endelig valideringsscore | 0.97 | 0.11 | 0.78 | 0.63 |
For begge modeller blev træningstiden reduceret næsten lineært af fordelingsfaktoren. Modelkonvergensen faldt dog betydeligt. Denne adfærd er konsistent for de to forskellige modeller, de forskellige beregningsinstanser, de forskellige distributionsmetoder og forskellige datatyper. Så hvorfor påvirkede distribution af træningsprocessen modellens nøjagtighed?
Der er en række teorier, der forsøger at forklare denne effekt:
- Når tensoropdateringer er store i størrelse, kan trafikken mellem arbejdere og parameterserveren blive overbelastet. Derfor vil asynkrone parameterservere lide betydeligt dårligere konvergens på grund af forsinkelser i vægtopdateringer [1].
- Forøgelse af batchstørrelsen kan føre til overpasning og dårlig generalisering og derved reducere valideringsnøjagtigheden [2].
- Ved asynkron opdatering af modelparametre, bruger nogle DNN'er muligvis ikke de seneste opdaterede modelvægte; derfor vil de beregne gradienter baseret på vægte, der er et par iterationer bagud. Dette fører til vægttab [3] og kan være forårsaget af en række årsager.
- Nogle hyperparametre er model- eller optimeringsspecifikke. For eksempel siger den officielle XGBoost-dokumentation, at
exact
værdi fortree_mode
hyperparameter understøtter ikke distribueret træning, fordi XGBoost anvender rækkeopdelingsdatadistribution, mensexact
træmetoden fungerer på et sorteret kolonneformat. - Nogle forskere foreslog, at konfiguration af en større mini-batch kan føre til gradienter med mindre stokasticitet. Dette kan ske, når tabsfunktionen indeholder lokale minima og sadelpunkter, og der ikke ændres på trinstørrelsen, for at optimering sætter sig fast i sådanne lokale minima eller sadelpunkter [4].
Optimer til distribueret træning
Hyperparameteroptimering (HPO) er processen med at søge og vælge et sæt hyperparametre, der er optimale for en indlæringsalgoritme. SageMaker Automatic Model Tuning (AMT) leverer HPO som en administreret service ved at køre flere træningsjob på det medfølgende datasæt. SageMaker AMT søger i de intervaller af hyperparametre, du angiver, og returnerer de bedste værdier, målt med en metrik, du vælger. Du kan bruge SageMaker AMT med de indbyggede algoritmer eller bruge dine brugerdefinerede algoritmer og containere.
Optimering til distribueret træning adskiller sig dog fra almindelig HPO, fordi i stedet for at lancere en enkelt instans pr. træningsjob, lancerer hvert job faktisk en klynge af instanser. Dette betyder en større indvirkning på omkostningerne (især hvis du overvejer dyre GPU-accelererede instanser, som er typiske for DNN). I tillæg til AMT grænser, kan du muligvis ramme SageMaker-kontogrænser for samtidig antal træningstilfælde. Endelig kan lanceringsklynger indføre operationelle overhead på grund af længere starttid. SageMaker AMT har specifikke funktioner til at løse disse problemer. Hyperbånd med tidlig stop sikrer, at velfungerende hyperparametre konfigurationer finjusteres, og at de, der yder dårligt, automatisk stoppes. Dette muliggør effektiv udnyttelse af træningstiden og reducerer unødvendige omkostninger. SageMaker AMT understøtter også fuldt ud brugen af Amazon EC2 Spot Instances, som kan optimere uddannelsesomkostninger op til 90 % over on-demand-instanser. Med hensyn til lange starttider genbruger SageMaker AMT automatisk træningsinstanser inden for hvert tuningjob og reducerer derved den gennemsnitlige opstartstid for hver træningsjob med 20 gange. Derudover bør du følge med AMT bedste praksis, såsom at vælge de relevante hyperparametre, deres passende intervaller og skalaer og det bedste antal samtidige træningsjob og sætte et tilfældigt frø til at gengive resultater.
I det næste afsnit ser vi disse funktioner i aktion, mens vi konfigurerer, kører og analyserer et AMT-job ved hjælp af XGBoost-eksemplet, vi diskuterede tidligere.
Konfigurer, kør og analyser et tuningjob
Som tidligere nævnt kan kildekoden findes på GitHub repo. I trin 1-5 downloader og forbereder vi dataene, opretter xgb3
estimator (den distribuerede XGBoost-estimator er indstillet til at bruge tre forekomster), kør træningsjob og observer resultaterne. I dette afsnit beskriver vi, hvordan du konfigurerer tuning-jobbet for den estimator, forudsat at du allerede har gennemgået trin 1-5.
Et tuning-job beregner optimale hyperparametre for de træningsjob, det lancerer, ved at bruge en metrik til at evaluere ydeevne. Du kan konfigurere din egen metric, som SageMaker vil parse baseret på regex, du konfigurerer og udsender til stdout
, eller brug metrics for SageMaker indbyggede algoritmer. I dette eksempel bruger vi indbygget XGBoost objektiv metrik, så vi behøver ikke at konfigurere et regex. For at optimere til modelkonvergens optimerer vi baseret på validerings-AUC-metrikken:
Vi tuner syv hyperparametre:
- num_round – Antal runder til boostning under træningen.
- eta – Trinstørrelseskrympning brugt i opdateringer for at forhindre overpasning.
- alpha – L1-regulariseringsterm på vægte.
- min_barnevægt – Minimumssum af instansvægt (hessian) påkrævet hos et barn. Hvis træpartitionstrinnet resulterer i en bladknude med summen af forekomstens vægt mindre end
min_child_weight
, opgiver byggeprocessen yderligere opdeling. - max_depth – Maksimal dybde af et træ.
- colsample_bylevel – Subsamplingsforhold af kolonner for hver opdeling, i hvert niveau. Denne delprøvetagning finder sted én gang for hvert nyt dybdeniveau, der nås i et træ.
- colsample_bytree – Delprøveforhold mellem kolonner ved konstruktion af hvert træ. For hvert træ, der er konstrueret, sker delprøvetagningen én gang.
For at lære mere om XGBoost hyperparametre, se XGBoost Hyperparametre. Følgende kode viser de syv hyperparametre og deres intervaller:
Dernæst giver vi konfiguration til Hyperband-strategien og tunerobjektkonfigurationen ved hjælp af SageMaker SDK. HyperbandStrategyConfig
kan bruge to parametre: max_resource
(valgfrit) for det maksimale antal iterationer, der skal bruges til et træningsjob for at nå målet, og min_resource
– det mindste antal iterationer, der skal bruges af et træningsjob, før træningen stoppes. Vi bruger HyperbandStrategyConfig
at konfigurere StrategyConfig
, som senere bruges af tuning job definitionen. Se følgende kode:
Nu skaber vi en HyperparameterTuner
objekt, som vi videregiver følgende oplysninger til:
- XGBoost-estimatoren, indstillet til at køre med tre forekomster
- Det objektive metriske navn og definition
- Vores hyperparameter rækker
- Tuning af ressourcekonfigurationer, såsom antal træningsjob, der skal køres i alt, og hvor mange træningsjob, der kan køres parallelt
- Hyperbåndindstillinger (den strategi og konfiguration, vi konfigurerede i sidste trin)
- Tidlig stop (
early_stopping_type
) indstillet tilOff
Hvorfor indstiller vi tidligt stop til Off? Træningsjob kan stoppes tidligt, når det er usandsynligt, at de forbedrer den objektive metrik for hyperparameterindstillingsjobbet. Dette kan hjælpe med at reducere beregningstiden og undgå at overmontere din model. Hyperband bruger dog en avanceret indbygget mekanisme til at anvende tidlig stop. Derfor er parameteren early_stopping_type
skal indstilles til Off
når du bruger Hyperbands interne tidlige stopfunktion. Se følgende kode:
Til sidst starter vi det automatiske modelindstillingsjob ved at ringe til passer metode. Hvis du vil starte jobbet på en asynkron måde, skal du indstille wait
til False
. Se følgende kode:
Du kan følge jobbets fremskridt og resumé på SageMaker-konsollen. I navigationsruden under Kurser, vælg Hyperparameter tuning job, og vælg derefter det relevante tuningjob. Følgende skærmbillede viser tuning-jobbet med detaljer om træningsjobs status og ydeevne.
Når tuning-jobbet er færdigt, kan vi gennemgå resultaterne. I notebook-eksemplet viser vi, hvordan man udtrækker resultater ved hjælp af SageMaker SDK. Først undersøger vi, hvordan tuning-jobbet øgede modelkonvergensen. Du kan vedhæfte HyperparameterTuner
objekt ved hjælp af jobnavnet og kald beskrive metode. Metoden returnerer en ordbog, der indeholder metadata for justering af job og resultater.
I den følgende kode henter vi værdien af det bedst ydende træningsjob, målt ved vores objektive metrik (validerings-AUC):
Resultatet er 0.78 i AUC på valideringssættet. Det er en væsentlig forbedring i forhold til de oprindelige 0.63!
Lad os derefter se, hvor hurtigt vores træningsjob kørte. Til det bruger vi HyperparameterTuningJobAnalytics metode i SDK'et til at hente resultater om tuning-jobbet og læse ind i en Pandas-dataramme til analyse og visualisering:
Lad os se den gennemsnitlige tid et træningsjob tog med Hyperband-strategi:
Den gennemsnitlige tid tog cirka 1 minut. Dette er i overensstemmelse med Hyperband-strategimekanismen, der stopper underpræsterende træningsjob tidligt. Med hensyn til omkostninger opkrævede tuning-jobbet os for i alt 30 minutters træningstid. Uden tidlig stop af Hyperband forventedes den samlede fakturerbare træningsvarighed at være 90 minutter (30 job * 1 minut pr. job * 3 tilfælde pr. job). Det er tre gange bedre i omkostningsbesparelser! Endelig ser vi, at tuning-jobbet kørte 30 træningsjob og tog i alt 12 minutter. Det er næsten 50 % mindre af den forventede tid (30 jobs/4 job parallelt * 3 minutter pr. job).
Konklusion
I dette indlæg beskrev vi nogle observerede konvergensproblemer ved træning af modeller med distribuerede miljøer. Vi så, at SageMaker AMT ved hjælp af Hyperband adresserede de vigtigste bekymringer, som optimering af data parallelt distribueret træning introducerede: konvergens (som blev forbedret med mere end 10 %), driftseffektivitet (tuning-jobbet tog 50 % mindre tid end et sekventielt, ikke-optimeret job ville har taget) og omkostningseffektivitet (30 vs. de 90 fakturerbare minutter af træningsjobtid). Følgende tabel opsummerer vores resultater:
Forbedringsmetrik | Ingen Tuning/Naiv Model Tuning Implementering | SageMaker Hyperband Automatisk Model Tuning | Målt forbedring |
Modelkvalitet (Målt ved validerings-AUC) |
0.63 | 0.78 | 15 % |
Koste (Målt ved fakturerbare træningsminutter) |
90 | 30 | 66 % |
Driftseffektivitet (Målt ved samlet køretid) |
24 | 12 | 50 % |
For at finjustere med hensyn til skalering (klyngestørrelse), kan du gentage tuning-jobbet med flere klyngekonfigurationer og sammenligne resultaterne for at finde de optimale hyperparametre, der tilfredsstiller hastighed og modelnøjagtighed.
Vi inkluderede trinene til at opnå dette i det sidste afsnit af notesbog.
Referencer
[1] Lian, Xiangru, et al. "Asynkron decentraliseret parallel stokastisk gradientnedstigning." International konference om maskinlæring. PMLR, 2018.
[2] Keskar, Nitish Shirish, et al. "Om stor-batch træning til dyb læring: Generaliseringsgab og skarpe minima." arXiv fortryk arXiv:1609.04836 (2016).
[3] Dai, Wei, et al. "I retning af at forstå virkningen af forældethed i distribueret maskinlæring." arXiv fortryk arXiv:1810.03264 (2018).
[4] Dauphin, Yann N., et al. "Identifikation og angreb af sadelpunktsproblemet i højdimensionel ikke-konveks optimering." Fremskridt inden for neurale informationsbehandlingssystemer 27 (2014).
Om forfatteren
Uri Rosenberg er AI & ML Specialist Technical Manager for Europa, Mellemøsten og Afrika. Med base i Israel arbejder Uri på at give virksomhedskunder mulighed for at designe, bygge og drive ML-arbejdsbelastninger i stor skala. I sin fritid nyder han at cykle, vandre og klage over dataforberedelse.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
- PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
- PlatoESG. Automotive/elbiler, Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
- BlockOffsets. Modernisering af miljømæssig offset-ejerskab. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/effectively-solve-distributed-training-convergence-issues-with-amazon-sagemaker-hyperband-automatic-model-tuning/
- :har
- :er
- :ikke
- $OP
- 1
- 10
- 100
- 12
- 15 %
- 20
- 200
- 2014
- 2016
- 2018
- 24
- 27
- 30
- 7
- 8
- 9
- a
- Om
- Konto
- nøjagtighed
- præcis
- opnå
- Handling
- faktisk
- Desuden
- Derudover
- adresse
- adresser
- fremskreden
- påvirke
- afrika
- AI
- AL
- algoritme
- algoritmer
- Alpha
- allerede
- også
- forbløffende
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- blandt
- an
- analyse
- analytics
- analysere
- ,
- En anden
- api
- Indløs
- passende
- cirka
- ER
- AS
- At
- vedhæfte
- At angribe
- Automatisk Ur
- automatisk
- gennemsnit
- undgå
- AWS
- Balance
- baseret
- BE
- fordi
- før
- adfærd
- bag
- BEDSTE
- Bedre
- mellem
- Big
- fremme
- både
- bygge
- Bygning
- indbygget
- by
- beregning
- ringe
- ringer
- CAN
- Kan få
- kapaciteter
- kategorier
- forårsagede
- lave om
- opladet
- barn
- Vælg
- vælge
- klik
- Cluster
- kode
- Kolonne
- Kolonner
- Kom
- Fælles
- sammenligne
- fuldføre
- Compute
- Bekymringer
- konkurrent
- Konference
- Konfiguration
- konfigureret
- Overvej
- konsekvent
- Konsol
- konstruere
- Beholdere
- indeholder
- kontinuerligt
- Konvergens
- Koste
- kostbar
- Omkostninger
- kunne
- skabe
- skik
- Kunder
- DAI
- data
- Dataforberedelse
- decentral
- dyb
- dyb læring
- definition
- forsinkelser
- demonstrere
- dybde
- beskrive
- beskrevet
- Design
- udpeget
- detaljer
- DID
- forskellige
- drøftet
- distribueret
- distribueret træning
- distribution
- fordeling
- do
- dokumentation
- Er ikke
- færdig
- Dont
- ned
- downloade
- Drop
- grund
- varighed
- i løbet af
- E&T
- hver
- tidligere
- Tidligt
- nemt
- Øst
- effekt
- effektivt
- effektivitet
- effektiv
- beskæftiger
- bemyndige
- muliggøre
- muliggør
- sikrer
- Enterprise
- Miljø
- miljøer
- især
- Europa
- evaluere
- Endog
- Hver
- undersøge
- eksempel
- forventet
- eksperimenter
- Forklar
- udforske
- ekstrakt
- faktor
- faktorer
- Mode
- FAST
- hurtigere
- Feature
- Funktionalitet
- få
- Endelig
- Finde
- Fornavn
- passer
- følger
- efter
- Til
- format
- fundet
- fire
- FRAME
- fra
- fuldt ud
- funktion
- yderligere
- Endvidere
- kløft
- generative
- Generativ AI
- generatorer
- få
- få
- giver
- godt
- GPU
- GPU'er
- gradienter
- større
- Vækst
- ske
- Have
- have
- he
- hjælpe
- hans
- Hit
- Hvordan
- How To
- Men
- HTML
- http
- HTTPS
- Tuning af hyperparameter
- if
- billeder
- KIMOs Succeshistorier
- Påvirkninger
- Forbedre
- forbedret
- in
- medtaget
- øget
- oplysninger
- Infrastruktur
- initial
- instans
- i stedet
- interne
- ind
- indføre
- introduceret
- israel
- spørgsmål
- IT
- iterationer
- ITS
- Job
- Karriere
- Holde
- L1
- Sprog
- stor
- større
- Efternavn
- senere
- lancere
- lanceringer
- lancering
- føre
- Leads
- LÆR
- læring
- mindre
- Niveau
- biblioteker
- ligesom
- lokale
- Lang
- længere
- off
- maskine
- machine learning
- lavet
- Main
- lykkedes
- leder
- mange
- massive
- maksimal
- Kan..
- midler
- mekanisme
- nævnte
- Metadata
- metode
- metoder
- metrisk
- Metrics
- Mellemøsten
- Middle East
- måske
- minimum
- minut
- minutter
- ML
- model
- modeller
- mere
- mest
- flere
- ganget
- skal
- navn
- Natural
- Navigation
- Behov
- behov
- behov
- net
- neurale netværk
- Ny
- næste
- ingen
- node
- noder
- notesbog
- nummer
- objekt
- objektiv
- observere
- of
- off
- officiel
- tit
- on
- On-Demand
- engang
- ONE
- kun
- åbning
- betjene
- operationelle
- optimal
- optimering
- Optimer
- optimering
- or
- ordrer
- vores
- ud
- i løbet af
- samlet
- egen
- pandaer
- brød
- Parallel
- parameter
- parametre
- passerer
- per
- ydeevne
- Place
- plato
- Platon Data Intelligence
- PlatoData
- Punkt
- punkter
- fattige
- muligheder
- eventuelt
- Indlæg
- praksis
- forberedelse
- Forbered
- forhindre
- Problem
- behandle
- forarbejdning
- processorer
- Progress
- foreslog
- give
- forudsat
- giver
- tilfældig
- forholdet
- nået
- Læs
- årsager
- nylige
- anbefales
- reducere
- Reduceret
- reducerer
- reducere
- hilsen
- regulært udtryk
- relevant
- gentag
- kræver
- Kræver
- forskere
- ressource
- Ressourcer
- resultere
- Resultater
- afkast
- gennemgå
- runder
- RÆKKE
- Kør
- kører
- sagemaker
- SageMaker Automatisk Model Tuning
- samme
- Gem
- så
- siger
- SC
- Scale
- skalaer
- skalering
- SDK
- søgning
- Sektion
- se
- frø
- set
- udvælgelse
- Servere
- tjeneste
- Tjenester
- sæt
- indstilling
- indstillinger
- setup
- syv
- skarp
- bør
- Vis
- vist
- Shows
- Luk ned
- signifikant
- betydeligt
- Simpelt
- enkelt
- Størrelse
- So
- SOLVE
- nogle
- Kilde
- kildekode
- Space
- specialist
- specifikke
- hastighed
- delt
- splits
- Spot
- starte
- Starter
- opstart
- Status
- Trin
- Steps
- stoppet
- standsning
- stopper
- opbevaring
- Strategi
- sådan
- lidt
- RESUMÉ
- support
- Understøtter
- bord
- taget
- tager
- Teknisk
- teknikker
- tensorflow
- semester
- vilkår
- end
- at
- The Source
- deres
- Them
- derefter
- Der.
- derved
- derfor
- Disse
- de
- denne
- dem
- tre
- Gennem
- tid
- gange
- til
- tog
- I alt
- Trafik
- Tog
- uddannet
- Kurser
- overførsler
- træ
- prøv
- To gange
- to
- typer
- typisk
- under
- forståelse
- usandsynligt
- unødvendig
- opdateret
- opdateringer
- opdatering
- us
- brug
- anvendte
- bruger
- ved brug af
- udnytte
- validering
- værdi
- Værdier
- visualisering
- vs
- ønsker
- var
- Vej..
- we
- web
- webservices
- vægt
- gik
- hvornår
- ud fra følgende betragtninger
- som
- hvorfor
- Wikipedia
- vilje
- med
- inden for
- uden
- arbejdere
- virker
- værre
- ville
- XGBoost
- år
- Du
- Din
- zephyrnet