Vrstvy úložiště v AI serveru: model, dataset, scratch, checkpoint

S kupujícími vedeme pořád dokola jeden a tentýž rozhovor o NVMe. Chtějí „co nejrychlejší disk“, protože v katalogových listech vidí u Gen5 disku 14 GB/s a 4090 vedle Samsungu 9100 PRO zní jako vyvážená dvojice. Pak se zeptáme, k čemu ten stroj bude, odpověď zní „hlavně inference“ — a správná sestava má nakonec jeden disk místo osmi. Úložiště je v konfiguraci AI serveru tou částí, kde se předimenzovává nejsnáze, prodejce to nic nestojí a workload to prakticky vůbec nepozná.

Tento článek popisuje čtyři skutečné vrstvy úložiště v jednom AI serveru, co každá z nich reálně musí zvládnout, jak vypadá trh s NVMe v roce 2026, kdy se Gen5 vyplatí zaplatit, proč hardwarový RAID u NVMe přestal dávat smysl a jak každou vrstvu nadimenzovat bez vyhazování peněz. Volba souborového systému je samostatné téma, kterému se věnuje L04; úložiště sdílené v rámci clusteru (NFS, BeeGFS, Lustre, objektová úložiště) řeší K04. My zůstaneme uvnitř skříně.

Čtyři vrstvy úložiště

Pořádný AI server má čtyři odlišné role úložiště. Liší se velikostí, propustností, výdrží i cenou, a to zásadně. Házet je do jednoho pytle je první chyba.

Inferenční server se 4 GPU obvykle potřebuje jen první vrstvu a možná kousek druhé. Trénovací stroj s 8 GPU potřebuje všechny čtyři — a každá z nich chce jiný disk. Otázka „kolik TB NVMe?“ nedává bez určení vrstvy žádný smysl.

Úložiště modelů

Vrstva modelů drží Vaši knihovnu vah — každou variantu Llamy, Qwenu, Mistralu, Stable Diffusion, Fluxu či Whisperu, kterou kdy budete chtít načíst. Žije tu také OS, image kontejnerů, prostředí conda a binárky inferenčního serveru. U většiny sestav to všechno splyne se systémovým diskem.

Dimenzování se odvíjí od toho, kolik modelů držíte nahraných. Několik příkladů v běžných kvantizacích:

• Llama 3 70B Q4: ~40 GB
• Llama 3 70B FP8: ~70 GB
• Qwen2.5-VL 72B Q4: ~45 GB plus pár GB na vision tower
• Mistral Large 2 (123B) Q4: ~70 GB
• Llama 4 Maverick MoE FP8: ~250 GB
• Skromná knihovna VLM (8 modelů, různé kvantizace): 300–500 GB
• Výzkumná laboratoř držící 30 modelů připravených: 2–4 TB

Převažuje čtení. Model se jednou při startu procesu načte a zbytek dne žije ve VRAM. Disk odbaví 40GB sekvenční čtení při startu vLLM a pak většinu času zahálí. Jediné 2–4TB NVMe Gen4 — klidně i spotřebitelské jako Samsung 990 PRO — to zvládne levou zadní. Plaťte za kapacitu, ne za propustnost.

Úložiště datasetů

Ve vrstvě datasetů leží trénovací korpusy a materiál pro doučování. Právě tuhle vrstvu zákazníci chronicky poddimenzovávají, protože dataset, se kterým pracují dnes, se tam vejde — a zapomínají, že ten další už ne.

Reálná rozpětí:

• Korpus pro LoRA doučování v jedné doméně: 10–100 GB
• Multimodální sada pro doučování (obrázky + text): 1–10 TB
• Textový korpus v předtrénovacím měřítku (výřez z FineWeb apod.): 5–50 TB
• Sada pro předtrénink videa nebo robotické demonstrace: 20–200 TB
• Genomický, vědecký nebo scrapovaný webový archiv: 100 TB – 1 PB+

Přístupový vzor je sekvenční čtení, opakované napříč epochami a paralelně mnoha workery DataLoaderu. Citlivé na propustnost (protože GPU čeká), tolerantní k latenci. Jakmile jsou data nahraná, zápis je prakticky nulový.

U datasetů nad zhruba 10 TB správná odpověď obvykle vede ven ze skříně — viz K04 pro NFS, BeeGFS a objektová úložiště. Uvnitř skříně dává smysl datasetová vrstva z HDD v RAIDZ2 (levné, velké, pomalé, ale po zahřátí page cache dostačující) nebo RAID ze středně drahých U.2 NVMe, zhruba do 50 TB.

