NVIDIA Parabricks v4.7 Install Guide: GPU Genomics

By the end of this guide you’ll have a working GPU genomics pipeline: Parabricks v4.7.0-1 running inside a Docker container, aligning FASTQs to a reference genome in single-digit minutes instead of hours. One docker run command, four flags that matter, and the config decisions nobody warns you about.

Parabricks is NVIDIA’s GPU-accelerated re-implementation of the standard genomics stack – BWA, GATK, DeepVariant, STAR, Minimap2, and friends. It started at the University of Michigan and was acquired by NVIDIA in 2020. The tools produce output concordant with their CPU baselines, so you don’t have to re-validate downstream analyses.

The end state: one command that works

Here’s the command you’re building toward. Everything below explains why each piece exists.

docker run 
 --gpus all 
 --rm 
 --volume $(pwd):/workdir 
 --volume $(pwd):/outputdir 
 nvcr.io/nvidia/clara/clara-parabricks:4.7.0-1 
 pbrun fq2bam 
 --ref /workdir/Ref.fasta 
 --in-fq /workdir/sample_1.fq.gz /workdir/sample_2.fq.gz 
 --out-bam /outputdir/out.bam

That invocation replaces the old pbrun binary from pre-v4.0 releases – the official deploy docs are explicit about this. The container is the product now – there’s no host install, no compilation, no package manager to fight.

Hardware and software you actually need

Parabricks is stricter than a typical CUDA workload because the pipelines assume specific memory footprints. Skimming these numbers is where most failed installs start.

The requirements page says 16 GB VRAM “works” – but there’s a condition buried two paragraphs later. Three tools default to more than that. More on that below.

Prep the host

Verify your driver first. If nvidia-smi reports a CUDA Version older than 12.9.1, upgrade before touching anything else.

# confirm driver + CUDA
nvidia-smi

# confirm Docker
docker --version

# confirm NVIDIA Container Toolkit hook is wired into Docker
docker run --rm --gpus all nvcr.io/nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

If that last command prints your GPU table, you’re good. If it prints could not select device driver "" with capabilities: [[gpu]], the container toolkit isn’t configured – fix that before pulling Parabricks (see the errors section below).

Pull the container

Parabricks ships from NVIDIA’s NGC registry as a publicly available image. No account needed for the pull itself.

docker pull nvcr.io/nvidia/clara/clara-parabricks:4.7.0-1

Pull it once and cache it – every subsequent docker run reuses the local layer. On a metered or slow connection, plan accordingly before starting a batch job.

The 16 GB trap – and why three separate flags fix it

Turns out, “16 GB minimum” in the docs means “the container starts.” It does not mean every pipeline runs. Three tools default to memory footprints above that threshold:

• Giraffe (vg giraffe + GATK) – defaults to 40 GB per GPU. Add --low-memory to fit on a T4, L4, or A10.
• HaplotypeCaller – defaults to 18 GB. Add --htvc-low-memory.
• MutectCaller – defaults to 18 GB. Add --mutect-low-memory.

These are three separate flags. There’s no global “I have a small GPU” switch – you set them per tool. This is the single most common reason a Parabricks run fails on cloud GPUs like g5.12xlarge (4x A10G, 24 GB each) or g4dn (4x T4, 16 GB each).

Why the split? Each caller manages GPU memory differently under the hood – Giraffe loads a pangenome graph structure that simply doesn’t compress below ~40 GB at full resolution, while the variant callers have adjustable batch sizes. The low-memory flags trade throughput for footprint, not accuracy.

Cloud GPU tip: Check VRAM before compute-capability. A cheap 4x T4 instance runs fq2bam and DeepVariant without complaint – but tries to run Giraffe and dies with an OOM around 90 seconds in. Add the flag, or pay for A100s.

Verify the install

Skip the fake “hello world” and use a real fq2bam smoke test with tiny data. Grab the sample FASTQ pair from NVIDIA’s tutorial docs, drop them in your working directory, and run the command from the top of this article. If it produces out.bam and out.bam.bai in under two minutes, your GPU pipeline is live.

# Quick version-and-help check without any data
docker run --rm --gpus all 
 nvcr.io/nvidia/clara/clara-parabricks:4.7.0-1 
 pbrun fq2bam --help | head -20

