Lagringslag i en AI-server: Model, datasæt, Scratch, Checkpoint

Vi har en tilbagevendende samtale med købere om NVMe. De beder om "så hurtigt som muligt", fordi specifikationsarkene viser 14 GB/s på et Gen5-drev, og en 4090 ved siden af ​​en Samsung 9100 PRO lyder matchende. Så spørger vi, hvad boksen er til, svaret er "for det meste inferens", og den rigtige build viser sig at være ét drev i stedet for otte. Lagring i en AI-server er den del af specifikationen, hvor overkøb er nemt, smertefrit for leverandøren og næsten fuldstændig usynligt for arbejdsbyrden.

Denne artikel dækker de fire reelle lagerniveauer i en enkelt AI-server, hvad hver enkelt rent faktisk skal gøre, hvordan NVMe-markedet i 2026 ser ud, hvornår Gen5 er sin præmie værd, hvorfor hardware-RAID holdt op med at betyde noget for NVMe, og hvordan man kan dimensionere hvert niveau uden at bruge penge. Valg af filsystem er et separat spørgsmål, der behandles i L04; klyngedelt lager (NFS, BeeGFS, Lustre, objektlagre) er K04. Her holder vi os inde i kabinettet.

De fire opbevaringslag

En seriøs AI-server har fire forskellige lagerroller. De har vidt forskellige størrelser, gennemløbshastigheder, udholdenheds- og omkostningsprofiler. At behandle dem som én pulje er den første fejltagelse.

En inferensserver med 4 GPU'er behøver typisk kun det første niveau og måske en lille smule af det andet. En træningsboks med 8 GPU'er behøver alle fire, og de fire ønsker forskellige drev. Spørgsmålet "hvor mange TB NVMe?" er meningsløst uden at vælge et niveau.

Modelopbevaring

Modelniveauet er det, der indeholder dit bibliotek af vægte — alle Llama-, Qwen-, Mistral-, Stable Diffusion-, Flux- og Whisper-varianter, du nogensinde forventer at indlæse. Det er også her, operativsystemet, containerbillederne, conda-envs og inferensserverens binære filer findes. For de fleste builds kollapser disse på boot-drevet.

Størrelsesbestemmelse er en funktion af, hvor mange modeller du har residente. Nogle eksempler på almindelige kvantiseringer:

• Llama 3 70B Q4: ~40 GB
• Llama 3 70B FP8: ~70 GB
• Qwen2.5-VL 72B Q4: ~45 GB plus et par GB vision-tårn
• Mistral Large 2 (123B) Q4: ~70 GB
• Llama 4 Maverick MoE FP8: ~250 GB
• Et beskedent VLM-bibliotek (8 modeller, blandede kvantiseringer): 300-500 GB
• Et forskningslaboratorium, der holder 30 modeller varme: 2-4 TB

Læsefor det meste. Modellen indlæses én gang ved processtart og forbliver i VRAM resten af ​​dagen. Drevet ser en sekventiel læsning på 40 GB ved vLLM-opstart og går derefter stort set i dvale. En enkelt 2-4 TB Gen4 NVMe - selv et forbrugerdrev som en Samsung 990 PRO - håndterer dette uden at blive for travlt. Betal for kapacitet, ikke gennemløb.

Datasætlagring

Datasættet er der, hvor træningskorpora og finjusteringsmateriale findes. Det er på dette niveau, kunderne kronisk underspecificerer, fordi det datasæt, de arbejder med i dag, passer, og de glemmer, at det næste ikke gør.

Realistiske intervaller:

• Finjustering af LoRA-korpus med enkelt domæne: 10-100 GB
• Multimodalt finjusteringssæt (billeder + tekst): 1–10 TB
• Tekstkorpus på prætræningsniveau (FineWeb-undergruppe osv.): 5-50 TB
• Videoforberedende træning eller robotdemonstrationssæt: 20-200 TB
• Genomisk, videnskabeligt eller scrapet webarkiv: 100 TB – 1 PB+

