turbomotion046 - stock.adobe.com
Storage für KI: SCADA für direkten GPU-Zugriff auf Storage
SCADA entsteht als neue Speicherzugangstechnik, die GPUs direkten Zugriff auf Kapazitätsmedien erlaubt. Sie adressiert wachsende Datenmengen und feingranulare KI-Workloads.
Auf dem jüngsten globalen Summit des Open Compute Project (OCP) ging es unter anderem darum, wie KI-taugliche Storage-Infrastrukturen gestaltet sein müssen. Daran wird dort unter anderem an der Initiative Stichwort Storage-Next gearbeitet. Es handelt sich hierbei um eine Kollaborationsinitiative unter der Leitung von NVIDIA, um die Schnittstellen zwischen Speichersystemen und GPUs zu optimieren. Die konzipierte Lösung heißt SCADA.
SCADA hat im Storage nichts mit speicherprogrammierbaren Steuerungen zu tun. Hier stehen die fünf Großbuchstaben für Scaled Accelerated Data Access. Das ist das Konzept einer neue Storage-Zugangstechnologie speziell für KI-Umgebungen.
Lange standen rechenintensive Anwendungen wie LLM-Training oder Inferenz im Mittelpunkt der Aufmerksamkeit. Erstere ist insbesondere rechenintensiv. Die zweitgenannte ist zwar datenintensiv, aber vorhersehbar und die Zugriffe erfolgen vergleichsweise auf große Mengen an Daten, lassen sich also mit einer CPU bewältigen
An Bedeutung gewinnen inzwischen allerdings datenzentrierte Anwendungen, bei denen die GPU auf Daten zugreift. Die Zugriffe zielen auf relativ kleine, zufällig verteilte Datenblöcke und sind gemäß der Logik der sie auslösenden Anwendungen nicht vorhersehbar. Das betrifft etwa die Suchindizes von Vektordatenbanken, prognostische künstliche Intelligenz (KI) oder relationale Graphen.
Storage-Anforderungen steigen massiv
Einige Beispiele: Die Inferenz von Systemen aus LLM und GNN (Grafisches Neuronales Netz), also bei Systemen mit Kontextbewusstsein, braucht bis 400 TByte. LLM-RAG (Retrieval Augmented Generation) oder graphische RAG, benötigen Storage in den Petabyte-Kapazitäten. Bei relationalen Graphen können die Anforderungen schnell mehrere hundert Terabyte betragen.
Hier müssen also Datenmengen geladen werden, die nicht in den Cache der GPU passen. Wegen der unregelmäßig verteilten Zufallszugriffe werden gleichzeitig sehr viel mehr Daten in den Cache geladen als die Applikation am Ende wirklich benötigt.
Massive Steigerung bei den IOPS
Zudem haben datenintensive Apps um Dimensionen häufigere Zugriffe zwischen zwei Synchronisationspunkten als Compute-intensive Anwendungen. GPUs können aber bis zu 100.000 GPU-Threads gleichzeitig bewältigen, was allerdings eine hohe Bandbreite erfordert. Nötig ist dementsprechend eine maximale Ein-/Ausgabeleistung.
Möglichst große Seiten sind dafür nicht so wichtig. Denn während die Zugriffsgranularität beim KI-Training meist zwischen 10 MByte und 1 TByte liegt, greift eine Vektordatenbank auf Datenstücke zu, die manchmal so klein sind wie 64 Bits. Bei relationalen Graphen können sie sogar bis auf 8 Bit schrumpfen.
NAND braucht Unterseiten
Das wiederum bedeutet, dass auch bei NAND einige Veränderungen sinnvoll sind. So könnten Sub-Pages (Unterseiten) eine sinnvolle Ergänzung der bisherigen NAND-Specs sein. Außerdem müssen die NAND-Chips möglichst zuverlässig arbeiten, was die Chips verteuern dürfte.
Schließlich werden Direktzugriffe von GPU auf GPU oder von GPU auf Storage häufiger, was die Bedeutung von PCIe-Switches erhöht. In den Designs für Lernen und Inferenz von KI-Algorithmen kommunizierten meist CPUs mit GPUs über NVMe oder NIC.
Um diese Herausforderungen zu bewältigen, enthält das SCADA-Konzept, das auf der OCP-Tagung von CJ Newburn, Distinguished Engineer bei NVIDIA GPU Cloud und Vikram Mailthody, Senior Researcher bei NVIDIA Research vorgestellt wurde, zwei wesentliche Elemente.
KI-Storage soll am besten von der Rechenleistung disaggregiert werden. Weiter soll der GPU der direkte Zugriff auf die Kapazitätsmedien über eine anwendungsspezifische Schnittstelle (API) ermöglicht werden.
Logik wandert auf die GPU
Das SCADA-Konzept verlagert dabei die gesamte Logik vom Client-Request über Annahme, die Vorbereitung und die Ausführung von Requests auf die GPU, sofern es sich um feingranulare Anwendungen handelt. Weitere Voraussetzung dafür ist, dass GPUs mit NVLink und an viele Storage-Server angebunden sind, deren Daten sie nutzen können.
Ein Argument für die neue Vorgehensweise besteht auch darin, dass in einen Rechenknoten bei den genannten neuen Anwendungen gar nicht genug Speicherraum hat, um die für eine volle Ausschöpfung der Leistungsressourcen nötige Kapazität zu fassen. Denn wenn eine GPU bereits 100.000 Threads erzeugen kann, in einen Rechenknoten aber neben den CPUs auch noch acht GPUs passen, ist das zumindest bei den heutigen Speicherdichten nicht mehr möglich.
Überzeugende Testresultate
Disaggregiert man das Storage dagegen und bindet es offen für Direktzugriffe an die GPU, werden praktisch unbegrenzte Speichermengen zur Bearbeitung der Algorithmen zugänglich. Nützlich ist es für dieses Konzept auch, in PCIe-Switches eine Netzwerkkarte zu integrieren, statt sie separat vorzuhalten. Dann können GPUs über sie auch direkt interagieren.
Testdaten wurden ebenfalls präsentiert. So erreichten GPUs bei Direktzugriff über NVMe für die Indexierung von Vektordatenbanken die doppelte Leistung. Sie könnte noch gesteigert werden, wenn dem RDMA-Datenpfad mehr Bandbreite hinzugefügt wird. Die Kosten solcher Lösungen sind etwas höher, allerdings erlauben sie mehr Leistung und damit voraussehbar auch bessere Ergebnisse.
Konsequenzen: Bedeutungsverlust für die CPU
Das Konzept hat im Rahmen der Storage-Next-Initiative der OCP bereits viele Unterstützer hinter sich versammelt. Sie reichen von den Großen der Storage- und Server-Branche über Vernetzungsspezialisten bis zu Bauelementeherstellern. Intel sucht man allerdings aus naheliegenden Gründen vergeblich, auch AMD ist auf der Liste der Unterstützerfirmen nicht zu finden. Kein Wunder: Induziert das Konzept doch einen weiteren Bedeutungsverlust für die klassische CPU und weitere Bodengewinne für NVIDIA.
Kommt SCADA, werden auch die Anwender umdenken müssen: von der einseitigen Kostenoptimierung – möglichst viele TByte für möglichst wenig Geld – wird man sich verabschieden müssen. An ihre Stelle tritt eine auf möglichst viele IOPS gerichtete Optimierung der gesamten Lebensdauerkosten (TCO).
