一段录音，四种活儿：英伟达 Nemotron 3.5 Transcribe 把转录、说话人、翻译、问答装进一个模型

英伟达在 2026 年 10 月 28 日发布了 Nemotron 3.5 Transcribe。这不是又一个只能“把语音转成文字”的模型，而是一个可以“按指令换活儿”的模型：同一段录音，换一句提示词，就能分别得到带说话人标签的转录、英译文、词级时间戳，或者对这段录音的提问回答。对做会议记录、课堂回放、医疗听写的人来说，这意味着原来要拼四五个工具的流水线，现在有可能收敛到一个检查点里。

这个模型的完整名字是 NVIDIA-Nemotron-3.5-Transcribe-30B-A4B，名字本身就把结构说了一半：总参数约 300 亿，混合专家架构，每 token 实际激活约 40 亿。也就是说，它是一个“看起来很大、跑起来不算大”的模型。英伟达在自家 Hugging Face 官方博客里说，它可以在一块 GPU 上运行，从 Jetson AGX Thor、DGX Spark 这样的边缘与桌面设备，一直到 Blackwell 数据中心 GPU 都能覆盖。这个“单卡可跑”的说法，是它和很多动辄要集群的语音大模型最实际的区别。

一个检查点，四种输出

先把“一个检查点”说清楚。传统语音工具链通常是分段拼装的：先用一个模型转录，再用一个模型做说话人分离，再用一个翻译模型翻成英文，最后如果要问答，还要再接一个语言模型。每一段都有自己的错误率，错误还会往下传。Transcribe 的做法是把这四件事放进同一个模型里，用自然语言提示词来切换任务。官方博客给出的示例很直白：同一段会议录音，提示词写“转录并标注每个说话人”，得到的就是带标签的转录；写“把这段音频翻译成英文”，得到的就是译文；写“这次会议做了哪些决定？”，得到的则是回答。

这种“提示词切换任务”的设计，对开发者最友好的地方不是省了几个模型，而是省了几套接口和格式对齐的麻烦。转录、说话人标签、时间戳、译文都来自同一次推理，时间戳和说话人标签不容易对不上号。当然，这也带来一个新要求：提示词本身变成了产品的一部分。同样一段录音，提示词写得含糊，输出就含糊；写清楚语言、书写格式、术语表，输出质量会明显不一样。官方博客专门建议，遇到不熟悉的术语时先给上下文再考虑微调——先用提示词里的术语表兜底，兜不住再走训练，这比一上来就微调要省得多。

语言支持是不对称的，先看表再选型

Transcribe 的语言数字很容易被读成“40 种语言全都一样好”，其实完全不是。官方博客给出的支持矩阵是分任务的：转录支持 40 种语言；翻译支持其中 31 种与英语互译；说话人归属只支持 13 种语言；音频问答只用英语训练。录音时长上限约 1 小时，单次最多标注 8 位说话人。把这张表摊开，选型结论就很清楚了：如果你要的是英文或主流语言的会议转录加说话人标签，它正对靶心；如果你要的是小语种的说话人分离，或者非英语的录音问答，它现在还不是答案，硬上只会得到“能跑但不可靠”的结果。

词级时间戳是另一个值得单独提的功能。转录文字如果没有时间戳，事后核对、定位、剪辑都会很痛苦；有了词级时间戳，课堂回放可以做到“文字跟着录音走”，会议纪要可以点一句文字就跳到对应的录音位置。官方博客提到，实时音视频平台 Agora 在课堂演示里就用了这个能力，把录制课程转成带时间戳的文字，方便学生边看边定位。这个例子也划出了它的适用边界：它是为“录播回放”设计的，不是为“实时字幕”设计的。官方博客明确写道，它面向录制的音频，不支持直播流。需要实时字幕、实时语音助手的场景，要另选模型，不要指望它后续“顺便”支持。

基准数字：厂商口径，逐项拆开读

英伟达在官方博客里给出的基准成绩相当亮眼，但每一项都要注明“这是厂商自报、尚未独立复现”。在 Hugging Face Open ASR Leaderboard 上，英文平均词错误率（WER，越低越好）为 5.33%，在开放权重模型里排第一；多语言 7 种语言平均为 4.62%，长音频为 10.98%，在官方博客的对比里同样是开放权重最低。词错误率的意思是：每 100 个词里平均错几个，5.33% 大约相当于每 20 个词错 1 个——对会议记录来说可用，但对人名、地名、专业术语这类关键信息，仍然必须人工核对。

