KI-Datenpipeline-Architektur: Petabyte-Scale Training mit 100GB/s versorgen

Aktualisiert am 11. Dezember 2025

Update Dezember 2025: Metas Data PreProcessing Service (DPP) eliminiert jetzt Datenstaus in Exabyte-Scale Trainings-Clustern. WEKApod erreicht 720GB/s Durchsatz von 8 Speicherknoten für 768 H100 GPUs. PCIe Gen5 NVMe SSDs mit über 14GB/s sequentiellen Lesevorgängen werden zum Standard für Training-Tier-Speicher. Feature Stores und gestufte Caching-Architekturen reduzieren die Zugriffslatenz auf kalte Daten um das 10-fache.

Meta entdeckte, dass 56% der GPU-Zyklen im Leerlauf verbrachten und auf Trainingsdaten warteten.[^1] Das Unternehmen speichert Exabytes an Trainingsdaten in Tectonic, ihrem verteilten Dateisystem, verfügte jedoch nicht über die Speicherkapazität, um Petabyte-große Datensätze lokal bei der Training-Hardware zu halten.[^2] Die Lösung erforderte den Aufbau eines Data PreProcessing Service (DPP), der skaliert, um Datenstaus vollständig zu eliminieren. Organisationen, die große Modelle trainieren, stehen vor der gleichen grundlegenden Herausforderung: Die leistungsstärksten GPUs erreichen nichts, während sie auf Eingabedaten warten.

Der Speicher, der das KI-Training versorgt, bestimmt, ob GPU-Investitionen die erwarteten Erträge liefern. WEKApod erreicht über 720GB/s Durchsatz und 18 Millionen IOPS mit Latenzen unter 150 Mikrosekunden und versorgt 768 H100 GPUs von nur 8 Speicherknoten.[^3] Metas RSC-Supercomputer nutzt 46 Petabytes Cache-Speicher, um GPUs ausgelastet zu halten.[^4] Das Training von GPT-4 erforderte etwa 25.000 A100 GPUs, die 13 Billionen Tokens über 90-100 Tage verarbeiteten.[^5] Im großen Maßstab wird die Datenpipeline-Architektur ebenso kritisch wie die Compute-Architektur.

Die Datenpipeline-Herausforderung

Large Language Models benötigen Zugriff auf Petabytes hochwertiger, vorverarbeiteter Daten. Ohne schnellen, zuverlässigen Speicher stehen selbst die leistungsstärksten GPUs im Leerlauf und warten auf Eingaben.[^6] Die Performance-Tier der Speicherinfrastruktur ermöglicht den nahtlosen Datenfluss durch rechenintensive Pipeline-Stufen: Normalisierung, Tokenisierung und Training.

Eine typische Machine-Learning-Pipeline umfasst Datenvorverarbeitung durch CPUs, Modelltraining auf GPUs und Nachbearbeitung wieder auf CPUs.[^7] Engpässe entstehen beim Datentransfer zwischen CPU-RAM und GPU-DRAM. Die Diskrepanz zwischen Speicherdurchsatz, Netzwerkbandbreite, Vorverarbeitungs-Compute und GPU-Verbrauch erzeugt Staus, die teure Beschleuniger-Kapazität verschwenden.

Metas Datenspeicher- und Ingestion-Architektur

Metas End-to-End-DSI-Pipeline besteht aus einem zentralen Data Warehouse auf verteiltem Speicher und einem Data PreProcessing Service, der die Vorverarbeitung unabhängig vom Training-Compute skaliert.[^8] Die Architektur trennt Speicher, Vorverarbeitung und Training in separate skalierbare Tiers.

Tectonic dient als Metas Exabyte-Scale verteiltes Dateisystem und bietet disaggregierte Speicherinfrastruktur für KI-Trainingsmodelle.[^9] Das Unternehmen trainiert Modelle auf Terabyte- bis Petabyte-großen Datensätzen ohne lokale Speicherkapazität, die diesen Größenordnungen entspricht. Disaggregierter Speicher ermöglicht flexible Ressourcenzuweisung, erfordert jedoch Hochbandbreiten-Netzwerke, die Speicher und Compute verbinden.

