NVIDIA 悄悄发布了 Nemotron 3.5 ASR，一个支持 40 种语言、专为流式推理优化的 600M 参数语音识别模型。

背景：为什么要换掉 Whisper

最近在做一个面向中日韩三语会议场景的实时字幕工具。最开始用的是 Whisper large-v3，离线精度确实不错，但只要一涉及流式推理，问题就暴露出来了。Whisper 的本质是一个编码器（encoder-only）模型，它需要拿到完整音频才能输出，所有"实时"方案都是在外面套了个滑动窗口的变通，结果就是：段落边界断词、上下文割裂、延迟飘忽不定。

更麻烦的是计算浪费。传统缓冲式流式推理每个新 chunk 进来都要把前一段音频重新算一遍——重叠区域的计算量随窗口大小线性增长。在有并发压力的生产环境里，这意味着 GPU 大量资源烧在了重复劳动上。

在测试场景里，单张 A10G（24GB 显存）跑 Whisper large-v3 缓冲流式，80ms chunk 下最多撑住约 14 个并发流，延迟开始显著抖动。这对于会议场景勉强够用，但一旦想扩容就非常贵。

架构先说清楚：缓存感知到底"感知"了什么

在聊体验之前，先把核心架构讲清楚，因为这是理解它所有优势和局限的前提。

Nemotron 3.5 ASR 的编码器基于 FastConformer，一种融合了卷积和自注意力的架构：卷积捕捉局部声学模式，注意力建模长程依赖，两者搭配在一起，兼顾了效率和表达能力。但真正让它在流式场景里与众不同的，是 Cache-Aware（缓存感知） 机制。

Cache-Aware 的核心逻辑：不是每次新音频块进来都从头算，而是把上一次编码器在每一层（自注意力层 + 卷积层）的隐状态缓存起来，下一个 chunk 到来时直接在缓存上续算。

结果就是：每个 chunk 的处理是严格非重叠的，没有"重计算"这回事。上下文不丢，计算不浪费。

解码器用的是 RNNT（Recurrent Neural Network Transducer），相比 CTC 在连续语音、非标准口音上表现更稳，代价是稍慢。整个模型 600M 参数，encoder 24 层，全参数规模恰好在"产线可用"和"精度不拉胯"之间的甜点区。

语言控制方面，模型用了一个巧妙的 prompt 注入设计：语言 ID 被扩展成 128 维的 one-hot 向量，沿时间轴广播后和声学特征（1024 维）做拼接，再经过一个投影层送进 RNNT 解码器。这意味着语言条件是逐帧融合进去的，而不是全局 token——理论上在语言切换场景里更有优势。

环境搭建的第一道坎

模型支持两条路：NVIDIA NeMo 框架或 HuggingFace Transformers（需要 v5.13.0+）。

NeMo 那条路：依赖链挺重，光装环境就花了半天，Cython、PyTorch、NeMo 本体，加上各种 CUDA 兼容性问题，踩了几个坑。但装好之后，流式推理的接口设计很干净——cache 状态管理 NeMo 帮你全包了，不用自己维护。

import nemo.collections.asr as nemo_asr

asr_model = nemo_asr.models.ASRModel.from_pretrained(

"nvidia/nemotron-3.5-asr-streaming-0.6b")

# 流式推理脚本

# python speech_to_text_cache_aware_streaming_infer.py \

# model_path=... \

# target_lang=ja-JP \

# att_context_size="[56,6]" \ # 560ms chunk

# strip_lang_tags=true

Transformers 那条路相对友好一些，但 AutoModelForRNNT 是个比较新的类，文档还在追赶进度。流式推理需要自己写一个 generator 来逐步喂 mel frame，代码量不小，但可控性更高

chunk size 的选择：不是越小越好

这是花时间最多的地方。模型支持五档 chunk size：80ms、160ms、320ms、560ms、1120ms，通过 att_context_size 中右侧上下文帧数来控制。

直觉上以为 80ms 延迟最低当然最好，实测不是这样。以日语为例：

WER/CER 从 80ms 到 1120ms 有明显的梯度改善。对于会议字幕这种场景，320ms 感知延迟在可接受范围内（人类对 300ms 以内的延迟基本感知不明显），精度比 80ms 好一截，GPU 并发能力也比最高延迟档低一个档位。

560ms 以上在对话场景里开始有明显的"字幕滞后感"，虽然数字看起来不大，但人对语音字幕的延迟感知比想象中更灵敏——主要因为人会提前预判说话节奏。

并发压力测试：这才是真正的惊喜

官方数据说，单张 H100 在 80ms chunk 下，Nemotron 能撑 240 个并发流，而 Parakeet RNNT 1.1B 只有 14 个。这个 17× 的差距让人一开始持怀疑态度——毕竟参数量少一半（0.6B vs 1.1B）也是个因素。

没有 H100，用的是 A10G。在 320ms chunk 下，Nemotron 3.5 ASR 能稳定跑到 120 个并发流，延迟开始爬升的拐点在 90 个左右。对比之前 Whisper large-v3 的 14 个上限，这个提升是实实在在的。

