Storage für KI-Cluster: NFS, BeeGFS, Lustre und die Frage nach dem Object Store

Gemeinsamer Speicher ist der Teil eines verteilten Trainingsclusters, an den niemand denkt – bis er der Grund dafür ist, dass die GPUs bei 40% Auslastung dümpeln. Ihn dann noch auszutauschen, ist schmerzhaft: In jedem Trainingsskript stecken Annahmen, jeder Checkpoint liegt in einem Format, das sauber migriert oder eben nicht, und der Cluster ist im Produktivbetrieb. Der richtige Zeitpunkt für die Speicherentscheidung liegt vor dem Einbau des zweiten Trainingsknotens.

Dies ist die Speicherhälfte der K-Serie. Es ist die Sicht von Einkauf und Architektur, keine Anleitung für Systemadministratoren – das Ziel ist, die Entscheidung zwischen NFS, BeeGFS, Lustre und Objektspeichern mit offenen Augen zu treffen und ehrlich zu benennen, was die meisten Kentino-Kunden wirklich brauchen.

Warum gemeinsamer Speicher der stille Engpass ist

Ein Trainingssystem mit einem Knoten liest seinen Datensatz von lokalem NVMe und schreibt die Checkpoints an dieselbe Stelle. Nichts zu diskutieren. Sobald ein zweiter Knoten dazukommt, ändern sich zwei Dinge:

1. Jeder Knoten liest denselben Datensatz. Die Bytes sind auf jedem Worker identisch und müssen von jedem Knoten aus sichtbar sein.
2. Jeder Knoten schreibt Checkpoints, und die Gesamtheit muss erhalten bleiben. Beim Sharding mit FSDP oder DeepSpeed schreibt jeder Rank seinen eigenen Anteil; bei DDP schreiben die Ranks redundant. So oder so sieht das Dateisystem alle paar Minuten bis Stunden einen Schwall großer Schreibvorgänge.

Diese Zugriffsmuster sind gegensätzlich. Der Datensatzzugriff ist dauerhaft, sequenziell, leselastig und latenztolerant. Der Checkpoint-Zugriff kommt stoßweise, in großen Blöcken, ist schreiblastig, und das Training blockiert darauf. Ein Speichersystem, das eines gut kann, ist beim anderen oft nur mittelmäßig.

Hinzu kommt ein drittes Verhalten moderner ML-Datensätze: Metadaten-Stürme. Ein Datensatz aus 50 Millionen JPEGs von 4–12 KB bedeutet aus Sicht des Dateisystems 50 Millionen open/stat/read/close-Zyklen. Zuerst geht der Metadatenserver in die Knie, nicht der Datenpfad. Deshalb ist „wir haben reichlich Bandbreite“ keine ausreichende Antwort.

NFS – der Standard, und er trägt länger, als Sie denken

NFS (NFSv3 oder v4) ist der Weg des geringsten Widerstands. Jede Linux-Distribution bringt es mit, jeder Scheduler versteht es, und ein „Storage-Knoten“ ist schlicht eine Linux-Maschine mit viel Platte, einer Zeile in /etc/exports und einer schnellen NIC.

Was Ihnen ein vernünftig gebauter NFS-Server bietet:

• Ein Namensraum, auf jedem Compute-Knoten identisch eingebunden.
• Ordentlicher sequenzieller Lesedurchsatz, besonders mit nconnect auf modernen Kerneln (ein Mount wird über mehrere TCP-Verbindungen gemultiplext – die Grenze des einzelnen Streams ist seit Jahren Geschichte).
• Betrieblich langweilig. Ausfälle sind gut verstanden, Wiederherstellungsverfahren stehen in jedem jemals geschriebenen Admin-Handbuch.

Worauf Sie verzichten:

