NVIDIA NemotronLabs VoiceChat 11B 挑战语音 AI 流水线

NVIDIA NemotronLabs 发布了 VoiceChat 11B，这是一款开放权重语音模型，据称可在全双工对话中实现 448 毫秒的轮次衔接和实时工具调用。

这一发布挑战了标准语音代理流水线，后者通常将自动语音识别、语言模型和文本转语音服务串联起来。VoiceChat 则在一个协同网络内处理流式语音理解与生成。它可以边说边听、在被打断时让出话语权，并在不结束对话的情况下准备工具调用。

这一组合的重要性不止在于延迟数字本身。开放语音模型越来越擅长自然发声，但生产系统还必须能在用户犹豫、打断或修改请求时执行操作。NVIDIA VoiceChat 11B 将这些问题整合进一个可下载模型中，不过其基准测试结果显示，流畅的语音并不能保证可靠执行。

NVIDIA NemotronLabs 将倾听、表达与行动整合在一起

该发布将多项语音代理功能整合为一个流式系统，使对话时机成为模型自身的一部分，而非外部编排问题。

NVIDIA 于 2026 年 8 月 3 日发布了 VoiceChat 11B。该公司将其描述为一款拥有 110 亿参数的端到端语音转语音模型，专为实时全双工交互设计。全双工意味着双方可以同时说话和倾听，而不是等待严格的交接。

该模型可接收 16 kHz 音频及文本系统提示词。它输出代理文本、22.05 kHz 合成语音，以及持续更新的用户转录文本。公开的模型卡包含模型权重、基准测试结果、示例对话和部署说明。

其架构结合了四个主要组件。Fast Conformer 编码器将输入语音转换为音频表征。Nemotron Nano V2 9B 语言模型骨干预测带有时间信息的文本 token 流。文本转语音解码器将这些 token 转换为音频编码，编解码器则重建语音输出。

NVIDIA 将整体设计描述为混合式 Mamba 和 Transformer 架构。Mamba 是一种旨在高效处理长序列流的序列建模方法，而 Transformer 则提供现代语言模型中常见的注意力机制。

独立的输出通道用于预测工具调用脚本。这种分离让模型能在应用读取结构化函数请求时继续管理语音输出。应用仍负责执行函数并返回结果。

这一设计并非从字面上消除了语音技术栈中的所有组件。语音编码、推理、合成和解码依然存在。关键变化在于，它们在共享、帧对齐的时间线上协同运行，而不是让已完成的输出在多个独立服务间依次传递。

这一共享时间线让模型能够在用户仍在说话时获取部分语音信息。它可以判断停顿是代表一轮对话结束、犹豫，还是短暂停歇。它也能在生成自身回应时持续监测新的输入。

传统级联系统通常需要独立的端点检测逻辑来做出这些判断。自动语音识别服务先确定用户说了什么，语言模型再生成文本，语音服务则将该回应转换为音频。

各阶段可以独立优化，这仍是其一大优势。然而，每次交接都会引入缓冲、网络传输，以及又一个可能导致对话时机失误的环节。

VoiceChat 将更多这种协调工作移入模型。这一转变构成了该发布的核心问题：统一语音系统能否在保持低延迟的同时，拥有足以采取真实行动的准确性。

448 毫秒结果改变了交互基准

VoiceChat 最具说服力的结果在于对话时机，但这一测量描述的是基准测试条件，而非所有已部署应用。

在 Full-Duplex-Bench 1.0 上，NVIDIA 报告了 448 毫秒的平滑轮次衔接延迟。该模型在该任务中的轮次重叠率（TOR）为 0.82。TOR 衡量模型是否能在恰当时机取得或让出对话主导权。

在用户打断场景中，该模型取得了 1.00 的 TOR 和 480 毫秒延迟。这一结果表明，在评估的打断场景中，它能稳定地让出话语权。NVIDIA 还报告了暂停处理 TOR：合成数据上为 0.153，对话 Candor 数据集上为 0.255，数值越低越好。