Der DPP Master empfängt Session-Spezifikationen mit Datensatz-Tabellen, Partitionen, erforderlichen Features und Transformationsoperationen.[^10] Der Master teilt Vorverarbeitungs-Workloads über Petabytes von Daten in unabhängige, eigenständige Arbeitseinheiten namens Splits auf. DPP Workers fordern Splits vom Master an und führen Vorverarbeitungs-Transformationen aus, wodurch der Vorverarbeitungsdurchsatz von der CPU-Kapazität der Training-Nodes entkoppelt wird.

Speicherhierarchie und Caching

Meta entwickelt gestaffelte Speicherlösungen, die HDDs und SSDs kombinieren, wobei SSDs als Caching-Tier für häufig verwendete Features dienen.[^11] Nicht alle Trainingsdaten erfordern die gleichen Zugriffsmuster: Häufig abgerufene Features profitieren von Flash-Speicher, während kalte Daten auf kapazitätsoptimierten Medien verbleiben.

Die Caching-Strategie reduziert Speicherkosten ohne Einbußen beim Training-Durchsatz. Heiße Daten in schnellen Tiers bedienen die Mehrheit der Lesevorgänge, während kalte Daten während der ersten Epochen aus dem Kapazitätsspeicher gestreamt werden. Das Verständnis von Datenzugriffsmustern ermöglicht intelligente Tiering-Entscheidungen, die Kosten und Performance ausbalancieren.

Speichertechnologien für KI-Training

Verschiedene Speichertechnologien erfüllen unterschiedliche Rollen in KI-Datenpipelines. Die Wahl hängt von Zugriffsmustern, Kapazitätsanforderungen und Budgetbeschränkungen ab.

Parallele Dateisysteme

Parallele Dateisysteme wie Lustre und GPFS liefern extreme Leistung mit massiver Parallelität und eignen sich ideal für synchrone I/O-intensive KI-Workloads.[^12] Diese Systeme verteilen Daten über viele Speicherserver und bieten aggregierte Bandbreite, die mit der Serveranzahl skaliert.

Google Cloud bietet Managed Lustre als Hochleistungs-Cache über Cloud Storage an und beschleunigt KI-Workloads, die extrem hohen Durchsatz und niedrige I/O-Latenz erfordern.[^13] Organisationen importieren und exportieren Daten zwischen Managed Lustre und Cloud Storage und nutzen das parallele Dateisystem als Performance-Tier für aktives Training, während Daten im Object Storage für Langlebigkeit aufbewahrt werden.

NVMe-Speicher

PCIe Gen5 NVMe SSDs überschreiten 14 GB/s sequentiellen Lesedurchsatz und bewältigen Millionen zufälliger Lese-IOPS.[^14] Die Technologie eliminiert Speicher als Engpass beim Training von KI-Modellen auf mehreren zehn Terabytes an Daten. Die PCIe Gen5-Einführung 2024-2025 verdoppelte den Durchsatz pro Lane auf etwa 4 GB/s pro Lane und erreicht 64 GB/s in x16-Konfigurationen.

NVMe-oF (NVMe over Fabrics) erweitert die NVMe-Performance über Netzwerke und ermöglicht disaggregierte Speicherarchitekturen, die nahezu lokale Latenzen beibehalten. Training-Cluster greifen auf gemeinsame NVMe-Speicherpools zu, ohne die Performance-Vorteile direkt angeschlossener Laufwerke zu opfern.

Object Storage für kalte Daten

Object Storage bietet kosteneffiziente Kapazität für Petabyte-große Datensätze, die höhere Latenzen tolerieren. Ein großes E-Commerce-Unternehmen speichert Hunderte von Petabytes an Trainingsdaten in AWS S3, wobei KI/ML-Training-Workloads über mehrere AWS-Regionen und On-Premises-Rechenzentren verteilt sind.[^15]

