← Blog

Comparison

Whisper, Google Speech, or SpeechKit: what to choose for Russian speech

Whisper, Google Speech-to-Text, and Yandex SpeechKit solve the same task, yet they are built in fundamentally different ways. The first is an open model you can host on your own server and never pay per minute. The second is a global cloud API billed in dollars with a huge ecosystem. The third is a Russian cloud where the Russian language is a first-class citizen and data stays in the country. People argue about them on the level of who is more accurate, while in practice the choice comes down to four things: quality on your specific type of recording, the cost of an audio hour including add-ons, latency, and data jurisdiction. Below is a comparison without marketing, with a measurement methodology and scenarios where each option wins.

Three different products, not three buttons

Whisper is not a service but a family of open models. OpenAI published the weights, and from there you decide where and how to run them: on your own GPU, on a rented one, or on a CPU. You do not pay per minute of recognition, data never leaves your infrastructure, and the model can be fine-tuned or wrapped in your own pipeline. The price is operational responsibility: servers, drivers, queues, updates, monitoring, and a person who understands MLOps. For a team without GPU experience, that is not an evening of work but a separate project.

Google Speech-to-Text is a classic managed cloud API. You send audio, get text, and pay per minute. Included are streaming recognition, speaker diarization, word-level timestamps with confidence scores, domain adaptation, and global infrastructure with clear availability guarantees. The flip side is dollar billing, the need to deal with payments and taxes, and the question of where recordings are physically processed and stored. For a product living outside Russia, this is often the shortest path. For a Russian business handling personal data, it is an extra legal layer.

Yandex SpeechKit is a Russian cloud with the Russian language at the center of the product. It knows local vocabulary well, supports streaming and deferred recognition, and accepts payment in rubles by card or through SBP. Data is processed in Russia, which removes a large part of the 152-FZ concerns. The limitations are equally clear: a narrower ecosystem than Google, limited deep model customization, and a per-minute price that starts to differ noticeably from your own server at large volumes.

There is also a fourth option that general comparisons mention least often: a hybrid. An open model runs on the provider's managed GPUs, while the client gets a familiar API, a ruble invoice, and support. That is exactly how our platform works: faster-whisper large-v3 under the hood, pyannote for speaker diarization, and Silero VAD for speech detection. You get the quality and privacy of a self-hosted solution without maintaining your own GPU fleet. For the rest of the article I will compare all four options, because in practice people choose a model of ownership, not a brand.

Methodology first, brand second

Comparing vendors by marketing promises is pointless. Build a reference set of 20-50 clips from your own recordings: a phone call, a meeting, a clean microphone, a noisy office, two speakers, rare names and terms. For each clip, prepare the text that is actually spoken in it. Then run the same set through every candidate and compute WER, the share of wrong words. This is the only metric that lets you compare options against each other on your own data.

It is important to measure more than WER. The cost of an audio hour with the add-ons you need, the 95th percentile latency, behavior under peak load, and the amount of manual correction after recognition. The last point often matters more than raw accuracy: if the model gets names and amounts wrong, an editor will have to re-listen to the recording even when the overall number looks decent. An editor's hour almost always costs more than a recognition hour, so correction belongs in the economics just as much as minutes do.

Test the domain separately. A WER measured on read speech says almost nothing about an 8 kHz phone channel. If your product is call quality control, test calls, not podcasts. If it is subtitles, test video with music and overlapping speech. Results on someone else's benchmark are only a rough guide: they show an order of magnitude, not your result. The gap between the model is good on average and the model is good on my recordings costs weeks of rework.

There are two ways to compute WER. On the Pro and Business plans, the POST /v1/eval endpoint takes audio and a reference text, recognizes the recording itself, and returns a ready word-level breakdown. If you are on Free or comparing several services at once, run transcription through the API and compute the metric locally; a few lines of Python are enough.

Python
import re
from difflib import SequenceMatcher

import requests

def normalize(text):
    return re.findall(r"\w+", text.lower().replace("ё", "е"))

def wer(reference, hypothesis):
    ref, hyp = normalize(reference), normalize(hypothesis)
    matcher = SequenceMatcher(a=ref, b=hyp, autojunk=False)
    errors = 0
    for tag, i1, i2, j1, j2 in matcher.get_opcodes():
        if tag != "equal":
            errors += max(i2 - i1, j2 - j1)
    return errors / max(len(ref), 1)

API = "https://ttsapi.ru/v1"
HEADERS = {"X-Api-Key": "rtt_…"}

with open("sample.wav", "rb") as f:
    r = requests.post(
        f"{API}/transcribe/sync",
        headers=HEADERS,
        files={"audio": ("sample.wav", f, "audio/wav")},
        data={"language": "ru"},
    )

reference = open("reference.txt", encoding="utf-8").read()
print(f"WER: {wer(reference, r.json()['transcript']):.3f}")

Whisper: why open source is still strong

