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 priorityModel worth trying firstWhat we measured
Fast, lightweight English transcriptionWhisper tiny.en FP16Lowest 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 recordingsWhisper large-v3-turbo FP163.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 transcriptionWhisper large-v3-turbo FP16Lowest measured German error rate: 3.80% WER, 0.91% CER on 25 clips.
A shared LAN transcription endpointWhisper small FP16The tested single-worker service completed 27/27 requests with either one or three RK1 clients.
Accurate English with a fast Parakeet backendParakeet CTC 0.6B FP321.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.

ComponentRecorded configuration
Carrier and modulesTuring Pi 2.5; Jetson Orin Nano 8GB in Node 4; three RK1 clients in Nodes 1–3
Operating systemJetPack 7.2.1-b49; Jetson Linux R39.2.1; Ubuntu 24.04.5; kernel 6.8.12-1021-tegra
GPU librariesCUDA 13.2; cuDNN 9.20.x; TensorRT 10.16.2.10 installed but not used for these Parakeet measurements
Whisper stackfaster-whisper 1.2.1; CTranslate2 4.8.2; Python 3.12.3; FP16 or INT8-FP16
Parakeet stackNeMo 3.0.0; PyTorch 2.13.0+cu132; FP32; cudaMallocAsync allocator
StorageJetson NVMe for model weights, audio datasets and benchmark logs
Power and coolingThe 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.

MeasurementAudio includedModels with completed results
Original seven-model comparison100 clean English LibriSpeech clips, 25 noise-added versions of clean clips, 25 German FLEURS clipsFive Whisper configurations and two Parakeet configurations
Expanded evaluationThe original 150 items plus 50 English clips: 25 EdAcc conversational segments, 21 LibriSpeech audiobook clips, four OpenSLR read promptsFive Whisper configurations only
LAN workloadThree fixed English WAV recordings repeated for 27 requests per conditionOne 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 precisionAll-English WER (125)Clean English WER (100)Noisy English WER (25)German WER / CER (25)
Whisper tiny.en FP166.657%6.25%8.10%N/A
Whisper base.en FP164.001%3.90%4.38%N/A
Whisper small multilingual FP163.258%3.22%3.40%9.15% / 2.43%
Whisper large-v3-turbo FP161.700%1.72%1.62%3.80% / 0.91%
Whisper large-v3-turbo INT8-FP161.593%1.68%1.30%4.66% / 1.51%
Parakeet CTC 0.6B FP321.629%1.68%1.46%N/A
Parakeet TDT 0.6B v3 FP321.629%1.77%1.13%7.60% / 2.77%
Figure 1. Original 150-item benchmark: category-level word error rates (A) and the separate German word/character error comparison (B). English scores share the same audio. German uses 25 FLEURS clips.

The lowest English error counts were almost tied. Here are the actual word edits, with substitutions (S), deletions (D) and insertions (I) shown separately:

ConfigurationSDITotal edits / 2,824 words
Whisper turbo INT8-FP16367245
Parakeet CTC FP32392546
Parakeet TDT v3 FP32365546

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.

ModelEnglish RTF ↓Call latency P50 / P95
Whisper tiny.en FP160.035650.269 / 0.453 s
Whisper base.en FP160.050860.392 / 0.633 s
Whisper small multilingual FP160.089260.683 / 0.996 s
Whisper turbo FP160.217461.736 / 1.963 s
Whisper turbo INT8-FP160.245571.959 / 2.204 s
Parakeet CTC FP320.036420.270 / 0.416 s
Parakeet TDT v3 FP320.044630.328 / 0.519 s
Figure 2. Processing speed for the original comparison. Panel A is real-time factor (RTF) by speech category. Panel B shows median (dot) and P95 (upper end) inference latency for individual clips. Lower is better; neither panel measures live microphone-to-first-word delay.

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

ModelPeak process RSSPeak system usedIncrease over that run’s idle baseline
Whisper tiny.en FP160.93 GiB2.64 GiB+0.42 GiB
Whisper base.en FP161.11 GiB2.81 GiB+0.60 GiB
Whisper small multilingual FP161.66 GiB2.81 GiB+0.60 GiB
Whisper turbo FP163.72 GiB5.00 GiB+2.75 GiB
Whisper turbo INT8-FP162.61 GiB4.24 GiB+1.99 GiB
Parakeet CTC FP326.24 GiB6.83 GiB+4.44 GiB
Parakeet TDT v3 FP326.35 GiB7.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.