Scratch

Scratch je nedoceněný hrdina. Pohltí všechno, co se jinam pořádně nevejde: dekódované obrazové shardy, mezivýsledky aktivací odkládané ZeRO-Offloadem, cache datasetů vytvořené knihovnami webdataset/DALI, dočasné promíchané datasety, artefakty z buildu kontejnerů i výpis spadlého běhu. Zároveň hodně čte i hodně zapisuje.

Dimenzování: ideální je 2–8 TB. Pod 2 TB ho zaplní jediné doučování. Nad 8 TB už většinou stavíte malou datasetovou vrstvu a říkáte jí scratch — což je v pořádku, jen si to přiznejte.

Tady na výdrži záleží způsobem, jakým u ostatních vrstev nezáleží. Scratch žere zápisy — 5–20 TB zapsaných denně není na vytíženém trénovacím stroji nic neobvyklého. Podnikový disk s 1 DWPD a kapacitou 4 TB umožní 4 TB zápisu denně po dobu pěti let; pořádný trénovací scratch chce 1–3 DWPD, tedy třídu mixed-use.

Checkpoint

Ve vrstvě checkpointů přistává stav tréninku. Nárazově: deset minut ticho, pak 50–500 GB zapsaných během pár sekund, a zase ticho.

Checkpoint modelu 70B v FP16 představuje ~140 GB vah. S FSDP přidají gradienty a stav optimizéru dalších 400–700 GB na jeden checkpoint. S DeepSpeed ZeRO-3 a plným stavem optimizéru (Adam: 8 bajtů na parametr pro master FP32 a první i druhý moment) se checkpoint modelu 70B může přiblížit 1 TB.

Trvalá rychlost zápisu jediného NVMe Gen5 je ~10–13 GB/s. Checkpoint o velikosti 700 GB se tedy zapíše zhruba za minutu, optimisticky — pokud každý rank streamuje na vlastní disk. Synchronně se trénink na celou tu minutu zastaví. Řešením je asynchronní shardovaný checkpointing (viz níže).

NVMe Gen4 vs Gen5 — kdy se příplatek vyplatí

Trh s NVMe se v roce 2026 dělí mezi vyzrálé Gen4 (5–7 GB/s) a dnes už mainstreamové Gen5 (12–14 GB/s). Na špičce spotřebitelské nabídky sedí Samsung 9100 PRO s 14.8 GB/s sekvenčního čtení a 13.4 GB/s sekvenčního zápisu. Podniková Gen5 je na tom podobně — Solidigm D7-PS1010 s 14.5 GB/s čtení, Micron 9550 MAX se 14 GB/s čtení, Kioxia CD8, SanDisk DC SN861 — všechny zvládají 13–14 GB/s čtení a 8–10 GB/s trvalého zápisu.

Cenový příplatek za Gen5 oproti Gen4 srovnatelné kapacity je v polovině roku 2026 30–50 % u spotřebitelských disků a 20–35 % u podnikových.

Kdy se Gen5 skutečně vrátí:

• Načítání modelu za studena. MoE model o 250 GB se na Gen5 načte za 18 sekund oproti 36 sekundám na Gen4. Má to smysl, pokud modely často střídáte.
• Trénink omezený I/O. Vision pipeliny dekódující surové JPEGy z disku, multimodální datasety, kde je úzkým hrdlem předzpracování.
• Checkpoint na lokální NVMe před asynchronní kopií. Čím rychlejší lokální zápis, tím dřív trénink pokračuje.
• Úložný server obsluhující 8 a více trénovacích nodů. Souhrnná poptávka klientů překročí strop Gen4.

Kdy Gen4 bohatě stačí a Gen5 jsou vyhozené peníze:

• Inferenční servery. Model se načte jednou při startu a zbytek dne je disk na jednotkách MB/s.
• Kořen OS a úložiště kontejnerů. Start jednou za měsíc, občasná instalace balíčků.
• Datasetová vrstva s předem dekódovanými a velkými shardy. PyTorch DataLoader s 8 workery čtoucí shardy WebDatasetu se zastaví někde na 4–6 GB/s v součtu; Gen4 to pokryje.

Upřímná verze: zhruba 70 % zákaznických sestav, které dodáváme, slouží čistě k inferenci, a pro ty je Gen4 NVMe napříč celou sestavou správná volba. Gen5 je rozhodnutí pro trénovací vrstvu.

