One recording, four jobs: NVIDIA's Nemotron 3.5 Transcribe packs transcription, speakers, translation, and Q&A into one model

On 28 October 2026, NVIDIA released Nemotron 3.5 Transcribe. This is not just another model that turns speech into text, but one that can "switch jobs on instruction": with a different prompt, the same recording yields a speaker-labelled transcript, an English translation, word-level timestamps, or answers to questions about the recording. For people building meeting notes, lesson replays, and medical dictation, that means a pipeline that used to need four or five tools may now converge into a single checkpoint.

The model's full name is NVIDIA-Nemotron-3.5-Transcribe-30B-A4B, and the name already tells half the story: about 30 billion parameters in total, a mixture-of-experts architecture, with about 4 billion actually active per token. In other words, it is a model that "looks big but runs reasonably small". NVIDIA's official Hugging Face blog says it can run on a single GPU, from edge and desktop devices such as Jetson AGX Thor and DGX Spark all the way to Blackwell data-centre GPUs. That "runs on one card" claim is the most practical difference between it and many speech models that need a cluster.

One checkpoint, four outputs

First, what "one checkpoint" means. A traditional speech pipeline is usually assembled in stages: one model transcribes, another separates speakers, a third translates, and if you want question answering, a fourth language model is attached. Each stage has its own error rate, and errors propagate downstream. Transcribe puts all four jobs into one model and switches between them with natural-language prompts. The official blog's examples are plain: for the same meeting recording, the prompt "Transcribe this recording and label each speaker" yields a labelled transcript; "Translate this audio into English" yields a translation; "What decisions were made in this meeting?" yields an answer.

The friendliest part of this design for developers is not saving a few models, but saving several interfaces and the work of aligning their formats. Transcripts, speaker labels, timestamps, and translations all come from the same inference run, so timestamps and speaker labels are less likely to drift apart. But it also creates a new requirement: the prompt itself becomes part of the product. A vague prompt on the same recording yields a vague output; a prompt that states the language, the written format, and a glossary produces visibly better output. The official blog specifically recommends giving context before training when terms are unfamiliar — use a glossary in the prompt first, and only fine-tune what the prompt cannot cover, which saves far more than jumping straight to fine-tuning.

Language support is asymmetric: check the table before choosing

Transcribe's language numbers are easy to misread as "40 languages, all equally good". They are not. The support matrix in the official blog is split by task: transcription in 40 languages; translation between 31 of them and English; speaker attribution in only 13 languages; audio question answering trained in English only. Recordings are capped at about one hour, with at most eight speakers labelled. Spread the table out and the selection conclusion is clear: if you want meeting transcription with speaker labels in English or a mainstream language, it hits the target; if you want speaker separation in a smaller language, or non-English recording Q&A, it is not the answer yet, and forcing it will only produce results that "run but cannot be trusted".

Word-level timestamps deserve a mention of their own. A transcript without timestamps is painful to verify, locate, and edit later; with word-level timestamps, a lesson replay can show "text following the recording", and meeting notes can jump to the exact audio position from a single sentence. The official blog notes that the real-time voice and video platform Agora used this capability in a classroom demo, turning a recorded lesson into a timestamped transcript so students can see what was said and when. That example also marks the boundary of use: it is designed for "recorded replay", not "live captioning". The official blog states plainly that it is built for recorded audio, not live streams. Live captioning, live voice assistants, and live phone transcription need a different model; do not expect this one to "also" support them later.

Benchmark numbers: vendor figures, read one by one

NVIDIA's benchmark results in the official blog are striking, but each one must be labelled "vendor-reported, not independently reproduced". On the Hugging Face Open ASR Leaderboard, the English average word error rate (WER — lower is better) is 5.33%, first among open-weight models; the seven-language multilingual average is 4.62%, and the long-form average is 10.98%, also the lowest among open-weight models in the blog's comparison. A 5.33% WER means roughly one word wrong in every 20 — usable for meeting notes, but names, places, and technical terms still need human checking.

