Skip to main content

Batch data processing

Turn an overnight job into a coffee break

Many data pipelines are slow not because the algorithm is hard but because they run row by row on one CPU core. RAPIDS puts the same DataFrame code on thousands of CUDA cores, with almost no interface change.

Batch jobs per hour, from
$0.193
Typical speedup range
10-50x
Idle cluster cost
0

01 — When it applies

Which data jobs belong on a GPU

GPU-accelerated data processing has a clear boundary: the work must vectorise, the data must be large enough to justify moving it into VRAM, and the arithmetic intensity must be high. If the bottleneck is disk I/O or network, a GPU changes nothing.

Plenty of everyday work meets those conditions: joins and group-bys on large tables, rolling-window computation on time series, the many column transforms of feature engineering, and tree-model training with XGBoost or LightGBM. Operations that take tens of minutes in pandas often take tens of seconds in cuDF.

Hourly rental fits this shape particularly well, because data processing is usually batch — daily, weekly, or a one-off historical backfill. Maintaining a GPU cluster for intermittent work is poor economics; renting one and destroying it when the job ends is the right shape.

02 — Workloads

Data jobs that suit a GPU

What they share: large data, parallel operations, high arithmetic intensity.

  • Large-table ETL and aggregation

    Joins, group-bys, sorts and deduplication across tens of millions to billions of rows. cuDF's interface closely mirrors pandas, so most code runs after changing one import.

  • Feature engineering

    The column transforms, encodings, binning and rolling statistics that precede training. This step often takes longer than training itself and compresses most readily on a GPU.

  • Tree-model training

    XGBoost and LightGBM both have mature GPU backends with dramatic speedups on large datasets — the most reliable case for GPU-accelerating classical ML.

  • Graph analytics and similarity search

    cuGraph's PageRank, community detection and shortest paths, plus large-scale vector similarity. These problems are naturally highly parallel.

03 — Stack

The RAPIDS suite, preinstalled

Interfaces mirror pandas, scikit-learn and NetworkX, so migration cost is close to zero.

  • cuDF — DataFrame acceleration

    The GPU counterpart to pandas with a highly compatible API. Most scripts run after swapping import pandas as pd for import cudf as pd.

    cuDF · pandas-compatible · Columnar

  • cuML — machine learning

    The GPU counterpart to scikit-learn, covering regression, clustering, dimensionality reduction and nearest neighbours. fit/predict code is unchanged.

    cuML · sklearn-compatible · XGBoost

  • cuGraph and Dask

    cuGraph for graph algorithms; Dask-cuDF for datasets larger than one card's VRAM, with multi-GPU scaling.

    cuGraph · Dask · Multi-GPU

04 — Choosing a GPU

Sizing a card for data work

This workload is the most VRAM-sensitive of all — data has to fit in VRAM to be accelerated. Budget two to three times the dataset size, because intermediate results are large.

Data scaleVRAM neededCheapest availableNotes
Millions of rows, single table12GBRTX 3060$0.100/hrEnough for routine analysis, and the speedup is already substantial. An entry card is the best value.
Tens of millions, multi-table joins24GBTesla V100$0.188/hrJoin intermediates expand VRAM use considerably; this tier is the safer choice.
Hundreds of millions, complex pipelines48GBQ RTX 8000$0.508/hrThe 48GB tier, and with Dask chunking it will handle larger sets still.
Very large scale, multi-GPU80GBA100 SXM4$1.088/hrDask-cuDF scales across cards, pooling VRAM for data one card cannot hold.

"Cheapest available" is derived from live inventory — the lowest per-GPU rate among models that clear the VRAM bar — and moves with the market. Multi-GPU nodes rent whole.

05 — Getting started

Running a GPU pipeline

  • 01

    Estimate the data size first

    Pick a VRAM tier from the table. Remember intermediates are much larger than the source data, especially for joins and pivots — leave headroom.

  • 02

    Change the import and run

    Most pandas scripts run after switching to cudf. Unsupported operators raise a clear error; fall that section back to CPU as directed.

  • 03

    Persist the results, then destroy

    Write results back to object storage or download them. Destroy the instance once you have them rather than letting disk keep billing.

06 — FAQ

GPU data processing

Can cuDF really drop in for pandas?

Mostly. cuDF covers the pandas interfaces people actually use, and most scripts run after one import change. Some operators are unsupported, particularly apply with Python callables. Where that happens, fall that section back to CPU — converting between cuDF and pandas is straightforward.

How much data justifies a GPU?

In practice the gain becomes clear above a million rows and dramatic above ten million. Below that, the cost of moving data in and out of VRAM can eat most of the speedup. And if the bottleneck is disk I/O rather than compute, a GPU will not help at all.

What if the data exceeds VRAM?

Use Dask-cuDF, which chunks the data into VRAM-sized partitions and processes them in turn, with multi-GPU scaling available. The simpler answer is often to rent a card with more VRAM — which is precisely the advantage of renting over owning.

Does XGBoost GPU acceleration need extra setup?

No. The XGBoost in the image is the GPU build; set the device parameter to cuda when training. Speedups on large datasets are typically about an order of magnitude.

How do I run scheduled jobs in the cloud?

Two approaches: keep one instance resident and trigger with cron, or create an instance per run and destroy it afterwards. The second is cheaper for infrequent jobs; the first avoids repeated image pulls and suits frequent ones.

Start building on NexGPU

Enterprise R&D team or solo developer — either way, your first job can be running in minutes.

Sign up to browse live network pricing. No payment method required.