A speech-to-text model might recognize clean recordings perfectly and still be the wrong choice for an 8GB Jetson Orin Nano. Conversational speech is harder, processing speed varies widely, and the largest models can leave little memory for other services.
We tested five OpenAI Whisper configurations and two NVIDIA Parakeet configurations for automatic speech recognition (ASR) on a Jetson Orin Nano 8GB mounted on Turing Pi 2.5. We compared word errors, processing speed and memory use, then ran a shared transcription service for the board’s RK1 nodes.
On the original English recordings, Whisper large-v3-turbo INT8-FP16 made 45 word errors, while each Parakeet model made 46, out of 2,824 reference words. Adding a more varied selection of recordings reversed the ordering of the two Whisper turbo variants. And the speed and memory measurements revealed compromises that accuracy alone wouldn’t show.
Whisper vs Parakeet speech-to-text: Which should you choose?
| Your priority | Model worth trying first | What we measured |
| Fast, lightweight English transcription | Whisper tiny.en FP16 | Lowest English real-time factor, 0.03565, and the smallest memory footprint in the original run; English WER was 6.657%. |
| Better accuracy on the broader English recordings | Whisper large-v3-turbo FP16 | 3.818% WER across the expanded 175-clip English set versus 3.902% for turbo INT8-FP16, a small difference of three edits in 3,588 reference words. |
| German transcription | Whisper large-v3-turbo FP16 | Lowest measured German error rate: 3.80% WER, 0.91% CER on 25 clips. |
| A shared LAN transcription endpoint | Whisper small FP16 | The tested single-worker service completed 27/27 requests with either one or three RK1 clients. |
| Accurate English with a fast Parakeet backend | Parakeet CTC 0.6B FP32 | 1.629% English WER and 0.03642 RTF, close to tiny.en’s speed, but with much higher memory use in the tested stack. |
These are recommendations based on the model, precision and runtime we actually tested. Whisper ran through faster-whisper and CTranslate2 at FP16 or INT8-FP16. Parakeet ran through NVIDIA NeMo and PyTorch at FP32. This is a comparison of working deployments, not a controlled experiment in which every model uses the same precision or inference engine. A different Parakeet runtime could change the results.
The test system: One Jetson, three RK1 nodes
The Jetson occupied Node 4 of the Turing Pi 2.5 for these speech tests, while RK1 modules occupied Nodes 1–3. It had been in Node 2 during the earlier carrier-board comparison. The board’s Gigabit Ethernet switch carried audio requests from the RK1s to the Jetson. Each node remained a separate computer, with its own memory and compute resources.
| Component | Recorded configuration |
| Carrier and modules | Turing Pi 2.5; Jetson Orin Nano 8GB in Node 4; three RK1 clients in Nodes 1–3 |
| Operating system | JetPack 7.2.1-b49; Jetson Linux R39.2.1; Ubuntu 24.04.5; kernel 6.8.12-1021-tegra |
| GPU libraries | CUDA 13.2; cuDNN 9.20.x; TensorRT 10.16.2.10 installed but not used for these Parakeet measurements |
| Whisper stack | faster-whisper 1.2.1; CTranslate2 4.8.2; Python 3.12.3; FP16 or INT8-FP16 |
| Parakeet stack | NeMo 3.0.0; PyTorch 2.13.0+cu132; FP32; cudaMallocAsync allocator |
| Storage | Jetson NVMe for model weights, audio datasets and benchmark logs |
| Power and cooling | The recorded power profile was 25W (nvpmodel mode 1), with automatic fan control. Fixed GPU clocks and matching ambient temperatures were not verified across sessions. |
The Jetson’s CPU and GPU share 8GB of LPDDR5 system memory. In the results below, process RSS means the benchmark process’s resident memory; system used is the total observed system-memory use, including other activity and GPU allocations. Neither is a measure of dedicated graphics-card VRAM.
The expanded run had approximately 640 MiB of swap already in use, with no observed swap growth in the completed Whisper measurements. The available power telemetry is from the Jetson’s sensors, not a calibrated wall meter. A configured 25W profile also doesn’t mean the system drew exactly 25W throughout each test.
For background on the platform, our NVIDIA Jetson software-stack guide explains CUDA, runtimes and containers. Our dev kit versus Turing Pi benchmark looks separately at what changes when the same module moves between carriers.
How we tested accuracy, speed and memory
We used an original 150-item evaluation set, a later 200-item set and a separate HTTP service test. Those numbers are not three independent collections of speech.
| Measurement | Audio included | Models with completed results |
| Original seven-model comparison | 100 clean English LibriSpeech clips, 25 noise-added versions of clean clips, 25 German FLEURS clips | Five Whisper configurations and two Parakeet configurations |
| Expanded evaluation | The original 150 items plus 50 English clips: 25 EdAcc conversational segments, 21 LibriSpeech audiobook clips, four OpenSLR read prompts | Five Whisper configurations only |
| LAN workload | Three fixed English WAV recordings repeated for 27 requests per condition | One Whisper small FP16 server, accessed by one or three RK1 nodes |
The common English comparison uses 125 items per pass, including the 25 noise-added recordings, and 2,824 reference words. The noisy recordings were generated at 10 dB signal-to-noise ratio by mixing room noise into existing clean clips. They are not independent utterances. German scores come from the separate 25-clip FLEURS de_de subset.
Each successful configuration completed three measured passes after warm-up, with the audio order shuffled. Whisper used beam size 1, temperature 0, an explicit language setting and voice-activity-detection filtering turned off. Parakeet used batch size 1, checkpoint-default decoding and no VAD filter; CTC used greedy decoding. These settings are documented so the measurements can be interpreted, but decoding procedures were not identical between model families.
Word Error Rate (WER) counts substituted, deleted and inserted words divided by the number of words in the reference transcripts. We totaled the edits across each category rather than averaging individual clip percentages. Character Error Rate (CER) uses character edits instead of word edits. Lower is better for both.
Our scoring normalized Unicode, capitalization, punctuation and whitespace. Numbers remained as digits rather than being expanded into words. That can penalize a correct transcript written as 21 when the reference spells out twenty one. We did not run a second scoring pass with Whisper’s English number normalizer, so results from other benchmarks using different normalization rules should not be compared directly.
Real-Time Factor (RTF) is processing time divided by the duration of the audio. An RTF of 0.10 means ten seconds of audio took about one second to transcribe. We included audio decoding and the completed transcription call, but not library import, model load or warm-up. P50 and P95 call latencies are descriptive percentiles over repeated calls to the same recordings, not independent-sample confidence intervals.
Accuracy: What happened on the original recordings?
All seven model configurations completed three passes over the same 125 English clips. The German results apply only to multilingual checkpoints.
| Model and precision | All-English WER (125) | Clean English WER (100) | Noisy English WER (25) | German WER / CER (25) |
Whisper tiny.en FP16 | 6.657% | 6.25% | 8.10% | N/A |
Whisper base.en FP16 | 4.001% | 3.90% | 4.38% | N/A |
Whisper small multilingual FP16 | 3.258% | 3.22% | 3.40% | 9.15% / 2.43% |
Whisper large-v3-turbo FP16 | 1.700% | 1.72% | 1.62% | 3.80% / 0.91% |
Whisper large-v3-turbo INT8-FP16 | 1.593% | 1.68% | 1.30% | 4.66% / 1.51% |
| Parakeet CTC 0.6B FP32 | 1.629% | 1.68% | 1.46% | N/A |
| Parakeet TDT 0.6B v3 FP32 | 1.629% | 1.77% | 1.13% | 7.60% / 2.77% |

