Evidence at a glance
Transcription Style Becomes a Runtime Choice
NVIDIA released Nemotron 3.5 Transcribe on October 28, 2026. It is an open-weight speech-augmented language model, or SALM, built for transcription. It supports 40 languages and recordings up to an hour long, with the aim of handling different transcription requirements through one model rather than a separate tool for every output format.
The change is about who gets to choose the transcription convention. Traditional systems often fix decisions such as whether to keep fillers, how to render numbers, and whether to include speaker labels during training or product configuration. Yet meeting notes, captions, and verbatim records need different outputs. Nemotron 3.5 turns those choices into text instructions at inference time: a request can ask for verbatim or written-form text, speaker attribution, contextual vocabulary, or translation. The point is not to make one transcript suit everyone, but to let the same audio produce text suited to different uses.
Speaker Information Enters the Generation Pipeline
The promptable interface is backed by more than a single speech recognizer. The system converts 16 kHz audio into log-mel features for a trainable ASR encoder. In parallel, a frozen Sortformer diarization branch estimates who is speaking when, then fuses speaker activity into the ASR features every 80 milliseconds. It supports up to eight speakers, so the language model receives speaker cues alongside the speech representation when generating text.
The decoder uses the Nemotron 3.5 Lightning hybrid Mamba–Transformer MoE backbone. The complete checkpoint has about 34 billion parameters, of which roughly 4.3 billion are active; the “30B” in the model name refers to the language-model backbone, not the full checkpoint. After text is generated, a CTC adapter aligns it to the audio to produce word-level timestamps. An MTP module can be used for speculative decoding. In other words, speaker attribution and timestamps are part of one workflow, but they are not produced by the same mechanism: speaker cues enter generation, while timestamps are aligned afterward.
Benchmarks Show Both the Gains and the Limits
NVIDIA’s technical report gives an average English WER of 4.71% across nine public test sets, compared with 4.94% for the next open-weight model it lists, Qwen3-ASR-1.7B. On the multilingual Open ASR benchmark, the average across seven languages is 4.62%, versus 6.49% for the open-model comparison in the same material. Those figures make a case for its competitiveness among open-weight models, not for universal leadership. The report also lists commercial systems at 3.88% on the English leaderboard and 3.56% in the multilingual comparison. These results come from different benchmark tasks and should not be collapsed into one overall score.
For long-form audio and full-session, multi-speaker transcription, the report gives WER of 10.98% and cpWER of 15.80%, alongside open-model comparison figures of 13.37% and 16.83%. A more targeted result comes from ContextASR-Bench: providing an entity list reduces named-entity WER from 12.21% to 2.20%. That suggests supplying proper-name hints can work better than expecting the model to infer every term from general language knowledge. But the result establishes an improvement on that test, not a guarantee across domains, list quality, or recording conditions. These figures are reported by NVIDIA, so deployment evaluations should still use the team’s own audio and task definitions.
Open Weights Do Not Mean Lightweight Deployment
The active-parameter count may suggest a low inference barrier, but it does not determine hardware requirements by itself. The listed BF16 reference setup requires one 80 GB H100. FP8 and roughly 21 GB NVFP4 checkpoints are also available, with the latter able to run on an RTX 5090. Supported paths include vLLM, Hugging Face Transformers, SGLang-Omni, and NeMo-Speech.cpp for GGUF files. For engineering teams, the decision is not just whether the model loads, but how precision, memory, runtime support, and target throughput fit together.
Performance claims need the same attention to conditions. NVIDIA reports that NIM can process 2,238 seconds of audio per second, with a 30-second recording returning a transcript in 0.13 seconds, on an optimized setup using an RTX PRO 6000 Blackwell Server Edition, NVFP4, and DFlash2. The model card also says these service optimizations are not included in the open-source inference implementations. NIM’s speed therefore should not be assumed for every open runtime. Open weights make self-hosting possible, but an optimized high-throughput service stack is not the same thing as reproducible local inference.
Validate the Audio Before Consolidating the Toolchain
Combining ASR, diarization, and timestamping in one model pipeline may reduce the coordination required across separate systems. Contextual entity lists also provide a concrete way to adapt recognition to domain terms. But consolidation does not make errors disappear: speaker cues enter the generation process, while timestamps are aligned by a later adapter, and failures at either stage can affect downstream use. Teams with separate recognition, alignment, and human-review steps should check whether the consolidated path still meets each step’s quality requirements, rather than treating fewer tools as proof of a better system.
Mandarin far-field meetings deserve particular scrutiny; support for 40 languages is not enough to settle the question. The supplied material reports a cpCER of 34.95% on AliMeeting Mandarin far-field audio, a clear warning signal. That metric is not directly comparable with the English and multilingual WER averages, but it is reason to test against the team’s own recording conditions. A practical decision is to shortlist Nemotron 3.5 when prompt-based style changes are useful and the team can validate speaker labels, proper names, and timestamps on its own data. For Mandarin far-field work, or deployments whose throughput depends on optimizations absent from open implementations, run targeted evaluations and hardware checks before replacing the existing pipeline.