RAPIDS on an NVIDIA RTX PRO Blackwell workstation: cuDF, cuML and XGBoost on the GPU

What RAPIDS does on a workstation

RAPIDS is NVIDIA's set of open-source Python libraries for data science on the GPU: cuDF for dataframes, cuML for classic machine learning, and the integrations that let pandas, scikit-learn and XGBoost code run on an NVIDIA card. On an RTX PRO Blackwell workstation it pays off when the data has millions of rows and fits, or nearly fits, in the card's memory; for small tables the CPU can stay faster, because moving data to the GPU costs more than it saves.

The two entry points need no code changes. cudf.pandas is loaded with %load_ext cudf.pandas in Jupyter or python -m cudf.pandas on the command line, after which import pandas imports a proxy module; operations "execute on the GPU where possible and on the CPU otherwise". cuml.accel does the same for scikit-learn, UMAP and HDBSCAN, loaded with python -m cuml.accel or %load_ext cuml.accel before the other imports, and "transparently falls back to the original CPU implementation when an estimator or operation cannot be accelerated". XGBoost has its own GPU path, set with one parameter.

This page is for data-science teams choosing a workstation card. Language models on a workstation are covered in our guide to the best workstation GPU for AI.

Requirements as of October 2026

RAPIDS installation guide (now at docs.nvidia.com/datascience), cuDF documentation (version 26.12 of the docs), XGBoost documentation and the cuDF and cuML repositories, read 24 October 2026.

The install guide offers conda, pip and Docker. The pip wheels come from NVIDIA's package index with a suffix for the CUDA major version, cudf-cu12 or cudf-cu13, and the guide's release selector generates the exact command for each combination. The guide does not name Blackwell; its threshold of compute capability 7.0 covers the 12.0 of every RTX PRO Blackwell card. For a new workstation on these cards we would install the CUDA 13 packages on a driver from the R580 branch, which meets the 580.65.06 minimum and has long-term support to June 2028, as our guide to NVIDIA driver branches and CUDA versions explains.

How much GPU memory your data needs

A dataframe on the GPU stores each column as a contiguous array, so its size follows from rows, columns and data types. A table of 100 million rows with 20 columns of 64-bit floats is 16 GB (14.9 GiB); a billion rows with 10 such columns is 80 GB (74.5 GiB). Converting 64-bit columns to 32-bit, where precision allows, halves that. Joins, aggregations and sorts need working memory on top, so plan the card for a multiple of the input, not for the input alone.

Our arithmetic: rows × columns × 8 bytes. "Tight" means the input fits but working memory for joins and sorts may not; RTX PRO 4500 (32 GB), RTX PRO 5000 72 GB and RTX PRO 6000 Max-Q (96 GB) from NVIDIA's product pages.

Three mechanisms handle data that does not fit:

1. Managed memory in cudf.pandas. The documentation states that "cudf.pandas uses a managed memory pool by default" with prefetching, which "enables oversubscribing GPU memory", so data larger than GPU memory runs "in many cases, without CPU (Pandas) fallback". The pool mode is set with CUDF_PANDAS_RMM_MODE: managed_pool by default, or managed, async, pool and cuda. On WSL2 managed memory "does not support oversubscription", and cudf.pandas "is limited to the physical size of GPU memory".
2. Dask with Dask-CUDA. The Dask-cuDF guide recommends LocalCUDACluster on a single machine, "No matter how many GPUs are available on the machine (even one!)", partitions "between 1/32 and 1/8 the memory capacity of a single GPU" (1/32 to 1/16 for large sorts and joins), an RMM pool on each worker, for example rmm_pool_size=0.9, and cuDF's native spilling with enable_cudf_spill=True. When the data exceeds GPU memory, "the bottleneck is typically device-to-host memory spilling".
3. XGBoost's compressed format. XGBoost stores the training data on the GPU in a quantised ELLPACK format that "will commonly use 1/4 the space of a CSR matrix stored in floating point", allocates working memory "proportional to the number of rows", and advises xgboost.QuantileDMatrix first when a large data set runs out of memory.

By the Dask guide, a 72 GB card takes partitions of 2.25 to 9 GB and a 96 GB card 3 to 12 GB, by our arithmetic. Spilling moves data into system memory, which is why a data-science workstation needs more host memory than the card has; we plan at least twice the GPU memory, the ratio NVIDIA's guide for certified systems sets for servers. Send us the size of your largest table and the operations you run on it; our team replies with the card and the host memory that hold it.

cudf.pandas in daily work: fallback and limits

cudf.pandas "supports 100% of the Pandas API", in its documentation's words, by running supported operations on the GPU and the rest in pandas on the CPU. Data moves between host and device "only when necessary", so a pipeline that falls back often spends its time on copies. Its profiler shows which functions ran on the GPU and which on the CPU, the first thing to check when a notebook is slower than expected.

