Hosting af AI-applikationer: Dimensionering af CPU, GPU og lagerplads

Begræns først AI-arbejdsbyrden

Valget af hardware starter med opgaven, ikke med en GPU. Ved Slutning En eksisterende model behandler inddata og genererer for eksempel svar. Finjustering tilpasser en foruddannet model til yderligere data eller en opgave; fuldstændig træning opbygger derimod modelvægtningerne som led i et selvstændigt træningsforløb.

Disse mål medfører forskellige belastningsprofiler: En chattjeneste skal reagere på forespørgsler, mens en træningsopgave behandler data over en længere periode og gemmer mellemresultater. For AI-hosting Du bør derfor tage højde for, om det er responstid, behandlede forespørgsler, træningstid eller f.eks. omkostningerne ved en bestemt opgave, der er i fokus.

Dokumentér modelversion og kørselstid samt antal parametre, arkitektur, præcision og en planlagt kvantisering. Notér desuden de forventede indgangs- og udgangslængder, samtidige forespørgsler eller batchstørrelser samt spidsbelastningen. På den måde kan tilbud og senere tests sammenlignes på baggrund af de samme antagelser, i stedet for blot at sammenligne nominelle hardwaredata.

I en intern chat-assistent kan en enkelt kort forespørgsel uden problemer håndteres, mens flere lange samtaler kan overbelaste hukommelsen. KV-cachen opbevarer yderligere tilstande under tekstgenereringen; dens behov afhænger blandt andet af modellen og behandlingen. Planlæg derfor ikke kun ud fra den gennemsnitlige dialog, men også ud fra lange sammenhænge og parallel brug.

Notér også, hvilke data der behandles, hvor de må opbevares, og hvilke krav der stilles til tilgængelighed og gendannelsestid. Disse driftsmål har indflydelse på valget mellem en enkelt server og en mere kompleks arkitektur. Antagelserne udgør blot et udgangspunkt: Om de holder stik, viser først en test med en repræsentativ belastning.

CPU og RAM er på vej

Selvom en model kører på en GPU, arbejder CPU’en også med i datastrømmen. Den kan modtage forespørgsler, tokenisere tekst, læse filer og forberede inddata til modelbehandlingen. Hvis denne forberedelse er for langsom, står GPU’en og venter på arbejde; en større accelerator løser da ikke nødvendigvis flaskehalsen.

Der Arbejdshukommelse Afhængigt af anvendelsen optager den modelkomponenter, forberedte data og filcacher. Derudover er der behov for hukommelse til processer, der indlæser og konverterer træningsdata. Planlæg derfor ikke kun selve modellen, men også forløbet fra datasættet til den færdige batch samt tilstrækkelige reserver til spidsbelastninger under behandlingen.

PyTorch-DataLoader kan anvende flere arbejdsprocesser til parallel databehandling. Yderligere arbejdsprocesser optager dog også hukommelse, og det fælles hukommelsesområde kan også blive knapt. Øg derfor antallet gradvist, og hold øje med ventetiderne for data og hukommelsesbehovet, i stedet for at anvende en fast værdi som en generel anbefaling.

Flere CPU-kerner er især en fordel, når de opgaver, der skal udføres, kan køres parallelt. Hvis derimod adgang til lagringsmedier, et enkelt behandlingstrin eller selve GPU’en begrænser gennemstrømningen, kan ekstra kerner ikke ændre meget. Også klokfrekvensen kan være relevant for korte forespørgsler; yderligere baggrundsinformation findes i artiklen om CPU-regulator på hosting-servere.

For små modeller eller sjældne forespørgsler er CPU-inferens et alternativ, der er værd at undersøge, i forhold til et GPU-system, der er tilgængeligt døgnet rundt. Sammenlign de to varianter med den samme model, passende præcision og den forventede belastningsprofil. Det afgørende er, om CPU’en kan opnå den krævede responstid, selv under spidsbelastning, og hvilke omkostninger der reelt er forbundet hermed.

At forstå GPU og VRAM korrekt

Ved en inferens, der udelukkende foregår på GPU’en, skal modelvægtningerne kunne rummes i den tilgængelige GPU-hukommelse. Den VRAM-behov Men det slutter ikke der: Kørselen kræver yderligere områder til mellemresultater og midlertidige buffere. Et kort, hvor vægtene rent matematisk lige akkurat passer ind, udgør derfor endnu ikke et sikkert grundlag for produktiv drift.

Ved autoregressiv tekstgenerering kommer KV-cachen oveni. Den gemmer allerede beregnede nøgle- og værditilstande, så de kan genbruges i de efterfølgende genereringstrin. Lange kontekster og forespørgsler, der behandles samtidigt, kan øge dette ekstra hukommelsesbehov; hvor meget afhænger af modellen og behandlingen.

