Der Wettlauf um den Aufbau einer verteilten GPU-Laufzeit

NVIDIA und AMD befinden sich in einem intensiven Wettlauf, um die Herausforderungen der Datenbewegung auf Cluster-Ebene zu bewältigen. In den letzten zehn Jahren haben GPUs bemerkenswerte Geschwindigkeitsvorteile bei der Datenverarbeitung geliefert. Doch die Datenmengen wachsen weit über die Kapazität eines einzelnen GPU-Servers hinaus. Wenn die Arbeit über den lokalen Speicher oder VRAM einer GPU hinausgeht, treten versteckte Kosten auf: das Überlaufen zum Host, das Verschieben über Netzwerke und das Leerlaufen von Beschleunigern. Bevor wir uns den neuesten Bemühungen um verteiltes Rechnen bei NVIDIA und AMD zuwenden, lassen Sie uns schnell klären, was verteiltes Rechnen ist, wie es funktioniert und warum es so herausfordernd ist.

Verteiltes Rechnen und Laufzeiten auf GPUs

Verteiltes Rechnen koordiniert Berechnungsaufgaben über Rechenzentren und Servercluster hinweg, die GPUs, CPUs, Speicherebenen und Netzwerke nutzen, um einen einzelnen Job schneller oder in größerem Maßstab auszuführen, als es ein einzelner Knoten bewältigen kann. Wenn ein einzelner Server Ihre Daten nicht halten oder verarbeiten kann, teilen Sie die Arbeit auf mehrere Server auf und führen Teile parallel aus. Wenn der Job echte verteilte Algorithmen erfordert, nicht nur trivial parallelisierbare unabhängige Aufgaben, ist eine leistungsfähige Datenbewegung unerlässlich. Datensätze und Modelle haben die Speicherkapazität einer einzelnen GPU überschritten. Sobald dies geschieht, wird die Geschwindigkeit weniger durch die rohe Rechenleistung als vielmehr durch die Geschwindigkeit, mit der Daten zwischen GPUs, CPUs, Speicher und dem Netzwerk bewegt werden, begrenzt. Mit anderen Worten, auf Rechenzentrumsgröße ist der Engpass die Datenbewegung, nicht die FLOPS.

Eine verteilte Laufzeit ist die Systemsoftware, die einen Cluster wie einen Computer agieren lässt. Sie plant den Job, entscheidet, wo jedes Stück Arbeit ausgeführt werden soll, und bewegt Daten, damit GPUs nicht untätig bleiben. Eine gute Laufzeit platziert Aufgaben dort, wo die Daten bereits sind (oder bald sein werden), überlappt Berechnungen mit I/O, sodass Kerne weiterlaufen, während Bytes abgerufen werden, wählt effiziente Pfade für diese Bytes (NVLink, InfiniBand/RDMA, Ethernet; komprimiert oder nicht) und verwaltet mehrere Speicherebenen absichtlich (GPU-Speicher, gepinnter Host-RAM, NVMe, Objektspeicher) und hält den Durchsatz stabil, selbst wenn einige Arbeiter langsamer werden oder ausfallen.

Die Herausforderungen bei der Datenbewegung

Diese Aufgabe ist schwierig, da reale Datensätze verzerrt sind, sodass einige Partitionen die Wand-Uhr-Zeit dominieren können, es sei denn, die Laufzeit erkennt und mildert sie. Netzwerke sind geteilt und unvollkommen, was bedeutet, dass Staukontrolle, Rückdruck und Kompressionsentscheidungen ebenso wichtig sind wie die Wahl des Kerns. Multi-Tier-Speicher führt zu Fragmentierungs- und Evakuierungsproblemen, die einfache Allokations-/Freigabestrategien nicht bewältigen können. Eine heterogene Infrastruktur mit gemischten GPU-Generationen, Interconnects und Cloud-Objektspeichern kann statische Pläne beeinträchtigen und die Laufzeit zwingen, während des Betriebs anzupassen. Wenn die Laufzeit bei der Schätzung von Partitionsgrößen, Platzierung oder Vorababruf falsch liegt, warten GPUs auf Eingaben. Auf Rechenzentrumsgröße summieren sich viele kleine Verzögerungen zu großen Verzögerungen. Und Verzögerungen sind verlorene Einnahmen und Produktivität.

NVIDIA und die verteilten Laufzeiten