The lowest English error counts were almost tied. Here are the actual word edits, with substitutions (S), deletions (D) and insertions (I) shown separately:
| Configuration | S | D | I | Total edits / 2,824 words |
| Whisper turbo INT8-FP16 | 36 | 7 | 2 | 45 |
| Parakeet CTC FP32 | 39 | 2 | 5 | 46 |
| Parakeet TDT v3 FP32 | 36 | 5 | 5 | 46 |
A difference of one edit among 2,824 words is too small to establish an accuracy winner. The two Parakeet models reached the same overall WER with different transcripts: they disagreed on 37 of the 125 clips.
The German results have a clearer ordering within this small test: turbo FP16 had 3.80% WER and 0.91% CER, ahead of turbo INT8-FP16 and Parakeet TDT v3. Parakeet TDT v3 supports German; Parakeet CTC 0.6B is English-only. NVIDIA’s TDT v3 and CTC model cards document that difference.
Speed: The fastest model wasn’t the most accurate
RTF uses the same 125 English clips for every model. Latency P50/P95 values pool 375 English calls per configuration, three passes of those same 125 clips.
| Model | English RTF ↓ | Call latency P50 / P95 |
Whisper tiny.en FP16 | 0.03565 | 0.269 / 0.453 s |
Whisper base.en FP16 | 0.05086 | 0.392 / 0.633 s |
Whisper small multilingual FP16 | 0.08926 | 0.683 / 0.996 s |
| Whisper turbo FP16 | 0.21746 | 1.736 / 1.963 s |
| Whisper turbo INT8-FP16 | 0.24557 | 1.959 / 2.204 s |
| Parakeet CTC FP32 | 0.03642 | 0.270 / 0.416 s |
| Parakeet TDT v3 FP32 | 0.04463 | 0.328 / 0.519 s |

