STT Model Benchmark 2026: Parakeet vs Whisper vs Qwen3 vs Grok

Speech is about four times faster than typing. For developers feeding complex prompts into AI assistants, voice input reduces working memory strain and carries richer context. But voice-driven workflows depend entirely on the underlying speech-to-text (STT) engine underneath. A model that hallucinates technical terms, drops proper nouns, mishears "Kubernetes" as something else entirely, or introduces multi-second delays breaks the flow of thought before it ever reaches your editor.

To understand how modern STT options hold up under real developer use, we benchmarked open-weight models and cloud APIs on real developer dictation: technical jargon, code-switching (mixing two languages in the same sentence or recording), meeting chatter, filler words and all. Some of these models we ran ourselves end to end; others we researched from public vendor documentation to round out the landscape. We're explicit below about which is which. Here is what the evidence actually shows, what commonly goes wrong, and, most usefully, which model we'd point you to for which job.

1. The Open-Weight and Local STT Landscape

Open-weight models you run yourself, whether on your own machine or a rented GPU, offer predictable latency, no data leaving your infrastructure, and low ongoing cost once set up. We tested several of the current leading open architectures on real dictation clips spanning English and other languages.

NVIDIA Parakeet TDT 0.6B (v2 and v3)

Parakeet TDT 0.6B is a compact "FastConformer" model, small enough that it doesn't need a data-center GPU to be fast. In our tests it processed a 60-second English clip in about 2.6 seconds: 23x realtime. It also showed clean capitalization, accurate timestamps, and precise handling of proper nouns. Independent public benchmarks (not our own numbers, cited for context) put Parakeet v3 in the same range or faster on ordinary consumer cards like an RTX 3060 or RTX 4060. This is not a model that requires an expensive rig. Source: Local AI Master, Parakeet TDT benchmark.

Parakeet v3 (multilingual): covers 25 European languages, including French, German, Spanish, Portuguese, Dutch, Polish, and Ukrainian. On one of our non-English test clips we measured 22.4x realtime; in batched testing on the same GPU, throughput scaled to 168x realtime at batch size 64 while using only 3.5 GB of memory.
CPU-only and lightweight deployment: forced onto CPU (no GPU at all, via ONNX), Parakeet v3 still sustained 10.8-12.9x realtime. Packaged as a small C++ binary (parakeet.cpp), it hit 10.3-17.2x realtime on CPU with no accuracy loss versus the full GPU version.

For European languages, Parakeet v3 was the fastest and most accurate open-weight model we tested. It's also light in raw compute terms; our measured throughput scales well even on modest GPU hardware. That said, the model itself is only step one. Turning that raw throughput into something you'd actually ship still means building and running the routing, fallback, and cleanup layers covered in Section 4. That's a real ongoing engineering commitment, not just a checkbox on a hosting bill.

Qwen3-ASR (0.6B and 1.7B)

Qwen3-ASR trades a bit of speed for much broader language coverage: 52 languages and dialects, including Mandarin and Cantonese, Arabic, Korean, Thai, Vietnamese, Japanese, Turkish, Hindi, Malay, Indonesian, and more, in addition to the usual European set.

Qwen3-ASR 0.6B: 19.9x realtime in English, 12.0x realtime on non-English test clips, on GPU. Minor word-repetition artifacts showed up occasionally on longer non-English segments (e.g. repeating a word three times in a row); a cheap deduplication or LLM cleanup pass fixes this.
Qwen3-ASR 1.7B: 12.7x realtime (English), 7.4x realtime (non-English). This is the more accurate of the two, correctly handling technical grammar where the smaller model occasionally garbled it.
On CPU (no GPU), Qwen3-ASR is meaningfully slower than Parakeet, about 1.8-3.4x realtime versus Parakeet's 10.8-12.9x, because it's an LLM-style decoder rather than a lean acoustic model. If you don't have a GPU, Parakeet wins outright; Qwen3-ASR only earns its keep when you need one of the ~30 languages Parakeet doesn't cover.