在 Artificial Analysis 的语音转文字榜上，Transcribe 以 2.8% 的 AA-WER 与另一开放权重模型并列第一，而激活参数只有对方的约六分之一（约 40 亿对约 240 亿）。这个“六分之一”的说法是这篇发布最值得记住的效率论点：它不是靠堆参数赢的，而是靠架构与数据赢的。但同样要提醒：AA-WER 是该机构自己的加权指标，与 Hugging Face 的 WER 不是同一个数字，不能直接横向比较。两份榜单都指向“开放权重第一梯队”这个方向性结论，但具体数字只能在各自的榜单内部比较。

说话人归属的成绩同样要拆开看。在 David AI 的 21 种语言转录加说话人基准上，Transcribe 的说话人错误率（DER）为 18.26%，在 14 个参评系统里最低，略高于自家专用说话人模型 Nemotron 3 Diarization 的 18.38%——注意，这里数字越低越好，所以 18.26% 是更优的一方。在 VoiceArena 的英语全会话基准上，它的拼接词错误率（cpWER）为 32.4%，同样在 14 个系统里排第一，漏词率 8.32%，而中位数约为 31%。这些数字说明它在“谁在什么时候说了什么”这件事上确实下了功夫，但 18% 的说话人错误率也意味着，十人以上的长会、多人抢话的片段，仍然会出现张冠李戴，关键发言的归属要回听原音确认。

Granary v2：真正值钱的可能是一半的数据

和模型一起发布的还有 Granary v2。这是一套开放的多语言语音数据整理管线，用英伟达 NeMo Curator 搭建，公开的数据清单覆盖 463,062 小时、48 种语言、16 个来源语料，比上一代的 25 种语言多出近一倍。需要注意的是，官方博客明确说明：这个数字描述的是本次发布的数据集清单，不是 Transcribe 全部训练数据的混合比例与采样权重。把“清单规模”读成“训练规模”，是这类发布最常见的误读。

Granary v2 的价值不在于小时数本身，而在于它产出的数据形态。同一段录音，管线会生成三种转录形态：保留口头禅的逐字版、带规范化数字与货币的口语版、去掉口头禅的干净版。开发者可以直接用提示词向模型索取其中某一种形态，而不用自己再写清洗规则。除此之外，管线还会产出短音频说明、借词修复、语音问答对、上下文术语和带自动质量分的翻译。这些“训练目标”就是 Transcribe 能用提示词切换任务的底气：模型在训练时就见过这些任务形态，上线后才换得动。

对想做领域适配的团队，官方博客给出的路径是先提示词、后微调，并附了一个医疗案例：在印度医生与医学生的公开基准上，用生成式医疗文本与公开药品目录构造适配数据后，微调使未见过的说话人的词错误率相对最优提示词下降了 45.8%。这个数字是“相对下降”，不是“绝对错误率降到某个值”，而且基准本身没有专门的训练集划分，读的时候要留一分谨慎。但方向是清楚的：术语、口音、书写格式这类领域问题，先用提示词里的术语表和示例解决，解决不了再走 NeMo Speech 微调，成本和风险都更可控。

单卡运行与部署：先算吞吐，再谈替换

部署方面，官方博客给出的吞吐数字很抓人：在一块 RTX PRO 6000 Blackwell Server Edition GPU 上，用即将推出的 NVFP4 量化版本，100 小时的音频不到 3 分钟就能处理完。但脚注同样重要：这个测试用的是 30 秒短片段、高并发条件。真实场景里如果是一段 1 小时的连续长会，吞吐表现会不同，不能直接拿“100 小时 / 3 分钟”去承诺上线指标。部署前应该用自己的录音——同样的时长、口音、噪音水平——实测一遍，再写进对内对外的承诺里。

目前可用的部署方式包括 vLLM 服务与 NeMo-Speech.cpp 本地部署，量化版本也已提供；托管端点则来自 Baseten、DeepInfra 等第三方，官方博客没有把自家免费试用 API 作为主推入口。换句话说，这是一个“权重开放、部署自理”的模型，不是“注册即用的 SaaS”。对在乎录音不出内网的团队（医疗、法务、内部会议），这一点反而是优点：录音可以留在自己的基础设施里处理。但对只想快速调用 API 的团队，它的上手成本会比纯 API 模型高一截，选型时要把部署人力算进去。

给 vibe 开发者的用法清单

