TM 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
- Deployment systems
- Audio deepfake detection
- Measured 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.
Read more detail+
The evaluation set is out-of-distribution by construction: 2,000 bona fide and 2,000 synthetic clips in six languages (de, ja, ko, nl, pl, zh-cn), none of which appear in the model's training split, with the synthetic half spanning 62 distinct generators.
Casting GPU weights to FP16 is the largest single-factor gain measured: median per-clip latency falls from 43.9 ms to 14.4 ms (3.09x) and only 2 of 4,000 labels change. On the CPU, at fixed runtime, dynamic INT8 cuts median latency from 498.9 ms to 420.9 ms (1.18x) and the artifact from 522.6 MiB to 177.7 MiB (2.94x).
Moving the byte-identical INT8 graph to the handset costs 13.88x per clip (median 5.86 s) while changing ROC-AUC by 1.0 x 10^-5 and 7 of 4,000 labels (exact McNemar p = 1.0). Mobile deployment cost speed, not detection quality, for this model and this graph.
The device dominates at both steps: GPU to CPU costs 8.70x at the median with framework, precision and code path fixed, and server CPU to handset a further 13.88x with the model file itself held fixed. No precision reduction measured here closes either gap.
The paper's principal output is a suitability matrix over nine operational scenarios, mapping each one's binding constraint onto the configuration it selects, with every cell backed by a measured row.
Headline measurements.
One model, seven configurations.
The study
158.9M-parameter dual-stream audio deepfake detector
- Devices
- NVIDIA L4 GPU / AMD EPYC 9554 server CPU / OnePlus EB2101 handset (Android 11)
- Precisions
- FP32FP16INT8
- Runtimes
- PyTorchONNX RuntimeTensorRTONNX Runtime (Android)
Evaluation set
- 4,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.
Not a device competition: a handset is not trying to replace an L4. Median per-clip inference latency, drawn on a log scale.
FP16 / PyTorch / NVIDIA L4
Artifact 303.2 MiB
3.09x faster than the FP32 GPU baseline; 2 of 4,000 labels changed.
INT8 dynamic / ONNX Runtime / EPYC 9554
Artifact 177.7 MiB
1.18x faster than FP32 at fixed runtime; artifact 2.94x smaller.
INT8 dynamic / ONNX Runtime / OnePlus EB2101
Artifact 177.7 MiB
Byte-identical graph to the CPU row; 13.88x slower, ROC-AUC differs by 1.0 x 10^-5.
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. Per-clip cost rises 13.88x to a 5.86 s median, and every one of the 4,000 clips is slower. Detection behaviour does not follow: ROC-AUC differs by 1.0 x 10^-5, 7 of 4,000 labels change, and the exact McNemar test on those discordant pairs gives p = 1.0. For this model and this graph, mobile deployment cost speed, not detection quality.
- 5.86 s
- Median per-clip latency
- 0.00001
- ROC-AUC difference
- 7 / 4,000
- Labels changed
Real-time behaviour on the phone
Slower than the server does not mean too slow. 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
Sustained load, not a short benchmark
Over a continuous 7.39-hour run the device does not hold its initial speed. Per-window inference cost rises 1.60x from the first 400 clips to the last, and the rise is not gradual: clustering recovers three well-separated operating points at 1,176, 1,424 and 1,875 ms per window. Controlled against clip length and class composition, the pattern is the signature of frequency capping under a thermal or power budget, which means continuous on-device screening has to be provisioned from the throttled state, not the benchmark state.
- 7.4 h
- Continuous run
- 1.60x
- Per-window cost degradation
- 3 states
- Discrete frequency plateaus
Deployment target is a systems decision.
312xSustained capacity range
0.00040ROC-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.