Formáty — M.2, U.2/U.3, E3.S

M.2 Gen5 bude podtaktovat. Samsung 9100 PRO 2 TB při trvalých 13 GB/s v horké skříni dosáhne 75 °C a stáhne výkon. Modely s chladičem pomáhají. M.2 je v pořádku pro systémový disk a nenáročné workloady; pro scratch vrstvu s trvalým zápisem to správný formát není.

U.2 je tahoun. Každé podnikové NVMe, které Kentino dodává ve skříni Bone64c nebo Supermicro, je U.2 a je prakticky vždy zaměnitelné s U.3 backplanem. Tepelný strop 25 W, dvojportové zapojení pro multipath, výměna za provozu, kapacity 7.68 TB a 15.36 TB na ideálním poměru ceny a hustoty.

E3.S je budoucnost, ale pomalu. Navrženo od základu pro teploty Gen5/Gen6. Pro jednotlivý server nebo menší cluster od Kentina zůstává do konce roku 2026 praktickou volbou U.2/U.3; E3.S vstupuje do hry při obměnách v roce 2027.

Vyhněte se skládání M.2 nosičů do horké skříně. PCIe karty, které za přepínacím čipem drží čtyři M.2 disky, fungují, jenže ve 4U serveru s osmi GPU je proudění vzduchu kolem těchto nosičů špatné. Tepelné podtaktování vidíme do deseti minut trvalé zátěže. Potřebujete-li v serveru čtyři NVMe, použijte U.2.

Výdrž — DWPD jako nákupní vodítko

U AI serveru je přiřazení přímočaré:

• Vrstva modelů: read-intensive, 0.3–1 DWPD.
• Vrstva datasetů: read-intensive, 0.3–1 DWPD.
• Vrstva scratch: mixed-use, 1–3 DWPD. Právě tahle vrstva si rozpočet na výdrž zaslouží.
• Vrstva checkpointů: mixed-use, 1–3 DWPD. Nárazové zápisy se sčítají; 1 DWPD na 4TB disku dovolí jen 4 TB denně, což intenzivní trénovací tempo překročí.

Write-intensive (3+ DWPD) je pro téměř každý AI workload zbytečný luxus. Špatně zvolenou třídu výdrže lze napravit výměnou disku; špatně zvolenou třídu propustnosti často ne. Propustnost si pohlídejte už při stavbě, výdrž berte jako něco, co jde dodatečně upgradovat.

RAID pro NVMe — hardware je mrtvý, odpovědí je software

Tohle si zaslouží vlastní podkapitolu, protože se zákazníci stále ptají. Krátká verze: pokud má Vaše sestava v roce 2026 před NVMe disky hardwarový RAID řadič, je špatně nakonfigurovaná.

Hardwarové RAID řadiče (LSI/Broadcom MegaRAID, Microchip SmartRAID, HPE Smart Array, Dell PERC) byly navrženy pro SAS/SATA. Vlastní ASIC řadiče obstarává paritu, cachování a řazení příkazů a při šířce pásma SAS (12 Gbit/s = 1.5 GB/s) má spoustu rezervy.

NVMe Gen5 se 14 GB/s na disk ovšem zahltí jednokartový RAID řadič už po dvou discích. Osm disků za hardwarovou RAID kartou vyprodukuje víc dat, než kolik dokáže přenést její PCIe uplink. Řadič se stane úzkým hrdlem a vzápětí i bodem selhání.

Praktické odpovědi jsou softwarové:

• mdadm (softwarový RAID v Linuxu). Vyzrálý, přímo v jádře, dobře zvládá RAID0/1/10. RAID5/6 na NVMe funguje, ale výpočet parity žere CPU. Pro 4 NVMe v zrcadle nebo stripe: ideální.
• ZFS RAIDZ2. Lepší přístup k integritě (kontrolní součty od konce ke konci), lepší nástroje pro scrub a výměnu disků, snapshoty a klony. Náročnější na CPU než mdadm. Správná volba pro archivní a datasetové vrstvy, kde je integrita dat důležitější než maximální propustnost.
• Replikace po discích / erasure coding na úrovni aplikace. U opravdu velkých polí přesouvají MinIO/Ceph EC nebo stripování BeeGFS rozhodnutí o redundanci zcela mimo blokovou vrstvu.

Pro většinu sestav Kentino:

