Apache Spark auf GPU-Servern mit dem RAPIDS Accelerator: Anforderungen, Auslegung, Karten

Was die GPU-Beschleunigung für Spark bringt und wann sich GPU-Knoten lohnen

Apache Spark läuft auf GPUs über NVIDIAs cuDF-Plugin für Apache Spark, das laut NVIDIAs Download-Seite früher „RAPIDS Accelerator for Apache Spark“ hieß. Es führt Spark-SQL- und DataFrame-Operationen mit der Bibliothek libcudf auf der GPU aus, braucht keine Codeänderung und fällt bei jeder Operation, die es nicht unterstützt, auf die CPU zurück. GPU-Knoten lohnen sich für lange ETL- und SQL-Jobs mit Joins, Sortierungen und Aggregationen über große Parquet- oder ORC-Daten; RDD-Code, kurzen Abfragen und Jobs, die von zeilenbasierten Benutzerfunktionen bestimmt werden, helfen sie nicht.

NVIDIAs FAQ beziffert das: „Generally, for complicated queries where all the processing can run on the GPU we see between 3x and 7x speedup.“ Als gut geeignet nennt sie Aggregationen über viele verschiedene Schlüssel, Joins und Sortierungen, das Schreiben von Parquet und ORC und das Lesen von CSV. Auf der anderen Seite braucht die GPU laut FAQ rund 2 bis 3 Sekunden für die Initialisierung, wenn ein Executor zum ersten Mal startet, und GraphX und RDDs werden nicht beschleunigt, ebenso wenig APIs, die Row-Objekte oder Scala- und Java-Funktionen entgegennehmen.

Die Artefaktnamen bleiben vorerst unverändert, die Jars heißen also weiter rapids-4-spark, und die meisten Teams suchen weiter nach „Spark RAPIDS“. Dieser Leitfaden richtet sich an das Data-Engineering- und Plattformteam, das Spark auf eigenen Servern betreibt und wissen will, ob GPU-Knoten seine ETL-Jobs beschleunigen und was es kaufen soll. Für pandas und scikit-learn auf einem Rechner mit einer Karte ist unser Leitfaden zur RAPIDS-Workstation für Data Science der bessere Einstieg.

Anforderungen von Spark RAPIDS, Stand Oktober 2026

Download-Seite des NVIDIA cuDF-Plugins für Apache Spark, Release 26.08.1, gelesen am 25. Oktober 2026. Aufgeführt sind außerdem Databricks 14.3 und 17.3 ML LTS sowie Dataproc 2.1 bis 2.3.

Bei neuen Karten verdient die Treiberzeile Aufmerksamkeit. R525 ist die Untergrenze des Plugins; die Karte setzt ihre eigene. NVIDIAs Product Brief zur RTX PRO 6000 Blackwell Server Edition nennt R575 und CUDA 12.9 als Mindestversionen, ein Blackwell-Knoten läuft also mit einem aktuellen Produktions- oder Langzeit-Treiberzweig. Die RTX-PRO-Blackwell-Server-Edition-Karten, die L40S und die H200 NVL fallen unter die genannten Architekturen, stehen aber nicht auf der Liste der getesteten Modelle. NVIDIAs eigenes Handbuch zitiert ein Ergebnis von AWS mit RTX PRO 4500 Blackwell: Auf Clustern mit acht Knoten und 103 von TPC-DS abgeleiteten Abfragen bei 3 TB waren die GPU-Knoten nach 4,7 Minuten fertig, die CPU-Knoten nach 16,8 bis 17,4 Minuten. NVIDIA weist darauf hin, dass diese NDS-Ergebnisse „do not comply with the TPC-DS Specification“ und nicht mit veröffentlichten TPC-DS-Ergebnissen vergleichbar sind.

Zuerst das Qualification Tool

