All papers
Research paper · Working preprint · 2026

Deploying an audio deepfake detector across GPU, CPU and Android

Precision, Runtime and Platform in the Deployment of an Audio Deepfake Detector: A Measured Cross-Target Study

Ayush Sahu, Tarini Sai Padmanabhuni, Sanjith Kumar

Deployment systemsAudio deepfake detectionMeasured study
Configurations
7 inference configurations
Devices
GPU / server CPU / Android
Clips
4,000 scored per config
Audio
11.27 hours
Generators
62 synthetic

What the paper measures.

Audio deepfake detectors are increasingly proposed for use outside the datacentre, but published work reports detection accuracy far more often than the cost of running the model.

This study measures one 158.9M-parameter dual-stream detector across seven inference configurations spanning three device classes: an NVIDIA L4 GPU, a server CPU, and a 2021 Android handset, with three numerical precisions and four runtimes.

Every configuration scored the identical 4,000-clip, 11.27-hour out-of-distribution evaluation set, so each comparison is clip-paired and carries an explicit statement of what it holds fixed.

Across the seven configurations sustained capacity spans 312x while ROC-AUC spans 0.00040: for this model, choosing a deployment target is almost entirely a systems decision rather than a detection-quality one.

Headline measurements.

7
Inference configurations
4,000
Out-of-distribution clips
3
Device classes: GPU, CPU, Android
312x
Sustained capacity range
0.00040
ROC-AUC range
3.09x
FP16 GPU speedup
2.94x
INT8 CPU artifact compression
99.65%
Handset clips faster than real time

One model, seven configurations.

The study158.9M-parameter dual-stream audio deepfake detector
  • Devices: NVIDIA L4 GPU / AMD EPYC 9554 server CPU / OnePlus EB2101 handset (Android 11)
  • Precisions: FP32, FP16, INT8
  • Runtimes: PyTorch, ONNX Runtime, TensorRT, ONNX Runtime (Android)
Evaluation set4,000 clips
  • 2,000 bona fide / 2,000 synthetic
  • 11.27 hours of audio
  • 6 languages, none in the training split
  • 62 synthetic generators
Out-of-distribution by construction: every configuration scored the identical clip set, in the same order, so comparisons are clip-paired.

Three deployment points.

One detector, one graph, three device classes, each measured on the figure that matters for where it runs.

GPU14.4 msmedian per clip
  • FP16 / PyTorch / NVIDIA L4
  • Artifact 303.2 MiB
CPU2.94xsmaller artifact than FP32
  • INT8 dynamic / ONNX Runtime / EPYC 9554
  • Artifact 177.7 MiB
Android99.65%of clips faster than real time
  • INT8 dynamic / ONNX Runtime / OnePlus EB2101
  • Artifact 177.7 MiB

Findings.

GPU / reduced precision

FP32 PyTorch on the L4 is the reference point at 43.9 ms median per clip. Casting the weights to FP16, with the same code path, thread count and warm-up policy, drops the median to 14.4 ms, a 3.09x per-clip speedup, while the artifact halves from 606.3 MiB to 303.2 MiB. Only 2 of 4,000 labels change.

43.9 ms to 14.4 ms
Median per-clip latency
606.3 to 303.2 MiB
Artifact size
2 / 4,000
Labels changed

CPU / INT8 quantization

At fixed runtime, ONNX Runtime on both sides, dynamic INT8 cuts the median from 498.9 ms to 420.9 ms, about 1.18x, while compressing the artifact from 522.6 MiB to 177.7 MiB, roughly 2.94x smaller. The aggregate speedup is smaller than the arithmetic one because a fixed ~91 ms per-call overhead does not scale with audio length, so short clips benefit least.

498.9 ms to 420.9 ms
Median per-clip latency
522.6 to 177.7 MiB
Artifact size (2.94x)
1.18x
Median speedup

Android / the platform effect in isolation

The byte-identical INT8 graph was moved from the server CPU to the handset, so the platform is the only thing that changes. Detection behaviour holds: ROC-AUC differs by 1.0 x 10^-5, 3,993 of 4,000 labels are unchanged, and the exact McNemar test on the discordant pairs gives p = 1.0. For this model and this graph, the handset delivers the same detection quality as the server.

0.00001
ROC-AUC difference
3,993 / 4,000
Labels unchanged
p = 1.0
Exact McNemar test

Real-time behaviour on the phone

Judged against the actual duration of each clip, the handset stays ahead of the audio for 3,986 of 4,000 clips, 99.65%, at a median real-time factor of 0.634, with no accelerator delegate engaged: CPU-only, four of eight cores.

99.65%
Clips faster than real time
0.634
Median real-time factor
CPU-only
No NNAPI / GPU / DSP delegate

Deployment target is a systems decision.

312x
Sustained capacity range
0.00040
ROC-AUC range

Across the seven configurations, sustained capacity spans 312x while ROC-AUC spans 0.00040. The device moves cost by factors of nine to fourteen at each step; the largest precision gain available within a device is 3.09x. What limits deployed accuracy is neither the device nor the numerics but the decision threshold.

Read the paper.

Full text, 25 pages, rendered here on the page. No download.

1 / 25
Page 1 of 25
Next paperDo generator artifacts survive a language change?

Test it against the conditions your calls actually have.

Evaluate Detectif.ai on your own channels, codecs, languages and generators.