Nemotron 3.5 Transcribe 与 Nemotron 3.5 Transcribe 30B：两个名字，同一个检查点，四个文件

如果某个产品目录、对比网站或你自己的采购表把 Nemotron 3.5 Transcribe 和 Nemotron 3.5 Transcribe 30B 列为两条条目，那它其实是把同一个模型列了两遍。已发布的代码库是 NVIDIA-Nemotron-3.5-Transcribe-30B-A4B，NVIDIA 的规格卡给出的总参数为 34B、激活参数约 4.3B，而所有标题里那个不带后缀的名称，正是同一个产物去掉了尺寸标识。并不存在另一个独立的 30B 模型可供对比，因此这与其说是一场正面对比，不如说是一个命名问题，而部署决策就藏在其中。

不过，这个决定是真实存在的，也正是这两个名字总是并排出现的原因。一个名字是你搜索时用的，也是模型目录或 API 列表可能显示的名字。另一个是你实际下载的名字，下载时可选四种精度之一、四种内存占用之一，而这些文件之间的选择，才是这个模型真正要求你做的唯一比较。接下来是核对：30B 到底算什么，为什么卡片上写 34B，以及哪个文件适合你手上的 GPU，而不是发布页面所假定的那块 GPU。

自相矛盾的名字

目前流传着两个数字，而且两者都是官方数据。仓库名称以 30B-A4B 结尾，遵循 NVIDIA 为其专家混合系列采用的命名惯例：先写总参数，再写激活参数。同一页面上的模型卡标注为总参数 34B、激活参数约 4.3B，并明确说明其中包含音频编码器。研究页面在标题中重复了 30B-A4B 这一名称，并在正文中重复了 4.3B 的激活参数这一数字。

模型卡还列出了各个组件，算术也正是从这里开始变得要紧。语言主干是 Nemotron 3.5 Lightning 30B-A3B，一个 Mamba-2 与 Transformer 的混合 MoE，激活参数为 3.5B。联合音频编码器——一个 Transformer ASR 编码器加一个说话人编码器——约为 800M。把这些加起来，得到大约 30.8B，而不是 34B。要么是 34B 把 NVIDIA 没有逐项列出的某些东西也算了进去，要么仓库名里的 30B 只是一个四舍五入的标签，而主干的实际情况比名字所示的更大。NVIDIA 尚未公布这一对账说明，目前也还不存在针对完整 checkpoint 的第三方参数审计。

这对买家而言，其含义比听起来要窄。系统是 31B 还是 34B，并不会改变它能装在哪张卡上，因为文件大小主要由精度决定，而不是由最后那三十亿参数决定。它的确意味着，任何标注“30B”的规格表和任何标注“34B”的规格表，描述的都是同一个下载文件；而基于这一差异做出的采购比较，只是在比较一种四舍五入的约定。

30B 后缀实际统计的到底是什么

后缀算的是一个语言模型，而不是一个转写器。Nemotron 3.5 Transcribe 是一个语音增强的 LLM：音频经过一个 Transformer 编码器，一个冻结的 Nemotron 3 Diarization 模型通过 NVIDIA 所谓的并行专家编码器贡献说话人表示，混合 MoE 解码器则负责写出转写文本。30B 这个标签属于解码器及其嵌入栈。语音路径——编码器、说话人分离器、CTC 时间戳头——是叠加在其上的，并不是名字所标示的内容。

这就是为什么该模型在有些方面的表现像 LLM，而传统 ASR 系统并不会如此。它能接受提示。它能回答关于音频的问题。它能在同一遍处理中完成与英语之间的 31 个语言对的互译。它拥有 65,536 个 token 的上下文，因此一小时的语音无需分块即可容纳。这一切都不是因为 30B 解码器规模大；而是因为该解码器本身就是一个通用语言模型，并且语音被投影到了它的输入空间中。

这也解释了大家一直在寻找的那种缺失。不存在仅有 30B 的兄弟模型，没有更小的稠密 Transcribe，也没有更大的版本。该仓库提供的是单一模型的多种精度版本，而不是一个模型家族。市面上流通的其他尺寸版本，只有社区生成的量化版本，以及一个真正更小的流式识别器——Nemotron Speech Streaming EN 0.6B——那是一个不同的模型，仅覆盖英语且不支持说话人分离（diarisation），并不是这个模型的缩小版。

