A team already runs its tabular preprocessing comfortably with cuDF on one GPU and is deciding whether a particular workload warrants moving to dask-cuDF instead. They want to base the decision on what dask-cuDF actually adds rather than on habit. Which two circumstances genuinely justify choosing dask-cuDF over single-GPU cuDF for that workload? Select TWO.
- AThe working dataset is larger than a single GPU's memory, so the computation must be partitioned and streamed across several GPUs to complete at all. Correct
- BThe job must scale horizontally across multiple GPUs or several nodes, distributing partitions of the frame so the aggregate memory and compute exceed one device. Correct
- CThe dataset already fits in one GPU's memory and the priority is the lowest possible latency on a single short transformation.
- DThe team wants column operations to execute eagerly and return materialised results immediately after each call for interactive debugging.
- EThe workload needs a string operation that uses regular-expression backreferences, which the team expects dask-cuDF to support where single-GPU cuDF does not.
Why A is correct: Partitioning a frame that exceeds one device's VRAM is the core reason dask-cuDF exists, letting an out-of-core dataset be processed across a cluster.
Why B is correct: Dask supplies the scheduler and partitioned execution that spread a single logical DataFrame over many workers, which plain cuDF on one GPU cannot do.
Why C is wrong: This is the case where single-GPU cuDF is preferable; Dask adds graph-building and scheduling overhead that only hurts a small low-latency job.
Why D is wrong: Eager, immediate results describe cuDF's execution model; dask-cuDF is lazy and defers work until a trigger, so wanting eagerness argues against it.
Why E is wrong: Dask-cuDF executes the same cuDF kernels per partition, so an unsupported regex feature stays unsupported; distribution changes scale, not operator coverage.