.svg)
Key Takeaways
- GPU-accelerated Spark uses the RAPIDS Accelerator plugin to run supported operations on GPUs without changing existing Spark SQL or DataFrame code.
- RAPIDS cuDF provides the GPU DataFrame engine the accelerator uses to execute supported columnar operations.
- Unsupported operations automatically fall back to standard CPU execution, allowing GPU and CPU operators to run within the same Spark workload.
- RAPIDS and CPU-based vectorization with Gluten and Velox take different acceleration paths and can coexist at the platform level for different workloads.
- Managed Spark platforms can add service fees on top of GPU infrastructure costs, reducing the cost benefit gained from faster execution.
GPU-accelerated Spark does not require rewriting Spark SQL or DataFrame code. The RAPIDS Accelerator works within Spark's existing physical plan, swapping supported CPU operators for GPU equivalents while unsupported operations continue on the CPU.
This turns the acceleration question from "Do we need to migrate?" into "Which parts of this workload can run on GPUs?" The answer depends on operator support, CPU fallback, infrastructure cost, and workload characteristics.
This article explains how RAPIDS cuDF accelerates Spark, what the performance and cost tradeoffs look like, and how the GPU path compares with CPU-based vectorization through Gluten and Velox.
What is GPU-Accelerated Spark?
GPU-accelerated Spark is Apache Spark running its supported SQL and DataFrame operations on graphics processing units (GPUs) instead of CPUs, through a plugin that intercepts Spark's physical execution plan and replaces CPU operators with GPU equivalents while the application keeps using standard Spark APIs.
Unlike CPU-based vectorization, GPU acceleration moves supported computation to dedicated GPU hardware, while CPU vectorization keeps execution on the cluster's CPUs, a distinction covered later against Gluten and Velox.
What is RAPIDS cuDF, and How Does it Fit Into GPU-Accelerated Spark?
RAPIDS cuDF is NVIDIA's GPU-accelerated DataFrame library for columnar data processing, and the RAPIDS Accelerator for Apache Spark is the plugin that puts cuDF underneath Spark's distributed execution engine, so a Spark job benefits from GPU processing without becoming a single-node cuDF job.
This allows supported parts of a distributed Spark job to execute through cuDF on GPUs without turning the workload into a separate application or changing its Spark SQL and DataFrame code. In short, cuDF is the GPU processing library; the RAPIDS Accelerator is the Spark integration layer.
How Does the RAPIDS Accelerator Replace Spark's CPU Operators Without Changing Application Code?
The RAPIDS Accelerator replaces Spark's CPU operators by examining Spark's physical execution plan, per NVIDIA's RAPIDS Accelerator documentation, and swapping supported CPU operators for GPU equivalents below the application layer, leaving the Spark SQL or DataFrame code that produced the plan unchanged.
The cluster still needs GPU-specific setup:
- GPU-enabled workers: Compatible NVIDIA GPUs with CUDA installed.
- Plugin setup: The JAR loads at cluster startup.
- GPU execution: Load the plugin with spark.plugins=com.nvidia.spark.SQLPlugin; spark.rapids.sql.enabled controls GPU acceleration for SQL operations.
The optional RAPIDS Shuffle Manager can use UCX for GPU-to-GPU transfers, keeping shuffle data on GPUs per NVIDIA's shuffle manager documentation and reducing CPU-memory transfers.
Which Spark Operations Does RAPIDS cuDF Accelerate, and Which Still Fall Back to CPU?
RAPIDS cuDF accelerates Spark operations with GPU-native implementations, including columnar scans, joins, aggregations, and many common SQL functions. Unsupported operations fall back to standard CPU execution rather than causing the job to fail.
A simplified mixed plan could look like this:
A job therefore does not need complete GPU compatibility to benefit. What matters most is whether its compute-intensive operations can execute on GPUs, even if other parts of the plan fall back to CPUs.
How Does GPU-Accelerated Spark With RAPIDS cuDF Compare to CPU-Based Vectorization Like Gluten and Velox?
RAPIDS cuDF and CPU-based vectorization accelerate Spark through different hardware paths. RAPIDS moves supported operations to GPUs, while Gluten and Velox use vectorized C++ execution on CPUs. Teams considering accelerating Apache Spark with Gluten and Velox should therefore evaluate whether their workloads justify dedicated GPU infrastructure.
These are complementary acceleration options rather than platform-wide either/or choices.
Why Do Managed Spark Platforms Make GPU-Accelerated Spark More Expensive Than It Needs to Be?
Managed Spark platforms make GPU-accelerated Spark more expensive than it needs to be by charging a service fee on top of GPU compute that is already expensive on its own, so every GPU node and every hour of runtime carries an avoidable markup.
Running RAPIDS Spark on infrastructure teams control removes that fee while letting GPU resources scale with demand, which is the core of the GPU Spark cost problem that managed platforms created.
See how Acceldata's Spark acceleration runs RAPIDS Spark on infrastructure you control, so cost math accounts for platform fees and utilization, not instance pricing alone.
What Does GPU-Accelerated Spark's Performance Look Like in Practice?
GPU-accelerated Spark can post triple-digit throughput gains: a cuDF microkernel optimization improved throughput by 117% on 500-KB chunked Parquet list-column reads, per NVIDIA's April 2025 technical benchmark, using smaller, type-specific microkernels that cut code paths and register pressure.
That figure is scan-level, not an end-to-end Spark speedup, since job-level gains depend on how much execution time runs on GPU-eligible operations versus CPU fallback.
The gap compounds at scale. A global telecommunications provider running Spark workloads on Acceldata's xLake platform needed 85% fewer compute cores and completed the same class of benchmark workloads 2.5 times faster, per published case study results.
How Do You Monitor GPU-Accelerated Spark Jobs When the Spark UI Can't See Infrastructure-Level Failures?
Monitoring GPU-accelerated Spark jobs when the Spark UI can't see infrastructure failures means pairing Spark execution signals with Kubernetes and GPU-level telemetry, since the Spark UI only reports what happens inside an application, not what happens to the nodes and containers underneath it.
What the Spark UI can't tell you about your data platform is this same blind spot: one GPU node failure can take down several Spark applications.
The same discipline applies to diagnosis: how Acceldata diagnosed and fixed a throughput bottleneck in a high-throughput Scala microservice profiled the actual hot path instead of guessing.
What Should Teams Read Next to Decide Between GPU and CPU-Based Spark Acceleration?
The choice between RAPIDS cuDF and Gluten and Velox depends on whether a workload benefits enough from GPU execution to justify dedicated hardware. Teams evaluating the CPU path can review the ODP Spark with Gluten Velox whitepaper for detailed benchmark and cost data.
Before choosing an acceleration path, evaluate:
- Data volume and shape: Is the workload large and compute-intensive enough to benefit from GPUs?
- GPU eligibility: How much of the physical plan can RAPIDS accelerate?
- Current infrastructure: Does Spark run on managed or self-managed infrastructure?
- Available GPU capacity: Does the team already have GPU resources it can use?
Running GPU-Accelerated Spark Without the Managed-Platform Markup with Acceldata
GPU-accelerated Spark only pays off when RAPIDS cuDF is matched to the right workload, not applied everywhere, and its infrastructure is priced and watched like any other.
That comes down to a few practices:
- Matching RAPIDS cuDF to GPU-eligible operations, Gluten and Velox to the rest.
- Pricing GPU compute on its own terms, not a managed platform's markup.
- Watching GPU nodes, since the Spark UI can't see them.
Acceldata's Open Data Platform runs both RAPIDS cuDF and Gluten and Velox on Kubernetes-native infrastructure teams control, keeping GPU-accelerated Spark's performance without the markup.
Book a demo and see how ODP runs GPU-accelerated Spark without a managed platform's markup on your GPU bill.
FAQs
Does GPU-accelerated Spark require rewriting existing Spark SQL or DataFrame code?
No. GPU-accelerated Spark does not require rewriting Spark SQL or DataFrame code, since the RAPIDS Accelerator works at the physical execution-plan level. Cluster-level setup is still needed: compatible NVIDIA drivers, CUDA, and the plugin JAR.
Can RAPIDS cuDF and Gluten/Velox run in the same Spark environment, or is it one or the other?
RAPIDS cuDF and Gluten/Velox are not mutually exclusive at the platform level. Teams can route GPU-eligible workloads through RAPIDS and CPU-vectorized ones through Gluten and Velox.
What GPU hardware and driver requirements does the RAPIDS Accelerator for Spark need?
The RAPIDS Accelerator needs compatible NVIDIA GPU hardware, drivers, and CUDA versions, though minimums vary by release. Verify the live compatibility matrix in NVIDIA's documentation before deployment.
Does GPU-accelerated Spark make sense for smaller clusters, or only at large scale?
GPU-accelerated Spark can make sense for smaller clusters too, since cluster size alone is not the deciding factor. The cost-benefit depends on GPU pricing, job size, and how much of the workload is GPU-eligible.
How do you tell whether a slow Spark job is a good candidate for GPU acceleration versus one that just needs tuning?
A slow Spark job is a strong GPU-acceleration candidate when its bottleneck sits in GPU-supported scans, joins, or aggregations. Shuffle skew, poor partitioning, or inefficient resource configuration should be tuned first instead, since GPU hardware does not fix those issues.