Confirm the banner shows 4.7.0-1. That’s your ground truth – the docker tag lies if you pulled with :latest, but the runtime banner doesn’t.

Common install errors – real ones from the field

Error:failed to create shim task: OCI runtime create failed... nvidia-container-cli: initialization error: load library failed: libnvidia-ml.so.1: cannot open shared object file

This lit up GitHub issue #1092 on the nvidia-container-toolkit repo (May 2025) specifically on fresh Ubuntu 24.04 hosts. The driver looks fine in nvidia-smi, but the container toolkit can’t find the library. Fix: purge every trace of nvidia packages, reinstall nvidia-driver-570-server and nvidia-container-toolkit from the official repo, then sudo systemctl restart docker. Half-measures do not work here.

Error:unknown or invalid runtime name: nvidia

The toolkit is installed but Docker never got told about it. Run sudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker. This edits /etc/docker/daemon.json – if you have a hand-crafted daemon.json, back it up first.

Error:Failed to initialize NVML: Insufficient Permissions on RHEL/Rocky

SELinux blocks the container from touching device files. Add --security-opt=label=disable to your docker run, or write a proper SELinux policy. Most bioinformatics shops just disable the label.

Upgrading from v4.5 or v4.6

The tag change is the easy part. What actually changed: v4.7.0-1 added the pangenome_germline pipeline that fuses Giraffe with pangenome-aware DeepVariant end-to-end, plus first-class support for NVIDIA GB10 (DGX Spark). If you were running v4.5’s separate Giraffe → DeepVariant chain, you can collapse it into a single tool call now.

v4.6 (October 2025) also brought DeepVariant and DeepSomatic 1.9 with pangenome-aware mode, and STAR quantMode GeneCounts for gene-level counts at roughly 8x speedup on RTX PRO 6000. Jump straight from v4.5 to v4.7 and all of that came along for the ride – check the v4.7.0-1 release notes for the full diff.

# upgrade = pull new tag, retire old one
docker pull nvcr.io/nvidia/clara/clara-parabricks:4.7.0-1
docker image rm nvcr.io/nvidia/clara/clara-parabricks:4.5.0-1

Uninstall

Nothing installed on the host to remove – that’s the whole point of the container model. Cleanup is one command:

docker image rm nvcr.io/nvidia/clara/clara-parabricks:4.7.0-1
docker system prune -a # optional: reclaim other unused layers

To also strip the NVIDIA Container Toolkit: sudo apt-get remove --purge nvidia-container-toolkit. The GPU driver itself is separate – other CUDA workloads on the same host probably still need it.

Is the speedup real? A brief sanity check

The marketing line – 30x WGS in under 10 minutes – is measured on 4x RTX PRO 6000 Server Edition GPUs. Most readers don’t have that. Scale linearly at your own risk. The July 2025 Parabricks bioRxiv preprint puts it more concretely: 7.8x Smith-Waterman throughput on H100 vs A100, and nvCOMP DEFLATE hitting 18.19 GB/s decompression on H100. Different GPU, different curve.

What holds regardless of hardware: the 35-50x speedup vs a CPU BWA-GATK4 pipeline at 99.99% concordance. That’s the number that actually matters for justifying the GPU spend.

FAQ

Do I need an NGC account or API key to pull the Parabricks container?

No. The image is publicly available – docker pull works without credentials. An NGC account is only needed for enterprise-support features via NVIDIA AI Enterprise.

Can I run Parabricks on a single consumer GPU like an RTX 4090?

Technically yes. A 4090 has 24 GB and meets the compute capability requirements, so fq2bam and DeepVariant will run. In practice, a 30x WGS on one 4090 is still meaningfully slower than the four-GPU benchmarks you see quoted – and somatic pipelines like Mutect need the low-memory flag. Fine for method development and single-sample work. For production cohorts, you want multi-GPU.

Why Docker instead of a native binary or conda package?

Parabricks bundles specific CUDA, cuDNN, TensorRT, and nvCOMP versions that are painful to reproduce on a host. The container guarantees the exact stack the benchmarks were measured against. It also deploys identically on-prem, on DGX Cloud, or on any AWS/GCP/Azure GPU instance – which is why reproducibility is baked into the distribution model rather than left to the user.