NVIDIA Nemotron 3.5 Transcribe: Evaluate Recorded Meetings Task by Task

NVIDIA’s release announcement describes transcription in 40 languages, translation between English and 31 languages, and speaker attribution in 13. It says the model handles recordings up to one hour and labels up to eight speakers. Natural-language instructions select the task and guide transcript style or vocabulary.

For a small team building meeting replay or recorded-interview tools, the appeal is a common model behind several outputs: a transcript, speaker labels, translated text, and answers about the recording. Our editorial assessment is that this could simplify experimentation. It does not establish that every output is equally dependable or that combining tasks improves the finished application.

This article analyzes NVIDIA’s published sources. We have not run the model or tested its outputs. Vendor measurements remain vendor evidence; the pilot below is a proposed evaluation.

The model card provides a language support matrix with separate columns for transcription, translation, multispeaker transcription, and code-switching. A language appearing in the transcription list does not establish support for all the other tasks. The card also says audio understanding, reasoning, and spoken instruction following were evaluated only in English and may be unreliable in other languages.

Build a coverage checklist around the actual recording. A multilingual team might need original-language transcription, English translation, and speaker labels from the same meeting. Check each combination independently before making it part of the product’s expected behavior.

Speaker labels also distinguish voices within a recording; NVIDIA explicitly says they do not establish real-world identity. Our recommendation is to keep labels such as “Speaker 1” until a person verifies the mapping. A correctly recognized sentence attributed to the wrong colleague can still produce an incorrect meeting record.

Both the announcement and model card identify Transcribe as an offline model for recorded audio. The card explicitly warns that internal audio chunking does not make it a real-time streaming transcription service. A recording uploaded after a meeting fits that documented scope. Continuous live captions require a separate evaluation and should not be assumed from this release.

The model card lists 34 billion total parameters, including the audio encoder, with approximately 4.3 billion active parameters. Its BF16 quick start uses one H100 with 80 GB of memory. The active-parameter figure therefore should not be treated as the size of the complete model that must be deployed.

NVIDIA’s announcement reports processing 100 hours of audio in under three minutes, but specifies 30-second clips, high concurrency, one RTX PRO 6000 Blackwell Server Edition GPU, and an NVFP4 version described there as forthcoming. That benchmark does not establish turnaround time for an hour-long meeting on your hardware. Measure the complete upload-to-result path in the intended configuration.

The Granary v2 dataset card describes public manifests covering 463,062 hours across 48 languages and 16 source entries. These are dataset figures, not Transcribe’s task coverage or its full training mixture. The repository distributes labels and instruction pairs; source audio must be obtained separately.

Its transcript variants distinguish spoken wording, written number formatting, and removal of disfluencies. That distinction matters when a product needs either a faithful transcript or cleaner reading text. Choose the desired convention before judging errors, or formatting differences can obscure recognition problems.

Target availability also varies by record. The dataset card warns that a translation key can exist while its translation text is empty because quality filtering rejected the candidate. Our recommendation is to inspect usable targets before assembling adaptation data. Granary offers material for building a training workflow; downloading its manifests alone does not provide a complete audio training set.

Begin with a small set of representative recordings containing your usual microphones, accents, terminology, and overlapping speech. Prepare human-checked transcript excerpts and speaker assignments. Keep some recordings out of prompt development so the final check includes unfamiliar examples.

First evaluate transcription: omitted words, names, numbers, and domain terms. Then evaluate whether the right speaker receives each statement. Finally, ask concrete audio questions and verify answers against the recording, including whether the model invents a decision that nobody made. A fluent answer should not compensate for an incorrect transcript or attribution.

Compare a plain prompt with one specifying language, output style, and a short vocabulary list. Record the model variant, instructions, recording duration, processing time, and manual corrections. Our guide to designing a reliable AI workflow helps turn those observations into explicit acceptance and recovery steps.

Consider a pilot when your application processes recordings after capture and its required language-task combinations appear in the documentation. Keep the initial output reviewable: text linked to the relevant audio, with uncertain speaker mappings left unresolved.

Prompting should precede fine-tuning. If repeated errors remain, classify them before investing in adaptation: vocabulary mistakes, missed overlapping speech, formatting differences, and unsupported answers need different remedies. Granary’s breadth does not establish that any particular remedy will work for your recordings.

Expand only after the pilot meets predefined accuracy and turnaround criteria. If meeting outputs later create tasks or update records, apply the safeguards in our guide to preventing duplicate AI workflow actions. A reviewed transcript and a reliable downstream action are separate acceptance decisions.