8月3日，NVIDIA 开源了 NemotronLabs VoiceChat 11B，一个端到端的实时全双工语音对话模型。全双工这个词值得先解释一下：传统语音助手是你说完、它听完、再回答，一来一回像对讲机；全双工则是双方可以同时说话，你能随时打断它，它也能在你说到一半时接话，对话节奏和真人聊天一致。
语音助手行业过去十几年一直卡在一个结构性问题：听和说被拆成了两套系统。识别要一个模型，理解要一个模型，合成又要一个模型，三套模型串起来，延迟层层叠加，打断和插话这种人类对话里最自然的行为，对级联架构来说几乎是不可能完成的任务。这也是为什么市面上的语音助手总给人一种"慢半拍"的感觉。
全双工模型的思路是换赛道：让一个模型同时处理听和说。过去这类模型基本都是闭源的，NVIDIA 这次不仅把权重开源了，还做了一件行业里没人做过的事——在开源全双工模型上支持实时工具调用。也就是说，你可以一边跟它聊天，一边让它帮你查天气、查股价、查新闻，它说着话就把工具调用了，整个过程不打断对话。
一个模型包办听说
先看它和传统语音助手在架构上的根本区别。传统方案是三级级联：ASR 把用户语音转成文字，LLM 处理文字生成回复，TTS 再把回复合成语音。三个模型来回传数据，每一跳都有延迟，打断处理和自然轮转几乎做不好。
VoiceChat 11B 把这三步合并进一个统一架构：音频进来先经过 Fast Conformer 编码器转成音频 token，送到 Nemotron Nano V2 9B 语言模型骨干里预测文本 token，再交给 TTS 解码器直接生成代理语音。整个流程一次完成，没有模型间切换，端到端延迟自然就低。
模型本体 11B 参数，采用混合 Mamba/Transformer 架构。Mamba 负责高效处理流式长序列，Transformer 保留全局建模能力，两者配合既能处理实时音频流，又不牺牲对话质量。这种混合设计在语音这类长序列任务里很常见——纯 Transformer 处理流式音频的计算开销太大，纯 Mamba 又在长程依赖上吃亏，混合架构取两者之长。
输入端用 16kHz 采样率的音频，Fast Conformer 编码器来自 NVIDIA 的 Nemotron-Speech-Streaming-En-0.6b 模型；输出端是 22.05kHz 的语音，由 TTS 解码器生成。中间的语言模型骨干是 Nemotron Nano V2 9B，负责理解语义、组织回复、决定是否调用工具。
边说边调用工具
工具调用是 VoiceChat 11B 最大的卖点，也是它自称"首个开源全双工工具调用模型"的底气。实现方式很巧妙：模型除了常规的文本输出通道，还有一个独立的输出通道专门预测工具调用脚本。
举例来说，你问"今天北京天气怎么样"，模型先触发一个 <TOOLCALL> 标记，里面是结构化的工具名和参数，比如 {"name": "get_weather", "arguments": {"city": "北京"}}。工具执行期间，模型不会沉默——每个工具可以配一条"on-hold"等待语，比如"我帮你查一下"，说完这句继续等工具返回，拿到结果后再自然地把答案说出来。
整个过程听起来就是一段流畅的对话，而不是"好的，正在为您查询……"这种生硬的等待。官方给了三个演示音频：自然轮转对话、用户打断让位、实时工具调用，对应的波形图如下。
工具调用的效果，官方给了两套评测。AU Harness 的 BFCL-v3 语音版，平均分 56.1%，其中简单工具 58.5%、多工具 62.5%、无关请求拒绝率 89.6%——模型知道什么时候该调用、什么时候不该调用，这个判断能力是及格的。但并行工具只有 42.5%、并行多工具 27.5%，一次要调好几个工具时准确率掉得厉害。
另一套是 Full-Duplex-Bench v3，工具选择准确率 82.5%，已经能和前沿模型比一比；但参数准确率只有 44.2%，Pass@1 是 33%——选对工具容易，把参数填对难。比如"查明天上海和北京的天气"，它可能选对了 get_weather，却把城市参数搞混。这是语音工具调用现在的普遍瓶颈，VoiceChat 11B 作为第一个开源实现，把问题暴露出来本身就是价值。
打断秒回：数据说话
全双工做得好不好，几个关键指标就能看出来，官方用的评测是 Full-Duplex-Bench 1.0，VoiceChat 11B 在开源模型里排第二。
- • 轮转延迟：450ms 左右，也就是你问完到它开始回答，平均不到半秒。评测里 Smooth Turn Taking 的延迟数据是 448ms。
- • 打断处理：User Interruption 指标满分 1.0，延迟 480ms——你说到一半打断它，它基本立刻停嘴让位，响应时间不到半秒。官方在同一指标下给出的 GPT-4o 参考评分是 4.33，这里 TOR 和 GPT-4o 的数值属于两套不同口径，直接横向对比意义不大，重点看 480ms 的让位延迟。
- • 暂停处理：两个评测子集（Synthetic 和 Candor）的 TOR 指标分别是 0.153 和 0.255，数值越低代表处理自然停顿越稳，不容易误判"你说完了"。
这些数据放在开源全双工模型里是第一梯队。VoiceBench 榜单上，它在所有开源全双工模型里排名第二——VoiceBench 是评测 LLM 语音助手真实口语交互的基准，覆盖开放式问答、指令遵循和对抗性用例，数据来自真实人声和合成语音混合。能排到开源第二，说明它不只是"能对话"，而是"对话得像样"。
需要说明的是，Full-Duplex-Bench 1.0 上的开源模型第二名这个成绩，是它和另一批开源全双工模型横向比较的结果，第一梯队里还有更早发布的 PersonaPlex、Moshi 这类模型。VoiceChat 11B 的优势不在"碾压"，而在"全都要"——延迟、打断、工具调用放在同一个开源模型里，这在以前是没有的。
上手指南：本地部署
VoiceChat 11B 支持离线推理和交互式流式部署两种方式，官方给的是 vLLM 运行时，测试硬件是 H100，兼容 A100、H100、H200、B100、B200、RTX-6000 这些主流数据中心卡。
离线推理流程不复杂：克隆 NVIDIA-NeMo/Speech 仓库切到 nemotron-labs-voicechat 分支，建 conda 环境装依赖，然后下载权重跑脚本。
git clone https://github.com/NVIDIA-NeMo/Speech.git
cd Speech
git switch nemotron-labs-voicechat
# 下载权重
hf download nvidia/NVIDIA-NemotronLabs-VoiceChat-11B \
--local-dir /path/to/checkpoint
# 普通对话
python "$NEMO_DIR/examples/speechlm2/offline_voicechat_infer.py" \
--checkpoint /path/to/checkpoint \
--wav "$NEMO_DIR/examples/speechlm2/sample_audio/sample_general.wav" \
--output-dir /path/to/output
工具调用的离线模式不真正执行工具，而是通过 --api-response-json 喂一个预写的工具响应 JSON，验证模型能不能正确生成调用脚本。要跑真正的实时语音工具调用，需要部署 NVIDIA 的推理容器，通过 WebSocket 接口交互，官方在仓库里有完整的部署文档，包括前置条件、容器启动、模型仓库生成和 API 参考四份说明。
有一点要注意：官方明确标注这个模型仅限研究用途（research purposes only），商用部署前需要评估 OpenMDW 许可证的具体条款。硬件方面，官方测试环境是 H100，兼容列表包括 A100、H100、H200、B100、B200 和 RTX-6000，都是数据中心级显卡，家用消费级 GPU 不在官方支持范围内——想跑全双工实时对话，先确认手里有没有对应的卡。
550k 小时训练数据
VoiceChat 11B 训练用了约 55 万小时音频，混合真实语音和合成语音。合成部分用多种 TTS 系统在文本语料上生成，真实部分包括 Fisher 电话对话、LibriVox/LibriTTS 有声书、VCTK、Voxmovies 电影语音等公开数据集。
文本侧用的是 Nemotron 5.5 预训练和 SFT 数据、Ultrachat 对话数据、Brainy-mantis 等。特别值得注意的是，训练数据里包含了 Nemotron Nano v3 的函数调用数据和 PersonaPlex 的训练集——工具调用能力和角色控制能力是从数据层面直接带进来的，不是后加的补丁。PersonaPlex 是 NVIDIA 年初发布的另一款全双工模型，主打角色和声音定制，VoiceChat 11B 继承了它的数据资产。
55 万小时是个什么概念？一个人不眠不休连续听，也要听六十多年。当然，这里面大量是合成语音，真实性和多样性不能和纯真人数据画等号，但量级摆在这里，是它能同时撑起识别、理解、合成、工具调用四件事的数据基础。
适用场景与局限
适合的场景很明确：语音助手原型和研究，尤其想研究全双工对话机制、打断处理、流式语音理解的团队；需要语音调用工具的智能体实验，比如语音控制家电、语音查询天气股票新闻；以及对比各类 speech-to-speech 模型的评测工作。
局限也要说清楚。第一，模型目前只支持英文，官方数据里没有中英文混合能力的标注。第二，工具调用的准确率还有提升空间——AU Harness 评测平均 56.1%，其中简单工具 58.5%、多工具 62.5%，但并行工具只有 42.5%，并行多工具 27.5%，复杂并行场景容易出错。第三，Full-Duplex-Bench v3 上工具选择的准确率 82.5%，但参数准确率只有 44.2%，Pass@1 是 33%，说明工具参数生成还有不少翻车概率。第四，官方定位研究用途，生产环境部署要自己评估合规和稳定性。另外，社区有反馈说实时音频在某些硬件组合上可能不工作，跑之前先确认环境。
总结：语音助手的开源时刻
VoiceChat 11B 的意义在于，它把全双工语音对话和工具调用这两件最难的事，同时带进了开源世界。450ms 的轮转延迟、打断秒回、边说边调工具——这些体验以前只能在闭源 API 里感受，现在有了可以本地跑、可以看代码、可以自己微调的开源实现。
回到开头说的那个问题：语音助手为什么总是"慢半拍"？根子在于级联架构。VoiceChat 11B 给了一条不同的路——一个模型从头听到尾，从听到说再到调用工具，全在一条流水线里完成。这条路 NVIDIA 已经走通了，而且愿意把权重交出来，让整个行业都能站在上面继续往前推。
它还不是终点。工具调用的复杂并行场景准确率偏低，英文单语也限制了覆盖面，研究用途的定位意味着商用还要等一等。但方向已经很清楚：语音助手正在从"你问我答"走向"边听边说边做事"，而开源阵营这次站到了最前面。对做语音、做智能体、做对话系统的开发者来说，VoiceChat 11B 是值得第一时间上手的研究样本——跑一遍演示音频，你就知道全双工和级联的差距在哪里。