Úložiště pro AI clustery: NFS, BeeGFS, Lustre a otázka object storage

Sdílené úložiště je ta část distribuovaného trénovacího clusteru, kterou nikdo neřeší, dokud se nestane důvodem, proč GPU běží na 40 % využití. V tu chvíli je jeho výměna bolestivá — každý trénovací skript má v sobě zabudované předpoklady, každý checkpoint je ve formátu, který se nemusí přenést čistě, a cluster je v produkci. Správný čas rozhodnout o úložišti je dřív, než do racku přibude druhý trénovací uzel.

Toto je úložná polovina série K. Jde o pohled kupujícího a architekta, ne o návod pro správce systému — cílem je rozhodnout mezi NFS, BeeGFS, Lustre a objektovými úložišti s otevřenýma očima a říct na rovinu, které z nich většina zákazníků Kentino skutečně potřebuje.

Proč je sdílené úložiště tichým úzkým hrdlem

Trenér na jednom uzlu čte dataset z lokálního NVMe a checkpointy zapisuje tamtéž. Není co řešit. Jakmile se přidá druhý uzel, mění se dvě věci:

1. Každý uzel čte stejný dataset. Bajty jsou na každém workeru identické a musí být viditelné ze všech uzlů.
2. Každý uzel zapisuje checkpointy a jejich sjednocení musí přežít. Při shardingu pomocí FSDP nebo DeepSpeed zapisuje každý rank svůj vlastní díl; u DDP zapisují ranky redundantně. Tak či tak souborový systém zaznamená nárazovou vlnu velkých zápisů každých pár minut až hodin.

Tyto přístupové vzory jsou protichůdné. Přístup k datasetu je trvalý, sekvenční, čtecí a tolerantní k latenci. Přístup při checkpointu je nárazový, velkoblokový, zápisový — a trénink na něj čeká. Úložiště, které je dobré v jednom, bývá v tom druhém průměrné.

Navíc moderní ML datasety dělají ještě třetí věc: metadatové bouře. Dataset s 50 miliony JPEGů o velikosti 4–12 KB znamená z pohledu souborového systému 50 milionů cyklů open/stat/read/close. Jako první padne metadatový server, ne datová cesta. Právě proto odpověď „máme dost propustnosti“ nestačí.

NFS — výchozí volba, která vydrží déle, než čekáte

NFS (NFSv3 nebo v4) je cesta nejmenšího odporu. Dodává ho každá linuxová distribuce, rozumí mu každý plánovač a „úložný uzel“ je prostě linuxový stroj se spoustou disků, jedním řádkem v /etc/exports a rychlou síťovkou.

Co vám rozumně postavený NFS server dá:

• Jeden jmenný prostor připojený stejně na každém výpočetním uzlu.
• Slušnou sekvenční propustnost čtení, zvlášť s nconnect na moderních jádrech (multiplexování jednoho mountu přes několik TCP spojení — strop jednoho streamu je už roky minulostí).
• Provozní nudu. Poruchy jsou dobře popsané a postupy obnovy najdete v každé příručce správce.

Co ztrácíte:

• Jeden server, jedno úzké hrdlo. Agregovaná propustnost clusteru je omezená tím, co zvládne obsloužit jediný stroj.
• Zamykání a serializace metadat. Workloady s malými soubory narazí na limity metadat dřív než na limity propustnosti.
• Žádné elegantní škálování do šířky. Když je stroj plný, postavíte druhý s jiným přípojným bodem a vaše skripty se o něm musí dozvědět.

Nevalná pověst, kterou NFS v HPC kruzích má, stojí hlavně na starém stropu jednoho spojení a na bolesti s metadaty drobných souborů. Pro trénovací datasety v rozsahu 100 GB až 1–2 TB na 4–8 GPU uzlech je pořádně postavený NFS server skutečně v pořádku. Viděli jsme zákazníky, kteří bez jediné stížnosti trénovali fine-tuny Qwen2.5-VL nad datasety na NFS.

NFS začíná bolet, když:

