RAPIDS auf einer NVIDIA-RTX-PRO-Blackwell-Workstation: cuDF, cuML und XGBoost auf der GPU

Was RAPIDS auf einer Workstation leistet

RAPIDS ist NVIDIAs Sammlung quelloffener Python-Bibliotheken für Data Science auf der GPU: cuDF für Dataframes, cuML für klassisches maschinelles Lernen und die Integrationen, mit denen Code für pandas, scikit-learn und XGBoost auf einer NVIDIA-Karte läuft. Auf einer RTX-PRO-Blackwell-Workstation lohnt es sich, wenn die Daten Millionen Zeilen haben und in den Kartenspeicher passen oder fast passen; bei kleinen Tabellen kann die CPU schneller bleiben, weil das Verschieben der Daten auf die GPU mehr kostet, als es bringt.

Die beiden Einstiege brauchen keine Codeänderung. cudf.pandas wird mit %load_ext cudf.pandas in Jupyter oder python -m cudf.pandas auf der Kommandozeile geladen; danach importiert import pandas ein Proxy-Modul, und Operationen laufen laut Dokumentation „on the GPU where possible and on the CPU otherwise“. cuml.accel macht dasselbe für scikit-learn, UMAP und HDBSCAN, geladen mit python -m cuml.accel oder %load_ext cuml.accel vor den übrigen Imports, und fällt „transparently“ auf die ursprüngliche CPU-Implementierung zurück, wenn ein Schätzer oder eine Operation nicht beschleunigt werden kann. XGBoost hat einen eigenen GPU-Pfad, gesetzt mit einem Parameter.

Diese Seite richtet sich an Data-Science-Teams, die eine Workstation-Karte wählen. Sprachmodelle auf einer Workstation behandelt unser Leitfaden zur besten Workstation-GPU für KI.

Anforderungen, Stand Oktober 2026

Installationsanleitung von RAPIDS (jetzt unter docs.nvidia.com/datascience), Dokumentation von cuDF (Doku-Version 26.12), Dokumentation von XGBoost und die Repositorys von cuDF und cuML, gelesen am 24. Oktober 2026.

Die Installationsanleitung bietet conda, pip und Docker an. Die pip-Pakete kommen aus NVIDIAs Paketindex mit einem Suffix für die CUDA-Hauptversion, cudf-cu12 oder cudf-cu13, und der Release-Auswähler der Anleitung erzeugt den genauen Befehl für jede Kombination. Blackwell nennt die Anleitung nicht; ihre Schwelle von Compute Capability 7.0 deckt die 12.0 jeder RTX-PRO-Blackwell-Karte ab. Für eine neue Workstation mit diesen Karten würden wir die CUDA-13-Pakete auf einem Treiber aus dem Zweig R580 installieren, der das Minimum 580.65.06 erfüllt und bis Juni 2028 langfristig unterstützt wird, wie unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt.

Wie viel GPU-Speicher Ihre Daten brauchen

Ein Dataframe auf der GPU speichert jede Spalte als zusammenhängendes Array, seine Größe folgt also aus Zeilen, Spalten und Datentypen. Eine Tabelle mit 100 Millionen Zeilen und 20 Spalten mit 64-Bit-Gleitkommazahlen belegt 16 GB (14,9 GiB); eine Milliarde Zeilen mit 10 solchen Spalten 80 GB (74,5 GiB). 32-Bit-Spalten statt 64-Bit, wo die Genauigkeit reicht, halbieren das. Joins, Aggregationen und Sortierungen brauchen zusätzlichen GPU-Speicher für Zwischenergebnisse; planen Sie die Karte daher für ein Vielfaches der Eingabe, nicht für die Eingabe allein.

Unsere Rechnung: Zeilen × Spalten × 8 Byte. „Knapp“ heißt, die Eingabe passt, der Speicher für Zwischenergebnisse von Joins und Sortierungen womöglich nicht; RTX PRO 4500 (32 GB), RTX PRO 5000 72 GB und RTX PRO 6000 Max-Q (96 GB) laut NVIDIAs Produktseiten.

Drei Mechanismen helfen bei Daten, die nicht passen:

