For the next local run of Russian-language work meetings, we would choose Parakeet TDT 0.6B v3, and keep GigaAM v3 E2E RNNT as the second option. On the same 47 minutes 56 seconds of audio, these configurations showed similar processing times: 30.69 and 31.10 seconds. Parakeet retained 10 of the 17 selected control phrases, while GigaAM retained 8. This is a basis for the next check on our own recordings, not proof of universal superiority.
Below is a comparison of Russian speech recognition models Parakeet, GigaAM, Whisper large-v3-turbo, Qwen3-ASR-1.7B, and Voxtral Mini 4B Realtime 2602. We’ll break down speed, technical terms, meaning-changing errors, and how to choose a model for business use.
Author: Vladimir Lomtev. Publisher: Vladimir Lomtev AI Studio. Analysis date: October 29, 2026. The basis is a local experiment and its saved logs. The audio was not listened to during contextual evaluation; there is no manual reference transcript. Therefore, there is no measured WER or accuracy percentage below. Full meeting recordings and transcripts are not included in the publication.
This material is intended for developers, automation leaders, and teams choosing local meeting transcription. It tests batch processing of a shared set of clips on a single computer. Online latency, speaker diarization, CPU performance, and long-context model behavior will require separate tests.
Contents
- How the experiment was set up
- Speed results and control phrases
- What each model showed
- Which errors change the meaning
- Why control matches are not the same as WER
- How to choose a model for your task
- How to verify a transcript before sending it to CRM
- How to repeat the comparison on your own recordings
- Limitations of the results
- FAQ
How the experiment was set up
ASR, or Automatic Speech Recognition, is the automatic conversion of speech into text. For a business workflow, what matters is both the time to get results and preserving the specific meaning: who approved an action, what amount was named, and what constraint was set. A single convenient overall score hides these differences.
The experiment included three work discussion recordings with durations of about 5:38, 13:42, and 28:36. The exact total input length is 2875.541375 seconds; the “47:56” display is rounded. Each of the five models received 141 common fragments. A total of 705 results were saved in the logs.
The models were chosen from the Whisper/GigaAM tools already in use, plus three additional candidates for the same local hardware. The recordings came from available work meetings, not from a random sample of all Russian-language audio. This is a practical experiment for a specific conversation stream; representativeness for other companies has not been established.
Shared audio and identical boundaries
The input was normalized to one format: one channel, 16 kHz sampling rate, PCM with 32-bit floating-point numbers. In the logs for the five runs, each fragment has the same ID, start, end, and SHA-256 — the checksum of the input audio bytes. This makes it possible to verify that the saved results correspond to the same shared clip set.
While preparing the publication, all 705 log entries were checked and the hashes were compared across models. The intermediate PCM files are no longer available at the saved paths, so at this stage it was not possible to recalculate their hashes from the original bytes. Matching hashes in the logs and a fresh check of the audio itself are different levels of verification.
The maximum fragment length was 24 seconds. Boundaries were found using pauses with a threshold of −35 dB and a minimum duration of 0.25 seconds: 129 endings fell on detected pauses. The rest were due to file endings and forced cuts. According to the experiment log, the audio was preserved in full: no silence removed, no gaps, and no overlaps.
No context was carried over between fragments. The terminology glossary, previous transcripts, and user text prompts were not passed in. This makes input comparison simpler, but it limits conclusions about models that can use a longer conversation history.
Hardware and configurations
All runs were performed locally on an NVIDIA GPU with 8 GB of VRAM and an AMD Ryzen 7 5700X. According to the saved experiment manifests, the CUDA backend was used.
| Model | Weight format | Language mode | Engine in the experiment |
|---|---|---|---|
| Whisper large-v3-turbo | FP16 | Russian explicitly set | Installed local Parley engine |
| GigaAM v3 E2E RNNT | Installed v3_e2e_rnnt variant | Russian-language configuration | Installed gigaam-core |
| Qwen3-ASR-1.7B | FP16 GGUF | Russian explicitly set | transcribe.cpp 0.4.1 |
| Parakeet TDT 0.6B v3 | FP16 GGUF | Auto-detection | transcribe.cpp 0.4.1 |
| Voxtral Mini 4B Realtime 2602 | Q8_0 GGUF | Auto-detection | transcribe.cpp 0.4.1, processing ready-made fragments |
For Whisper, beam search 5, temperature 0, and four CPU threads were used. For the additional models, the manifests record four threads and n_ctx 2048. The transcribe.cpp source version is pinned to commit 5700f127e38dd53c4735ea23ef743b4b538eacd4.
Specific configurations are being compared in full. The engines and weight formats differ, so the observed difference cannot be attributed entirely to the neural network architecture. In particular, Voxtral was tested in Q8_0, not in the original full precision.
Speed results and control phrases
The time below is the sum of the saved processing times for the fragments after the model was loaded. It does not include downloading, engine compilation, audio preparation, weight loading, or the extra check of Qwen auto mode. This is one saved run of each configuration, with no repeated series to estimate variance.
| Model | Processing time for shared input, s | RTF | Context matches out of 17 |
|---|---|---|---|
| Parakeet TDT 0.6B v3 FP16 | 30.69 | 0.0107 | 10/17 |
| GigaAM v3 E2E RNNT | 31.10 | 0.0108 | 8/17 |
| Whisper large-v3-turbo FP16 | 142.49 | 0.0496 | 9/17 |
| Qwen3-ASR-1.7B FP16 | 148.00 | 0.0515 | 7/17 |
| Voxtral Mini 4B Realtime 2602 Q8_0 | 321.43 | 0.1118 | 10/17 |
The table source is the logs from five runs; totals and matches were recalculated during article preparation. The last column reflects the presence of expected contextual expressions, not the share of words correctly recognized. The criteria for selecting control samples are described below.
RTF, or Real-Time Factor, is the ratio of processing time to audio duration. For example, for Parakeet: 30.6865 / 2875.5414 ≈ 0.0107. A value below 1 means that in this batch run, processing took less time than the recording duration. RTF does not show the delay before the first words appear in live conversation.
Based on the saved timings, Whisper processed the full input about 4.64 times slower than Parakeet, and Voxtral about 10.47 times slower. The difference between Parakeet and GigaAM was about 0.42 seconds for the full set. Without repeat runs, such a small difference is best interpreted as roughly the same speed, not a stable advantage.
A low RTF also does not mean the finished meeting transcript will appear in the same number of seconds. In a production app, there will also be file reading, job queuing, speaker diarization, text review, and final document preparation. Those costs were not measured here.
What each model showed
The properties of the model families were verified against primary sources as of October 29, 2026. The official model card describes the model's capabilities and intended use; the behavior of a specific local run is established by experimental logs. These sources answer different questions.
Parakeet: the first candidate for the next run
NVIDIA Parakeet TDT 0.6B v3 is a multilingual speech recognition model. The official model card lists 25 European languages, including Russian. For download and deployment, use the information for v3 specifically: a similar name from another version does not confirm the same language coverage. NVIDIA Parakeet TDT 0.6B v3 model card.
In our run, Parakeet combined about 31 seconds of processing with 10 control matches. In one disputed case, it preserved "user scenarios"; in another, CRM. That is why it became the first candidate for the next recordings of this type.
At the same time, Parakeet did not preserve all technical abbreviations. There were distortions of UX and ZUP configuration. Choosing the model for the next test does not mean its output can be sent into business systems without checking important details.
GigaAM: similar speed and a useful second option
GigaAM is being developed as a family of models for speech recognition tasks; the specific version matters. The experiment used v3 E2E RNNT. The figures obtained cannot be transferred to another version or a CTC configuration without a separate run. Official GigaAM repository.
GigaAM processed the full input in 31.10 seconds and preserved 8 of 17 control expressions. Compared with Whisper, it handled "user scenarios," "task pool," and CRM more naturally in context. These examples explain why the model remains useful for Russian-language workplace conversations even with fewer selected matches.
Its weak points in this set were some IT terms and abbreviations. For example, "vibe coder" became "IPoder," and ZUP became "zub." If GigaAM is already built into the app, this experiment alone does not justify an urgent replacement: first, it is worth estimating the labor involved in corrections on new meetings.
Whisper Turbo: preserves individual terms, but meaning still needs review
Whisper is a family of multilingual OpenAI models. This test used large-v3-turbo; full large-v3 and large-v2 were not run here. Their results cannot be inferred from this table. The official repository also notes that performance depends on the language and usage conditions. Whisper repository.
Whisper Turbo produced 9 control matches in 142.49 seconds. Useful results included preserving UX, "Claude," and ZUP in separate fragments. If a technical term is distorted in the main text, an alternative Whisper version can help localize the spot for listening review.
However, in other fragments there were meaning mismatches: the number and the presence of negation differed from the four other systems. A majority agreement on one point does not make Whisper wrong, but such intervals cannot be accepted automatically. For this meeting stream, the model is better treated as an additional source of hypotheses until a benchmark measurement is obtained.
Qwen3-ASR-1.7B: no advantage detected in this run
The official Qwen3-ASR model card describes multilingual recognition and language identification. That makes the model a candidate for testing in mixed speech, but it does not guarantee preservation of a specific corporate vocabulary. Qwen3-ASR-1.7B model card.
The main run used an explicitly set Russian language. It produced 7 control matches in 148 seconds. In disputed places, it used "political" instead of the contextually expected "user" scenarios, and "Y-axis" instead of UX.
To check the effect of the language setting, 14 control fragments were additionally processed in automatic mode. The number of matches remained 7/17; the texts of 13 out of 14 fragments matched the ru mode word for word. This is a narrow test of the language-setting hypothesis. There was no full rerun of all meetings in automatic mode, so no conclusion can be drawn for the entire set.
Voxtral: comparable control matches with more time
Voxtral Mini 4B Realtime 2602 is designed for streaming transcription. The official model card describes latency control; checking finished short fragments in a third-party engine does not replace testing that mode directly. Voxtral Mini 4B Realtime 2602 model card.
In the Q8_0 configuration, the model produced 10/17 matches and processed the set in 321.43 seconds. On the selected expressions, it tied for the top result with Parakeet, while taking significantly more time. In some places the names and phrases were sensible, but no overall advantage was found that would justify this difference for batch processing of these meetings specifically.
The name Realtime does not contradict the table: the model's intended use and the speed of a specific offline run describe different properties. For live captions, first output, text stabilization, and behavior after pauses should be measured separately.
Which errors change the meaning
Differences in punctuation and turn segmentation are immediately visible. Meaning substitutions are more dangerous: the text can read smoothly but convey something else. In the experiment, Speaker labels, the number of filler words, and sentence formatting were not used to choose a preferred version.
Below are short anonymized fragments of model hypotheses. "Expected by context" means an interpretation of the business domain, not a quote from a meeting participant verified by ear.
| Type of discrepancy | One version | Another version | What needs to be checked |
|---|---|---|---|
| Meaning of the product discussion | "political scenarios" | "user scenarios" | Match with the topic and the original audio |
| Workload | "half-tasks" | "task pool" | Word combination and neighboring lines |
| Technical role | "vibe coder" | "IPoder" | Role name, not the plausibility of an individual word |
| Accounting configuration | "ZUP" | "zub" | Specialized abbreviation |
| Total | “five thousand per month” | “50 thousand per month” | The number from the audio, without choosing by majority |
| Negation | “strongly needed” | “not very needed” | The presence of the particle “not” |
Terms should be evaluated in their subject-matter context
In discussions of accounting configurations, “tooth” may be a grammatically acceptable word and at the same time an incorrect interpretation. An automated editor can make such a phrase sound even more convincing. If the check is limited to spelling and smoothness of the text, the problem will remain.
It is useful to include the project dictionary in testing as a separate condition. It may include product names, department abbreviations, and acceptable spelling variants. But the presence of a dictionary in the app does not yet mean that a specific engine uses it during recognition: sometimes it is only replacements after the text has been produced. In our overall run, the dictionary was not passed in.
Numbers and negations require a separate review queue
In one fragment, Whisper gave five thousand, while four other models gave fifty thousand. In another, four systems preserved a negation that was not present in the Whisper version. There is also the reverse example: at the beginning of the first recording, GigaAM returned 2006 where the four other models gave 260.
These places are excluded from the 17 control expressions: the context does not allow a reliable assignment of the correct number and original wording. Agreement across several systems helps prioritize review. It does not create a gold standard, because models can make similar mistakes.
For a working process, it is useful to save a timestamp next to an amount, date, or obligation. Then the editor can check the specific interval, and the recipient can see where the statement came from. If usable audio is not available, the questionable value should remain unconfirmed.
Why control matches are not the same as WER
WER, or Word Error Rate, is the number of substitutions, deletions, and insertions of words relative to the reference transcript, divided by the number of words in the reference. To measure it, you need a verified correct text and consistent normalization rules. The difference between two automatic transcripts by itself does not show which one is wrong.
This experiment used a different procedure: checking for the presence of 17 expected expressions in 14 selected fragments. The list included UX, sessions, user scenarios, Kontur, TIN, dashboard, PostgreSQL/Postgres, ClickHouse, VPN, CRM, task pool, vibe coder, leads, Claude/Klod, wrapper, big project, and HR payroll.
The rules accounted for some Latin and Cyrillic variants, word forms, and split-letter formatting. When preparing the publication, the matches were recalculated according to the saved rules control_checks.json. This reproduces the original check, but it does not improve the reliability of the expected words without listening to the audio.
The selection was made from the difficult points in the previous Whisper/GigaAM comparison before results from three additional models were obtained. Therefore, the list was deliberately enriched with problems from the two original systems. It is useful as a diagnostic set, but it is not a random or independent control sample.
You cannot turn 10/17 into “59% accuracy for Parakeet.” That recalculation ignores the remaining words, omissions, extra insertions, and the correctness of the expected expressions themselves. It creates the impression of a full quality metric, which does not exist here.
The correct wording of the result: in the selected context checks, Parakeet and Voxtral each produced 10 matches; the average recognition accuracy across the entire audio is unknown. This limitation remains regardless of model size or speed.
How to choose a model for your task
Start by defining what happens after recognition. A personal draft, archive search, and entering obligations into a CRM require different checks. The cost of corrections and the consequences of an error may matter more than a difference of a few seconds in processing time.
| Task | Where to start with this experiment | What to check before rollout |
|---|---|---|
| Batch transcription of similar Russian meetings on NVIDIA GPU | Parakeet and GigaAM | Quality on new meetings, time spent on manual editing |
| The existing process already uses GigaAM | Keep it as the baseline configuration | Does the switch deliver a noticeable benefit after text review |
| A lot of IT terms and internal abbreviations | Compare the main result with the additional Whisper hypothesis | Dictionary, names, recurring distortions |
| Live subtitles or a voice interface | Run a separate streaming test, including a suitable Voxtral mode | First output, stabilization, pauses, dropouts |
| Mixed languages and an unfamiliar subject area | Build a separate set for multilingual candidates | Language switching and terms in each language pair |
| Amounts, deadlines, and obligations move into the CRM | Any model with mandatory verification of critical fields | Audio, decision author, negation, units of measurement |
This matrix is a recommendation for the order of checks. It does not prove accuracy in scenarios that were not run. For example, the result on this GPU does not answer the question of speed on a laptop without a discrete graphics card.
When planning costs, consider the entire process: storing recordings, deployment, maintenance, and editing. These costs were not measured in the experiment. So speed alone cannot be used to calculate budget savings or the payback period.
For a general introduction to local options, it is useful to look at a separate article on meeting transcription with GigaAM, Whisper, and Parakeet. Its results belong to a different experiment; they cannot be combined with our table into a single ranking.
How to verify a transcript before sending it to the CRM
A practical workflow consists of primary recognition, searching for questionable spots, and confirming important fields. A second model can help find discrepancies, but it is not a human reviewer.
- Keep the original model hypothesis. Editing should create a new version of the text so that a disputed correction can be traced.
- Link the text to recording intervals. Open the disputed interval together with the audio and the options from several models.
- Highlight the fields with consequences. Amounts, dates, responsible names, restrictions, and negations require special attention.
- Obtain confirmation. The employee checks the audio; if it is unclear, the value remains unconfirmed or is clarified with the participant.
- Send the verified version to the business system. Save a link to the source and the verification status so that later changes do not erase where the data came from.
This is the proposed workflow, not a measured implementation result. It is possible to use a second model only for disputed intervals, but the effect of such a scheme on missed errors should be measured separately. If both models make the same mistake, a simple comparison of the texts will not raise a warning.
Summarization with a language model adds another step. From a smooth summary, it can be hard to tell whether a statement was actually said or appeared during paraphrasing. For important decisions, it is useful to require a link to a specific utterance and a confirmed field; the generation of the final document should preserve the connection to the source.
Local recognition helps organize processing on your own equipment. At the same time, you need to check the entire data path: call recording, logging, backups, and external services for summaries. The fact that a local ASR run was completed does not automatically describe the company’s full workflow.
How to Reproduce the Comparison on Your Own Recordings
Start with a small set of real-world tasks that reflects your workflow: ordinary meetings, poor microphones, technical terms, long monologues, and interruptions. Split the material into tuning data and final test data. If you tune parameters on the same clips that later determine the winner, the evaluation will depend on that tuning.
Record the Conditions Before You Start
For each configuration, note the exact model name, weight version, quantization, engine, device, language mode, and decoding parameters. Save the audio preparation and chunking rules. If one system gets a dictionary or long context, that must be a separate comparison condition.
Define in advance what counts toward time: only post-upload processing, or the path from file selection to finished text. For a product, both numbers are useful. Repeated runs will show how much the result changes; the number of repetitions and the aggregation method should be stated in the report.
Prepare a Verified Reference
A labeler listens to the selected intervals and records the correct words. Before calculating WER, agree on the rules for writing numbers, abbreviations, interjections, and unintelligible speech. Otherwise, formatting can change the score even when the content is the same.
At the same time, create a separate check for critical entities: amounts, deadlines, names, system names, and negations. You can weight them according to the impact on your process, but the rules must be set before reviewing the results. Overall WER and the quality of extracting key fields answer different questions.
Use a Test Card
Below is a template you can copy into a working document. Fill in the values based on the test; anything unknown remains unknown.
| Field | What to record |
|---|---|
| Purpose | Draft, search, protocol, CRM field preparation |
| Audio set | Selection rule, duration, language, recording type |
| Source | File version, checksums, permitted access |
| Preparation | Sample rate, channels, chunk boundaries, pauses, overlaps |
| Configuration | Model, weights, engine, hardware, language, prompts |
| Time | Measurement scope, repetitions, result, and variance |
| Quality | Reference, normalization, WER, verification of important entities |
| Manual effort | Review and correction time per unit of audio |
| Acceptance | Allowed errors and rules for confirming fields |
| Decision | Selected option, constraints, and conditions for retesting |
The result of such a test is a defensible choice for a specific process. If microphones, subject matter, model weights, or the engine change, you will need to verify that the earlier conclusions still hold.
Limitations of the Results
The comparison has several boundaries that affect the decision:
- Three recordings from one work context. The results do not cover accents, phone lines, noisy rooms, or every industry-specific vocabulary set.
- No audio reference. Context expectations may be wrong; average accuracy and WER remain unknown.
- A single short chunking setup. It equalizes the input but does not reveal the full capabilities of long context and streaming state.
- Different engines and weight precision. The table compares configurations, not the isolated efficiency of the architectures.
- One saved run. The stability of small timing differences was not statistically tested.
- Intermediate PCM files are unavailable during article preparation. The reanalysis confirmed that the logs matched, but it was not a new model run or a new check of the audio bytes.
Speaker separation accuracy, memory usage under load, maintenance cost, live interface latency, and editor labor were not measured. A successful GPU run does not prove a universal minimum video memory requirement for any implementation.
Model and software versions change. The conclusion applies to the listed weights, parameters, and logs as of October 29, 2026. It can serve as a starting point for the next test; it should be transferred to another environment only after verification.
Frequently Asked Questions
Which model recognizes Russian speech best locally?
In this experiment, the first candidate for the next run was Parakeet TDT 0.6B v3: 30.69 seconds to process the shared input and 10/17 contextual matches. GigaAM showed similar speed. Without a manual reference, it is impossible to declare a universal accuracy leader.
What is faster on GPU: Whisper or GigaAM?
In the saved configurations, GigaAM v3 E2E RNNT processed the set in 31.10 seconds, while Whisper large-v3-turbo FP16 took 142.49 seconds. This refers to time after the model was loaded on the same dataset, with no repetitions to assess variance.
Can 10/17 be treated as an accuracy percentage?
No. It is the number of matching expected expressions in specially selected difficult spots. WER requires an audio-verified reference transcript, which is not available in this experiment.
Why was the Realtime model slower?
Voxtral Mini 4B Realtime 2602 here processed ready-made chunks in a specific third-party engine and Q8_0 quantization. Streaming output latency was not measured separately. A model’s intended use does not determine the runtime of every way it can be launched.
Will running two models at the same time help?
It will provide two hypotheses and help identify some disputed spots. This comparison did not measure how much such a setup reduces errors. Matching results can also be wrong; significant fields should be confirmed against the audio.
Is a local model enough for a finished protocol?
Recognition creates the text foundation. For a working protocol, you also need verification of decisions, owners, deadlines, and amounts. These tasks and the later summarization were not evaluated for speed or accuracy in the ASR table.
Sources and Verifiability
The numeric table was taken from local experiment logs dated October 29, 2026. During article preparation, 141 results for each model, timing totals, and matches across 17 rules were recalculated. Shared identifiers, boundaries, and recorded input hashes were checked across all models. Full conversations and source audio are not published; independent quality verification based on this article is limited by the lack of an open reference and recordings.
Model properties were checked against primary sources:
- NVIDIA Parakeet TDT 0.6B v3: official model card.
- GigaAM: official repository.
- Whisper: official repository.
- Qwen3-ASR-1.7B: official model card.
- Voxtral Mini 4B Realtime 2602: official model card.
The October 29, 2026 version of the article describes one experiment. A later audio review may change the interpretation of disputed expressions; it should be documented as a new basis, not as a silent replacement of the original results.
How Vladimir Lomtev’s AI Studio Helps Integrate Transcription into Your Workflow
When implementing it, it is important to connect recognition with your company’s data and actions. As part of process audits, data preparation, multimodal integrations, and testing, Vladimir Lomtev’s AI Studio helps:
- describe the workflow from meeting recording to verified fields and the final document;
- prepare a dataset and acceptance criteria to validate it in your domain;
- integrate the approved voice workflow into the business logic and verify handoff of the results.
The first step is to choose one process, document the current time spent, data sources, constraints, and the criterion for an acceptable result. Support for a specific model and the deployment configuration are defined separately for the task. These directions align with studio services.
What decision to make based on this comparison
For the next evaluation of similar Russian-language meetings on this machine, it makes sense to start with Parakeet TDT 0.6B v3 and keep GigaAM as a close speed benchmark. Whisper may offer a useful alternative for specific terms. Qwen3-ASR-1.7B and Voxtral, in the configurations tested, did not show a reason to prefer them for this batch scenario.
The key selection criterion is to test the output on your own new recordings and separately confirm the important fields. Saved timings make it possible to compare speed. A conclusion about accuracy will require the next step: a ground-truth transcript from the audio and predefined evaluation rules.
