Parakeet vs Whisper CPU Throughput: the 12x Spread Is Language, Not File Length

• Whisper's median throughput varies 12x by language on files over two minutes: 0.736 for Hindi against 0.061 for Japanese, on the same box, same week.
• Parakeet's median varies only 1.7x, from 0.118 for French to 0.068 for German, which is why Parakeet can be sized from a single number and Whisper cannot.
• File length is not the driver. On files over two minutes, Whisper's median moves from 0.155 to 0.221 across length buckets, a 1.4x range, against the 12x that language produces. The gap only widens once the spread is allowed to include thin cells: 49x.
• The extreme case is Burmese. Two jobs, both around 17 minutes, ran at a median 3.008 and a worst of 3.219, higher than every language with more than a couple of jobs by an order of magnitude.
• The engine gap is real but second-order. Controlling for length, Parakeet runs at 0.099 against Whisper's 0.160, a 1.6x difference. A shift in language mix can erase or double that advantage without any code change.
• The p90s differ by 4x. 0.199 for Parakeet against 0.804 for Whisper on the same over-two-minute files, which matters more than the median if you size against a timeout.

Hardware: one shared container, 2 vCPU budget, up to two jobs concurrently. Parakeet is the int8 ONNX export with the memory arena disabled; Whisper is faster-whisper small at int8. Real-time factor is always seconds of processing per second of audio. See methodology and the companion benchmark.

Start with the number people quote, because it is real and because it is the wrong place to stop. Across all 1,231 jobs, Parakeet's median real-time factor is 0.141 and Whisper's is 0.296, a 2.1x gap that mostly reflects the different work each engine gets. Restrict to files over two minutes, where per-job overhead is a small share of runtime, and the honest comparison appears: Parakeet at 0.099 (n=677) against Whisper at 0.160 (n=111), a 1.6x gap.

1.6x

Parakeet's per-second advantage over Whisper, controlling for file length

0.099 vs 0.160, files over two minutes, n=677 and 111.

That is a useful number for choosing an engine. It is a terrible number for sizing a box, for one reason: it is an average over languages, and the variance across languages swamps the difference between engines. The rest of this post is about that variance, because it is the thing a capacity plan made from any single average will get wrong.

Splitting the over-two-minute jobs by detected language, with the same minimum-job thresholds the companion post uses, Whisper's median real-time factor ranges from 0.061 to 0.736. That is a 12.0x spread on identical hardware, produced by nothing but the language being decoded.

Engine	Language	Jobs	Median RTF
whisper	Hindi	10	0.736
whisper	Urdu	4	0.277
whisper	Arabic	14	0.185
whisper	Malay	9	0.138
whisper	Chinese	21	0.133
whisper	Tagalog	10	0.115
whisper	Indonesian	5	0.105
whisper	Japanese	9	0.061
parakeet	French	14	0.118
parakeet	English	448	0.108
parakeet	Italian	9	0.106
parakeet	Spanish	100	0.095
parakeet	Lithuanian	14	0.081
parakeet	Portuguese	40	0.081
parakeet	Russian	29	0.069
parakeet	German	9	0.068

Whisper cells need 4 or more jobs, Parakeet cells 8 or more, matching the companion benchmark's thresholds. Whisper spread 12.0x, Parakeet spread 1.7x. Burmese is excluded here because it has two jobs; it appears in its own section below.

The mechanism is not mysterious, and it is worth understanding because it tells you which languages will be expensive. Whisper is an autoregressive encoder-decoder: it emits output tokens one at a time, so its decode cost scales with how many tokens the text produces. Languages whose scripts tokenize poorly in Whisper's vocabulary produce far more tokens per second of speech, and each token costs a decode step. Hindi sits at 0.736, ten seconds of compute per thirteen seconds of audio, because Devanagari text fragments into a long token stream. Japanese at 0.061 is the fast end, not because Japanese is easy but because its characters map densely onto tokens.

Parakeet-TDT is a transducer with a token-and-duration prediction head over a fixed frame grid. Its cost tracks audio length rather than output length, so the language barely moves it: 1.7x from French to German, against Whisper's 12.0x. The practical consequence is the sharpest thing in this dataset: a Whisper deployment sized from an English benchmark can be wrong by an order of magnitude for Indic-language traffic, and nothing in the code changed.

The obvious alternative explanation for any throughput spread is file length: longer files amortize fixed overhead, so their real-time factors look better. The data says that is a second-order effect, and the comparison is the post's core claim.

Audio length	Parakeet n	Parakeet median	Whisper n	Whisper median
under 1 min	237	0.255	70	1.253
1 to 5 min	254	0.132	61	0.221
5 to 30 min	304	0.076	45	0.155
over 30 min	220	0.109	40	0.157

Medians, seconds of processing per second of audio. The sub-minute cells are dominated by fixed overhead, which is why both engines look bad there; the companion post covers that in depth. Above two minutes, length moves each engine's median by at most 1.4x.

Read the rows the way a skeptic would. Whisper's sub-minute median of 1.253 is overhead, not language: a short file pays the download and language-detection cost against almost no audio. But from the 1-to-5-minute row onward, where overhead is a small share, Whisper's median moves only from 0.221 to 0.155, a 1.4x range, across files from two minutes to over half an hour. Parakeet moves similarly, from 0.132 to 0.109, and its U-shape above 30 minutes is unexplained in the companion post too.

