Mechanism-level survey · 2026.07

GPT-LIVE 实时语音交互背后的端到端双全工语音模型技术路线调研报告

围绕数据、训练与交互机制，梳理五条可能路线。重点不是猜测闭源模型，而是回答：真正的双全工需要什么信息流、数据字段和训练信号？

L1 · OpenAI 直接训练证据：缺失L2 · 产品/API 行为边界L3 · 相邻公开系统证据L4 · 研究者复现设计
01 / QUICK READ

五分钟速读

最稳妥的结论不是“GPT-LIVE 使用了某种架构”，而是从公开系统中确定一组可复现的机制设计空间。

0

可核查的 L1 训练披露

当前材料不能确认 GPT-LIVE 的 codec、token、双流结构、损失函数或训练阶段。

4

最小功能部分

流式表示、联合生成、floor-control、部署前的后训练与对齐共同形成体验，但它们不是四个串联网络层。

5

公开候选路线

从 Moshi 式双流，到低资源 Speech Encoder + LLM，再到 codec-free 与状态空间流式方案。

3

复现成熟度

低资源 S2S、事件增强 S2S、研究级双流 full-duplex，应分阶段验证且分别声明能力边界。

一句话边界：OpenAI 的实时产品行为只能说明“系统能做什么”，不能说明“内部如何训练”；Moshi 等系统说明公开机制可行，也不能反推 GPT-LIVE。
02 / EVIDENCE

证据边界：四个等级不能混写

L1 · 直接事实

GPT-LIVE 官方训练证据

要求官方论文、系统卡或技术报告直接披露训练机制。当前调研中此类证据为零。

L2 · 行为边界

OpenAI 产品与 API

能证明低延迟语音、打断等外显能力或工程接口；不能证明模型使用双流、Mimi、SNAC 或 Fisher 微调。

L3 · 公开机制

相邻论文与代码

Moshi、DuplexChat、AudioLM、LLaMA-Omni 等支持具体机制事实，但事实只属于对应系统。

L4 · 设计推断

公开条件下复现路线

把 L3 机制组合成训练方案，并明确哪些能力可验证、哪些仍不能声称。

03 / TERMS

先拆开四个常被粘在一起的词

端到端

训练端到端、推理端到端、表示端到端和产品链路端到端不是同一件事。用户直接说话并听到回复，不足以证明训练主路径没有文本瓶颈或外部模块。

实时

实时描述延迟和增量处理，不自动意味着系统能在输出期间持续消费用户语音。

双全工

需要输入与输出并行，并能表达 overlap、barge-in、backchannel、silence/hold 与中断恢复；“UI 可打断”不是充分训练证据。

Speech-to-Speech

可包含 codec tokens、speech embeddings、text tokens 或 inner monologue。S2S 不等于纯语音语义通路。

04 / MECHANISM

双全工的核心：生成什么，与何时生成

运行时主链完成语音理解与生成；floor-control 并行决定说、听、保持、让行和短反馈；后训练只在部署前塑造模型与策略。

端到端双全工语音系统的通用功能抽象
图 1｜gpt-image-2 生成后经机制审校。它补齐流式解码器，并将后训练画成部署前影响，而非推理节点。概念示意，非 GPT-LIVE 内部架构。
流式表示Waveform → Codec tokens / Embeddings
联合生成Speech + Text + Audio context
音频解码Tokens → Streaming waveform
Floor-controlSpeak / Listen / Hold / Yield
部署前对齐Safety / Style / Latency
05 / INTERACTION

双全工不是“更快的 S2S”

模型必须持续生成时间步上的语音或沉默，同时让用户流在助手发声时继续进入系统。

Moshi 式用户流与助手流同步时间轴
图 2｜基于 Moshi 等公开系统的机制示意。Backchannel 与 Repair 的具体标签在公开证据中仍弱，图中仅作交互事件抽象。
Overlap两条音频流在同一时间区间都有有效信号。
Barge-in用户在助手尚未完成输出时改变其行为。
Backchannel短反馈不夺取主话轮。
Silence / Hold“不说”也是需要学习的动作。
Repair / Restart停止、回滚、改写或恢复被打断计划。
Self-listening输出时继续监听，需要处理回声与自身语音。
06 / DATA

数据能表达什么，模型才可能学会什么

研究级 full-duplex 最小数据字段

字段用途缺失后果
user_audio + assistant_audio说话人分离的同步双流无法可靠学习并行听说
start_ms / end_ms毫秒级时序与事件对齐无法训练 overlap 与接话时机
overlap / barge_in重叠与打断监督只能靠偶然模式学习
backchannel / silence_hold短反馈和主动沉默容易抢话或对沉默处理僵硬
codec_token_span音频 token 与事件时间轴对齐辅助目标难以落到正确区间
floor_control_actionlisten / speak / hold / yield / repair没有显式交互策略监督

低资源 S2S 的可执行格式

source_wav、source_text、target_token、target_text 足以建立 speech input → speech output 闭环，但通常没有双说话人同步流和交互事件，因此只能作为半双工或弱双工近似。

07 / TRAINING

训练不是一步到位，而是能力逐层注入

01 / FOUNDATION

基座与表示

文本 LM 或 speech-text backbone；训练流式 codec / speech encoder；混合文本、语音或音频 token 预训练。

02 / DUPLEX

多流与自然对话

基于 diarization 构造 simulated multi-stream，再用 Fisher 或自然双人对话学习 overlap、interruptions 与 turn-taking。

03 / ALIGNMENT