Lassen Sie vor dem Kauf eines GPU-Knotens NVIDIAs Qualification Tool über die Event-Logs des bestehenden CPU-Clusters laufen. Es wertet die Logs aus, sagt mit einem XGBoost-Modell namens QualX GPU-Laufzeit und Beschleunigung je SQL-Abfrage und je Anwendung voraus, listet Operatoren, die auf die CPU zurückfallen würden, und schlägt Spark-Einstellungen für die GPU vor. NVIDIA weist darauf hin, dass ein hoher Rang keine Zusicherung ist, dass eine Anwendung am meisten gewinnt.

Das Tool wird aus PyPI als spark-rapids-user-tools installiert und braucht Python 3.10 bis 3.12 und Java 8 oder neuer. Für einen Cluster im eigenen Rechenzentrum lautet der Befehl spark_rapids qualification --platform onprem, mit --eventlogs auf das Log-Verzeichnis. Eine empfohlene Clusterform liefert es nur für Cloud-Plattformen; für eigene Server ergibt sie sich aus den Regeln zur GPU-Zahl weiter unten. Die Seite zum Tool führt außerdem Iceberg-Schreiboperatoren wie MergeRows und WriteDelta als auf der GPU nicht unterstützt, was für Lakehouse-Jobs zählt.

Die Schätzung des Tools setzt einen eigenen Cluster voraus. Ein sinnvoller erster Test ist ein GPU-Server, der die am höchsten eingestuften Jobs neben dem CPU-Cluster rechnet, mit spark.rapids.sql.explain=NOT_ON_GPU, damit die Logs jede Operation zeigen, die auf der CPU geblieben ist. Wir legen GPU-Knoten nach diesem Bericht aus; schicken Sie uns seine Zusammenfassung und Ihre Spark-Version, und unser Team antwortet mit einer Konfiguration.

Ein Executor je GPU bestimmt die Clusterform

Der Tuning Guide hält fest: „The cuDF for Apache Spark plugin only supports a one-to-one mapping between GPUs and executors.“ Weder mehrere Executors je GPU noch mehrere GPUs je Executor werden unterstützt, ein Server mit acht Karten betreibt also acht GPU-Executors, einer mit vier Karten vier.

On-Premise-Leitfaden, Tuning Guide und FAQ des NVIDIA cuDF-Plugins für Apache Spark, gelesen am 25. Oktober 2026. Vollständige Eigenschaftsnamen: spark.executor.resource.gpu.amount, spark.task.resource.gpu.amount, spark.rapids.sql.concurrentGpuTasks, spark.sql.files.maxPartitionBytes.

Die FAQ ergänzt, dass die GPU meist davon profitiert, zwei Tasks gleichzeitig zu bearbeiten, und das Beispiel im Tuning Guide gibt jedem Executor 6 Kerne auf einem Knoten mit 24 Kernen und vier GPUs. Das passt zum Minimum von sechs physischen Kernen je GPU in NVIDIAs Leitfaden für NVIDIA-Certified Systems: Ein Server mit acht Karten braucht mindestens 48 Kerne, mehr, wo CPU-Stufen bleiben. Der Spark-Driver braucht keine GPU; laut FAQ bringt eine GPU am Driver keinen Vorteil.

MIG ist möglich, aber nicht der bevorzugte Betrieb des Plugins. Die FAQ antwortet, dass es funktioniert, wenn der Cluster-Manager jede MIG-Instanz einem Executor isoliert zuweist, dass es im Allgemeinen nicht empfohlen wird und auf gemeinsam genutzten Clustern von Vorteil sein kann. Unter YARN braucht MIG je nach YARN-Version zusätzliche Einrichtung.

GPU-Speicher, Pinned Memory und Spill