• Datasety přesáhnou ~2 TB a míchání způsobuje zahlcení cache na serveru.
• Na stejný mount sáhne pod zátěží více než ~8–12 výpočetních uzlů.
• Workloadu dominují desítky milionů malých souborů.
• Velikost checkpointu na rank přesáhne 50–100 GB zapisovaných souběžně.

Pod všemi čtyřmi prahy je NFS téměř jistě správná odpověď a paralelní souborový systém je zbytečné přepálení.

BeeGFS — praktický střed

BeeGFS je paralelní souborový systém, který lidé reálně nasazují, když NFS přestane stačit. Data rozděluje mezi více úložných cílů (disky na více serverech) a metadatových cílů (samostatné NVMe servery). Klienti vidí jeden jmenný prostor; čtení i zápisy se paralelně prokládají přes úložné cíle.

Proč se objevuje ve středně velkých clusterech:

• Nasazení trvá dny, ne týdny. Schopný linuxový inženýr postaví instalaci se dvěma úložnými uzly a jedním MDS během odpoledne. Lustre v této lize nehraje.
• Agregovaná propustnost roste lineárně s počtem úložných cílů. Tři uzly na 100 GbE doručí téměř 3× vyšší propustnost čtení než jeden.
• Nativní RDMA na InfiniBandu nebo RoCE — eliminuje režii TCP/IP.
• Open source, žádná past licencování za TB. Komerční podpora od ThinkParQ je volitelná.

V čem je upřímně slabší:

• Metadata u workloadů s obrovským množstvím malých souborů. Při převaze souborů pod 4 KB se jediný MDS stává úzkým hrdlem. Metadatové cíle lze přidat, ale architektura není tak agresivní jako DNE v Lustre.
• Žádný vestavěný tiering. Horká a studená data si řídíte sami.
• HA je přilepené, ne nativní. Zrcadlení funguje, ale není tak transparentní jako failover v Lustre.

Ideální nasazení: 4–32 trénovacích uzlů, 10–100 TB datasetu, soubory v rozsahu 1 MB až 1 GB. Přesně tam končí většina vícouzlových sestav Kentino.

Základní nasazení BeeGFS pro čtyřuzlový cluster třídy Kentino:

Trvalé agregované čtení do čtyř trenérů se obvykle pohybuje v rozmezí 30–60 GB/s, což stačí nasytit 32 GPU u většiny trénování v počítačovém vidění i u LLM. Škálování se zastaví, jakmile se nasytí metadatový server — pak přidejte druhý metadatový cíl, nebo začněte uvažovat o Lustre.

Lustre — zlatý standard, reálná složitost

Lustre pohání úložnou vrstvu prakticky každého superpočítače z top 500, který potřebuje POSIX, a škáluje do stovek petabajtů a agregované propustnosti v řádu TB/s. Architektura má tři role: MGS/MDS (správa + metadata), OSS (object storage servery držící OST) a klienty. Klienti se na MDS ptají na operace se jmenným prostorem a pak komunikují přímo s tím OSS, který drží data — datová cesta se metadatovému serveru zcela vyhýbá. Právě proto Lustre škáluje, a DNE (Distributed Namespace) umožňuje škálovat horizontálně i metadata.

Cenou je provoz: strmější křivka učení než u BeeGFS, přísné požadavky na jádro a ovladače, desítky ladicích parametrů (výkon „z krabice“ obvykle není to, co hardware umí doručit) a postupy obnovy, které vyžadují schopného úložného inženýra.

Práh, kdy dává Lustre smysl, leží zhruba u 16–32+ trénovacích uzlů nebo u datasetů v řádu PB. Pod ním nasytí BeeGFS síť dávno předtím, než se architektonické výhody Lustre projeví. Portfolio Kentino na tento práh většinou nedosáhne — Lustre cluster postavíme, pokud si o něj řeknete, ale nejdřív vám řekneme, že BeeGFS a pořádný MDS vás dovezou na 80 % cesty za 20 % provozní bolesti.

Objektové úložiště — MinIO a Ceph pro ML data lakes

