实时交互模型火了：全双工如何让AI边听边说

实时交互模型火了全双工如何让AI边听边说一、概念澄清实时交互模型不是又一个语音助手二、三代演进从级联流水线到全双工三、全双工怎么工作以 Thinking Machines 为例四、OpenAI 的两条腿Realtime API 与原生语音五、开源格局谁能本地跑全双工六、落地判断Voice Agent 的门槛在哪七、冷静视角三个还没解决的硬伤总结2026年10月13日机器之心发布了 iRTE 2026 实时智能大会的议程其中 10 月 23 日下午的「对话式 AI 技术专场」把主题直接定为「互动即智能对话式 AI 与交互模型」。这份阵容里OpenAI、Thinking Machines Lab 等团队被点名为「把注意力从更拟人的语音回答转向 AI 如何真正参与一场实时互动」的代表。换句话说过去一年语音模型的战场正从「说话像人」悄悄挪到「互动像人」。这篇文章想讲清一件事实时交互模型到底是什么、它和此前的语音助手差在哪、以及为什么 2026 年突然成了产业议题。一、概念澄清实时交互模型不是又一个语音助手最容易混淆的是把「实时交互模型」当成「语音助手升级版」。两者关心的事情不一样传统语音助手关心「你说完我答得准不准」实时交互模型关心「对话进行到一半我能不能边听你说话、边想、边插话、边调工具」。厘清这点的关键是认出三种被统称为「语音 AI」的东西其实是三档不同的范式。第一档是级联流水线语音活动检测VAD判断你停没停自动语音识别ASR转文字大语言模型LLM生成回复文本转语音TTS念出来——四棒接力。第二档是端到端全模态Omni用单一模型直接听音频、想回复、说出来把三段合一但多数仍假设「轮流说话」靠静音判断轮次。第三档才是全双工 / 交互式模型边听边说同时处理输入与输出每秒做很多次「该说、该听、该停、该打断、还是该调工具」的决策彻底取消了「轮流」这个假设。给个直观判断一个能让你在它说到一半时打断、它立刻改口甚至和你同时开口做实时翻译的系统才是全双工仅仅是「语音进去、语音出来」的多半还停在 Omni 甚至级联。把这三档分清后面所有讨论才有锚点。图一级联流水线靠 VAD 切轮次全双工直接消解轮次本身二、三代演进从级联流水线到全双工把时间轴拉直能看清这条线的推进节奏。2024 年下半年Kyutai 开源的 Moshi 是真正的先声它用双流架构同时建模「用户说的话」和「自己要说的话」配合自研的 Mimi 神经编解码器把全双工从论文概念变成可跑的开源模型。同年 10 月OpenAI 推出 Realtime API把 GPT-4o 的原生语音能力用 WebSocket 暴露给开发者语音助手不用再自己拼接 ASR、LLM、TTS 三件套。到 2025 年 8 月 28 日Realtime API 转正式可用GA。2026 年 2 月面壁智能发布 MiniCPM-o 4.5把「原生全双工」压进 9B 参数、跑在端侧证明全双工不一定要云端巨模。5 月由前 OpenAI CTO 米拉·穆拉蒂创立的 Thinking Machines Lab 发布「交互模型」interaction models把这套思路工程化、产品化。再到 10 月iRTE 2026 把「实时交互模型」单独拎成专场——从研究概念到产业议题前后不过两年。图二全双工从研究概念走向产业议题仅用两年这条主线背后是同一个执念怎么摆脱「轮流说话」这个假设以及怎么摆脱 VAD 对轮次的猜测。级联和 Omni 都还依赖 VAD 划分轮次常用 500–800ms 静音阈值——你停顿半秒以上才被判定「说完了」只有全双工彻底消解了轮次本身。三种范式不是简单的新旧替代而是在不同延迟与成本约束下的设计取舍2026 年的生产系统里它们会长期并存。三、全双工怎么工作以 Thinking Machines 为例全双工最值得看的工程样本是 Thinking Machines Lab 今年 5 月发布的 TML-Interaction-Small。它用一个 2760 亿参数的混合专家模型每次激活约 120 亿以 200 毫秒为单位的「微轮次」工作音频、视频以小块持续流入模型同时生成自己的音频、文本与工具调用不再等用户说完。它的核心设计是把系统拆成两个协作模型。前端是交互模型负责实时感知与响应维持和用户的同步后端是后台模型异步承担深度推理、工具调用和长周期任务结果以流式回灌进实时对话。这种「快慢分工」带来了几个以前流水线难以表达的行为能在恰当时机插话、能和你说着话同时去搜索或生成界面、能直接感知时间流逝。举个具体场景你正说「帮我查这周五的天气顺带订个餐厅」前端模型先开口「好的我来看一下」同时把「查天气 订餐厅」交给后台你话音未落改了主意「算了餐厅别订了」前端在下一帧约 200ms 内就捕获到这个转向立刻中止自己正在生成的语音、收回后台那个还没发出的订餐调用——你感觉不到它在「听完一整句再反应」。这种「说到一半随时改、工具随时收」的灵活度正是前台微轮次与后台异步协作共同换来的级联流水线因为要等整段 ASR 结果才动天然做不到。图三交互模型维持前台同步后台模型异步干活共享一份对话上下文和这条云端巨模路线对照面壁智能今年 2 月的 MiniCPM-o 4.5 走了端侧全双工9B 参数、端到端全模态把音视频切成极小切片做脉冲式处理让模型在说话的同时继续看和听。它说明全双工不必绑云端大集群端侧也能跑出近似真人的节奏对隐私与离线更友好代价是端侧算力限制了任务复杂度。按该团队公布的数字在 FD-bench V1 的轮次延迟上它做到 0.40 秒对比 GPT-Realtime-2 的 1.18 秒FD-bench V1.5 的交互质量 77.8 对 46.8在它自己新造的「时间感知 / 插话时机」类基准上TimeSpeak 64.7 对 4.3、CueSpeak 81.7 对 2.9领先更夸张因为它的对手在这些维度上几乎为零。不过这些基准都来自团队自身且模型目前只给少量研究预览伙伴未公开。它自己也承认几个边界连续音视频会让上下文快速膨胀长会话管理仍是开放问题强依赖网络弱网下体验骤降更大的版本目前还跑不进实时。读这些数字合格的姿态是「方向可信、数值待独立复现」。四、OpenAI 的两条腿Realtime API 与原生语音OpenAI 在这条线上走的是「先把原生语音能力做成可用基础设施」的路线。Realtime API 的本质是用一个持久的 WebSocket 连接把语音直接喂给 GPT-4o、再把语音直接流回来省掉了 STT→LLM→TTS 的拼接与逐跳延迟。它支持自动中断你说一半它 Detect 到声音就停、函数调用语音助手能真的下单或查信息以及后来升级的语义级 VAD——不再只看静音而是用分类器判断你是「说完了」还是「在思考中停顿」减少误打断。需要厘清的是定位GPT-4o Realtime 是原生语音单模型处理音频比级联先进但它仍偏「轮次式」——更接近 Omni 那一档而非 Moshi / TML 那种边听边说的全双工。它的价值在于给开发者一套稳的生产接口而不是把交互范式推到极致。价格上音频输入每百万 token 100 美元、输出 200 美元折算约每分钟输入 0.06 美元、输出 0.24 美元对高频语音场景不算便宜。想现在就试最省事的是接 OpenAI Realtime API——它是公开可用、带文档的入口配一个 API Key 和稳定网络就能起一个实时语音会话骨架见下。更想本地可控、不把音频出域可以选 Moshi 这类开源全双工模型用 PyTorch / MLX 在本地跑约 6GB 显存int4即可代价是交互质量不如接了前沿后端的商业方案。两条路对应两种诉求要快上手用云端 API要数据主权走本地开源。把「轮次式」和「全双工」的体感摊开讲用 Realtime API 这类轮次式方案模型底层仍在生成「一整轮」回复只是你开口时被 VAD 或语义 VAD 检测到、中途掐断——它停得及时但逻辑还是「先有完整轮次、再被打断」。全双工不是这样它压根没在生成「一整轮」而是每 200ms 重新决定「这一帧该说一个词、该听、还是该停」你打断只是让它下一帧改了主意。前者像「写到一半的稿子被划掉」后者像「本来就是边想边说改念头不需要撕稿」。这层差别很微妙却是全双工体验「更像人」的根源。# 环境pip install openai需设置 OPENAI_API_KEY 与稳定网络# 极简实时语音会话骨架基于 OpenAI Realtime API音频采集/播放细节省略importasyncio,openaiasyncdefmain():clientopenai.AsyncOpenAI()# 读取环境变量 OPENAI_API_KEYasyncwithclient.beta.realtime.connect(modelgpt-4o-realtime-preview)assession:awaitsession.send({type:session.update,session:{instructions:你是一个中文实时语音助手},})# 实际使用时持续以 input_audio_buffer.append 推麦克风音频# 播放 response.output_audio.delta 返回的音频流即可print(实时会话已建立可开始语音对话)asyncio.run(main())把 OpenAI 和 Thinking Machines 放一起看会发现一个共同趋势把「实时交互」和「深度思考」解耦。简单问答由前台模型低延迟兜底遇到要搜、要算、要调工具的重活交给后台前沿模型前台继续维持对话。这种「快慢分工」正成为 2026 年实时交互模型的主流骨架。五、开源格局谁能本地跑全双工如果你不想被云厂商绑定开源侧目前能选什么结论是全双工的开源权重依然稀缺半双工和轻量级选择更丰富。图四开源语音模型从全双工到轻量三档生产级全双工仍只有 MoshiMoshiKyutai是迄今唯一从零为全双工设计的开源模型7B 级参数、双流架构、配合 Mimi 编解码器实测约 200 毫秒延迟Apache-2.0 / CC-BY 协议适合研究和原型。阿里 Qwen2.5 / Qwen3-Omni 是端到端全模态支持音视频输入但属于半双工更像「Omni 多模态」而非原生全双工胜在生产可用、社区活跃。Mini-Omni2Snakers4用 0.5–7B 的参数、MIT 协议做到部分双工适合资源受限的端侧部署代价是对话智能相对有限。据开源社区 2026 年初的梳理真正全双工的开源权重基本只有 Moshi绝大多数本地语音应用仍跑级联方案——想本地体验全双工Moshi 几乎是唯一现成的选择。不过 Moshi 的本地体验有前提它依赖 Mimi 编解码器在 12.5Hz 的帧率上做流式编解码对 CPU / GPU 的实时性要求不低普通笔记本要在 int4 量化下才能稳住约 200ms 的端到端延迟一旦宿主机器负载高、缓冲区抖动延迟就会掉进「明显能感觉到在等」的区间。换句话说开源全双工现在「能跑」和「跑得稳」之间还差一层工程打磨这也是它更多出现在研究和原型里、而非大规模生产流量的原因。六、落地判断Voice Agent 的门槛在哪聊完技术落到最实在的现在做 Voice Agent 到底卡在哪。从 iRTE 2026 的阵容能看出产业侧在攻哪些点——美团在推 VoiceAgentEval 基准加强化学习优化阶跃星辰讲下一代交互模型Soul 做面向实时交互的语音合成Loxi-Speech声网主攻多模态与实时语音通信底座亮源新创、BreezeBlue AI 等也在语音与产品一线。国内 Kimi、MiniMax、面壁、生数等公司也会在大会带来 Voice Agent 相关分享场景覆盖客服、硬件、社交、教育。但工程门槛是硬约束。一条经验基准是对话要自然用户停说后到听到首字节的延迟得压在 700 毫秒以内超过 1200 毫秒就明显觉慢超过 2000 毫秒放弃率陡增。级联方案即便调优总延迟也常在 360–1330 毫秒区间瓶颈多在 LLM 的首 token 延迟全双工模型因持续运行首音频可以在你还没说完时就冒头理论上限更好但部署对硬件和流式缓冲管理要求高。再叠加长会话的上下文膨胀、弱网下的体验塌方、以及「设备分不清背景音和有意输入」的隐私难题Voice Agent 离「随处可跑」还有距离。对开发者来说务实的做法是轻量场景先用级联求稳强交互场景才上全双工并且把长会话的上下文裁剪和网络容错当成一等公民来设计。七、冷静视角三个还没解决的硬伤一篇合格的资讯文得和厂商叙事拉开距离。实时交互模型至少有三个硬伤现在还无法回避。其一长会话的上下文膨胀。全双工持续吞入音频与视频上下文比文本对话膨胀得快得多很长一段对话后如何不丢关键信息、不爆显存仍是开放问题。这也是为什么 TML 这类系统更适合中短交互超长会话的工程方案还没成熟。其二评测标准缺失。什么是「好的实时交互」没有共识指标于是各家自己造基准TML 造了 TimeSpeak、CueSpeakOpenAI 有 FD-bench。基准不同数字之间没法直接比所谓「领先」要先问「按谁的尺子」。在第三方给出可复用的交互质量评测之前单看厂商自报分数容易高估。其三实时执行的边界与隐私。全双工系统被设计成「能随时插话、随时调工具」这天然比问答机器人更接近「替你动手」。与此同时它持续监听环境音频设备很难可靠区分孩子路过时的无意背景音和有意输入——这种误读不只是体验问题更是数据合规的雷区。在把这类模型接进邮件、支付、日历之前这条边界比跑分更该先被评估。把三点说在前面不是唱衰而是把「厂商承诺」和「已验证事实」隔开全双工在交互自然度上确实比级联、Omni 进了一步但「进可乱真」目前还停在研究和预览阶段。总结实时交互模型全双工是 2026 年语音 AI 最清晰的一条主线它不再满足于「说话像人」而是要让 AI 在对话进行中边听、边想、边说、边调工具。技术上Moshi 证明了全双工可开源、Thinking Machines 用 276B MoE 加「快慢分工」把它工程化、面壁把它压到端侧 9BOpenAI 则先把它做成稳定可用的 Realtime API。对开发者务实路线是轻量用级联、强交互上全双工且把长会话上下文与网络容错当成一等公民开源侧目前能本地跑全双工的几乎只有 Moshi。下一步最该盯的是第三方能否给出统一的「交互质量」评测——那才是判断这场「边听边说」热潮是真突破还是新叙事的关键。