底层的全双工基准测试评估了普通语言基准测试经常忽略的行为，包括附和回应、停顿、打断，以及说话者之间的平滑切换。

即使语音代理给出的事实答案不变，这些行为也决定了它是否让人感觉反应灵敏。如果系统抢话，或将每次停顿都误判为说完，那么即便它生成了出色答案，仍会让人感觉失灵。

不过，448 毫秒这一数字仍应谨慎解读。NVIDIA 使用其自身运行时配置和 H100 GPU 测试该模型。应用延迟还包括麦克风传输、音频缓冲、工具执行、网络条件和播放。

端点检测策略同样会改变用户感受到的速度。激进的系统会很快开始说话，但可能在自然停顿中打断用户。保守的系统避免这些打断，却会在每次回应前引入静默。

全双工建模试图用持续决策取代这种固定权衡。模型会倾听有关一轮对话是否结束的语义和声学证据。它也会在开始说话后继续处理新的音频。

这一能力适用于客户支持、日程安排、无障碍系统和交互式角色。来电者可在回答中途更正账号。用户可以打断冗长解释。游戏角色也可以在对话仍在展开时作出反应。

但基准测试中的时机只是这些体验的一部分。模型还必须准确转录姓名、保留先前细节、调用被允许的函数，并避免基于不完整请求采取行动。

NVIDIA 表示，训练混合数据约包含 55 万小时的真实和合成音频。模型卡列出的来源包括 Fisher speech、LibriVox、LibriTTS、HiFi-TTS、内部录音，以及由文本语料合成的语音。

这种混合数据的广度有助于解释模型对对话能力的侧重。但它也留下了有关不同口音、嘈杂环境、专业词汇以及英语以外语言表现的问题。

VoiceChat 目前面向英语交互。其系统提示词和工具响应还有一项不寻常的运行限制：必须使用 ASCII 文本。NVIDIA 建议开发者在将工具结果送往语音合成前，移除表情符号、Unicode 标点、度数符号和类似字符。

这一限制在受控演示中尚可管理。但在需要读取国际姓名、地址、货币或多语言记录的应用中，问题会更加棘手。

因此，延迟结果提供了一个有用的基准，而非完整的部署结论。它表明，开放权重模型可以在对话时间尺度上协调倾听与表达。它并不表明围绕该模型构建的每个应用都能在 448 毫秒内响应。

实时工具调用才是 NVIDIA VoiceChat 11B 的真正考验

独立函数通道是此次发布最关键的功能，因为它能将自然对话连接到外部操作，而无需强制完全静默。

只能依据内部知识回答的语音模型，仍然只是一个交谈界面。能够查询订单、获取日程、更新记录或调用其他服务时，语音代理才具备实际操作能力。

NVIDIA 表示，VoiceChat 是首个在执行期间仍保持语音交互、并支持工具调用的开放全双工模型。这一说法专门适用于开放全双工系统，而非所有商业语音服务。

该模型通过系统提示词接收工具定义。当它检测到匹配请求时，专用函数通道会输出结构化工具名称及其参数。外围应用验证该输出、调用外部 API，并返回结果。

VoiceChat 可以在预测到函数调用后，立即给出由运营方定义的“等待中”提示。例如，天气助手可能会说正在查看天气预报；客服代理则可能告知来电者正在查询订单。

这一小小的行为解决了语音界面中反复出现的问题。API 调用并不会瞬间完成，无法解释的沉默会让用户怀疑系统是否停止了倾听。

等待提示不会降低 API 延迟。它在维持对话连续性的同时掩盖了一部分等待时间。开发者可为每个工具配置不同提示语，从而控制代理在结果出现前说什么。

这一机制还区分了两类不确定性。代理可以确认已收到所请求的操作，而不会假装已经知道结果。只有在应用返回数据后，它才会说出实际结果。

