What published benchmarks show about accelerating variant calling and genomic models

Moving germline variant calling from CPUs to GPUs or DRAGEN servers cuts a whole-genome run from 17 to 39 hours to between half an hour and about two hours, and the one study that compared the calls with the CPU pipeline found close agreement. These speed gains come from hardware acceleration of established algorithms, not from machine learning. No study reruns a pipeline to test whether its calls repeat. For a genomic foundation model, FP8 precision gave at most 19.3% more throughput.

Evidence tables: every comparison in this review, with per-configuration values and source details, is on the Large-scale diagnostic genomics model execution use case in the Rewire benchmark database.

The question for a lab director is which hardware and software configuration can process the lab's genomes within its turnaround, budget and reproducibility requirements without changing the calls. That splits into four measurable parts: wall-clock time per sample, cost per sample, memory and hardware needed, and whether accelerated or reduced-precision execution gives the same results as the established CPU pipeline. This review covers five published execution benchmarks of variant-calling pipelines, the DRAGEN developers' runtime, one benchmark of foundation-model inference at reduced precision, and two studies whose tables are internally inconsistent. I did not rerun any pipeline. Values from different studies cannot be pooled, because hardware, inputs and software versions differ between them.

How the execution families work

Every short-read germline pipeline does two expensive things: it aligns reads to the reference, then calls variants from the aligned reads. The families below differ in what hardware runs those steps and whether the calling step uses a trained model.

Execution routes for one genome and what the published studies measured. Diagram by the author.

CPU reference pipelines. BWA-MEM aligns reads, GATK marks duplicates and recalibrates base qualities, and HaplotypeCaller reassembles candidate haplotypes in active regions and genotypes them with a pair hidden Markov model. Samarakoon and colleagues describe this as the gold-standard CPU pipeline, run here as GATK 4.0.3.0 on AMD EPYC 7702 servers (Samarakoon et al. 2025). It is open source and well documented, and it is slow: each stage is parallelised across CPU cores or genomic intervals.

GPU reimplementations. NVIDIA Parabricks ports BWA-MEM, HaplotypeCaller, DeepVariant and several somatic callers to GPUs. The aim is to reproduce the CPU tool's output faster, not to change the algorithm. Parabricks is closed source, which Samarakoon and colleagues note limits inspection of its logic. It needs no paid licence (Franzoso et al. 2025).

FPGA hardware. Illumina's DRAGEN runs mapping and its own germline small-variant caller (GSVC) on field-programmable gate arrays, either in an on-premise DRAGEN server or in cloud instances with FPGAs (Behera et al. 2024). Its caller is not a port of HaplotypeCaller, so its calls are expected to differ.

CPU-optimised and hybrid ML callers. Sentieon reimplements BWA and GATK algorithms for faster CPU execution. Its DNAscope pipeline adds a trained model: candidate variants from a haplotype-based caller are genotyped by a machine-learned model that uses variant annotations as features, a gradient boosting machine (Hu et al. 2026). DNAscope Hybrid combines short and long reads from one sample. Sentieon needs a paid licence.

Deep-learning callers. DeepVariant converts read pileups into images and classifies genotypes with a convolutional neural network. It runs on CPUs or, through Parabricks, on GPUs. Clair3 is a long-read caller that uses a pileup network and a full-alignment network, with a newer GPU mode.

Genomic foundation models. These are large sequence models trained on genomes and used for embeddings, variant-effect scores or sequence generation. They are not variant callers. Their execution cost is set by parameter count, sequence length and numeric precision. Precision is the number format used for weights and activations: FP32 uses 32 bits, BF16 16 bits and FP8 8 bits. Fewer bits mean less memory traffic and faster matrix arithmetic on recent GPUs, at some risk of changing the output.

CPU, GPU and DRAGEN on ten genomes

The most complete comparison is by Pubudu Saneth Samarakoon, Alex Rodriguez and colleagues at the University of Oslo and Oslo University Hospital, published in Bioinformatics Advances. They declare no competing interests and did not develop either accelerated platform. They ran ten WGS samples, six high-coverage Illumina Platinum Genomes and four low-coverage 1000 Genomes samples, through a CPU-only GATK pipeline, Parabricks on four L4, four A100 and eight H100 GPUs, and DRAGEN v4.2 on an Illumina DRAGEN server.

For NA12878 at 47.55x, read mapping plus HaplotypeCaller took 2,317.7 minutes on CPUs. The accelerated set-ups took between 54.22 and 123.45 minutes.