1. Managed Memory in cudf.pandas. Laut Dokumentation nutzt cudf.pandas „a managed memory pool by default“ mit Prefetching, was „enables oversubscribing GPU memory“; Daten größer als der GPU-Speicher laufen damit „in many cases, without CPU (Pandas) fallback“. Der Modus wird mit CUDF_PANDAS_RMM_MODE gesetzt: standardmäßig managed_pool, sonst managed, async, pool oder cuda. Unter WSL2 unterstützt Managed Memory keine Überbelegung, und cudf.pandas ist auf die physische Größe des GPU-Speichers begrenzt.
2. Dask mit Dask-CUDA. Der Leitfaden zu Dask-cuDF empfiehlt LocalCUDACluster auf einer einzelnen Maschine, „No matter how many GPUs are available on the machine (even one!)“, Partitionen „between 1/32 and 1/8 the memory capacity of a single GPU“ (1/32 bis 1/16 für große Sortierungen und Joins), einen RMM-Pool je Worker, etwa rmm_pool_size=0.9, und das native Spilling von cuDF mit enable_cudf_spill=True. Übersteigen die Daten den GPU-Speicher, gilt laut Leitfaden: „the bottleneck is typically device-to-host memory spilling“.
3. Das komprimierte Format von XGBoost. XGBoost speichert die Trainingsdaten auf der GPU in einem quantisierten ELLPACK-Format, das „will commonly use 1/4 the space of a CSR matrix stored in floating point“, belegt Speicher für Zwischenergebnisse „proportional to the number of rows“ und rät bei Speichermangel zuerst zu xgboost.QuantileDMatrix.

Nach dem Dask-Leitfaden nimmt eine 72-GB-Karte Partitionen von 2,25 bis 9 GB und eine 96-GB-Karte von 3 bis 12 GB, nach unserer Rechnung. Spilling verschiebt Daten in den Systemspeicher; eine Data-Science-Workstation braucht daher mehr Hauptspeicher, als die Karte hat. Wir planen mindestens das Doppelte des GPU-Speichers, das Verhältnis, das NVIDIAs Leitfaden für zertifizierte Systeme bei Servern vorgibt. Schicken Sie uns die Größe Ihrer größten Tabelle und die Operationen darauf; unser Team antwortet mit Karte und Hauptspeicher, die sie tragen.

cudf.pandas im Alltag: Rückfall und Grenzen

cudf.pandas „supports 100% of the Pandas API“, so die Dokumentation, indem es unterstützte Operationen auf der GPU und den Rest in pandas auf der CPU ausführt. Daten wandern zwischen Host und Gerät „only when necessary“; eine Pipeline, die oft zurückfällt, verbringt ihre Zeit also mit Kopien. Der Profiler zeigt, welche Funktionen auf der GPU und welche auf der CPU liefen, und ist der erste Blick, wenn ein Notebook langsamer ist als erwartet.

Die FAQ nennt die Grenzen, die in der Praxis zählen:

• unterstützt wird nur pandas 2; cuDF 24.02 war das letzte Release für pandas 1.5
• kleine Daten können auf der GPU langsamer sein als auf der CPU, wegen der Kosten der Datenübertragung; die Bibliothek glänzt ab 10.000 bis 100.000 Zeilen
• globale Variablen lassen sich während des CPU-Rückfalls lesen, aber nicht ändern
• mit normalem pandas gepickelte Objekte lassen sich unter cudf.pandas nicht entpickeln
• es „is not designed for distributed or out-of-core computing (OOC) workflows today“; dafür verweist die FAQ auf Dask und Apache Spark
• die meisten Drittbibliotheken, die pandas nutzen, funktionieren damit; Funktionen, die pandas fehlen, etwa der .list-Accessor von cuDF, brauchen cuDF direkt

Eine reproduzierbare veröffentlichte Messung von cudf.pandas auf RTX-PRO-Blackwell-Karten haben wir nicht gefunden. NVIDIAs Benchmark-Seite zu cuDF beschreibt, wie sich der Benchmark für datenbankähnliche Operationen und PDS-H mit Skalierungsfaktor 50, „roughly 50GB of data“, wiederholen lassen, nennt im Text aber keine Zeiten; NVIDIAs Blog vom September 2024 spricht von „up to 100x“ mit einer RTX 6000 Ada, ohne CPU oder Datensatz zu nennen. Der faire Test ist Ihr eigenes Notebook mit Ihren eigenen Daten, einmal mit und einmal ohne %load_ext cudf.pandas.

cuML und XGBoost auf der GPU

cuml.accel deckt Schätzer von scikit-learn sowie UMAP und HDBSCAN ab. Ob ein Schätzer auf der GPU läuft, „can depend on parameters, input types, methods, or library versions“; das Projekt hat die Beispielgalerie von scikit-learn damit geprüft und hält fest: „This does not mean that every operation runs on the GPU“. Wie bei cudf.pandas zeigt ein Profil eines echten Laufs, was beschleunigt wurde.

