Metas KI-Speicher-Blaupause im großen Maßstab
Meta hat seine BLOB-Speicherarchitektur grundlegend neu gestaltet, um den Anforderungen moderner KI-Workloads gerecht zu werden. Die Neuentwicklung zielt darauf ab, GPU-Auslastung zu maximieren und die Iterationsgeschwindigkeit der Forschung zu erhöhen.
Die Grenzen der bisherigen Architektur
Die bisherige Speicherinfrastruktur basierte auf der Tectonic-Blockschicht und einer darauf aufbauenden BLOB-Architektur. Diese war primär für traditionelle Dienste wie Facebook, Instagram und Meta AI ausgelegt. Bei KI-Workloads zeigten sich klare Limitationen:
- Hohe und unvorhersehbare Latenzen bei Metadatenabfragen, die zu GPU-Stillständen führten
- Ineffiziente globale Replikation für primär regionale KI-Berechnungen
- Suboptimale Kosten- und Energieeffizienz bei hohen IOPS-Anforderungen, die Flash-Speicher erfordern
Diese Faktoren beeinträchtigten sowohl die Recheneffizienz als auch die Geschwindigkeit, mit der Forscher neue Modelle entwickeln und trainieren konnten.
Die neue KI-Speicherarchitektur
Meta hat die BLOB-Speicherarchitektur vollständig neu implementiert. Die zentralen strukturellen Änderungen sind:
-
Vereinheitlichtes Metadaten-Schema: Alle Metadaten wurden in einem flachen Schema konsolidiert, das auf ZippyDB basiert. Dies ermöglicht O(1)-Lookup-Zeiten für die Auflösung von Pfaden zu Speicheradressen.
-
Direkter Datenpfad: Der vorherige Dataplane-Proxy wurde entfernt. Ein „Fat Client SDK“ streamt Daten nun direkt von den Speicherservern, was Latenz, Durchsatz und Energieeffizienz verbessert.
-
Regionale Bereitstellung: Der schlanke Stack wird regional direkt neben den GPU-Clustern deployt.
Bewältigung von Lastspitzen und Hot Spots
Zur Handhabung der hohen Parallelität und burst-artigen Zugriffsmuster von KI-Trainings wurden zwei zentrale Mechanismen integriert:
- Ein verteilter Daten-Cache, der freien Speicher auf GPU-Hosts nutzt und Komponenten des Owl-Subsystems wiederverwendet.
- Ein Readplan-Metadaten-Cache, der Pfad-zu-Adresse-Zuordnungen im In-Memory-Speicher vorhält.
Zusätzlich wurden Protokolloptimierungen implementiert: Client-seitige „Hedged Reads“ gegen langsame Knoten (Laggards) sowie eine dynamische Parallelitätskontrolle zur Dämpfung von Egress-Spitzen bei Checkpoint-Ereignissen.
Gestufte Caching-Architektur zur Beschleunigung der Forschung
Meta hat eine mehrschichtige Caching-Hierarchie eingeführt:
- L1/L2: Speicher und Flash auf den GPU-Hosts
- L3: Regionales Flash-basiertes BLOB-Speichernetzwerk
- Ultimative Quelle: Globales, HDD-basiertes BLOB-Speichernetzwerk
Wichtige Mechanismen sind der Dataloader-Prefetch, eine explizite prefetch()-API im SDK zur Hintergrund-Hydrierung in den L3-Cache sowie ein automatischer Datenlebenszyklus mit konfigurierbaren Eviction-Richtlinien (TTL, LRU) und Quotenbewusstsein. Dadurch reduziert sich die Zeit für Datenaufnahme und -verschiebung zwischen Regionen erheblich.
Quelle: Meta Engineering
FAQ
Welches Kernproblem adressiert die neue BLOB-Architektur?
Sie löst Speicherengpässe, die durch exponentiell wachsende KI-Modelle und Datensätze entstehen und die GPU-Auslastung sowie die Forschungsgeschwindigkeit limitieren.
Was ist die zentrale technische Änderung im Metadatenbereich?
Die Zusammenführung aller Metadaten in ein einheitliches, flaches Schema auf Basis von ZippyDB, das konstante Lookup-Zeiten ermöglicht.
Wie wird die gestufte Caching-Architektur genutzt?
Durch Prefetch-Mechanismen und einen automatischen Lebenszyklus werden Daten schrittweise von globalen HDDs in regionale Flash-Speicher und schließlich auf die GPU-Hosts gebracht, um Wartezeiten zu minimieren.
Welche zukünftigen Herausforderungen nennt Meta?
Die weitere Skalierung bis an die Netzwerkgrenzen, Checkpointing ohne GPU-Stillstände bei noch größerem Maßstab sowie die Optimierung für Inferenz-Workloads.