名称背后的四个文件，以及每个文件占用的内存开销

这就是这两个名称实际所指的对比。NVIDIA 发布了三种精度，社区又增加了第四种交付格式；下面的内存数据来自已发布的检查点和社区仓库，而不是来自某个厂商的单一表格。

• BF16 — 参考检查点，磁盘上约 67–68GB，在单块 H100 80GB 上提供服务。这是生成已发布基准测试数值所用的版本，也是需要复现这些数值时应使用的版本。

• FP8 — 约35GB，这将最低要求降至48GB显卡，例如L40S。按照NVIDIA自己的说法，相对BF16的精度损失很小，但这只是NVIDIA的说法；尚无独立的FP8评估结果公开发表。

• NVFP4 — 约 21GB，小到足以适配 32GB 的 RTX 5090 或 RTX PRO 6000。这一精度正是 NVIDIA 标志性吞吐量声明背后的支撑：在单块 RTX PRO 6000 上搭配 DFlash2 草稿模型时，每秒可处理 2,238 秒音频。

• GGUF —— 包含四个社区解码器，大小介于 19.7GB 到 35GB 之间，另需一个必备的 1.67GB F16 编码器文件。其中 19.7GB 的 IQ4_NL 版本面向 24GB 显卡、CPU 推理、Metal 和 Vulkan；19.7GB 的 NVFP4 版本面向 Blackwell；Q5 约为 29GB，Q8 约为 35GB。可选的 1.15GB DFlash2 起草器可在 CUDA 路径上增加投机解码。

• MLX — 社区提供的 4 位至 8 位移植版本，面向 Apple silicon，大小约在 19GB 至 35GB 之间，其中一位作者报告在 4 位构建上约为每秒 154 个 token。适合在 Mac 上进行评估，不适用于生产服务路径。

是什么在运行它们，以及人们在运行时犯的一个错误

GGUF 文件是个陷阱。以 .gguf 结尾的文件并不意味着它就是 llama.cpp、Ollama 或 LM Studio，而且这三者都无法运行此模型：它需要一个接入了音频编码器的 speech-LLM 运行时。发布时真正可用的路径，比格式列表所暗示的范围更窄。

• vLLM 0.32.0 —— 主路径，也是唯一能暴露完整输出接口的路径，包括通过 V1 runner 和 timestamp middleware 提供的词级时间戳。说话人归属输出与翻译功能都在这里。

• SGLang-Omni 0.2.0 基于 SGLang 0.5.22 —— 通过 OpenAI 兼容的音频端点进行整文件转录，不支持词级时间戳、说话人归属、翻译或投机解码。

• NeMo Speech —— 微调工具包，NVIDIA 称在单块 GPU 上每项任务需 0.5 至 2.3 GPU 小时。已发布的 LoRA 配方可在单卡上运行。

• NeMo-Speech.cpp 和 speech.cpp —— GGUF 构建器所针对的 C++ 路径，也是唯一能加载这些量化文件的路径。上面这两个 19.7GB 和 35GB 文件都是为它分发的，而各仓库的 README 则是说明什么适合放在哪里的可靠来源。

• Transformers —— 从源码安装后在进程内使用，足以满足评估需求，但不适用于高吞吐场景。

错误在于下载最小的量化版本、让 llama.cpp 指向它，然后断定这个模型坏了。它并没有坏；它是一个语音 LLM，带有一个文本运行时根本无从理解的编码器。如果运行时没有在支持的架构中列出 Nemotron 3.5 Transcribe，那么无论文件多小，它都无法加载。

每个文件适用于哪里，用通俗的话说明

应从硬件出发倒推，而不是从模型卡出发正推。模型卡中声明的基线——单张 H100 80GB、BF16——是保真度最高的路径，而不是最低的那条路径。

• 24GB 显卡，RTX 4090 或 L4 级别——搭配其 1.67GB 编码器的 19.7GB IQ4_NL GGUF。为 KV 缓存和音频缓冲区留出余量；24GB 很紧张，但已有文档说明可正常工作。

• 32GB 显卡、RTX 5090 或 RTX PRO 6000 —— 21GB 的 NVFP4 检查点，这正是 NVIDIA 吞吐量声明所描述的配置；如果需要投机解码，还可搭配 DFlash2 草稿模型。