• Ein Server, ein Engpass. Der Gesamtdurchsatz des Clusters ist auf das begrenzt, was diese eine Maschine liefert.
• Locking und Serialisierung der Metadaten. Workloads mit kleinen Dateien stoßen an Metadatengrenzen, bevor sie an Bandbreitengrenzen stoßen.
• Kein eleganter Scale-out. Ist die Maschine voll, bauen Sie eine zweite mit einem anderen Mount-Punkt – und Ihre Skripte müssen davon erfahren.

Der schlechte Ruf, den NFS in HPC-Kreisen hat, geht vor allem auf die alte Grenze einer einzigen Verbindung und den Metadaten-Schmerz bei Kleinstdateien zurück. Für Trainingsdatensätze zwischen 100 GB und 1–2 TB auf Knoten mit 4–8 GPUs ist ein sauber gebauter NFS-Server wirklich ausreichend. Wir haben Kunden gesehen, die Qwen2.5-VL-Feinabstimmungen klaglos auf NFS-gestützten Datensätzen trainiert haben.

NFS wird unangenehm, wenn:

• Datensätze ~2 TB überschreiten und das Mischen den Cache des Servers zum Überlaufen bringt.
• Mehr als ~8–12 Compute-Knoten unter Last auf denselben Mount zugreifen.
• Zig Millionen kleiner Dateien den Workload bestimmen.
• Die Checkpoint-Größe pro Rank 50–100 GB überschreitet und gleichzeitig geschrieben wird.

Unterhalb aller vier Schwellen ist NFS mit ziemlicher Sicherheit die richtige Antwort, und ein paralleles Dateisystem ist überdimensioniert.

BeeGFS – der praktische Mittelweg

BeeGFS ist das parallele Dateisystem, das tatsächlich zum Einsatz kommt, wenn NFS nicht mehr reicht. Es verteilt Daten über mehrere Storage-Targets (Platten auf mehreren Servern) und Metadaten-Targets (separate NVMe-Server). Clients sehen einen Namensraum; Lese- und Schreibvorgänge werden parallel über die Storage-Targets gestriped.

Warum es in mittelgroßen Clustern auftaucht:

• Die Einrichtung dauert Tage, nicht Wochen. Ein kompetenter Linux-Techniker bringt eine Installation mit zwei Storage-Knoten und einem MDS an einem Nachmittag zum Laufen. Lustre spielt nicht in dieser Liga.
• Die aggregierte Bandbreite skaliert linear mit den Storage-Targets. Drei Knoten an 100 GbE liefern annähernd 3× den Lesedurchsatz eines einzelnen Knotens.
• Natives RDMA über InfiniBand oder RoCE – vermeidet TCP/IP-Overhead.
• Open Source, keine Lizenzfalle pro TB. Kommerzieller Support von ThinkParQ optional.

Wo es ehrlicherweise schwächer ist:

• Metadaten bei Workloads mit sehr vielen kleinen Dateien. Ein einzelner MDS wird zum Engpass, sobald Dateien unter 4 KB dominieren. Sie können Metadaten-Targets ergänzen, aber die Architektur ist nicht so konsequent wie Lustres DNE.
• Kein eingebautes Tiering. Hot und Cold verwalten Sie selbst.
• Hochverfügbarkeit ist angebaut, nicht nativ. Spiegelung funktioniert, ist aber nicht so transparent wie Lustres Failover.

Der Sweet Spot: 4–32 Trainingsknoten, 10–100 TB Datensatz, Dateien im Bereich 1 MB bis 1 GB. Dort landen die meisten Kentino-Builds mit mehreren Knoten.

Ein BeeGFS-Basisaufbau für einen Cluster der Kentino-Klasse mit 4 Knoten:

Der dauerhafte aggregierte Lesedurchsatz in die vier Trainingsknoten liegt typischerweise bei 30–60 GB/s – genug, um 32 GPUs bei den meisten Vision- und LLM-Trainings zu versorgen. Die Skalierung endet, sobald der Metadatenserver gesättigt ist: ein zweites Metadaten-Target ergänzen oder über Lustre nachdenken.