Samarakoon et al. 2025, Supplementary Table S3. Hardware differs between columns, so differences mix software and hardware. One value per sample and set-up.

Across the ten samples, the authors report mapping speedups over CPU of about 10 to 14 on L4, 19 to 24 on A100, 20 to 30 on H100 and 23 to 31 for DRAGEN. Variant calling gained more: about 49 to 78 for DRAGEN GSVC and 49 to 117 for Parabricks HaplotypeCaller on L4 and A100. Mapping speedup on H100 and DRAGEN rose with coverage, while variant-calling speedup fell with coverage on every platform.

The CPU nodes were shared with other users, and the cloud GPUs ran in a multi-tenant environment, so the CPU times may include contention. One total, NA12778 on L4, does not equal the sum of its stages and cannot be used.

The authors also give purchase and rental estimates rather than measured costs. A cloud machine with four L4 GPUs cost 4.01 USD per hour and a spot machine with eight H100s 48.77 USD per hour. They estimate a DRAGEN server at about 90,000 USD with three years of support, plus a 12,000 USD annual licence for 100,000 gigabases.

Accuracy and agreement with the CPU calls

Samarakoon and colleagues are the only group here to check whether acceleration changed the calls. They used hap.py with the vcfeval engine in two ways. First, they scored accelerated calls against the Platinum Genomes high-confidence truth sets for NA12877 and NA12878. Second, they used the CPU-only GATK calls as the reference and scored each accelerated caller's agreement with them.

Figure 5 from Samarakoon et al. 2025, Bioinformatics Advances, CC BY 4.0. Top: accuracy against Platinum Genomes truth. Bottom: concordance with the CPU-only GATK calls.

Against the truth sets, all accelerated callers had near-perfect SNV recall and indel recall above 0.98, with lower indel precision. Against the CPU calls, Parabricks HaplotypeCaller reproduced the CPU output almost exactly. Parabricks DeepVariant agreed closely on SNVs and deviated slightly on indels, which is expected for a different algorithm. DRAGEN GSVC deviated most, with F1 above 0.93 according to the text.

These values exist only as points in a figure. No table gives them, and the CPU baseline's own accuracy against the truth set is not plotted beside the accelerated callers. Calls were unfiltered, so the result does not cover the hard filters a clinical pipeline would add.

The same group ran Parabricks DeepVariant on the same H100 machine with two releases. NA12878 took 14.58 minutes with the release used in the pipeline and 16.05 minutes with the update. The paper gives three different version strings for these runs, so the exact versions are uncertain. A version change altered runtime on fixed hardware, and nobody measured whether it altered the calls.

Cloud cost depends on the caller

Kyle O'Connell and colleagues at Deloitte Consulting ran two germline and four somatic callers on one HG002 genome down-sampled to 30x, in BMC Bioinformatics. Their employer funded the study and is an NVIDIA, AWS and Google alliance partner; they did not develop Parabricks or the callers. Somatic inputs were a synthetic tumour made by adding 198 SNVs to the same genome.

On Google Cloud, HaplotypeCaller v4.2.0.0 took 38.8 hours and cost 67.9 USD on a 32-vCPU machine, and 0.59 hours and 17.5 USD on eight A100 GPUs, a printed speedup of 65.8. DeepVariant v1.1.0 took 18.8 hours and 32.9 USD on CPU, and 1.2 hours and 18.3 USD on four A100s.

The somatic callers behaved differently. LoFreq cost 8.1 USD on the CPU machine and 19, 27.1 and 30.1 USD on two, four and eight A100s. Mutect2 cost 14.2 USD on CPU and 15.2 USD on eight A100s, although it ran 15.7 times faster. The authors conclude that, with the Parabricks version they tested, poorly accelerated tools cost more on GPUs.

Two points limit this study. Each configuration is one recorded run; DGX runs were repeated at least three times but only the final run is shown. The GPU type behind the AWS rows is unresolved, because a table footnote says V100 and the text says A100.

Matched hourly cost on Google Cloud

Eugenio Franzoso, Mariangela Santorsola and Francesco Lescai at the University of Pavia compared Sentieon DNASeq 202308 with Parabricks Germline 4.0.1-1 on five exomes and five genomes, in Clinical and Translational Science. They declare no conflicts. Instead of matching hardware, they matched hourly price: a 64-vCPU machine at 1.79 USD per hour for Sentieon and a 48-vCPU machine with one T4 GPU at 1.65 USD per hour for Parabricks.