XGBoost trainiert mit device="cuda" und tree_method="hist" auf der GPU, in der scikit-learn-Schnittstelle als XGBRegressor(tree_method="hist", device="cuda"); cuda:1 wählt die zweite Karte. Ein auf der GPU trainiertes Modell „can be used on any device regardless of the one used to train it“ und kann also Vorhersagen von einem Server ohne GPU liefern. Für „fully distributed GPU training“ über mehrere GPUs nennt die Dokumentation von XGBoost Dask, Spark und PySpark.

Eine Karte oder mehrere

cudf.pandas läuft auf einer GPU. Eine zweite Karte hilft nur über Dask, das die Daten in Partitionen teilt und je GPU einen Worker startet, oder indem zwei Analysten je eine Karte bekommen. Für eine Person, die interaktiv in pandas arbeitet, hält eine Karte mit 96 GB einen Datensatz, den zwei Karten mit 48 GB nur als Dask-Partitionen verarbeiten könnten, mit dem Austausch zwischen ihnen. Unter WSL2 unterstützt RAPIDS ohnehin nur eine GPU.

NVIDIA-Produktseiten und Datenblätter, wie in unseren Kartenartikeln festgehalten; „passt für“ ist unsere Planungsschätzung der Eingabegröße, mit Speicher für Zwischenergebnisse von Joins und Sortierungen bis etwa zum Doppelten der Eingabe.

Auch die Bandbreite steigt mit der Klasse, von 896 bis 1.792 GB/s. Die RTX PRO 5000 72 GB ist die Karte, die wir für einen Data-Science-Arbeitsplatz zuerst auslegen würden: Sie hält eine Tabelle von rund 24 GB samt Zwischenergebnissen, bei 300 W in einer Dual-Slot-Karte. Die RTX PRO 6000 Max-Q bringt ein Drittel mehr Speicher und Bandbreite bei denselben 300 W und passt zu Analysten, die auf derselben Maschine auch Modelle feinabstimmen oder bereitstellen. Unsere Seite Workstation mit RTX PRO 5000 72 GB kaufen nennt Tower für eine bis vier Karten.

Der Rest der Workstation

Data Science belastet auch Prozessor und Systemspeicher: CSV- und Parquet-Dateien werden beim Einlesen gelesen und dekodiert, und ausgelagerte Daten landen im Hauptspeicher. Planen Sie mindestens das Doppelte des GPU-Speichers als DDR5 ECC, 192 GB für eine Karte mit 96 GB, und NVMe-Laufwerke für die Arbeitsdaten. Der Dask-cuDF-Leitfaden hält fest, dass Parquet-Blockgrößen über dem Standard von 256 MiB „are usually more performant on GPUs with more than 8 GiB of memory“.

Plattformen laut unserer Seite zu KI-Servern; Hauptspeicher nach dem Verhältnis 2 × GPU-Speicher aus NVIDIAs Leitfaden für zertifizierte Systeme; Leistung: Karte mit 300 W plus Prozessor mit 350 W plus 15 Prozent, unter Volllast.

An 230 V zieht ein System mit einer Karte nach dieser Schätzung unter Volllast weniger als 4 A, eines mit zwei 300-W-Karten rund 1,1 kW, wie unsere Seite zu 2× RTX PRO 6000 Max-Q in einer Workstation ausrechnet.

Workstation je Analyst oder gemeinsamer Server

Eine Workstation gibt einem Analysten eine ganze Karte und eine schnelle lokale Platte. Teilen sich mehrere Personen große Datensätze, hält ein Server mit RTX PRO 6000 Server Edition im Serverraum, erreichbar über JupyterHub oder einen Scheduler, die Daten an einem Ort und die Karten ausgelastet; unser Vergleich GPU-Server oder Workstations für ein Team geht diese Wahl durch.

RAPIDS selbst ist unter Apache 2.0 kostenlos. NVIDIA AI Enterprise führt RAPIDS unter seinen unterstützten Frameworks, was nur zählt, wenn Ihr Unternehmen NVIDIAs Enterprise-Support dafür möchte, wie unser Leitfaden was kostenlos ist und was NVIDIA AI Enterprise braucht erklärt.

Was wir liefern

Diese Workstation können Sie bei uns kaufen: Wir liefern RTX PRO 4500, RTX PRO 5000 mit 48 und 72 GB sowie RTX PRO 6000 Max-Q und Workstation Edition und bauen Workstations auf Bestellung mit Threadripper PRO oder Xeon W, vor der Lieferung montiert und getestet, auf Wunsch mit Linux, NVIDIA-Treiber, CUDA und Container-Laufzeit. Bestellt wird auf einem EU-Vertrag mit EU-Rechnung und Herstellergarantie auf jede Komponente; Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Schreiben Sie uns Datengröße, Bibliotheken und Zahl der Analysten, und wir antworten mit einer Konfiguration.

FAQ