IBM Granite Speech 4.1 (2B)

A multimodal model supporting English, French, German, Spanish, Portuguese, and Japanese. It reached 12.3x realtime on GPU with clean output for all six languages, notably including Japanese, which several of the other local models here don't cover at all. It doesn't cover as broad a language set as Parakeet or Qwen3-ASR.

Whisper (local medium, and Groq-hosted turbo)

Whisper remains the industry's broadest-coverage model, spanning 99+ languages, including the long tail (Arabic, Hebrew, Hindi, Thai, and dozens more that none of the compact models above touch). It also handles code-switching (mixed languages in one recording) better than the faster local models we tested.

A crippled local number, and the real one: running the local faster-whisper medium model on our GPU test rig, the only available backend (CTranslate2) could run just float32 precision on that hardware, no int8 or fp16 acceleration, and we measured about 1x realtime under that specific constraint. That's a backend/hardware limitation of the test rig, not a fact about Whisper's actual speed. The real production path is different: Whisper-large-v3-turbo hosted on Groq, which is what a production backend actually uses. We ran that exact model on the real 5-minute reference recording used elsewhere in this piece, 4 fresh calls today: elapsed times of 1.99s, 1.70s, 19.54s, and 22.68s wall-clock (including upload and network round trip), a mean of 11.48s, which is about 26x realtime on average (individual runs ranged 13x-176x, reflecting real cloud-latency variance across calls, not a stable per-call number; full raw responses and a rerunnable script are committed in raw/whisper_turbo_groq_check/).
Takeaway: don't confuse a specific local deployment's limitation with the model's real capability. On the deployment actually used in production, Whisper is nowhere near "1x slow": even its worst observed run among these 4 calls was 13x realtime. That said, this cloud wall-clock number and the local models' GPU throughput numbers above are two different kinds of measurement (network-and-queue-inclusive latency vs. local compute throughput), so treat them as separate facts, not a head-to-head ranking. Whisper's clearest, most comparable strength here is language coverage and code-switching accuracy.

Moonshine (medium-streaming)

A CPU-focused model supporting English, Spanish, Mandarin, Japanese, Korean, Vietnamese, Ukrainian, and Arabic. It hit 5.1x realtime on CPU alone, useful as a last-resort CPU option for a handful of non-European languages, but quality lagged behind Granite and Parakeet, with occasional filler-word hallucination and inconsistent capitalization.

NVIDIA Nemotron 3.5 ASR 0.6B (gated local model)

A gated-access model you download and run locally via NVIDIA's NeMo toolkit on CPU. On a 5-minute technical recording, generic transcription scored 24.5-24.7% word-error-rate (WER, the standard way to measure how many words a model gets wrong out of the total); its official low-latency streaming mode scored worse, at 32.2% WER. It handled full recordings tolerably but produced garbled, hallucinated leading text when fed very short audio snippets starting mid-sentence, useful as an internal stress test, not as a production model on this evidence.

2. Cloud STT Services: What They Cost You, and What You Get

Cloud APIs remove the need to run any hardware yourself: you send audio, you get text back, someone else worries about GPUs and scaling. The tradeoff is per-minute billing, a network round trip, and, depending on your compliance requirements, your audio leaving your infrastructure. We ran one cloud model, Grok STT, through the exact same test clips and reference transcripts we used for the local models above. The local baselines it was compared against also ran on our own GPU, so this isn't cloud-on-someone-else's-hardware versus local-on-ours. The same box did both jobs.

Grok STT 1.0 (xAI)

Tested via both OpenRouter and xAI's native API on identical clips: English recordings on OAuth, Kubernetes, and Python, plus a non-English Docker walkthrough.

Clip	Grok STT	Our local Parakeet	Our local Whisper
English, OAuth	10.02% WER	1.93% WER	1.72% WER
English, Kubernetes	5.65% WER	6.10% WER	4.99% WER
English, Python	2.31% WER	4.82% WER	2.10% WER
Non-English, Docker	12.78% WER	0.00% WER	8.89% WER