Whisper tiny.en recorded the lowest aggregate English RTF at 0.03565, narrowly ahead of Parakeet CTC at 0.03642. But tiny.en also made substantially more transcription errors. The Parakeet CTC model came much closer to the turbo variants’ English accuracy while keeping processing time low in this particular setup.
Parakeet TDT v3’s measured speed needs one implementation detail: its preferred CUDA-graph compilation path failed, and the run continued with native PyTorch CUDA graphs. Its RTF is a measurement of that working fallback, not proof of the fastest performance TDT could achieve in a different runtime.
Memory: What the 8GB Jetson actually used
Memory was the clearest deployment constraint in this test. These are observed peaks, not standalone model sizes. The Jetson’s GPU and CPU share one memory pool, and peak process RSS is not additive to peak whole-system memory.
Original seven-model run
| Model | Peak process RSS | Peak system used | Increase over that run’s idle baseline |
Whisper tiny.en FP16 | 0.93 GiB | 2.64 GiB | +0.42 GiB |
Whisper base.en FP16 | 1.11 GiB | 2.81 GiB | +0.60 GiB |
Whisper small multilingual FP16 | 1.66 GiB | 2.81 GiB | +0.60 GiB |
| Whisper turbo FP16 | 3.72 GiB | 5.00 GiB | +2.75 GiB |
| Whisper turbo INT8-FP16 | 2.61 GiB | 4.24 GiB | +1.99 GiB |
| Parakeet CTC FP32 | 6.24 GiB | 6.83 GiB | +4.44 GiB |
| Parakeet TDT v3 FP32 | 6.35 GiB | 7.03 GiB | +4.63 GiB |
The baseline was captured separately before each model run. Subtracting each reported increment from its peak yields roughly 2.2 to 2.4 GiB of system memory already in use at those baselines, not a single common idle value. By comparison, our earlier dev-kit versus Turing Pi study measured about 0.66 GiB at idle on Turing Pi after extra services had been stopped. These speech tests ran with a higher starting load. That starting memory belongs to the surrounding software and system, not to Parakeet. We did not isolate which services accounted for the difference.
Parakeet CTC and TDT reached 6.83 and 7.03 GiB of peak system use. Their lowest observed available-memory readings were 550 MiB and 347 MiB, respectively. Both completed the original benchmark, but neither left much free memory in this FP32 NeMo/PyTorch configuration.