Der GPU-Speicher bestimmt, wie viele Daten jeder Task hält und wie viele Tasks gleichzeitig laufen. Der Tuning Guide empfiehlt als Batch-Größe min(2GiB - 1 byte, (gpu_memory - 1 GiB) / gpu_concurrency / 4). Nach unserer Rechnung mit dem angegebenen Kartenspeicher als Eingabe erreicht bei zwei gleichzeitigen Tasks jede Karte in diesem Artikel die Obergrenze von 2 GiB: Eine L4 mit 24 GB ergibt vor der Grenze (24 − 1) ÷ 2 ÷ 4 = 2,9 GiB. Bei vier gleichzeitigen Tasks fällt die L4 auf 1,4 GiB und eine RTX PRO 4500 Server Edition mit 32 GB auf 1,9 GiB, während eine Karte mit 96 GB an der Grenze bleibt. Eine größere Karte erlaubt also vor allem mehr Parallelität ohne kleinere Batches, passend zum Hinweis des Leitfadens, dass größere GPUs mehr Parallelität verkraften.

Der Arbeitsspeicher des Hosts zählt genauso. Der Pinned Pool, spark.rapids.memory.pinnedPool.size, gilt je Executor und sollte idealerweise die Eingabepartitionen der gleichzeitigen Tasks aufnehmen; vier Executors mit je 4 GB belegen 16 GB je Knoten, und unter YARN muss der Memory Overhead des Executors das abdecken. Der Spill-Speicher im Host ist standardmäßig so groß wie der Pinned Pool plus 1 GB, und der Leitfaden rät zu mehr, wenn ein Job häufig auslagert. Auslagern auf eine langsame Platte kann laut Leitfaden besonders teuer werden, ein Argument für NVMe-Laufwerke als lokale Spark-Verzeichnisse.

Das Plugin reserviert standardmäßig 640 MiB GPU-Speicher für das System und baut einen RMM-Speicherpool auf; auf einer Karte, die es mit Bibliotheken ohne RMM teilt, muss der Pool abgeschaltet werden. Für einen Knoten, der auch KI-Modelle bedient, halten MIG oder getrennte Karten beides auseinander.

Shuffle und das Netz zwischen den Knoten

Der RAPIDS Shuffle Manager hat zwei Modi. MULTITHREADED, der Standard, ist „similar to the built-in Spark shuffle“, mit mehr Threads für Kompression und Dekompression, standardmäßig 20, und bleibt mit dem External Shuffle Service von Spark kompatibel. Der UCX-Modus, gesetzt mit spark.rapids.shuffle.mode=UCX, hält Shuffle-Blöcke in einem auslagerbaren Cache aus GPU, Host und Platte und bewegt sie mit Unified Communication X: innerhalb eines Knotens von GPU zu GPU über cuda_ipc, zwischen Knoten über InfiniBand oder RoCE mit GPUDirect RDMA.

Der UCX-Modus braucht UCX 1.19.1 oder neuer auf den Hosts und in den Containern. Er verlangt, den External Shuffle Service abzuschalten und damit auch die dynamische Allokation, und NVIDIAs Tests auf Databricks liefen ohne Autoscaling. Die Klasse des Shuffle Managers muss zur Spark-Version passen, zum Beispiel com.nvidia.spark.rapids.spark353.RapidsShuffleManager für Spark 3.5.3.

Eine Mindestgeschwindigkeit der Verbindung nennt NVIDIA nicht, nur dass der Manager „relies on fast connections between executors“. Wir legen die Netzwerkkarten nach dem Shuffle-Volumen in Ihrer bisherigen Spark-Historie aus: Ein Cluster aus zwei oder drei GPU-Knoten mit schweren Joins bekommt RDMA-fähige Netzwerkkarten, ein einzelner Knoten oder ein leichter Shuffle nicht. Unser Leitfaden zu GPU-Clustern ohne InfiniBand erklärt die Variante mit RoCE.

Welche unserer Karten zu Spark passen

Jeder Spark-Executor nutzt eine Karte, und nur der UCX-Shuffle bewegt Daten zwischen den Karten; entscheidend sind also GPU-Zahl, Speicher je Karte und Leistungsaufnahme, nicht die größte Karte.

NVIDIA-Produktseiten und Datenblätter, wie in unseren Leitfäden zu den Karten aufgeführt, gelesen im September und Oktober 2026; „für Spark“ ist unsere Einschätzung nach dem Modell des Plugins mit einer GPU je Executor.