Whisper's strength is versatility. The large-v3 model supports about 99 languages, handles punctuation reasonably well, and is robust to accents and background noise. Russian is not its native language, but on clean speech the result is close to commercial services. faster-whisper speeds inference up several times thanks to CTranslate2 and can run the model in int8 on a GPU or even a CPU, which makes it accessible for small projects. Open weights mean you are not tied to a price list and can adjust the model to the task.

The weak spots are known too. Whisper tends to hallucinate on silence and music: instead of an empty fragment it may emit a phrase from its training subtitles. Diarization is not built in and has to be added as a separate pipeline such as pyannote. There is no out-of-the-box streaming mode: live recognition needs VAD and chunking with overlap. Long files also have to be split manually, otherwise the model loses context or runs out of memory. Each of these points is solvable, but each costs engineering time.

Self-hosted economics look attractive only under load. large-v3 takes about 5 GB of video memory, so you need a GPU that is not idle. Renting a card like an RTX 4090 or A10 costs tens of thousands of rubles a month, plus disk, traffic, and engineer time. At a hundred hours of audio a month, your own server is almost certainly more expensive than the cloud. At a thousand hours with a steady stream, the picture flips: fixed hardware cost is spread across volume and the per-minute price drops several times.

Whisper is chosen when control and privacy matter: medical records, internal conversations, data that cannot go to the cloud, or a task with a very large volume. It is also used as the foundation of a product when custom logic around recognition is needed: your own dictionaries, post-processing, integration with a language model. That is why the open model remains the foundation of most managed services, including ours.

Google Speech-to-Text: the ecosystem and its price

Google Speech-to-Text is strong where predictable infrastructure and a rich feature set are needed. Streaming recognition, speaker diarization, word-level timestamps with confidence, domain adaptation through phrase lists, and a choice of processing region. Documentation is detailed, SDKs exist for almost every popular language, and the provider guarantees resilience. If your team already lives in Google Cloud, integration takes hours rather than weeks.

The limitations start beyond technical capabilities. Dollar billing means a card, an exchange rate, and taxes; for Russian companies this is often an insurmountable barrier. Streaming sessions are capped in duration, so an endless stream will have to be reconnected anyway. Data is processed outside Russia, which requires a separate legal assessment when personal data is involved. Latency from a remote region also makes itself felt, especially in interactive scenarios.

Google is chosen when the product serves a global market, the team already uses GCP, and multilingual support is needed without owning infrastructure. For a Russian call center with customer recordings, it is rarely the optimal option even if recognition quality is satisfactory: the blocker is not the model but the contract and jurisdiction.

Hidden costs are worth estimating in advance. Free minutes are limited, after which the price grows linearly; storing results, network traffic, and currency conversion add on top. Count not the price per minute but the full quarterly bill including every service you use in the same cloud. Often it is the adjacent budget lines, not recognition itself, that determine the final amount.

Yandex SpeechKit: Russian as the first language

SpeechKit is the most natural choice for a Russian product. The Russian language is the primary target rather than an add-on, so local names, company names, and colloquial vocabulary are recognized predictably. There is synchronous and streaming mode, deferred processing for large files, and speaker diarization. Ruble payment, data in Russia, support in Russian: for many teams this is the decisive argument that outweighs a fraction of a percent in WER.

The limitations are tied to ecosystem scale and flexibility. Customizing the model beyond dictionaries and settings is difficult. The feature set is narrower than Google's, so some capabilities have to be built in-house. At large volumes the ruble price per minute becomes noticeable, especially compared with renting your own GPU. For a startup that is not a problem; for a service with thousands of hours a month it is already a budget line.

SpeechKit is chosen when a fast start without infrastructure, compliance with data storage requirements, and a predictable ruble budget are needed. It is a good fit for call centers, meeting transcription services, and products where Russian is the main scenario and the team does not want to run a GPU farm.

When estimating the budget, do not forget the minimum billing increment, the streaming rate, and paid add-ons. As of October 2026, the benchmark is about 0.65 rubles per minute for synchronous and streaming recognition, 0.61 for deferred, and 0.15 for the delayed-output mode. Prices change, so check the official price list before calculating. Also check how a short utterance is billed: a billing block can turn a ten-second request into a full minute.

Comparison of key parameters

Let us put the key parameters into one table. It does not replace testing on your own data, but it helps quickly rule out options that do not fit by jurisdiction, budget, or feature set. Pay attention to the data and onboarding rows: those are the ones that most often become decisive, even though reviews give them the least space.

CriterionWhisper (self-hosted)Google Speech-to-TextYandex SpeechKitVoice kit API
What it isopen modelcloud APIcloud APImanaged Whisper
Data locationyour ownabroadin Russiain Russia
Billingyour hardwareUS dollarsrublesrubles
Diarizationseparate (pyannote)yesyesyes (Basic+)
Streamingbuild it yourselfyesyesyes (Pro+)
Word-level timestampsyesyesyesyes
Key wordsvia promptadaptationdictionarieskeyterms
Long filessplit manuallysession limitdeferred modeup to 512 MB / 4 h
OnboardingGPU and MLOpsGCP and billingYandex Clouda key in a minute

