Dette er et gæsteindlæg skrevet sammen med Metas PyTorch-team og er en fortsættelse af del 1 af denne serie, hvor vi demonstrerer ydeevnen og letheden ved at køre PyTorch 2.0 på AWS.
Maskinlæringsforskning (ML) har bevist, at store sprogmodeller (LLM'er) trænet med betydeligt store datasæt resulterer i bedre modelkvalitet. I de sidste par år er størrelsen af nuværende generations modeller steget markant, og de kræver, at moderne værktøjer og infrastruktur trænes effektivt og i stor skala. PyTorch Distributed Data Parallelism (DDP) hjælper med at behandle data i skala på en enkel og robust måde, men det kræver, at modellen passer på én GPU. PyTorch Fully Sharded Data Parallel (FSDP)-biblioteket bryder denne barriere ved at aktivere modelsharding til at træne store modeller på tværs af dataparallelarbejdere.
Distribueret modeltræning kræver en klynge af arbejderknudepunkter, der kan skaleres. Amazon Elastic Kubernetes Service (Amazon EKS) er en populær Kubernetes-konform tjeneste, der i høj grad forenkler processen med at køre AI/ML-arbejdsbelastninger, hvilket gør den mere overskuelig og mindre tidskrævende.
I dette blogindlæg samarbejder AWS med Metas PyTorch-team for at diskutere, hvordan man bruger PyTorch FSDP-biblioteket til at opnå lineær skalering af deep learning-modeller på AWS problemfrit ved hjælp af Amazon EKS og AWS Deep Learning-containere (DLC'er). Vi demonstrerer dette gennem en trin-for-trin implementering af træning 7B, 13B og 70B Llama2 modeller ved hjælp af Amazon EKS med 16 Amazon Elastic Compute Cloud (Amazon EC2) p4de.24xlarge instanser (hver med 8 NVIDIA A100 Tensor Core GPU'er og hver GPU med 80 GB HBM2e-hukommelse) eller 16 EC2 p5.48xlarge instanser (hver med 8 NVIDIA H100 Tensor Core GPU'er og hver GPU med 80 GB HBM3-hukommelse), der opnår næsten lineær skalering i gennemløb og muliggør i sidste ende hurtigere træningstid.
Følgende skaleringsdiagram viser, at p5.48xlarge-instanserne tilbyder 87 % skaleringseffektivitet med FSDP Llama2-finjustering i en 16-node klyngekonfiguration.
Udfordringer ved at træne LLM'er
Virksomheder anvender i stigende grad LLM'er til en række opgaver, herunder virtuelle assistenter, oversættelse, skabelse af indhold og computervision, for at øge effektiviteten og nøjagtigheden i en række forskellige applikationer.
Træning eller finjustering af disse store modeller til en brugertilpasset brug kræver dog en stor mængde data og computerkraft, hvilket øger den overordnede tekniske kompleksitet af ML-stakken. Dette skyldes også begrænset hukommelse, der er tilgængelig på en enkelt GPU, hvilket begrænser størrelsen af den model, der kan trænes, og også begrænser batchstørrelsen pr. GPU, der bruges under træning.
For at imødegå denne udfordring kan forskellige modelparallelismeteknikker som f.eks DeepSpeed ZeRO , PyTorch FSDP blev skabt for at give dig mulighed for at overvinde denne barriere af begrænset GPU-hukommelse. Dette gøres ved at anvende en sharded data parallel-teknik, hvor hver accelerator kun rummer en skive (a shard) af en modelreplika i stedet for hele modelreplikaen, hvilket dramatisk reducerer træningsjobbets hukommelsesfodaftryk.
Dette indlæg demonstrerer, hvordan du kan bruge PyTorch FSDP til at finjustere Llama2-modellen ved hjælp af Amazon EKS. Vi opnår dette ved at udskalere computer- og GPU-kapacitet for at imødekomme modelkravene.
FSDP oversigt
I PyTorch DDP-træning vil hver GPU (benævnt en arbejdstager i forbindelse med PyTorch) har en komplet kopi af modellen, inklusive modelvægte, gradienter og optimeringstilstande. Hver medarbejder behandler en batch af data og bruger i slutningen af tilbageløbet en alt-reducere operation for at synkronisere gradienter på tværs af forskellige arbejdere.
At have en kopi af modellen på hver GPU begrænser størrelsen af modellen, der kan rummes i en DDP-workflow. FSDP hjælper med at overvinde denne begrænsning ved at skære modelparametre, optimeringstilstande og gradienter på tværs af dataparallelle arbejdere, samtidig med at enkelheden af dataparallelisme bevares.
Dette er demonstreret i det følgende diagram, hvor hver GPU i tilfælde af DDP har en komplet kopi af modeltilstanden, inklusive optimeringstilstanden (OS), gradienter (G) og parametre (P): M(OS + G): + P). I FSDP indeholder hver GPU kun et udsnit af modeltilstanden, inklusive optimeringstilstanden (OS), gradienter (G) og parametre (P): M (OS + G + P). Brug af FSDP resulterer i et væsentligt mindre GPU-hukommelsesfodaftryk sammenlignet med DDP på tværs af alle arbejdere, hvilket muliggør træning af meget store modeller eller brug af større batchstørrelser til træningsjob.
Dette kommer dog på bekostning af øgede kommunikationsomkostninger, som afbødes gennem FSDP-optimeringer såsom overlappende kommunikations- og beregningsprocesser med funktioner som f.eks. forhåndshentning. For mere detaljeret information, se Kom godt i gang med Fully Sharded Data Parallel (FSDP).
FSDP tilbyder forskellige parametre, der giver dig mulighed for at justere ydeevnen og effektiviteten af dine træningsjobs. Nogle af de vigtigste funktioner og muligheder i FSDP inkluderer:
- Transformer-indpakningspolitik
- Fleksibel blandet præcision
- Aktivering checkpointing
- Forskellige sharding-strategier, der passer til forskellige netværkshastigheder og klyngetopologier:
- FULD_SHARD – Shard-modelparametre, gradienter og optimeringstilstande
- HYBRID_SHARD – Fuld skår i en node DDP på tværs af noder; understøtter en fleksibel sønderdelingsgruppe til en fuld kopi af modellen (HSDP)
- SHARD_GRAD_OP – Shard kun gradienter og optimeringstilstande
- NO_SHARD – Svarende til DDP
For mere information om FSDP, se Effektiv træning i stor skala med Pytorch FSDP og AWS.
Følgende figur viser, hvordan FSDP fungerer for to parallelle dataprocesser.
Løsningsoversigt
I dette indlæg opsætter vi en computerklynge ved hjælp af Amazon EKS, som er en administreret tjeneste til at køre Kubernetes i AWS Cloud og lokale datacentre. Mange kunder omfavner Amazon EKS til at køre Kubernetes-baserede AI/ML-arbejdsbelastninger, der drager fordel af dets ydeevne, skalerbarhed, pålidelighed og tilgængelighed, såvel som dets integrationer med AWS-netværk, sikkerhed og andre tjenester.
Til vores FSDP use case bruger vi Kubeflow Training Operator på Amazon EKS, som er et Kubernetes-native projekt, der letter finjustering og skalerbar distribueret træning til ML-modeller. Det understøtter forskellige ML-frameworks, inklusive PyTorch, som du kan bruge til at implementere og administrere PyTorch træningsjob i stor skala.
Ved at bruge den tilpassede PyTorchJob-ressource fra Kubeflow Training Operator, kører vi træningsjob på Kubernetes med et konfigurerbart antal arbejderreplikaer, som giver os mulighed for at optimere ressourceudnyttelsen.
Følgende er nogle få komponenter i træningsoperatøren, der spiller en rolle i vores Llama2 finjusteringsbrug:
- En centraliseret Kubernetes-controller, der orkestrerer distribuerede træningsjob for PyTorch.
- PyTorchJob, en tilpasset Kubernetes-ressource til PyTorch, leveret af Kubeflow Training Operator, til at definere og implementere Llama2-træningsjob på Kubernetes.
- etcd, som er relateret til implementeringen af rendezvous-mekanismen til koordinering af den distribuerede træning af PyTorch-modeller. Det her
etcd
server, som en del af rendezvous-processen, letter koordineringen og synkroniseringen af de deltagende arbejdere under distribueret træning.
Følgende diagram illustrerer løsningsarkitekturen.
De fleste af detaljerne vil blive abstraheret af de automatiseringsscripts, som vi bruger til at køre Llama2-eksemplet.
Vi bruger følgende kodereferencer i denne brugssituation:
Hvad er Llama2?
Llama2 er en LLM præ-trænet på 2 billioner tokens tekst og kode. Det er en af de største og mest kraftfulde LLM'er, der er tilgængelige i dag. Du kan bruge Llama2 til en række forskellige opgaver, herunder naturlig sprogbehandling (NLP), tekstgenerering og oversættelse. For mere information, se Kom godt i gang med Llama.
Llama2 fås i tre forskellige modelstørrelser:
- Lama2-70b – Dette er den største Llama2-model med 70 milliarder parametre. Det er den mest kraftfulde Llama2-model og kan bruges til de mest krævende opgaver.
- Lama2-13b – Dette er en mellemstor Llama2-model med 13 milliarder parametre. Det er en god balance mellem ydeevne og effektivitet, og kan bruges til en række forskellige opgaver.
- Lama2-7b – Dette er den mindste Llama2-model med 7 milliarder parametre. Det er den mest effektive Llama2-model og kan bruges til opgaver, der ikke kræver det højeste niveau af ydeevne.
Dette indlæg giver dig mulighed for at finjustere alle disse modeller på Amazon EKS. For at give en enkel og reproducerbar oplevelse af at oprette en EKS-klynge og køre FSDP-job på den, bruger vi aws-do-eks projekt. Eksemplet vil også fungere med en allerede eksisterende EKS-klynge.
En scriptet gennemgang er tilgængelig på GitHub for en out-of-the-box oplevelse. I de følgende afsnit forklarer vi ende-til-ende-processen mere detaljeret.
Levere løsningsinfrastrukturen
Til eksperimenterne beskrevet i dette indlæg bruger vi klynger med p4de (A100 GPU) og p5 (H100 GPU) noder.
Klynge med p4de.24xlarge noder
Til vores klynge med p4de noder bruger vi følgende eks-gpu-p4de-odcr.yaml manuskript:
Ved brug af ekskl og det foregående klyngemanifest, opretter vi en klynge med p4de noder:
Klynge med p5.48xlarge noder
En terraform-skabelon til en EKS-klynge med P5-noder er placeret i det følgende GitHub repo.
Du kan tilpasse klyngen via variabler.tf fil og derefter oprette den via Terraform CLI:
Du kan bekræfte klyngens tilgængelighed ved at køre en simpel kubectl-kommando:
Klyngen er sund, hvis outputtet af denne kommando viser det forventede antal noder i Klar-status.
Implementer forudsætninger
For at køre FSDP på Amazon EKS bruger vi PyTorchJob tilpasset ressource. Det kræver osv , Kubeflow Training Operator som forudsætninger.
Implementer etcd med følgende kode:
Implementer Kubeflow Training Operator med følgende kode:
Byg og skub et FSDP-containerbillede til Amazon ECR
Brug følgende kode til at bygge et FSDP-containerbillede og skub det til Amazon Elastic Container Registry (Amazon ECR):
Opret FSDP PyTorchJob-manifestet
Indsæt din Knusende ansigt-token i følgende uddrag, før du kører det:
Konfigurer din PyTorchJob med .env fil eller direkte i dine miljøvariabler som nedenfor:
Generer PyTorchJob-manifestet ved hjælp af fsdp skabelon , generere.sh script eller opret det direkte ved hjælp af scriptet nedenfor:
Kør PyTorchJob
Kør PyTorchJob med følgende kode:
Du vil se det angivne antal FDSP worker pods, der er oprettet, og efter at have trukket billedet vil de gå ind i en kørende tilstand.
For at se status for PyTorchJob skal du bruge følgende kode:
For at stoppe PyTorchJob skal du bruge følgende kode:
Når et job er fuldført, skal det slettes, før du starter en ny kørsel. Vi har også observeret, at sletning afetcd
pod og lade den genstarte, før du starter et nyt job, hjælper med at undgå en RendezvousClosedError
.
Skaler klyngen
Du kan gentage de foregående trin med at oprette og køre job, mens du varierer antallet og instanstypen af arbejdernoder i klyngen. Dette giver dig mulighed for at producere skaleringsdiagrammer som det, der er vist tidligere. Generelt bør du se en reduktion i GPU-hukommelsesfodaftryk, reduktion i epoketid og stigning i gennemløb, når flere noder føjes til klyngen. Det forrige diagram blev fremstillet ved at udføre flere eksperimenter ved hjælp af en p5-knudegruppe varierende fra 1-16 noder i størrelse.
Overhold FSDP træningsarbejdsbyrden
Observerbarhed af generative kunstig intelligens-arbejdsbelastninger er vigtig for at tillade synlighed i dine løbende jobs samt hjælpe med at maksimere udnyttelsen af dine computerressourcer. I dette indlæg bruger vi et par Kubernetes-native og open source-observationsværktøjer til dette formål. Disse værktøjer sætter dig i stand til at spore fejl, statistik og modeladfærd, hvilket gør AI-observation til en afgørende del af enhver forretningsanvendelse. I dette afsnit viser vi forskellige tilgange til at observere FSDP træningsjob.
Arbejder pod logs
På det mest grundlæggende niveau skal du være i stand til at se logfilerne for dine træningspuder. Dette kan nemt gøres ved at bruge Kubernetes-native kommandoer.
Hent først en liste over pods og find navnet på den, du vil se logfiler for:
Se derefter logfilerne for den valgte pod:
Kun én arbejder (valgt leder) pod-log vil vise den overordnede jobstatistik. Navnet på den valgte leder pod er tilgængeligt i begyndelsen af hver worker pod log, identificeret med nøglen master_addr=
.
CPU udnyttelse
Distribuerede træningsbelastninger kræver både CPU- og GPU-ressourcer. For at optimere disse arbejdsbelastninger er det vigtigt at forstå, hvordan disse ressourcer udnyttes. Heldigvis er nogle fantastiske open source-værktøjer tilgængelige, som hjælper med at visualisere CPU- og GPU-udnyttelse. For at se CPU-udnyttelse kan du brugehtop
. Hvis dine worker pods indeholder dette værktøj, kan du bruge nedenstående kommando til at åbne en shell til en pod og derefter kørehtop
.
Alternativt kan du implementere en htopdaemonset
som den, der er angivet i det følgende GitHub repo.
daemonset
vil køre en letvægts htop pod på hver node. Du kan køre ind i enhver af disse pods og kørehtop
kommando:
Følgende skærmbillede viser CPU-udnyttelsen på en af noderne i klyngen. I dette tilfælde ser vi på en P5.48xlarge-instans, som har 192 vCPU'er. Processorkernerne er inaktive, mens modelvægtene downloades, og vi ser stigende udnyttelse, mens modelvægtene indlæses til GPU-hukommelsen.
GPU-udnyttelse
Hvisnvtop
værktøjet er tilgængeligt i din pod, du kan gå ind i det ved at bruge nedenfor og derefter kørenvtop
.
Alternativt kan du implementere en nvtopdaemonset
som den, der er angivet i det følgende GitHub repo.
Dette vil køre ennvtop
pod på hver node. Du kan gå ind i enhver af disse pods og kørenvtop
:
Følgende skærmbillede viser GPU-udnyttelsen på en af noderne i træningsklyngen. I dette tilfælde ser vi på en P5.48xlarge instans, som har 8 NVIDIA H100 GPU'er. GPU'erne er inaktive, mens modelvægtene downloades, så øges GPU-hukommelsesudnyttelsen, når modelvægtene indlæses på GPU'en, og GPU-udnyttelsen stiger til 100 %, mens træningsgentagelserne er i gang.
Grafana instrumentbræt
Nu hvor du forstår, hvordan dit system fungerer på pod- og nodeniveau, er det også vigtigt at se på metrics på klyngeniveau. Aggregerede udnyttelsesmålinger kan indsamles af NVIDIA DCGM Exporter og Prometheus og visualiseres i Grafana.
Et eksempel på Prometheus-Grafana-implementering er tilgængeligt i det følgende GitHub repo.
Et eksempel på implementering af DCGM-eksportører er tilgængeligt i det følgende GitHub repo.
Et simpelt Grafana-dashboard vises i det følgende skærmbillede. Det blev bygget ved at vælge følgende DCGM-metrikker: DCGM_FI_DEV_GPU_UTIL
, DCGM_FI_MEM_COPY_UTIL
, DCGM_FI_DEV_XID_ERRORS
, DCGM_FI_DEV_SM_CLOCK
, DCGM_FI_DEV_GPU_TEMP
og DCGM_FI_DEV_POWER_USAGE
. Dashboardet kan importeres til Prometheus fra GitHub.
Følgende dashboard viser en kørsel af et Llama2 7b enkelt epoke træningsjob. Graferne viser, at når streaming-multiprocessor-uret (SM) stiger, stiger strømforbruget og temperaturen på GPU'erne også sammen med GPU- og hukommelsesudnyttelsen. Du kan også se, at der ikke var nogen XID-fejl, og at GPU'erne var sunde under denne kørsel.
Siden marts 2024 er GPU-observabilitet for EKS understøttet indbygget i CloudWatch Container Insights. For at aktivere denne funktionalitet skal du blot implementere CloudWatch Observability Add-on i din EKS-klynge. Derefter vil du være i stand til at gennemse pod-, node- og klyngeniveau-metrics gennem forudkonfigurerede og tilpasselige dashboards i Container Insights.
Ryd op
Hvis du har oprettet din klynge ved hjælp af eksemplerne i denne blog, kan du udføre følgende kode for at slette klyngen og eventuelle ressourcer, der er knyttet til den, inklusive VPC:
For eksctl:
Til terraform:
Kommende funktioner
FSDP forventes at inkludere en per-parameter sharding-funktion, der sigter mod yderligere at forbedre dets hukommelsesfodaftryk pr. GPU. Derudover har den igangværende udvikling af FP8-understøttelse til formål at forbedre FSDP-ydeevnen på H100 GPU'er. Endelig, når FSDP er integreret medtorch.compile
, håber vi at se yderligere ydeevneforbedringer og aktivering af funktioner som selektiv aktiveringskontrol.
Konklusion
I dette indlæg diskuterede vi, hvordan FSDP reducerer hukommelsesfodaftrykket på hver GPU, hvilket muliggør træning af større modeller mere effektivt og opnår næsten lineær skalering i gennemstrømning. Vi demonstrerede dette gennem en trin-for-trin implementering af træning af en Llama2-model ved hjælp af Amazon EKS på P4de- og P5-forekomster og brugte observerbarhedsværktøjer som kubectl, htop, nvtop og dcgm til at overvåge logfiler samt CPU- og GPU-udnyttelse.
Vi opfordrer dig til at drage fordel af PyTorch FSDP til dine egne LLM-uddannelsesjob. Kom i gang kl aws-do-fsdp.
Om forfatterne
Kanwaljit Khurmi er Principal AI/ML Solutions Architect hos Amazon Web Services. Han arbejder med AWS-kunder for at yde vejledning og teknisk assistance, der hjælper dem med at forbedre værdien af deres maskinlæringsløsninger på AWS. Kanwaljit har specialiseret sig i at hjælpe kunder med containeriserede, distribuerede computere og deep learning-applikationer.
Alex Iankoulski er Principal Solutions Architect, Self-managed Machine Learning hos AWS. Han er en fuld stack software- og infrastrukturingeniør, der kan lide at udføre dybt, praktisk arbejde. I sin rolle fokuserer han på at hjælpe kunder med containerisering og orkestrering af ML- og AI-arbejdsbelastninger på containerdrevne AWS-tjenester. Han er også forfatter til open source lave rammer og en Docker-kaptajn, der elsker at anvende containerteknologier til at accelerere innovationstempoet og samtidig løse verdens største udfordringer.
Ana Simoes er Principal Machine Learning Specialist, ML Frameworks hos AWS. Hun understøtter kunder, der implementerer AI, ML og generativ AI i stor skala på HPC-infrastruktur i skyen. Ana fokuserer på at støtte kunder med at opnå pris-ydeevne for nye arbejdsbelastninger og use cases til generativ AI og maskinlæring.
Hamid Shojanazeri er partneringeniør hos PyTorch, der arbejder på open source, højtydende modeloptimering, distribueret træning (FSDP), og slutninger. Han er medskaber af lama-opskrift og bidragyder til TorchServe. Hans hovedinteresse er at forbedre omkostningseffektiviteten og gøre kunstig intelligens mere tilgængelig for det bredere samfund.
Mindre Wright er AI/Partner Engineer i PyTorch. Han arbejder på Triton/CUDA kerner (Accelererer Dequant med SplitK arbejdsnedbrydning); side-, streaming- og kvantiserede optimeringsværktøjer; og PyTorch Distributed (PyTorch FSDP).
- 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. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
- PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
- Kilde: https://aws.amazon.com/blogs/machine-learning/scale-llms-with-pytorch-2-0-fsdp-on-amazon-eks-part-2/
- :har
- :er
- :hvor
- ][s
- $OP
- 1
- 10
- 100
- 12
- 13
- 16
- 2024
- 28
- 500
- 7
- 70
- 8
- 80
- 800
- a
- I stand
- Om
- abstraheret
- fremskynde
- accelerator
- tilgængelig
- Konto
- nøjagtighed
- opnå
- opnå
- tværs
- Aktivering
- Tilføjelse
- tilføjet
- Yderligere
- Derudover
- adresse
- Tilføjer
- Vedtagelsen
- Fordel
- Efter
- aggregeret
- AI
- AI / ML
- Støtte
- sigter
- målsætninger
- Alle
- tillade
- tillader
- også
- altid
- Amazon
- Amazon EC2
- Amazon Web Services
- beløb
- an
- Ana
- ,
- og infrastruktur
- enhver
- app
- applikationer
- Indløs
- Anvendelse
- tilgange
- arkitektur
- ER
- kunstig
- kunstig intelligens
- AS
- Assistance
- assistenter
- forbundet
- At
- forfatter
- Automation
- tilgængelighed
- til rådighed
- undgå
- AWS
- Balance
- barriere
- bash
- grundlæggende
- BE
- før
- Begyndelse
- adfærd
- være
- jf. nedenstående
- Bedre
- mellem
- Største
- Billion
- Blog
- både
- pauser
- bredere
- bygge
- bygget
- virksomhed
- men
- by
- CAN
- kapaciteter
- Kapacitet
- tilfælde
- tilfælde
- KAT
- Centers
- centraliseret
- udfordre
- udfordringer
- Chart
- Diagrammer
- cli
- ur
- Cloud
- Cluster
- kode
- samarbejder
- kommer
- Kommunikation
- samfund
- sammenlignet
- fuldføre
- kompleksitet
- komponenter
- beregning
- Compute
- computer
- Computer Vision
- computing
- udførelse
- Konfiguration
- indeholder
- Container
- Beholdere
- indhold
- indholdsskabelse
- sammenhæng
- fortsættelse
- bidragsyder
- controller
- koordinerende
- koordinering
- kopiere
- Core
- Koste
- skabe
- oprettet
- Oprettelse af
- skabelse
- afgørende
- Nuværende
- skik
- Kunder
- tilpasses
- tilpasse
- instrumentbræt
- dashboards
- data
- datacentre
- datasæt
- DDP
- dyb
- dyb læring
- definere
- krævende
- demonstrere
- demonstreret
- demonstrerer
- indsætte
- implementering
- implementering
- beskrive
- beskrevet
- detail
- detaljeret
- detaljer
- Udvikling
- diagram
- forskellige
- direkte
- diskutere
- drøftet
- distribueret
- distribueret computing
- distribueret træning
- do
- Docker
- færdig
- Dont
- downloade
- downloadet
- dramatisk
- tegne
- grund
- i løbet af
- hver
- tidligere
- lette
- nemt
- effektivitet
- effektiv
- effektivt
- valgt
- omfavne
- muliggøre
- aktivering
- muliggør
- muliggør
- tilskynde
- ende
- ende til ende
- ingeniør
- Engineering
- forbedre
- Indtast
- Hele
- Miljø
- epoke
- fejl
- eksempel
- eksempler
- udføre
- forventet
- erfaring
- eksperimenter
- Forklar
- Ansigtet
- letter
- hurtigere
- Feature
- Funktionalitet
- få
- Figur
- File (Felt)
- Endelig
- passer
- fleksibel
- fokuserer
- efter
- Fodspor
- Til
- Heldigvis
- rammer
- fra
- fuld
- fuldt ud
- funktionalitet
- yderligere
- Generelt
- generation
- generative
- Generativ AI
- få
- GitHub
- godt
- GPU
- GPU'er
- gradienter
- grafer
- stor
- stærkt
- gruppe
- Gæst
- gæst Indlæg
- vejledning
- hands-on
- he
- sund
- hjælpe
- hjælpe
- hjælper
- Høj ydeevne
- højeste
- hans
- besidder
- håber
- Hvordan
- How To
- Men
- HPC
- HTML
- http
- HTTPS
- identificeret
- tomgang
- if
- illustrerer
- billede
- implementering
- vigtigt
- Forbedre
- forbedringer
- in
- omfatter
- Herunder
- Forøg
- øget
- Stigninger
- stigende
- info
- oplysninger
- Infrastruktur
- Innovation
- indsigt
- instans
- i stedet
- integreret
- integrationer
- Intelligens
- interesse
- ind
- IT
- iterationer
- ITS
- Job
- Karriere
- jpeg
- jpg
- json
- lige
- Nøgle
- Venlig
- KubeFlow
- Etiketter
- Sprog
- stor
- storstilet
- større
- største
- Efternavn
- lancering
- leder
- læring
- mindre
- udlejning
- Niveau
- Bibliotek
- letvægt
- ligesom
- synes godt om
- begrænsning
- Limited
- grænser
- lineær
- Liste
- LLM
- placeret
- log
- Logge på
- Se
- leder
- elsker
- maskine
- machine learning
- Main
- Making
- administrere
- håndterbar
- lykkedes
- måde
- mange
- Marts
- Marts 2024
- maksimere
- Kan..
- mekanisme
- Hukommelse
- Meta
- Metadata
- Metrics
- blandet
- ML
- model
- modeller
- Moderne
- Overvåg
- mere
- mest
- navn
- indbygget
- Natural
- Natural Language Processing
- I nærheden af
- Behov
- behov
- netværk
- netværk
- Ny
- NLP
- ingen
- node
- noder
- nummer
- Nvidia
- of
- tilbyde
- Tilbud
- on
- ONE
- igangværende
- kun
- på
- åbent
- open source
- drift
- operatør
- optimering
- optimeringer
- Optimer
- or
- orkestrering
- OS
- Andet
- vores
- ud
- output
- samlet
- Overvind
- overliggende
- egen
- Tempo
- Parallel
- parametre
- del
- deltager
- partner
- passerer
- sti
- per
- ydeevne
- fly
- plato
- Platon Data Intelligence
- PlatoData
- Leg
- Populær
- Indlæg
- magt
- vigtigste
- forud
- forudsætninger
- bevare
- tidligere
- Main
- Forud
- behandle
- Processer
- forarbejdning
- Processor
- producere
- produceret
- projekt
- gennemprøvet
- give
- forudsat
- trækker
- formål
- Skub ud
- pytorch
- kvalitet
- rækkevidde
- klar
- reducerer
- reduktion
- henvise
- referencer
- benævnt
- region
- register
- relaterede
- pålidelighed
- gentag
- svar
- anmodninger
- kræver
- Krav
- Kræver
- forskning
- ressource
- Ressourcer
- resultere
- Resultater
- stigende
- robust
- roller
- Kør
- kører
- Skalerbarhed
- skalerbar
- Scale
- skalering
- script
- scripts
- problemfrit
- Sektion
- sektioner
- sikkerhed
- se
- valgt
- udvælgelse
- selektiv
- Series
- tjeneste
- Tjenester
- sæt
- flere
- brudt
- sharding
- hun
- Shell
- bør
- Vis
- vist
- Shows
- betydeligt
- lignende
- Simpelt
- enkelhed
- forenkler
- enkelt
- Størrelse
- størrelser
- Slice
- mindre
- uddrag
- Software
- løsninger
- Løsninger
- Løsning
- nogle
- Kilde
- specialist
- specialiseret
- specificeret
- hastigheder
- spikes
- stable
- påbegyndt
- Tilstand
- Stater
- statistik
- Status
- Steps
- Stadig
- Stands
- strategier
- streaming
- sådan
- Dragt
- support
- Understøttet
- Støtte
- Understøtter
- synkronisering
- SYS
- systemet
- Tag
- tager
- mål
- opgaver
- hold
- Teknisk
- teknik
- teknikker
- Teknologier
- skabelon
- terraform
- tekst
- at
- deres
- Them
- derefter
- Der.
- Disse
- de
- denne
- dem
- tre
- Gennem
- kapacitet
- tid
- tidskrævende
- til
- i dag
- sammen
- Tokens
- værktøjer
- spor
- Tog
- uddannet
- Kurser
- Oversættelse
- trillion
- sand
- tune
- to
- typen
- Ultimativt
- forstå
- undervejs
- us
- brug
- brug tilfælde
- anvendte
- bruger
- ved brug af
- forsyningsselskaber
- nytte
- udnyttet
- værdi
- række
- forskellige
- Varierende
- verificere
- udgave
- meget
- via
- Specifikation
- visning
- Virtual
- synlighed
- vision
- Visualiser
- mængder
- går igennem
- ønsker
- var
- we
- web
- webservices
- GODT
- var
- hvornår
- som
- mens
- WHO
- vilje
- med
- inden for
- Arbejde
- arbejdstager
- arbejdere
- workflow
- arbejder
- virker
- Verdens
- indpakning
- yaml
- år
- Du
- Din
- zephyrnet