Lustre – Goldstandard, echte Komplexität

Lustre betreibt die Speicherebene praktisch jedes Top-500-Supercomputers, der POSIX braucht, und skaliert bis in den Bereich mehrerer hundert Petabyte und mehrerer TB/s Gesamtdurchsatz. Die Architektur kennt drei Rollen: MGS/MDS (Verwaltung und Metadaten), OSS (Object Storage Server mit den OSTs) und Clients. Clients sprechen für Namensraum-Operationen mit dem MDS und danach direkt mit dem OSS, der die Daten hält – der Datenpfad umgeht den Metadatenserver vollständig. Diese Trennung ist der Grund, warum Lustre skaliert, und DNE (Distributed Namespace) lässt auch die Metadaten horizontal skalieren.

Der Preis ist betrieblicher Natur: steilere Lernkurve als bei BeeGFS, strenge Kernel- und Treiberanforderungen, Dutzende Stellschrauben (die Leistung ab Werk ist meist nicht das, was die Hardware liefern könnte) und Wiederherstellungsverfahren, die einen kompetenten Storage-Techniker verlangen.

Die Schwelle, ab der Lustre sinnvoll wird, liegt grob bei 16–32+ Trainingsknoten oder Datensätzen der PB-Klasse. Darunter sättigt BeeGFS das Netzwerk lange bevor Lustres architektonische Vorteile zum Tragen kommen. Das Kentino-Portfolio erreicht diese Schwelle meist nicht – wir bauen auf Wunsch einen Lustre-Cluster, sagen Ihnen aber vorher, dass BeeGFS plus ein kräftiger MDS 80% des Wegs bei 20% des Betriebsaufwands schafft.

Objektspeicher – MinIO und Ceph für ML-Data-Lakes

Die parallelen Dateisysteme oben sind richtig, wenn das Framework Dateien erwartet. Ein wachsender Teil moderner ML-Pipelines tut das nicht – Datensätze liegen als S3-Objekte, der Data Loader holt sie über HTTP, und das lokale Dateisystem ist nur flüchtiger Scratch-Speicher.

MinIO ist ein auf einen Zweck ausgelegter, S3-kompatibler Objektspeicher. Der verteilte Modus läuft auf 4–32+ Knoten mit Erasure Coding. Open Source, betrieblich einfacher als jedes parallele Dateisystem, und moderne Data Loader (PyTorch mit fsspec/s3fs, WebDataset, NVIDIA DALI) lesen ihn direkt.

Ceph ist breiter aufgestellt – Block (RBD), Datei (CephFS) und Objekt (RGW) auf derselben RADOS-Schicht. Ceph gewinnt, wenn Sie ein Speichersystem für mehrere Workloads wollen (VMs, Dateifreigaben, ML-Objekte). Es verliert bei der betrieblichen Einfachheit – Ceph ist ein System, auf das Sie sich festlegen, mit eigenem Monitoring, eigenem Tuning und eigener Bereitschaftsdisziplin.

Was Objektspeicher für ML bietet: günstige Kapazität (dicht bestückte HDD-Knoten mit Erasure Coding erreichen €/TB-Werte, an die Flash nicht herankommt), betrieblich einfachen Scale-out, Sharding by Design (kein Metadaten-Engpass) und eine gute Passung zu shard-basierten Data Loadern. Worauf Sie verzichten: Latenzen im zweistelligen Millisekundenbereich pro Operation (keine Mikrosekunden), kein direktes POSIX (Loader umschreiben oder die FUSE-Einbuße akzeptieren) und keine In-Place-Schreibvorgänge (Objekte sind unveränderlich – für Checkpoints gut, für alles Veränderliche schlecht).

