Running GPU-accelerated pipelines

Some nf-core pipelines can run specific steps on a GPU instead of a CPU, for example, tools like NVIDIA Parabricks, GPU-accelerated basecallers, or machine-learning-based classifiers. GPU support is opt-in and pipeline-specific: there is no single flag that turns on GPU acceleration across all of nf-core. Always check the pipeline’s own docs/usage.md for the exact parameter names before you run.

Currently, GPU acceleration typically assumes you have Nvidia/CUDA capable cards (e.g. AMD GPUs are unfortunately currently not supported).

This page assumes you’re already comfortable with -profile and custom configuration files — see Configuration options first if not.

How pipelines expose GPU support

Two patterns currently exist across nf-core pipelines, and you need to know which one your pipeline uses.

Pattern 1: a standalone parameter, no profile required

Some pipelines gate GPU acceleration entirely behind a boolean parameter, with no separate profile needed. For example, nf-core/rnaseq accelerates rRNA removal and STAR alignment this way:

nextflow run nf-core/rnaseq \
--input samplesheet.csv \
--outdir results \
--remove_ribo_rna --ribo_removal_tool ribodetector --use_gpu_ribodetector \
-profile docker

Here, --use_gpu_ribodetector is enough on its own — -profile docker (or singularity) is the same profile you would use for a CPU-only run. The GPU container flags (--gpus all for Docker, --nv for Singularity/Apptainer) are applied automatically, and only to the GPU-enabled step. Other steps in the same run are unaffected and continue to run normally on CPU-only nodes, which matters on a shared or mixed cluster.

Pattern 2: a feature parameter combined with -profile gpu

Other GPU integrations instead require you to add a gpu profile alongside a feature parameter that selects the GPU-based tool. For example, nf-core/sarek:

nextflow run nf-core/sarek \
--input samplesheet.csv \
--outdir results \
--aligner parabricks \
-profile docker,gpu

or nf-core/methylseq:

nextflow run nf-core/methylseq \
--aligner bwameth \
-profile gpu \
--input samplesheet.csv --genome GRCh38

In this pattern, the gpu profile might set the container engine’s GPU flags globally (docker.runOptions, singularity.runOptions, etc.), so every process in the run gets them — not just the GPU-accelerated one - check the pipeline configuration.

Check the pipeline’s usage docs for whether you also need to set the accelerator directive yourself in a custom config — some pipelines only set it automatically on cloud/Kubernetes executors (awsbatch, google-batch, k8s, hq), leaving it up to you elsewhere.

Running on a shared cluster (HPC)

If your institution has a profile in nf-core/configs, GPU-enabled processes are usually already routed to the right queue or partition, with the correct scheduler flags (SLURM --gres=gpu:N, LSF -gpu num=N, PBS -l select=...:ngpus=N) added for you — you don’t need to work these out yourself.

Combine your institution’s profile with whichever GPU mechanism your pipeline needs:

# Pattern 1 pipeline (institution profile only)
nextflow run nf-core/rnaseq --use_gpu_ribodetector -profile <institution>
# Pattern 2 pipeline (institution profile plus the pipeline's own gpu profile)
nextflow run nf-core/sarek --aligner parabricks -profile gpu,<institution>

Check nf-core/configs to see if your cluster already has a profile, and read its docs/<institution>.md page — most include a copy-paste command for GPU runs on that system.

Overriding GPU settings for a single run

To request more GPUs or target specific hardware for one run, add a custom config with -c that targets the process by name:

custom-gpu.config
process {
withName: 'RIBODETECTOR' {
accelerator = [request: 2, type: 'a100']
}
}

Only set clusterOptions yourself if there’s no institutional profile doing this translation, or its clusterOptions hardcodes a flag instead of reading task.accelerator:

custom-gpu.config
process {
withName: 'RIBODETECTOR' {
accelerator = [request: 2, type: 'a100']
clusterOptions = '--gpus=a100:2'
}
}

See Customize process resources for how to find the exact process name to target, including cases where a tool is used more than once in the same pipeline.

See also