Aufbau eines Storage-Clusters für Pretraining mit 30-Petabyte-Festplatten

 (si.inc)
3 Punkte von GN⁺ 2025-10-02 | 1 Kommentare | Auf WhatsApp teilen
  • Für das Pretraining eines Modells zur Lösung von Computer-Use-Problemen wird in der Innenstadt von San Francisco ein eigener Storage-Cluster aufgebaut, mit dem Ziel, Videodaten im Umfang von 90 Millionen Stunden zu speichern
  • Es wurde ein On-Premises-Ansatz gewählt, mit dem sich eine 30-PB-Speicherinfrastruktur für 354.000 US-Dollar pro Jahr betreiben lässt. Bei AWS wären es 12 Millionen US-Dollar, also etwa 34-mal geringere Kosten
  • Anders als die meisten Public Clouds liegt der Fokus nicht auf Hochverfügbarkeit und Integrität; stattdessen wird aufgrund der Eigenschaften von Trainingsdaten eine Strategie gewählt, bei der Datenverlust toleriert wird
  • Der Betrieb erfolgt mit einfacher Software auf Basis von Rust und Nginx; statt komplexer Systeme wie Ceph oder MinIO wird ein selbst entwickeltes Programm mit 200 Zeilen Code eingesetzt
  • Im Verlauf des Projekts wurden zahlreiche praktische Erfahrungen und Best Practices rund um physische Platzierung, Netzwerkkonfiguration und Kabelmanagement gesammelt

Einleitung und Hintergrund

  • Für das Pretraining von Modellen zur Computernutzung werden große Mengen an Videodaten benötigt
  • Für ein typisches Text-LLM (z. B. LLaMa-405B) reichen etwa 60 TB Daten aus, doch video-basiertes Training erfordert 500-mal mehr Speicherplatz
  • Die Nutzung einer Public Cloud wie AWS würde 12 Millionen US-Dollar pro Jahr kosten, doch durch die Anmietung eines Colocation-Centers und den Eigenaufbau konnten die Kosten drastisch auf rund 354.000 US-Dollar gesenkt werden
  • Durch die eigene Speicherung großer Datenmengen wurde das Problem gelöst, dass Datenkosten der größte Engpass waren

Warum selbst bauen?

  • Cloud-Angebote konzentrieren sich auf hohe Zuverlässigkeit, Redundanz und Datenintegrität, doch Daten für das Pretraining sind nicht so kritisch, dass nicht einmal 5% Verlust zulässig wären
  • Dadurch konnten deutlich lockerere Zuverlässigkeitsanforderungen gewählt werden als in gewöhnlichen Unternehmen (13 Neunen Zuverlässigkeit statt nur 2 Neunen)
  • Die Preise für Storage liegen deutlich über den tatsächlichen Selbstkosten
  • Da Daten der größte Kostenfaktor sind, wurde entschieden, dass ein lokales Rechenzentrum innerhalb eines ausreichend gut vorhersagbaren Rahmens wirtschaftlicher ist

Kostenvergleich: Cloud vs. Eigenbau

  • Monatlich wiederkehrende Kosten: Internet 7.500 US-Dollar + Strom 10.000 US-Dollar = insgesamt 17.500 US-Dollar
  • Einmalkosten: Festplatten 300.000 US-Dollar, Chassis 35.000 US-Dollar, CPU-Nodes 6.000 US-Dollar, Installationskosten 38.500 US-Dollar, Arbeitskosten 27.000 US-Dollar, Netzwerk und sonstige Installationskosten 20.000 US-Dollar → insgesamt 426.500 US-Dollar
  • Einschließlich Abschreibung (3 Jahre) ergeben sich monatliche Fixkosten von 29.500 US-Dollar
  • AWS: 1.130.000 US-Dollar pro Monat, Cloudflare R2: 270.000 US-Dollar pro Monat, Eigenbau: 29.500 US-Dollar pro Monat
    • AWS: rund 38 US-Dollar pro TB und Monat
    • Cloudflare: rund 10 US-Dollar pro TB und Monat
    • Eigenbau: 1 US-Dollar pro TB und Monat
  • Beim Training großer Modelle traten selbst bei Cloudflare Rate-Limit-Probleme durch starke Last auf internen Systemen auf; in der eigenen Umgebung wurde das mit einer dedizierten 100-Gbps-Leitung gelöst