Adgangsmønsteret er sekventiel læsning, gentaget på tværs af epoker, på tværs af mange DataLoader-arbejdere parallelt. Gennemløbsfølsom (fordi GPU'en venter), latenstidstolerant. Skrivehastigheden er stort set nul, når dataene er staged.

For datasæt over ~10 TB forlader det rigtige svar normalt kabinettet — se K04 for NFS, BeeGFS og objektlagringsmønstre. Inde i kabinettet er et datasætlag af harddiske i RAIDZ2 (billigt, stort, langsomt, men tilstrækkeligt efter opvarmning af sidecachen) eller et mellemlags U.2 NVMe RAID rimeligt op til måske 50 TB.

Skrab

Scratch er den ubesungne helt. Den absorberer alt, der ikke passer helt ind andre steder: afkodede billedfragmenter, mellemliggende aktiveringer spildt af ZeRO-Offload, datasætcacher bygget af webdataset/DALI, midlertidige datasætombytninger, containeropbygningsartefakter og dump af en nedbrudt kørsel. Læsetung og skrivetung på samme tid.

Størrelse: 2-8 TB er det optimale. Mindre end 2 TB og en enkelt finjustering fylder det. Mere end 8 TB, og du bygger normalt et lille datasætlag og kalder det for scratch – fint nok, men indrøm hvad du gør.

Udholdenhed betyder noget her på en måde, som det ikke gør for de andre niveauer. Scratch æder skrivninger — 5-20 TB skrevet om dagen er ikke usædvanligt på en meget brugt træningsboks. Et 1 DWPD enterprise-drev på 4 TB tillader 4 TB skrevet om dagen i fem år; et seriøst træningsdrev fra scratch ønsker 1-3 DWPD, blandet brugsgrad.

Checkpoint

Checkpoint-niveauet er der, hvor træningstilstanden lander. Bursty: lydløs i ti minutter, derefter 50-500 GB skrevet på et par sekunder, og derefter lydløs igen.

Et 70B-modelcheckpoint ved FP16 har en vægt på ~140 GB. Med FSDP øger gradienter og optimeringstilstand fodaftrykket pr. checkpoint til 400-700 GB. Med DeepSpeed ​​ZeRO-3 og fuld optimeringstilstand (Adam: 8 bytes pr. parameter for master FP32 + første/andet øjeblik) kan et 70B-checkpoint lande tæt på 1 TB.

Den vedvarende skrivehastighed for en enkelt Gen5 NVMe er ~10-13 GB/s. Et checkpoint på 700 GB skriver optimistisk set på cirka et minut – hvis hver rang streamer til sit eget drev. Synkront trænes blokke for det minut. Løsningen er asynkron sharded checkpointing (beskrevet nedenfor).

NVMe Gen4 vs Gen5 — når premium-prisen er det værd

NVMe-markedet i 2026 er delt mellem en moden Gen4 (5-7 GB/s) og den nuværende mainstream Gen5 (12-14 GB/s). Øverst på forbrugermarkedet ligger Samsung 9100 PRO med 14.8 GB/s sekventiel læsning og 13.4 GB/s sekventiel skrivning. Enterprise Gen5 er i samme nabolag — Solidigm D7-PS1010 med 14.5 GB/s læsning, Micron 9550 MAX med 14 GB/s læsning, Kioxia CD8, SanDisk DC SN861 — som alle leverer 13-14 GB/s læsning og 8-10 GB/s vedvarende skrivning.

Omkostningspræmien for Gen5 i forhold til Gen4 med sammenlignelig kapacitet i midten af ​​2026 er 30-50 % i forbrugerenden og 20-35 % i virksomhedsenden.

Når Gen5 rent faktisk betaler tilbage:

• Modelindlæsning fra kulde. En 250 GB MoE-model indlæses på 18 sekunder på Gen5 vs. 36 sekunder på Gen4. Det har betydning, hvis du ofte skifter model.
• Trænings-I/O-bundet. Vision pipelines, der afkodning af rå JPEG'er fra disk, multimodale datasæt, hvor forbehandling er flaskehalsen.
• Kontrolpunkt til lokal NVMe før asynkron kopiering. Jo hurtigere den lokale skrivning er, desto hurtigere genoptages træningen.
• Klyngelagerserver, der understøtter 8+ træningsnoder. Den samlede kundeefterspørgsel overstiger Gen4-loftet.

Når Gen4 er fin, og Gen5 er spildte penge:

• Inferensservere. Modellen indlæses én gang ved opstart; resten af ​​dagen er drevet på et encifret MB/s.
• OS-rod og containerlager. Start op en gang om måneden, installer pakker af og til.
• Datasætniveau, hvor shards er foruddekodede og store. PyTorch DataLoader med 8 arbejdere, der læser WebDataset-shards, mætter med måske 4-6 GB/s samlet set; Gen4 dækker det.

Den ærlige version: omkring 70% af de kundebuilds, vi leverer, er ren inferens, og for dem er Gen4 NVMe generelt korrekt. Gen5 er en beslutning på træningsniveau.

Formfaktorer — M.2, U.2/U.3, E3.S

M.2 Gen5 vil reducere temperaturen. En Samsung 9100 PRO 2 TB, der vedligeholdes ved 13 GB/s i et varmt kabinet, når 75 °C og clocker tilbage. Modeller med køleplade hjælper. M.2 er fin til opstart og moderate arbejdsbelastninger; det er ikke den rigtige formfaktor til et scratch-niveau med vedvarende skrivning.

U.2 er arbejdshesten. Alle Kentino NVMe-drev til virksomheder, der leveres i et Bone64c- eller Supermicro-kabinet, er U.2, næsten universelt udskiftelige med U.3-backplanes. 25 W termisk envelope, dobbeltport til multipath, hot-swap, 7.68 TB og 15.36 TB kapaciteter ligger på det optimale pris-densitetsniveau.

E3.S er fremtiden, langsomt. Designet fra bunden til Gen5/Gen6-termiske processorer. For en Kentino-build med én server eller en lille klynge forbliver U.2/U.3 det praktiske valg frem til 2026; E3.S kommer på banen til opdateringscyklusser i 2027.

Undgå at stable M.2-bærere i et varmt kabinet. PCIe-kortadaptere, der holder fire M.2-drev bag en switchchip, fungerer, men i en 4U-server med otte GPU'er er luftstrømmen over disse bærere dårlig. Vi ser termisk throttling inden for ti minutter ved vedvarende belastning. Hvis du har brug for fire NVMe i en server, skal du bruge U.2.

Udholdenhed — DWPD som et købssignal

For en AI-server er kortlægningen ligetil:

• Modelniveau: læseintensiv, 0.3–1 DWPD.
• Datasætniveau: læseintensiv, 0.3–1 DWPD.
• Skrabeniveau: blandet anvendelse, 1-3 DWPD. Dette er det niveau, der tjener sit udholdenhedsbudget.
• Kontrolpunktsniveau: Blandet brug, 1-3 DWPD. Bursty-skrivninger akkumuleres; 1 DWPD på et 4 TB-drev tillader kun 4 TB/dag, hvilket en høj træningskadence overstiger.

Skriveintensiv (3+ DWPD) er overkill for næsten alle AI-arbejdsbelastninger. At købe det forkerte udholdenhedsniveau kan gendannes ved udskiftning; at købe den forkerte gennemløbsklasse kan ofte ikke. Få den rette gennemløbshastighed på byggetidspunktet, og betragt udholdenhed som noget, du kan opgradere.

RAID til NVMe — hardwaren er død, softwaren er svaret

Dette fortjener sit eget underafsnit, fordi kunderne stadig spørger. Den korte version: hvis din build har en hardware RAID-controller foran NVMe-drevene i 2026, er den forkert konfigureret.

Hardware RAID-controllere (LSI/Broadcom MegaRAID, Microchip SmartRAID, HPE Smart Array, Dell PERC) blev designet til SAS/SATA. Controllerens indbyggede ASIC håndterer paritet, caching og kommandokø, og ved SAS-båndbredde (12 Gbit/s = 1.5 GB/s) har den masser af plads.

NVMe Gen5 med 14 GB/s pr. drev mætter en RAID-controller med et enkelt kort efter to drev. Otte drev bag et hardware-RAID-kort producerer mere båndbredde, end kortets PCIe-uplink kan flytte. Controlleren bliver flaskehalsen og derefter fejlpunktet.

De praktiske svar er software:

• mdadm (Linux-software-RAID). Moden, in-kernel, understøtter RAID0/1/10 godt. RAID5/6 på NVMe fungerer, men paritetsberegningen bruger CPU'en. Til 4 NVMe i mirror eller stripe: perfekt.
• ZFS RAIDZ2. Bedre integritetshistorie (end-to-end checksums), bedre værktøjer til scrubs og erstatning, snapshot/klon semantik. CPU-tungere end mdadm. Det rigtige valg til arkiv- og datasætlag, hvor dataintegritet er vigtigere end maksimal gennemløbshastighed.
• Replikering/sletning af kodning pr. drev på applikationslaget. For meget store arrays flytter MinIO/Ceph EC eller BeeGFS-striping redundansafgørelsen helt ud af bloklaget.

For de fleste Kentino-builds:

• Støvle: 2× M.2 NVMe i mdadm RAID1.
• Kradse: RAID0 på tværs af 2-4 NVMe (data kan regenereres).
• Datasæt/tjekpunkt: RAID10 i mdadm eller RAIDZ2 i ZFS.

Hardware RAID har præcis ét tilbageværende use case i en AI-server: et lille boot-spejl bag et grundlæggende Broadcom/MegaRAID-kort på en server, hvor man absolut ønsker pre-OS boot-redundans. Selv der fungerer mdadm RAID1 med EFI på begge drev fint.

Netværkstilsluttet lagring til datasætniveauet

Konklusionen er, at datasættet næsten altid hører hjemme uden for AI-serveren over 10 TB. Inde i kabinettet ønsker man hurtig scratch, hurtigt checkpoint og et modellager; datasættet kan være eksternt.

Hvordan PyTorch rent faktisk indlæser data

En nyttig model til dimensionering af lagring er at følge PyTorchs DataLoader gør. Med num_workers=8 og pin_memory=True:

1. Otte arbejdere behandler hver åbne datasætfil parallelt.
2. Hver arbejder læser, afkoder (JPEG, videobilleder, lyd-resample) og tensoriserer en sample.
3. Den afkodede tensor placeres i den delte hukommelse.
4. Hovedprocessen henter data fra den delte kø, forbinder data til værtens RAM og kopierer til GPU via DMA.

De praktiske implikationer:

• En visionspipeline er sjældent lagerbundet medmindre datasættet er så stort, at sidens cache ikke kan indeholde et fungerende sæt.
• En LLM-foruddannelsespipeline, der læser prætokeniserede shards er ofte lagerbundet på Gen4. Gen5 hjælper. Det samme gælder at placere det aktive shard-sæt på lokal NVMe i stedet for NFS.
• Inferens er i bund og grund aldrig lagerbundet efter modelbelastning. Diskaktivitetsmåleren på en serveringsboks er flad.

Checkpoint-klippen

Et 70B-modelcheckpoint ved FP16 er 140 GB vægte. Tilføj Adam-optimeringstilstand (~8 bytes pr. parameter for FP32 master + første + andet moment): ~560 GB mere. Tilføj gradienter, hvis du tager et snapshot midt i trinnet: ~140 GB mere. Et "komplet" 70B-checkpoint kan nå 800 GB til 1 TB afhængigt af, hvad du gemmer.

Synkront, single-rank-writes-everything-checkpoint til et enkelt Gen5 NVMe ved 13 GB/s vedvarende skrivning: ~75 sekunder for et 1 TB checkpoint. Træningsblokke i hele varigheden. Hvis du gør dette for hver 100 trin, når hvert trin tager 5 sekunder, betyder det, at du lige har gjort træningen 15 % langsommere.

To rettelser, begge essentielle:

1. Sharded checkpointing. Hver FSDP-rang skriver sin egen shard til sin egen lokale NVMe. Med 8 GPU'er og 8 lokale drev er skrivekapaciteten pr. rang 125 GB, og skrivninger paralleliseres. Væguret falder til ~10 sekunder.

2. Asynkron kontrolpunkt. PyTorch DCP (torch.distributed.checkpoint) aflaster skrivningen til en CPU-tråd. GPU'en stopper kortvarigt for GPU→CPU-stagingkopieringen (et par sekunder), derefter genoptages træningen, og den faktiske skrivning til lageret sker i baggrunden.

Kombinationen – async sharded – ændrer checkpoint-lagring fra "skal absorbere 1 TB på sekunder" til "skal holde trit med en steady-state baggrundskopi på et par hundrede MB/s". Næsten alle lagringsniveauer håndterer det. Fejlen, man skal undgå: synkrone, fuld-state-per-rank checkpoints skrevet direkte til NFS. Det var normalt i 2022. Det er malpractice i 2026.

Beton Kentino AI-lagringslayouts

4-GPU inferensserver (f.eks. Kentino AI 192 Genoa, 4× RTX 5090 eller 4× RTX Pro 6000 Blackwell):

Boot + model:    1× 2 TB Gen5 M.2 NVMe (consumer or read-intensive enterprise)
Scratch:         optional, often unnecessary for pure inference
Dataset:         not needed on the box
Checkpoint:      not needed on the box

Total: 2 TB NVMe. Cost: low. Sufficient for any inference workload.

8-GPU træningsserver (f.eks. Kentino AI 256 Turin Dual, 8× RTX 5090 eller 8× RTX Pro 6000):

Boot:            2× 480 GB M.2 NVMe, mdadm RAID1, ext4 → /
Model storage:   2× 4 TB U.2 Gen5 NVMe, mdadm RAID1, ext4 → /models
Scratch:         2× 8 TB U.2 Gen5 NVMe, mdadm RAID0, XFS → /scratch
Checkpoint:      2× 8 TB U.2 Gen5 NVMe, mdadm RAID10, XFS → /checkpoints
Dataset:         NFS mount from external storage server, 100 GbE

Total local NVMe: ~36 TB. Cost: meaningful but matched to GPU spend.

Klyngedelt lagernode (separat fra beregning):

Boot:            2× 960 GB M.2 NVMe, RAID1, ext4
Hot tier:        12× 7.68 TB U.2 Gen5 NVMe, ZFS RAIDZ2 or BeeGFS storage target, XFS
Cold tier:       8× 16 TB SAS HDD, ZFS RAIDZ2 → /archive
Network:         2× 100 GbE, RoCE or NVMe-oF capable

Serves the cluster's dataset tier. See K04 for distributed FS choice.

To ting at bemærke. Inferensserveren har ét drev . Træningsserveren har fire niveauer, men hvert drev er dimensioneret til sin rolle og ikke overspecificeret til at være det største tilgængelige. Klyngelagernoden er en helt separat maskine.

Ærlig vurdering — de fleste kunder overskrider specifikationerne for lagerplads

Et mønster, vi ser ofte nok til at berettige en påpegelse: en kunde bygger en 8-GPU-server "for at være fremtidssikret", specificerer otte 15.36 TB U.2 NVMe-drev, fordi slotsene er der, og kører derefter inferensbelastninger, der berører måske 200 GB modelfiler og lader resten af ​​arrayet stå ubrugt for evigt. €25,000 i NVMe står koldt.

De ærlige størrelsesregler:

• Ren inferens, enkelt server: 2-4 TB NVMe i alt. Én disk. Færdig.
• Inferens plus lejlighedsvis finjustering: 4–8 TB i alt. Opstart + scratch.
• Seriøs træning, enkelt server: 16-40 TB på tværs af boot/model/scratch/checkpoint, med datasættet eksternt på en NAS eller et objektlager.
• Cluster: Datasæt og kontrolpunkt flyttes til delt lagring; lokal NVMe pr. node krymper tilbage til inferensprofilen (2-8 TB) til opstart, model og tilbageskrivning fra bunden.

Lagring er det eneste sted i en AI-build, hvor "mere er altid bedre"-instinktet konsekvent er forkert. GPU'er skalerer fordele nogenlunde lineært med omkostningerne; RAM skalerer rimeligt; lager skalerer ofte slet ikke, når man først har nok.

Hvad går i stykker

De fejltilstande vi ser i felten, i rækkefølge:

• Bootdrevet er forbruger M.2 uden redundans. Drev fejler efter 18 måneder, serveren kan ikke startes, modeller forbliver sikre på RAID, men genopbygningen tager en dag. Rettelse: 2× M.2 i mdadm RAID1, selv på inferensbokse.
• Scratch udfylder midt i løbet. Datasætcache, afkodede shards, midlertidige framework-filer konspirerer. Rettelse: monitor, alarm ved 80% fuld, størrelse 1.5 gange det største forventede arbejdssæt.
• Hardware RAID-kort bag NVMe. Ydeevnen er halvt så høj som den burde være, controlleren er et enkelt fejlpunkt, udskiftning er eksotisk. Rettelse: riv kortet ud, MDadm eller ZFS Direct.
• Synkront checkpoint til NFS, træningen går i stå. Rettelse: asynkron sharded checkpoint, lokal NVMe først, derefter asynkron kopi.
• Gen5 M.2 termisk gasspjæld. Drev med en hastighed på 14 GB/s klarer 4 GB/s efter 3 minutters vedvarende skrivning. Rettelse: køleplade, bedre luftgennemstrømning eller skift til U.2.
• Datasættet på datasætniveauet mætter Gen4. Vision-træningspipelinen er 30% lagerbegrænset. Rettelse: Gen5-versionen er nu installeret, foruddekodet til WebDataset eller begge dele.
• ZFS ARC spiser RAM beregnet til træning. Standard 50% allokering bruger OOMs i træningsprocessen. Rettelse: begrænsning zfs_arc_max til 10-20% af RAM. Se L04.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.