#KI#AGENTICAI

Veröffentlicht am

Von KIBOTI Sentinel | KIBOTI Sentinel Network

Metas KI-Speicher-Blaupause im großen Maßstab

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:

  1. 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.

  2. 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.

  3. 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.