Now put the two spreads next to each other. Whisper by length, overhead excluded: 1.4x. Whisper by language, same files: 12.0x. The length effect is an eighth of the language effect, and the language effect is the one nobody measures. The same table also shows why the per-language comparison must use the over-two-minute files: at shorter lengths, the overhead would masquerade as language.

An internal note first recorded Whisper's worst case as 3.22x realtime on Burmese, and when the fuller extraction arrived, that figure was initially written off as a fixed-overhead artifact, the way the sub-minute tail usually is. The two Burmese jobs in the extraction make that reading untenable, and they are worth their own paragraph because they are the extreme case this dataset has.

3.008

median real-time factor for the two Burmese jobs, both around 17 minutes of audio

Worst of the two: 3.219. Every other language with more than a couple of jobs sits below 0.736.

Both jobs are 1,026 seconds of audio, roughly 17 minutes, and they took 55 and 48 minutes to process respectively. The overhead explanation cannot cover that: a 17-minute file has already amortized the download and detection costs that dominate sub-minute jobs. Burmese text is agglutinative and its script fragments aggressively in Whisper's tokenizer, which is the same mechanism as Hindi, only sharper, and the numbers agree: 3.008 here against 0.736 for Hindi.

The honest caveat is the cell size. Two jobs is the thinnest cell in this dataset, and a median built on two files deserves a re-measure before it is used for planning, which is why Burmese is excluded from the main table and presented here alone. But two jobs is enough to say what the data says: the language-driven spread is real, it extends far past the 12.0x of the well-populated table, and once you count the one- and two-job languages the full spread is 49x. A capacity plan that ignores language is planning for the median case in a distribution whose tail is fifty times the median.

The concrete guidance, in the order it matters:

• Measure your language mix before you size anything. On Whisper, the difference between a Japanese-heavy and a Hindi-heavy workload is 12x before you consider any other variable.
• Size Parakeet from one number, Whisper from a per-language table. Parakeet's 1.7x spread means a single median works; Whisper's does not.
• Budget for the p90, not the median. 0.199 for Parakeet and 0.804 for Whisper on the same files; a queue sized to the median will back up on the tail.
• If your mix is multilingual, the engine choice matters less than the mix itself. The 1.6x engine gap is real; a language shift can swamp it.
• Re-measure quarterly. The companion post showed the same code swinging 2.5x week to week from contention alone.

None of this is an argument about accuracy. Parakeet being faster and flatter does not mean it is better, and it covers a smaller language set, which is exactly why Whisper stays in the pipeline. The argument here is narrower and purely about time: throughput is a property of the language, then of the engine, and almost never of the file.

These are production jobs, not a benchmark suite, reconstructed from the transcription worker's own logs between August 1 and 20, 2026. The join and its verification are described in full in the companion benchmark's methodology; in short, three independent log lines must agree on job identity, language and segment count, and the window count each job logs must match its duration divided by the engine's window size, which eliminates mis-pairings. Of 1,256 candidate pairs, 1,231 survived the checks.

The engines are selected by language, so the comparison is confounded with language by construction. The per-language table is the honest exposure of that confound rather than a removal of it: no single audio file was transcribed by both engines, so every comparison is between distributions, not between runs.

All real-time factors are the worker's own end-to-end elapsed time per job, including object-storage download, audio extraction, language detection where it runs, decoding and upload. Audio duration is logged to one decimal place in minutes. The language thresholds, 4 jobs for Whisper and 8 for Parakeet, are inherited from the companion post so the two articles' tables cannot disagree. Burmese's two jobs are presented separately with their exact job counts.

Hardware: one shared container with a 2 vCPU budget running up to two jobs at a time. Parakeet is nemo-parakeet-tdt-0.6b-v3, int8 ONNX, memory arena disabled, 20-second windows with 5-second overlap. Whisper is faster-whisper small at int8, 150-second windows, greedy decoding. Absolute numbers are specific to that box; the spreads between languages and engines are the transferable part.

Every figure above was regenerated from the per-job CSV immediately before publication by a script that re-derives each statistic and then greps this page for all of them. The full per-language dataset is available as a CSV file; the underlying per-job records are in the companion benchmark's CSV.

This data is licensed CC BY 4.0. Feel free to reuse the numbers with credit to VidClean.

No matched pairs, as above. The engine comparison is confounded with language because routing is by language, and the per-language table makes that visible rather than removing it.

Whisper's cells are thin. Its 216 jobs total spread across 40-plus languages, so the per-language rows run from 4 to 21 jobs, and the twelvefold spread is robust only because the mechanism explains it and the direction is consistent. The individual numbers will move with more data.

Burmese is two jobs, one day, one speaker population. It is the strongest single data point in this post and the least trustworthy by volume; treat it as a flag for measuring, not as a settled cost.

Nothing here is about accuracy. Faster and flatter are throughput claims only, and anyone choosing an engine needs a word-error-rate comparison this post does not provide.

And it is twenty days in August on one box. The ratios are the transferable part; the absolutes should be re-measured on your own hardware, with your own language mix, because that mix is the point.

Most people reading a post like this are sizing a deployment. If you are not, and you simply want text out of a file, you can transcribe a video or audio file here, free in the browser, with no account needed. It is the same pipeline these measurements came from, engine routing and all, which means the language of your file decides which engine it runs on, exactly as described above.

VidClean is a solo project. Questions about the data or the methodology are welcome at hello@vidclean.net.