英伟达开放40语种转写模型权重

NVIDIA 的 Nemotron 3.5 Transcribe 想把语音转文字做成一个可按指令调用的专用模型：同一份录音，可以输出逐字稿、书面稿、带说话人和时间戳的文本，也能翻译。它覆盖 40 种语言，单次支持最长 1 小时音频。

对开发者，吸引力在于减少语音识别、说话人区分和时间对齐之间的拼接工作。但开源权重中的领先成绩有边界：商业 API 仍然更准，中文远场会议表现偏弱，最快的部署路径也尚未开源。

一个模型接管转写流程，靠什么实现

Nemotron 3.5 Transcribe 属于语音增强语言模型（SALM）：音频编码器先把声音转换成模型能处理的特征，再交给语言模型根据文本指令生成结果。NVIDIA 将它定位为转写专家，不是通用助手。

这个设计解决的是一个真实问题：同一段话没有唯一正确的文字版本。口头的数字要不要转成阿拉伯数字，语气词是否保留，专业术语如何拼写，都取决于读者和用途。把这些要求放进指令，输出形式就不必完全依赖后处理。

它内部仍然有明确分工。可训练的 0.6B Transformer ASR 编码器，与冻结的 Nemotron 3 Diarization 并行工作。后者最多跟踪 8 位说话人，每 80 ms 将说话人活动信息加入语音特征，让解码器同时获得内容和发言者线索。

骨干是 Nemotron 3.5 Lightning 30B-A3B，采用 Mamba-Transformer 混合专家架构（MoE）。52 层中，23 层是 Mamba-2，23 层是 MoE，只有 6 层注意力。每个 MoE 层从 128 个专家中选择 6 个，另加 1 个共享专家。较少的注意力层有助于压低长音频的 KV cache 开销，上下文长度为 65,536 token。

额外的 MTP 模块负责为推测解码预生成 token；50M 参数的 CTC adapter 则将完成的转写文本对齐到音频，生成词级时间戳。因此，「一个模型」指的是统一调用入口，内部并非没有专门组件。

开放权重第一，离实际可用还有多远

原文所有评测数字均由 NVIDIA 技术报告自报，不能当成独立复测结论。

英语 Open ASR 的 9 个公开测试集上，它的平均词错误率（WER）为 4.71%，优于 Qwen3-ASR-1.7B 的 4.94%。不过仍有 7 个商业系统领先，第一名 OtterAI speech-v3.1 为 3.88%。

多语言 Open ASR 的 7 种语言测试中，它为 4.62%，Qwen3-ASR-1.7B 为 6.49%，商业系统 ElevenLabs Scribe v2 为 3.56%。覆盖 40 种语言，不代表这 40 种语言都经过同等充分的公开验证。

长音频平均 WER 为 10.98%，优于 Parakeet-TDT-0.6B-v3 的 13.37%。完整多说话人会话的平均 cpWER 为 15.80%，优于 DiCoW v3.3 配合 DiariZen 的 16.83%。cpWER 同时涉及转写和说话人归属，不能直接拿来与普通 WER 横比。NVIDIA 据此称，它是首个在该项评测中超过级联系统的 SALM。

更有实际参考价值的是术语提示。在 ContextASR-Bench 中，提供实体列表后，命名实体 WER 从 12.21% 降至 2.20%。对于产品名、项目名密集的录音，这比泛泛要求模型「认真识别」更值得尝试。

但 AliMeeting 中文远场会议的 cpCER 达到 34.95%。该指标按字符衡量，并涉及说话人归属，不能与前面的英文 WER 直接比较；它仍足以提醒国内团队：中文会议和中英混说需要单独验证。

训练规模也不是普通团队容易复制的。监督微调使用 256 张 H100，运行 28,500 步；之后进行 400 次 GSPO 更新，以 1 减 WER 作为奖励。独立音频约 1.72M 小时，计入重复训练约 6.5M 小时。

显存能装下，不等于能复现最高速度

标题写 30B，模型名写 30B-A4B，实际 checkpoint 约有 34B 参数，每次激活约 4.3B。额外权重包括 1.3B 的 MTP 模块和音频组件。激活参数少，有助于减少计算量，却不能据此按 4.3B 估算权重显存。

BF16 可运行在单张 H100 80 GB 上；FP8 checkpoint 约 35 GB，NVFP4 约 21 GB，后者可以运行在 RTX 5090 上。另有面向 NeMo-Speech.cpp 的 GGUF 文件，OpenMDW-1.1 许可证允许商用。

部署路径包括带 NeMo Speech 插件的 vLLM 0.32.0、Transformers，以及 SGLang-Omni 0.2.0。vLLM 提供 OpenAI-compatible API，已有兼容调用层的服务可以复用部分接入方式，具体请求字段原文没有展开。

最高速度来自 Nemotron Transcribe NIM：NVFP4 配合可选的 DFlash2 draft model，在单张 RTX PRO 6000 Blackwell Server Edition 上，每秒处理 2,238 秒音频，30 秒片段返回耗时 0.13 秒。但这些服务优化尚未开源，NVIDIA 预计发布当日的 vLLM 路径约慢 2 倍。单张 H100、BF16 加 MTP2 的约 410 RTFx 也属于估计值，即处理速度约为音频时长的 410 倍。

这些都是离线处理数字。模型目前不支持流式转写，不能据此推导实时字幕体验。NVIDIA 还测试了 17 项微调任务，单项使用一张 GB300 约需 0.5 到 2.3 GPU-hours；原文没有充分交代任务规模，不能直接当作团队预算。

我的判断

我认可它把输出格式、说话人和时间戳放到同一入口的方向。对需要维护多个语音组件的团队，减少接口适配和中间结果传递，有明确的工程价值。

不过，原文没有给出维护成本、端到端故障率或同硬件成本对照，「接起来更省事」目前仍是基于架构的判断。相比轻量 ASR 加独立对齐工具，它的权重和部署门槛更高；相比商业 API，它提供了本地部署选择，却没有取得准确率上的全面领先。

横向比较还要守住测试口径。报告引用的是 2026 年 10 月榜单，测试集已经变化，不能把竞争模型早期 model card 的分数混进同一排名。尤其对国内程序员，英文榜单第一的意义，小于自己的中文会议录音能否少改几遍。

能拿来做什么

• 做录音整理工具时，可以先用统一接口验证逐字稿、书面稿、说话人和词级时间戳输出，再评估是否替换现有组件。
• 用 Node 服务封装转写时，可以围绕最长 1 小时的离线任务设计上传、任务状态和结果获取流程，先测试实际等待时间。
• 处理技术分享或产品讨论录音时，可以提供项目名、库名和业务实体列表，并单独统计这些词的识别错误。
• 评估中文会议场景时，应保留远场、多人和中英混说样本，与现用方案比较；同时记录所用精度、运行时和硬件，避免拿 NIM 峰值替代自己的部署结果。