Dokumentationen til Transformers 4.48.2 beskriver blandt andet cache-kvantisering og udlagring som muligheder for at spare på VRAM. Fordelen afhænger dog af implementeringen og belastningen; yderligere databehandling eller dataoverførsler kan nedsætte hastigheden. Kontroller derfor både hukommelsesforbruget og responstiden, i stedet for automatisk at betragte en besparelse i hukommelsesforbruget som en ydelsesforbedring.

Under træningen er inferensberegningen slet ikke tilstrækkelig. Ud over vægtene opstår der hukommelsesbehov til gradienter, optimatorens tilstande og gemte aktiveringer. Hvor store disse andele bliver, afhænger blandt andet af optimatoren, præcisionen og træningsmetoden; længere sekvenser eller større batches kan især øge hukommelsesbehovet til aktiveringer.

For en fuldstændig GPU-baseret udførelse skal den tilgængelige VRAM kunne rumme de nødvendige vægte og kørselsdata. Hybride metoder kan placere dele af behandlingen eller modelvægtningerne uden for GPU'en; deres egnethed og omkostningerne ved dataoverførsler afhænger af kørselstiden. Dette skal adskilles fra den udlagring af KV-cachen, der er beskrevet i Transformers 4.48.2.

Betragt model, kørselstid og planlagt parallelitet samlet, og kontroller de maksimale hukommelsesniveauer under en repræsentativ belastning. Tilstrækkelig hukommelse til den valgte implementering er ikke i sig selv et bevis på den ønskede responstid eller udnyttelsesgrad.

Beregne modelhukommelsen omtrentligt

En første beregning af hukommelsesbehovet tager udgangspunkt i antallet af modelparametre og det format, hvori deres vægte rent faktisk gemmes. Den giver en nedre grænse for dette hukommelsesbehov, men endnu ikke en fuldstændig dimensionering af GPU-serveren. Den siger især ikke noget om, hvor meget hukommelse en konkret forespørgsel kræver under kørsel.

Illustrativt regneeksempel, ikke en måling: Syv milliarder parametre ganget med to byte giver 14 milliarder byte til vægtene. Delt med 1.073.741.824 byte pr. GiB giver det cirka 13,0 GiB. Forudsætningen er, at alle de betragtede vægte faktisk er ensartede med to byte pr. parameter; andre formater eller yderligere repræsentationer ændrer beregningen.

Følgende er ikke inkluderet: KV-cache til tekstgenerering, midlertidige buffere og kørselstidsoverhead. Især ved lange kontekster kan cachen vokse betydeligt; også antallet af forespørgsler, der behandles samtidigt, er relevant for den nødvendige reserve. Cache-dokumentationen til Transformers 4.48.2 beskriver desuden metoder, der kan spare hukommelse, men som afhængigt af metoden kan gå ud over hastigheden.

Til træning er vægtberegningen slet ikke tilstrækkelig. Dokumentationen til Transformers 4.35.0 anslår for en eksempelkonfiguration med blandet præcision og AdamW 18 byte pr. parameter plus aktiveringer. Dette afspejler yderligere komponenter såsom gradienter og optimeringstilstande; aktiveringerne afhænger blandt andet af sekvenslængde og batchstørrelse.

De 18 byte er ikke en generel multiplikator for alle træningsforløb: Optimeringsindstillinger, præcision og træningsmetoder kan ændre behovet. Hverken dette tal eller de 13,0 GiB udgør derfor en anbefaling for en bestemt VRAM-størrelse. Ved valget er den konkrete kørselstid og de forventede maksimale hukommelsesbelastninger under repræsentativ belastning afgørende.

Sammenligning af arbejdsbelastninger og flaskehalse

De samme modelvægte kan, afhængigt af opgaven, medføre meget forskellige krav. Tabellen viser mulige testpunkter, ikke en rangorden og ikke garanterede flaskehalse. Hvilken ressource der rent faktisk udgør en begrænsning, afhænger blandt andet af modellen, datapipeline, parallelisering og belastning.

Når det drejer sig om en intern chat-assistent, udgør modellen og genereringen kun en del af planlægningen. Fastlæg en maksimal indtastningslængde, en forventet udgangslængde og antallet af samtidige brugere. Derefter kan man kontrollere, om svartiden forbliver acceptabel ved spidsbelastning, og om vægtninger, cache og buffer samtidig kan rummes i den tilgængelige hukommelse.

En dokumentsøgning med generativt svar har en længere datavej: Dokumenter importeres og forberedes, der genereres embeddings, et indeks gennemsøges, og relevant indhold overføres til sprogmodellen. Import og søgning kan stille andre krav til CPU, RAM og lagerplads end selve genereringen. Derfor er det en god idé at registrere tiderne og lagerbehovene for disse trin hver for sig.