• Systémový disk: 2× M.2 NVMe v mdadm RAID1.
• Scratch: RAID0 přes 2–4 NVMe (data jde znovu vygenerovat).
• Dataset/checkpoint: RAID10 v mdadm nebo RAIDZ2 v ZFS.

Hardwarový RAID má v AI serveru přesně jedno zbývající opodstatnění: malé zrcadlo systémového disku za jednoduchou kartou Broadcom/MegaRAID na serveru, kde opravdu chcete bootovatelnou redundanci ještě před startem OS. I tam ale mdadm RAID1 s EFI na obou discích funguje bez problémů.

Síťové úložiště pro datasetovou vrstvu

Shrnuto: nad 10 TB patří datasetová vrstva téměř vždy mimo AI server. Uvnitř skříně chcete rychlý scratch, rychlý checkpoint a úložiště modelů; dataset může být vzdálený.

Jak PyTorch ve skutečnosti načítá data

Užitečným vodítkem pro dimenzování úložiště je sledovat, co dělá DataLoader v PyTorchi. S parametry num_workers=8 a pin_memory=True:

1. Osm worker procesů paralelně otevírá soubory datasetu.
2. Každý worker čte, dekóduje (JPEG, snímky videa, převzorkování zvuku) a převádí vzorek na tenzor.
3. Dekódovaný tenzor se uloží do sdílené paměti.
4. Hlavní proces si ho vybere ze sdílené fronty, připne do hostitelské RAM a přes DMA zkopíruje do GPU.

Praktické důsledky:

• Vision pipeline je úložištěm omezená jen zřídka — pokud ovšem dataset není tak velký, že se pracovní sada nevejde do page cache.
• Předtrénovací pipeline LLM čtoucí předem tokenizované shardy bývá na Gen4 úložištěm omezená často. Gen5 pomůže. Stejně tak pomůže dát aktivní sadu shardů na lokální NVMe místo na NFS.
• Inference není úložištěm omezená prakticky nikdy — po načtení modelu. Ukazatel aktivity disku na obslužném stroji je plochý.

Útes jménem checkpoint

Checkpoint modelu 70B v FP16 má 140 GB vah. Přidejte stav optimizéru Adam (~8 bajtů na parametr pro FP32 master plus první a druhý moment): dalších ~560 GB. Přidejte gradienty, pokud snapshotujete uprostřed kroku: dalších ~140 GB. „Kompletní“ checkpoint modelu 70B se tak může vyšplhat na 800 GB až 1 TB podle toho, co všechno ukládáte.

Synchronní checkpoint, kdy jeden rank zapisuje všechno na jediné NVMe Gen5 s trvalým zápisem 13 GB/s: ~75 sekund na 1TB checkpoint. Trénink po celou tu dobu stojí. Dělat to každých 100 kroků, když jeden krok trvá 5 sekund, znamená zpomalit celý běh o 15 %.

Dvě opravy, obě zásadní:

1. Shardovaný checkpointing. Každý FSDP rank zapisuje vlastní shard na vlastní lokální NVMe. S 8 GPU a 8 lokálními disky je zápis na rank 125 GB a zápisy běží paralelně. Reálný čas klesne na ~10 sekund.

2. Asynchronní checkpointing. PyTorch DCP (torch.distributed.checkpoint) přesouvá zápis do vlákna na CPU. GPU se krátce zastaví kvůli kopii z GPU do CPU (pár sekund), pak trénink pokračuje a samotný zápis na úložiště probíhá na pozadí.

Kombinace — asynchronní a shardovaný — promění úložiště pro checkpointy z „musí pohltit 1 TB během sekund“ na „musí stíhat vyrovnanou kopii na pozadí o pár stovkách MB/s“. To zvládne skoro jakákoli vrstva úložiště. Čemu se vyhnout: synchronním checkpointům s plným stavem na každý rank zapisovaným rovnou na NFS. V roce 2022 to byla běžná praxe. V roce 2026 je to chyba.

Konkrétní rozvržení úložiště pro AI servery Kentino

Inferenční server se 4 GPU (např. Kentino AI 192 Genoa, 4× RTX 5090 nebo 4× RTX Pro 6000 Blackwell):

Systém + modely:  1× 2 TB Gen5 M.2 NVMe (spotřebitelské nebo podnikové read-intensive)
Scratch:          volitelně, u čisté inference často zbytečný
Dataset:          na stroji není potřeba
Checkpoint:       na stroji není potřeba

Celkem: 2 TB NVMe. Náklady: nízké. Dostačuje pro jakýkoli inferenční workload.

