Hosting för AI-applikationer: Dimensionering av CPU, GPU och lagringsutrymme

Begränsa först AI-arbetsbelastningen

Valet av hårdvara börjar med uppgiften, inte med ett grafikkort. När det gäller Slutsats En befintlig modell bearbetar indata och genererar till exempel svar. Finjustering anpassar en förtränad modell till ytterligare data eller en uppgift; fullständig träning bygger däremot upp modellvikterna inom ramen för en egen träningsomgång.

Dessa mål leder till olika belastningsprofiler: En chattjänst måste svara på förfrågningar, medan ett träningsjobb bearbetar data under en längre tid och lagrar delresultat. För AI-hosting Du bör därför ta hänsyn till om det är svarstiden, antalet behandlade förfrågningar, träningstiden eller kanske kostnaderna för en viss uppgift som är viktigast.

Dokumentera modellversion och körtid samt antal parametrar, arkitektur, noggrannhet och planerad kvantisering. Notera dessutom de förväntade in- och utdatalängderna, samtidiga förfrågningar respektive batchstorlekar samt toppbelastningen. På så sätt kan offerter och senare tester jämföras utifrån samma antaganden, istället för att endast jämföra nominella hårdvarudata.

I en intern chattassistent kan en enskild kort förfrågan hanteras utan problem, medan flera långa konversationer kan överbelasta minnet. KV-cachen lagrar ytterligare tillstånd vid textgenerering; dess behov beror bland annat på modellen och bearbetningen. Planera därför inte bara för den genomsnittliga dialogen, utan även för långa sammanhang och parallell användning.

Notera även vilka data som behandlas, var de får lagras samt vilka krav som ställs på tillgänglighet och återställningstid. Dessa driftsmål påverkar valet mellan en enskild server och en mer komplex arkitektur. Antagandena utgör endast en utgångspunkt: först en test med representativ belastning visar om de håller.

CPU och RAM på gång

Även om en modell körs på en GPU arbetar CPU:n med längs datavägen. Den kan ta emot förfrågningar, tokenisera text, läsa filer och förbereda indata för modellbearbetningen. Om denna förberedelse går för långsamt får GPU:n vänta på arbete; en kraftfullare accelerator löser då inte nödvändigtvis flaskhalsen.

Der Arbetsminne Beroende på användningsområdet tar den in modellkomponenter, förberedda data och filcacher. Till detta kommer minne för processer som laddar och omvandlar träningsdata. Planera därför inte bara själva modellen, utan även vägen från datamängden till den färdiga batchen samt tillräckliga reserver för toppar i bearbetningen.

PyTorch-DataLoader kan använda flera arbetare för parallell databehandling. Ytterligare arbetare tar dock också upp minne, och även det delade minnesutrymmet kan bli knappt. Öka därför antalet stegvis och håll koll på väntetiderna för data och minnesbehovet, istället för att använda ett fast värde som en allmän rekommendation.

Fler CPU-kärnor är framför allt till hjälp när de uppgifter som ska utföras kan köras parallellt. Om däremot lagringsåtkomst, ett enskilt bearbetningssteg eller själva GPU:n begränsar genomströmningen, har fler kärnor liten betydelse. Även klockfrekvensen kan vara relevant för korta förfrågningar; mer bakgrundsinformation om detta finns i artikeln om CPU-regulator på webbhotellsservrar.

För små modeller eller sällsynta förfrågningar är CPU-inferens ett alternativ värt att överväga jämfört med ett GPU-system som är permanent tillgängligt. Jämför båda alternativen med samma modell, lämplig noggrannhet och den förväntade belastningsprofilen. Det avgörande är om CPU:n uppnår den erforderliga svarstiden även vid belastningstoppar och vilka kostnader som faktiskt uppstår.

Att förstå GPU och VRAM på rätt sätt

Vid en helt GPU-baserad inferens måste modellvikterna rymmas i det tillgängliga GPU-minnet. Den VRAM-behov Men det slutar inte där: Körtiden kräver ytterligare utrymme för delresultat och tillfälliga buffertar. En karta där vikterna räknemässigt precis får plats utgör därför ännu inte en säker grund för produktiv drift.

Vid autoregressiv textgenerering tillkommer KV-cachen. Den lagrar redan beräknade nyckel- och värdetillstånd så att de kan återanvändas i efterföljande genereringssteg. Långa sammanhang och förfrågningar som bearbetas samtidigt kan öka detta extra minnesbehov; i vilken utsträckning beror på modellen och bearbetningen.