Ved finjusteringen kan man Gradientakkumulering muliggøre en større effektiv batchstørrelse, selvom der kun behandles mindre enkeltbatches samtidigt. Gradienterne fra flere trin samles, før parametrene opdateres. Dette kan være en fordel ved begrænset hukommelse, men garanterer ikke en øget gennemstrømning; yderligere behandlingstrin kan tage tid.

Også datatilførslen fortjener en nærmere gennemgang: Hvis forbehandlingen eller indlæsningen halter bagefter modelbehandlingen, hjælper en større GPU ikke nødvendigvis. Omvendt kan en hurtig datapipeline ikke erstatte for lidt VRAM. Sammenlign derfor alternativerne med de samme inddata og et gennemsigtigt belastningsprofil.

Planlægning af lager- og GPU-forbindelser

Når man planlægger lagerplads, er det en god idé at skelne mellem datatyper og adgangsform: Træningsdatasæt læses gentagne gange, og modelvægte indlæses før brug. Begge dele kræver en pålidelig kilde, hvorfra de kan gendannes efter et skift af host. Kapacitet alene er ikke nok; også indlæsningstid og adgangsmønstre påvirker driften.

Midlertidige arbejdsdata kan lagres på en lokal NVMe-enhed, hvis der er behov for et hurtigt arbejdsområde. Spørg udbyderen, om disse data overlever genstarter og skift af vært. Checkpoints og sikkerhedskopier kræver derimod en bevidst planlagt opbevaring og en verificeret gendannelsesvej; et lokalt arbejdsmappe er ikke automatisk en uafhængig sikkerhedskopi.

Fælles tilgængelig eller objektbaseret lagring kan gøre det lettere at distribuere og opbevare datasæt, vægtninger og kontrolpunkter. Det afgørende er, om applikationen understøtter den valgte adgang, og om dataene kan indlæses og gendannes inden for den fastsatte tid. Et ekstra lokalt arbejdsområde kan være nyttigt, men erstatter ikke den permanente lagring.

GPUDirect Storage muliggør under passende hardware-, software- og filsystemforhold en mere direkte datavej mellem lagringsenheden og GPU-hukommelsen. Dette er især interessant, når ind- og udlæsning ligger på den kritiske vej, og applikationen benytter den understøttede vej. Hvis CPU’en først skal afkode eller forbehandle dataene, kan det begrænse fordelene.

Ved brug af flere GPU’er skal der skelnes mellem replikering og fordeling. Replikering stiller modelkopier til rådighed for at fordele forespørgsler; den omdanner ikke separate VRAM-områder til en fælles hukommelse automatisk. Dokumentationen til vLLM 0.20.1 beskriver en sådan dataparallel levering; dermed følger der ingen udtalelse om andre runtime-versioner.

Tensor- og pipeline-parallellisme fordeler derimod dele af behandlingen og skaber behov for kommunikation. Kontroller derfor forbindelserne mellem GPU’erne samt – ved flere servere – netværkstopologien og understøttelsen fra modellen og kørselstiden. Dokumentationen til vLLM 0.8.5 behandler disse strategier for distribueret serving; de konkrete anvisninger er versionsafhængige.

Registrere flaskehalse under belastning

En meningsfuld sammenligning starter med en dokumenteret lastprofil. Notér modelversion, præcision, den konkrete hardwarevariant og kørselstidens version. Angiv typiske og maksimale kontekstlængder, udgangslængder samt antallet af samtidige forespørgsler. På den måde kan en senere ændring af infrastrukturen testes under de samme betingelser.

Mål tiden indtil det første token og genereringshastigheden under inferensen. Registrer desuden fejl og svartider ved normal belastning og ved forventede spidsbelastninger. En høj gennemsnitlig gennemstrømning er ikke tilstrækkelig, hvis enkelte forespørgsler ved lange kontekster eller høj parallelitet venter for længe eller mislykkes.

Til træning og finjustering er trin eller behandlede eksempler pr. tidsenhed et godt udgangspunkt. Hold desuden øje med, hvor længe datapipelineen lader dig vente på den næste batch. PyTorch-DataLoader kan forberede data med flere arbejdsprocesser; deres hukommelsesbehov og belastningen af den delte hukommelse skal også indgå i vurderingen.

Registrer spidsbelastninger for GPU-hukommelse og RAM samt lagerudnyttelse og ventetider. På et eksisterende NVIDIA-system viser læse-kommandoen nvidia-smi Afhængigt af enhed og driver vises blandt andet GPU-status og hukommelsesforbrug. Det ændrer ikke nogen produktiv konfiguration, men erstatter ikke en måling af applikationen.