On Artificial Analysis's speech-to-text leaderboard, Transcribe ties for first among open-weight models at 2.8% AA-WER, with about one-sixth of the active parameters of the model it ties (about 4 billion versus about 24 billion). That "one-sixth" claim is the most memorable efficiency point of this release: it wins on architecture and data, not by stacking parameters. But it must also be noted that AA-WER is that organisation's own weighted index, not the same number as Hugging Face's WER, so the two cannot be compared directly. Both leaderboards point to the same directional conclusion — "top tier among open-weight models" — but each figure only makes sense inside its own leaderboard.

The speaker-attribution results need the same unpacking. On David AI's 21-language transcription-plus-speaker benchmark, Transcribe's diarization error rate (DER) is 18.26%, the lowest of 14 systems tested, just ahead of NVIDIA's dedicated speaker model Nemotron 3 Diarization at 18.38% — remember, lower is better here, so 18.26% is the better side. On VoiceArena's English full-session benchmark, its concatenated minimum-permutation WER (cpWER) is 32.4%, again first of 14 systems, with a deletion rate of 8.32% against a median of about 31%. These numbers show real work on "who said what, when", but an 18% diarization error rate also means that long meetings with ten or more people and overlapping speech will still produce misattributed turns, and key statements should be confirmed against the original audio.

Granary v2: half the value may be in the data

Released alongside the model is Granary v2, an open multilingual speech-data curation pipeline built with NVIDIA NeMo Curator. Its public manifest covers 463,062 hours across 48 languages and 16 source corpora, nearly double the previous version's 25 languages. Note carefully that the official blog states this figure describes the dataset release, not Transcribe's full training mixture or sampling weights. Reading "manifest size" as "training size" is the most common misreading of releases like this.

Granary v2's value is not the hour count itself, but the shapes of data it produces. For the same recording, the pipeline generates three transcript forms: a verbatim version keeping fillers, a spoken-form version with normalised numbers and currency, and a clean version without fillers. Developers can request one of these forms directly from Transcribe with a prompt, instead of writing their own cleaning rules. Beyond that, the pipeline produces short audio captions, loanword restoration for code-switching, speech-grounded Q&A pairs, contextual ASR biasing terms, and translations with automatic quality scores. These "training targets" are why Transcribe can switch tasks by prompt: the model saw these task forms during training, so it can switch after release.

For teams wanting domain adaptation, the official blog's path is prompt first, fine-tune second, with a medical case study attached: on an open benchmark of recordings from Indian doctors and medical students, building adaptation data from generated medical text and public medicine catalogues cut WER on held-out speakers by 45.8% relative to the best prompt. That figure is a "relative reduction", not an absolute error rate, and the benchmark itself has no designated training split, so it should be read with caution. But the direction is clear: solve terminology, accent, and written-form problems first with a glossary and examples in the prompt, and only then go to NeMo Speech fine-tuning — cheaper and less risky.

Single-GPU deployment: measure throughput before promising replacement

On deployment, the official blog's throughput figure grabs attention: on one RTX PRO 6000 Blackwell Server Edition GPU, using the forthcoming NVFP4 quantized version, 100 hours of audio were processed in under three minutes. But the footnote matters just as much: the test used 30-second clips at high concurrency. A continuous one-hour meeting will behave differently in practice, so "100 hours in 3 minutes" cannot be promised directly as a production metric. Before deployment, test with your own recordings — same length, accents, and noise levels — and only then write commitments, internal or external.

Currently available deployment routes include serving with vLLM and local deployment with NeMo-Speech.cpp, with quantized versions provided; hosted endpoints come from third parties such as Baseten and DeepInfra, and the official blog does not present a free NVIDIA trial API as the main entry. In other words, this is an "open weights, self-serve deployment" model, not a "sign up and call" SaaS. For teams that care about recordings never leaving their own infrastructure (medical, legal, internal meetings), that is actually an advantage. But for teams that just want a quick API call, the setup cost is higher than a pure API model, and deployment labour should be counted in the selection.

Why now: speech is moving from "transcription" to "understanding"

