NVIDIA RAPIDS: cuDF, cuML, and cuGraph for GPU Data Science

RAPIDS is a suite of open-source Python libraries, built on CUDA, that execute data science and analytics workloads on NVIDIA GPUs while exposing APIs closely modelled on the corresponding CPU libraries [NVIDIA-DOC]. It occupies the slot in NVIDIA's stack labelled GPU data science — the layer between raw CUDA and the deep-learning frameworks. When a question describes accelerating dataframe operations, classical machine learning, or graph analytics on GPUs, RAPIDS is the answer.

Two design decisions explain everything else about it:

API mirroring. RAPIDS libraries intentionally imitate their CPU counterparts' interfaces. The consequence is that porting is often a change of import rather than a rewrite, and the consequence of that is the exam's favourite framing: RAPIDS components are identified by which CPU library they replace.

Keeping data on the GPU. Moving data between host (CPU) memory and device (GPU) memory costs time. RAPIDS is designed so a whole pipeline — load, clean, join, aggregate, featurise, fit — can stay resident in GPU memory, paying the transfer cost once rather than at every step. This single fact explains the entire when-to-use rule: the overhead is fixed, the benefit scales with data, so there is a crossover size below which the CPU wins.

The component map

The first three rows are the exam. The rest are worth recognising so a distractor naming cuPy or cuSpatial does not unsettle you, but no reasonable question requires depth on them. The confusable-pairs list for this certification names cuDF vs cuML vs cuGraph explicitly as a trio to keep distinct [FIELD], which is a direct signal that a question exists in the form "which RAPIDS library replaces X?"

A memory device that survives exam pressure: cu + what it does. cuDF = dataframes = pandas. cuML = machine learning = scikit-learn. cuGraph = graphs = NetworkX. The names are the answers; the only trap is confusing which CPU library each corresponds to, and the expansion resolves it.

L1 — Intuition: why a GPU can do dataframe work at all

A GPU is a throughput machine: thousands of relatively simple cores executing the same instruction across many data elements at once. A CPU is a latency machine: a few very sophisticated cores optimised for complex, branching, sequential work.

Most dataframe operations turn out to be a natural fit for the throughput machine, because they are element-wise or reduction-shaped: filter every row against a predicate, add two columns, group by a key and sum, sort, join on a key. Each of those applies the same logic across millions of independent elements — precisely the pattern a GPU is built for. Similarly, the classical ML algorithms in cuML are dominated by dense linear algebra and distance computations, and graph algorithms in cuGraph are dominated by repeated sparse matrix-style operations over edge lists. All three domains parallelise.

What does not fit: work that is sequential, branch-heavy, tiny, or dependent on Python-level per-row logic. A .apply() with an arbitrary Python function per row is the canonical anti-pattern; it drags execution back toward the interpreter and gives up the parallelism the GPU exists for.

L2 — The three components in more detail

cuDF. A dataframe library with a pandas-like API: reading CSV, Parquet, JSON and ORC; selection and filtering; joins and merges; group-by and aggregation; sorting; string operations; datetime handling. Its usefulness for the work in this module is direct — the deduplication, group-by-source cross-tabulation, and percentile computations from 08-03 are exactly the shapes that accelerate. Modern RAPIDS also ships a pandas accelerator mode (cudf.pandas) that lets unmodified pandas code run on the GPU where supported and fall back to CPU where not; for the exam, the fact to hold is that such a compatibility path exists, not its flags.

The important caveat is coverage: cuDF mirrors most of pandas, not all of it. Some methods, dtypes, and index behaviours differ or are unsupported, so "drop-in replacement" is a design goal that is largely met rather than a guarantee. Treat any claim of perfect API parity as a distractor.

cuML. GPU implementations of the classical ML algorithm families you would reach for in scikit-learn: linear and logistic regression, ridge/lasso, k-means and DBSCAN clustering, PCA and truncated SVD, t-SNE and UMAP for dimensionality reduction, random forests and gradient-boosted trees, k-nearest neighbours, and support vector machines. The API deliberately follows scikit-learn's fit / predict / transform conventions.