Memory differed between sessions
The subsequent Whisper-only run produced different memory peaks even for the same model configurations. The following table compares whole-system used peaks; it does not mix in process RSS or idle-subtracted increments.
| Whisper configuration | Original peak system used | Expanded-run peak system used |
tiny.en FP16 | 2.64 GiB | 2.69 GiB |
base.en FP16 | 2.81 GiB | 2.76 GiB |
small multilingual FP16 | 2.81 GiB | 3.04 GiB |
| Turbo FP16 | 5.00 GiB | 4.03 GiB |
| Turbo INT8-FP16 | 4.24 GiB | 3.81 GiB |
Turbo INT8-FP16 showed 0.76 GiB less peak system memory than FP16 in the first session. In the later session the difference was 0.21 GiB (4.03 versus 3.81 GiB). Figure 3B instead compares the increase over each model’s own pre-run baseline: 1.89 versus 1.66 GiB, a 0.23 GiB difference. Those are different memory measurements, so they need not match. Turbo FP16’s process RSS also changed substantially, from 3.72 GiB in the original run to 2.91 GiB in the later run.
We could not pin down why memory use changed between sessions. Background activity, runtime state and sampling conditions could all play a part, but none was isolated as the cause. On an 8GB system, what matters for deployment is the memory left with your own services running, not a model-size figure on its own.
Why FP32 Parakeet needed so much space
Each checkpoint is roughly 0.6 billion parameters. At four bytes per FP32 parameter, weights alone correspond to approximately 2.4 GB (about 2.24 GiB) before runtime buffers, intermediate tensors and framework overhead. In the later attempted run, importing NeMo/PyTorch reduced reported available memory by 664 MiB for CTC and 645 MiB for TDT, even before their checkpoints were loaded. These components overlap with process and system accounting, so they must not simply be added to the peak-RSS values above. The results do not describe the memory footprint of an optimized FP16, ONNX or TensorRT Parakeet deployment.
The expanded English test changed the Whisper ranking
The later evaluation kept the original 125 English items and added 50 more. Those additions were 25 EdAcc conversational clips, 21 LibriSpeech audiobook clips and four OpenSLR read-prompt clips. All five Whisper configurations completed the expanded set, giving 175 English recordings per pass. The multilingual Whisper configurations also processed the 25 German clips, making 200 items for their complete run.
| Whisper model | Original English WER (125) | Added English WER (50) | Expanded English WER (175) |
tiny.en FP16 | 6.657% | 20.550% | 9.615% |
base.en FP16 | 4.001% | 15.707% | 6.494% |
small multilingual FP16 | 3.258% | 14.921% | 5.741% |
| Turbo FP16 | 1.700% | 11.649% | 3.818% |
| Turbo INT8-FP16 | 1.593% | 12.435% | 3.902% |

On the original English subset, turbo INT8-FP16 had the lower measured WER. With the additional 50 clips, turbo FP16 moved ahead, 3.818% versus 3.902%. That was 137 versus 140 edits across 3,588 reference words. It is a small observed difference, not a statistically established winner, but it shows why the earlier INT8 result should not decide the choice on its own.
The longer English evaluation also measured the cost of those results:
| Whisper model | English RTF (175 clips) | Inference P95 / P99 | Peak RSS | Peak system used | Increase over idle |
tiny.en FP16 | 0.0330 | 0.396 / 0.480 s | 938 MiB | 2,750 MiB | +578 MiB |
base.en FP16 | 0.0486 | 0.553 / 0.747 s | 1,090 MiB | 2,825 MiB | +661 MiB |
small multilingual FP16 | 0.0899 | 0.960 / 1.136 s | 1,685 MiB | 3,117 MiB | +945 MiB |
| Turbo FP16 | 0.2259 | 1.930 / 2.027 s | 2,976 MiB | 4,123 MiB | +1,940 MiB |
| Turbo INT8-FP16 | 0.2552 | 2.168 / 2.320 s | 2,756 MiB | 3,906 MiB | +1,703 MiB |
The P95 and P99 values summarize 525 measured calls per model, or the same 175 clips repeated three times. Across the unchanged 25 German clips, turbo FP16 had the lowest observed Whisper error rate at 3.80% WER / 0.91% CER.
Why conversation is a different test
The 50 added English clips weren’t all accented speech. They were a mixture of speaking and recording styles. In the 25 conversational EdAcc clips, even the turbo models had much higher WER than on the clean audiobook recordings.
| Whisper model | Conversational EdAcc WER (25) | Audiobook LibriSpeech WER (21) | Read prompts OpenSLR WER (4) |
tiny.en FP16 | 36.19% | 6.78% | 4.17% |
base.en FP16 | 28.45% | 4.80% | 0.00% |
small multilingual FP16 | 28.18% | 3.39% | 0.00% |
| Turbo FP16 | 21.55% | 3.11% | 0.00% |
| Turbo INT8-FP16 | 23.48% | 2.82% | 0.00% |