• 48GB 显卡，L40S 或 A6000——35GB FP8 检查点，在保真度与成本之间最不别扭的折中。

• 80GB 加速器，H100 或 A100 —— BF16，这是参考配置，也是唯一无需附加精度说明即可复现已发布 WER 表的配置。

• 完全没有 GPU——这些文件中都没有。编码器在 C++ 路径中运行于 CPU 上，但在没有加速的情况下，用 30B-A3B 解码器处理一小时音频，就是以小时计的批处理作业，而不是服务。

有一个约束在每一种精度下都成立：输入是16kHz单声道PCM，且每次请求的音频上限为一小时。降采样和声道选择发生在模型看到任何内容之前，而立体声的会议室录音会被混成单声道，除非你自己拆分声道。这是一个预处理决策，而非检查点决策，并且一旦做错，它在转写质量上的代价比BF16到FP8这一步更大。

当某个列表同时显示两个名称时要运行的检查

既然重名情况确实存在，并且会在目录和对比页面中反复出现，那么一个简短的核验流程就比再写一段解释更有价值。

• 仓库 ID —— 唯一的官方制品是 NVIDIA-Nemotron-3.5-Transcribe-30B-A4B。若某一行名为 Nemotron 3.5 Transcribe 30B 但仓库 ID 不同，则该行要么是量化版本，要么完全是另一个模型。

• 许可证字符串——官方发布版为 OpenMDW-1.1，允许商业使用。若某个条目写的是仅限研究或非商业用途，那它描述的是另一回事。

• 上下文与音频窗口——65,536 个 token，时长一小时。若某项列表宣称更长的窗口，那要么是错的，要么是在描述另一个检查点。

• 参数标注——名称中为 30B-A4B，模型卡中为 34B，二者均为 4.3B 激活。某条列表将总量写成 4B，这是把激活参数数量误当成了总参数数量，而这也是网络上对该模型最常见的转写。

• 文件列表 — 来自 NVIDIA 的 BF16、FP8 和 NVFP4，以及一个 DFlash2 草稿模型。如果某个页面将“Nemotron 3.5 Transcribe 30B”作为单个可下载文件提供，且没有列出各种精度版本，那么它就是一个打着厂商名义的社区量化模型。

真正独立的路由问题

一旦选定文件且运行时正常工作，部署问题就告一段落，而一个更早的问题又回来了：文本会怎样。转录稿是摘要、实体抽取、脱敏、搜索索引和问答的原材料，而这些调用是普通的文本模型流量，面临普通的文本模型问题——速率限制、上游中断，以及一个廉价的分类模型就足以处理九成的数据量。

OrcaRouter 不提供 Nemotron 3.5 Transcribe 服务，其目录中也没有以这两个名称中的任何一个命名的条目；如果你在任何地方看到这个模型出现两行记录，上面提到的仓库检查是确认此事最快的方法。该平台真正提供的是转录文本生成之后的那一层能力：一个兼容 OpenAI 的密钥即可访问 200 多个文本与视觉模型，按提供商标价计费、零加价，跨提供商自动故障转移，以及一套路由 DSL，可将多个模型组合成一次调用，从而让低成本的提取环节和高成本的判断环节共用同一个端点。GPU 负责转录；路由则决定这份转录文本价值几何。

后缀是文件大小标签，而不是第二个模型。

要把这两个名字理清楚，最干净利落的方式是这样：Nemotron 3.5 Transcribe 是产品，Nemotron 3.5 Transcribe 30B 是仓库，30B 这个数字数的是解码器，而那张卡数的是一个系统。30.8B 和 34B 之间的落差是 NVIDIA 应当厘清的一处未决细节，但它不会改变买家的任何决策，因为决策看的是显存以 GB 计的容量和支持的运行时，而不是参数量上的第三位数。

选择你的显卡能够承载的精度，确认运行时列出的是该架构，并把任何将这两个名称呈现为两个独立模型的条目视为目录错误，而不是一种选择。这个版本中真正的分岔——足以证明值得进行一次真正正面对比的那一个——是一边的 0.6B 流式识别器和另一边的这个 30B 离线转写器。那项比较关乎延迟和覆盖范围，值得做。把一个模型与它自己的文件名相比则不是。