Where it matters for LLM work: k-nearest neighbours and clustering over embedding vectors. Clustering a large embedding set to find topical structure, or running approximate nearest-neighbour search over millions of vectors, are cuML-shaped problems, and they connect directly to the embedding and retrieval work in 03-01 and 07-04. Note the boundary though — cuML is classical ML. It is not a deep-learning framework and does not train neural networks; that is PyTorch and TensorFlow territory, and confusing the two is a distractor family.

cuGraph. GPU graph analytics with a NetworkX-like API: PageRank, betweenness and other centrality measures, connected components, community detection (Louvain), shortest paths, breadth- and depth-first traversal. Graph algorithms are the least intuitive of the three as a GPU fit, but they are dominated by repeated sparse operations over the same edge structure, which parallelises well and rewards keeping the graph resident in GPU memory across iterations. Graph work with NetworkX and cuGraph is named in this course's feature-engineering material for exactly this reason.

Dask and Polars, for context. Two non-RAPIDS scale tools worth being able to place, since the official suggested-reading orbit includes big-data topics:

The distinction worth carrying: Dask is about distributing work across more devices; cuDF is about making one device faster; Polars is about making the CPU path faster. They answer different questions and a well-formed exam option will reflect that. Also note the scaling ladder implied: pandas → Polars or cuDF on one machine → Dask-cuDF across many GPUs.

L3 — When GPU acceleration actually pays off

This is the judgment half of the lesson, and the part where it is easy to over-claim. This course quotes no speedup figure, because none of the sources it is built from supply a benchmark that can be responsibly attributed, and a fabricated multiplier is worse than an admitted gap. What can be said structurally is more useful for an exam anyway.

GPU acceleration has costs that do not scale with your data:

And a hard constraint that CPU work does not have: GPU memory is a fixed, comparatively small budget. A dataset that fits in host RAM may not fit in device memory, and exceeding it produces an out-of-memory failure rather than graceful slowdown. The mitigations are chunking, multi-GPU via Dask-cuDF, and, in recent RAPIDS, unified/managed memory — but the constraint is the first thing to check before proposing a GPU pipeline.

So the payoff condition is a conjunction:

GPU acceleration pays off when — (1) the dataset is large relative to the fixed overheads, (2) the operations are parallelisable rather than sequential or per-row-Python, (3) the working set fits in GPU memory or can be partitioned to, and (4) the pipeline can stay on the GPU for multiple steps so the transfer is paid once, not per operation.

It does not pay off when the data is small (the overhead dominates and pandas finishes first), when the work is a single trivial operation on data already in CPU memory (you pay two transfers to save microseconds), when the bottleneck is disk or network I/O rather than compute, when the logic is inherently row-sequential, or when no GPU is available and the environment must run anywhere.

One additional practical point, and it is the one that catches people converting a working pipeline: transfer costs are per boundary crossing, so a pipeline that bounces between cuDF and pandas repeatedly can be slower than either pure path. The win comes from staying on one side. Convert once at the start, work, convert once at the end.

The disambiguation table. Read it right-to-left when an exam stem names a CPU library and asks for the GPU equivalent.

The last three rows exist because RAPIDS questions frequently appear inside a broader NVIDIA-stack question, and the failure mode is picking a real NVIDIA product that solves a different problem. The one-line placements to hold:

• RAPIDS = GPU data science (prepare and analyse the data)
• NeMo = build, customise, and curate for LLMs — with NeMo Curator owning data curation (08-01)
• TensorRT / TensorRT-LLM = optimise a model for inference
• Triton = serve many models
• NIM = packaged, pre-optimised inference microservice