The selected EdAcc clips were scored with our general-purpose transcript normalization, not the EdAcc leaderboard’s scoring rules. Some speakers overlap the original LibriSpeech test, and the regional-accent labels are incomplete. These results describe these recordings, not the accuracy a reader should expect for everyone with a given accent.
Why Parakeet has no expanded-set score
Both Parakeet models completed the original comparison, but neither loaded in the later session. After NeMo/PyTorch imports, available RAM was lower than the levels recorded before their earlier successful model loads:
| Model | RAM available after import in successful session | RAM available after import in later session |
| Parakeet CTC 0.6B FP32 | 5,094 MiB | 4,673 MiB |
| Parakeet TDT 0.6B v3 FP32 | 5,083 MiB | 4,686 MiB |
Both attempts stopped before model weights loaded, because available memory had fallen below the level set for safe model loading. Neither produced an expanded-set transcript. The cause of that reduced headroom remains unknown, so we cannot compare Parakeet with Whisper on the additional 50 recordings, particularly the conversational EdAcc clips.
Sharing one Jetson ASR service across RK1 nodes
Instead of running a separate speech model on every device, we loaded Whisper small FP16 once on the Jetson and exposed a simple HTTP endpoint. Each RK1 client uploaded a complete mono, 16 kHz, 16-bit PCM WAV recording and received a transcript. The service used one GPU inference worker, so simultaneous requests waited in a queue rather than running separate model instances.
Both scenarios replayed the same three English WAV files, nine requests per file, for 27 requests each. First, one RK1 sent all the requests. Then three RK1s shared the same workload. Because individual clip durations were not retained with these results, the throughput figures describe completed requests for this particular mix, not audio seconds processed per second.
| RK1 clients | Completed | Throughput | Full-request P50 | Full-request P95 / P99 | Mean server queue wait |
| 1 | 27/27 | 1.233 req/s | 0.741 s | 1.146 / 1.166 s | ~0 s |
| 3 | 27/27 | 1.250 req/s | 2.175 s | 3.342 / 3.356 s | 1.405 s |

