Inhaltsverzeichnis

Die physische Position der Komponenten beschreibt eine KI-Architektur nur unvollständig. Entscheidend ist der Datenfluss zwischen ihnen, und dabei sollten mindestens drei Arten von Datenbewegung getrennt betrachtet werden, weil sie unterschiedlichen Gesetzmäßigkeiten folgen. 

Quelldaten müssen den Compute erreichen 

Training, Fine-Tuning, Datenanalyse und Indexierung können große Mengen an Quelldaten verarbeiten. Liegen Compute und Daten in unterschiedlichen Infrastrukturen, müssen diese Daten übertragen, repliziert oder über ein Netzwerk zugänglich gemacht werden. Die relevante Größe ist dabei nicht die Gesamtkapazität des Datenbestands, sondern das Produkt aus der je Durchlauf verarbeiteten Datenmenge und der Häufigkeit, mit der dieser Durchlauf innerhalb eines Zeitraums stattfindet. 

Ein Datenbestand von 500 TB, der einmalig migriert wird, erzeugt deshalb ein völlig anderes Netzwerkprofil als ein wesentlich kleinerer Bestand, der kontinuierlich vollständig neu verarbeitet wird. Diese Unterscheidung wird in Architekturdiskussionen regelmäßig übersprungen, weil die Kapazitätsangabe leichter verfügbar ist als das Zugriffsprofil. [QUERVERWEIS: AI Data Lake – Konsolidierung von Datenbeständen] 

Auch innerhalb eines Rechenzentrums entsteht ein Datenpfad 

Selbst wenn Storage und GPU-Systeme am selben Standort stehen, müssen die Daten vom Storage über Netzwerkkarte und PCIe-Topologie in den System-Memory und von dort in den GPU-Memory gelangen. Bei datenintensiven GPU-Anwendungen kann dieser interne Pfad selbst zum Performancefaktor werden. 

NVIDIA GPUDirect Storage ist ein konkretes Beispiel für eine Architektur, die diesen Pfad verändert. GPUDirect Storage ermöglicht DMA-Transfers zwischen Storage und GPU-Memory und vermeidet dabei den Umweg über einen Bounce Buffer im CPU-Memory; laut NVIDIA lassen sich damit Bandbreitenengpässe entschärfen sowie Latenz und CPU-Last reduzieren. Bemerkenswert ist, dass für diese Klasse von Optimierung bislang kein herstellerübergreifender Standard existiert. Die SNIA hat im August 2025 mit Storage.AI ein herstellerneutrales Standardisierungsprojekt gestartet, das unter anderem GPU-initiierte I/O und direkten Storage-Zugriff über Herstellergrenzen hinweg adressieren soll; getragen wird es unter anderem von AMD, Cisco, Dell, IBM, Intel, NetApp, Pure Storage, Samsung, Seagate und WEKA. 

Das Beispiel zeigt ein grundsätzliches Architekturprinzip: Für KI-Workloads reicht es nicht, die Rechenleistung der GPUs zu betrachten. Auch der Datenpfad zwischen Storage und Computemuss zum Workload passen. [BILD 2: Datenpfad Storage – NIC/PCIe – System Memory – GPU Memory, mit und ohne GPUDirect Storage] 

An das Modell geht der Context, nicht der Datenbestand 

Bei Retrieval-Augmented Generation (RAG) muss zwischen den Quelldaten und dem tatsächlich an das Modell übertragenen Context unterschieden werden. In der Aufbereitungsphase werden Dokumente extrahiert, in Chunks zerlegt, als Embeddings repräsentiert und indexiert. Bei einer Anfrage wählt das Retrieval aus diesem Index die relevanten Chunks aus, aus denen der Context für das Modell zusammengestellt wird. 

Wird das Retrieval lokal betrieben und das LLM extern genutzt, müssen deshalb nicht sämtliche indexierten Quelldaten an den LLM-Service übertragen werden. Übertragen wird der für die jeweilige Anfrage zusammengestellte Context, zusätzlich zur Anfrage selbst und zu weiteren Bestandteilen des Prompts. Genau an dieser Stelle entsteht eine Architekturgrenze zwischen dem Retrieval-System und dem externen Modell, und welche Informationen diese Grenze passieren dürfen, muss Teil der Security- und Governance-Architektur sein. [BILD 3: RAG-Datenpfad mit Trust Boundary vor dem externen Model Endpoint]