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