Lower is better; WER is the percentage of words the model got wrong. Grok STT lost to our own bare local models on 3 of 4 clips, and lost badly on the non-English one. It also has real, repeatable bugs: mishearing "Kubernetes" as "Kupinetics" before enough context built up, spelling the same proper noun two different ways within a single transcript, and, worst for anything latency-sensitive, a 6.7x spread in response time on identical back-to-back requests (9.6 seconds to 64.5 seconds for the same clip). Sub-second audio also reliably produced fabricated text (e.g. "Oh, no." on pure silence) rather than an empty response.

To be fair to Grok STT: it's a reasonable option if you don't already have a local pipeline, it covers 25 languages out of the box, and the accuracy gap narrows on clean English audio. It just didn't beat what we already had running locally.

Why cloud, and why local

Neither approach is universally right:

Cloud APIs win when you don't want to run any infrastructure at all, need enterprise features like formal compliance certifications or guaranteed regional data residency, or need a language your local stack doesn't cover and don't want to manage another model. You pay per minute, and you inherit the provider's latency and uptime.
Self-hosted models win on latency (no network round trip, and no 6x variance like Grok STT's) and on privacy (audio never leaves your infrastructure). In exchange, you own the whole pipeline: the model itself, plus the routing, fallback, stitching, and cleanup layers in Section 4, plus keeping all of it running and up to date as models change. That's a real, ongoing systems project, not a one-time setup cost.

Our own numbers above make the case concretely: bare local Parakeet and Whisper, running on hardware we already own, beat a paid cloud API on accuracy in three of four tests. Cloud isn't automatically better just because it's cloud, but "better than one cloud API on accuracy" and "worth building and maintaining yourself" are two different questions.

3. What Actually Goes Wrong (and How Often)

Benchmarks are more useful once you know what kind of errors to expect. Across our tests, the recurring failure modes were:

Code-switching (mixing languages mid-sentence): the single biggest source of dropped accuracy on real developer and meeting audio. On lecture-style dictation, about 23% of segments contained English technical terms dropped into otherwise non-English speech ("full screen", "SGGS-based", "UI"), and the primary local model alone got them wrong close to every time.
Filler words: in real multi-speaker meetings, about 35% of segments were pure filler ("um", "yeah", "uh", "so"). Not an accuracy problem exactly, but a real cost problem if you reprocess or clean up every segment blindly.
Technical jargon and proper nouns mishearing: every model we tested, local and cloud, occasionally mangled a specific technical term before enough context accumulated to disambiguate it. This is the single hardest problem in this space and no model we tested solved it completely.
Spelling instability: the same proper noun spelled two different ways within one transcript, seen in both a local model on informal audio and the cloud model above.
Hallucination on near-silence: short or empty audio segments produced fabricated words rather than an empty string, across multiple models we tested.
Confidence is a decent, not perfect, error predictor: on a small sample of segments with known errors (about 800 words at high confidence, 300 at low confidence), segments where a model reported ≥90% confidence in its own output had an estimated 2-5% error rate; segments below 70% confidence had a 40-60% error rate. That's a useful signal for building a "only double-check the shaky parts" pipeline (more on that below), but it's an approximate calibration from a small sample, not a guarantee that holds at scale.

None of this is model-specific griping. It's the shape of the actual problem. Speech-to-text for real, messy, multi-speaker, multilingual, jargon-heavy audio is still an unsolved problem across every model we tried, cloud or local. The practical question isn't "which model never makes mistakes" (none do); it's which combination of models catches the most of them for the least cost and latency.

4. Beyond a Single Model: Routing, Streaming, and Cleanup

The strongest results in our testing didn't come from any single model. They came from combining a fast local model with smarter fallback and cleanup logic.

A simple router beats a single model

Rather than relying on one model for every segment, we tested routing individual chunks of audio to different models based on what's in them:

Segments with detected foreign-language words (a simple check for English words dropped into non-English speech, or vice versa) get routed to Whisper, which handles code-switching noticeably better than the faster local models.
Segments that are pure filler get ignored entirely rather than reprocessed; on one 5-minute, 4-speaker meeting test, 35% of segments were pure filler, a free reduction in downstream work for that recording specifically (the share of filler varies by audio; a separate, larger meeting dataset in our records showed a lower filler-ignore rate).
Segments with moderate confidence and a handful of low-confidence words (not garbage, not clean) get sent to a small LLM for a targeted spelling fix rather than a full re-transcription.
Everything else stays as the fast local model's output.

On a set of real meeting recordings without ground-truth transcripts, we estimated a baseline error rate of 14.1% for the fast local model alone (from confidence scores, not a measured WER), and projected that the router above would bring it toward 10-12%, assuming the individual fallback stages perform on this audio the way they did in separate tests. That's a projection, not a measured result, and we haven't yet run it end to end with a human reference transcript to confirm it. Two things we did measure directly and explicitly rejected: re-transcribing every low-confidence segment in isolation with a second model (it fixed about 1 in 6 real errors and made almost as many worse, because it lacks the surrounding context) and padding-and-rerunning short clips (14% fix rate, and it introduced new errors at the boundaries).

Dual-layer streaming for live voice interfaces

For a live "you talk, text appears as you go" interface, a two-layer setup performed best: a very lightweight streaming model shows live text and detects when you've finished a thought (end-of-utterance), and once that boundary is hit, a slower, more accurate offline model re-decodes that same chunk of audio in under two seconds to correct anything the fast layer got wrong. You get instant visual feedback and corrected accuracy a moment later, rather than choosing one or the other.

Stitching long recordings without losing words at the seams

When long audio gets cut into shorter chunks for processing (common for anything beyond a few minutes), naive hard cuts occasionally slice a word in half at the boundary. Snapping each cut to the nearest natural pause in the audio, rather than a fixed timestamp, cut boundary errors by close to a third in our testing, with no added complexity. We also tested having an LLM "smartly" merge the chunks back together instead of simple concatenation; it sounded appealing but in practice silently dropped 21-60% of the words in some chunks, because the merge prompt was instructed to discard "garbage" text and over-applied that to real, messy speech. Simple concatenation at a natural pause point outperformed the fancier LLM approach on both correctness and cost.

Cleaning up the transcript afterward

Once a model produces its best transcript, a separate cleanup pass (a compact instruction-tuned LLM, not another ASR model) can fix dropped characters, punctuation, and grammar without paraphrasing or rewriting what was actually said. We compared three candidate cleanup models on real (occasionally profane) developer dictation: one preserved the exact meaning and profanity while fixing genuine errors; a second left obvious typos unfixed; a third rewrote phrasing and censored words that were actually said, which is a real problem if you're transcribing what someone actually said. Model choice matters here as much as it does for the transcription step itself: a "smart" cleanup model that changes your words is worse than no cleanup at all.

What it actually takes to make this feel instant

None of the sections above is a standalone trick. A dictation pipeline that reliably returns clean, accurate text in a couple of seconds is all of them running together: an ASR model, a router deciding which segments need a second opinion, one or more fallback models for code-switching and jargon, a stitching layer that snaps boundaries to natural pauses on longer recordings, a cleanup pass that fixes errors without rewriting your words, and confidence-based retry logic tying it all together, plus ongoing work to keep it all correct as the underlying models get replaced. Every failure mode in Section 3 needs a specific answer somewhere in that chain, or it just resurfaces as a bad transcript. That's a genuine, ongoing systems-engineering project, which is exactly the kind of problem worth paying a few dollars a month to have already solved, rather than assembling and maintaining it yourself for one app.

5. Other Names You'll See in This Space

Beyond the models we benchmarked directly, the broader speech-to-text market is large and worth knowing by name, even if we haven't run these ourselves. (The entries below are sourced from public vendor documentation checked in July 2026. We have not benchmarked them ourselves.)

Enterprise cloud APIs: OpenAI's Whisper API, GPT-4o Transcribe, and GPT-Realtime-Whisper; Google Cloud Speech-to-Text and Chirp 3; Amazon Transcribe; Microsoft Azure Speech to Text.

Voice-agent-focused hosted services: Deepgram Nova-3 and Flux; AssemblyAI Universal-2 and Universal-3.5 Pro; ElevenLabs Scribe v2 and Scribe v2 Realtime; Speechmatics; Rev AI Reverb.

Open or downloadable models: Mistral's Voxtral Mini Transcribe 2 and open-weight Voxtral Realtime; Meta's SeamlessM4T v2, Massively Multilingual Speech (1,100+ languages), and newer Omnilingual ASR project (1,600+ languages, Apache 2.0); NVIDIA's Canary-Qwen-2.5B; Kyutai's STT 1B and 2.6B streaming models.

Sources: OpenAI Whisper, Google Chirp 3, Deepgram, AssemblyAI, ElevenLabs Scribe, Speechmatics, Rev AI, Mistral audio docs, Meta Omnilingual ASR, Meta MMS model card, Kyutai STT.

6. Which Model Should You Actually Use?

If you just want an answer for your specific situation:

Your situation	Use this
Single-speaker technical dictation, European languages	Parakeet v3, with Whisper as a fallback for any dropped-in English/foreign terms
Multi-speaker meetings, informal speech	Parakeet v3 + filler filtering + Whisper for foreign phrases + a small LLM for spelling fixes
You need one of ~30 languages Parakeet doesn't cover (Chinese, Arabic, Korean, Thai, Vietnamese, Turkish, Hindi, etc.)	Qwen3-ASR (52 languages), or Whisper for anything even Qwen3-ASR lacks
No GPU available at all	Parakeet v3 on CPU: it beats every other option here by a wide margin without a GPU
Live, realtime voice interface	Dual-layer setup: a small streaming model for instant display, a larger model to re-decode and correct each finished thought
You don't want to run any infrastructure and need enterprise compliance features	A cloud API (Google, Azure, AWS); accept the latency and variance tradeoffs that come with an external service
You want an easy hosted API and don't yet have a local pipeline	Deepgram, AssemblyAI, or Mistral Voxtral are straightforward to adopt, though we haven't benchmarked their accuracy ourselves
Cleaning up a transcript afterward	A small instruction-tuned LLM with an explicit "preserve everything, never paraphrase or censor" instruction, not an LLM merge/stitch step that's allowed to drop content

7. Summary and Practical Takeaways

For European languages: Parakeet v3 offers the best combination of speed and accuracy we measured, running comfortably even on modest GPU hardware.
For broader language coverage (50+ languages): Qwen3-ASR trades some speed for reaching languages Parakeet doesn't, provided you have a GPU.
For the long tail of languages nothing else here supports, or for mixed-language recordings: Whisper remains the strongest choice on coverage and code-switching accuracy, and on the cloud-hosted turbo deployment, it's fast too (see Section 1), not the slow option a naive local benchmark makes it look like.
For realtime voice interfaces: pair a fast, lightweight streaming model for live display with a slower, more accurate model to correct each finished thought a moment later.
For cleanup after transcription: use a non-censoring, instruction-tuned LLM that's explicitly told to preserve everything, not to "helpfully" rewrite or drop content.
Don't assume cloud beats local, or vice versa, without testing on your own audio: in our tests, a paid cloud API lost to models we already ran locally, on the same hardware, on 3 of 4 clips.
The model is the easy part: getting from a raw ASR model to text that reliably "just works" in a couple of seconds takes the entire pipeline in Section 4, running together and kept correct over time. That's the part most people underestimate.

At AICHE, evaluating speech-to-text performance this closely is core to reducing the friction between thinking out loud and getting usable text where it needs to go. Whether you're dictating complex prompt constraints or capturing technical notes in a language other than English, using the right STT architecture, and knowing its actual failure modes, is what determines whether your spoken thoughts reach your tools intact.