NVIDIA 的交互式容器为这一工作流提供了双向 WebSocket 接口。WebSocket 会保持连接开放，使音频帧、模型输出、函数请求和结果可以双向传递，而无需每次都建立新请求。

公开的部署代码打包了 CUDA、Triton 和 vLLM 组件。NVIDIA 为离线测试和交互式流处理分别提供了不同路径。

这一区别很重要。离线函数调用示例不会调用实时工具。它们从文件读取预先准备好的 JSON 响应，让研究人员检查模型是否生成预期的函数请求。

只有交互式流处理路径才能完成实时往返。因此，开发者不能将成功的离线示例视为其联网应用能够正确处理超时、格式错误参数、授权失败和迟到响应的证据。

生产应用还需要围绕模型建立明确的状态机。它必须知道工具调用何时开始、归属于哪一轮对话、用户是否取消了它，以及应当朗读哪一个回应。

全双工使这种状态管理更复杂。用户可能在听到等待提示后修改请求。此时，应用需要决定是取消原始调用、启动另一个调用，还是请求确认。

以请求改签航班的旅行助手为例。用户可能在第一次查询可用航班仍在运行时，打断并提出新的日期。低延迟语音会让这种更正感觉自然，但预订系统必须确保只有用户意图中的行程进入确认环节。

这正是 NVIDIA 对传统语音技术栈施加的主要压力。级联系统在识别、推理和合成之间提供清晰边界。VoiceChat 提供了更紧密的时机协同，但开发者仍需要围绕实际操作建立可靠边界。

因此，此次发布转移了部分工程负担。团队在协调对话式音频组件上投入的精力会减少，但需要在持续语音环境下投入更多精力，验证模型的结构化输出。

流畅对话并不意味着可靠的工具执行

VoiceChat 在选择工具方面的表现优于处理工具参数，这暴露出对话自信与操作正确性之间的差距。

NVIDIA 报告称，在 Berkeley Function Calling Leaderboard v3 测试框架的音频版本中，模型平均得分为 56.1%。不同任务结构之间的结果差异显著。

该模型在简单调用中的得分为 58.5%，在涉及多个可用工具的场景中为 62.5%。在并行调用时，得分降至 42.5%；在涉及多个工具的并行调用中，则降至 27.5%。

它在无关性检测上的表现明显更好，得分为 89.6%。该测试评估模型是否会在请求并不需要工具时避免调用工具。

第二项评估，Full-Duplex-Bench v3，引入了自然语音条件和多步骤工具使用。NVIDIA 报告的工具选择准确率为 82.5%，参数准确率为 42.2%，Pass@1 结果为 33%。

这些数字揭示了核心权衡。模型通常能够识别合适的函数，但在构造该函数所需的值时，可靠性要低得多。

一个语音天气请求可以说明这种差异。选择天气函数相对简单；但在用户犹豫、更正或被打断后，正确提取城市名称则更困难。

对于影响重大的操作，风险会进一步增加。客服系统可能选择了正确的退款工具，却附上错误的订单号。日历助手可能选中了安排日程的函数，却误读了更改后的日期。

Pass@1 衡量的是首次尝试调用是否符合基准测试的成功标准。33% 的得分不足以证明系统具备无需监督的可靠操作能力。

这些结果并未抹杀其架构贡献，而是明确了开发者在部署前必须测试的内容。对话质量、工具选择、参数提取和成功完成是彼此独立的指标。

应用程序应依据严格的 schema 验证函数名称和参数。它们应拒绝缺失值、限制可接受范围，并在执行不可逆操作前请求确认。

VoiceChat 发布的系统提示词要求模型不要猜测缺失的必填参数。它还指示代理只能调用提示词中明确列出的工具。

提示词指令很有用，但并不是安全控制措施。宿主应用程序必须独立执行权限控制，并在将任何内容转发至其他系统之前，将模型输出视为不可信输入。

长时间对话带来了另一项不确定性。Pipecat 的独立部署工作指出，NVIDIA 训练该模型时使用的音频上下文窗口最长不超过两分钟。超出该窗口的信息可能不再可靠。