Paralelní souborové systémy výše jsou správná volba, když framework očekává soubory. Rostoucí část moderních ML pipeline je ale neočekává — datasety žijí jako S3 objekty, data loader si je tahá přes HTTP a lokální souborový systém je jen dočasný scratch.

MinIO je jednoúčelové objektové úložiště kompatibilní s S3. Distribuovaný režim běží na 4–32+ uzlech s erasure codingem. Open source, provozně jednodušší než kterýkoli paralelní souborový systém, a moderní data loadery (PyTorch s fsspec/s3fs, WebDataset, NVIDIA DALI) z něj čtou přímo.

Ceph je širší — blok (RBD), soubory (CephFS) i objekty (RGW) nad stejnou vrstvou RADOS. Ceph vyhrává tam, kde chcete jedno úložiště pro více workloadů (VM, sdílené disky, ML objekty). Prohrává v provozní jednoduchosti — Ceph je systém, ke kterému se zavážete, s vlastním monitoringem, laděním a pohotovostní disciplínou.

Co objektové úložiště pro ML přináší: levnou kapacitu (husté HDD uzly s erasure codingem dávají €/TB, na které flash nedosáhne), provozně jednoduché škálování do šířky, sharding už v návrhu (žádné metadatové úzké hrdlo) a dobrou shodu s data loadery pracujícími se shardy. Co ztrácíte: latenci operací v desítkách ms (ne v mikrosekundách), přímý POSIX (buď přepíšete loader, nebo přijmete penalizaci přes FUSE) a zápis na místě (objekty jsou neměnné — pro checkpointy v pořádku, pro cokoli, co se mění, špatně).

Architektura, která v praxi funguje: objektové úložiště jako trvalý, velký a levný data lake; paralelní nebo NFS souborový systém jako rychlá pracovní sada připravená pro aktuální běh. Dataset žije v MinIO. Úloha si na začátku připraví relevantní shardy na BeeGFS nebo na lokální NVMe scratch. Finální checkpointy se k archivaci vracejí do MinIO.

WekaIO a VAST — enterprise třída (krátce)

WekaIO a VAST Data jsou účelově stavěná odpověď za enterprise ceny: extrémní metadatový výkon u malých souborů, velmi vysoká agregovaná propustnost, nativní S3 i POSIX, integrovaný tiering, cesty GPU-direct. Dávají vynikající smysl pro clustery se 100+ GPU, kde musí úložiště držet krok s investicí do GPU. Nejsou správnou volbou pro server se 4 nebo 8 GPU ani pro cluster ze čtyř takových — cena úložiště by sestavě dominovala. Zmiňujeme je kvůli poctivosti vůči horní hranici trhu, ne jako doporučení pro kupujícího, pro kterého je tato série psaná.

Vzory přístupu k datasetu a proč na nich záleží

V trénování ML dominují dva vzory. Vzor A — velké shardy: datasety předem zabalené do tarballů WebDataset, do parquetu nebo LMDB, 100 MB až 10 GB na shard, čtené sekvenčně a míchané uvnitř. V tomhle je dobrý každý úložný systém. Vzor B — mnoho malých souborů: miliony JPEGů/PNG/JSONů, jeden na vzorek, bušící do metadatové cesty. Tohle trestá NFS, ve větším měřítku ubližuje BeeGFS a právě kvůli tomu existují Weka a VAST.

Jediné rozhodnutí s největší pákou v oblasti trénovacího úložiště je převést vzor B na vzor A. Pokud je váš dataset z malých souborů, před tréninkem ho přebalte do shardů. Cenou je jeden předzpracovací průchod; přínosem je, že jakýkoli úložný systém začne stačit. Viděli jsme pipeline, které zrychlily 3–5× bez jediné změny úložného hardwaru, jen přebalením.

Pokud přebalit nemůžete — dataset se neustále mění, framework skutečně vyžaduje soubor na vzorek — dimenzujte úložiště podle metadatových IOPS, ne podle propustnosti. To vás posouvá k BeeGFS s více MDS cíli, k Weka/VAST nebo k Lustre s DNE.

Strategie checkpointů — zapisovat rychle, zapisovat později, zapisovat méně

