Sprogmodeller er statistiske metoder, der forudsiger rækkefølgen af tokens i sekvenser, ved hjælp af naturlig tekst. Store sprogmodeller (LLM'er) er neurale netværksbaserede sprogmodeller med hundreder af millioner (BERTI) til over en billion parametre (MiCS), og hvis størrelse gør single-GPU-træning upraktisk. LLM'ers generative evner gør dem populære til tekstsyntese, opsummering, maskinoversættelse og meget mere.
Størrelsen af en LLM og dens træningsdata er et tveægget sværd: det bringer modelleringskvalitet, men medfører infrastrukturudfordringer. Selve modellen er ofte for stor til at passe i hukommelsen på en enkelt GPU-enhed eller på flere enheder i en multi-GPU-instans. Disse faktorer kræver træning af en LLM over store klynger af accelereret maskinlæring (ML)-instanser. I de sidste par år har adskillige kunder brugt AWS Cloud til LLM-træning.
I dette indlæg dykker vi ned i tips og bedste praksis for vellykket LLM-træning på Amazon SageMaker træning. SageMaker Training er en administreret batch ML-beregningstjeneste, der reducerer tiden og omkostningerne til at træne og tune modeller i skala uden behov for at administrere infrastruktur. Inden for en startkommando, Amazon SageMaker lancerer en fuldt funktionel, flygtig computerklynge, der kører opgaven efter eget valg, og med forbedrede ML-funktioner såsom metastore, administreret I/O og distribution. Indlægget dækker alle faser af en LLM-træningsarbejdsmængde og beskriver tilhørende infrastrukturfunktioner og bedste praksis. Nogle af de bedste fremgangsmåder i dette indlæg refererer specifikt til ml.p4d.24xlarge-forekomster, men de fleste er anvendelige til enhver forekomsttype. Disse bedste praksisser giver dig mulighed for at træne LLM'er på SageMaker i størrelsesordenen dusinvis til hundredvis af millioner af parametre.
Med hensyn til omfanget af dette indlæg, bemærk følgende:
- Vi dækker ikke videnskabeligt design af neurale netværk og tilhørende optimeringer. Amazon.Science indeholder adskillige videnskabelige publikationer, herunder og ikke begrænset til LLM'er.
- Selvom dette indlæg fokuserer på LLM'er, er de fleste af dets bedste praksis relevante for enhver form for træning i store modeller, inklusive computersyn og multimodale modeller, såsom stabil diffusion.
Bedste praksis
Vi diskuterer følgende bedste praksis i dette indlæg:
- Compute – SageMaker Training er en fantastisk API til at starte CPU-datasætforberedelsesjob og tusindskala GPU-job.
- Opbevaring – Vi ser dataindlæsning og checkpointing udføres på to måder, afhængigt af færdigheder og præferencer: med en Amazon FSx Luster filsystem, eller Amazon Simple Storage Service Kun (Amazon S3).
- parallelitet – Dit valg af distribueret træningsbibliotek er afgørende for korrekt brug af GPU'erne. Vi anbefaler at bruge et cloud-optimeret bibliotek, såsom SageMaker sharded data parallelism, men selvadministrerede og open source-biblioteker kan også fungere.
- netværk – Sørg for, at EFA og NVIDIA GPUDirectRDMA er aktiveret for hurtig kommunikation mellem maskinen.
- Resiliency – I stor skala kan der ske hardwarefejl. Vi anbefaler, at du regelmæssigt kontrollerer. Hvert par timer er almindeligt.
Regionsvalg
Forekomsttype og ønsket kapacitet er en afgørende faktor for valg af region. For regionerne støttet af SageMaker og Amazon Elastic Compute Cloud (Amazon EC2) instanstyper, der er tilgængelige i hver region, se Amazon SageMaker-priser. I dette indlæg antager vi, at træningsinstanstypen er en SageMaker-administreret ml.p4d.24xlarge.
Vi anbefaler, at du arbejder med dit AWS-kontoteam eller kontakter AWS salg for at bestemme den passende region for din LLM-arbejdsbyrde.
Forberedelse af data
LLM-udviklere træner deres modeller på store datasæt af naturligt forekommende tekst. Populære eksempler på sådanne datakilder omfatter Almindelig gennemgang , Bunken. Naturlig forekommende tekst kan indeholde skævheder, unøjagtigheder, grammatiske fejl og syntaksvariationer. En LLM's eventuelle kvalitet afhænger væsentligt af udvælgelsen og kurationen af træningsdataene. LLM-træningsdataforberedelse er et aktivt område for forskning og innovation i LLM-industrien. Udarbejdelsen af et datasæt til naturlig sprogbehandling (NLP) bugner af muligheder for at dele-intet parallelitet. Med andre ord er der trin, der kan anvendes på enheder af værker – kildefiler, afsnit, sætninger, ord – uden at kræve synkronisering mellem medarbejdere.
SageMaker job API'erne, nemlig SageMaker Training og SageMaker Processing, udmærker sig til denne type opgaver. De gør det muligt for udviklere at køre en vilkårlig Docker-container over en flåde af flere maskiner. I tilfælde af SageMaker Training API, kan computerflåden være heterogen. Adskillige distribuerede computing frameworks er blevet brugt på SageMaker, bl.a Dashboard, Ray, og også PySpark, som har en dedikeret AWS-administreret container , SDK i SageMaker Processing.
Når du starter et job med flere maskiner, kører SageMaker Training and Processing din kode én gang pr. maskine. Du behøver ikke at bruge en bestemt distribueret computerramme for at skrive en distribueret applikation: du kan skrive den kode efter eget valg, som vil køre én gang pr. maskine, for at realisere dele-intet parallelitet. Du kan også skrive eller installere den inter-node kommunikationslogik efter eget valg.
Dataindlæsning
Der er flere måder at gemme træningsdataene på og flytte dem fra deres lager til de accelererede beregningsknuder. I dette afsnit diskuterer vi mulighederne og bedste praksis for dataindlæsning.
SageMaker opbevaring og indlæsningsmuligheder
En typisk LLM-datasætstørrelse er i hundreder af millioner af teksttokens, der repræsenterer et par hundrede gigabyte. SageMaker-administrerede klynger af ml.p4d.24xlarge-instanser foreslår flere muligheder for datasætlagring og -indlæsning:
- On-node NVMe SSD – ml.P4d.24xlarge instanser er udstyret med 8TB NVMe, tilgængelig under
/opt/ml/input/data/<channel>
hvis du bruger SageMaker filtilstand, og kl/tmp
. Hvis du søger enkelheden og ydeevnen af en lokal læsning, kan du kopiere dine data til NVMe SSD'en. Kopieringen kan enten udføres af SageMaker File-tilstand eller med din egen kode, for eksempel ved hjælp af multi-processed Boto3 or S5cmd. - FSx for Luster – On-node NVMe SSD'er er begrænset i størrelse og kræver indtagelse fra Amazon S3 ved hvert job eller varm klyngeoprettelse. Hvis du ønsker at skalere til større datasæt, mens du bevarer tilfældig adgang med lav latens, kan du bruge FSx til Lustre. Amazon FSx er et parallelt open source-filsystem, populært inden for højtydende computing (HPC). FSx til Luster-brug distribueret fillagring (stripping) og fysisk adskiller filmetadata fra filindhold for at opnå højtydende læsning/skrivning.
- SageMaker FastFile-tilstand – FastFile-tilstand (FFM) er en SageMaker-kun-funktion, der præsenterer eksterne S3-objekter i SageMaker-administrerede computerforekomster under en POSIX-kompatibel grænseflade og kun streamer dem ved læsning ved hjælp af FUSE. FFM læser resultater i S3-opkald, der streamer fjernfiler blok for blok. Som en bedste praksis for at undgå fejl relateret til Amazon S3-trafik, bør FFM-udviklere sigte mod at holde det underliggende antal S3-opkald rimeligt, for eksempel ved at læse filer sekventielt og med en kontrolleret mængde parallelitet.
- Selvstyret dataindlæsning – Du kan selvfølgelig også beslutte at implementere din egen, fuldt tilpassede dataindlæsningslogik ved hjælp af proprietær eller open source-kode. Nogle grunde til at bruge selvadministreret dataindlæsning er at lette en migrering ved at genbruge allerede udviklet kode, for at implementere tilpasset fejlhåndteringslogik eller for at have mere kontrol over underliggende ydeevne og sharding. Eksempler på biblioteker, du kan bruge til selvadministreret dataindlæsning, omfatter torchdata.datapipes (tidligere AWS PyTorch S3-plugin) og Webdatasæt. AWS Python SDK Boto3 kan også kombineres med Torch Datasæt klasser for at oprette tilpasset dataindlæsningskode. Tilpassede dataindlæsningsklasser muliggør også kreativ brug af SageMaker Training heterogene klynger for fint at tilpasse CPU- og GPU-balancen til en given arbejdsbyrde.
For mere information om disse muligheder, og hvordan du vælger dem, se Vælg den bedste datakilde til dit Amazon SageMaker-uddannelsesjob.
Bedste praksis for storstilet interaktion med Amazon S3
Amazon S3 er i stand til at håndtere LLM-arbejdsbelastninger, både til datalæsning og checkpointing. Den understøtter en anmodningssats på 3,500 PUT/COPY/POST/DELETE eller 5,500 GET/HEAD-anmodninger pr. sekund pr. præfiks i en bøtte. Denne sats er dog ikke nødvendigvis tilgængelig som standard. I stedet for, når anmodningsfrekvensen for et præfiks vokser, skalerer Amazon S3 automatisk for at håndtere den øgede hastighed. For mere information, se Hvorfor får jeg 503 Slow Down-fejl fra Amazon S3, når anmodningerne er inden for den understøttede anmodningshastighed pr. præfiks.
Hvis du forventer højfrekvent Amazon S3-interaktion, anbefaler vi følgende bedste praksis:
- Prøv at læse og skrive fra flere S3 buckets og præfikser. For eksempel kan du opdele træningsdata og kontrolpunkter på tværs af forskellige præfikser.
- Tjek Amazon S3-metrics ind amazoncloudwatch for at spore anmodningsrater.
- Prøv at minimere mængden af samtidig PUT/GET:
- Har færre processer, der bruger Amazon S3 på samme tid. For eksempel, hvis otte processer pr. noder skal checkpoint til Amazon S3, kan du reducere PUT-trafik med en faktor 8 ved at checkpointe hierarkisk: først inden for node, derefter fra noden til Amazon S3.
- Læs flere træningsposter fra en enkelt fil eller S3 GET i stedet for at bruge en S3 GET for hver træningsrekord.
- Hvis du bruger Amazon S3 via SageMaker FFM, foretager SageMaker FFM S3-opkald for at hente filer stykke for stykke. For at begrænse Amazon S3-trafikken, der genereres af FFM, opfordrer vi dig til at læse filer sekventielt og begrænse antallet af filer, der åbnes parallelt.
Hvis du har en Supportplan for udviklere, virksomheder eller virksomheder, kan du åbne en teknisk supportsag om S3 503 Slow Down-fejl. Men sørg først for, at du har fulgt den bedste praksis, og få anmodnings-id'erne for de mislykkede anmodninger.
Træningsparallelisme
LLM'er har almindeligvis snesevis til hundredvis af milliarder af parametre, hvilket gør dem for store til at passe ind i et enkelt NVIDIA GPU-kort. LLM-udøvere har udviklet adskillige open source-biblioteker, der letter den distribuerede beregning af LLM-træning, bl.a. FSDP, DeepSpeed , Megatron. Du kan køre disse biblioteker i SageMaker Training, men du kan også bruge SageMaker distribuerede træningsbiblioteker, som er optimeret til AWS Cloud og giver en enklere udvikleroplevelse. Udviklere har to valgmuligheder for distribueret træning af deres LLM på SageMaker: distribuerede biblioteker eller selvadministrerede.
SageMaker distribuerede biblioteker
For at give dig forbedret distribueret træningsydelse og brugervenlighed, foreslår SageMaker Training adskillige proprietære udvidelser til at skalere TensorFlow og PyTorch træningskode. LLM-uddannelse udføres ofte på en 3D-parallelistisk måde:
- Dataparallelisme opdeler og fodrer træningsminibatches til flere identiske kopier af modellen for at øge behandlingshastigheden
- Pipeline parallelitet tilskriver forskellige lag af modellen til forskellige GPU'er eller endda instanser for at skalere modelstørrelsen ud over en enkelt GPU og en enkelt server
- Tensor parallelisme opdeler et enkelt lag i flere GPU'er, normalt inden for den samme server, for at skalere individuelle lag til størrelser, der overstiger en enkelt GPU
I det følgende eksempel trænes en 6-lags model på en klynge af k*3 servere med 8*k*3 GPU'er (8 GPU'er pr. server). Dataparallelismegrad er k, pipelineparallelisme 6 og tensorparallelisme 4. Hver GPU i klyngen indeholder en fjerdedel af et modellag, og en fuld model er opdelt over tre servere (24 GPU'er i alt).
Følgende er specifikt relevante for LLM'er:
- SageMaker distribuerede model parallelt – Dette bibliotek bruger grafpartitionering til at producere intelligent modelpartitionering optimeret til hastighed eller hukommelse. SageMaker distribuerede modelparallel afslører den nyeste og bedste træningsoptimering for store modeller, herunder dataparallelisme, pipelineparallelisme, tensorparallelisme, optimeringstilstandsskæring, aktiveringskontrolpunkt og aflæsning. Med SageMaker distribuerede model-parallelle bibliotek dokumenterede vi en 175-milliarder parametermodeltræning over 920 NVIDIA A100 GPU'er. For mere information, se Træn 175+ milliarder parameter NLP-modeller med parallelle modeltilføjelser og Hugging Face på Amazon SageMaker.
- SageMaker sønderdelte data parallelt - i MiCS: Nær-lineær skalering til træning af gigantisk model på Public CloudZhang et al. indføre en parallelstrategi med lav kommunikationsmodel, der kun opdeler modeller over en dataparallel gruppe i stedet for hele klyngen. Med MiCS var AWS-forskere i stand til at opnå 176 teraflops pr. GPU (56.4% af den teoretiske top) til træning af en 210-lags 1.06-billion-parameter-model på EC2 P4de-instanser. MiCS er nu tilgængelig for SageMaker Training-kunder som SageMaker sønderdelte data parallelt.
SageMaker distribuerede træningsbiblioteker giver høj ydeevne og en enklere udvikleroplevelse. Især behøver udviklere ikke at skrive og vedligeholde en brugerdefineret parallelprocesstarter eller bruge et rammespecifikt lanceringsværktøj, fordi parallelstarteren er indbygget i joblancerings-SDK'en.
Selvstyret
Med SageMaker Training har du friheden til at bruge rammerne og det videnskabelige paradigme efter eget valg. Især hvis du selv vil administrere distribueret træning, har du to muligheder for at skrive din tilpassede kode:
- Brug en AWS Deep Learning Container (DLC) – AWS udvikler og vedligeholder DLCs, der leverer AWS-optimerede Docker-baserede miljøer til top open source ML-frameworks. SageMaker Training har en unik integration, der giver dig mulighed for at trække og køre AWS DLC'er med eksternt, brugerdefineret indgangspunkt. Specielt til LLM-træning er AWS DLC'er til TensorFlow, PyTorch, Hugging Face og MXNet særligt relevante. Brug af en framework DLC giver dig mulighed for at bruge framework-native parallelism, såsom PyTorch Distributed, uden at skulle udvikle og administrere dine egne Docker-billeder. Derudover har vores DLC'er en MPI integration, som giver dig mulighed for nemt at starte parallel kode.
- Skriv et brugerdefineret SageMaker-kompatibelt Docker-billede – Du kan medbringe dit eget (BYO) billede (se Brug dine egne træningsalgoritmer , Amazon SageMaker Custom Training containere), enten starte fra bunden eller udvide et eksisterende DLC-billede. Når du bruger et brugerdefineret billede til LLM-træning på SageMaker, er det særligt vigtigt at verificere følgende:
- Dit billede indeholder EFA med passende indstillinger (omtales mere senere i dette indlæg)
- Dit billede indeholder et NVIDIA NCCL-kommunikationsbibliotek, aktiveret med GPUDirectRDMA
Kunder har været i stand til at bruge en række selvadministrerede distribuerede træningsbiblioteker, herunder DeepSpeed.
Kommunikation
I betragtning af den distribuerede karakter af et LLM-træningsjob er kommunikation mellem maskiner afgørende for gennemførligheden, ydeevnen og omkostningerne ved arbejdsbyrden. I dette afsnit præsenterer vi nøglefunktioner til kommunikation mellem maskinen og afslutter med tips til installation og tuning.
Elastisk stofadapter
For at accelerere ML-applikationer og forbedre ydeevnen ved at opnå fleksibilitet, skalerbarhed og elasticitet fra skyen, kan du drage fordel af Elastisk stofadapter (EFA) med SageMaker. Vores erfaring er, at brug af EFA er et krav for at opnå en tilfredsstillende multi-node LLM træningsydelse.
En EFA-enhed er en netværksgrænseflade knyttet til EC2-instanser, der administreres af SageMaker under afviklingen af træningsjob. EFA er tilgængelig på specifikke familier af tilfælde, herunder P4d. EFA-netværk er i stand til at opnå flere hundrede Gbps gennemløb.
Tilknyttet EFA har AWS introduceret Skalerbart pålideligt datagram (SRD), en ethernet-baseret transport inspireret af InfiniBand Reliable Datagram, udviklet med afslappet pakkebestillingsbegrænsning. For mere information om EFA og SRD, se I søgen efter ydeevne er der mere end én måde at opbygge et netværk på, videoen Hvordan EFA fungerer, og hvorfor vi ikke bruger infiniband i skyenog forskningspapiret En skyoptimeret transportprotokol til elastisk og skalerbar HPC fra Shalev et al.
Du kan tilføje EFA-integration på kompatible instanser til SageMaker eksisterende Docker-containere eller brugerdefinerede containere, der kan bruges til træning af ML-modeller ved hjælp af SageMaker-job. For mere information, se Løbtræning med EFA. EFA eksponeres via open source Libfabric kommunikationspakke. LLM-udviklere programmerer det dog sjældent direkte med Libfabric, og stoler normalt i stedet på NVIDIA Collective Communications Library (NCCL).
AWS-OFI-NCCL plugin
I distribueret ML bruges EFA oftest med NVIDIA Collective Communications Library (NCCL). NCCL er et NVIDIA-udviklet open source-bibliotek, der implementerer inter-GPU-kommunikationsalgoritmer. Inter-GPU-kommunikation er en hjørnesten i LLM-træning, der katalyserer skalerbarhed og ydeevne. Det er så afgørende for DL-træning, at NCCL ofte er direkte integreret som en kommunikations-backend i deep learning-træningsbiblioteker, så LLM-udviklere bruger det – nogle gange uden at bemærke det – fra deres foretrukne Python DL-udviklingsramme. For at bruge NCCL på EFA bruger LLM-udviklere den AWS-udviklede AWS OFI NCCL plugin, som kortlægger NCCL-kald til Libfabric-grænsefladen, der bruges af EFA. Vi anbefaler at bruge den seneste version af AWS OFI NCCL for at drage fordel af de seneste forbedringer.
For at kontrollere, at NCCL bruger EFA, skal du indstille miljøvariablen NCCL_DEBUG
til INFO
, og tjek i loggene, at EFA er indlæst af NCCL:
For mere information om NCCL- og EFA-konfigurationen, se Test din EFA- og NCCL-konfiguration. Du kan yderligere tilpasse NCCL med flere miljøvariabler. Bemærk, at effektivt i NCCL 2.12 og nyere, bidrog AWS med en automatiseret kommunikationsalgoritmevalglogik til EFA-netværk (NCCL_ALGO
kan efterlades deaktiveret).
NVIDIA GPUDirect RDMA over EFA
Med P4d-instanstypen har vi introduceret GPUDirect RDMA (GDR) over EFA-stof. Det gør det muligt for netværksinterfacekort (NIC'er) at få direkte adgang til GPU-hukommelse, hvilket gør ekstern GPU-til-GPU-kommunikation på tværs af NVIDIA GPU-baserede EC2-instanser hurtigere, hvilket reducerer orkestreringsomkostninger på CPU'er og brugerapplikationer. GDR bruges under hætten af NCCL, når det er muligt.
GDR-brug vises i inter-GPU-kommunikation, når logniveauet er indstillet til INFO, som i følgende kode:
Brug af EFA i AWS Deep Learning Containers
AWS vedligeholder Deep Learning Containers (DLC'er), hvoraf mange kommer med AWS-administrerede Dockerfiler og bygget indeholdende EFA, AWS OFI NCCL og NCCL. Følgende GitHub-repos tilbyder eksempler med PyTorch , TensorFlow. Du behøver ikke selv at installere disse biblioteker.
Brug af EFA i din egen SageMaker Training container
Hvis du opretter din egen SageMaker Training-container og ønsker at bruge NCCL over EFA til accelereret inter-node kommunikation, skal du installere EFA, NCCL og AWS OFI NCCL. For mere information, se Løbtræning med EFA. Derudover bør du indstille følgende miljøvariabler i din container eller i din indgangskode:
FI_PROVIDER="efa"
angiver udbyderen af stofgrænsefladenNCCL_PROTO=simple
instruerer NCCL om at bruge en simpel protokol til kommunikation (i øjeblikket understøtter EFA-udbyderen ikke LL-protokoller; aktivering af dem kan føre til datakorruption)FI_EFA_USE_DEVICE_RDMA=1
bruger enhedens RDMA-funktionalitet til en- og tosidet overførselNCCL_LAUNCH_MODE="PARALLEL"
NCCL_NET_SHARED_COMMS="0"
Orchestration
Håndtering af livscyklussen og arbejdsbyrden for snesevis til hundredvis af computerforekomster kræver orkestreringssoftware. I dette afsnit tilbyder vi bedste praksis for LLM-orkestrering
Inden job orkestrering
Udviklere skal skrive både server-side træningskode og klient-side launcher-kode i de fleste distribuerede rammer. Træningskode kører på træningsmaskiner, hvorimod opstartskode på klientsiden starter den distribuerede arbejdsbyrde fra en klientmaskine. Der er lidt standardisering i dag, for eksempel:
- I PyTorch kan udviklere starte opgaver med flere maskiner vha
torchrun
,torchx
,torch.distributed.launch
(afskrivningssti), ellertorch.multiprocessing.spawn
- DeepSpeed foreslår sin egen deepspeed CLI launcher og understøtter også MPI-lancering
- MPI er en populær parallel computing-ramme, der har fordelen af at være ML-agnostisk og rimeligt fastansat, og derfor stabil og dokumenteret, og ses i stigende grad i distribuerede ML-arbejdsbelastninger
I en SageMaker Training cluster lanceres træningsbeholderen én gang på hver maskine. Du har derfor tre muligheder:
- Native launcher – Du kan bruge den native launcher til en bestemt DL-ramme som et indgangspunkt, for eksempel en
torchrun
opkald, som i sig selv vil afføde flere lokale processer og etablere kommunikation på tværs af instanser. - SageMaker MPI integration – Du kan bruge SageMaker MPI-integration, tilgængelig i vores AWS DLC, eller selvinstallerbar via salviemager-trænings-værktøjssæt, for direkte at køre din indgangskode N gange pr. maskine. Dette har den fordel, at du undgår brugen af mellemliggende, rammespecifikke launcher-scripts i din egen kode.
- SageMaker distribuerede biblioteker – Hvis du bruger de distribuerede SageMaker-biblioteker, kan du fokusere på træningskoden og behøver slet ikke at skrive launcher-kode! SageMaker distribueret launcher kode er indbygget i SageMaker SDK.
Inter-job orkestrering
LLM-projekter består ofte af flere job: parametersøgning, skaleringseksperimenter, retablering fra fejl og mere. For at starte, stoppe og parallelisere træningsopgaver er det vigtigt at bruge en joborkestrator. SageMaker Training er en serverløs ML-joborkestrator, der leverer transient compute-instanser umiddelbart efter anmodning. Du betaler kun for det, du bruger, og klynger bliver dekommissioneret, så snart din kode slutter. Med SageMaker Trænings Varme Pools, har du mulighed for at definere en time-to-live på træningsklynger, for at genbruge den samme infrastruktur på tværs af job. Dette reducerer iterationstid og variabilitet mellem jobplacering. SageMaker-job kan lanceres fra en række forskellige programmeringssprog, herunder Python , CLI.
Der er en SageMaker-specifik Python SDK kaldet SageMaker Python SDK og implementeret via sagemaker Python-biblioteket, men dets brug er valgfrit.
Øge kvoterne for uddannelsesjobs med en stor og lang uddannelsesklynge
SageMaker har standardkvoter på ressourcer, designet til at forhindre utilsigtet brug og omkostninger. For at træne en LLM ved hjælp af en stor klynge af avancerede instanser, der kører i lang tid, skal du sandsynligvis øge kvoterne i følgende tabel.
Kvotenavn | Standard værdi |
Længste løbetid for et træningsjob | 432,000 sekunder |
Antal forekomster på tværs af alle uddannelsesjob | 4 |
Maksimalt antal tilfælde pr. træningsjob | 20 |
ml.p4d.24xlarge til træningsjobbrug | 0 |
ml.p4d.24xlarge til træning af varm poolbrug | 0 |
Se AWS servicekvoter hvordan du får vist dine kvoteværdier og anmoder om en kvoteforhøjelse. On-Demand, Spot Instance og trænings-varmepools-kvoter spores og ændres separat.
Hvis du beslutter dig for at holde SageMaker Profiler aktiveret, skal du være opmærksom på, at hvert træningsjob lancerer et SageMaker Processing-job, der hver forbruger en ml.m5.2xlarge instans. Bekræft, at dine SageMaker Processing-kvoter er høje nok til at imødekomme den forventede samtidighed med træningsjob. Hvis du f.eks. vil starte 50 Profiler-aktiverede træningsjob, der kører samtidigt, skal du hæve grænsen for ml.m5.2xlarge for behandling af jobbrug til 50.
For at starte et langvarigt job skal du desuden udtrykkeligt indstille Estimator max_run
parameter til den ønskede maksimale varighed for træningsjobbet i sekunder, op til kvoteværdien for den længste løbetid for et træningsjob.
Overvågning og robusthed
Hardwarefejl er ekstremt sjælden i omfanget af en enkelt forekomst og bliver mere og mere hyppig, efterhånden som antallet af anvendte forekomster stiger samtidigt. På typisk LLM-skala - hundreder til tusinder af GPU'er brugt 24/7 i uger til måneder - er hardwarefejl næsten sikre. Derfor skal en LLM-arbejdsbelastning implementere passende overvågnings- og modstandsdygtighedsmekanismer. For det første er det vigtigt at nøje overvåge LLM-infrastruktur, for at begrænse virkningen af fejl og optimere brugen af computerressourcer. SageMaker Training foreslår flere funktioner til dette formål:
- Logs sendes automatisk til CloudWatch Logs. Logfiler inkluderer dit træningsscript
stdout
,stderr
. I MPI-baseret distribueret træning sender alle MPI-medarbejdere deres logfiler til lederprocessen. - Metrics for systemressourceudnyttelse som hukommelse, CPU-brug og GPU-brug sendes automatisk til CloudWatch.
- Du kan definere tilpassede træningsmålinger som vil blive sendt til CloudWatch. Metrikken hentes fra logfiler baseret på regulære udtryk, du angiver. Tredjeparts eksperimentpakker som f.eks AWS partner at tilbyde vægte og skævheder kan bruges med SageMaker Training (se for eksempel Optimering af CIFAR-10-hyperparametre med W&B og SageMaker).
- SageMaker Profiler giver dig mulighed for at inspicere infrastrukturbrug og få optimeringsanbefalinger.
- Amazon Eventbridge , AWS Lambda giver dig mulighed for at oprette automatiseret klientlogik, der reagerer på hændelser som jobfejl, succeser, S3-filuploads og mere.
- SageMaker SSH Helper er et community-vedligeholdt open source-bibliotek, der giver dig mulighed for at oprette forbindelse til træningsjobværter gennem SSH. Det kan være nyttigt at inspicere og fejlfinde kodekørsler på specifikke noder.
Ud over overvågning bringer SageMaker også udstyr til jobresiliens:
- Klyngesundhedstjek – Inden dit job starter, kører SageMaker GPU-sundhedstjek og verificerer NCCL-kommunikation på GPU-instanser, og erstatter eventuelle defekte instanser, hvis det er nødvendigt for at sikre, at dit træningsscript begynder at køre på en sund klynge af instanser. Sundhedstjek er i øjeblikket aktiveret for P- og G GPU-baserede instanstyper.
- Indbyggede genforsøg og klyngeopdatering – Du kan konfigurere SageMaker til automatisk prøve igen træningsjob, der mislykkes med en SageMaker intern serverfejl (ISE). Som en del af at prøve et job igen, vil SageMaker erstatte alle forekomster, der stødte på uoprettelige GPU-fejl, med nye forekomster, genstarte alle sunde forekomster og starte jobbet igen. Dette resulterer i hurtigere genstart og fuldførelse af arbejdsbyrden. Klyngeopdatering er i øjeblikket aktiveret for P- og G GPU-baserede instanstyper. Du kan tilføje din egen applikativ genforsøgsmekanisme omkring klientkoden, der sender jobbet, for at håndtere andre typer lanceringsfejl, såsom at overskride din kontokvote.
- Automatiseret checkpoint til Amazon S3 – Dette hjælper dig kontrolpost dine fremskridt og genindlæs en tidligere tilstand på nye job.
For at drage fordel af udskiftning på nodeniveau skal din kode fejle. Kollektiver kan hænge, i stedet for at fejle, når en node fejler. For at få hurtig afhjælpning skal du derfor indstille en timeout på dine kollektiver og få koden til at kaste en fejl, når den nås.
Nogle kunder konfigurerer en overvågningsklient til at overvåge og handle i tilfælde af jobstop eller applikativ konvergensstop ved at overvåge CloudWatch-logfiler og metrics for unormale mønstre som ingen logs skrevet eller 0 % GPU-brug for at antyde et hæng, konvergensstop og auto stoppe/prøve jobbet igen.
Dybt dyk ved checkpointing
SageMaker checkpoint feature kopierer alt, hvad du skriver på /opt/ml/checkpoints
tilbage til Amazon S3 som den URI, der er angivet i checkpoint_s3_uri
SDK-parameter. Når et job starter eller genstarter, sendes alt skrevet på den URI tilbage til alle maskinerne kl /opt/ml/checkpoints
. Dette er praktisk, hvis du ønsker, at alle noder skal have adgang til alle kontrolpunkter, men i skala – når du har mange maskiner eller mange historiske kontrolpunkter, kan det føre til lange downloadtider og for høj trafik på Amazon S3. Derudover behøver arbejderne i tensor- og pipeline-parallelisme kun en brøkdel af den checkpointede model, ikke det hele. Hvis du står over for disse begrænsninger, anbefaler vi følgende muligheder:
- Checkpointer til FSx for Luster – Takket være højtydende tilfældig I/O kan du definere sharding og filtilskrivningsskema efter eget valg
- Selvstyret Amazon S3 checkpointing – For eksempler på Python-funktioner, der kan bruges til at gemme og læse kontrolpunkter på en ikke-blokerende måde, se Lagring af kontrolpunkter
Vi anbefaler kraftigt, at du tjekker din model med få timers mellemrum, for eksempel 1-3 timer, afhængigt af tilknyttede overhead og omkostninger.
Frontend og brugerstyring
Brugeradministration er en af SageMakers nøgleanvendelighedsstyrker sammenlignet med ældre delt HPC-infrastruktur. SageMaker Training tilladelser er styret af flere AWS identitets- og adgangsstyring (IAM) abstraktioner:
- Principaler – brugere og systemer – får tilladelse til at starte ressourcer
- Træningsjob bærer selv roller, som giver dem mulighed for at have deres egne tilladelser, for eksempel med hensyn til dataadgang og servicekaldelse
Derudover tilføjede vi i 2022 SageMaker Rolle Manager for at lette oprettelsen af persondrevne tilladelser.
Konklusion
Med SageMaker Training kan du reducere omkostningerne og øge iterationshastigheden på din træningsbelastning af store modeller. Vi har dokumenteret succeshistorier i adskillige indlæg og casestudier, herunder:
Hvis du ønsker at forbedre din LLM time-to-market og samtidig reducere dine omkostninger, så tag et kig på SageMaker Training API og lad os vide, hvad du bygger!
Særlig tak til Amr Ragab, Rashika Kheria, Zmnako Awrahman, Arun Nagarajan, Gal Oshri for deres nyttige anmeldelser og undervisning.
Om forfatterne
Anastasia Tzeveleka er Machine Learning og AI Specialist Solutions Architect hos AWS. Hun arbejder med kunder i EMEA og hjælper dem med at udvikle maskinlæringsløsninger i stor skala ved hjælp af AWS-tjenester. Hun har arbejdet på projekter inden for forskellige domæner, herunder Natural Language Processing (NLP), MLOps og Low Code No Code-værktøjer.
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.
Olivier Cruchant er en Principal Machine Learning Specialist Solutions Architect hos AWS, baseret i Frankrig. Olivier hjælper AWS-kunder – fra små startups til store virksomheder – med at udvikle og implementere maskinlæringsapplikationer i produktionskvalitet. I sin fritid nyder han at læse forskningsartikler og udforske vildmarken med venner og familie.
Bruno Pistone er en AI/ML Specialist Solutions Architect for AWS baseret i Milano. Han arbejder med kunder af enhver størrelse for at hjælpe dem med at forstå deres tekniske behov dybt og designe AI- og Machine Learning-løsninger, der gør den bedste brug af AWS Cloud og Amazon Machine Learning-stakken. Hans ekspertise er Machine Learning end to end, Machine Learning Industrialization og MLOps. Han nyder at tilbringe tid med sine venner og udforske nye steder, såvel som at rejse til nye destinationer.
- SEO Powered Content & PR Distribution. Bliv forstærket i dag.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/training-large-language-models-on-amazon-sagemaker-best-practices/
- :er
- ][s
- $OP
- 000
- 1
- 100
- 2022
- 7
- 8
- a
- evner
- I stand
- Om
- over
- fremskynde
- accelereret
- adgang
- imødekomme
- Konto
- opnå
- opnå
- tværs
- Lov
- Aktivering
- aktiv
- tilpasse
- tilføjet
- Desuden
- Derudover
- tilføjelser
- Fordel
- AI
- AI / ML
- AL
- algoritme
- algoritmer
- Alle
- tillade
- tillader
- Amazon
- Amazon EC2
- Amazon FSx
- Amazon maskinindlæring
- Amazon SageMaker
- beløb
- ,
- api
- API'er
- anvendelig
- Anvendelse
- applikationer
- anvendt
- passende
- ER
- OMRÅDE
- omkring
- AS
- forbundet
- At
- attributter
- auto
- Automatiseret
- automatisk
- til rådighed
- undgå
- AWS
- tilbage
- Bagende
- Balance
- baseret
- BE
- fordi
- bliver
- før
- være
- gavner det dig
- BEDSTE
- bedste praksis
- Beyond
- Big
- Billion
- milliarder
- Bloker
- bringe
- Bringer
- bygge
- bygget
- virksomhed
- by
- ringe
- kaldet
- Opkald
- CAN
- stand
- Kapacitet
- kort
- Kort
- bære
- tilfælde
- Casestudier
- katalyserer
- udfordringer
- skiftende
- Kanal
- kontrollere
- Kontrol
- valg
- valg
- Vælg
- klasser
- kunde
- nøje
- Cloud
- Cluster
- kode
- kollektive
- kombineret
- Kom
- Fælles
- almindeligt
- Kommunikation
- Kommunikation
- sammenlignet
- kompatibel
- færdiggørelse
- beregning
- Compute
- computer
- Computer Vision
- computing
- konkluderer
- gennemført
- Konfiguration
- Bekræfte
- Tilslut
- følgelig
- indeholder
- Container
- Beholdere
- indeholder
- indhold
- bidrog
- kontrol
- kontrolleret
- Praktisk
- Konvergens
- Korruption
- Koste
- Omkostninger
- kunne
- Kursus
- dæksel
- Dækker
- skabe
- skabelse
- Kreativ
- kritisk
- afgørende
- datasikring
- For øjeblikket
- skik
- Kunder
- tilpasse
- data
- dataadgang
- Dataforberedelse
- datasæt
- beslutte
- dedikeret
- dyb
- dyb læring
- Standard
- Degree
- Afhængigt
- afhænger
- indsætte
- Design
- konstrueret
- ønskes
- destinationer
- Bestem
- bestemmelse
- udvikle
- udviklet
- Udvikler
- udviklere
- Udvikling
- udvikler
- enhed
- Enheder
- forskellige
- Broadcasting
- direkte
- diskutere
- drøftet
- distribueret
- distribueret computing
- distribueret træning
- fordeling
- Docker
- Er ikke
- Domæner
- Dont
- ned
- downloade
- snesevis
- i løbet af
- hver
- nemt
- Effektiv
- enten
- EMEA
- muliggøre
- aktiveret
- muliggør
- muliggør
- tilskynde
- ender
- forbedret
- nyde
- nok
- sikre
- Enterprise
- virksomheder
- indrejse
- Miljø
- miljøer
- udstyr
- udstyret
- fejl
- fejl
- etablere
- Endog
- begivenheder
- eventuel
- Hver
- at alt
- udviklet sig
- eksempel
- eksempler
- Excel
- eksisterende
- forvente
- forventet
- erfaring
- eksperiment
- Udforskning
- udsat
- udtryk
- strækker
- udvidelser
- ekstern
- ekstremt
- stof
- Ansigtet
- lette
- faciliterende
- faktorer
- mislykkedes
- mislykkes
- Manglende
- familier
- familie
- Mode
- FAST
- hurtigere
- defekt
- gennemførlig
- Feature
- Funktionalitet
- få
- felt
- File (Felt)
- Filer
- Fornavn
- passer
- FLÅDE
- Fleksibilitet
- Fokus
- fokuserer
- efterfulgt
- efter
- Til
- fraktion
- Framework
- rammer
- Fransk vin
- Frihed
- hyppig
- frisk
- venner
- fra
- fuld
- fuldt ud
- funktionel
- funktionalitet
- funktioner
- yderligere
- GAL
- genereret
- generative
- få
- få
- GitHub
- given
- GPU
- GPU'er
- graf
- stor
- størst
- gruppe
- Vokser
- håndtere
- Håndtering
- Hænge
- ske
- Hardware
- Have
- have
- Helse
- sund
- hjælpsom
- hjælpe
- hjælper
- Høj
- Høj frekvens
- Høj ydeevne
- historisk
- hætte
- værter
- HOURS
- Hvordan
- How To
- Men
- HPC
- HTML
- http
- HTTPS
- Hundreder
- hundreder af millioner
- i
- identisk
- Identity
- billede
- billeder
- straks
- KIMOs Succeshistorier
- gennemføre
- implementeret
- gennemføre
- vigtigt
- Forbedre
- forbedret
- forbedringer
- in
- I andre
- omfatter
- Herunder
- Forøg
- øget
- Stigninger
- stigende
- individuel
- industrien
- info
- oplysninger
- Infrastruktur
- Innovation
- inspirerede
- installere
- instans
- i stedet
- integreret
- integration
- Intelligent
- interaktion
- grænseflade
- mellemmand
- interne
- indføre
- introduceret
- IT
- iteration
- ITS
- selv
- Job
- Karriere
- jpg
- Holde
- Nøgle
- Venlig
- Kend
- Sprog
- Sprog
- stor
- storstilet
- større
- seneste
- lancere
- lanceret
- lanceringer
- lag
- lag
- føre
- leder
- læring
- Legacy
- Niveau
- biblioteker
- Bibliotek
- livscyklus
- ligesom
- Sandsynlig
- GRÆNSE
- begrænsninger
- Limited
- lidt
- LLM
- lastning
- lokale
- Lang
- lang tid
- Se
- leder
- Lav
- maskine
- machine learning
- Maskiner
- vedligeholde
- Vedligeholdelse
- fastholder
- lave
- maerker
- Making
- administrere
- lykkedes
- ledelse
- mange
- Maps
- maksimal
- Hukommelse
- Metadata
- metoder
- Metrics
- migration
- MILAN
- millioner
- ML
- MLOps
- tilstand
- model
- modeller
- modificeret
- Overvåg
- overvågning
- mere
- mest
- bevæge sig
- flere
- nemlig
- indfødte
- Natural
- Natural Language Processing
- Natur
- nødvendigvis
- nødvendig
- Behov
- behov
- netværk
- netværksbaseret
- net
- neurale netværk
- Ny
- NLP
- node
- noder
- nummer
- talrige
- Nvidia
- objekter
- of
- tilbyde
- tilbyde
- Olive
- on
- On-Demand
- ONE
- åbent
- open source
- open source-kode
- åbnet
- Muligheder
- optimering
- Optimer
- optimeret
- Option
- Indstillinger
- orkestrering
- ordrer
- Andet
- egen
- pakke
- pakker
- Papir
- papirer
- paradigme
- Parallel
- parameter
- parametre
- del
- særlig
- især
- lidenskabelige
- forbi
- sti
- mønstre
- Betal
- Peak
- ydeevne
- forestillinger
- tilladelse
- Tilladelser
- Fysisk
- pipeline
- Steder
- plato
- Platon Data Intelligence
- PlatoData
- spiller
- Punkt
- pool
- Pools
- Populær
- Indlæg
- Indlæg
- praksis
- praksis
- forudsige
- præferencer
- foretrækkes
- præsentere
- gaver
- forhindre
- tidligere
- Main
- behandle
- Processer
- forarbejdning
- producere
- Program
- Programmering
- programmeringssprog
- Progress
- projekter
- korrekt
- foreslå
- foreslår
- proprietære
- protokol
- protokoller
- give
- forudsat
- udbyder
- leverer
- offentlige
- publikationer
- formål
- sætte
- Python
- pytorch
- kvalitet
- rejse
- tilfældig
- SJÆLDEN
- Sats
- priser
- nået
- Læs
- Læsning
- indse
- rimelige
- årsager
- modtage
- nylige
- anbefaler
- anbefalinger
- optage
- optegnelser
- opsving
- reducere
- reducerer
- reducere
- om
- region
- regioner
- fast
- regelmæssigt
- relaterede
- relevant
- pålidelig
- fjern
- erstatte
- repræsenterer
- anmode
- anmodninger
- kræver
- krav
- Kræver
- forskning
- forskning og innovation
- ressource
- Ressourcer
- Resultater
- Anmeldelser
- roller
- roller
- Kør
- kører
- sagemaker
- samme
- Gem
- Skalerbarhed
- skalerbar
- Scale
- skalaer
- skalering
- Ordningen
- videnskabelig
- forskere
- rækkevidde
- scripts
- SDK
- Søg
- Anden
- sekunder
- Sektion
- søger
- valgt
- valg
- senior
- Serverless
- Servere
- tjeneste
- Tjenester
- sæt
- indstillinger
- flere
- brudt
- sharding
- delt
- bør
- betydeligt
- Simpelt
- enkelhed
- samtidigt
- enkelt
- Størrelse
- størrelser
- færdigheder
- langsom
- lille
- So
- Software
- Løsninger
- nogle
- Kilde
- Kilder
- specialist
- specifikke
- specifikt
- specificeret
- hastighed
- udgifterne
- splits
- Spot
- stabil
- stable
- starte
- Starter
- starter
- Nystartede
- Tilstand
- statistiske
- Steps
- Stands
- standsning
- opbevaring
- butik
- Historier
- Strategi
- strøm
- vandløb
- styrke
- stripning
- kraftigt
- undersøgelser
- succes
- Succeshistorier
- vellykket
- sådan
- support
- Understøttet
- Understøtter
- synkronisering
- syntaks
- systemet
- bord
- Tag
- Opgaver
- opgaver
- hold
- Teknisk
- tensorflow
- Tak
- at
- verdenen
- deres
- Them
- selv
- teoretisk
- derfor
- Disse
- tredjepart
- tusinder
- tre
- Gennem
- kapacitet
- tid
- gange
- tips
- til
- i dag
- Tokens
- også
- værktøj
- værktøjer
- top
- I alt
- spor
- Trafik
- Tog
- uddannet
- Kurser
- Oversættelse
- transportere
- trillion
- typer
- typisk
- under
- underliggende
- forstå
- enestående
- enheder
- Opdatering
- us
- usability
- Brug
- brug
- Bruger
- sædvanligvis
- værdi
- Værdier
- række
- forskellige
- verificere
- udgave
- via
- video
- Specifikation
- vision
- varm
- Vej..
- måder
- uger
- GODT
- Hvad
- som
- mens
- WHO
- Hele
- vilje
- med
- inden for
- uden
- ord
- Arbejde
- arbejdede
- arbejdere
- arbejder
- virker
- world
- skriver
- skriftlig
- år
- Du
- Din
- dig selv
- youtube
- zephyrnet