Note the genuine adjacency between RAPIDS and NeMo Curator, which is where a careless answer goes wrong. Both touch data at scale, and NVIDIA's curation tooling is itself GPU-accelerated. The discriminator is level of abstraction: cuDF is a general-purpose dataframe library you write analysis code against; NeMo Curator is a purpose-built curation pipeline for LLM training corpora. If the stem says "curate a training dataset," answer NeMo Curator. If it says "accelerate pandas-style dataframe operations," answer cuDF.

The figures below are constructed for illustration to expose the reasoning about fixed versus scaling costs. They are not measured, and no speedup claim should be taken from them.

Continue the 12,000-document corpus from 08-03. The profiling pipeline does: load metadata, tokenize and count, dedup by hash, compute near-duplicate similarity, group-by-source cross-tabs, and cluster the embeddings to find topical structure. A colleague asks whether it should be a RAPIDS pipeline.

Work the four payoff conditions in order rather than guessing.

Condition 1 — is the data large relative to the overheads? 12,000 documents is metadata for 12,000 rows plus one embedding matrix. As a dataframe, 12,000 rows is small. Rows in the thousands are where pandas is comfortably fast and the CUDA context startup plus two transfers is a meaningful fraction of total runtime. Verdict for the dataframe steps: no benefit, likely a small net loss.

Condition 2 — which operations are parallelisable? Break the pipeline down:

Two steps are genuinely GPU-shaped. The rest are too small to care.

Condition 3 — does it fit in GPU memory? A 12,000 × 768 float32 embedding matrix is about 12,000 × 768 × 4 bytes ≈ 35 MB. Trivially yes. Note that this is also the arithmetic that says the problem is small: 35 MB is not a GPU-scale working set.

Condition 4 — can the pipeline stay on the GPU? No. The tokenizer is CPU-side and sits in the middle of the pipeline, so a GPU implementation would bounce across the boundary — the exact anti-pattern from section 2.

The decision: keep the profiling pipeline in pandas. Optionally use cuML for the embedding clustering as a single self-contained GPU step, transferring the 35 MB matrix in and the labels out — one boundary crossing, one parallel workload, no bouncing.

Now change one number. The same pipeline over 12 million documents. Re-run the conditions:

The finding, and the exam-relevant lesson: the correct answer changed because of scale, not because of preference, and the constraint that forced the multi-GPU decision was GPU memory capacity, not compute. That is the reasoning shape to bring to a scenario question — check whether the working set fits before proposing the GPU path, and reach for Dask-cuDF when it does not.

That last row is a deliberate piece of course design. This lesson is allocated the shortest study time in the module because the exam's demand is a mapping, and the honest advice is to bank the mapping and move on.

Objectives served. 2.1 "awareness of the process of extracting insights from large datasets using data mining, data visualization, and similar techniques" — note large datasets, which is the clause RAPIDS answers — and 2.3 "conduct data analysis under the supervision of a senior team member" [OFFICIAL]. It also sits under 1.10 / 4.6, "use Python packages (spaCy, NumPy, Keras, etc.) to implement specific traditional machine learning analyses," because cuML is precisely traditional ML, and under 1.6 / 4.3 on familiarity with the Python ecosystem. Crucially, the official study guide's suggested-reading list names RAPIDS, cuML, and GPU data science among its readings, which is about as explicit a signal as the blueprint gives that these names are expected knowledge [OFFICIAL].

Calibration. RAPIDS is Tier 2 in the [FIELD] priority tiers, alongside data-quality handling and TensorRT/Triton — above visualization, below tokenization and NIM [FIELD]. Two further calibration findings shape how to study it. First, NVIDIA-branded answers are favoured: when two options are technically defensible, the NVIDIA-stack option tends to be keyed, which means an option naming a RAPIDS component in a GPU-data-science stem deserves serious weight. Second, deep GPU-hardware detail was reported as overkill and absent, so nothing below the component-identity level is worth memorising.

