+38% capacity across a transcription fleet, without buying hardware

The problem

Volume was about to double, and the question was “which machine to buy.” Before answering, I measured what the current fleet was wasting.

What was found

• The average audio file is 3.95 s, but the recognizer’s window is fixed at 30 s: the system was processing 7.6× the actual audio, almost all of it silence the system itself added.
• The temperature parameter isn’t a single number — it’s a fallback list. When the first pass doesn’t meet the thresholds, it resamples at a higher temperature, and best_of=5 multiplies each attempt by five. The triage was non-deterministic: 10.6% of transcripts diverged between two identical runs.
• Fixing it at zero gave −27% time, changing 0.5% of decisions, against a noise floor of 0.4% — and erring on the safe side.

Two “obvious” optimizations were rejected by the same benchmark: a voice activity detector (misses 2.4% of cases) and packing multiple audio files into the window (−65% time, but the model starts understanding the student and the error disappears). The damage from packing is a step function, not a ramp: two clips per window already cause 70% of the harm.

What was measured in production

The machine without the patch became an unintentional control group — the only one that didn’t improve. It’s what backs up the causal claim.

What the client didn’t need to do

Buy anything, yet. The purchase recommendation came later, once the numbers were reworked against real capacity.