Trénovací server s 8 GPU (např. Kentino AI 256 Turin Dual, 8× RTX 5090 nebo 8× RTX Pro 6000):

Systém:          2× 480 GB M.2 NVMe, mdadm RAID1, ext4 → /
Úložiště modelů: 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 z externího úložného serveru, 100 GbE

Celkem lokální NVMe: ~36 TB. Náklady: citelné, ale úměrné investici do GPU.

Sdílený úložný node clusteru (oddělený od výpočtu):

Systém:          2× 960 GB M.2 NVMe, RAID1, ext4
Horká vrstva:    12× 7.68 TB U.2 Gen5 NVMe, ZFS RAIDZ2 nebo úložný cíl BeeGFS, XFS
Studená vrstva:  8× 16 TB SAS HDD, ZFS RAIDZ2 → /archive
Síť:             2× 100 GbE, s podporou RoCE nebo NVMe-oF

Obsluhuje datasetovou vrstvu celého clusteru. Volbu distribuovaného FS řeší K04.

Všimněte si dvou věcí. Inferenční server má jediný disk. Trénovací server má čtyři vrstvy, ale každý disk je dimenzovaný na svou roli, ne nafouknutý na největší dostupnou kapacitu. A sdílený úložný node je samostatný stroj.

Upřímně — většina zákazníků úložiště předimenzuje

Vzorec, který vídáme tak často, že si zaslouží zmínku: zákazník staví server s 8 GPU „aby byl připravený do budoucna“, osadí osm 15.36TB U.2 NVMe disků, protože ty pozice tam prostě jsou, a pak na něm provozuje inferenční workloady, které sáhnou možná na 200 GB souborů s modely a zbytek pole nechají navždy ladem. 25 000 € v NVMe, které leží ladem.

Upřímná pravidla pro dimenzování:

• Čistá inference, jeden server: 2–4 TB NVMe celkem. Jeden disk. Hotovo.
• Inference plus občasné doučování: 4–8 TB celkem. Systémový disk + scratch.
• Vážně míněný trénink, jeden server: 16–40 TB rozdělených mezi systém, modely, scratch a checkpointy, s datasetem externě na NAS nebo v objektovém úložišti.
• Cluster: dataset a checkpointy se stěhují na sdílené úložiště; lokální NVMe v každém nodu se vrací na inferenční profil (2–8 TB) pro systém, modely a zpětný zápis do scratche.

Úložiště je jediné místo v AI sestavě, kde je instinkt „čím víc, tím líp“ soustavně špatně. U GPU roste přínos s cenou zhruba lineárně, u RAM rozumně, u úložiště často nepřibývá vůbec nic, jakmile ho máte dost.

Co se láme

Poruchy, které vídáme v praxi, seřazené podle četnosti:

• Systémový disk je spotřebitelské M.2 bez redundance. Po osmnácti měsících disk odejde, server nenabootuje, modely jsou v bezpečí na RAIDu, ale obnova zabere den. Řešení: 2× M.2 v mdadm RAID1, i na inferenčních strojích.
• Scratch se zaplní uprostřed běhu. Cache datasetu, dekódované shardy a dočasné soubory frameworku se spiknou. Řešení: monitorovat, hlásit při 80 % zaplnění a dimenzovat na 1.5násobek největší očekávané pracovní sady.
• Hardwarová RAID karta před NVMe. Výkon je poloviční oproti očekávání, řadič je jediným bodem selhání a náhrada je exotická. Řešení: kartu vyhodit a jet přes mdadm nebo ZFS napřímo.
• Synchronní checkpoint na NFS a zaseknutý trénink. Řešení: asynchronní shardovaný checkpoint nejdřív na lokální NVMe, pak asynchronní kopie.
• Tepelné podtaktování Gen5 M.2. Disk se štítkovými 14 GB/s dává po 3 minutách trvalého zápisu 4 GB/s. Řešení: chladič, lepší proudění vzduchu, nebo přechod na U.2.
• Dataset na datasetové vrstvě vytěžuje Gen4 naplno. Trénovací vision pipeline je z 30 % omezená úložištěm. Řešení: scratch na Gen5, předem dekódovat do WebDatasetu, nebo obojí.
• ZFS ARC ukousne RAM určenou pro trénink. Výchozí alokace 50 % pošle trénovací proces do OOM. Řešení: omezit zfs_arc_max na 10–20 % RAM. Viz L04.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.