Dokumentationen för Transformers 4.48.2 beskriver bland annat cachekvantisering och utlagring som sätt att spara VRAM. Nyttan beror dock på implementeringen och belastningen; ytterligare bearbetning eller dataöverföringar kan minska hastigheten. Kontrollera därför både minnesanvändning och svarstid tillsammans, istället för att automatiskt betrakta minnesbesparingar som en prestandaförbättring.

Vid träning räcker inferensberäkningen inte alls till. Förutom vikterna uppstår lagringsbehov för gradienter, optimerartillstånd och lagrade aktiveringar. Hur stora dessa andelar blir beror bland annat på optimeraren, precisionen och träningsmetoden; längre sekvenser eller större batcher kan i synnerhet öka lagringsbehovet för aktiveringar.

För en helt GPU-baserad körning måste det tillgängliga VRAM-minnet rymma de nödvändiga vikterna och körningsdata. Hybridmetoder kan lagra delar av bearbetningen eller modellvikterna utanför GPU:n; deras lämplighet och kostnaderna för dataöverföringar beror på körtiden. Detta ska skiljas från den utlagring av KV-cachen som beskrivs i Transformers 4.48.2.

Betrakta modell, körtid och planerad parallellitet i sitt sammanhang och kontrollera de maximala minnesnivåerna under representativ belastning. Att det finns tillräckligt med minne för den valda implementeringen är inte i sig ett bevis på önskad svarstid eller utnyttjandegrad.

Beräkna modellminnet ungefärligt

En första minnesberäkning utgår från antalet modellparametrar och det format i vilket deras vikter faktiskt lagras. Den ger en nedre gräns för denna minnesandel, men ännu ingen fullständig dimensionering av GPU-servern. Framför allt säger den ingenting om hur mycket minne en konkret förfrågan kräver under körning.

Illustrativt räkneexempel, ingen mätning: Sju miljarder parametrar multiplicerat med två byte ger 14 miljarder byte för vikterna. Delat med 1 073 741 824 byte per GiB blir det cirka 13,0 GiB. Förutsättningen är att alla vikter som beaktas faktiskt är enhetliga med två byte per parameter; andra format eller ytterligare representationer förändrar beräkningen.

Följande ingår inte: KV-cache för textgenerering, tillfälliga buffertar och körningstidens overhead. Särskilt vid långa sammanhang kan cachen växa avsevärt; även antalet förfrågningar som bearbetas samtidigt är relevant för den nödvändiga reserven. Cache-dokumentationen för Transformers 4.48.2 beskriver dessutom metoder som kan spara minne, men som beroende på metod kan gå ut över hastigheten.

När det gäller träning räcker viktberäkningen verkligen inte till. Dokumentationen till Transformers 4.35.0 uppskattar att en exempelkonfiguration med blandad precision och AdamW kräver 18 byte per parameter plus aktiveringar. Detta inkluderar även andra komponenter såsom gradienter och optimerartillstånd; aktiveringarna beror bland annat på sekvenslängd och batchstorlek.

De 18 byte är inte en allmän multiplikator för varje träning: optimeringsverktyg, precision och träningsmetoder kan påverka behovet. Varken detta tal eller 13,0 GiB utgör därför en rekommendation för en viss VRAM-storlek. Avgörande för valet är den faktiska körtiden och de förväntade maximala minnesbelastningarna under representativ belastning.

Jämföra arbetsbelastningar och flaskhalsar

Samma modellvikter kan, beroende på uppgiften, medföra mycket olika krav. Tabellen visar möjliga testpunkter, inte någon rangordning och inga garanterade flaskhalsar. Vilken resurs som faktiskt utgör en begränsning beror bland annat på modellen, datapipeline, parallellisering och belastning.

När det gäller en intern chattassistent är modellen och genereringen bara en del av planeringen. Ange en maximal inmatningslängd, en förväntad utmatningslängd och antalet samtidiga användare. Därefter kan man kontrollera om svarstiden förblir acceptabel vid toppbelastning och om vikter, cache och buffert samtidigt ryms i det tillgängliga minnet.

En dokumentsökning med generativt svar har en längre dataväg: dokument importeras och bearbetas, inbäddningar genereras, ett index genomsöks och relevant innehåll överförs till språkmodellen. Import och sökning kan ställa andra krav på CPU, RAM och lagringsutrymme än själva genereringen. Därför är det värt att registrera tidsåtgången och lagringsbehovet för dessa steg separat.