Die Architektur, die sich in der Praxis bewährt: Objektspeicher als dauerhafter, großer, günstiger Data Lake; ein paralleles Dateisystem oder NFS als schneller Arbeitsdatensatz für den aktuellen Lauf. Der Datensatz liegt in MinIO. Ein Job kopiert die relevanten Shards beim Start auf BeeGFS oder lokalen NVMe-Scratch. Die finalen Checkpoints wandern zur Archivierung zurück nach MinIO.

WekaIO und VAST – die Enterprise-Klasse (kurz)

WekaIO und VAST Data sind die eigens gebaute Antwort zum Enterprise-Preis: extreme Metadatenleistung bei kleinen Dateien, sehr hohe aggregierte Bandbreite, natives S3 und POSIX, integriertes Tiering, GPU-Direct-Pfade. Für Cluster mit 100+ GPUs, bei denen der Speicher mit den GPU-Ausgaben Schritt halten muss, ergibt das hervorragend Sinn. Für einen Server mit 4 oder 8 GPUs – oder einen Cluster aus vier solchen – ist es die falsche Wahl: Die Speicherkosten würden den Build dominieren. Hier der Ehrlichkeit halber erwähnt, nicht als Empfehlung für den Käufer, für den diese Reihe geschrieben ist.

Zugriffsmuster auf Datensätze und warum sie zählen

Zwei Muster dominieren das ML-Training. Muster A – große Shards: Datensätze, vorab in WebDataset-Tarballs, Parquet oder LMDB gepackt, 100 MB bis 10 GB pro Shard, sequenziell gelesen und intern gemischt. Darin ist jedes Speichersystem gut. Muster B – viele kleine Dateien: Millionen JPEGs/PNGs/JSONs, eine Datei pro Sample, die den Metadatenpfad hämmern. Das bestraft NFS, tut BeeGFS im großen Maßstab weh und ist der Grund, warum es Weka und VAST gibt.

Die wirkungsvollste Einzelentscheidung beim Trainingsspeicher ist, Muster B in Muster A zu überführen. Besteht Ihr Datensatz aus kleinen Dateien, packen Sie ihn vor dem Training in Shards um. Der Preis ist ein einziger Vorverarbeitungsdurchlauf; der Nutzen ist, dass jedes Speichersystem ausreicht. Wir haben Pipelines um 3–5× schneller werden sehen, ohne eine einzige Änderung an der Speicherhardware – allein durch Umpacken.

Wenn Umpacken nicht geht – der Datensatz ändert sich ständig, das Framework braucht wirklich eine Datei pro Sample –, dimensionieren Sie den Speicher nach Metadaten-IOPS, nicht nach Bandbreite. Das führt Sie zu BeeGFS mit mehreren MDS-Targets, zu Weka/VAST oder zu Lustre mit DNE.

Checkpoint-Strategie – schnell schreiben, später schreiben, weniger schreiben

Checkpoint-Schreibvorgänge sind der Worst Case: Jeder Rank schreibt gleichzeitig, die Schreibvorgänge sind groß, und das Training blockiert, bis die Daten sicher liegen. Ein naiver synchroner Checkpoint bei einem Modell mit 100 B Parametern kann das Training um Dutzende Minuten anhalten.

Der aktuelle Stand der Technik ist ein dreistufiges Verfahren, nativ in PyTorchs torch.distributed.checkpoint (DCP), in NVIDIA NeMo und in den meisten modernen Frameworks:

1. Jeder Rank schreibt seinen Shard auf lokalen NVMe-Scratch. Die gesamte Schreibbandbreite des Clusters ist die Summe der NVMe-Raten pro Knoten (je 5–50 GB/s). Das Training läuft binnen Sekunden weiter.
2. Ein asynchroner Hintergrundprozess kopiert auf den gemeinsamen Speicher. Zu diesem Zeitpunkt läuft das Training längst wieder.
3. Ältere Checkpoints werden gelöscht oder in den Objektspeicher verschoben – nach Zeitplan. Die letzten 2–3 behalten Sie auf schnellem Speicher, der Rest geht nach MinIO/Ceph.