Franzoso et al. 2025, Table S2, five samples per row. Two genome runtime cells print values that cannot be genome runtimes (0:03:21 and 0:04:41) and are left out of the ranges.

At this price point the two were close: Parabricks faster on exomes, Sentieon faster on genomes, costs overlapping. The costs exclude the Sentieon licence, which the authors note is required. A single entry-level T4 is a weaker GPU than the A100s and H100s in the other studies.

Runtime against read depth

Stefano Marangoni and colleagues at the Italian Institute of Technology in Aosta built GeNePi, a Nextflow pipeline whose germline module wraps Parabricks, in Briefings in Bioinformatics. They declare no competing interests. Because they built the pipeline, the GPU rows are developer-reported. They timed one unnamed human genome per depth from 30x to 100x on three GPU nodes and a CPU node running the equivalent GATK workflow.

Figure 2 from Marangoni et al. 2026, Briefings in Bioinformatics, CC BY 4.0. Runtime of Parabricks and CPU GATK germline workflows by read depth on four hardware configurations.

A 30x genome took 17 hours on the CPU node, and 1 hour 36 minutes, 42 minutes and 30 minutes on two V100s, two A100s and four A100s. At 100x the same configurations took 60 hours, 6 hours 30 minutes, 2 hours 30 minutes and 2 hours 6 minutes. Runtime rose almost linearly with depth on every configuration.

The article's Discussion states a 10- to 78-fold average acceleration. The ratios in its Supplementary Table S1 run from about 10 to 34, so the upper figure comes from runs not shown in that table. The number of runs behind each value is not stated, and the CPU times are printed in whole hours.

DNAscope on one cloud instance

Jinnan Hu, Donald Freed and colleagues, all employed by Sentieon, timed three DNAscope pipelines on one Azure HB120rs v3 instance with 120 vCPUs and 456 GiB of memory, in Frontiers in Bioinformatics. DNAscope took 18.9 minutes and 37.8 core-hours for 30x Illumina reads, at 1.1 USD on demand or 0.11 USD on spot pricing. DNAscope LongRead took 41.2 minutes for 30x PacBio HiFi at 2.5 USD. DNAscope Hybrid took 85.8 minutes for 10x HiFi plus 35x Illumina at 5.2 USD.

Each pipeline had different input data, so the three are not a ranking. Costs exclude the licence, the sample behind the table is not named, and the software version for the timing is not stated. The table has no GATK row, so it gives no same-data comparison with the CPU baseline.

The DRAGEN developer figure

Illumina's DRAGEN paper by Behera and colleagues, in Nature Biotechnology, reports a DRAGEN 4.2 total runtime for HG002 of 1,838.5 seconds on one hardware configuration and 5,521.21 seconds on an AWS f1.4xlarge FPGA instance. These are developer-reported single values. Stage times in that table cannot be summed, because stages run concurrently.

Reduced precision for a genomic foundation model

Mutian Yu, Lizhen Shi and colleagues at Northwestern University and the DOE Joint Genome Institute, which develops GenomeOcean, tested FP8 inference on GenomeOcean models of 100M, 500M and 4B parameters, in a bioRxiv preprint that has not been peer reviewed. All runs used one H100 SXM5 GPU with 80 GB of memory, bacterial genomes from GTDB, and five trials per configuration. This is the only study here that prints spread over repeated runs.

FP8 workloads and results from Yu et al. 2026 (preprint), GenomeOcean on one H100. Diagram by the author.

H100 tensor cores multiply FP8 matrices at about twice the BF16 rate. Realised gains were far smaller. For embedding extraction with FP8 weights, throughput fell by 24.9% at 100M parameters and by 11.1% at 500M, and rose by 4.7% at 4B. With the 4B model, BF16 processed 21,386 ± 126 input tokens per second with 72.14 GB peak GPU memory, and FP8 22,401 ± 204 with 67.91 GB. The authors attribute the losses at small scale to fixed costs of scaling, casting and kernel dispatch that outweigh faster arithmetic.

Generation gained more, mostly from compressing the key-value cache. The 4B model generated 1,818.79 ± 7.95 tokens per second in BF16, 2,085.89 ± 34.49 with an FP8 KV cache, and 2,169.04 ± 24.30 with FP8 weights, activations and KV cache, the 19.3% best case. Power fell from 692.40 to 647.01 W. At small batch sizes, FP8 KV-cache generation was slower than BF16.

