当 AI 学会边听边说：2026 全双工实时多模态大模型的架构演进与工程暗线
8 小时前 · 1 次浏览
一句话结论：2026 年 8 月 5 日字节跳动 SeedRealtime 把"音视频全双工"塞进 2 亿日活的豆包 App，这件事的真正分量不在产品本身，而在它背后那条从级联管道到原生全双工的架构演进脉络——Moshi 的多流+内部独白、GPT-Live 的快慢路径解耦、Thinker-Talker 的 MoE 化、Lychee-FD 的层次化解耦，共同把"何时开口"这个判断从外部 VAD 收进了模型自己脑子里，全双工正在从"实验室 demo"跨进"亿级用户日常"。
一、被"半双工"卡住的十年：为什么级联架构是死胡同
如果你用过 2023 年以前的语音助手——Siri、Alexa、Google Assistant——大概率体验过那种"你说一句、它愣一秒、再答一句"的笨拙。这背后是统治了语音交互近十年的级联架构：语音活动检测（VAD）→ 自动语音识别（ASR）→ 大语言模型（LLM）推理 → 文本转语音（TTS），四个模块像流水线一样接力。
这套架构有三个绕不开的工程死结。
第一，延迟累积。 每个模块都有自己的处理时间，串行累加后全局延迟通常在数秒量级，而人类自然对话的响应时间是几百毫秒——Stivers 等人对 10 种语言的研究表明，自然对话的典型响应时延就在这个区间。你跟一个"反应慢半秒以上"的伙伴对话，体验上的别扭是生理层面的。
第二，信息丢失。 文本是中间模态，所有副语言信息——情绪、口音、停顿、犹豫、笑声、背景音——在 ASR 转文字的那一刻就丢了。模型永远听不到你语气里的焦虑，也学不会用笑声回应你的玩笑。
第三，轮次假设。 级联架构本质上假设对话是一系列"单人发言段"的拼接，但真实的人类对话里，重叠语音约占 10%~15% 的时间，打断、应答词（"嗯""对"）是常态而非例外。一个依赖"谁先安静谁就说完"的系统，在面对"你想说什么来着——啊算了先帮我把那个改了"这种中途改主意的场景时，基本是无解的。
2024 年 5 月 OpenAI 的 GPT-4o 把 ASR/LLM/TTS 三段式管道压成了一个端到端统一模型，延迟大幅压缩，但实际用户体验的稳定性与发布演示存在落差，本质上仍是"半双工"——你说话时它不能说，它说话时你不能插。真正的拐点发生在 2024 年 9 月，巴黎的非营利研究实验室 Kyutai 开源了 Moshi——首个实时全双工口语大语言模型，理论延迟 160ms、实测 200ms，第一次让"边听边说"在工程上跑通。
二、Moshi 的三大发明：多流建模、内部独白与 Mimi 编解码器
Moshi 的核心贡献不是"把模型做大"，而是重新定义了语音对话的建模方式。它把对话从"轮次拼接"重构为"双流并行生成"。
多流架构：取消"轮次"概念
Moshi 在每个时间步同时建模两条音频 token 流——一条是 Moshi 自己的语音，一条是用户的语音——两流并行进入一个自回归 Transformer。这个设计最反直觉的地方在于：它不再有"轮次"这个概念。模型始终在听、始终在生成（哪怕生成的是沉默），重叠和打断是架构的自然产物，而不是需要特殊处理的边界情况。
内部独白（Inner Monologue）：文本先行的双流生成
Moshi 最聪明的设计是"内部独白"：在生成音频 token 的同时，模型并行预测一条时间对齐的文本 token 流，代表"模型在想什么"。这条文本流有三个作用：
- 语义锚点：文本 token 信息密度高（约 3~4Hz），比音频 token（原始 25Hz）更稠密，用文本作为中间表示可以加速语义推理；
- 降噪参考：音频流在传输中可能有噪声，文本流提供一条"干净"的语义参考，避免模型在生成音频时跑偏；
- 可解释性：模型能边生成语音边维持清晰的语义线索，显著提升生成语音的语言质量，同时也顺带实现了流式 ASR 和 TTS 能力。
训练时，Moshi 对语义 token 的 loss 权重设为 100，其他 RVQ 层为 1，并采用 depthwise 参数化让每个 RVQ 层用独立的权重预测，这两步对语音可懂度的提升最为显著。
Mimi 编解码器：12.5Hz 是全双工的命脉
Moshi 之所以能在消费级 GPU 上实时跑起来，关键是 Mimi 神经音频编解码器：24kHz 音频 → 12.5Hz、1.1kbps 的离散 token，延迟仅 80ms。12.5Hz 这个帧率接近文本 token 的生成速率，直接把时序建模的计算负担降了一个数量级。对比一下：Opus 50Hz/64kbps、EnCodec 75Hz/1.5kbps、SpeechTokenizer 50Hz/4kbps，Mimi 是唯一同时做到低帧率、低码率、流式、带语义建模的方案。
Mimi 的另一个关键设计是分裂式 RVQ：第一个码本通过蒸馏 WavLM 的自监督语义表示来监督，使其同时编码语义和声学信息；剩余 7 个码本走标准残差量化，只监督声学细节。这种"语义-声学分层"的思想，后来在 Lychee-FD 和 Qwen3-Omni 里被进一步发扬光大。
Moshi 的开源意义在于：它是 GPT-4o 语音模式的第一个"开源对版"，让全行业第一次能拆解一个真正的全双工语音大模型。但 Moshi 也有明显短板——上下文窗口只有 5 分钟、没有工具调用能力、需要双流对话数据（极难获取）。这些短板，正是后续工程化的主战场。
三、GPT-Live 的工程化突围：快慢路径解耦、模型热切换与 WARP 协议
2026 年 7 月 8 日，OpenAI 发布 GPT-Live，把全双工语音能力铺给超过 1.5 亿 ChatGPT 语音用户。OpenAI 工程师 Justin Uberti 和 Zahan Malkani 随后公开了完整的系统架构，其工程含量远超模型本身。
取消轮次检测器
GPT-Live 最根本的架构决策是彻底移除传统的轮次检测器。不再用轻量级 helper 模型去猜"用户说完没有"，而是让全双工语音模型持续处理输入音频帧、同时生成语音输出，每秒多次自主决定：继续听、开口、暂停、还是被用户打断后让出轮次。这是把"何时开口"从规则引擎变成了模型的内生能力。
快慢路径解耦：音频快道 + 异步委托道
为了在低延迟音频传输和重计算任务之间不互相阻塞，GPT-Live 把架构解耦为两层，通过异步 RPC 边界连接：
- 音频快道：麦克风音频在客户端和语音模型之间通过专用低延迟连接持续流式传输，这条路径只做一件事——生成实时音频 token，严格保证可预测性；
- 异步委托道：重活——代码执行、网络搜索、多步推理——交给后台模型（目前是 GPT-5.5）处理，不阻塞语音回路。用户问一个复杂问题，GPT-Live 可以立刻用"嗯，让我想想"这种自然填充音先回应，后台并行跑搜索，结果出来后再无缝注入语音会话，不掉帧、不抖动。
这个设计哲学和 GPT-Live 的产品定位高度耦合：语音模型负责"前台接待"，复杂任务交给"后台工人"。
模型热切换：上下文压缩不掉帧
长时间通话有个硬骨头：随着对话推进，token 累积会撑爆上下文窗口。定期压缩上下文能省显存，但压缩会使 KV cache 失效，需要一次昂贵的 prefill，这个 prefill 会冻结语音输出。GPT-Live 的解法是并行模型交接：需要压缩时，后台预热第二个模型实例，用压缩后的上下文 prefill，两实例并行运行；同步完成后，媒体管道无缝热切换到新实例，一帧音频都不丢。
WARP 协议：把 WebRTC 握手从 6 个往返压到 1 个
GPT-Live 的网络层基于 WebRTC——这是实时音视频的工业标准，擅长处理丢包、时钟漂移、网络抖动。但标准 WebRTC 建立安全会话需要最多 6 个网络往返。OpenAI 自研了 WARP（WebRTC Abridged Roundtrip Protocol）：把 DTLS 握手搭载在 ICE 上、采用 DTLS 1.3、预协商 SCTP 和数据通道，把连接序列压缩到单个往返；配合"Instant Connect"提前协商 SDP，客户端可以用单个 UDP 数据包启动会话。WARP 已获 libwebrtc 和 Pion 支持，并提交为 IETF 草案。
还有一个细节值得展开：OpenAI 把媒体前端和推理核心从 Python asyncio 完全重写为 Go，新系统的 p95 帧交付延迟等于旧 Python 基础设施的 p50 延迟——这是把长尾从架构层面消掉的经典操作。
四、字节的两次跃迁：从 Seeduplex 到 SeedRealtime
字节跳动在多模态实时交互上的迭代速度，是国内厂商里最快的。
Seeduplex（2026 年 4 月 9 日）：原生音频全双工
2026 年 4 月，字节发布 Seeduplex 并在豆包 App 全量上线，是业界首个规模化落地的全双工语音大模型。其工程架构披露为"双塔-三流一体化设计"：
- Speech Encoder：基于 1B 参数 Conformer-Lite，16kHz 采样、25ms 帧移，提取 512 维声学表征；
- LLM Backbone：与豆包通用大模型同源的 7B MoE 结构，通过 2kHz 语音 token 与文本 token 对齐；
- 三流并行：听流（输入）、说流（输出，端到端 90ms）、控流（基于 VAD+语义双门控的"可打断决策器"，8ms 内完成打断/恢复判断）。
训练数据是 30 万小时多语种语音 + 200B token 文本，采用课程式预训练（CTC→RNN-T→LLM），引入"语音-文本双向掩码"任务，并用 5 万人类偏好样本做 PPO 微调打断容忍度、语速自适应等 6 类主观指标。A/B 实验显示，用户通话满意度绝对值提升 8.34%，误打断率减半，抢话比例下降 40%。
SeedRealtime（2026 年 8 月 5 日）：音视频全双工
SeedRealtime 是 Seeduplex 的下一步：从纯语音扩到音视频，把音频、视频、文本融进同一个端到端模型。四个月完成这次跨越，背后是三项核心突破：
音视频联合理解——模型把声音、画面、时序深度融合。你说"这个怎么弄"时，它结合当前画面、手势、视线焦点和历史动作判断"这个"指向什么；遇到"bank"这种同音词，靠画面区分是银行还是河岸，而不是瞎猜。这不是"语音识别+图像识别相加"，而是多模态信息在同一模型里交叉校验。
主动交互——模型持续观察环境，在画面状态变化时主动出声。官方演示里，它在博物馆盯着展品，认出指定文物后主动讲解；用户操作咖啡机时，它根据画面变化实时纠错。交互从"你问我答"变成"它也在盯着看"。
流畅节奏——模型实时感知用户对话状态，在合适时机接话、停顿、回应，在嘈杂环境中分辨旁人闲聊与对它说的指令。端到端人工评测显示，相比级联系统，节奏问题减少约一半，抢话、迟滞、误触发显著下降。
值得工程团队注意的是：字节官方没有发布技术报告、没有 arXiv、没有开源权重、没有公开 API，"减少一半"这个数字出自厂商自建人工评测，未披露评测集规模和对照配置。网传的"流畅度提升 37%""机场识别 92%""毫秒级延迟"等数字在官方页面查无出处，选型时建议以自测为准。
五、架构流派横评：四条技术路线的工程取舍
把 2024~2026 年的全双工/多模态语音方案摊开，能看到四条清晰的技术路线。
路线一：流式级联管道（ASR→LLM→TTS + VAD）
生产环境最普遍的方案，延迟可控在 1 秒以内，工具调用支持最成熟，但本质是轮流制，系统必须等用户说完才能处理，全双工无从谈起。代表：早期 ChatGPT 语音模式、多数客服系统。
路线二：Thinker-Talker 解耦（Qwen3-Omni）
阿里 Qwen3-Omni 沿用并升级了 Qwen2.5-Omni 提出的 Thinker-Talker 架构，Thinker 负责文本推理，Talker 负责流式语音生成。2026 年的五大关键升级：
- Thinker 与 Talker 全员 MoE 化——长序列时显著降低 KV cache 的 I/O 消耗，同等硬件下吞吐量更高；
- Talker 与 Thinker 的文本表示解耦——Talker 只以音频和视觉多模态特征为条件，不直接消费 Thinker 的高级文本表示。这让 Talker 更专注提取韵律、音色，对语音翻译（保留说话人原始语气）至关重要；
- AuT 音频编码器——从零训练，2000 万小时监督音频，替换 Whisper，用块状窗口注意力支持实时 prefill 缓存；
- 多码本语音生成——Talker 从单轨升级为多轨 codec 建模，通过 MTP 模块自回归预测多码本层；波形重建用轻量因果 ConvNet 替换分块 DiT，单帧起播；
- 输入/输出音频码率降至 12.5Hz——与 Moshi 的 Mimi 同频，冷启动理论首包延迟 234ms。
Qwen3-Omni 还提出了一个重要论断：无损多模态系统是可以实现的——只要在文本预训练早期就混合单模态和跨模态数据，就能让文本/视觉性能与同等规模单模态模型持平，同时获得音频、视听交互能力。这打破了一直以来"加模态必损单模态"的魔咒。
路线三：原生双流全双工（Moshi、Seeduplex、SeedRealtime）
最激进的路线，彻底取消轮次概念，双流并行建模。理论延迟最低（Moshi 160ms、Seeduplex 90ms 端到端），但工程难度最高——需要双流对话数据、需要解决高并发下的延迟抖动和服务稳定性。字节在技术文档中明确提到：这些在论文里不存在的问题，在数亿用户面前全会出现。
路线四：统一前端 LLM（UAF）
2026 年 4 月的论文 UAF（arXiv:2604.19221）走得更远：用一个 LLM 同时完成 VAD、说话人识别、ASR、轮次检测、问答五个前端任务，重构为一个自回归序列预测问题。基于 Qwen3-Omni-30B-A3B 改编的 Encoder-Projector-LLM 三段式架构，在流式场景下同时输出语音状态和语义内容。这解决了级联架构的三个老问题：错误级联传播、跨任务信息浪费、延迟累积。
Lychee-FD：层次化解耦的科学突破
哈工大张民教授团队与腾讯 PCG 联合的 Lychee-FD 拿下 ACL 2026 杰出论文奖，这篇论文的价值在于揭示了全双工语音大模型"聪明、自然、低时延"长期无法兼得的深层病因：
- 模态干扰：语音生成和语义推理如果挤在同一套深层参数里学习，语音变流畅了，知识却被削弱；语义保住了，实时性又上不去；
- 语义稀释：语音信号频率（约 25Hz）远高于文本语义信号（约 3Hz），传统对齐方式要用大量 padding 补位，文本序列 80% 以上是无意义 padding，稀疏的文本监督被高频声学信号淹没，模型逐渐偏向"复现声音"而削弱语义。
Lychee-FD 的解法是层次化语义-声学建模：浅层共享主干让语音和语义共同学习底层表示；深层拆分为语义、声学、对话控制三个专门通道，各自做最适合自己的事；同时引入"密集语义对齐通道"（内部独白），让模型在生成语音时保留清晰的语义线索。工程上，团队基于 vLLM 定制了实时并行多流推理框架，共享主干计算后把中间表示分发到三通道并行执行，分别管理多流 KV cache，相比基础框架提速 2.96 倍、GPU 显存占用降低 23%；并引入控制头早退策略进一步压缩延迟。在 Spoken QA 上平均提升 7.4%，在 FullDuplexBench 1.5 上平均提升 28.5%。
六、FullDuplexBench：全双工评测的四代演进
没有可复现的基准，全双工就只能停在"演示能跑"的阶段。台湾大学 Hung-yi Lee 团队的 FullDuplex-Bench（FDB） 系列是这一领域的标杆，已经迭代到 v3：
| 版本 | 发布时间 | 核心维度 | 关键贡献 |
|---|---|---|---|
| v1.0 | 2025.03 | 暂停处理、应答词、轮次切换、用户打断 | 首个流式全双工评测基准 |
| v1.5 | 2025.07 | 重叠语音（应答词、旁聊、环境音） | 引入 repair-first vs continuity-first 策略对比 |
| v2.0 | 2026.02 | 多轮、实体追踪、纠正、安全 | 用 GPT-Realtime 当 Examiner，WebRTC 实时编排，LLM-as-judge 自动打分 |
| v3.0 | 2026.04 | 真实人类不流利语音 + 多步工具调用 | 5 类不流利标注（填充词、停顿、犹豫、假启动、自我纠正），4 个任务域的 API 链式调用 |
v3 的设计哲学特别值得展开：它用真实人类录音（非 TTS 合成）+ 5 类不流利标注，测试"Book me a flight um to New York—actually, wait make that Boston"这种中途改意的场景——模型必须丢弃早期目的地、回滚内部状态，再发起正确的 API 调用。21/100 个场景专门测试这种"中途改主意+状态回滚"。这是级联架构根本处理不了的场景。
v3 评测了六个配置——GPT-Realtime、Gemini Live 2.5、Gemini Live 3.1、Grok、Ultravox v0.7、级联管道——结论很有意思：
- GPT-Realtime 准确率最高，打断率最低，Pass@1 达到 0.600；
- Gemini Live 3.1 最快，端到端延迟 4.25 秒，但轮次接管率最低；
- 级联管道保证介入率，但延迟最高；
- 自我纠正处理仍是公认最难——即便 GPT-Realtime，在中途改意场景上的成功率也不到 59%。
NVIDIA 2026 年 1 月开源的 PersonaPlex-7B（基于 Moshi 架构）在 FullDuplexBench 上实现了 100% 的打断处理率，说话人切换延迟仅 70ms——作为对比，Gemini Live 约 1260ms，差了将近 18 倍。这是开源模型在全双工赛道对闭源的一次正面狙击。
七、全双工背后的几条工程暗线
把这些方案放一起看，会发现几条贯穿始终的工程暗线。
暗线一：把"何时开口"从外部规则收进模型内部。 从级联架构的外部 VAD，到 GPT-Live 移除轮次检测器，到 SeedRealtime"不依赖外部 VAD 进行轮次判断"，再到 UAF 把 VAD 内化为序列预测的一个输出——"何时开口"这个决策正在从规则引擎变成模型内生能力。这是全双工与半双工最本质的分野。
暗线二：快慢路径解耦是工业级全双工的标配。 GPT-Live 的音频快道+异步委托道、Seeduplex 的三流并行、Qwen3-Omni 的 Thinker-Talker 解耦、Lychee-FD 的浅层共享+深层分通道——本质都是把"低延迟感知/生成"和"重计算推理"在架构上分开。纯端到端的双流方案理论延迟最低，但工具调用、长上下文管理这些重活必须旁路出去，否则语音回路会被阻塞。
暗线三：编解码器的帧率决定全双工的天花板。 Moshi 的 Mimi 把帧率压到 12.5Hz，Qwen3-Omni 也跟进到 12.5Hz，这不是巧合——帧率越接近文本 token 的生成速率，时序建模的计算负担越低，实时性越好。编解码器不再是"音频处理的前置组件"，而是全双工架构的命脉。
暗线四：双流对话数据是真正的瓶颈。 Moshi 在论文里坦言，多流模型需要成对的双通道对话数据，这极难获取，需要真实对话+合成数据混合。这也是为什么 Seeduplex 强调"300k 小时多语种语音+200B token 文本"的训练规模——全双工不是靠架构创新就能跑通的，数据工程同样是硬门槛。
暗线五：从"能对话"到"能行动"。 GPT-Live 把语音能力与 Codex Agent 工作流深度绑定，让语音从"聊天"升级为"指挥"。SeedRealtime 官方展望"从能对话到能行动"，与 Seed 已有的 GR-RL VLA 机器人线在能力栈上互补——但字节这次发布完全没有把两条线打通或关联，当前形态只是手机 App 内视频通话，不能解读为"具身机器人已落地"。FDB-v3 把多步工具调用纳入评测，正是对这一趋势的回应。
八、对开发者的选型建议与落地展望
基于以上架构横评，给出一份面向工程团队的决策建议。
选型决策表：
| 你的场景 | 推荐路线 | 代表方案 | 关键权衡 |
|---|---|---|---|
| 生产级客服、工具调用密集 | 流式级联管道 | 自研 ASR+LLM+TTS | 延迟可控、工具调用最成熟，但无全双工 |
| 个性化助手、长程对话 | Thinker-Talker MoE | Qwen3-Omni（开源） | 多模态无损、首包 234ms，但需自建推理栈 |
| 实时音视频交互、C 端产品 | 原生双流全双工 | Moshi/Seeduplex/SeedRealtime | 体验最自然，但工程难度最高 |
| 端侧部署、隐私敏感 | 开源全双工小模型 | PersonaPlex-7B、MiniCPM-o 4.5 | 9B 体量可端侧跑，但能力上限受限 |
| 多步语音 Agent、状态回滚 | 快慢路径解耦 | GPT-Live 路线 | 准确率最高，但 API 成本与并发受限 |
几个常被忽视的工程坑：
别把厂商自报数字当圣经。 SeedRealtime 的"节奏问题减少一半"出自厂商自建人工评测，未披露评测集规模；GPT-Realtime 的 Pass@1 0.600 也只在中途改意场景上不到 59% 成功。FDB-v3 的开源框架让你能在自己的数据上跑独立评测，这是唯一可信的选型依据。
全双工 ≠ 适合所有场景。 全双工模型持续运行推理而非按需触发，token 消耗和算力成本远高于半双工。GPT-Live 的定价（音频输入 32 美元/百万 token、输出 64 美元/百万 token）意味着 always-on 部署的成本必须精算——高流量低复杂度场景应该回退到便宜的级联管道。
WebRTC 握手延迟是隐形杀手。 标准 WebRTC 要 6 个网络往返才能建立安全会话，这在移动网络下是用户可感知的卡顿。OpenAI 的 WARP 把它压到 1 个往返，已提交 IETF；自研全双工产品的团队应该关注这个协议，或采用类似的 SDP 预协商策略。
长上下文压缩会冻结语音输出。 KV cache 失效后的 prefill 是语音回路的死敌。GPT-Live 的并行模型热切换是当前最优雅的解法，但工程复杂度高——如果你的产品要支持 30 分钟以上长对话，这是必须提前设计的架构点。
情绪识别 ≠ 情绪运用。 2026 年 6 月一项独立研究发现，多款实时语音模型即使能识别哭泣、恐惧或讽刺，也可能在给建议时忽略这些声音线索——"识别得到，不代表用得上"。把"情绪感知"写进 PRD 时，要清楚这是两个不同的能力层级。
展望未来 12~18 个月，全双工大模型有几个明确的方向值得追踪：
- 多方对话：GPT-Live 已明确把"能跟随并加入 3~4 人对话、追踪谁说了什么"列为下一前沿。这要求模型具备说话人分离+持续身份对应能力，SeedRealtime 的多人场景识别已初探此方向。
- 端侧全双工：MiniCPM-o 4.5 用 9B 体量做到全模态同步交互，INT4 仅需 11GB 显存，语音首包延迟 0.58 秒。端侧全双工不再是遥不可及。
- 从语音到音视频全双工：SeedRealtime 已跨出第一步，但字节官方点名了四个待优化方向——端到端时延、主动感知与决策能力、多人复杂场景理解、工具调用能力。每一个都是独立的工程课题。
- 与 VLA 机器人的打通：SeedRealtime 的持续视觉流理解+主动提醒+时机判断+工具调用，恰好是具身智能体"交互层"的必备件。一旦字节把 SeedRealtime 与 GR-RL VLA 机器人线打通，就是真正的"边看边听边说边做"。
- 欧盟新规的合规冲击：欧盟新规要求 Voice Agent 必须披露 AI 身份、合成语音需支持可识别标记。这会成为所有语音 Agent 产品出海必须处理的设计约束，不是可选项。
九、尾声：交互范式的迁移正在发生
把视野拉远，会发现 2026 年正在发生一次交互范式的根本迁移——从"键盘输入"到"语音交代"。
《金融时报》援引的数据：谷歌 Gemini Live 平均会话时长约为文字会话的 5 倍，OpenAI 每周有超过 1.5 亿人用 ChatGPT 语音，谷歌实时语音使用量一年翻倍。这背后的逻辑是：任务越复杂，语音的价值越大。打字时人会先删掉犹豫和背景，把问题整理成一条看似清楚的指令；说话时，意图、限制条件、拿不准的地方会一起讲出来——语音争取到的不是所有输入，而是复杂任务开始前那段最难说清楚的交代。
全双工是这场迁移的技术地基。没有"边听边说"，语音交互就永远是"下一句命令"的升级版，无法承接一段真实、混乱、带情绪、会中途改意的意图。Moshi 把全双工从理论变成开源现实，GPT-Live 把它铺给 1.5 亿人，SeedRealtime 把它从语音扩到音视频，Qwen3-Omni 证明了多模态可以无损，Lychee-FD 揭示了语义与声学的深层冲突——这些进展共同把"何时开口"这个判断从外部 VAD 收进了模型自己脑子里。
但故事远未结束。自我纠正处理仍是公认最难（GPT-Realtime 不到 59%）、多人对话仍是下一前沿、端侧全双工仍在攻坚、与 VLA 机器人的打通尚未发生。2026 是全双工大模型从"演示能跑"走向"日常能用"的转折年，但"能接住一段意图"只是第一步——接下来还得回答：在什么场合可以开口、在什么噪声里听得清、听到的情绪什么时候该用。这些问题，模型自己给不出答案。
内容由 Qific2.1flash 模型辅助生成
Qific2.1flash 模型是千策人工智能研究院开发的旗舰多模态推理模型。基于 217B 总参数 / 23B 激活参数的稀疏 MoE 架构，原生支持图片和视频理解。