语音双工系统的
架构、时延与评测

段数、原生语音与双工分别描述什么

这里按推理时的信息流区分三段式、两段式和原生 S2S。两段式在业界存在不同用法，本页采用“语音理解模型输出回答文本，再接语音合成”的工作定义。带 Thinker、Talker 和共享隐藏状态的模型单列为混合设计。

ASR 或 STT 表示语音识别，LLM 表示语言模型，TTS 表示语音合成。S2S 表示从语音输入到语音输出，codec 是声音的编解码器。

DuplexCascade 把流式 ASR、文本 LLM 和流式 TTS 用微轮次连接，提供了级联全双工的研究实例。段数与双工能力因此需要分别记录。语音编码器、codec 和波形解码器也可以存在于端到端模型中，直接清点模块数容易得到含混分类。[2]

主要指标围绕完整交互组织

主指标负责回答“系统有没有把事情做好”，诊断指标负责定位问题发生在哪个环节。每项统计都需要固定起止事件、分母、超时规则和系统边界。

P50 为中位数，P95 表示 95% 样本不超过的值。Pass@1 是一次尝试的成功率。 WER、CER 分别衡量词和字的识别错误，MOS 是主观质量评分的均值。

Full-Duplex-Bench v1.5 把重叠场景分成打断、附和、旁人对话和背景语音，并测量行为及停止、重入时间。这组情境适合构成交互测试的基础。[10]

160 ms 是怎样的一段时间

Higgs 把连续媒体和工作流按 160 ms 时间片组织。模型读入当前片段，再生成下一片段的输出，思考和工具调用可以跨多个片段持续。这种设计定义了更新节奏。用户端时延还涉及采集、计算、决策、网络和播放。[1]

每块都要在 160 ms 内算完吗

对单会话、串行关键阶段，要持续按 160 ms 推进，就需要及时产出每个下一块。长期平均计算耗时低于 160 ms 是基本条件，还需要给抖动留余量，关注尾延迟、超期比例和缓冲。多阶段流水线可以把吞吐摊开计算，关键路径上的固定延迟仍然存在。

用一个简化的单工作者模型说明。当 Δ = 160 ms、C = 80 ms，计算有余量。当 C = 220 ms，每处理一个新块，等待队列便增加约 60 ms。Higgs 博客没有披露单步耗时的 P50 / P95 或超期比例，无法据分块长度确认其实际计算分布。

分块越短，交互会怎样变化

事件发生在一个时间片内部时，模型需要等到该事件进入可用输入。事件均匀落在固定边界之间、并且必须等整块时，残余等待平均约 Δ/2，最大接近 Δ。实际系统还受编码器前视和接收策略影响。

缩短 Δ 可以更频繁地更新感知，也会增加调用、调度和控制开销，并改变每步可用的信息量。MiniCPM-o 4.5 的作者比较了 1.0 s、0.2 s、0.1 s，在其模型和训练设置下选择 1.0 s 作为折中。时间片大小要和训练方式、语义稳定性一起评估。[6]

时间数据来源 Higgs、TML、Moshi、MiniCPM-o、Qwen3-Omni。

用户听到回答的时间取决于关键路径

流式系统会把部分识别、理解与生成提前到用户仍在说话时。核算时只计事件发生后尚未完成的部分，并保留阶段重叠。首次开口、给出有效内容、完成工具动作和停止播放，分别使用自己的起止事件。

声音已经生成后，还可能在网络或播放器中排队。Google 的 Live API 指南明确要求收到打断事件时清空待播音频。客户端缓冲因此会影响用户感知的停止时延。[14]

用代表实现建立架构地图

下面以公开结构或接口描述定位代表路线。闭源模型的内部模块、实际训练数据和服务调度仍有未知项。版本明确的论文适合解释机制，当前系统选型需要固定具体模型 ID 再测。

同场数据怎样揭示不同取舍

Full-Duplex-Bench v3 的 2026 年 4 月 v1 研究，用 100 条真人录音、12 名说话者，在统一 LiveKit 框架与本地 mock 工具下比较多种配置。下面保留其中四项，展示三类信息流的系统表现。这组结果属于该版本和样本的评测快照。[11]

Pass@1 沿用作者报告，核心要求工具选择与参数正确，论文另报回答质量和应答率，完整通过判据披露有限。较早开口、关键回答起始和正确完成任务需要分别评价。论文将 Ultravox 广义归入 S2S，本页依据其公开核心的音频到文本结构作两段式定位，TTS 适配的披露有限。系统级差异需要结合模型能力、话轮和部署配置解释。

GPT-Live-1 的补充数据

GPT-Live-1 已有官方评测和第三方时延数据。下表按来源、后台配置与统计口径分开列出。FDB-v1 轮替、FDB-v3 工具任务、受控录音与电话链路各自描述不同的工作条件。

本次所查资料尚缺 GPT-Live-1 在原图同一统计口径下的首音均值与关键回答起始均值，因此原表保留空缺。 0.798、1.210 和 2.27 秒各有独立条件，不能合并成一个统一时延排名。