Aufbau und Prozess

  • Für einen schnellen Aufbau wurde der Plan Storage Stacking Saturday(S3) umgesetzt, mit Unterstützung aus dem Umfeld und durch professionelle Auftragnehmer
  • Innerhalb von 36 Stunden wurden 2.400 Festplatten in Racks eingebaut und damit 30 PB Hardware fertiggestellt
  • Die Software besteht aus Rust (für Schreibvorgänge, 200 Zeilen) + nginx (für Lesezugriffe) + SQLite (zur Verfolgung von Metadaten)
    • Ceph, MinIO, Weka, Vast usw. wurden wegen Komplexität und Kosten nicht eingesetzt (zu komplex, nicht erforderlich, hoher Wartungsaufwand usw.)
    • Alle Laufwerke wurden mit XFS formatiert

Feedback und Erkenntnisse aus dem Projekt

Was gut funktioniert hat

  • Der Trade-off zwischen Redundanz und Performance wurde passend gewählt, sodass das 100G-Netz nahezu vollständig ausgelastet werden konnte
  • Durch den Aufbau in räumlicher Nähe wurde einfaches Debugging und einfache Wartung ermöglicht
  • Anbieter wurden über eBay gefunden, der eigentliche Kauf erfolgte jedoch direkt bei einzelnen Lieferanten; die Bedeutung von Garantien wurde hervorgehoben
  • Eine 100G-Internetleitung hatte viele Vorteile, und auch Netzwerkprobleme ließen sich intern leicht debuggen
  • Sauberes Kabelmanagement half später erheblich bei der Fehlersuche
  • Statt komplexer Open-Source-Storage-Systeme wurde das Prinzip der Vereinfachung angewandt, um den Wartungsaufwand zu minimieren
  • Auch Zeit- und Arbeitskosten wurden präzise prognostiziert, und der Spareffekt ließ sich klar bestätigen

Schwierigkeiten und Fehlversuche

  • Durch die Verwendung von Frontloadern war es umständlich, alle 2.400 HDDs einzeln manuell einzubauen
  • Die Storage-Dichte war unzureichend; bei höherer Dichte im ursprünglichen Design hätte sich Arbeitsaufwand sparen lassen
  • Daisy-Chaining verursachte Geschwindigkeitsengpässe; ideal wäre eine separate HBA-Anbindung pro Chassis
  • Bei Netzwerkkomponenten ist Markenkompatibilität wichtig, insbesondere bei optischen Transceivern
  • Das Experimentieren mit und Einrichten der Netzwerkkonfiguration kostete Zeit; statt DHCP/NAT wurde auf Performance und Komfort fokussiert (nur minimale Anforderungen an Firewall/secure link angewandt)
  • Die Bedeutung physischer Zugänglichkeit sowie der Verkabelung von Monitor und Tastatur beim Setup wurde deutlich

Ideen, die sich lohnen könnten

  • Effizientere Fernverwaltung durch KVM und IPMI
  • Ein separates Ethernet-Netzwerk für die Administration wird empfohlen
  • Netzwerk-Überprovisionierung (z. B. auch ein 400G-Backbone wäre erwägenswert)
  • Mit Servern höherer Dichte (90-Drive-Supermicro / 20-TB-HDDs usw.)
    könnten weniger Racks, geringerer Stromverbrauch und Vorteile bei der CPU-Konsolidierung erzielt werden

Wie man so etwas selbst aufbauen kann

Storage-Konfiguration

  • 10 CPU-Head-Nodes (Intel RR2000 usw., empfohlen pro Server: Dual Intel Gold 6148 / 128 GB ECC DDR4 RAM)
    • Bei CPU-intensiven Funktionen (z. B. ZFS) kann leistungsfähigere Hardware gewählt werden
  • 100 DS4246-Chassis (jeweils mit 24 HDDs)
  • 2.400 3.5"-HDDs (wenn möglich SAS-Laufwerke empfohlen, wegen Geschwindigkeitsvorteilen)
    • Kombination verschiedener Kapazitäten (12 TB, 14 TB usw.); größere Kapazitäten sind bei Platzierung und Wiederverkaufswert vorteilhaft
  • Schienen/Brackets für die physische Montage sowie Verkabelung und Kabel für die Geräte
  • Mehrere Crash Carts (Monitor + Tastatur) zum Debuggen von Netzwerkproblemen

Netzwerkinfrastruktur

  • 100GbE-Switches (gebrauchte Arista-Geräte o. Ä., QSFP28-Ports)
  • HBA pro Server (empfohlen: Broadcom 9305-16E usw.) sowie die Verbindung von HBA-Ports und Chassis
  • Netzwerkkarten (Mellanox ConnectX-4 usw., unbedingt im Ethernet-Modus)
  • DAC-/AOC-Kabel — bei Entfernungen zwischen Racks bietet DAC Kompatibilitätsvorteile
  • Beim Kauf von CPU-Head-Nodes wird empfohlen, einen Anbieter zu nutzen, der HBA/NIC bereits vorinstalliert hat
  • Serielle Kabel, separates Management-Ethernet-Netzwerk (alternativ WLAN-Adapter als Backup + Mini-Switch)

