A data scientist refactors a single-GPU cuDF script to dask_cudf so it can process a Parquet dataset larger than one GPU's memory across a four-GPU node. After reading the data and chaining a filter, an assignment of a derived column, and a group-by sum, she prints the DataFrame's repr and is surprised that no GPU utilisation is observed and the output describes partitions rather than aggregated numbers. Which property of the dask_cudf execution model explains this behaviour?
- Adask_cudf executes each transformation eagerly on the GPU but suppresses utilisation reporting until the final group-by has finished reducing across all of the partitions.
- BThe group-by sum is unsupported in dask_cudf and silently falls back to a metadata-only placeholder, which is why only partition descriptions appear in the printed output.
- Cread_parquet loaded the data into host memory, so the operations ran on the CPU and the printed object is a pandas-backed collection rather than a GPU collection.
- Ddask_cudf builds a lazy task graph and defers execution until a materialising action such as compute, persist, or head is called, so chained transformations alone do not dispatch GPU work. Correct
Why A is wrong: Tempting because plain cuDF is eager, but dask_cudf is lazy; the absent utilisation reflects genuine deferral, not suppressed reporting, so this is wrong.
Why B is wrong: Tempting if one assumes feature gaps, but group-by reductions are fully supported in dask_cudf; the partition repr reflects laziness, not a silent fallback.
Why C is wrong: Tempting because host-resident data would avoid GPU use, but dask_cudf.read_parquet creates GPU-backed partitions; the repr shows a lazy GPU collection, so this is wrong.
Why D is correct: Correct: dask_cudf inherits Dask's lazy evaluation model, so transformations only construct a task graph; computation runs on the GPU workers when a materialising action triggers the scheduler.