首页2026 年 8 月 3 日，NVIDIA 在 Hugging Face 上开放了 NemotronLabs VoiceChat 11B 的权重——这是目前第一个同时支持全双工对话和实时工具调用的开源语音模型。独立测评机构 Artificial Analysis 的数据显示，它是目前唯一一个在对话流畅度和语音推理能力两项评测中均进入前三的开源模型。
448ms 的轮换延迟和对话中途调用工具的能力，是这次发布最受关注的两个点。但权重开放不等于可以直接上线，NVIDIA 团队在模型卡里也明确标注”仅用于研究目的”。这篇文章把这个模型拆开来看：架构设计解决了什么问题，工具调用的实测数据说明了什么，部署门槛在哪里，以及它暴露出的下一个真正难题是什么。
一. 传统语音 Agent 的结构性问题
过去大多数语音 Agent 的实现方式是一条级联流水线：用户说完话，ASR 先把语音转成文字，LLM 拿到文字后理解并生成回复，最后由 TTS 把文字合成语音播放出来。这套流程的问题不是哪一环做得不好，而是三个模型之间的交接本身就在不断累积延迟，而且整条流水线只能严格按轮次工作——系统在说话的时候无法同时在听。
全双工模型要解决的就是这个结构性问题：让系统在输出语音的同时持续接收用户的输入，用户随时可以插话，系统能及时让出话语权。过去一年里，GPT Realtime、Gemini Live 等系统相继在这个方向上发力，但开源社区一直缺少可以直接拿来研究和评估的全双工模型。VoiceChat 11B 填的是这个空缺。
二. 架构：把三个模型压进一个网络
VoiceChat 11B 是一个 11B 参数的端到端 speech-to-speech 模型，把语音理解和语音生成放进同一个流式网络中，训练数据使用了约 55 万小时的真实与合成语料。架构上由四个部分组成：
语音编码器来自 Nemotron-Speech-Streaming-En-0.6b 的快速 Conformer，持续对输入的 16kHz 音频流进行编码。语言模型主干是 NVIDIA Nemotron Nano v2，负责消费音频 token 并预测文本 token。TTS 解码器把预测出的音频码渲染为 22.05kHz 的语音输出。第四个部分是一条独立的工具调用输出通道，专门用于输出 <TOOLCALL> 脚本。
NVIDIA NemotronLabs VoiceChat 11B 模型架构。图片来源：NVIDIA / Hugging Face
模型的输出包括三条并行流：智能体语音、智能体文本，以及持续更新的用户转写文本。取消 ASR、LLM、TTS 三模型之间的 API 交接，是压低端到端延迟的主要手段。
三. 工具调用：对话式 AI 进入 Agent 场景的关键设计
全双工解决了”对话速度”的问题，但语音 Agent 进入真实业务场景后，紧接着就会遇到工具调用的问题：用户问订单状态，模型需要去查；用户问天气，模型需要调接口。这个过程在网页聊天里可以转圈等，在语音通话里不行——几秒的沉默会让用户以为连接断了。
VoiceChat 11B 的处理方式是通过独立侧通道生成 <TOOLCALL>，后台同时执行真正的 API 请求。开发者可以为每个工具预设一句 hold message，比如查询订单时模型先说”我帮你看一下最新状态”，后台并行请求接口，结果回来后通过 <TOOL_RESPONSE> 交回模型继续对话。
这个设计的价值不在于技术有多新，而在于它正视了一个现实问题：全双工模型本身再快，也填不上外部 API 的等待时间。天气接口可能等 500ms，CRM 系统可能要两秒，企业内部系统碰上鉴权和网络抖动更不可控。把 API 等待时间纳入对话设计，而不是试图消灭它，是更有工程实用价值的方向。
四. 实测数据：轮换延迟达标，工具调用还差得远
在 Full-Duplex-Bench 1.0 上，VoiceChat 11B 的平滑轮换延迟为 448ms，TOR（轮换占用率）为 0.82；用户打断接管延迟 480ms，TOR 为 1.00，打断接管完整度满分。这些数字已经进入比较自然的交互区间，在开源模型里排名第二。
工具调用的数据则差距明显。在 AU Harness BFCL-v3 口语工具调用测试中：
| 测试场景 | 准确率 |
|---|---|
| 简单场景 | 58.5% |
| 多工具场景 | 62.5% |
| 并行场景 | 42.5% |
| 并行多工具场景 | 27.5% |
| 无关性识别 | 89.6% |
| 平均 | 56.1% |
在 Full-Duplex-Bench v3 的工具调用专项评测中，工具选择准确率达到 82.5%，但参数准确率只有 44.2%，Pass@1 为 33%。模型已经比较知道该用哪个工具，但能否把正确参数交给工具并一次完成任务，成功率只有三成。
这个结果和目前整个行业的状态基本一致。Full-Duplex-Bench v3 对 GPT Realtime、Gemini Live、Grok、Ultravox 等系统的测试同样发现，一旦加入真实用户的停顿、犹豫、自我修正和多步 API 调用，各家性能都会明显下降。语音工具调用在整个行业都还是早期阶段。
五. 部署门槛：80GB 显存起步，仅供研究
权重已在 Hugging Face 开放，许可证为 OpenMDW-1.1，较为宽松。但实际部署的门槛不低。
硬件上，单卡至少需要 80GB 显存，目标平台包括 A100、H100、B200、RTX 6000 Pro 等 x86_64 Linux GPU。目前没有托管 API，也没有推理服务商提供该模型，没有 GPU 资源的团队连评估都很难进行。
NVIDIA 团队在代码库里记录了真实存在的失败模式，逐条列出：音频上下文上限约两分钟；多轮对话后可能退化为不可恢复的乱码；单轮结束后存在失控的自言自语；用户转写可能丢词；单次会话推荐不超过五个工具调用；多工具并行调用能力不稳定；工具执行期间用户暂时无法正常打断。
最后这一条值得单独说。模型宣称全双工，但当真正进入工具执行阶段时，交互部分退回到了不可打断的状态。用户可以打断模型说话，却无法打断”已经发出去的退款请求”——体验层面实现了全双工，业务状态还是半双工。
六. 这个模型暴露出的下一个问题
过去一年语音模型的竞争很集中：谁能更快开口，谁更会判断用户说完没有，谁能在用户插话时自然让出话语权。VoiceChat 11B 在这几项上的表现已经进入第一梯队。
但当模型开始真正调用 CRM、支付、搜索、导航这些外部系统后，新的问题出现了。用户在工具执行过程中改变主意怎么办？一个 API 还没返回，用户又触发了第二个工具怎么办？模型说”我帮你取消”，但后台请求其实已经成功提交了，怎么处理？工具返回失败时，前台的语音应该如何接回来？
这类问题靠降低 100ms 延迟解决不了。它要求系统把对话状态、模型状态和业务状态放进同一个实时控制逻辑里。全双工不能只存在于模型推理阶段，还要贯穿工具执行和任务状态管理。
用户不会因为系统正在调用 API，就暂时停止做人。他仍然会说话、改口、催促、打断。VoiceChat 11B 的 hold message 机制提供了一个方向，但它处理的还只是”填补等待空白”，真正的挑战是”允许用户随时改变正在执行中的任务”。端到端语音模型下一步要走的路，就是这里。
七. 哪些团队现在可以用，用在哪里
考虑到 80GB 显存的硬件门槛和”仅供研究”的定位，VoiceChat 11B 现阶段适合的团队范围相对有限：有 GPU 资源的 AI 原生团队、企业研发实验室、GPU 云服务商，以及高校语音研究组。没有自有 GPU 的团队，等待推理服务商接入会更现实。
适合评估或试点的场景包括：联络中心和客服平台（插话打断 + 工具查询）、汽车座舱语音助手、零售语音点单、电信 IVR 现代化改造、游戏 NPC 对话，以及全双工延迟基准测试。
如果你在做实时语音 Agent，面临的问题不只是”如何降低延迟”，还包括工具调用期间如何保持对话连续、用户打断后如何恢复任务状态，声网对话式 AI 引擎在这条链路上有成熟的工程方案，欢迎联系声网专家团队了解更多。
