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 dockerHere, --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,gpunextflow run nf-core/methylseq \ --aligner bwameth \ -profile gpu \ --input samplesheet.csv --genome GRCh38In 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:
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:
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
- Configuration options
- Institutional profiles
- GPU-capable modules — for pipeline and module developers