Higgs 的论证如何组织

Higgs 以自然交互、智能和成本组织设计。其前台模型按时间片持续接收信息，自己思考、调工具，并按需委派后台。博客用交互、问答与任务等多组成绩呈现取舍，FDB v1.5 得分 75.5、τ-Voice 69.8，同表仍有更高配置。[1]

这种比较方法可以转化为评测纪律。每个系统都交代任务范围、完整模型配置、时间预算和成本边界。Demo 解释机制，测试集衡量覆盖，配对消融说明改善来自哪项设计。

前台和后台的分工尤其影响解读。TML 的表格注明，部分推理与工具成绩启用了后台代理。比较“模型能力”与“整机能力”时，应分别报告前台独立配置和完整系统配置。MoE 总参数量、音频 token 速率、后台调用和实际价格也需要分别记录。[7]

全双工如何进入架构与训练

全双工涉及三项设计。输入在输出期间怎样持续进入，听与说怎样按时间对齐，模型怎样学习何时继续、停下或行动。下列组织方式可以组合使用。

基于语言模型继续预训练，具体改了什么

文本模型已学会知识、推理和语言生成。语音系统在此基础上接入声音表示，使语音特征能进入骨干，并让生成端输出语音 token 或驱动专用语音头。训练时加入文本与声音对应关系、语音连续性，以及带时间的交互轨迹。

骨干可以继续做统一序列预测，音频编码器和波形解码器按各自目标训练。不同项目会选择冻结已有组件、先训新增模块，再逐步联合训练，或始终保留冻结的语言骨干。

1. 01

   建立声音表示与模态对齐

   利用语音、转写与配对数据，把音频特征映射到语言表示，训练语音生成模块。编码帧率与压缩影响计算预算和声学信息。

2. 02

   混合继续预训练

   混合文本、音频与可选视频数据，学习跨模态预测并保留语言能力。知识问答和文本能力需要在语音训练前后配对评估。

3. 03

   按时间训练双工行为

   把双声道、静默、停顿、附和、重叠和改口保留在时间轴上。训练中限制未来信息访问，让输出只依赖当时已到达的输入。

4. 04

   交互微调与强化学习

   监督微调（SFT）示范合适动作，强化学习（RL） 可依据正确答案、指令遵循、行动效果或交互行为优化。具体采用哪些奖励，需要逐模型查证。

5. 05

   蒸馏与仿真迭代

   部分系统把专长教师的能力蒸馏到交互模型，并从仿真失败中合成训练数据。模拟器的说话时机、工具返回和噪声会影响学到的行为。

语音转写和音质测试覆盖了模态能力的一部分。持续双工还需要验证新输入能否改变当前生成与后续行动，尤其是模型已经开始回答、工具仍在执行时的参数修正。

怎样证明自己的系统更好

先确定目标场景及成功条件，再比较质量、交互、时延和成本的共同边界。可以把通过任务正确、交互规则和时间门槛的对话记为“有效完成”，并同时报告各原始指标，保留失败原因。

这是可选的项目级验收口径，需要预先确定门槛与超时规则。有效完成数为零时，成本指标记录为不可用并保留完整支出。

从评测标准推导可视化

先写清楚怎样判定系统好，再确定需要采集哪些事件，最后选择图形。交互时机、任务完成与效率、时间、成本构成评价主线。模块活跃与工具异步轨迹用来解释这些结果。

结果层回答是否达到门槛，诊断层解释因果链，展示层帮助读者理解过程。单次回放、两配置配对与样本集聚合使用相同事件定义。图中的“计算请求在途”按观测事件标记，内部思考状态需要对应的公开事件才能呈现。

先把测试条件固定

• 固定模型 ID、服务版本、系统提示、工具和后台模型，记录推理预算与委派次数。
• 使用相同输入和设备条件，按实际时间流入音频，在系统实际播放时触发重叠事件。
• 同时记录客户端采集、发送、服务计算、工具、返回与实际播放，标明时钟对齐误差。
• 无响应和超时保留在成功率分母中，时延分布同时标注完成覆盖率。
• 按对话配对比较，多次重复并按会话聚类计算置信区间，避免把一个长对话的多个片段当作独立样本。
• 在相同成本或质量门槛下比较配置，另做前台独立与整机两套结果。

最小情境集覆盖八类问题

可先用少量案例核验采集与评分，再扩充独立测试集。样本量应由要检测的差异与置信度确定。开发案例、公开基准和最终保留测试集分别维护。

基准各自承担一个判断任务

用消融解释改进来源

一次只改变一项设计，比较提前处理开关、双工话轮控制、后台委派、播放器缓冲等设置。对时间片大小的实验，需要使用模型支持且训练条件相容的配置。若骨干、数据和服务都不同，证据支持的是整机配置之间的差异。

发布结果时给出四组图。任务成功率与有效答案时延的配置曲线，真打断检出与误打断的权衡，质量及时延门槛下的成本和并发，典型成功及失败对话的因果时间线。每个更优结论都应附带适用场景与代价。