NVIDIA versucht seit über einem Jahrzehnt, dieses Problem zu lösen, und AMD zieht nach. Zu den Initiativen von NVIDIA gehören unter anderem GPU-beschleunigtes Spark mit UCX-Shuffle und expliziten Spill-Kontrollen, Dask-gestützte Multi-Node RAPIDS und “Drop-in-distributed” Python über Legate/Legion, die alle durch MagnumIOs UCX und GPUDirect Storage miteinander verbunden sind. Es gibt sogar etwas Geheimnisvolles um das neueste verteilte Projekt von NVIDIA, das als CUDA DTX bekannt ist, das als Roadmap-Element auf der NVIDIA GTC 2025 erwähnt wurde. CUDA Distributed eXecution oder DTX ist eine einzelne Laufzeit, die über Hunderttausende von GPUs läuft. Auch wenn es sich offensichtlich noch in der Entwicklung befindet, zeigt es erneut, wie NVIDIA versucht, eine der schwierigsten Herausforderungen im beschleunigten Rechnen zu lösen – die Datenbewegung im großen Maßstab.

Beispiele für die verteilten Laufzeiten von NVIDIA

Warum investiert NVIDIA in verteilte Laufzeiten?

Kurz gesagt, um einen Software-Schutzwall zu schaffen. CUDA-X ist die Sammlung von GPU-beschleunigten Bibliotheken, SDKs und Cloud-Mikrodiensten von NVIDIA, die auf CUDA basieren und Datenverarbeitung, KI und HPC abdecken. Es ist die mittlere Schicht, die Frameworks aufrufen, damit der Code schnell auf den GPUs von NVIDIA läuft. CUDA-X ist das Herzstück der Full-Stack-Strategie von NVIDIA und der Grund, warum es die Lieblingsfolie von NVIDIA-CEO Jensen Huang bei GTC ist. Aber wenn CUDA-X der Kern von NVIDIAs Software ist, sind verteilte Laufzeiten die Systeme, die es erfolgreich auf Rechenzentrumsgröße machen. Während CUDA-X die Operationen schnell macht, sorgen verteilte Laufzeiten dafür, dass Systeme schnell sind.

CUDA-X-Bibliotheken hängen von gut abgestimmten CUDA-Primitiven und Kernen ab, um Leistung zu erzeugen, aber auf Clustergröße ist es die Datenbewegung, die am meisten zählt. Das ist der Job der verteilten Laufzeiten, der Systemebene, die entscheidet, wo CUDA-X-Operationen ausgeführt werden und wie Daten zwischen GPUs, Knoten, über das Netzwerk und zu und von Speicher bewegt werden. Berücksichtigen Sie Operationen wie Shuffles, Joins, KV-Cache-Transfers und Vorababruf/Spill zwischen HBM, Host-RAM, NVMe und Objektspeichern sowie Stau auf NVLink/InfiniBand/Ethernet. Es ist die Koordination der Arbeit, die kompliziert wird, und da die Datenverarbeitungsbereitstellungen auf Multi-Node und Multi-Rack wachsen, bestimmen Laufzeitentscheidungen zunehmend die End-to-End-Leistung.

RAPIDS als Kern von CUDA-X Datenverarbeitung

Es lässt sich stark argumentieren, dass RAPIDS cuDF/RAPIDS libcudf den CUDA-X-Datenverarbeitungsstapel von NVIDIA antreibt, von ETL (NVTabular) und SQL (BlazingSQL) bis hin zu MLOps/Sicherheit (Morpheus) und Spark-Beschleunigung (cuDF-Java). In den letzten sieben Jahren hat libcudf einen Großteil der Softwareentwicklung von NVIDIA im Bereich Datenverarbeitung katalysiert, sodass höherstufige Bibliotheken dieselben spaltenbasierten Primitiven, Netzwerk- und I/O-Pfade wiederverwenden können.

AMD verfolgt einen ähnlichen Ansatz

AMD rekonstruiert das CUDA-X/RAPIDS-Muster über HIP und ROCm-DS. HIP bietet Quellkompatibilität mit CUDA, und hipDF zielt darauf ab, die RAPIDS cuDF-API zu spiegeln, sodass verteilte Laufzeiten AMD-GPUs mit minimalen Änderungen anvisieren können. Heute ist hipDF noch in einem frühen Stadium mit begrenzter Operatorabdeckung, keiner Abfrageplanoptimierung oder realer Validierung. In seinem aktuellen Zustand stellt AMDs hipDF keine Bedrohung für NVIDIAs Marktanteil im Bereich der beschleunigten Datenverarbeitung dar, aber wenn es weiterhin in das ROCm-DS-Ökosystem investiert und eine gute Strategie für verteiltes Rechnen entwickelt, könnte es NVIDIAs Schutzwall erodieren.

