AI data storage trennt langlebige Archive von schnellem Zugriff
AI data storage muss zwei unterschiedliche Anforderungen miteinander vereinbaren: wachsende Datasets kostengünstig aufzubewahren und den kleineren, aktiven Teil schnell genug bereitzustellen, damit Grafikprozessoren (GPUs) ausgelastet bleiben. Backblaze hat ein zweistufiges Design dokumentiert, bei dem B2 Cloud Storage die dauerhafte Kopie von Datasets, abgeleiteten Dateien und checkpoints enthält, während NVIDIA AIStore häufig verwendete Daten auf lokalem Speicher in der Nähe der Rechenressourcen vorhält. Ein checkpoint ist ein gespeicherter Trainingszustand, mit dem die Arbeit später fortgesetzt oder wiederverwendet werden kann.
Das Design spiegelt wider, wie KI-Projekte Daten verwenden. Teams können Quell-Datasets, kuratierte Revisionen und aufeinanderfolgende checkpoints aufbewahren, doch ein einzelner Job liest nur eine wechselnde Teilmenge. Bei einer Änderung ihrer Parameter kann die Kuratierung erneut auf das Rohmaterial zugreifen, mehrere Entwickler können dieselbe Revision wiederverwenden und das Training kann eine Revision über viele Epochen hinweg lesen, also in vollständigen Durchläufen durch die Trainingsdaten. Das gesamte Archiv neben den GPUs zu speichern, kann teuer sein, während wiederholtes Lesen aus entferntem object storage die Leistung beeinträchtigen kann.
AIStore ist ein quelloffener, skalierbarer object store, der Daten und Anfragen bei wachsendem Bedarf auf mehrere Maschinen verteilen kann. Er kann über eine S3-compatible API, eine für die Funktionsweise von Amazon S3 ausgelegte Schnittstelle, einen entfernten B2 bucket anbinden. Bei der ersten Anfrage nach einem Objekt wird dieses aus dem entfernten system of record abgerufen. Nachfolgende Anfragen können die lokal im cache gespeicherte Kopie verwenden, solange sie verfügbar und gültig bleibt. Unterstützte S3-Anwendungen können durch Konfiguration auf den AIStore endpoint verweisen, statt ihren Code für den Speicherzugriff zu ersetzen.
Die Software bietet außerdem Funktionen für Trainings-Workloads. Ein prefetch-Job lädt eine bekannte Dataset-Revision, bevor die Verarbeitung beginnt. write-through speichert eine lokale Kopie und lädt das Ergebnis mit derselben Anfrage in den entfernten record hoch. GetBatch fasst viele kleine Objekte zu einem geordneten Stream zusammen, statt für jedes Objekt eine separate Anfrage zu stellen. In dem mehrschichtigen Design gelangen Daten von B2 über AIStore zur Anwendung und in den GPU-Speicher, wo Decodierung, Batch-Vorbereitung und Modellausführung stattfinden. Ergebnisse und checkpoints werden über AIStore zurück nach B2 übertragen.
Backblaze hat zwei Beispiel-Workflows erstellt, um dieses Muster zu demonstrieren. Das Beispiel zur Videokuratierung verwendet NVIDIA NeMo Curator, eine quelloffene, GPU-beschleunigte Bibliothek zur Vorbereitung großer Datasets für generative KI. Vollständige Durchläufe führen prefetch für Quellvideos aus, während begrenzte Durchläufe oder Durchläufe mit deaktiviertem prefetch nicht im cache vorhandene Eingaben bei Bedarf abrufen. Curator erzeugt Clips und Cosmos-Embed1 embeddings, numerische Darstellungen von Inhalten, die von KI-Systemen verwendet werden, und veröffentlicht sie anschließend über AIStore in B2. Spätere Kuratierungsdurchläufe können gültige Videos wiederverwenden, die sich noch im cache befinden.
Das Beispiel zum Robotiktraining behandelt Trainer, die ein gewöhnliches lokales Verzeichnis benötigen. NVIDIA Isaac GR00T ist ein offenes Vision-Language-Action-Modell für die Fähigkeiten humanoider Roboter. Seine Demonstrations-Datasets enthalten viele kleine Dateien, darunter Tabellen für einzelne Episoden, Kameravideos und Metadaten. Das Beispiel stellt eine Revision aus AIStore auf dem GPU-Knoten bereit, gleicht sie mit einem manifest ab, also einer Bestandsliste der erwarteten Dateien, und startet anschließend das Training, ohne den vorhandenen data loader zu ändern. checkpoints werden über AIStore in B2 veröffentlicht. Bei einer erneuten Bereitstellung dieser Revision kann die im cache gespeicherte Kopie gelesen werden, statt sie aus B2 abzurufen.
Backblaze beschreibt fünf betriebliche Regeln, um diese Ebenen unabhängig voneinander zu halten. Erstens sollte die schnelle Ebene anhand der gleichzeitig aktiven Arbeitsdaten und der wahrscheinlichen Wiederverwendung dimensioniert werden, nicht anhand des gesamten Archivs. Sie benötigt außerdem genügend freie Kapazität, damit durch prefetch geladene Daten bis zum Abschluss der Bereitstellung resident bleiben. Für entfernte buckets aktiviert AIStore standardmäßig LRU eviction. Ältere Daten werden aus dem cache entfernt, sobald die Festplattennutzung einen clusterweiten high watermark überschreitet, der standardmäßig bei 90 % liegt. Betreiber müssen diesen Schwellenwert daher auf den Workload abstimmen, statt ihn als nebensächliche Standardeinstellung zu behandeln.
Zweitens sollte prefetch verwendet werden, wenn ein vorhersehbarer Start wichtig ist. Drittens sind Dataset prefixes als nur einmal beschreibbare Speicherorte zu behandeln: Jede Revision sollte einen neuen Pfad erhalten, etwa raw/revision-001/, statt eine vorhandene Revision zu verändern. AIStore kann über versioning.validate_warm_get bei jedem Lesevorgang im cache gespeicherte Objekte auf außerhalb des Systems vorgenommene Änderungen in B2 prüfen. Eindeutige, unveränderliche prefixes vermeiden diese Prüfung bei jedem Lesevorgang für abgeschlossene Revisionen. Für Daten, die für Audits oder zur Reproduzierbarkeit aufbewahrt werden, kann B2 Object Lock verhindern, dass eine gesperrte Objektversion während ihres Aufbewahrungszeitraums gelöscht wird.
Viertens sollte mit jedem Ergebnis ein überprüfbares manifest veröffentlicht werden. Beide Beispiele kennzeichnen einen _SUCCESS.json record zunächst als ausstehend. Nachdem alle Objekte eingetroffen sind, markieren sie ihn als vollständig und erfassen für jede Datei deren Größe und SHA-256, einen kryptografischen Wert, mit dem erkannt werden kann, ob sich eine Datei geändert hat. Wenn ein Eingabe-manifest vorhanden ist, enthält die Herkunftsdokumentation der Ausgabe auch dessen hash, sodass die ursprüngliche Dataset-Revision identifiziert werden kann.
Fünftens sollten das erstmalige Laden, warm-cache-Lesevorgänge, die Verarbeitung und die Veröffentlichung getrennt gemessen werden, da jede Phase auf andere Änderungen reagiert. Die Veröffentlichung kann den größten Datentransfer verursachen: checkpoints enthalten Modellgewichte und den Zustand des Optimierers, und laut Backblaze kann selbst die GR00T-Demonstration mit 20 Schritten mehrere zehn Gigabyte veröffentlichen. Die Beispiel-Repositories vergleichen den direkten Abruf aus B2 mit cold und warm AIStore-Lesevorgängen. Ihre Integrationstests bestätigen, dass warm-Lesevorgänge keine B2 GET-Anfragen auslösen.
Auch die Grenzen für Anmeldedaten sind wichtig. Untergeordnete Curator- und GR00T-Prozesse erhalten den B2 key nicht. AIStore targets und Hilfsprogramme, die sich direkt mit B2 verbinden, benötigen ihn hingegen. Dadurch muss der Zugangsschlüssel für den entfernten Speicher nur an wenigen Stellen verteilt werden, ohne den S3-Workflow der Anwendung zu verändern.
Die Wirtschaftlichkeit hängt von der Wiederverwendung ab. Jobs, die denselben AIStore cluster nutzen, können dieselben im cache gespeicherten Objekte verwenden, ohne sie wiederholt herunterzuladen. Laut Backblaze kann dies die Lesevorgänge reduzieren, die auf das kostenlose Egress-Kontingent von B2 angerechnet werden; dieses entspricht dem Dreifachen des durchschnittlichen monatlichen Speichervolumens. Backblaze gibt außerdem an, dass Egress zu Rechenpartnern wie CoreWeave unbegrenzt kostenlos ist. Für einen einzelnen sequenziellen Durchlauf ist es jedoch einfacher, in Shards aufgeteilte Daten direkt aus B2 in den data loader zu streamen.
AIStore bleibt eine Infrastruktur, die ein Team selbst betreiben muss. Kubernetes mit ais-k8s ist eine Option für den Produktivbetrieb. write-through fügt vor jedem Upload einen lokalen Schreibvorgang hinzu, wobei Benchmarks von NVIDIA zeigen, dass dieser Mehraufwand mit zunehmender Objektgröße sinkt. Der Vorteil besteht darin, dass veröffentlichte Ergebnisse für die Wiederverwendung durch einen weiteren Job im cache bleiben. Betreiber sollten diesen Vorteil für jeden Workload gegen den zusätzlichen Aufwand beim Upload abwägen.
Für Organisationen, die eine solche Trennung von Kapazität und Leistung erwägen, bietet AEU Data europäische Cloud- und Dateninfrastruktur als Option für die zugrunde liegende Datenschicht an.