Self-hosted speech infrastructure
Audio in. Transcript and translation out. All 22 scheduled Indian languages.
TNT is a self-hosted speech pipeline that turns Indian-language audio into a clean transcript and a translation through a single API call. Two engines, one queue, one deployment unit. MIT-licensed weights, so there is no per-call vendor fee and no data leaving your infrastructure.
Planning stage. A complete technical specification, a costed deployment plan and a documented API contract exist. A running service does not.
- 22 scheduled languages, always on
- Confidence and quality tier on every response
- MIT-licensed models, self-hosted
- One API: POST /v1/transcribe-translate
Indian-language speech is still the hard part
Most teams building Indian-language products end up bolting a managed speech-to-text API onto a managed translation API and hoping the seam holds. It rarely does. The transcript arrives with no punctuation and no sentence boundaries, the translator expects clean sentences, and the quality loss happens invisibly in between. You pay two vendors per call, your audio leaves the country, and the languages you actually need are the ones with the worst coverage.
Two vendors, two bills, one broken seam
Speech-to-text and machine translation are sold separately. The layer that joins them - punctuation, sentence splitting, number formatting, protected terms - is nobody's product, so it becomes your bug.
Errors compound silently
A transcription mistake does not surface as an error. It is passed downstream and translated fluently into something confidently wrong. Most APIs will not tell you which parts they were unsure about.
Per-call pricing that scales against you
Managed transcription and managed translation are both billed per call, and a stitched pipeline pays both. Every minute of growth is a bigger bill, the price is set by someone you cannot renegotiate with, and the model weights are never yours.
One service. Two engines. One queue.
TNT packages an Indian-language speech recogniser and translator into a single deployable unit behind one API. The part in the middle - the part everyone else leaves to you - is built in.
Recognition
ai4bharat/indic-conformer-600m-multilingual
A single 600M-parameter checkpoint covering all 22 scheduled languages, with two decoding heads. The fast head serves live traffic; the accurate head re-decodes stored audio in the background so the answer you keep is better than the answer you saw.
Translation
ai4bharat/indictrans2
A 1B model plus distilled 200M and 320M variants, covering English to Indic, Indic to English, and Indic to Indic. The small models run the live lane, the large model runs the quality lane.
The seam
Voice activity detection, chunking with overlap stitching, punctuation restoration, inverse text normalisation, sentence splitting and do-not-translate glossary markup. This is not off-the-shelf. It is where most avoidable quality loss happens, and it is the reason TNT exists as a product rather than a tutorial.
No text-to-speech. The module is deliberately scoped as a foundation, with a documented output contract so speech synthesis, summarisation or an answering model can attach to it later without a rewrite.
All 22 scheduled languages. No add-on pricing.
Both models cover the full scheduled list in single checkpoints, so complete coverage costs nothing extra in memory or money. TNT never filters by language.
What it does instead is tell you the truth about quality.
Which Indian languages does TNT support?
TNT covers all 22 scheduled Indian languages in single model checkpoints, so complete coverage costs nothing extra. Coverage is tiered honestly rather than flattened: ten languages plus the English pivot are production grade, and the remaining twelve, including Kashmiri, Santali, Manipuri and Bodo, carry higher error rates. Every response states its tier.
Tier A - production grade
- Hindi - "हिन्दी"
- Bengali - "বাংলা"
- Marathi - "मराठी"
- Tamil - "தமிழ்"
- Telugu - "తెలుగు"
- Kannada - "ಕನ್ನಡ"
- Malayalam - "മലയാളം"
- Gujarati - "ગુજરાતી"
- Punjabi - "ਪੰਜਾਬੀ"
- Odia - "ଓଡ଼ିଆ"
- English - Pivot
Tier B - supported, higher error rate
- Assamese - "অসমীয়া"
- Bodo - "बड़ो"
- Dogri - "डोगरी"
- Kashmiri - "कॉशुर"
- Konkani - "कोंकणी"
- Maithili - "मैथिली"
- Manipuri - "মৈতৈলোন"
- Nepali - "नेपाली"
- Sanskrit - "संस्कृतम्"
- Santali - "ᱥᱟᱱᱛᱟᱲᱤ"
- Sindhi - "सिन्धी"
- Urdu - "اردو"
Every response carries a quality_tier field. We would rather tell you a language is Tier B than quietly pretend all 22 are equivalent. Word error rates are higher and translations are rougher. Gate these by confidence threshold rather than removing them, and your users in those languages get a usable product instead of no product.
Confidence is part of the contract, not a footnote
A fluent wrong answer is worse than a flagged uncertain one. TNT returns a confidence score for every segment, separately for recognition and for translation, and flags low-confidence spans instead of hiding them. Per-stage timings come back with every response too, so a performance regression is visible to you on the day it happens rather than in a support ticket three weeks later.
- asr_confidence and mt_confidence on every segment of every response
- Low-confidence spans flagged, never silently smoothed over
- quality_tier states whether the language is Tier A or Tier B
- timings_ms breaks down ingest, VAD, recognition, seam and translation
- version lets you refetch the improved result after background re-decoding
We will publish latency once we have measured it.
TNT is at planning stage. The pipeline is specified and costed, and nothing has been benchmarked on real hardware under real load, so there are no latency figures on this page. Publishing an estimate as though it were a measurement is the exact failure this company was set up not to commit.
What we can say is what those figures will describe, because that part is a design decision rather than a result. Latency is not one number. It is one per lane, and each lane degrades differently under load.
- Live
- A clip of thirty seconds or less, transcribed and translated in a single response on a warm GPU.
- Streaming
- Partial text arriving behind the speaker while they are still talking.
- Async batch
- A queue, measured per audio-hour rather than per request, at whatever utilisation the hardware is held at.
- Cold start
- A serverless worker with nothing warm behind it, which is the number a pilot deployment actually feels.
Each lane will be published at p50, p95 and p99. The median is the number that flatters a demo; the tail is the number that wakes somebody up.
An SLA you measure is an SLA you can defend. An SLA you guess at is a liability.
Runs where your data is allowed to be
One container, one queue, one GPU to start. No Kubernetes until you have more than one node, and a single Docker Compose box with a queue gets you further than most teams expect.
Pilot
Serverless GPU with scale to zero. Idle cost is near zero; cold starts sit behind an async job API.
Growth
One reserved 24 GB GPU on an Indian cloud or a Mumbai region. Data residency friendly.
On-premise
Your own hardware. One 24 GB GPU, 8 vCPU, 32 GB RAM. Nothing calls out.
Because the weights are MIT-licensed and the whole pipeline is one deployment unit, TNT can run entirely inside your network. No audio leaves your infrastructure, no third party sees a transcript, and there is no vendor who can change per-call pricing under you.
Compute you control, not a licence you cannot renegotiate.
The weights are MIT-licensed. That is the whole economic premise, and everything else follows from it: no per-call fee, no vendor with the unilateral ability to reprice you, and no floor under your unit economics that somebody else sets.
It also changes the shape of the curve rather than just its height. A managed stack bills per call, so the bill tracks volume forever. A self-hosted one bills for hardware time, so the bill tracks utilisation - and utilisation is something you can work on.
Three ways to pay for the same audio-hour
Managed speech-to-text plus managed translation
Two per-call meters running on the same audio, plus the seam between them, which you build and maintain yourself.
TNT, self-hosted
GPU time on infrastructure you chose, at whatever utilisation you hold it at. One deployment unit, one bill, no per-call meter.
TNT, pure batch at high utilisation
The same GPU time spread across a full queue. The cheapest lane, and the one that gets cheaper the more work you feed it.
How the deployment changes as the workload grows
| Active users | Audio per month | Infrastructure |
|---|---|---|
| 10 | 5 hours | Serverless, scale to zero |
| 100 | 50 hours | Serverless |
| 1,000 | 500 hours | Serverless, or a part-time dedicated GPU |
| 10,000 | 5,000 hours | One dedicated GPU plus peak capacity |
At an assumed 30 minutes of audio per active user per month. That assumption is the whole of the audio column - change it and every row moves with it.
Built for teams whose users do not speak English
- Contact centres
- Every call transcribed in the language it was spoken and translated for QA, compliance and coaching. Batch pricing, not live pricing.
- Consumer and social apps
- Voice notes, comments and user video captioned and translated across the 22 scheduled languages your users actually type in.
- Government and public services
- Records, grievances and field recordings, processed on infrastructure inside your own boundary.
- Media and education
- Lecture and interview archives turned into searchable, translated text with word-level timestamps.
Questions people actually ask
Bring speech to the languages your product already has users in
TNT is being built as one deployable unit with a documented contract, an honest confidence signal and a cost model that survives contact with growth. If you have Indian-language audio and a reason to keep it on your own infrastructure, we would like to hear about the workload.
Tell us the languages, the audio volume, and whether you need live or batch. That is enough for us to tell you what it would cost. The address is engineering@punkraven.com.