Det är lätt att fokusera på GPU:erna när man bygger en AI-plattform. Det är där budgeten går och där prestandan syns i specifikationerna. Men en GPU kan bara arbeta så snabbt som datan når fram till den. Står lagringen inte i proportion till beräkningskraften blir resultatet ett kluster som ser imponerande ut på papperet, men som i praktiken väntar en stor del av tiden.
Vi ser det ofta hos organisationer som har investerat i compute och sedan kopplat på befintlig lagring. Träningsjobben tar längre tid än väntat, GPU-utnyttjandet är lägre än det borde vara och ingen kan riktigt sätta fingret på varför. I den här artikeln tittar vi på varför AI ställer andra krav på lagring, vad ett parallellt filsystem tillför och hur ni undviker att I/O blir den begränsande faktorn.
Den dyraste väntan i datacentret
En GPU som väntar på data drar fortfarande ström, tar plats i racket och skrivs av i samma takt som en GPU som arbetar. Skillnaden är att den inte levererar något.
Ett enkelt räkneexempel visar hur snabbt det blir dyrt. Om ett kluster med 64 GPU:er väntar på I/O 30 procent av tiden motsvarar det ungefär 19 GPU:er som inte gör något nyttigt. Det är flera servrar som i praktiken lika gärna kunde vara avstängda.
Det lömska är att problemet sällan ser ut som ett lagringsproblem. Det upplevs snarare som att träningen tar tid, att köerna är långa eller att klustret helt enkelt är för litet. Den naturliga slutsatsen blir att köpa fler GPU:er, men om lagringen redan är flaskhalsen blir väntan bara längre.
Varför AI-workloads ställer andra krav
Traditionell företagslagring är byggd för databaser, virtuella maskiner och filservrar. Den hanterar många små, förutsägbara transaktioner bra och ger låg latens för enskilda användare. AI-workloads fungerar på ett helt annat sätt.
Under träning läser ofta hundratals GPU:er från samma dataset samtidigt, och alla vill ha full bandbredd på en gång. Datan kan bestå av miljontals små filer, som bilder eller dokument, som läses i slumpmässig ordning. Vid träning av stora språkmodeller handlar det i stället om stora sekventiella läsningar. En plattform för AI behöver klara båda.
Till det kommer checkpointing. Stora modeller sparar regelbundet sitt tillstånd, och under tiden står hela klustret och väntar. Ju längre en checkpoint tar, desto mer GPU-tid går förlorad. När datasetet dessutom har vuxit sig större än vad som får plats i lokalt minne eller på lokala NVMe-diskar måste data hämtas från delad lagring vid varje genomgång.
I produktion förändras mönstret igen. Inferens och RAG kräver att modeller laddas snabbt och att kontext kan hämtas med låg latens, ofta för många användare samtidigt.
En traditionell NAS med ett fåtal controllers blir i det här läget en tratt. Det spelar ingen roll hur många diskar som finns bakom, all trafik måste ändå passera samma punkt.
Vad ett parallellt filsystem tillför
Ett parallellt filsystem fördelar både data och metadata över många lagringsnoder. I stället för att köa genom en enskild controller kan varje GPU-server läsa från flera noder samtidigt. När ni lägger till noder ökar inte bara kapaciteten, utan också bandbredden.
Metadata är en del som ofta förbises. När ett dataset består av miljontals filer blir operationer som att öppna, lista och kontrollera filer en betydande belastning. Hanteras all metadata på ett ställe flyttar flaskhalsen bara dit.
Den tredje pusselbiten är hur datan tar sig till GPU:n. Med RDMA och NVIDIA GPUDirect Storage kan data gå direkt från lagringen till GPU-minnet, utan att passera CPU och systemminne. Det ger lägre latens och frigör CPU-kapacitet till förbehandling av data.
Nätverket förtjänar samma uppmärksamhet. Ett parallellt filsystem kan aldrig bli snabbare än nätverket som bär det. Därför dimensioneras storage-nätverket i en referensarkitektur som NVIDIA DGX SuperPOD lika noggrant som nätverket mellan GPU-noderna.
Så undviker ni I/O-flaskhalsen
Det mesta går att förebygga om lagringen planeras tillsammans med resten av plattformen. Det här är principerna vi brukar utgå från:
- Utgå från GPU:ernas behov. Den första frågan bör vara hur mycket genomströmning klustret behöver för att hålla GPU:erna sysselsatta. Kapacitet i terabyte kommer i andra hand.
- Lär känna era workloads. Små filer eller stora block, läs- eller skrivtungt, hur stora checkpoints och hur ofta de skrivs. Svaren styr vilken arkitektur som passar.
- Se nätverket som en del av lagringen. En välvald dataplattform bakom ett underdimensionerat nätverk ger samma resultat som en dålig.
- Använd flera lagringsnivåer. Aktiv data på all-flash nära GPU:erna, äldre data och arkiv på mer kostnadseffektiv objektlagring. Moderna plattformar flyttar data mellan nivåerna automatiskt.
- Följ GPU-utnyttjandet över tid. Sjunker utnyttjandet samtidigt som systemet väntar på I/O är det ofta lagringen som begränsar. Den mätningen hör hemma i MLOps-plattformen från början.
VAST, WEKA och andra alternativ
VAST Data och WEKA hör till de mest etablerade plattformarna för AI-lagring, men de angriper problemet på olika sätt. Det finns också fler alternativ som kan vara rätt beroende på miljö och skala.
Vilken plattform som passar bäst beror på era workloads, er skala, ert nätverk och vem som ska drifta lösningen. Licensmodell, support och hur väl plattformen passar in i befintlig miljö väger ofta lika tungt som ren prestanda.
| Plattform | Arkitektur | Styrka | Passar när |
|---|---|---|---|
| VAST Data | Disaggregerad all-flash, shared-everything | Samlar fil, objekt och data i en plattform i stor skala | Ni vill ha datasjö, träning och inferens på samma ställe |
| WEKA | Mjukvarudefinierat parallellt filsystem på NVMe | Mycket låg latens, stark på små filer, on-prem och moln | Prestanda per GPU är avgörande eller ni kör hybrid |
| DDN EXAScaler | Lustre-baserat parallellt filsystem | Hög sekventiell bandbredd, lång HPC-tradition | Stora forsknings- och HPC-miljöer |
| IBM Storage Scale | Parallellt filsystem (tidigare GPFS) | Mogen lösning med omfattande enterprise-funktioner | Ni har en IBM-miljö eller strikta krav på datahantering |
| Pure Storage FlashBlade | Scale-out all-flash för fil och objekt | Enkel drift och förutsägbar prestanda | Mindre och medelstora kluster där enkelhet väger tungt |
| Lustre / BeeGFS (open source) | Parallellt filsystem | Låg licenskostnad | Ni har egen kompetens för drift och felsökning |
Så märker ni att klustret svälter
Det finns några tydliga tecken på att lagringen håller tillbaka er AI-plattform:
- GPU-utnyttjandet ligger stadigt under 70 procent under träning.
- Den första epoken tar märkbart längre tid än de följande.
- Checkpoints tar minuter snarare än sekunder.
- Fler GPU:er ger inte kortare träningstid.
- Datascientists kopierar data till lokala diskar för att det går snabbare.
- Lagringen delas med andra system och prestandan varierar över dygnet.
Känner ni igen ett eller flera av dem är det värt att se över dataplattformen innan nästa investering i compute.
Bygg en dataplattform som håller takten
Aixia är Skandinaviens enda NVIDIA DGX SuperPOD-certifierade partner. Vi designar, bygger och driftar AI-infrastruktur där compute, nätverk och lagring planeras som en helhet, med plattformar som VAST Data, WEKA och Pure Storage och nätverk från Arista.
Vi börjar alltid med att förstå era workloads, inte med att välja produkt. Det ger en arkitektur som håller GPU:erna sysselsatta redan i dag och som kan växa i takt med datan.
Boka en arkitekturgenomgång av er dataplattform. Tillsammans går vi igenom era workloads, identifierar var flaskhalsarna finns och tar fram en konkret rekommendation för hur lagringen kan matcha er GPU-investering.