Anforderungen an das Rechenzentrum

  • 3,5 kW Leistungsaufnahme pro Cabinet, bei 42U wird eine Konfiguration von 4U×10 + 2U×1 angenommen
  • 3 PB pro Cabinet, plus ein zusätzliches 42U-Cabinet für Switches oder alternativ ein 1U-Chassis
  • Dedizierte 100G-Cross-Connects (typischerweise ein Paar QSFP28-LR4-Optiken), vorherige Prüfung von Formfaktor- und Markenkompatibilität ist zwingend
  • Ein Standort nahe am Büro (Colocation) wird empfohlen, damit bei Problemen schnell physisch eingegriffen werden kann und Debugging sowie Betriebsproduktivität optimiert werden

Tipps für die Ersteinrichtung

  • Nach der ersten lokalen Konsolen-Konfiguration des Switches sollten zunächst die 100GbE-Uplink-Ports eingerichtet und die Kompatibilität der optischen Transceiver geprüft werden
    • Falls nötig kann die ISP-Glasfaser direkt an die NIC angeschlossen werden, um zunächst Link-Up zu verifizieren und erst danach auf den Switch umzuziehen
  • Während der Ubuntu-Installation mit Netplan lässt sich die Netzwerkkonfiguration der Nodes am einfachsten abschließen
  • Nachdem die Nodes Internetzugang haben, sollte man in der Reihenfolge jeweils ein Kabel pro DS4246 anschließen → formatieren/mounten → Zustand prüfen vorgehen, um Verkabelungs- und Laufwerksfehler früh zu erkennen

Hinweise zu Performance, Stabilität und Sicherheit

  • Unter der Sicherheitsannahme, dass es sich ausschließlich um Trainingsdaten handelt, wird ein vereinfachter Betrieb mit direkter öffentlicher IP-Anbindung + Port-Firewall + nginx secure_link genutzt
    • Beim Umgang mit Kundendaten wäre dieselbe Konfiguration ungeeignet; DHCP/NAT/segmentierte Firewalls sind dann zwingend erforderlich
  • Daisy-Chaining vereinfacht zwar Verwaltung und Verkabelung, verursacht aber Bandbreitenengpässe; wenn möglich wird eine dedizierte HBA pro Chassis empfohlen
  • Optische Transceiver unterliegen starkem Brand-Lock-in; Beschaffung über FS.com und Amazon parallel ist sinnvoll, aber Spezifikationen und Markenabgleich müssen sorgfältig geprüft werden

Fazit und Bedeutung

  • Mit extrem günstigem Self-Storage auf dem Niveau von 1 US-Dollar pro TB und Monat wurde 30-PB-Video-Pretraining praktikabel, bei einer 10- bis 38-fachen Kostenreduktion gegenüber der Cloud
  • Einfache Architektur und gute Vor-Ort-Zugänglichkeit reduzierten Zeit und Risiko, und die dedizierte 100G-Leitung beseitigte I/O-Engpässe
  • Im Zeitalter großer multimodaler und Video-Modelle ist kostengünstige Dateninfrastruktur mit hoher Kapazität ein zentraler Wettbewerbsvorteil; dieser Ansatz liefert eine praxisnahe Referenz, die selbst mit wenigen Personen umsetzbar ist