Vid finjusteringen kan man Gradientackumulering möjliggöra en större effektiv batchstorlek, även om endast mindre enskilda batcher bearbetas samtidigt. Gradienterna från flera steg samlas in innan parametrarna uppdateras. Detta kan vara till hjälp vid begränsat minne, men innebär ingen garanterad ökning av genomströmningen; ytterligare bearbetningssteg kan ta tid.

Även datatillförseln förtjänar att granskas närmare: Om förbearbetningen eller inläsningen släpar efter modellbearbetningen hjälper inte nödvändigtvis en kraftfullare GPU. Omvänt kan en snabb datapipeline inte ersätta ett för litet VRAM-minne. Jämför därför olika alternativ med samma indata och en tydlig belastningsprofil.

Planera lagring och GPU-anslutningar

Vid lagringsplaneringen är det värt att göra en uppdelning efter datatyp och åtkomst: Träningsdatauppsättningar läses upprepade gånger, medan modellvikterna laddas in före användning. Båda kräver en tillförlitlig källa från vilken de kan göras tillgängliga på nytt efter ett värdbyte. Kapacitet i sig räcker inte; även laddningstid och åtkomstmönster påverkar driften.

Tillfälliga arbetsdata kan lagras på en lokal NVMe-enhet om det krävs ett snabbt arbetsutrymme. Kontrollera med leverantören om dessa data klarar omstarter och byte av värd. Kontrollpunkter och säkerhetskopior kräver däremot en noggrant planerad lagring och en verifierad återställningsväg; en lokal arbetsmapp är inte automatiskt en oberoende säkerhetskopia.

Delad eller objektbaserad lagring kan underlätta distributionen och bevarandet av dataposter, vikter och kontrollpunkter. Det avgörande är om applikationen stöder den valda åtkomstmetoden och om data kan laddas och återställas inom den avsedda tiden. Ett extra lokalt arbetsområde kan vara lämpligt, men ersätter inte den permanenta lagringen.

GPUDirect Storage möjliggör, under lämpliga förhållanden vad gäller hårdvara, mjukvara och filsystem, en mer direkt dataväg mellan lagringsenheten och GPU-minnet. Detta är särskilt intressant när in- och utmatning ligger på den kritiska vägen och applikationen använder den stödda vägen. Om CPU:n först måste avkoda eller förbehandla data kan detta begränsa nyttan.

Vid användning av flera GPU:er måste man skilja mellan replikering och fördelning. Replikering tillhandahåller kopior av modellen för att fördela förfrågningar; den omvandlar inte automatiskt separata VRAM-områden till ett gemensamt minne. Dokumentationen för vLLM 0.20.1 beskriver en sådan dataparallell distribution; detta innebär inte att samma gäller för alla andra runtime-versioner.

Tensor- och pipeline-parallellism fördelar däremot delar av bearbetningen och skapar behov av kommunikation. Kontrollera därför anslutningarna mellan GPU:er samt, vid flera servrar, nätverkstopologin och stödet från modellen och körmiljön. Dokumentationen till vLLM 0.8.5 behandlar dessa strategier för distribuerad serving; de konkreta anvisningarna är versionsberoende.

Upptäcka flaskhalsar under belastning

En meningsfull jämförelse börjar med en dokumenterad lastprofil. Ange modellversion, noggrannhet, specifik hårdvaruvariant och version av körmiljön. Ange typiska och maximala kontextlängder, utdatalängder samt antalet samtidiga förfrågningar. På så sätt kan en senare förändring av infrastrukturen testas under samma förhållanden.

Vid inferensen ska du mäta tiden fram till det första tokenet och genereringshastigheten. Registrera dessutom fel och svarstider vid normal belastning och vid förväntade toppar. En hög genomsnittlig genomströmning räcker inte om enskilda förfrågningar får vänta för länge eller misslyckas vid långa sammanhang eller hög parallellitet.

För träning och finjustering är steg eller bearbetade exempel per tidsenhet lämpliga som utgångspunkt. Observera samtidigt hur lång tid datapipeline tar på sig att vänta på nästa batch. PyTorch-DataLoader kan förbereda data med flera arbetare; deras minnesbehov och belastningen på det delade minnet bör också beaktas i utvärderingen.

Registrera toppvärden för GPU-minne och RAM samt lagringsutnyttjande och väntetider. På ett befintligt NVIDIA-system visar läsbefallningen nvidia-smi beroende på enhet och drivrutin, bland annat GPU-status och minnesanvändning. Det ändrar inte någon produktiv konfiguration, men ersätter inte en mätning av applikationen.