Die Konsequenz: Der gemeinsame Speicher muss nicht jeden Checkpoint mit voller Geschwindigkeit aufnehmen. Er muss die asynchrone Kopie aufnehmen, ohne hinter den Takt zu fallen. Für ein 70-B-Modell mit einem Checkpoint alle 30 Minuten genügt ein niedriger einstelliger GB/s-Wert im Dauerschreiben – das schafft ein kompetentes BeeGFS oder ein guter NFS-Server mühelos.

Der Fehler, den Sie vermeiden sollten: synchrone, nicht geshardete Checkpoints, direkt auf NFS geschrieben. 2022 war das normal. Heute nicht mehr. Wenn Ihre Pipeline so arbeitet, bringt das Korrigieren des Checkpoint-Codes mehr als ein Speicher-Upgrade.

Die Frage nach dem Cluster-Uplink

Teilt sich der Speicherverkehr das Fabric mit dem Training oder bekommt er ein eigenes?

Ein gemeinsames Fabric genügt für Cluster mit 4–8 Knoten und asynchronem Checkpointing; ein getrenntes Fabric ist oberhalb von 8 Knoten oder bei viel synchronem I/O gerechtfertigt.

Für Cluster der Kentino-Klasse mit 4–8 Knoten reicht ein gemeinsames Fabric, wenn asynchrones Checkpointing im Einsatz ist und der Speicher-Workload überwiegend aus Lesevorgängen besteht – dauerhaftes Lesen verträgt sich ohne nennenswerten Schaden mit NCCL-Kollektiven. Ein getrenntes Fabric rechtfertigt sich bei großem LLM-Training mit FSDP und hohem TP-/PP-Grad, bei viel synchronem Speicherverkehr oder wenn das Budget die Reserve hergibt. Der praktische Standard: gemeinsames 100 GbE bis 8 Knoten, mit einem Storage-VLAN als weicher Trennung.

Ehrliche Empfehlungen nach Größenordnung

Die meisten Kentino-Kunden landen in Zeile zwei und drei. Den Rest bauen wir auf Wunsch, sagen Ihnen aber, wenn es überdimensioniert ist.

Was kaputtgeht

Fehlerbilder, die wir gesehen haben, nach Häufigkeit sortiert:

• Metadaten-Hunger bei Last aus kleinen Dateien. Symptom: GPUs bei 30–50%, Netzwerk im Leerlauf, Storage-CPU im Leerlauf, jedes open() langsam. Abhilfe: in Shards umpacken oder MDS-Targets skalieren.
• Synchrone Checkpoints bremsen das Training aus. Abhilfe: asynchrone, geshardete Checkpoints (PyTorch DCP oder NeMo).
• Eine langsame Platte reißt den Cluster mit. Eine sterbende SSD fällt nicht sauber aus – sie wird einfach langsam. Abhilfe: Latenz pro Gerät überwachen, Alarm bei > 2× Referenzwert.
• Page-Cache-Thrashing auf dem Storage-Knoten. Der Datensatz passt nicht in den RAM, jede Epoche verdrängt die vorherige. Abhilfe: mehr RAM.
• nconnect auf den NFS-Clients nicht aktiviert. NFS mit einem einzigen Stream bleibt deutlich unter der Leitungsrate der NIC. nconnect=8 oder =16 bringt auf derselben Hardware 4–8× Durchsatz.
• MinIO im großen Maßstab ohne EC-Tuning. Die Voreinstellungen priorisieren Haltbarkeit vor Latenz; die Latenz bei kleinen Objekten leidet. Übernehmen Sie die Voreinstellungen nicht blind.

Nichts davon ist exotisch. Alles ist vorhersehbar, sobald man es einmal gesehen hat.

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen willkommen unter info@kentino.com.