语音这条线换了架构：从 ASR→LLM→TTS 三段式，到一个模型边听边说

做过语音客服的都知道那套经典架构：ASR 转文字 → LLM 出回复 → TTS 合成语音，外面再挂一个 VAD 判断用户说完没有。

这套东西的毛病不是某一环不行，是环与环之间既掉信息又掉时间：语气、停顿、情绪在 ASR 那一步就没了；四次模型调用串起来，延迟天然下不去；VAD 判断「说完了」这件事，本身就是全部尴尬停顿的来源。

今年夏天这套架构开始被整体替换。

一、NemotronLabs VoiceChat 11B：能下载的那个

2026 年 8 月 9 日，英伟达放出 NemotronLabs VoiceChat 11B——一个 110 亿参数的端到端语音到语音模型，开放权重，OpenMDW-1.1 宽松许可。流式语音理解和语音生成在同一个网络里完成，不再有 ASR / LLM / TTS 的交接。

结构是混合 Mamba / Transformer，由三个已有的英伟达组件加一条新输出通路拼出来：

• →Fast Conformer 语音编码器（来自 Nemotron-Speech-Streaming-En-0.6b），持续编码进来的 16 kHz 流。
• →Nemotron Nano v2 作为语言骨干，吃音频 token、预测文本 token。
• →TTS 解码器和编解码器预测音频码，渲染成 22.05 kHz 的语音。
• →一条专门给工具调用的独立输出通道。

输出同时有三样：机器人的音频、机器人的文本、以及一条实时的用户转写。训练用了约 55 万小时音频。

延迟数据（Full-Duplex-Bench 1.0）：平滑轮替 TOR 0.82，448 毫秒；用户打断 TOR 1.00，480 毫秒。也就是说它在说话的同时还在听，用户中途插嘴它会让开。

最实用的创新是工具调用不留冷场。工具调用在侧通道上以 <TOOLCALL> 块发出，你的代码用 <TOOL_RESPONSE> 块把结果送回去。关键在于「on-hold 台词」：每个工具可以由运营方预先定义一句话，模型一生成触发调用的那段文本，它就立刻把这句话说出来，所以 API 在跑的那几秒，对话不会掉进沉默。

约束也说得很死：建议每个会话最多 5 个工具；不能可靠地并发调用多个工具；工具执行期间用户打断不了；系统提示词和工具返回必须是纯 ASCII 且对 TTS 友好。

二、这个模型今天能不能上生产

不能。这一段必须说清楚，因为「开放权重」四个字很容易让人直接排期。

英伟达自己标的是「仅供研究用途」，仓库里把失效模式写得明明白白：

• →音频上下文有两分钟的天花板。
• →若干轮之后会退化成无法恢复的胡言乱语。
• →一个回合结束后可能自己接着自言自语。
• →用户转写会掉字。

硬件门槛：一张至少 80 GB 显存的卡（A100、H100、RTX 6000 Pro 或 B200），x86_64 Linux。目前没有托管 API，也没有推理服务商提供它——没有卡的团队连评估都做不了。

成绩单上，工具调用还很嫩：AU Harness 的 BFCL-v3 口语工具调用，simple 58.5%、multiple 62.5%、parallel 42.5%、parallel-multiple 27.5%、irrelevance 89.6%，平均 56.1%。Full-Duplex-Bench v3 上工具选择 82.5%、参数准确率 44.2%、pass@1 33%。英伟达报告它在开源全双工模型里 VoiceBench 排第二、Full-Duplex-Bench 1.0 上开源模型里排第二。

所以正确的用法是：拿它做试点、做延迟基准、做架构验证，别拿它接客户电话。

三、字节 SeedRealtime：把摄像头也接进去了

同一天（8 月 9 日），字节 Seed 团队放出 SeedRealtime——原生音视频全双工模型，音频、视频、文本在同一个架构里，面对的是连续的多模态流而不是一轮一轮的对话。轮替判断也搬进了模型内部，替掉了大多数实时语音栈还在依赖的外部 VAD。

官方放了七个场景，其中四个真正说明问题：

• →跨模态的身份绑定：嘈杂的聚餐场合，模型在人被介绍时把名字和脸对上，然后一直把每个声音绑在对应的人身上——出方案之前，能把互相冲突的出行偏好归到正确的人头上。
• →从一条挂起的指令主动开口：在河北博物院，用户让它「看到那个青铜器座的时候提醒我」。镜头继续扫，模型在东西进画面的一刻主动说话。同样的行为出现在翻 ResNet 论文时：它跟着快速翻页，看到「3.4 Implementation」那一节自己停下来，把学习率、动量、权重衰减念出来。
• →从视觉状态发起纠正，而不是等人问：看着做意式浓缩的流程，整豆被倒进手柄的那一刻它打断，然后读油脂颜色和萃取量，建议把萃取时间缩短 2 到 3 秒。
• →抗干扰 + 离屏记忆：在北京大兴机场，旁边无关的航班闲聊不会触发回应；用户真的问起来时，它用已经滚出屏幕的航班信息板内容回答，再联网查行李转盘位置。

现实一点：它已经在豆包 App 里上线了，但作为第三方你接不了。没有技术报告、没有参数量、没有开放权重、没有火山引擎或 BytePlus 的端点。字节自己的人评说节奏问题比级联栈减半，但没有基准，没有延迟数字。

所以它今天能给你的，是一份被验证过的参考架构，和一条被挪走的及格线。

四、同期还值得记一笔的几个

• →Cartesia Sonic-3.6（2026-08-18）：流式 TTS，登顶 Artificial Analysis 的两个语音竞技场。要托管服务、要声音质量的，从这条看起。
• →NVIDIA Nemotron 3 Diarization（2026-09-23）：1 亿参数的开放权重模型，实时追踪 8 个说话人。多人会议、多人客服场景里，说话人分离一直是个独立的工程难题，这么小的模型能解，值得试。
• →Kyutai Voice of Reason（2026-09-22）：语音原生模型，用强化学习解口头数学题。这个方向的意义是「语音不再只是输入输出层，它本身要能推理」。
• →Google Gemini 3.8 Flash TTS / Flash-Lite TTS（2026-09-23）：用提示词设计音色。对做内容的团队，这意味着音色不再是「从库里挑一个」。

五、要做语音产品，现在该怎么选

三个分叉：

自己有 80G 卡、做的是可控场景（内部、试点、做技术储备）：拿 VoiceChat 11B 起步，先把全双工这件事在你的业务里跑一遍，摸清两分钟上下文上限和多轮退化对你的场景是不是致命。

没有卡、要马上上线：还是托管 API。但选型的时候把「能不能被打断」当成一个硬指标去测，不要只看 TTS 好不好听。

做的是客服、销售这类会被打断的对话：把 448 毫秒这个数记住，它是当前开源能做到的水位。你现有的三段式栈如果在 1.5 秒以上，用户感知到的就是「这是个机器人」。

最后两个坑：

• →全双工模型的工具调用还很脆。参数准确率 44.2% 意味着它能选对该调哪个工具，但填错参数的概率接近一半。所以工具的参数要尽量设计成封闭枚举，并且在代码里做二次校验——别让模型直接把一个自由文本参数送进你的下单接口。
• →别把「模型内部做轮替」理解成「不用调了」。它只是把 VAD 的位置换了，什么时候该让开、什么时候该坚持说完，仍然要靠你在业务层设策略。