The competitive focus of speech tools is quietly shifting. A few years ago, the contest was "how accurate is the transcript": one percentage point off word error rate could headline a launch. Now that transcription itself is hard to differentiate on, the real dividing line has become "what can you do directly after transcription": can it tell who spoke, translate into another language, answer "what was actually decided". Transcribe gathers those four questions into one model, landing exactly on this shift. It is not the first model to do speaker separation, nor the first to do speech translation, but putting four jobs into one checkpoint and switching them by prompt does turn "post-processing a recording" from an engineering problem into a prompt problem.

The impact on product shape is bigger than the impact on benchmarks. Previously, a meeting-notes product had to maintain three supplier relationships — transcription, speaker, translation services — each with its own pricing, latency, and failure modes; now, in theory, it can maintain one model plus one prompt template. The words "in theory" cannot be dropped: speaker coverage in only 13 languages, Q&A trained in English only, and no live-stream scope determine which parts of a stack it can replace and which it cannot. When evaluating, do not ask "can it replace my whole speech stack", but "which segments of my stack fall exactly inside its support matrix". Converge the parts that fall inside; keep the original tools for the parts that do not.

A 30-minute controlled experiment beats ten pages of specs

If you plan to evaluate Transcribe seriously, do not start from the spec sheet — start from a 30-minute real recording. Pick the recording that best represents your scenario: several speakers taking turns, technical terms, background noise, one instance of overlapping speech. Run it through your current tool first, noting word error rate, speaker misattribution count, and terminology errors; then run it through Transcribe with a fixed prompt template, noting the same three numbers. Only when both results sit in the same table does the gap mean anything. Many models look perfect on clean demo recordings and fall apart on real meeting audio, and your users will only ever give you real recordings.

Three checks are easy to miss in such an experiment. First, timestamp drift: in a long recording, do text and audio still line up in the second half? Second, accents and homophones: do names, places, and product names in your domain show systematic errors, and can a glossary fix them? Third, failure mode: does the model clearly say "this part was unclear", or does it confidently invent plausible-sounding text? For meeting notes, the third point matters most — "unclear" can be re-recorded, while "invented" pollutes the minutes directly. Write these three checks into your evaluation sheet before deciding whether to wire Transcribe into your product; that is more reliable than any leaderboard ranking.

A usage checklist for vibe developers

If you are adding a "record to text" feature to your own vibe project, Transcribe offers a concrete reference path. First, run a small-scale trial with the official demo Space or a self-hosted setup, testing three things: whether your target language is in the support matrix, the real error rate at your recordings' noise level, and whether speaker counts exceed the eight-person cap. Second, fix a prompt template: language, written form (fillers or not, how numbers are written), and glossary — write all three into the template instead of hand-writing them each time. Third, flag key information for human review: names, places, amounts, dates, and decisions should all be marked "to verify", never written straight into a database or published.

Fourth, handle the privacy boundary: recordings may contain other people's voices and personal information, so inform participants, obtain consent, and set a retention period before launch, with extra compliance checks for medical and legal scenarios. Fifth, do not use it for live scenarios: live captions, live voice assistants, and live phone transcription are outside its design, and forcing them yields both latency and truncation. Sixth, regression-test regularly with real recordings: every prompt change, quantization change, or domain change should re-run the same sample set, so that when the error rate moves you can say which step moved it.

Verdict: the speech toolchain is moving from "assembly" to "prompting"

Transcribe's significance is not any single leaderboard first place, but the new speech-tool shape it demonstrates: previously "one model per task, one pipeline", now "one model, tasks switched by prompt, a data pipeline covering the rest". That shape is especially friendly to independent developers: fewer service bills and integrations, more control through prompts and data. But its boundaries are clear too: asymmetric language support, recorded audio only, key information still needing human verification, and deployment you handle yourself.

To draw the line against this site's earlier NVIDIA Nemotron articles: the Bolt piece covered a 74-billion-parameter personal agent model that fits in 24GB of VRAM, the Super VL piece covered a 120-billion-parameter multimodal agent model, and the IOI/IMO piece covered competition reasoning and open training sets; this piece covers a 30-billion-parameter speech-transcription model and the Granary v2 data pipeline — same family, different task, different model, and their numbers must not be swapped. When choosing a speech solution, check your language and task against the support matrix first, then look at leaderboards; reverse the order and you risk picking a model that is "strong on the leaderboard, unsupported for your scenario".