The net: this is a small number of near-guaranteed marks available for a few minutes of memorisation, which is an unusually good trade in a 50–60 question exam with roughly 60–70 seconds per question.

Question phrasings to expect

• "Which RAPIDS library provides a GPU-accelerated equivalent of pandas?" → cuDF.
• "Which RAPIDS library provides GPU-accelerated machine learning algorithms similar to scikit-learn?" → cuML.
• "Which RAPIDS library accelerates graph analytics in place of NetworkX?" → cuGraph.
• "A team's pandas pipeline over tens of millions of rows is too slow. Which NVIDIA solution addresses this with minimal code change?" → cuDF / RAPIDS, because the API mirrors pandas.
• "What is the main design goal of the RAPIDS APIs?" → to mirror familiar CPU library APIs so existing code ports with minimal change while executing on the GPU.
• "When is GPU-accelerated data processing not beneficial?" → on small datasets, where transfer and startup overhead dominates; on I/O-bound work; on inherently sequential logic.
• "Which tool scales a cuDF workload across multiple GPUs or nodes?" → Dask (Dask-cuDF).
• "What limits the size of a dataset that can be processed on a single GPU?" → GPU memory capacity.
• "Which is used for GPU-accelerated data science rather than model serving?" → RAPIDS, versus Triton/NIM for serving and TensorRT for inference optimisation.

Distractor families

Mistake 8 deserves the extra second it takes to prevent. Under exam pressure the three cu* names blur, and the reliable defence is to expand the suffix rather than to recall a memorised pairing: DF is dataframes, so pandas. ML is machine learning, so scikit-learn. Graph is graphs, so NetworkX.

They cover three different problem domains and replace three different CPU libraries. cuDF is the dataframe library — the GPU equivalent of pandas — handling I/O, filtering, joins, group-by, aggregation, sorting, and string operations on tabular data. cuML is the classical machine learning library — the GPU equivalent of scikit-learn — providing regression, k-means and DBSCAN clustering, PCA and UMAP, random forests, k-nearest neighbours, and SVMs, with the same fit/predict/transform conventions. cuGraph is the graph analytics library — the GPU equivalent of NetworkX — providing PageRank, centrality measures, connected components, community detection, and traversals. They compose naturally in a single pipeline: load and clean in cuDF, featurise and fit in cuML, analyse relationships in cuGraph, all without leaving GPU memory. That last property is the point of having them share a suite rather than existing separately.

Close enough to be the design principle, not close enough to be a guarantee — and that nuance is worth holding because both the over-claim and the under-claim show up as distractors. The API is intentionally modelled on pandas, so a large fraction of ordinary dataframe code ports with an import change, and RAPIDS additionally offers a pandas accelerator mode that runs unmodified pandas code on the GPU where operations are supported and falls back to CPU where they are not. What is not guaranteed is complete coverage: some pandas methods, dtypes, and index behaviours are unsupported or behave differently, and code that reaches for obscure corners of the API or for per-row Python callbacks will need work. The practical posture is to treat the mirroring as a strong head start rather than a promise, test the specific operations your pipeline uses, and keep a CPU fallback for environments without a GPU.

Four situations, and they are worth being able to recite because the exam asks the negative form. Small data, where CUDA context startup and host-to-device transfer are a large fraction of total runtime and pandas finishes first. I/O-bound work, where the pipeline spends its time waiting on disk or object storage and a faster compute engine changes nothing. Inherently sequential or branch-heavy logic, including per-row Python callbacks, which cannot exploit thousands of parallel cores. Working sets that exceed GPU memory without being partitioned, where the result is an out-of-memory failure rather than a slowdown — this is a capacity constraint, distinct from the others, and it is why Dask-cuDF exists. A fifth practical case: pipelines that alternate between GPU and CPU libraries, where repeated boundary crossings can cost more than either pure path. The single sentence to carry into the exam: GPU acceleration is a throughput advantage with a fixed setup cost, so it wins when the work is big and parallel and loses when it is small, sequential, or I/O-bound.

