A city open-data portal's nightly RAPIDS job fits on one GPU today, but next quarter the county will add several times more rows. How should they choose RAPIDS-only versus RAPIDS+Dask?
Select an answer to reveal the explanation.
Short Explanation
One GPU is a single dump truck—great until the landfill load triples. Stay on single-GPU RAPIDS while it meets the SLA; bring Dask when the pile no longer fits. Adding a convoy of trucks for a load one truck can haul just adds coordination tax.
Full Explanation
Choose single-GPU RAPIDS while tables and intermediates fit device memory and the nightly open-data job meets its SLA; introduce RAPIDS+Dask when county volume growth exceeds what one GPU can hold or finish on time. That progressive scale-out avoids distributed coordination overhead until it buys real capacity, which is the practical municipal posture as portals absorb several times more rows next quarter.
Always adding Dask even when a single GPU finishes comfortably under the SLA taxes operations with cluster scheduling complexity for no capacity gain. Never using Dask for municipal data regardless of scale ignores the point at which one device is no longer enough for countywide extracts. Switching to handwritten assembly instead of RAPIDS or Dask abandons maintainable civic ETL for an irrelevant implementation fantasy that cities cannot staff or audit.
Exam caveat: "fits" includes peak intermediates during joins and groupbys, not only source CSV size; a job can OOM mid-pipeline even when inputs looked small on disk. Operational check: monitor peak GPU memory and runtime on current nightly loads, set a threshold for sustained high memory or SLA risk, and pilot Dask partitions on a scaled replay before the county row surge lands in production.