In der Welt verteilter Dateisysteme sind Leistungsbenchmarks ein entscheidendes Werkzeug, um die Praxistauglichkeit und Skalierbarkeit neuer Systeme zu beurteilen. Das 3FS von DeepSeek stellt sich als ein vielversprechendes verteiltes Dateisystem dar, das speziell auf den Einsatz in AI-Trainings- und LLM-Inferenz-Workloads optimiert wurde. Doch wie genau halten die veröffentlichten Benchmark-Ergebnisse und Performanceaussagen dieser Software einer detaillierten Überprüfung stand? Es gilt, über die schillernden Zahlen hinauszublicken und sie an realistische Hardwareparameter und mögliche systemische Grenzen zu messen. Dieser Realitätscheck bietet eine fundierte Betrachtung der Leistungsdaten und hilft, mögliche Optimierungspotentiale sowie Engpässe zu identifizieren. Grundsätzlich neigen Benchmark-Analysen dazu, sich direkt auf aufwendige Profiler-Tools und detaillierte Messmetriken zu stürzen.
Während Werkzeuge wie perf, strace und iostat unverzichtbar sind für die Ursachenforschung bei Performance-Problemen, birgt der Sprung in komplexe Profilings ohne solide Basis die Gefahr, ziellos vorzugehen. Ein einfaches aber wirkungsvolles Mittel ist die sogenannte „Performance Reality Check“-Methode: Hierbei wird die benchmarkseitig erreichte Leistung mit theoretisch möglichen Hardware-Grenzwerten verglichen, die etwa von Spezifikationen der eingesetzten SSDs oder Netzwerkinfrastruktur abgeleitet werden. Dies gibt eine schnelle Einschätzung, ob die gemessene Performance realistisch ist oder ob schwerwiegende Flaschenhälse existieren. Ein konkretes Beispiel veranschaulicht die Methodik besonders gut: Ein Unternehmen könnte in einem Benchmark eine beeindruckende Datenmenge von 250 Gigabyte lesen. Ohne die Angabe der Zeitspanne ist diese Zahl allerdings wenig aussagekräftig.
Erst die Umrechnung auf eine Durchsatzrate, zum Beispiel Gigabyte pro Sekunde, offenbart das tatsächliche Leistungsniveau und erleichtert den Vergleich mit Hardware-Spezifikationen oder konkurrierenden Systemen. Beim genauerem Blick auf DeepSeeks 3FS bieten sich diverse Benchmarks an, um die Methode des Reality Checks an konkreten Zahlen zu demonstrieren. Einer der spannendsten und wichtigsten Benchmark-Workloads der 3FS Tests adressiert den Datendurchsatz bei AI-Trainingsjobs. Diese Jobs sind charakterisiert durch massive Lesemengen von Trainingsdaten, die zwischen Speicher- und Rechenknoten hin und her übertragen werden. DeepSeek gibt an, dass im großen Maßstab eine durchschnittliche Durchsatzrate von 6,6 Terabyte pro Sekunde erreicht wird, mit Spitzenwerten bis zu 8 Terabyte pro Sekunde. Diese Zahlen sind zunächst beeindruckend, doch das Verständnis der zugrunde liegenden Hardware ist essentiell, um deren Realisierbarkeit zu beurteilen.
Die Benchmark-Infrastruktur besteht aus 180 Storage-Knoten, die jeweils mit 16 modernen PCIe 4. 0 NVMe SSDs ausgestattet sind, sowie 500 Client-Knoten mit 200 Gbps Netzwerkanschlüssen. Für die Analysen wird ein realistisch referenzierter SSD-Typ gewählt, der eine durchschnittliche sequentielle Lesegeschwindigkeit von rund 7 Gigabyte pro Sekunde pro Laufwerk bietet. Daraus lässt sich eine theoretische Gesamtdurchsatzkapazität für die Storage-Seite von etwa 20 Terabyte pro Sekunde im sequentiellen Lesemodus ableiten. Die Netzwerkschnittstellen auf den Storage-Knoten erreichen zusammen eine maximale theoretische Netzwerkgeschwindigkeit von ungefähr 9 Terabyte pro Sekunde, während die Clients eine Kapazität von etwa 12,5 Terabyte pro Sekunde besitzen. Diese Analyse verdeutlicht, dass die eigentliche Engstelle beim AI-Trainingsbenchmark im Netzwerk und nicht in der Speicherkapazität liegt.
Der Spitzenwert von 8 Terabyte pro Sekunde liegt knapp unterhalb der maximalen Netzwerkbandbreite auf Seiten der Storage-Knoten. Gleichzeitig befindet sich die gemessene Leistung nur bei etwa 40 Prozent der ins Auge gefassten theoretischen Festplattenleistung. Dies deutet darauf hin, dass es nicht sinnvoll wäre, alle SSDs maximal auszunutzen, da das Netzwerk bereits limitiert. Zwei mögliche Optimierungstracks liegen daher nahe: zum einen die Reduktion der verbauten SSDs, um Kosten und Komplexität zu senken, oder die Aufrüstung der Netzwerkinfrastruktur auf höhere Geschwindigkeiten, beispielsweise auf 800 Gbps NICs. Beide Varianten haben allerdings praktische Stolpersteine, etwa in Kosten- und Hardwarekompatibilität. Interessanterweise fällt im Durchsatzverlauf ein regelmäßiges Abfallen um rund vier Prozent auf, was auf typische Checkpointing-Operationen oder periodische Software-Vorgänge innerhalb des verteilten Dateisystems schließen lässt.
Diese temporären Leistungseinbrüche sind jedoch eher geringfügig und wirken sich auf die Gesamtleistung kaum aus. Ein weiterer Benchmark, der sogenannte GraySort, stellt das Dateisystem auf eine harte Probe, indem er ein komplexes Muster aus sequenziellen Lese- und zufälligen Schreiboperationen enthält. Das Benchmark-Verfahren gleicht einem MapReduce-orientierten Sortiervorgang großer Datenmengen, die in iterativen Phasen sortiert, gemischt und wieder zurückgeschrieben werden. Die Messwerte illustrieren eine durchweg moderate Nutzung der Storage-Kapazitäten bei etwa 10 bis 15 Gigabyte pro Sekunde, wobei die Speicherknoten bei weitem nicht an ihre Netzwerkgrenze stoßen. Die Anzahl der Clients scheint hier der limitierende Faktor zu sein, da die vorhandene Storage-Hardware noch deutlich mehr Last vertragen könnte. Theoretisch wäre mit deutlich mehr Clients die Speicherkapazität optimaler ausnutzbar.
Dieses Muster weist auf einen klassischen Engpass in verteilten Systemen hin: Sind die Rechenwerkzeuge (Clients) nicht leistungsstark oder zahlreich genug, bleiben die eigentlichen Speicherressourcen unterfordert. Zudem verursacht das Konsistenzprotokoll CRAQ, das für die Integrität geschrieben Daten sorgt, zusätzlichen Verkehr und Verarbeitungsaufwand, der die Schreibleistung beeinflusst. Deshalb erreichen die Schreibdurchsätze bei den Kunden nicht die Read-Levels. Ein sehr praxisrelevanter Workload ist die Nutzung des Key-Value-Caches (KV Cache) während der Inferenz von großen Sprachmodellen (LLM). DeepSeek verfolgt hier einen speziellen Ansatz, bei dem für jeden Token speicherintensive Key-Value-Paare abgelegt werden, die den Rechenaufwand deutlich reduzieren sollen. Die Workload kennzeichnet sich durch viele kleine, zufällige Leseoperationen und periodische Löschvorgänge im Speicher.
Im KV-Cache-Benchmark schwankt die gemessene Leseleistung je nach Last stark: vom steigenden Spitzenwert knapp 40 Gigabyte pro Sekunde bis zu einem Durchschnitt von lediglich 3 Gigabyte pro Sekunde. Diese Diskrepanz verrät, dass die Systemauslastung stark von kurzzeitigen Zugriffen oder multiplen Benutzern abhängt. Die Löschmechanismen (Garbage Collection) laufen in bursts mit bis zu einer Million IOPS, was auf ein batchbasiertes Löschverfahren hindeutet – eine gängige Strategie, um Hintergrundarbeit zu bündeln und die Latenz für aktive Anfragen gering zu halten. Allerdings fällt ein Negativpunkt im Bereich der Speichereffizienz ins Auge: Da die einzelnen Key-Value-Datensätze eine Größe von rund 70 Kilobyte haben, aber auf 4-Kilobyte-Blöcke der SSD aufgeteilt werden, entsteht ein messbarer Speicherverlust durch nicht genau passende Blockgrößen.
Die Überhänge summieren sich bei großem Maßstab schnell zu sechsstelligen US-Dollar-Beträgen – ein Kostenfaktor, der in der Planung großer Rechenzentren nicht unterschätzt werden darf. Die Benchmark-Daten von DeepSeek lassen die Latenzbetrachtung vermissen, obwohl gerade in AI-Aufgaben mit Echtzeit-Constraints niedrige und stabile Antwortzeiten essenziell sind. Die Fokussierung auf reine Durchsatzzahlen schränkt das Gesamtbild des Systemverhaltens ein. Gerade Tail-Latenzen und Verzögerungen bei Datenzugriffen können die Nutzererfahrung an entscheidenden Stellen negativ beeinflussen. Zusammenfassend zeigt der Realitätscheck, dass DeepSeeks 3FS Distributed File System grundsätzlich solide aufgesetzt ist und die Performance-Claims in einem realistischen Rahmen liegen. Dennoch sind Optimierungen im Bereich der Netzwerkkapazität und der Client-Parallelisierung wünschenswert, um das volle Potenzial moderner SSD-Arrays auszuschöpfen.
Zusätzlich sollten speichereffiziente Datenstrukturen und garbage collection Mechanismen weiter verbessert werden, um Kosten und Systemlast zu senken. Die Offenheit in Bezug auf Latenzmetriken würde dem Verständnis der praktischen Einsatzfähigkeit zugutekommen. Der vorgestellte analytische Ansatz illustriert, wie ein simples Gegenüberstellen von Benchmark-Daten mit Hardware-Spezifikationen wertvolle Einblicke liefert und vereinfacht, wo langwierige Profiler-Sessions nur mühsam Erkenntnisse zutage fördern. Für Entwickler und Betreiber verteilter Systeme ist eine solche reale Einschätzung unverzichtbar, um Investitionen zu rechtfertigen und Engpässe gezielt anzugehen. Zukünftige Untersuchungen sollten, wie angekündigt, praktische Tests mit 3FS auf echter Hardware umfassen, um neben Durchsatz auch Latenzverteilungen zu messen und systemische Flaschenhälse zu identifizieren.
Durch diese iterative Herangehensweise gewinnt die Community ein aussagekräftiges Bild über die Leistungsfähigkeit und Robustheit vernetzter Speicherarchitekturen im Zeitalter der KI.
