NVIDIA Accelerated Data Science

Many accelerated projects fail on setup, not on code. You manage drivers, CUDA versions, Conda environments and Docker images, resolve version conflicts, and keep a clean baseline for fair benchmarking.

• Drivers, CUDA toolkit and runtime compatibility
• Conda environments for RAPIDS
• Docker images for GPU workloads
• Diagnosing version conflicts
• Pinning dependencies for reproducibility
• Benchmarking frameworks fairly

You build A containerized RAPIDS environment with a benchmark that anyone can rerun.

Analysis is where many projects begin, and it can be fast. You explore tables with cuDF, find anomalies in time series, and analyze networks with cuGraph, reading what each result means for the project.

• Exploratory analysis with cuDF
• Distributions, outliers and missing values
• Time series structure and anomaly detection
• Graph construction from tabular data
• Centrality, communities and paths in cuGraph
• Visualizing results from GPU data

You build An exploratory report on a table, a time series and a graph, all computed on the GPU.

ETL is often the slowest step in a pipeline. You move pandas workflows onto the GPU, choose efficient file formats, write joins and aggregations that scale, and avoid the patterns that force slow copies back to the CPU.

• cuDF compared with pandas
• Running existing pandas code with cudf.pandas
• Parquet and efficient file formats
• Joins, group-bys and window operations
• Avoiding fallbacks to the CPU
• User-defined functions on the GPU

You build A pandas pipeline rewritten for the GPU, with timings for each stage.

One GPU runs out of memory before a workload runs out of work. You partition data over several GPUs with Dask, reduce shuffles with caching, and decide when Spark with GPU acceleration fits better.

• Dask-cuDF and the Dask task graph
• Partition sizing and data placement
• Reducing shuffles with caching and persistence
• Spilling and memory management between devices
• Spark with GPU acceleration
• Choosing between Dask and Spark
• Reading the dashboard to find stalls

You build A multi-GPU ETL job with a measured speedup over a single GPU.

Models learn from the data you leave them. You clean and reformat at scale, scale features, generate synthetic data where real samples are thin, and watch pipelines for the stages that slow everything else.

• Cleaning and reformatting large tables
• Handling missing values and outliers
• Feature scaling and encoding on the GPU
• Generating synthetic data to fill gaps
• Profiling pipelines with DLProf and Nsight
• Finding and fixing pipeline bottlenecks

You build A data preparation pipeline with synthetic augmentation and a bottleneck report.

Good features often beat clever models. You engineer features at scale, train with cuML and XGBoost on the GPU, use mixed precision where it helps, and tune hyperparameters without waiting hours.

• Feature engineering for tabular and temporal data
• Training with cuML estimators
• XGBoost on the GPU
• Mixed precision and when it is safe
• Hyperparameter search at GPU speed
• Evaluating and comparing models

You build A tuned GPU model with a feature-engineering log and a comparison table.

More GPUs do not always mean faster results. You compare single and multiple GPU training, measure scaling efficiency, and balance accuracy against the inference speed the deployed model needs.

• Data-parallel training across GPUs
• Multi-GPU options in XGBoost and cuML
• Measuring scaling efficiency
• Communication overhead and its limits
• Trading accuracy for inference speed
• Choosing a training setup for a budget

You build A scaling study that charts speed and accuracy from one GPU to several.

Memory is the hard limit of GPU work. You estimate a dataset’s footprint before loading it, choose data types that shrink it, and plan chunking and spilling for the jobs that still do not fit.

• Estimating dataset size in device memory
• Choosing smaller data types safely
• Categoricals and string columns
• Chunking and out-of-core strategies
• Reading memory use with nvidia-smi and RMM
• Planning headroom for models

You build A memory sizing worksheet checked against measured use.

A speedup is a claim to test. You design benchmarks that compare libraries and hardware fairly, find the stages worth optimizing, and record results so that improvements survive future changes.

• Designing a fair benchmark
• Warm-up, caching and timing pitfalls
• Comparing libraries and instance types
• Finding the stage worth optimizing
• Cost set against time
• Recording results for later comparison

You build A benchmark suite that compares CPU and GPU versions of one workflow.

A model matters once it serves predictions. You export and deploy GPU-trained models, serve them with an inference server, and monitor accuracy, latency and drift after release.

• Exporting models for inference
• Forest inference on the GPU
• Serving with Triton Inference Server
• Batching and latency targets
• Monitoring accuracy and drift
• Updating a deployed model

You build A deployed model endpoint with monitoring for latency and drift.

Run one project through all of CRISP-DM. You analyze, prepare, train and benchmark on GPUs, size the work for memory, deploy it, and explain every choice of library and hardware.

• Framing the business question
• Preparing and exploring the data
• Training, tuning and benchmarking
• Sizing, deploying and monitoring
• Defending library and hardware choices

You build An accelerated data science project, from raw data to a monitored model, with its benchmarks.