A student in a Telugu classroom asks a question in Telugu with three English technical terms in it. A science teacher explains a physics derivation in Hindi, but every variable, unit, and law keeps its English name. Somebody types their reply back in Roman script, because that’s what their keyboard is set to. None of this is unusual. It is what a normal day of Indian speech sounds like.

Transcribing speech like this means getting two things right: the language it was spoken in, and the script it should be written in. Multilingual speech recognition isn’t new, and the good models handle Hindi, Tamil, or Bengali read cleanly into a microphone perfectly well. But coverage thins fast as you move down the list of Indian languages, dialects get collapsed into whatever standard language they’re closest to, and accuracy drops once the audio stops being clean: classroom noise, phone lines, spontaneous speech, an accent the training data didn’t have much of. And nearly every system assumes one language per utterance and one script per output, which rules out the Telugu student, the physics teacher, and the Roman-script reply all at once.

Indic-Transcribe is our attempt to close that gap. It’s a family of two 1.2B-parameter speech recognition models covering 27 languages: all 22 constitutional Indian languages, English, the Haryanvi and Chhattisgarhi dialects of Hindi, and Bhili and Bhojpuri. Both take the same input, the speech India actually produces: code-mixed, accented, recorded in noisy places. What they differ in is the output. Core transcribes into each language’s own script and is the more accurate of the two. Flex writes the same speech three ways: native script, romanized, and mixed script, so the transcript matches how people actually read and write. Let’s look at them in action.

Try it out: Pick a state on the map to hear a speaker from there and see what the model wrote. See how our model transcribes hundreds of accents, from a Kupwara man’s Kashmiri to a Kakching woman’s Manipuri. Indic-Transcribe was built to hear all of it.

We’re releasing Indic-Transcribe as two checkpoints rather than one, because the two things people ask of a transcript pull in different directions. One is accuracy: the closest possible match to what was said, in the language’s own script. The other is format: a transcript in the script the reader or the downstream system actually wants. Trying to serve both from a single set of weights costs you on the first, so we trained two.

They share an encoder, a tokenizer, and a training corpus; they differ in the output space they were trained to cover. If you only need one, start with Core.

Real speech does not arrive clean. It comes with an accent, in a dialect, with English mixed in, over music or a crowd. Both models were trained for all of that. The clips below are Core, since these cards are about what the models hear rather than how they write it down. Each one lets you play the audio and check the transcript yourself.

Architecture

Both Indic-Transcribe models are 1.2B-parameter encoder-decoder models built on the same backbone. The encoder is a FastConformer, taken from NVIDIA’s Canary family, and it accounts for most of the parameters. Reusing a strong pretrained speech encoder let us spend our effort where the actual problem was: not on learning to hear, but on learning to write down what was heard, in the right language and the right script.

That part is the decoder, and it’s new. We train a 24-layer Transformer decoder from scratch on top of the encoder, larger than the one Canary uses. Rebuilding it was necessary because the output side is where Indian speech gets complicated. A single utterance may span two languages, and the correct transcript for it depends on who’s going to read it.

Core and Flex differ only in the decoder. Same encoder, same tokenizer, same decoder shape, trained toward different output distributions. Core’s decoder only ever has to produce native script, so all of its capacity goes into getting those words right. Flex’s has to produce three scripts on demand and hold them consistent with each other, which is a harder job and costs it some accuracy on the native-script task.

One vocabulary for 27 languages: a single joint BPE vocabulary of 7,152 tokens (6,000 multilingual subwords + 1,152 special and task tokens) covers Devanagari, the Dravidian scripts, Bengali, Perso-Arabic, and Roman together, forcing subword units to be shared across languages rather than each carving out its own corner.

Telling the model what you want: following Canary’s task-token scheme, language and transcription mode are set by tokens passed to the decoder. For Flex that means native-script, romanized, and mixed-script output all come from one set of weights rather than three models. Core takes the same language token and ignores the mode.

Working with real audio: the model processes audio in windows of up to 30 seconds; for longer recordings we recommend VAD-based chunking on natural speech boundaries.

Training data

The architecture is only half the story. A model that works across India’s linguistic range is mostly a data problem, and Indic-Transcribe was trained on 1.3 million hours of audio.

Weakly supervised data drawn from a wide range of sources on the internet, selected deliberately for variety rather than cleanliness: different background noise, recording conditions, speaking styles, and subject matter, because clean read speech teaches a model very little about the audio people actually record.

Two further sources shaped the model in more specific ways.

Synthetic data was created to fill known gaps. General-purpose speech data underrepresents the vocabulary of the domains our users care about, so we generated data targeting them directly: education, agriculture, healthcare, banking and financial services, insurance, customer service and support, e-commerce and retail, and government schemes and public services. Each carries its own terminology, and much of that terminology is English embedded in an Indian-language sentence, exactly the case a model has to get right to be useful in production.

Human-labelled data comes primarily from IndicVoices: transcribed speech across 22 Indian languages, collected from speakers across the country and verified through strict maker-checker pipelines. It’s the part that anchors everything else to ground truth.

Balancing it. Hindi audio is abundant on the internet; Bhili is not. Trained naively on that distribution, a model becomes excellent at the languages that need the least help. We use temperature sampling to reweight the mix, deliberately raising the representation of low-resource languages during training so that coverage of 27 languages means something more than a line in a feature list.

This turned out to be the hardest part of the work, and not only across languages. The model has to hold up across domains, speaking styles, and all three transcription modes simultaneously, and these pull against each other; improving one slice of the distribution has a way of quietly costing you another. Most of our effort went into getting that balance right, and into designing the synthetic data carefully enough that the domain vocabulary Indian use cases depend on was actually covered rather than assumed.

Two models means two numbers on every benchmark, and the gap between them is the point rather than an embarrassment. We score both on the same clips against the same references, using OIWER, word error rate against multi-reference transcripts that accept documented spelling and transliteration variants, because a model shouldn’t be penalised for spelling a Hindi word the way half the country spells it. Core is the more accurate model everywhere; Flex pays for its output flexibility. How much it pays is what these charts are for, and it’s the number to weigh if you’re deciding between them.

Indic-Transcribe is a starting point rather than a finished product. Transcription is the first thing you need from a speech system and rarely the last, and the gaps we’ve described in this post don’t close with one model release. A few directions we’re working toward:

Real-time streaming: the current model transcribes recorded audio. Live captioning, voice interfaces, and support calls need transcription as the speech happens, not after it.

Speaker diarization: knowing who said what. A classroom recording or a customer call is a conversation, and a transcript without speaker turns loses most of what makes it useful.

Multi-speaker source separation: real Indian recording environments are rarely one voice at a time. Separating overlapping speakers is what makes diarization hold up outside clean conditions.

A model under 100MB: small enough for on-device and edge deployment. Speech recognition that needs a server and a connection isn’t available to everyone who needs it; a model that runs on the phone in someone’s hand, offline, is a different proposition entirely.

Wider language coverage: more dialects and more low-resource languages. Twenty-seven is a good start and nowhere near the number India actually speaks.

Closing the gap between Core and Flex: Flex’s extra output modes currently cost accuracy. They shouldn’t have to. Getting a single model to write three scripts as well as Core writes one is a training problem we think is solvable.

If you build with it, we’d like to hear how it does, especially where it fails. The languages, dialects, and conditions we haven’t covered well are the ones we most need to be told about, and a bug report from someone working in a language we underserve is worth more to us than any benchmark. Both models are on Hugging Face: Indic-Transcribe Core and Indic-Transcribe Flex, and the API is live; links are below.