Object Storage funktioniert am besten für Batch-Ingestion-Muster, bei denen Training-Jobs Daten in schnellere Tiers laden, bevor die intensive Verarbeitung beginnt. Die Wirtschaftlichkeit favorisiert Object Storage für Archivierung und Backup, während Performance-Tiers das aktive Training-I/O bewältigen.

Vorverarbeitung im großen Maßstab

Datenvorverarbeitung verbraucht erhebliche Compute-Ressourcen und wird oft zum Engpass, der die volle GPU-Auslastung verhindert. Metas Erfahrung zeigte, dass CPUs auf Trainer-Nodes Daten nicht schnell genug vorverarbeiten konnten, um GPUs zu versorgen, was die verteilte DPP-Architektur motivierte.[^16]

Verteilte Vorverarbeitungs-Worker

Die DPP-Architektur skaliert Vorverarbeitungs-Worker unabhängig von Training-Nodes.[^17] Das Hinzufügen von Vorverarbeitungskapazität erfordert nur das Hinzufügen von Worker-Instanzen, nicht die Modifikation der Training-Infrastruktur. Die Trennung ermöglicht es Organisationen, die Vorverarbeitungs-Compute-Ressourcen für spezifische Datensätze und Transformationskomplexität richtig zu dimensionieren.

Worker-Instanzen führen Transformationsoperationen einschließlich Bereinigung, Normalisierung, Tokenisierung und Feature-Extraktion aus. Komplexe Transformationen erfordern mehr Vorverarbeitungs-Compute pro Training-Durchsatzeinheit. Einfache Transformationen können mit minimalen Vorverarbeitungsressourcen mit dem Training Schritt halten.

Beschleunigte Vorverarbeitung

Branchenbemühungen führen zunehmend Vorverarbeitungs-Transformationsoperationen auf Beschleunigern statt auf CPUs aus.[^18] NVIDIA DALI (Data Loading Library) verlagert Bilddekodierung, Augmentation und Formatkonvertierung auf GPUs. Beschleunigte Vorverarbeitung eliminiert CPU-Engpässe für Bild- und Video-Training-Pipelines.

Die Verlagerung der Vorverarbeitung auf GPUs erfordert sorgfältiges Pipeline-Design, um keine neuen Engpässe zu erzeugen. GPU-Speicher, der für die Vorverarbeitung verwendet wird, reduziert den für Modellparameter und Aktivierungen verfügbaren Speicher. Der Kompromiss zwischen Vorverarbeitungsbeschleunigung und Training-Kapazität hängt von den Workload-Charakteristiken ab.

Feature Stores

Google empfiehlt die Verwendung von Vertex AI Feature Store für Features, die für Online-Serving bereit sind.[^19] Feature Stores berechnen und cachen Feature-Werte vor und eliminieren wiederholte Berechnungen über Training-Läufe hinweg. Das Planen von Feature-Engineering-Jobs zur regelmäßigen Berechnung neuer Feature-Werte in der erforderlichen Kadenz stellt frische Daten ohne Echtzeit-Vorverarbeitungs-Overhead sicher.

Feature Stores erweisen sich als besonders wertvoll für Empfehlungsmodelle, bei denen die Feature-Berechnungskomplexität die Zeitbudgets pro Anfrage überschreitet. Training und Inferenz können beide auf die gleichen vorberechneten Features zugreifen und so Konsistenz zwischen Entwicklung und Produktion gewährleisten.

Netzwerkarchitektur für Datenpipelines

Hochbandbreiten-Interconnects bilden die Grundlage für disaggregierte Speicherarchitekturen. InfiniBand und RoCE (RDMA over Converged Ethernet) liefern ultraniedrige Latenz und hohen Durchsatz, die für verteiltes Training über GPU-Cluster und schnellen Datensatzzugriff unerlässlich sind.[^20]

Speichernetzwerk-Design