En låg GPU-utnyttjandegrad tyder i sig varken på ett CPU- eller ett lagringsproblem. Jämför den över tid med väntetider för data, förfrågningsförlopp och lagringsutnyttjande, och ändra om möjligt endast en relevant variabel per jämförelse. Dokumentera även testets begränsningar, till exempel om sällsynta belastningstoppar eller särskilt långa inmatningar fortfarande saknas.

Att driva AI-infrastruktur på ett tillförlitligt sätt

Driftsplaneringen innefattar en verifierbar kombination av GPU-variant, drivrutin, ramverk och modellkörningstid. Kontrollera före uppdateringar vilka versioner som stöds tillsammans och hur du återgår till den tidigare kombinationen om problem uppstår. Vid speciella datavägar, såsom GPUDirect Storage, måste dessutom hårdvara, mjukvara och filsystem passa den avsedda användningen.

Fastställ vem som får läsa eller ändra modeller, träningsdata, loggar och administrationsgränssnitt. För känsliga uppgifter måste dessutom lagringsplats, dataöverföring och lagringstid anpassas till kraven på dataskydd. Kontrollera dessa punkter för alla berörda tjänster, inte bara för den server där modellen körs.

En Kontrollpunkt sparar ett träningsläge för senare återupptagning. Planera vilka tillstånd din träningsprogramvara behöver för detta, hur ofta de ska sparas och hur länge de ska bevaras. Modellvikter för leverans och kontrollpunkter för fortsättning fyller olika syften och bör märkas därefter.

Lokalt arbetslagringsutrymme är inte automatiskt permanent och ersätter inte en oberoende säkerhetskopia. Fråga leverantören vad som händer med lokala data vid omstart, byte av värd eller när avtalet löper ut. Spara nödvändiga data separat från arbetsmiljön och testa återställningen i praktiken, inklusive tiden det tar innan systemet är klart att användas igen.

Vid distribuerade jobb omfattar övervakningen, förutom de enskilda GPU:erna, även noder, nätverksanslutningar och hela applikationens framsteg. Planera från vilket lagrat läge ett jobb ska startas om efter ett avbrott och vilka resurser som måste vara tillgängliga för detta. Om modelldelar är fördelade över flera servrar påverkar även deras anslutningar driften; anvisningarna i vLLM-dokumentationen 0.8.5 är versionsbundna.

Välj hostingmodell och GPU-server

Vid tillfälliga uppdrag kan en tillfälligt anställd GPU-server kan vara fördelaktigt: Du betalar enligt de konkreta villkoren i erbjudandet för den resurs som behövs, istället för att ständigt hålla kapacitet i beredskap. Jämför även starttider, tillgänglighet vid önskad tidpunkt samt kostnader för lagrad data och dataöverföring.

Vid jämn belastning lönar det sig att välja en permanent reserverad infrastruktur. Den kan ge större kontroll över körtid och dataväg, men kräver egen planering för uppdateringar, övervakning och återställning. En hanterad inferenstjänst tar hand om delar av denna drift; kontrollera i gengäld vilka modeller, inställningar och datavägar som faktiskt finns tillgängliga där.

För valet av infrastruktur för maskininlärning krävs uppgifter om en specifik GPU-modell t.ex.: VRAM-kapacitet, minnesbandbredd, stödda beräkningsformat och utformning. Överför inte maximivärden för en produktfamilj till varje variant utan att först ha kontrollerat dem. Jämför prestandauppgifter endast med deras testförhållanden och den avsedda modellen, istället för att fatta beslut enbart utifrån ett teoretiskt toppvärde.

Även skalningstypen ingår i utbudet: Replikerade instanser kan fördela förfrågningar, medan en modelluppdelning kräver stöd genom körningstid och anslutningstopologi. Dokumentationen för vLLM behandlar dataparallellitet i version 0.20.1 och distribuerad betjäning i version 0.8.5; dessa uppgifter bör inte överföras till en annan version utan att först kontrolleras.

Ange först modell och belastningsprofil, gör sedan en uppskattning av lagringsutrymme och dataväg och begär in lämpliga offerter. Kontrollera därefter svarstid, fel och resursbehov med hjälp av representativa förfrågningar respektive träningsdata. Ytterligare aspekter för klassificering hittar du på GPU-hosting för webbapplikationer. Utan denna jämförelse av arbetsbelastningar går det inte att dra några generella slutsatser om vilken GPU som rekommenderas.