They are different layers of the same stack and each owns one verb. RAPIDS prepares and analyses data on the GPU — the data science layer. NeMo builds and customises LLMs, with NeMo Curator owning corpus curation, NeMo Retriever owning retrieval accuracy, and NeMo Guardrails owning runtime safety rails. TensorRT compiles a trained model for fast inference, and TensorRT-LLM adds the LLM-specific machinery (KV cache, paged attention, in-flight batching). Triton Inference Server serves many models with features like dynamic batching. NIM packages a pre-optimised model as a deployable inference microservice. A stem that describes accelerating dataframe or classical-ML work is RAPIDS; one that describes cleaning and deduplicating a training corpus is NeMo Curator; one about making inference faster is TensorRT; one about hosting models is Triton or NIM. Getting the layer right is most of getting the answer right, and 12-08 and 12-13 cover the optimisation and serving layers properly.

No, and this is a deliberate judgment rather than a concession. The exam examines RAPIDS at recognition depth: which component replaces which CPU library, what problem class RAPIDS occupies in NVIDIA's stack, and when GPU acceleration is and is not worthwhile. All of that is learnable from reading, and the [FIELD] calibration that this exam asks general-level rather than deep-technical questions applies with particular force here [FIELD]. If you already have GPU access and a genuinely large dataset, running one cuDF and one cuML workload will make the memory-capacity and transfer-overhead constraints concrete in a way reading does not, and that is worth an hour. If you are working on a free entry-level GPU with small data, you will mostly demonstrate the overhead-dominated case from section 4 — educational in its own way, but not what the exam asks about. Spend the time on Tier-1 material instead.

1. Memorise the three-way mapping cold: cuDF = GPU pandas · cuML = GPU scikit-learn · cuGraph = GPU NetworkX. This is the exam item, and expanding the suffix (dataframes / machine learning / graphs) is the recall trick that survives time pressure.
2. RAPIDS' design principle is API mirroring — imitating CPU library interfaces so existing code ports with minimal change while running on the GPU.
3. cuML is classical ML, not deep learning. Neural network training is PyTorch and TensorFlow; that swap is a distractor.
4. GPU acceleration pays off on large, parallel, GPU-resident workloads and loses on small data, I/O-bound work, sequential per-row logic, and pipelines that keep crossing the CPU/GPU boundary.
5. GPU memory capacity is a hard constraint, not a soft one. Exceeding it fails; Dask-cuDF is the answer when the working set needs partitioning across GPUs or nodes.
6. Dask distributes, cuDF accelerates, Polars is a CPU alternative. Three different answers to three different questions, and Polars is not an NVIDIA product.
7. Vectorise before you accelerate. A per-row Python .apply() gives up exactly the parallelism the GPU exists to provide.
8. Get the stack layer right: RAPIDS = data science · NeMo Curator = LLM corpus curation · TensorRT = inference optimisation · Triton = serving · NIM = packaged deployment microservice.
9. Do not memorise speedup numbers. This course quotes none because none can be responsibly sourced from its material; the defensible claim is structural — which workload shapes parallelise and which fixed costs must be amortised.
10. Tier 2, recognition depth. A few minutes of memorisation for near-certain marks; then move your study time to Tier-1 topics.

That closes this module. You can now curate a dataset on purpose including the cases that should fail, name any defect from its symptom, profile a text corpus in tokens rather than characters, choose the chart that answers the question you actually asked, disaggregate it so group-level harm can be seen, and identify which RAPIDS component replaces which CPU library and whether reaching for it is justified.

Next: 09-01 returns to the 20-item evaluation set you built by hand back in 01-08 and grows it to roughly a hundred items — using exactly the curation discipline, coverage matrix, and defect vocabulary this module just gave you. The measurement thread that ran through this module becomes the whole subject of the next one, and the first question it answers is how to add eighty items without quietly making the set easier.