Abschluss und Hinweis zur Zusammenarbeit

  • Wer auf Basis dieses Artikels einen ähnlichen Storage-Cluster aufgebaut hat, ist eingeladen, Verbesserungen und Erfahrungen zu teilen
  • Es werden Forschende für das Pretraining großskaliger Modelle zur Computernutzung sowie für KI-Forschung zu Generalisierung und menschlichen Werten gesucht (Kontakt: jobs@si.inc)

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-02
Hacker-News-Kommentare

  • Als ich meine Karriere begann, war On-Premises selbstverständlich. Langlebige Hardware bekommt am Ende viel Zuwendung, und jeder Server sammelt seinen eigenen Zustand an. Wenn die Hardware mit der Zeit nicht mehr leistungsfähig genug ist, muss man über interne Teams neue Hardware aus der bestehenden Liste auswählen und sich zusätzlich Kosten freigeben lassen, was umständlich ist. Beim Austausch der Hardware oder beim sorgfältigen Trennen von Geräten, die man wie Haustiere gehegt hat, und dem Umstieg auf neue Hardware verzögern sich Projekte manchmal. Als die Cloud aufkam, dachte ich daher: „Jetzt muss alles unbedingt in die Cloud.“ Mit der Zeit verlernt man jedoch selbst und auch als Organisation, Hardware direkt zu betreiben. Wenn man diese Fähigkeiten nicht wiederbelebt, wird die einst gute Entscheidung für die Cloud nach und nach weniger attraktiv. Deshalb danke dafür, dass ihr diese Fähigkeiten wieder aufbaut.

    • Bei uns ist die Situation etwas ungewöhnlich. Wir konnten uns Hyperscale-Cloud von Anfang an als Betriebsausgabe nicht leisten und mussten daher zwangsläufig eigene Fähigkeiten aufbauen. Es ist nicht so schwierig, wie man denkt, und wir werden vorerst so weitermachen. Allerdings sehen wir durchaus das erwähnte Problem der Zustandsakkumulation.

    • In meiner Erinnerung war On-Premises immer günstiger. Viele logistische Hürden fielen weg, und eine einzige Rechnung war bequem. Als die Cloud ihren Höhenflug hatte, lautete der Rat immer: On-Premises nutzen und die Cloud nur dann einsetzen, wenn der Traffic plötzlich hoch- oder runtergeht. Doch aus temporärer Skalierung wurde zunehmend Dauerbetrieb, und Entwickler verließen sich nur noch darauf, sofort neue Maschinen hochzufahren. Inzwischen gilt die Cloud für alle als Normalzustand. Dabei haben wir die Grundlage verloren, die tatsächlichen Kosten richtig wahrzunehmen, und der Kostenunterschied zwischen Cloud und On-Premises ist immer größer geworden.

    • Docker ist ein hervorragendes Werkzeug, um Server nicht mehr wie Haustiere zu behandeln. Ein Server im Rack wird einfach als weiterer K3- oder K8-Knoten behandelt und nicht wie ein Haustier. Das ist wirklich großartig. Über VMs könnte man etwas Ähnliches sagen, aber am Ende wird die VM selbst zum Haustier. Natürlich kann man Images bauen oder Snapshots erstellen, aber das fühlt sich anders an als die Veränderung, die Docker mit sich bringt.

    • Halb scherzhaft die Frage, ob man so eine Herausforderung noch einmal angehen sollte.

  • Ein Startup, das genug Geld hat, um ganz selbstverständlich eine zweibuchstabige .inc-Domain zu kaufen, hat zu viel Kapital. Das ist wie früher in Startups die Aeron-Stühle im Büro zu zählen. Kein gutes Zeichen.

    • Ungenutzte zweibuchstabige .inc-Domains werden für 2300 Dollar pro Jahr verkauft. Das ist nicht einmal 5 % der Personalkosten eines einzelnen Entwicklers.

    • Ich bezweifle, dass eine .inc-Domain praktisch einen echten Wert hat.

  • Interessanter Artikel. Beim Lesen hatte ich stellvertretend meinen Spaß. Noch mehr Fotos hätten das Ganze noch unterhaltsamer gemacht.

    • Falls die Autoren kommentieren, würde ich gern direkt fragen, was Standard Intelligence PBC eigentlich macht – ob das für Public Benefit Corporation steht oder an welchen Projekten sie arbeiten.

  • Mir gefiel, wie detailliert die technischen Inhalte beschrieben waren. Ich frage mich allerdings, wie die Suche nach Colocation-Fläche ablief. Habt ihr einen Broker benutzt? Und wie groß war bei den Preisverhandlungen der Unterschied zwischen dem ursprünglichen Angebot und dem tatsächlich gezahlten Preis?

    • Wir haben bei den meisten Colocation-Anbietern in San Francisco und Fremont Angebote eingeholt. Zwischen Angebot und tatsächlich gezahltem Preis gab es keinen Unterschied, aber bei den Konditionen und den einmaligen Kosten haben wir verhandelt.

  • Auch der verlinkte Discord-Blogpost ist interessant. Meist geht es darin ernsthaft zu, aber es gab auch solche unterhaltsamen Stellen: Wenn bei der WM ein Tor fiel, spiegelte sich das sofort in den Monitoring-Grafiken wider, sodass Teammitglieder während Meetings das Fußballschauen als dienstliches Monitoring tarnen konnten. Er wurde auch als Beleg dafür zitiert, dass Discord Nachrichten mit „weniger als einem Petabyte“ Speicher ablegt. Wenn man nachrechnet, ergibt sich aus der Knotengröße und -anzahl in diesem Artikel für den alten Cluster wohl etwa 708 TB und für das neue Setup etwa 648 TB, einschließlich Wachstumsspielraum.

  • Das Speichern selbst ist sehr günstig. Was ich aber nicht verstehe, ist der Teil mit dem Training und dem Netzwerk-Setup. In einem anderen Kommentar hieß es, dass sich die GPUs nicht an einem Ort befinden. Dann müssten die Trainingsdaten also nur mit 100 Gbit/s zwischen mehreren Standorten hin- und hergeschoben werden. Ich frage mich, ob das beim Pretraining nicht zu einem Flaschenhals wird.

    • Aktuell haben wir nur eine einzige 100-Gigabit-Verbindung, und vorerst können auch die GPU-Cluster nicht mehr als diese Datenrate senden und empfangen. Mit der weiteren Skalierung wollen wir sowohl Bandbreite als auch Speicher ausbauen. Übrigens stehen in der Colo mehrere 4090er, die für Datensplitting oder Embedding-Aufgaben extrem nützlich waren.

  • Bei Workloads dieser Größe könnte man sich von AWS oder anderen Clouds durchaus private Angebote geben lassen. Bei S3 kann man schon ab 0,5 PB ein individuelles Angebot bekommen. Das heißt nicht automatisch, dass die Gesamtkosten dann niedriger sind als beim Eigenbetrieb, aber die Retail-Preise eines CSP mit auf eBay beschaffter Hardware plus kostenloser Arbeit (abgesehen von Pizza) zu vergleichen, ist kein vollständiger Vergleich.

    • Bei AWS oder generell in der Cloud sind die Egress-Kosten wirklich der Knackpunkt. Selbst bei Verhandlungen bewegen sie sich dort überhaupt nicht. Für AI-Training ist das praktisch unbrauchbar. Ein Angebot von Cloudflare ist unter den gemanagten Object-Bucket-Storage-Angeboten eher günstig. Wenn man einen eigenen Cluster aufbaut, wird der Unterschied zu einem gemanagten Service kleiner, und der Eigenbau verschafft einem auch Verhandlungsmacht. Allerdings sind gemanagte Buckets für reinen Pretraining-Storage überdimensioniert. Glacier ist für Archivierung preislich attraktiv, aber für ML gibt es noch kein Produkt, das wirklich genau passt.

    • Mich würde interessieren, was für konkrete Deals da möglich sind. Sind auch mehr als 50 % Rabatt drin?

  • Es hat Spaß gemacht, beim Einbau der Laufwerke mitzuhelfen. Mit so vielen Daten tatsächlich zu arbeiten, ist einfach die spannendste Erfahrung :P

  • Es gibt keine Erwähnung der Ausfallrate der Disks. Mich würde interessieren, wie der Zustand nach ein paar Monaten aussieht.

    • Das erinnert mich an eine frühere Erfahrung: Als wir mehrere Disk-Arrays hochgezogen haben, gab es massenhaft Laufwerksausfälle. Wir haben Freitagnachmittag das Rack eingerichtet, es übers Wochenende unangetastet gelassen und mit einem einfachen Shell-Skript Lese-/Schreibtests laufen lassen. Als wir am Montag zurückkamen, war fast die Hälfte der Disks ausgefallen, ohne dass irgendwelche Logs hinterlassen worden wären. Ob etwas beim Striping schiefging oder ob der Stresstest sie gekillt hat, ließ sich nicht feststellen. Es war offenbar eine fehlerhafte Produktionscharge, und mehrere Kunden derselben Firma hatten Beschwerden. Der Hersteller tauschte alle aus, und nur der Produktivstart verzögerte sich. Danach gab es ein Jahr lang keinerlei Ausfälle mehr.

    • Im Vergleich zu vor zehn Jahren sind die Ausfallraten von Disks in letzter Zeit sehr niedrig geworden. Früher haben wir mehr als zehn pro Woche ausgetauscht, heute passiert das nur noch selten. Ein Blick auf die Festplattenstatistiken von Backblaze reicht meiner Meinung nach völlig aus.

    • Es hieß, dass in diesem Cluster Enterprise-Laufwerke verwendet werden. Wenn man aus Spargründen an der falschen Stelle kürzt, kann das später teuer werden. Ich habe persönlich gebrauchte Laufwerke für einen Homeserver ausprobiert, und die Leistungsschwankungen waren so groß, dass ich davon nicht begeistert war.

    • Guter Punkt.