NCA-ADS - Foundations of Accelerated Data Science (12% of the exam) - Section 5.4
Build end-to-end accelerated workflows.
Build end-to-end accelerated workflows that keep data resident on the GPU across ingestion, feature engineering, training, and evaluation stages to avoid costly CPU-GPU memory transfers. Recognise which RAPIDS components cover each stage and how they chain together without materialising intermediate CPU copies.
Practice question for this objective
lock_openFree sampleFoundations of Accelerated Data Sciencemedium
A data scientist builds a pipeline that reads raw sensor data with cuDF, runs feature engineering with cuDF operations, and then fits a cuML Random Forest. After profiling, they discover most wall-clock time is spent on memory transfers rather than computation. Which single architectural change is most likely to resolve this?
AReplace cuDF with pandas for the feature-engineering stage so the data lives in familiar host memory before being passed to cuML
BConvert the cuDF DataFrame to a NumPy array immediately after ingestion so downstream libraries can share a common in-memory format
CWrite the feature-engineered data to a Parquet file on NVMe storage between each stage so each stage can reload only the columns it needs
DPass the cuDF DataFrame directly into cuML using the shared device-memory pointer, keeping the data on the GPU for every stage of the pipelinecheck_circle Correct
Explain how keeping data resident in GPU memory across RAPIDS pipeline stages eliminates costly host-device transfers and improves end-to-end throughput. When cuDF DataFrames are passed directly to cuML estimators, no data leaves GPU memory: cuML reads from the same device buffer cuDF populated. The moment a pipeline stage serialises or copies data to host memory - whether via pandas, NumPy, or disk - the GPU pipeline is broken and two memory transfers (host-to-device and device-to-host) are incurred around that stage. Keeping the entire ETL-to-training path on the GPU is the primary performance principle behind the RAPIDS unified memory model.
Why A is wrong: Moving to pandas forces the data back to host memory, which introduces exactly the host-to-device transfer that cuML would then need to reverse. This increases the number of transfers rather than eliminating them.
Why B is wrong: Exporting to NumPy moves the data off the GPU to host memory. Any subsequent GPU operation would need to copy it back, adding at least two transfers where the goal is zero.
Why C is wrong: Materialising intermediate results to disk introduces I/O latency far greater than in-memory transfer costs and still requires re-reading and re-loading data to the GPU for subsequent stages.
Why D is correct: cuDF and cuML both operate on GPU memory and exchange data via the CUDA array interface or cuDF's native integration, so no host-device transfer is required between stages. This is the defining benefit of the RAPIDS end-to-end workflow.
Exam traps in Foundations of Accelerated Data Science
Answers that look right on this material and are not. Each one is a distractor from a different question in the NCA-ADS bank for this domain.
The pandas merge dispatches work to the GPU through an internal CUDA back-end, so performance is equivalent to using the cuDF merge operation for the same data
errorWhy it is wrong: Standard pandas has no GPU back-end. It operates on CPU memory using NumPy and its own C extensions. Only cuDF (or cuDF-backed pandas through the cuDF pandas accelerator mode) can dispatch merge work to the GPU.
When the dataset will soon grow to several hundred gigabytes, because only the multi-node cluster can ever hold and process data larger than a single GPU's memory.
errorWhy it is wrong: Tempting because clusters do help with oversized data, but the question asks when the single GPU wins; future growth argues for the cluster, so this answers the opposite case and is wrong.
Transfers are slow because the GPU must recompile each cuDF operation into CPU instructions before the data can cross the bus.
errorWhy it is wrong: Tempting because compilation overhead exists in some systems, but cuDF operations execute as GPU kernels and are not recompiled into CPU instructions per transfer; the cost is the physical data movement, not recompilation.