En lav GPU-udnyttelse er i sig selv ikke tegn på et problem med hverken CPU’en eller lagringspladsen. Sammenlign den over tid med datavente-tider, forløbet af forespørgsler og lagerudnyttelse, og ændr om muligt kun én relevant variabel pr. sammenligning. Dokumenter også testens begrænsninger, f.eks. hvis sjældne belastningsspidser eller særligt lange indtastninger stadig mangler.

Pålidelig drift af AI-infrastruktur

Driftsplanlægningen omfatter en kontrollerbar kombination af GPU-variant, driver, framework og modelkørselstid. Før du foretager opdateringer, skal du afklare, hvilke versioner der understøttes sammen, og hvordan du vender tilbage til den tidligere kombination, hvis der opstår problemer. Ved specielle datastier som f.eks. GPUDirect Storage skal hardware, software og filsystem desuden passe til den påtænkte anvendelse.

Fastlæg, hvem der må læse eller ændre modeller, træningsdata, logfiler og administrationsgrænseflader. For følsomme indtastninger skal desuden lagringssted, dataoverførsel og opbevaringsperiode afstemmes med kravene til databeskyttelse. Kontroller disse punkter for alle involverede tjenester, ikke kun for den server, hvor modellen kører.

En Kontrolpunkt gemmer en træningsstatus til senere genoptagelse. Planlæg, hvilke tilstande dit træningsprogram har brug for til dette formål, hvor ofte de skal gemmes, og hvor længe de skal opbevares. Modelvægte til levering og checkpoints til fortsættelse tjener forskellige formål og bør mærkes i overensstemmelse hermed.

Lokalt arbejdslager er ikke automatisk permanent og kan ikke erstatte en uafhængig sikkerhedskopi. Spørg udbyderen, hvad der sker med de lokale data ved genstart, udskiftning af serveren eller ved kontraktens udløb. Opbevar de nødvendige data uafhængigt af arbejdsområdet, og test gendannelsen i praksis, herunder hvor lang tid det tager, før systemet igen er klar til brug.

Ved distribuerede jobs omfatter overvågningen ud over de enkelte GPU’er også noder, netværksforbindelser og fremskridtet for hele applikationen. Planlæg, fra hvilket gemt punkt et job skal genstartes efter et nedbrud, og hvilke ressourcer der skal være tilgængelige til dette formål. Hvis modelkomponenter er fordelt på flere servere, påvirker deres forbindelser også driften; anvisningerne i vLLM-dokumentationen 0.8.5 er i denne sammenhæng versionsafhængige.

Vælg hostingmodel og GPU-server

Ved lejlighedsvis arbejde kan en midlertidigt ansat GPU-server kan være en god idé: Du betaler i henhold til de konkrete tilbudsbetingelser for den nødvendige kapacitet, i stedet for at skulle holde kapacitet til rådighed permanent. Sammenlign også opstartstider, tilgængelighed på det ønskede tidspunkt samt omkostninger til lagrede data og dataoverførsel.

Ved en jævn belastning kan det betale sig at vælge en permanent reserveret infrastruktur. Den kan give større kontrol over kørselstid og datavej, men kræver egen planlægning af opdateringer, overvågning og gendannelse. En administreret inferenstjeneste overtager dele af denne drift; tjek til gengæld, hvilke modeller, indstillinger og dataveje der rent faktisk er tilgængelige der.

Ved valg af infrastruktur til maskinlæring kræves oplysninger om en bestemt GPU-variant f.eks.: VRAM-kapacitet, hukommelsesbåndbredde, understøttede beregningsformater og formfaktor. Overfør ikke maksimale værdier fra en produktfamilie ukritisk til hver enkelt variant. Sammenlign ydeevneoplysninger kun med de tilhørende testbetingelser og den pågældende model, i stedet for udelukkende at basere din beslutning på en teoretisk topværdi.

Skaleringstypen indgår også i tilbuddet: Replikerede instanser kan fordele forespørgsler, mens en modelopdeling forudsætter understøttelse via kørselstid og forbindelsestopologi. Dokumentationen til vLLM omhandler dataparallelitet i version 0.20.1 og distribueret serving i version 0.8.5; disse oplysninger bør ikke overføres til en anden version uden nærmere undersøgelse.

Definer først modellen og belastningsprofilen, vurder derefter lagerkapacitet og datavej, og indhent passende tilbud. Kontroller derefter responstid, fejl og ressourcebehov ved hjælp af repræsentative forespørgsler eller træningsdata. Du kan finde yderligere aspekter til vurderingen under GPU-hosting til webapplikationer. Uden denne sammenligning af arbejdsbelastninger er det ikke muligt at udlede en generel anbefaling vedrørende GPU’er.