Pipecat implementation 还将知识、推理、转录和工具选择列为需要谨慎评估的领域。其维护者将长会话性能退化列为尚待测试的开放问题。

语音合成带来了文本基准无法捕捉的进一步风险。模型可能生成正确的结构化调用，却在口头总结时提供不准确的信息。它也可能在用户已经撤回请求后，仍然说出等待提示。

因此，评估至少应比对三项记录：用户转录文本、函数负载以及语音响应。任何不一致都可能改变用户对系统实际执行操作的理解。

开发者还需要在具有对抗性的时点测试打断情况，包括参数收集过程中的更正、工具结果返回时到达的语音，以及多个排队函数乱序完成的情况。

NVIDIA 将 VoiceChat 定位为 Labs 模型，面向研究人员、开发者和语音专业人士。其模型卡建议，在将其集成至 AI 系统之前，针对具体用例进行测试。

模型权重采用 NVIDIA Open Model Development and Weight license 1.1 版。“开放权重”比假定其采用不受限制的开源条款更准确，因为其使用仍受该许可证约束。

模型卡并未将 VoiceChat 描述为托管式生产 API。Hugging Face 也显示，在发布时没有推理服务提供商提供该模型。团队必须自行运行该模型，或采用独立维护的实现方案。

这一区别对企业买家很重要。此次发布提供了可检查的权重和代码，但并未提供托管服务级别协议、监控系统、合规套件或生产支持层。

开放权重仍伴随着高昂的部署成本

模型可以下载，但其参考运行时仍让全双工实验集中于配备大显存 NVIDIA 硬件的团队。

NVIDIA 将 A100、H100、H200、B100、B200 和 RTX 6000 列为兼容硬件系列。其公开评估使用 H100，而 vLLM-Omni 参考配置指定一张拥有 80 GB 显存的 H100。

vLLM-Omni recipe 将推理分为三个阶段。thinker 生成与帧对齐的文本时间线，talker 生成音频代码堆栈，decoder 重建波形音频。

该实现以 12.5 Hz 的时间线处理音频，对应每帧 80 毫秒。默认配置对主要阶段使用全精度执行，以匹配 NVIDIA 的参考行为。

根据该方案，仅全精度 thinker 的权重就约为 43 GB。维护者表示，48 GB 显存卡无法运行这一默认配置，并建议在低于 80 GB 显存级别的硬件上使用降精度选项。

这一要求限制了即时可用性。许多开发者可以将一个 110 亿参数的文本模型下载到消费级硬件上，但实时语音生成还增加了编码器、合成组件、音频编解码器和持续流式状态。

社区已经在绕开这一限制。Pipecat 发布了一个量化版本，设计目标是在单台 DGX Spark 上运行。其转换使用降精度权重和运行时补丁，以维持实时交互。

这一工作展现了发布权重的价值。独立团队可以检查架构、修改服务代码，并探索更小的部署配置，而无需等待厂商 API。

它也说明了为什么原始发布并非开箱即用的产品。Pipecat 的设置需要下载约 65 GiB 数据、至少 90 GiB 可用存储空间，并构建本地 CUDA 容器。在其文档所述配置中，启动需要数分钟。

NVIDIA 的参考路径同样要求使用 Linux、NVIDIA GPU、CUDA 组件、Python 依赖项以及特定的 Speech 仓库分支。交互式部署还增加了 Triton、vLLM 和 WebSocket 基础设施。

这些要求对于研究推理而言并不罕见，但合在一起，形成了比基于 API 的语音服务更高的运维门槛。

自托管具有实质性优势。音频可以保留在组织可控的环境中，并受其部署设计约束。团队可以检查模型产物、修改服务层，并避免依赖托管端点。

自托管也会转移责任。运营方必须处理扩缩容、GPU 可用性、连接恢复、可观测性、数据保留和安全补丁。他们还必须决定如何让对话音频和转录文本进入日志。