Theseus: Datenbewegung als erste Bürgerin

Voltron Datas Theseus ist so konzipiert, dass die “Datenbewegung zuerst” kommt, sodass die Leistung nicht signifikant über den GPU-Speicher hinaus abnimmt wie bei anderen Systemen. Die Ingenieure, die RAPIDS und BlazingSQL ins Leben gerufen haben, verantwortlich für die spaltenbasierte/cuDF-Arbeit, die CI/CD und das Packaging, das RAPIDS nutzbar gemacht hat, und die frühe Erfahrung mit verteilten SQL-Engines, sind dieselben Personen, die Voltron Data gegründet und Theseus entwickelt haben. Wir wissen genau, wo NVIDIAs Stärken im Einzelknoten enden und wo verteilte Laufzeiten beginnen, Schwierigkeiten zu haben. Das kürzlich veröffentlichte Theseus-Papier “Theseus: A Distributed and Scalable GPU-Accelerated Query Processing Platform Optimized for Efficient Data Movement” beschreibt die Kernherausforderung: Auf OLAP-Skala sind die meisten der schwierigen Probleme, wann, wo und wie Daten zwischen GPU, Host-Speicher, Speicher und dem Netzwerk bewegt werden. Wenn diese Operationen sequenziell ablaufen, hebt die Kosten der Datenbewegung den Nutzen der GPUs auf. Theseus ist speziell darauf ausgelegt, diese Latenzen zu verbergen, während die Beschleuniger beschäftigt bleiben.

Theseus hat das Datenbewegungsproblem gelöst

Theseus hat sich in großem Maßstab bewährt (siehe Benchmarks). Auf Cloud-Clustern, die nach Kosten normalisiert sind, übertrifft Theseus Databricks Photon in jeder Größenordnung und wächst auf 4X schneller bei der größten Größe. Es schließt auch TPC-H/DS bei 100 TB mit so wenigen wie zwei DGX A100 640 GB Knoten ab, d.h. 80X über den verfügbaren GPU-Speicher hinaus, was weiter beweist, dass Spill und Bewegung absichtlich und effizient behandelt werden. Vor Ort lieferte es einen ungefähr 2X Geschwindigkeitsvorteil gegenüber der Basislinie durch die Implementierung von gepinnten Puffern mit den richtigen Netzwerkeinstellungen. In der Cloud hat eine benutzerdefinierte Objektspeicher-Datenquelle plus Byte-Bereich-Vorabladung die Laufzeiten im Vergleich zu einem Standard-S3-Reader erheblich verkürzt.

Theseus ist absichtlich auf offenen spaltenbasierten Standards (Apache Arrow) aufgebaut und verwendet eine komposable Laufzeitphilosophie, sodass es in moderne Planer und APIs integriert werden kann, ohne den Kern neu zu konstruieren. Während es heute SQL bedient, erstreckt es sich auch auf KI/ML-Pipelines über UDFs. Theseus Query Profiler liefert betriebliche Sichtbarkeit. Theseus liefert sein eigenes Profiler/Observability, sodass Teams die Berechnung, Datei-I/O, Speicherauslastung und Netzwerknutzung pro Phase mit geringem Overhead sehen können, was es praktisch macht, die Datenbewegung zu optimieren, anstatt zu raten.

Fazit

NVIDIA und AMD sind beide im Wettlauf, um die Datenbewegung auf Cluster-Ebene zu lösen. Theseus ist die erste verteilte Laufzeit, die Bewegung in den Mittelpunkt von Planung, Speicher und I/O stellt und dann den Nutzen mit Benchmark-Ergebnissen beweist. Wenn Sie eine verteilte Laufzeit für datenzentrumsweite Analysen und KI benötigen, die offen, komposable und bereits auf CUDA und ROCm läuft, ist Theseus die Lösung.

Quellenliste:

• Quelle: The Race to Build a Distributed GPU Runtime
• Data Analytics are Faster on GPUs – Here’s Why
• Theseus: A Distributed and Scalable GPU-Accelerated Query Processing Platform Optimized for Efficient Data Movement
• Alleviating S3 Bottlenecks
• Theseus Benchmarks