The FAQ lists the limits that matter in practice:

• only pandas 2 is supported; cuDF 24.02 was the last release for pandas 1.5
• small data "may be slower on GPU than CPU, because of the cost of data transfers"; the library "shines on workflows with more than 10,000 - 100,000 rows of data"
• global variables "can be accessed but can't be modified during CPU-fallback"
• objects pickled with regular pandas cannot be unpickled under cudf.pandas
• it "is not designed for distributed or out-of-core computing (OOC) workflows today"; for those the FAQ points to Dask and Apache Spark
• most third-party libraries that use pandas work with it; functions that pandas lacks, such as cuDF's .list accessor, need cuDF directly

We found no reproducible published measurement of cudf.pandas on RTX PRO Blackwell cards. NVIDIA's cuDF benchmarks page documents how to rerun the database-like operations benchmark and PDS-H at scale factor 50, "roughly 50GB of data", but prints no timings in text; NVIDIA's blog of September 2024 claims "up to 100x" on an RTX 6000 Ada without stating the CPU or data set. The fair test is your own notebook on your own data, run once with and once without %load_ext cudf.pandas.

cuML and XGBoost on the GPU

cuml.accel covers scikit-learn estimators plus UMAP and HDBSCAN. Whether an estimator runs on the GPU "can depend on parameters, input types, methods, or library versions", and the project validated the scikit-learn example gallery with it while noting that "This does not mean that every operation runs on the GPU". As with cudf.pandas, a profile of one real run shows what was accelerated.

XGBoost trains on the GPU with device="cuda" and tree_method="hist", in the scikit-learn interface as XGBRegressor(tree_method="hist", device="cuda"); cuda:1 selects the second card. A model trained on the GPU "can be used on any device regardless of the one used to train it", so it can serve predictions from a CPU-only server. XGBoost's documentation names Dask, Spark and PySpark for "fully distributed GPU training" across several GPUs.

One card or several

cudf.pandas runs on one GPU. A second card helps only through Dask, which splits the data into partitions and runs a worker per GPU, or by giving two analysts a card each. For one person working interactively in pandas, one 96 GB card holds a data set that two 48 GB cards could only process as Dask partitions, with the shuffles between them. Under WSL2, RAPIDS supports only a single GPU in any case.

NVIDIA product pages and datasheets as recorded in our card articles; "fits" is our planning estimate of input size with working memory for joins and sorts, assuming working memory of up to about twice the input.

Bandwidth rises with the tier as well, from 896 to 1,792 GB/s. The RTX PRO 5000 72 GB is the card we would size first for a data-science seat: it holds a table of about 24 GB with working memory, at 300 W in a dual-slot card. The RTX PRO 6000 Max-Q adds a third more memory and bandwidth at the same 300 W, and suits the analyst who also fine-tunes or serves a model on the same machine. Our page to buy an RTX PRO 5000 72 GB workstation lists towers that take one to four cards.

The rest of the workstation

Data science also loads the processor and system memory: CSV and Parquet files are read and decoded on the way in, and spilled data lands in host memory. Plan at least twice the GPU memory in DDR5 ECC, 192 GB for one 96 GB card, and NVMe drives for the working data. The Dask-cuDF guide notes that Parquet block sizes above the default 256 MiB "are usually more performant on GPUs with more than 8 GiB of memory".

Platforms from our AI servers page; memory by the 2 × GPU memory ratio of NVIDIA's certified-systems guide; power: 300 W card plus a 350 W processor plus 15 per cent, at full load.

On 230 V a one-card build draws under 4 A at full load by that estimate, and a two-card build with 300 W cards about 1.1 kW, as our page on two RTX PRO 6000 Max-Q in a workstation works out.

A workstation per analyst or a shared server

A workstation gives one analyst a whole card and a fast local disk. When several people share large data sets, a server with RTX PRO 6000 Server Edition cards in the server room, reached through JupyterHub or a scheduler, keeps the data in one place and the cards busy; our comparison of a GPU server or workstations for a team works through that choice.

RAPIDS itself is free under Apache 2.0. NVIDIA AI Enterprise includes RAPIDS among its supported frameworks, which matters only if your company wants NVIDIA's enterprise support for it, as our guide on what is free and what needs NVIDIA AI Enterprise explains.

What we supply

You can buy this workstation from us: we supply the RTX PRO 4500, the RTX PRO 5000 48 GB and 72 GB and the RTX PRO 6000 Max-Q and Workstation Edition, and build workstations to order on Threadripper PRO or Xeon W, assembled and tested before delivery, with the Linux release, NVIDIA driver, CUDA and a container runtime installed on request. The order runs on one EU contract and invoice with manufacturer warranty on every component, and quantities and lead time are confirmed in writing with the quote. Write us the size of your data, the libraries you use and the number of analysts, and we reply with a configuration.

FAQ