全双工会话会让模型在整个交互过程中持续活跃。因此，容量规划取决于并发实时会话数量，而不只是已完成提示的数量。即使用户暂停，长时间通话也可能持续占用资源。

工具执行又引入了另一项容量维度。外部服务响应期间，语音模型可能仍需保持驻留。高效的应用程序需要管理这些等待，避免停滞调用无限制地消耗会话资源。

NVIDIA 尚未宣布托管的 VoiceChat API。寻求立即部署的开发者必须权衡自托管带来的控制力，以及运营流式 GPU 服务所需的工程工作。

这正是传统级联方案仍具优势的地方。团队可以选择托管语音识别器、托管语言模型和独立语音引擎，并且无需重新训练其余组件即可替换其中一个组件。

级联方案还可以将简单请求路由至更小的模型或专用服务。这种灵活性有助于控制运营要求，并让团队能够为每个阶段选择不同供应商。

VoiceChat 的统一时序更难通过独立 API 复现，其代价是语音质量、推理行为、工具调用与受支持硬件栈之间的耦合更紧密。

没有任何一种路线能赢得所有部署场景。NVIDIA NemotronLabs 让统一路线具备了足够的可检查性，供开发者直接衡量这一权衡。

三个信号将显示该模型能否走出实验室

下一阶段取决于独立延迟结果、更高的工具调用完成率，以及在更小硬件上的实际部署。

第一个信号是第三方端到端测试。开发者应在真实 WebSocket 连接中测量从麦克风到音频的延迟，而不只是参考模型的轮次衔接基准。

有价值的测试应包括背景噪声、重叠说话者、长时间停顿、更正和弱网络环境。它们还应在报告响应速度的同时报告误打断情况。如果一个更快的系统反复打断用户，它并不更好。

独立比较还需要采用一致的硬件和端点检测策略。否则，公开的延迟数字可能描述交互中的不同部分，看似可比，实则并非如此。

第二个信号是在不流畅语音下的工具调用可靠性。VoiceChat 82.5% 的选择结果令人鼓舞，但其 42.2% 的参数准确率和 33% 的 Pass@1 暴露了更棘手的问题。

未来版本需要更强的参数提取、取消处理和多步骤执行能力。评估应测试那些在请求进行到一半时修改日期、姓名、数量或地点的用户。

生产试点还应公布经过 schema 验证和澄清后的任务完成率。原始模型准确率无法揭示应用程序能否从不确定调用中安全恢复。

第三个信号是更广泛的硬件支持。社区量化工作已经表明，该模型可以超越参考的 80 GB 配置，但降精度也引入了另一个需要评估的变量。

值得关注的是能否在 48 GB 及更小系统上实现可复现的配置，以及相应的语音质量、打断行为和函数准确率测量。更小的内存占用只有在对话优势能够经受压缩时才有意义。

托管可用性也是这一信号的一部分。受支持的推理端点可让更多团队测试 NVIDIA VoiceChat 11B，而无需维护 CUDA、Triton 和流式基础设施。

目前，最好将此次发布理解为一个架构标志。它表明开放权重语音模型可以在一次连续交互中倾听、说话、让出话轮并发起操作。

它也让剩余的弱点异常清晰地显现出来。类人化时序可能让代理听上去比其工具参数所能证明的更有能力。开发者必须防止这种感知演变为权威。

决定性的考验并不在于 NVIDIA NemotronLabs 能否在 448 毫秒内开始说话，而在于当真实用户打断对话、改变主意时，应用程序能否在执行正确操作并传入正确参数的同时，保持这种响应速度。

评估该模型的团队应记录完整会话，将语音输出与结构化调用进行比对，并在接入具有实际影响的工具之前测试恢复能力。这些证据将表明，统一的全双工系统能否取代模块化语音流水线，还是它们仍是一条颇具吸引力、但前方还有大量运营工作要完成的研究路径。