Total cost of ownership: cloud versus your own server

The cloud charges per minute, and the bill grows linearly with volume. That is convenient at the start: no capital expenses, no idle hardware, no need for an on-call engineer. But at large volumes linear growth becomes the main budget constraint. The more successful the product, the more recognition pulls out of the margin.

Your own server works the opposite way: a large fixed cost and an almost zero variable cost. GPU, disk, electricity, and the engineer's salary do not depend on how many minutes you recognize. The higher the utilization, the cheaper the minute, and the worse idle time looks. That is why self-hosting makes sense either with a steady stream or when you already have a GPU for other tasks and recognition uses only part of its time.

Rough arithmetic. A hundred hours of audio a month is 6,000 minutes. At SpeechKit's price of about 0.65 rubles per minute, that is roughly 3,900 rubles. With Google, at about 90 rubles per dollar and a rate of 0.016 dollars per minute, it comes to about 8,600 rubles. Renting and maintaining a GPU costs tens of thousands of rubles, so self-hosting loses at that volume. At a thousand hours a month the picture flips: the cloud will cost hundreds of thousands, while your own server stays roughly the same.

That is exactly why a managed hybrid covers the middle segment: you pay per minute at a ruble rate but do not maintain infrastructure or pay for idle time. On our platform, 150 audio minutes a month are included in the free plan, Basic at 390 rubles gives 1,800 minutes and diarization, Pro at 1,490 gives 9,000 minutes, streaming recognition, and long recordings, and Business at 7,990 gives 30,000 minutes and the priority queue. Above the limit, pay-as-you-go works from your balance: 0.40 rubles per minute for asynchronous transcription and 0.50 for synchronous. see pricing.

What to choose for your task

A call center in Russia. The phone channel, diarization, key words, and in-country data storage are critical. SpeechKit or a Whisper-based hybrid are optimal: keyterms hint at plan and product names, diarization separates the operator from the customer, and long recordings up to four hours cover a whole shift without manual file splitting.

Media and subtitles. Word-level timestamps, even segments, and SRT or VTT export are needed. Whisper-based solutions win here: they provide word-level timestamps, and on top you can enable subtitle translation and marks for fast or unclear speech. Built-in captions from video hosting platforms do not give you such a file, so an API remains the only way to get editable subtitles.

Meetings and protocols. Diarization, long files, and webhooks matter, so you do not poll status in a loop. All four options fit, but the hybrid is cheaper at volume, while SpeechKit is simpler in terms of procurement and paperwork. If protocols must go to a CRM or a messenger, check for webhooks and ready integrations before buying.

Privacy and on-premises. If recordings cannot leave your perimeter, only your own Whisper remains. Then estimate GPU, redundancy, and model updates in advance, or the economics will be worse than the cloud. Separately decide who owns quality after a weight update: without an owner, degradation is noticed too late.

A prototype or an MVP. Take whatever connects fastest and do not spend weeks on infrastructure. The free tier of any cloud lets you validate the hypothesis before the first payment, and make the infrastructure decision based on real load numbers rather than a forecast.

A one-evening checklist

Build a set of 20-50 clips, prepare references, and run them through the candidates. Compute WER, the cost of an hour with add-ons, p95 latency, and the share of clips that needed manual correction. Add a limits check: file size, duration, request rate, and webhook support. If even one item fails, further comparison is pointless.

Separately test what most often ruins the impression from a demo: first and last names, company names, numbers and amounts, abbreviations, accents, noise, music, and overlapping speech. If the product is international, add clips with mixed speech where Russian and English appear in the same sentence. Those recordings show whether the model preserves terms instead of replacing them with similar-sounding words.

And do not forget monitoring. WER is not a one-off check before purchase but a metric worth keeping on a reference set and recomputing after model updates or a domain change. Degradation is noticed in the number much earlier than in user complaints. A good practice is to keep references in the repository and run the check in CI along with the rest of the tests.

Bottom line

There is no absolute winner. Whisper wins on control, privacy, and cost at large volumes. Google wins on ecosystem and global coverage. SpeechKit wins on the Russian language, ruble billing, and jurisdiction. A managed Whisper hybrid occupies the middle: the quality of an open model without operational load or GPU procurement.

The practical conclusion is simple: state your requirements along four axes, data, money, latency, and features, and test the candidates on your own set. After that the choice usually becomes obvious, and it rarely matches what general comparisons recommend. The only bad strategy is choosing by a marketing accuracy number and discovering the problem in production.

If you want to test the hybrid on your own recordings, start with the free plan: 150 audio minutes, no card. That is enough to run a test set, compute WER, and compare the result with the services you are considering. The full list of parameters and limits is here - see the documentation.

Compare on your own recordings

The free plan includes 150 audio minutes a month. Run your set through Whisper with diarization, key words, and timestamps, with no card and no GPU deployment.

Transcribe my first file see pricing
← All articles