Speichernetzwerke müssen den aggregierten Lesedurchsatz an den GPU-Training-Verbrauch anpassen. Ein Cluster von 1.000 H100 GPUs, der einen datenintensiven Workload trainiert, kann mehrere zehn Gigabytes pro Sekunde an anhaltendem Speicherdurchsatz erfordern. Die Netzwerkkapazität zwischen Speicher- und Compute-Tiers muss diese Anforderung mit Reserven für Burst-Muster überschreiten.

Die Netzwerktopologie beeinflusst den erreichbaren Durchsatz. Fat-Tree-Topologien bieten volle Bisektionsbandbreite, kosten aber mehr als überzeichnete Designs. Training-Workloads mit schwerem Speicher-I/O profitieren von nicht-blockierenden Fabrics, die Netzwerküberlastung als Engpass eliminieren.

Datentransfer-Optimierung

Datentransfer-Optimierungstechniken einschließlich parallelem I/O, Prefetching, Caching, Kompression und Datenlokalitäts-Optimierung gewährleisten effiziente Datenbewegung zwischen Speichersystemen und Compute-Nodes.[^21] Prefetching antizipiert Datenanforderungen und stellt Daten bereit, bevor Compute-Nodes sie anfordern. Kompression reduziert Netzwerkbandbreiten-Anforderungen auf Kosten von Compute-Zyklen.

Batching von Daten reduziert die Transaktionshäufigkeit und amortisiert den Overhead pro Anfrage über größere Transfers.[^22] Filterung von Daten minimiert die Stichprobengröße vor dem Senden an GPUs und reduziert sowohl Speicherlesevorgänge als auch Netzwerktransfers. Die Kombination von Techniken kann die effektiven Speicherbandbreiten-Anforderungen erheblich reduzieren.

Aufbau von Datenpipelines im großen Maßstab

Organisationen, die Petabyte-Scale Training-Infrastruktur einsetzen, benötigen integrierte Ansätze für Speicher, Vorverarbeitung und Netzwerk, die der GPU-Compute-Kapazität entsprechen.

Kapazitätsplanung

Die Speicherkapazitätsplanung muss das Wachstum der Trainingsdaten neben der Modellskalierung berücksichtigen. Training-Datensätze wachsen, während Organisationen mehr Daten ansammeln und größere Modelle mit mehr Tokens anstreben. Kapazitätsanforderungen kumulieren, wenn Organisationen mehrere Datensatzversionen für Reproduzierbarkeit aufbewahren.

Die Durchsatzplanung erweist sich als anspruchsvoller als die Kapazitätsplanung. Die Beziehung zwischen Modellgröße, Batch-Größe und Datendurchsatz-Anforderungen variiert je nach Architektur und Training-Konfiguration. Das Benchmarking spezifischer Workloads auf der Zielinfrastruktur liefert die zuverlässigsten Durchsatzanforderungen.

Infrastruktur-Deployment-Expertise

Die Komplexität der Datenpipeline-Infrastruktur entspricht oder übertrifft die Komplexität der Compute-Infrastruktur. Speichersysteme, Hochgeschwindigkeitsnetzwerke und Vorverarbeitungsdienste müssen nahtlos mit GPU-Clustern integriert werden. Konfigurationsfehler in jeder Komponente erzeugen Engpässe, die GPU-Investitionen verschwenden.

Introls Netzwerk von 550 Field Engineers ist auf die integrierten Infrastruktur-Deployments spezialisiert, die großangelegtes KI-Training erfordert.[^23] Das Unternehmen belegte Platz 14 auf der Inc. 5000-Liste 2025 mit 9.594% Dreijahreswachstum, was die Nachfrage nach professionellen Infrastrukturdiensten widerspiegelt.[^24] Organisationen, die Training-Cluster aufbauen, profitieren von Deployment-Expertise, die Speicher, Netzwerk und Compute als integriertes System adressiert.

Das Management von Deployments, die 100.000 GPUs mit über 64.000 Kilometern Glasfaser-Netzwerkinfrastruktur erreichen, erfordert eine operative Größenordnung, die den größten Training-Initiativen entspricht.