Hugging Face Speech-to-Text Models: 2026 Guide

Choose speech recognition by your recordings and deployment constraints. For a small CPU experiment, start with a Whisper conversion. For a larger multilingual evaluation, compare Whisper large-v3-turbo, Parakeet v3 and Qwen3-ASR using the same human-transcribed recordings. Speaker turns and timestamps need their own checks.

Checked October 31, 2026. We ran three Whisper conversions on Linux CPU, then added a Mac CPU baseline and an MLX Metal Turbo run on identical inputs. Parakeet, Qwen and Nemotron are documented alternatives, not winners from our test. For speech generation instead of recognition, see our Hugging Face TTS guide.

A shortlist by deployment need

Source: linked cards and Hub metadata as of 2026-10-31. These rows are evaluation paths, not a cross-model accuracy ranking. The two smaller tested models are English-only .en variants. All our inputs were English, so none of the results establishes multilingual accuracy.

Qwen's language and dialect counts should not be added together and advertised as 52 separate languages. Its card also distinguishes streaming inference from timestamp output: check the supported combination before choosing it for live captions. Nemotron's card explicitly describes an offline model; internal chunking is not a promise of realtime streaming. Its serving-performance claims also distinguish optimized infrastructure from the open release.

Our CPU test: inputs, transcripts and limits

We used the original WAV files from our Kokoro narration samples. Two stock voices read the same text. A third file adds seeded white noise to one of those recordings at a target signal-to-noise ratio of 15 dB. We did not select a different script for each model.

The intended reference text was:

Your weekly marketing report is ready. We published three articles, updated the product page, and prepared two videos for review. Next week, we will check which work brought people to your website.

Listen to the clean files in the TTS article. Here is the noisy input:

Download the noisy test WAV. The synthetic script is our intended reference, not an independently audited human transcription of the audio; listen for any TTS deviation before attributing a mismatch to ASR.

Measured 2026-10-31 on an AMD Ryzen 9 3900 Linux CPU, four threads, INT8, one timed run per model/file pair after a separate warm-up. The clean files last 11.73 and 12.69 seconds; the noisy derivative lasts 11.73 seconds. Elapsed time includes WAV decoding, resampling to 16 kHz and full transcription, excluding downloads and model loading. Real-time factor is elapsed time divided by audio duration.

All nine outputs matched the 32-word intended reference after normalization. This test was too easy to distinguish recognition quality. The larger Turbo conversion took longer on these short CPU inputs; that is not evidence that the smaller models match it on difficult recordings. We report each observation rather than a statistically meaningful speed ranking.

The complete reference transcript is shown above. All nine verbatim transcripts, model revisions and settings are available for inspection; differences in capitalization were ignored by the score. These are three checkpoint conversions, three input files and one underlying script—not nine independent speech examples.

How to read these results

Word error rate is the word-level edit distance divided by the reference word count: substitutions, deletions and insertions all count. We lowercase and remove punctuation, retaining apostrophes inside words. Lower is better on these files. We do not score capitalization or punctuation quality.

This is a small functional test with synthetic narration, not an ASR benchmark. It contains no actual customer calls, accents sampled from a population, overlapping speakers, room reverberation or microphone variation. White noise is not a substitute for those conditions. A model can score perfectly here and still fail on a meeting recording.

The timing includes decoding all returned segments. Some transcription APIs return an iterator before doing the expensive work; timing only the initial function call would give a misleadingly fast result. We warmed each model once, then timed one run per file with four CPU threads, INT8 computation, English specified, beam size five and voice-activity filtering off.

Mac mini follow-up: CPU baseline and Metal Turbo

On October 31, 2026, we reused the exact three committed Linux WAVs on an Apple M6 Mac mini with 32 GB unified memory, macOS 27.0.1. Input SHA-256 hashes are saved with every result. This separates recognition from any change in Mac TTS output.

Three timed repetitions per model/file pair follow one full clean-heart warm-up per runtime. Timing includes WAV decoding, float32 polyphase resampling to 16 kHz, input checksum reading and the complete transcript; Metal is synchronized before stopping its timer. Downloads and loading are excluded. All 18 Mac transcripts matched the intended 32-word synthetic reference after the same exact normalization used above. This repeats the Linux test's ceiling: these files are too easy to distinguish recognition quality.

The CPU baseline uses the same Systran tiny.en conversion, revision 0d3d19a32d3338f10357c0889762bd8d64bbdeba, now with faster-whisper 1.2.1 and CTranslate2 4.8.4. The GPU path uses the pre-existing community MLX float16 Turbo conversion, revision 624c19c9af5603fa73b83bce14d4aeea96156d18, through mlx-audio 0.6.1 and MLX 0.32.4. Its original model is OpenAI Whisper large-v3-turbo. The installed MLX decoder explicitly does not implement beam search; we used greedy decoding, English and temperature zero, with no VAD stage.

These rows change model, conversion, runtime, precision, accelerator and decoder settings. They do not isolate machine speed or show that tiny.en is as accurate as Turbo on difficult speech. The Linux CPU table remains separate. Full CPU transcripts and settings and full Metal transcripts and settings retain every repetition, reference denominator and input hash. The reference remains intended TTS text, not a human-audited transcript.

What a business transcription pilot should measure

Collect recordings you are allowed to process and manually transcribe a representative sample. Keep a separate test set out of prompt tuning. Include short and long calls, silence, strong accents, background speech and your own product vocabulary. Test recordings from the actual microphones or conferencing service.

Score names, amounts, dates and action items separately. A transcript can have a low overall word error rate while changing the one number that matters. Keep speaker identity and timestamps out of the word-recognition score so a good transcript cannot hide poor speaker attribution.

For a meeting workflow, report three separate outcomes:

1. Recognition: were the words captured, including domain terms?
2. Speaker attribution and timing: who said them, and when?
3. Downstream usefulness: does the reviewed summary preserve decisions and owners?

Do not score a summary against the model's own transcript as if it were independent truth. Keep the recording and a human-checked reference available for disputed passages.

Local inference and total cost

A local runtime can keep inference on your machine once required files are downloaded. Verify logging, temporary files and any external services in the complete application before making a privacy claim. A Hugging Face download alone does not establish where an entire transcription workflow sends data.

Measure elapsed time for the whole job, including loading if you run one-off jobs, and track memory and retry rates. A GPU may make sense for many concurrent recordings; a small CPU model may be sufficient for a low-volume background queue. Our small Linux and Mac observations do not establish a production capacity guarantee.

For related document ingestion, see Hugging Face OCR and document extraction. For a hosted voice-service comparison, see AI voice models.

Checkpoint revision and license-metadata snapshots, retrieved 2026-10-31.