Zápisy checkpointů jsou nejhorší možný vzor: všechny ranky zapisují současně, zápisy jsou velké a trénink čeká, dokud nejsou data trvale uložena. Naivní synchronní checkpoint u modelu se 100 B parametry dokáže trénink zastavit na desítky minut.

Dnešní best practice je třífázový postup, nativně podporovaný v torch.distributed.checkpoint (DCP) v PyTorchi, v NVIDIA NeMo i ve většině moderních frameworků:

1. Každý rank zapíše svůj shard na lokální NVMe scratch. Celková propustnost zápisu clusteru je součtem rychlostí NVMe v jednotlivých uzlech (5–50 GB/s na uzel). Trénink se odblokuje během několika sekund.
2. Asynchronní proces na pozadí kopíruje data na sdílené úložiště. Trénink už mezitím běží dál.
3. Starší checkpointy se mažou nebo přesouvají na objektové úložiště podle rozvrhu. Poslední 2–3 nechte na rychlém úložišti, zbytek jde do MinIO/Cephu.

Důsledek: sdílené úložiště nemusí absorbovat každý checkpoint plnou rychlostí. Musí jen stihnout pojmout asynchronní kopii, aniž by zaostávalo za kadencí. U modelu se 70 B parametry a checkpointem každých 30 minut stačí trvalý zápis v řádu jednotek GB/s — což bez problémů zvládne schopný BeeGFS i dobrý NFS server.

Čemu se vyhnout: synchronním, neshardovaným checkpointům zapisovaným přímo na NFS. V roce 2022 to bylo normální. Dnes už není. Pokud to vaše pipeline dělá, oprava kódu checkpointů má větší páku než upgrade úložiště.

Otázka clusterového uplinku

Sdílí provoz úložiště síť s tréninkem, nebo dostane vlastní?

Sdílená síť je v pořádku pro clustery se 4–8 uzly s asynchronními checkpointy; oddělená se vyplatí nad 8 uzlů nebo při silném synchronním I/O.

Pro clustery třídy Kentino se 4–8 uzly je sdílená síť v pořádku, pokud se používají asynchronní checkpointy a úložný workload je převážně čtecí — trvalé čtení koexistuje s kolektivními operacemi NCCL bez vážné újmy. Oddělená síť se vyplatí u velkého trénování LLM s FSDP při vysokém stupni TP/PP, při silném synchronním provozu k úložišti, nebo když rozpočet dovolí rezervu. Praktický výchozí stav: sdílená 100GbE do 8 uzlů a úložná VLAN jako měkká izolace.

Poctivá doporučení podle měřítka

Většina zákazníků Kentino spadá do druhého a třetího řádku. Zbytek postavíme, pokud si řeknete, ale upozorníme vás, když jde o přepálení.

Co se láme

Režimy selhání, které jsme viděli, seřazené podle toho, jak často koušou:

• Vyhladovění metadat při zátěži malými soubory. Příznak: GPU na 30–50 %, síť nečinná, CPU úložiště nečinné, každé open() pomalé. Řešení: přebalit do shardů, nebo přidat MDS cíle.
• Synchronní checkpointy zastavující trénink. Řešení: asynchronní shardované checkpointy (PyTorch DCP nebo NeMo).
• Jeden pomalý disk sráží celý cluster. Selhávající SSD neselže čistě — jen zpomalí. Řešení: sledujte latenci po zařízeních a alarmujte při > 2× základní hodnoty.
• Zahlcení page cache na úložném uzlu. Dataset se nevejde do RAM a každá epocha vytlačí tu předchozí. Řešení: více RAM.
• nconnect není na NFS klientech zapnutý. Výchozí NFS s jedním streamem končí hluboko pod linkovou rychlostí síťovky. nconnect=8 nebo =16 dá na stejném hardwaru 4–8× vyšší propustnost.
• MinIO ve větším měřítku bez ladění EC. Výchozí nastavení upřednostňuje trvanlivost před latencí; latence malých objektů tím trpí. Nepřijímejte výchozí hodnoty slepě.

Nic z toho není exotické. Všechno je předvídatelné, jakmile to jednou uvidíte.

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.