Throughput barely changed: 1.233 versus 1.250 requests/s. The median response time, however, rose from 0.741 to 2.175 seconds, with an average 1.405 seconds spent waiting in the server queue in the three-client case. That is the consequence of a serialized GPU worker. Adding clients doesn’t automatically increase the amount of work one loaded model can do.
The measurements cover uploading the prerecorded file, waiting, inference and returning the completed transcript. They don’t separate pure network-transfer time from the rest of the request, and the 27-call tail percentiles are not service-level guarantees. There was no live VAD endpoint, incremental partial transcript, or streaming first-word latency measurement. Our guide to how voice assistants work explains where those stages fit into a full voice pipeline.
How to interpret these benchmarks
The seven-model head-to-head covers 125 shared English clips, with German results where supported. The extra conversational clips were tested with Whisper only. The Jetson was recorded in its 25W profile, but fixed clocks and matching room temperatures were not verified across sessions. Memory peaks also differed between runs. The reported WER also depends on the stated number-normalization policy.
For a meaningful comparison on another Jetson, use the same audio samples, model checkpoints, precision, inference backend, decoding settings and transcript normalization. Keep power mode and background load as similar as possible. Different settings can change both WER and throughput.
For a real deployment, try the recordings your system will actually hear. A clean-speech WER score, an offline RTF and a full HTTP response time answer three different questions. None alone tells you how a live voice assistant will feel.
Troubleshooting
| Symptom | Check | Next step |
faster-whisper cannot load its CUDA backend | python3 -c "import ctranslate2; print(ctranslate2.__version__)"; cat /etc/nv_tegra_release | Check the installed GPU-enabled CTranslate2 build and the CUDA/cuDNN libraries in the active environment. Do not confuse a CPU fallback with a GPU result. |
| The model loads slowly or runs out of shared memory | free -h; sudo tegrastats --interval 1000 | Check available memory and background services before loading the model. Stop only workloads you can safely interrupt, and keep memory guards enabled. |
| Speeds differ from these results | sudo nvpmodel -q; sudo jetson_clocks --show | Check power mode, dynamic clocks, cooling and background load before comparing RTF. |
| RK1 cannot reach the service | curl http://JETSON_LAN_HOST:8000/health; on Jetson: ss -lntp | Check the Jetson address, listening interface and local-network access. |
| Response time rises with multiple clients | Measure queue time and full-request latency | With one inference worker, concurrent requests wait even when the network is fast. |
| WER doesn’t match another published benchmark | Check the reference transcripts and number handling | Match the dataset, language selection, tokenizer and transcript normalization before comparing percentages. |
What You’ve Built
We compared seven working model configurations on the same English recordings and checked German support where applicable. The later Whisper-only run showed how adding conversational speech can change a model ranking. We also showed how one Jetson can serve full-utterance transcriptions to RK1 clients over the Turing Pi board’s network.
The practical choice depends on what matters most. Whisper tiny.en is quick and light but makes more mistakes. Turbo FP16 earned its place on the more varied audio and German clips. Parakeet CTC was accurate and fast on the original English set, though our FP32 NeMo setup had very little spare memory in that session. A single-worker LAN service worked reliably for the measured requests, while additional clients mostly added waiting time.
Related Articles
- How Voice Assistants Work and Why They Feel Slow: the voice pipeline around speech recognition.
- NVIDIA Jetson Software Stack on Turing Pi 2.5: JetPack, CUDA, TensorRT and inference runtimes.
- Preparing NVIDIA Jetson as an AI Node on Turing Pi 2.5: GPU containers, NVMe storage and networking.
- Jetson Orin Nano Dev Kit vs Turing Pi 2.5: carrier differences and sustained-load testing.
FAQ
Which model had the lowest English WER?
In the original seven-model comparison, turbo INT8-FP16 had 1.593% WER on the common English set, just one word edit ahead of either Parakeet model. In the expanded Whisper-only run, turbo FP16 scored 3.818%, ahead of turbo INT8-FP16 at 3.902%. These are different audio denominators.
Why did Parakeet use so much memory?
The models had roughly 2.4 GB of FP32 weights each before activations and framework overhead. The measured original runs increased whole-system memory use by 4.44 GiB (CTC) and 4.63 GiB (TDT) above their respective baselines. In the later session, less memory remained after NeMo/PyTorch imports, and the loading guard prevented either model from starting inference.
Can an RK1 share the Jetson’s GPU?
Not directly. An RK1 can upload audio to a service hosted on the Jetson and receive text back over Ethernet. The Jetson performs the inference and keeps the model in its own memory.
Can the HTTP service handle several RK1 clients?
Yes. All 27 requests succeeded with both one and three RK1 clients. With one GPU worker, median full-response latency increased as requests queued; total measured throughput remained roughly unchanged.
Does this benchmark measure live or streaming speech recognition?
No. The accuracy and speed comparisons used prerecorded clips, and the HTTP service returned final transcripts for completed WAV uploads. Live microphone endpointing, partial transcripts and first-word streaming latency were not measured.