Figure 3. Memory usage across two benchmark sessions. Panel A shows peak process memory (RSS) and total system memory used during the original seven-model comparison. Panel B shows peak process RSS and the increase in system memory above each model run’s idle baseline during the expanded Whisper-only test. All values are in GiB. The Jetson’s CPU and GPU share system memory, and the two panels use different memory measurements, so their values are not directly comparable.

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 configurationOriginal peak system usedExpanded-run peak system used
tiny.en FP162.64 GiB2.69 GiB
base.en FP162.81 GiB2.76 GiB
small multilingual FP162.81 GiB3.04 GiB
Turbo FP165.00 GiB4.03 GiB
Turbo INT8-FP164.24 GiB3.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 modelOriginal English WER (125)Added English WER (50)Expanded English WER (175)
tiny.en FP166.657%20.550%9.615%
base.en FP164.001%15.707%6.494%
small multilingual FP163.258%14.921%5.741%
Turbo FP161.700%11.649%3.818%
Turbo INT8-FP161.593%12.435%3.902%
Figure 4. Later 200-item Whisper-only run. Panel A compares clean, noise-added and added English recordings; panel B covers German; panel C shows English processing speed and latency. This figure contains no Parakeet measurements.

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 modelEnglish RTF (175 clips)Inference P95 / P99Peak RSSPeak system usedIncrease over idle
tiny.en FP160.03300.396 / 0.480 s938 MiB2,750 MiB+578 MiB
base.en FP160.04860.553 / 0.747 s1,090 MiB2,825 MiB+661 MiB
small multilingual FP160.08990.960 / 1.136 s1,685 MiB3,117 MiB+945 MiB
Turbo FP160.22591.930 / 2.027 s2,976 MiB4,123 MiB+1,940 MiB
Turbo INT8-FP160.25522.168 / 2.320 s2,756 MiB3,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 modelConversational EdAcc WER (25)Audiobook LibriSpeech WER (21)Read prompts OpenSLR WER (4)
tiny.en FP1636.19%6.78%4.17%
base.en FP1628.45%4.80%0.00%
small multilingual FP1628.18%3.39%0.00%
Turbo FP1621.55%3.11%0.00%
Turbo INT8-FP1623.48%2.82%0.00%
Figure 5. Choosing a Whisper model means balancing errors, time and memory (A). The supplemental breakdown (B) shows why the kind of recording matters. Its 50 clips are already included in the 175-English results, not a second independent sample.

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:

ModelRAM available after import in successful sessionRAM available after import in later session
Parakeet CTC 0.6B FP325,094 MiB4,673 MiB
Parakeet TDT 0.6B v3 FP325,083 MiB4,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 clientsCompletedThroughputFull-request P50Full-request P95 / P99Mean server queue wait
127/271.233 req/s0.741 s1.146 / 1.166 s~0 s
327/271.250 req/s2.175 s3.342 / 3.356 s1.405 s
Figure 6. With one Jetson worker, three RK1 clients achieved almost the same throughput as one, but waited much longer for transcripts. These timings cover complete HTTP requests, not live speech recognition or first-word response.

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

SymptomCheckNext step
faster-whisper cannot load its CUDA backendpython3 -c "import ctranslate2; print(ctranslate2.__version__)"; cat /etc/nv_tegra_releaseCheck 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 memoryfree -h; sudo tegrastats --interval 1000Check 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 resultssudo nvpmodel -q; sudo jetson_clocks --showCheck power mode, dynamic clocks, cooling and background load before comparing RTF.
RK1 cannot reach the servicecurl http://JETSON_LAN_HOST:8000/health; on Jetson: ss -lntpCheck the Jetson address, listening interface and local-network access.
Response time rises with multiple clientsMeasure queue time and full-request latencyWith one inference worker, concurrent requests wait even when the network is fast.
WER doesn’t match another published benchmarkCheck the reference transcripts and number handlingMatch 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

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.