Für einen reinen ETL-Knoten empfehlen wir die RTX PRO 4500 Server Edition: Das von NVIDIA zitierte AWS-Ergebnis lief auf RTX PRO 4500 Blackwell, die Karte belegt nur einen Steckplatz, ist passiv gekühlt, und acht Karten ergeben acht Executors bei rund 2,2 kW Leistungsaufnahme nach unserer Schätzung, wie unser Leitfaden zum Server mit acht RTX PRO 4500 Server Edition herleitet. Die L4 ist die getestete Karte und die sparsamste Variante. Die RTX PRO 6000 Server Edition passt, wenn derselbe Knoten tagsüber KI-Inferenz oder Training rechnet und nachts Spark. Wir liefern alle fünf Karten in Servern auf Bestellung; nennen Sie uns Ihren Cluster-Manager und die Zahl der CPU-Knoten, auf denen Ihre Jobs heute laufen, und wir schlagen die Zahl der GPU-Knoten vor.

GPUs unter YARN und Kubernetes zuteilen

Unter YARN braucht die GPU-Zuteilung YARN 2.10 oder 3.1.1 oder neuer, für Docker wird 3.1.3 oder neuer bevorzugt. NVIDIA empfiehlt Docker mit cgroup-Isolation; ohne Isolation wird jede GPU mit nvidia-smi -c EXCLUSIVE_PROCESS in den exklusiven Prozessmodus gesetzt. Executors finden ihre GPU über das Discovery-Skript getGpusResources.sh von Spark, das auf jedem Knoten installiert ist. Im Standalone-Modus melden die Worker ihre GPUs über SPARK_WORKER_OPTS, der Master braucht keine GPU.

Unter Kubernetes fordern Executor-Pods nvidia.com/gpu-Ressourcen vom NVIDIA Device Plugin an, das der GPU Operator zusammen mit Treiber und Toolkit installiert, wie unser Leitfaden zum Teilen von GPUs in Kubernetes beschreibt. NVIDIAs FAQ rät, spark.kubernetes.executor.missingPodDetectDelta zu erhöhen, zum Beispiel auf 120000 ms, wenn Executor-Pods in Timeouts laufen.

Spark-GPU-Cluster auslegen: Konfigurationen je Knoten

Sie folgen NVIDIAs Konfigurations­leitfaden für NVIDIA-Certified Systems: mindestens sechs Kerne je GPU, Arbeitsspeicher von mindestens dem Doppelten des GPU-Speichers und zwei Sockel. Spark-Executors brauchen außerdem ihren eigenen Heap, wir addieren daher den Executor-Speicher, den Ihre CPU-Jobs heute nutzen.

Host-Mindestwerte nach unserer Rechnung aus NVIDIAs Regeln für zertifizierte Systeme; Leistungsaufnahme nach unserer Schätzung aus unseren verwandten Leitfäden (Karten plus Prozessoren plus 15 Prozent); eine Messung am gelieferten System bestätigt sie.

Die ersten drei bleiben unter den 2,94 kW, die wir je 230-V-Anschluss mit 16 A einplanen. Acht RTX PRO 4500 Server Edition brauchen ein Gehäuse mit 3U bis 5U: In Supermicros 2U-Servern sind höchstens sechs gelistet. Wir ergänzen NVMe-Laufwerke für die lokalen Spark-Verzeichnisse und Netzwerkports, die nach Ihrem Shuffle-Volumen ausgelegt sind. Unser Leitfaden zu CPU, RAM und Speicher für einen Server mit vier GPUs behandelt Prozessoren und Speicherkanäle.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration passend zu Ihrer Arbeitslast und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server auf Bestellung mit L4, RTX PRO 4500 Server Edition, L40S, RTX PRO 6000 Server Edition oder H200 NVL, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente, und installieren auf Wunsch Betriebssystem, NVIDIA-Treiber, CUDA und eine Container-Laufzeit. Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt.

FAQ