交互脚本与偏好

合成交互脚本覆盖稀有事件；再对抢话、延迟、礼貌、安全和风格做偏好或策略对齐。

Moshi 的公开锚点：无监督预训练 → 基于 diarization 的 simulated multi-stream post-training → Fisher full-duplex fine-tuning → synthetic interaction scripts instruction fine-tuning。该流程属于 Moshi，不是 OpenAI 训练披露。
08 / ROUTES

五条公开技术路线

它们不是互斥“门派”：一个系统可能同时使用 codec tokens、inner monologue、speech encoder 和独立 floor-control。

五条公开技术路线的定性二维地图
图 3｜横轴为双全工交互保真度，纵轴为公开复现难度。位置是研究归纳，不是统一 benchmark 排名；个别系统的 full-duplex 属性只在其公开声明范围内成立。

A · Codec-token 双流 AR

用户流与助手流联合自回归，配合 delay pattern 和 speech-or-silence token。机制最接近真双全工，数据与算力门槛最高。

B · Speech-text Interleaving

用文本或语义单元支撑长程语义，再生成声学表示。语言能力强，但 floor-control 仍取决于双流时序数据。

C · Encoder + LLM + Decoder

开源代码与数据格式最清楚，适合作为短期 baseline；通常不具备完整 timing policy。

D · Codec-free Embedding

连续表示避免离散 codec 的部分量化限制，但公开训练细节较少，暂不适合第一复现路线。

E · Duplex / State-space

聚焦增量状态更新、解码效率和长流式上下文；公开证据更偏 streaming 或 speech-to-text。

09 / COMPARISON

横向比较：先看训练信号，再看模型名字

ID路线代表系统表示 / 时间展开Floor-control复现难度证据边界
ACodec-token 双流自回归MoshiCodec tokens；显式双流高最高L3 强；映射 GPT-LIVE 仅 L4
BSpeech-text Interleaving / Inner MonologueMoshi、Spirit LM、AudioPaLMSpeech units + Text + Audio tokens取决于是否双流高L3 中—强
CSpeech Encoder + LLM + Speech DecoderLLaMA-Omni、Mini-Omni、SLAM-OmniSpeech embeddings + Target tokens通常较弱中L3 中—强；full-duplex 推断弱
DCodec-free / Embedding Full-duplexSALMONN-omniContinuous speech embeddings公开主张较强高L3 中；细节不足
EDuplex Decoding / 状态空间流式DuplexMambaFrames / Hidden states偏流式解码中—高L3 中；与 S2S 距离较远
选择顺序：先问是否必须持续同时听说；再问数据是否有同步双流与事件标签；然后确定是否必须生成可观察语音；最后才选择 codec、embedding、Transformer 或状态空间骨干。
10 / REPRODUCTION

复现路线：三阶段，不越级声称

从低资源 S2S 到研究级双流的复现路线
图 4｜阶段 1 图内“不可声称能力：半双工 / 弱双工”措辞应读作“仅能验证半双工 / 弱双工，不能声称自然全双工”；正文在此作明确校正。
SHORT TERM

低资源 S2S

验证：语音输入到语音输出闭环。
不能声称：持续监听、overlap policy 或自然全双工。

MID TERM

事件增强 S2S

新增：双说话人时间轴、事件标签和 floor-control action。
验证：事件分类和条件响应。

LONG TERM

研究级双流

新增：流式 codec、多流 AR、delay pattern、自然对话与合成脚本。
不能声称：等同 GPT-LIVE 产品体验。

11 / LIMITS

局限、争议与公开未知

  • 闭源内部未知：GPT-LIVE 是否使用离散 codec、连续 embedding、inner monologue、双流 AR 或独立 floor-control，均无 L1 训练证据。
  • 产品行为存在替代解释：低延迟、可打断和自然语音也可能由混合模块或产品层控制实现。
  • 数据比骨干更关键：没有 speaker-separated timing 与事件标签，换成更大模型也不等于学会双全工策略。
  • 公开损失不完整：部分系统只披露主任务或摘要级能力，不能把合理辅助损失写成论文事实。
  • 图像是解释性重绘：本页四图由 gpt-image-2 生成并经机制审校，不是论文原图，也不是任何公司的内部文档。
12 / SOURCES

主要公开来源

以下链接用于身份核查与机制追溯。具体 claim 仍应回到论文正文、技术报告或代码。

  1. Moshi: a speech-text foundation model for real-time dialogue
  2. Kyutai Moshi 开源项目
  3. Spirit LM: Interleaved Spoken and Written Language Model
  4. AudioLM: a Language Modeling Approach to Audio Generation
  5. AudioPaLM: A Large Language Model That Can Speak and Listen
  6. SpeechGPT: Intrinsic Cross-Modal Conversational Abilities
  7. Mini-Omni: Hear, Talk While Thinking in Streaming
  8. LLaMA-Omni: Seamless Speech Interaction with LLMs
  9. SALMONN-omni: Codec-free Full-duplex Speech
  10. DuplexMamba: Duplex and Streaming Speech Conversations
  11. Full-Duplex-Bench v1.5
  12. DuplexChat: Speaker-Separated Full-Duplex Dialogue Speech
  13. SLAM-LLM 开源框架
  14. OpenAI Realtime Console（仅作产品/API 边界证据）
报告生成说明：正文基于 2026-07-15 的本地调研材料整理；四张解释图由 Hermes 配置的 gpt-image-2（provider: glink）生成。发布日期：2026-07-17。