如果你正在给自己的 vibe 项目加“录音转文字”功能，Transcribe 提供了一个很具体的参考实现路径。第一步，先用官方演示空间或自托管小规模试跑，测三种东西：你的目标语言在不在支持矩阵里、你的录音噪音水平下的实际错误率、说话人数量有没有超过 8 人的上限。第二步，定提示词模板：语言、书写格式（要不要口头禅、数字写成什么样）、术语表，这三项写进模板，不要每次手写。第三步，给关键信息加人工复核：人名、地名、金额、日期、决定项，全部标成“需核对”，不要直接进数据库或对外发布。

第四步，处理好隐私边界：录音里可能包含他人的声音与个人信息，上线前要明确告知、取得同意、设定保留期限，医疗与法务场景还要额外确认合规要求。第五步，别用它做实时场景：直播字幕、实时语音助手、电话实时转写都不在它的设计范围内，硬套只会得到延迟与截断两头不讨好的结果。第六步，定期用真实录音回归测试：换一次提示词、换一次量化版本、换一次领域，都要重跑同一批样本，错误率变了要能说出是哪一步变了。

为什么是现在：语音正在从“转录”走向“理解”

语音工具的竞争焦点正在悄悄换位。早几年，比的是“转得准不准”：词错误率降一个百分点，就能当 headline 发。现在，转录本身已经很难再拉开差距，真正的分水岭变成了“转完之后能直接干什么”：能不能分清谁说的、能不能翻成另一种语言、能不能回答“刚才到底决定了什么”。Transcribe 把这四个问题收进一个模型，恰好踩在这个换位点上。它不是第一个做说话人分离的模型，也不是第一个做语音翻译的模型，但把四件事做进同一个检查点、再用提示词切换，确实让“录音的后续处理”从工程问题变成了一句提示词的问题。

这个变化对产品形态的影响比对基准的影响更大。以前，一个会议记录产品要维护转录服务、说话人服务、翻译服务三套供应商关系，每套都有自己的计价、延迟与故障模式；现在，理论上可以只维护一个模型加一套提示词模板。当然，“理论上”三个字不能去掉：说话人只覆盖 13 种语言、问答只训了英语、直播不在范围内，这些边界决定了它能替代几套服务、不能替代几套。评估时不要问“它能不能替代我的整个语音栈”，而要问“我的语音栈里哪几段正好落在它的支持矩阵里”。落在里面的部分可以收敛，没落进去的部分还是要留着原来的工具。

一个 30 分钟的对照实验，胜过十页参数表

如果你打算认真评估 Transcribe，不要从参数表开始，从一段 30 分钟的真实录音开始。选一段最能代表你场景的录音：有几个人轮流发言、有专业术语、有背景噪音、有一次抢话。先用你现在的工具跑一遍，记下词错误率、说话人张冠李戴的次数、术语错几个；再用 Transcribe 跑一遍，提示词模板固定，同样记下这三个数字。两次结果放在同一张表里，差距才有意义。很多模型在干净的演示录音上表现完美，在真实会议录音上立刻现形，而你的用户永远只会给你真实录音。

对照实验里还有三个容易漏掉的检查点。第一，检查时间戳的漂移：长录音播到后半段，文字和声音还对得上吗？第二，检查重音与同音词：人名、地名、产品名在你的领域里有没有系统性的错法，能不能用术语表纠过来？第三，检查失败模式：模型是会明确说“这段没听清”，还是会自信地编一段听起来合理的话？对会议记录来说，第三点最重要——“没听清”可以补录，“编造”会直接污染纪要。把这三个检查点写进评估表，再决定要不要把 Transcribe 接进你的产品，比任何榜单排名都更可靠。

判断：语音工具链正在从“拼装”走向“提示”

Transcribe 的意义不在于某一项榜单第一，而在于它示范了一种新的语音工具形态：过去是“一个任务一个模型、一段流水线”，现在是“一个模型、提示词切换任务、数据管线负责兜底”。这种形态对独立开发者尤其友好：少了几套服务的账单与对接，多了提示词与数据这两件自己能掌控的东西。但它也有清晰的边界：语言支持不对称、只做录播不做直播、关键信息仍需人工核对、部署需要自己动手。

与本站此前发过的英伟达 Nemotron 系列文章划界：Bolt 篇讲的是 74B 参数、能装进 24GB 显存的个人 agent 模型，Super VL 篇讲的是 120B 多模态 agent 模型，IOI/IMO 篇讲的是竞赛推理与训练集开源；本篇讲的是 30B 语音转录专用模型与 Granary v2 数据管线，是同一家族、不同任务、不同模型，不要把它们的数字互相套用。选语音方案时，先对着支持矩阵查自己的语言与任务，再看榜单；顺序反了，很容易选到一个“榜单很强、你的场景不支持”的模型。