原因在架构里说得很清楚：Cache-Aware 设计消灭了重叠计算，每个 chunk 的处理是严格线性的——计算量不随并发数增加而指数增长，GPU 利用率曲线非常漂亮。

40 种语言：分级制度比你想的更诚实

很多宣传材料把"40 种语言"作为亮点反复说，但实际上模型用了一个三级分层，这个分层设计比很多竞品更诚实。

主要测试的是日语（Tier A）和普通话（Tier B）。日语的体感接近官方数据，在 320ms chunk 下 CER 约 12%，考虑到这是流式推理且带有标点输出，已经相当好了——传统流式 ASR 通常要你自己另外接一个标点恢复模型。

普通话（zh-CN）属于 Tier B，官方 FLEURS 数据在 320ms 下 CER 约 20%。用了几段带方言口音的真实会议录音测试，确实能感受到比日语更容易出错，特别是专业词汇和缩写。不过有一点令人意外：自动语言检测（target_lang=auto） 在中日混合场景里表现出乎意料地稳——同一段音频里日文句子和中文句子能被分别正确打标，不需要预先分段。

"最让人意外的功能是自动语言标签。开启 strip_lang_tags=false 之后，每段转录结果后面会自动带上 <ja-JP> 或 <zh-CN>，这对多语言会议的下游处理来说省了一个分类模块。"

和同类方案的真实对比

参数对比表满大街都是，只说几个实际选型时会影响决策的点。

如果你的场景是隐私敏感（医疗、法律、金融）+ 高并发流 + 多语言，Nemotron 3.5 ASR 目前是我知道的最有竞争力的开源选项。如果你只需要简单的英文单语种低并发转录，Whisper 依然够用，且社区生态更成熟。

说几个被低估的细节

标点和大写是内置的，不是选配

这听起来不起眼，但实际上省了一个完整的后处理模块。很多 ASR 系统输出的是裸文本，你还得接一个单独的标点恢复（Punctuation Restoration）模型，这增加了延迟、增加了部署复杂度。Nemotron 3.5 ASR 的输出直接带标点和正确大写，对 RAG、会议摘要这类下游任务非常友好。

无需重新训练就能调整延迟-精度权衡

前面提到的五档 chunk size 是推理时切换的，不需要重新 fine-tune 模型。这意味着同一个模型权重文件，你可以在延迟敏感的语音交互场景用 160ms，在会议字幕场景用 320ms，在批量录音处理时用 1120ms——一个权重，三种工况。

训练数据的透明度相对不错

训练集包含 Multilingual LibriSpeech、Mozilla Common Voice、FLEURS、VoxPopuli 等公开数据集，加上 NVIDIA 内部数据集和 Granary。标注方式清楚说明了哪些是人工标注、哪些是合成标注（用 Canary、Parakeet、Whisper、FunASR 的集成做的伪标签，标点部分用 Qwen3-32B 补全）。这种透明度在闭源商业 API 里是看不到的。

有什么让人不满意的

环境依赖链太重。 NeMo 框架的安装对新手非常不友好，依赖版本要求严格，CUDA 版本对不上就是一堆报错。Transformers 路线相对干净，但 RNNT 的流式接口在文档上还不够完善

普通话精度有提升空间。 Tier B 的定级是诚实的，但对于中文为主的场景，20% 左右的 CER 在专业场合（技术会议、医疗问诊）还不够用，需要在领域数据上 fine-tune。好消息是 NVIDIA 提供了 fine-tune 的完整方案和 blog，坏消息是你得有足够的标注数据和额外的 GPU 时间。

CPU 推理基本不可用。 官方明确说了需要 NVIDIA GPU，CPU 虽然能跑但速度差距悬殊，用 Whisper.cpp 之类的方案会更合适。如果你的场景是边缘设备（树莓派、无 GPU 服务器），这个模型不适合你。

中文口语和方言支持还是短板。 测试了几段带上海腔调的普通话，错误率明显上升。这不是这个模型特有的问题，但如果你的用户群体口音多样，这需要在评估阶段认真测试，不能只看 FLEURS 上的数字。

适不适合你：一个粗糙的决策框架

Nemotron 3.5 ASR 代表了一种正确的工程取舍思路：用 Cache-Aware 架构从根本上解决流式 ASR 的重计算问题，而不是在 Whisper 外面套一个 workaround 凑合。600M 的参数规模不算最大，但在"推理效率"这个维度上击穿了比它大一倍的竞品。收益是实实在在的并发能力提升和更干净的下游文本，节省的 GPU 开销在规模上去之后会非常明显。

总结一句话：如果你在做多语言流式语音识别的生产系统，又有 NVIDIA GPU 可用，Nemotron 3.5 ASR 值得认真评估。不要只看那张"40 种语言"的宣传图，去看 FLEURS 上各语言的实际 WER 数字，再结合自己的场景数据测一遍。

 动画详解transformer  在线视频教程