Output fidelity changed little. Metagenomic binning on 4B embeddings scored an adjusted Rand index of 0.5278 ± 0.0672 in BF16 and 0.5280 ± 0.0653 in FP8. Perplexity on 96 GTDB sequences rose from 125.97 to 128.73. Neither measure is a diagnostic output, and the inputs are microbial genomes, not human samples.

My own runs of Evo 2 7B point the same way on reproducibility. Two H100s on different clouds gave bit-identical variant scores, while an L40S running the same container reordered the ranking, and FP32 restored agreement at three to six times the compute. For foundation models, the GPU model and number format are part of the method.

Two studies with inconsistent tables

Two further benchmarks bear on this question, but their printed values cannot be used as they stand. Zhenxian Zheng and colleagues at the University of Hong Kong, who develop Clair3, compared Clair3 in GPU mode with DeepVariant on HG003 long reads, in Bioinformatics. Their supplementary runtime table differs from their Results text for apparently the same runs, names a different DeepVariant version, and gives DeepVariant accuracy values that differ from the text. Accuracy also uses the GIAB v4.2.1 confident regions of one sample, which exclude the hardest regions.

Aspidova and colleagues, who develop ModernGENA and GENA-LM, timed four DNA language model families on one A100 in a bioRxiv preprint. Their printed tokens per second are far too low for the printed batch sizes and their own stated training throughput, so the unit or scale is unclear. Until the authors resolve these points, neither study can rank configurations.

The method families compared

Values are from the studies above and are not comparable across rows, because inputs and hardware differ.

The baseline

The baseline here is the CPU GATK best-practice pipeline: BWA-MEM alignment, duplicate marking, base-quality recalibration and HaplotypeCaller. It is the baseline because it is the pipeline the accelerated tools were built to reproduce, it is open source, and every short-read study here uses it, or Sentieon's reimplementation of it, as the reference point for speedup and agreement. It contains no trained model.

The baseline is not the truth. Truth comes from characterised reference samples: Platinum Genomes high-confidence calls for NA12877 and NA12878 in Samarakoon et al., and GIAB benchmarks for HG002 and HG003 elsewhere. An accelerated or ML method preserves accuracy only if it scores at least as well against that truth on the same data. Agreement with the CPU calls shows that acceleration did not change the output, which is a separate question.

So no machine-learning caller or foundation model has been shown, in a same-data table, to beat the CPU baseline on accuracy. The large speed gains come from hardware acceleration of established algorithms. DeepVariant is faster than HaplotypeCaller on CPUs in O'Connell's data, but its accuracy was not tabulated beside the baseline's.

What has not been measured

• No study reruns a variant-calling pipeline on the same input and compares the calls. Run-to-run reproducibility on GPUs or FPGAs is unmeasured.
• No study prints accuracy against a truth set in the same table as runtime for the same runs. Samarakoon et al. show it only in a figure.
• No short-read germline study prints peak memory in a table; two show it only in figures.
• No study measures a genomic foundation model inside a diagnostic workflow on human data. The one usable foundation-model benchmark uses bacterial genomes.
• Apart from the five GenomeOcean trials, each value is one printed number per sample and configuration, on at most ten samples. Marangoni et al. and Hu et al. do not state how many runs lie behind each value.
• Hardware differs within almost every comparison, so the effect of software cannot be separated from that of hardware.
• Costs are list prices or authors' estimates at the time of each study and exclude Sentieon and DRAGEN licences, storage and staff time.
• No study tests filtered call sets, which is what a clinical report uses.

What would change the picture

The most useful study would run the CPU GATK pipeline, Parabricks, DRAGEN and DeepVariant on the same GIAB samples at several depths, on stated hardware, with each configuration repeated several times. It would print runtime, cost, peak memory, accuracy against the truth set and pairwise concordance of the calls in one table, before and after a software version update. A second study would put a genomic foundation model inside a diagnostic task on human data, such as variant-effect scoring, and measure whether its scores repeat across GPU types and precisions.

Until then, the evidence supports a narrow conclusion. GPU and DRAGEN execution make a 30x genome a job of two hours or less rather than most of a day or more. One independent study found the GPU port of HaplotypeCaller reproduces the CPU calls. Whether a given configuration gives the same calls on every run, and whether a foundation model's scores survive a change of hardware, are questions each lab still has to test on its own samples.

Per-configuration values and source details for every study above are in the Large-scale diagnostic genomics model execution use case.