📄 DiffuPlex：用滚动掩码预测减少全双工对话的逐帧计算
英文题目：DiffuPlex: Accelerating Full-Duplex Spoken Dialog Models via Rolling Masked Diffusion
标签：#全双工语音交互 | #语音对话系统 | #扩散模型 | #实时处理
评分：7.1/10 | 创新 1.5/2 | 技术严谨 1.2/1.5 | 实验充分 1.3/1.5 | 清晰度 0.8/1 | 影响力 1/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1/1.5
👥 作者与机构
- Heeseung Kim：Department of Artificial Intelligence；University of Seoul；Seoul, Republic of Korea
📌 核心摘要
全双工语音交互的输入是持续到达的用户音频流，输出是需同步播放的助手音频流，常规做法每80ms交互帧唤醒一次主干做自回归推进，在打断重叠与附和处序列计算压力大。DiffuPlex以历史交互与掩码未来块为输入，经一次主干唤醒同时预测未来一段用户与助手声学码本及文本，输出包含双方内容的未来草稿。置信保留以该草稿为输入，只截取其中置信的连续前缀按原帧率消耗播放，并把对应用户预测存入缓存供后续核对，前缀长度决定单次唤醒推进帧数。随播放到达的真实用户帧与缓存预测逐帧比对，若偏离则保留已播助手内容，只丢弃未播未来并再次唤醒重测，核对结果决定草稿延续或重绘。与沿用自回归主干且跳过计算时以静音代替的延迟执行基线不同，该方法以预测填补唤醒间隔因而在助手发声段也能推进。在Full-Duplex-Bench v1.0评测中，效率指标每唤醒推进帧数cc上DiffuPlex-Speak为2.23，高于自回归personaplex-rl-seamless的1.00。在同一Full-Duplex-Bench v1.0的单张RTX A6000受控推理中，部署链路wall-clock加速比指标上DiffuPlex-Speak相对自回归personaplex-rl-seamless为1.59倍，耗时更少。训练使用四张NVIDIA RTX A6000，助手长语音段的未来声学建模仍不稳定，结论限于已测打断与轮转场景。
🔗 开源与复现资源
第三方资源：https://diffuplex.github.io/ — 链接可访问（HTTP 200）
第三方资源：https://huggingface.co/kyutai/personaplex-rl-seamless — 暂时无法访问
第三方资源：https://huggingface.co/nvidia/personaplex-7b-v1 — 暂时无法访问
第三方资源：https://huggingface.co/kyutai/moshiko-pytorch-bf16 — 暂时无法访问
第三方资源：https://github.com/DanielLin94144/Full-Duplex-Bench — 链接可访问（HTTP 200）
第三方资源：https://huggingface.co/datasets/hlt-lab/voicebench — 暂时无法访问
第三方资源：https://github.com/sarulab-speech/UTMOSv2 — 链接可访问（HTTP 200）
第三方资源：https://developers.openai.com/api/docs/models/gpt-5.6-luna — 链接可访问（HTTP 200）
可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
全双工对话为什么每帧都要算一次
这篇论文处理的是能边听边说的语音对话模型。输入是连续到来的用户音频，输出是需要连续播放的助手音频，目标是在重叠、打断和简短应答都可能发生的条件下维持自然的交互节奏。必须保留的信息包括何时保持沉默、何时给出简短应答、何时接管轮次以及被打断后如何让路并重新回答。论文基于的 personaplex-rl-seamless 以 12.5 Hz 运行，也就是每 80 ms 为一个交互帧，每个帧都要调用 1 次时间主干，同时对用户流和助手流做预测。
这样的细粒度更新能快速响应打断，但代价是整场对话都要维持每 80 ms 1 次的主干前向。论文还引用了一个背景观察：在双人电话对话的大量活跃时间里，只有一方在说话的比例很高，另一侧长期沉默；而且人在说话时会对未来几个词乃至回应做提前规划。这意味着未来若干帧可能是可以一起预测的，不必每帧都重新唤醒主干。理解这一点很关键：后面所有加速都建立在交互帧节拍不变、只是主干唤醒变稀疏的前提上，播放仍然是每 80 ms 1 帧。
已有加速路线为什么不能直接搬过来
相关工作大致有 3 条线。第一条是全双工对话本身，有单流串行和用户助手双流并行两类，Moshi 和 PersonaPlex 属于后者，特点是每步同时更新双通道，交互粒度细但计算密。第二条是自回归生成的推测与并行解码，例如用小模型打草稿再用大模型验证，或者增加预测头 1 次多产几个词，这在文本和部分语音生成里能减少目标模型调用。第 3 条是掩码与块扩散，把逐词生成换成多位置并行预测，也有人把它用作自回归的打草稿器，还有滚动扩散处理时间序列。
论文认为这些路线不能直接解决全双工的困难：文本的推测解码可以用已到来的完整输入去验证草稿，而全双工里验证助手草稿所需要的未来用户语音在预测时刻还没有到来。PredGen 和 RelayS2S 虽然用部分用户语音提前准备回答，但其回答本身仍然是自回归逐帧生成的，只是把计算提前，并没有减少为产生多帧未来交互所需的顺序主干步数。VocalNet-MDM 等语音扩散工作处理的是半双工，远端输出可以依赖已有的输入，而全双工的未来助手帧依赖尚未到来的用户帧。
因此论文把问题定位为联合预测缺失的未来交互，并在用户语音到来后只修正未播放部分，而不是简单跳过计算或用静音填充。
论文要解决的具体计算瓶颈是什么
瓶颈是时间主干的顺序调用次数。基线在每个 80 ms 帧都要做 1 次时间主干前向，深度变换器再在每帧内对音频码本做自回归解码。论文的目标是减少前者，即顺序的时间主干调用，同时不改变输出帧率和实时节拍。输入处理过程是：用户音频经 Mimi 编码进入时间主干，助手文本与助手音频码本由模型生成并送播放队列；用户音频的预测只用于一致性检查，不会被播放。
作用与代价要分开看：减少唤醒次数能省累积计算，但单次唤醒因为要预测更宽的未来块而变贵；消费预测的助手语音能省更多，但远端声学码本缺少同帧语义条件的支撑，可能损失语音自然度。论文用两种推理策略刻画这种取舍：DiffuPlex-Listen 只在预测助手持续沉默时才多消费未来，DiffuPlex-Speak 也允许消费预测出的助手语音。两者共用同一个掩码未来预测器，区别只在保留规则。
一次唤醒管多帧的整体流程是怎样的
整体流程可以按 1 次主干唤醒来理解。模型在当前交互边界上做 1 次前向，1 次产出未来 W 个位置的用户与助手预测，论文主实验取 W=16。接着从中选一个从 h=1 开始的连续前缀保留下来，保留下来的助手帧按原 80 ms 速率播放，期间不再唤醒主干；对应的用户预测被存下来，用于和陆续到来的真实用户帧对照。如果新到用户帧与存储预测不一致，就保留已经播放的助手帧，只丢弃未播放的未来并重新唤醒。
如果一致，就继续播放直到前缀用完再唤醒。论文把这种预测、消费、修正不断向前滚动的过程称为滚动掩码扩散。图 1 把左右两条路线放在同一时间轴上对比，左边每行只落实 1 帧，右边 1 次横向预测覆盖多帧，底部回退只影响未播放部分。
交互帧 × 主干唤醒： 交互帧是每 80 ms 推进一次的用户与助手并行状态，是对话必须按实时节拍播放的单位；主干唤醒是时间主干做一次前向计算的动作。常规模型一帧一唤醒，DiffuPlex 让一次唤醒产出多帧未来，再按 80 ms 节拍慢慢播放，从而把二者解耦。
读图说明：下面这张总览图左侧是常规全双工，右侧是 DiffuPlex，纵轴是毫秒时间，横向方块是交互帧，颜色深浅区分已播放和仅草稿状态，重点看唤醒次数与回退范围的变化。
看图路径： 1. 先看左侧每行只落实一个实心帧，体会一帧一唤醒的节奏；2. 再看右侧一次横向箭头覆盖多个阴影帧，体会一次预测多帧；3. 注意底部红色回退箭头只指向未播放的浅色帧，已播放深色帧不动
论文图 1。原论文 Figure 1:：“Overview of conventional full-duplex generation and DiffuPlex.”。
这张图实际显示左侧每个时刻都有拿笔的机器人表示正在计算，实心帧每次只前进一格；右侧顶部 1 次长箭头对应多个阴影帧，说明 1 次计算管了多帧，底部红色箭头从未来指回当前，表示发现用户变化后只撤销浅色未播放帧，深色已播放帧保持不动。这正好对应后文保留前缀与只改未播放未来的规则。
第二张方法总览把 1 次唤醒拆成预测和消费修正两半，左边是掩码阶梯输入与时间主干 1 次唤醒，右边是置信截断与一致性检查。
看图路径： 1. 在(a) 中沿已实现交互到前瞻 h=1 到 h=4 看 MASK 阶梯如何变密；2. 在(b) 上半部分看 h=4 置信失败如何把保留前缀截断为 r=3；3. 在(b) 下半部分对比 X1 一致继续与 X2 失配触发下一次唤醒
论文图 2。原论文 Figure 2:：“Overview of DiffuPlex. (a) One backbone wake predicts a masked future block with an assistant draft and user predictions.”。
图中(a) 左侧已实现交互之后，h=1 保持原始自回归输入，h 越大越多流被标为 M，输出同时给出助手草稿 A 与用户预测 U；下方训练分支显示干净通路冻结、掩码通路加门控适配并做蒸馏。(b) 上半部分 h=1 恒保留，h=2 和 h=3 打勾而 h=4 失败，于是保留前缀 r=3；下半部分 A1 和 A2 按 80 ms 播放，X1 一致则不唤醒，X2 失配则把旧未来重标为 M 并进入下 1 次唤醒。这说明保留长度由置信决定，而下 1 次唤醒时机由耗尽或修正决定。
掩码未来预测如何补上还没到来的输入
预测未来多帧的难点是远端位置依赖还没生成或还没到达的输入。DiffuPlex 把这些输入替换为按流学习的 MASK 向量。h=1 是普通下 1 帧预测，不做任何掩码；h 越大，被遮蔽的流越多，且保持原生的流延迟结构。论文给出 17 流布局：一个助手文本流、助手 8 个 Mimi 码本、用户 8 个 Mimi 码本。
助手文本、助手 cb0 和用户 cb0 的原生延迟为 0，助手与用户的 cb1 到 cb7 延迟为 1。训练与推理都保留这种延迟，不改变自回归的输入到目标移位。推理时每个唤醒处理一个未来块，深度变换器在每帧内仍对音频码本保持自回归，只是时间维度上 1 次并行产出多个位置。
助手草稿 × 用户预测： 助手草稿是同一未来块中对助手侧文本与音频的预测，用来提前准备可播放内容；用户预测是同一未来块中对用户侧语义的预测，不播放只留作对照。两者在一次唤醒中联合产生，前者决定能省几次计算，后者决定草稿是否还与真实来话一致。
保留规则只看助手文本。每个前瞻位置的置信度定义为采样到的助手文本词在其未加温度与 top-k 前 logits 的 softmax 概率。助手文本状态分为 PAD 表示无词汇词、EPAD 表示词汇生成前的最后一个 PAD、词汇表示真正出词。h=1 恒保留。从 h=2 起按状态与置信度找第一个不满足的位置，把此前连续满足的部分作为候选前缀，公式如下。
\[\tilde{r}=\min\left(\{h\in\{2,\ldots,W\}:s(y_{h})\notin\mathcal{S}\ \lor\ C_{h}<\tau_{\mathrm{conf}}\}\cup\{W+1\}\right)-1.\]该式先扫描 h 从 2 到 W，遇到状态不在允许集合或置信度低于阈值就停下，候选长度为停止位置减一。Listen 的允许集合只有 PAD，Speak 允许 3 种状态全要。接着要求候选长度达到策略最小长度 m 才真正多消费，否则只保留 h=1，公式如下。
\[r=\begin{cases}\tilde{r},&\tilde{r}\geq m,\\ 1,&\text{otherwise},\end{cases}\]主实验 Listen 取 m=6，Speak 取 m=2，置信阈值为 0.80。论文特别说明 Listen 要求较长的 PAD 连续段，是因为短 PAD 可能是语音内停顿而非持续聆听。保留下来的助手帧直接进播放队列，用户预测只存分布不参与播放。下 1 次唤醒时，已收到的用户帧和已播放的助手帧会替代原来的预测位置，与新掩码未来一起做 1 次前向。
置信保留 × 用户感知修正： 置信保留是按助手文本采样概率和 PAD/EPAD/词汇状态决定能连续拿走多长前缀，管的是提前消费的激进程度；用户感知修正是拿新到用户帧与存储的用户预测做比较，决定是否丢弃未播放未来，管的是发现偏离后的纠错。保留决定省多少，修正决定错了能否只改未播放部分。
修正规则在不唤醒主干的情况下比较存储预测与新到用户帧。记新到用户语义词为 xh，存储的用户分布为 qh，采样的助手文本词为 yh 及其存储分布为 Ph，有效替代词集合为 Ah，阈值为 τrev，主实验取 -0.5，触发条件如下。
\[-\log q_{h}(x_{h})+\log P_{h}(\mathcal{A}_{h}(y_{h}))-\log P_{h}(y_{h})\geq\tau_{\mathrm{rev}}.\]第一项是新到用户词在存储预测下的负对数似然，越意外越大；后两项是助手对已选词相对有效替代的犹豫程度，越不确定越容易修正。论文在附录把该式解释为保持与修正两种假设的近似后验对数比，其中未来修正后的用户似然用与位置无关的常数代替，其常数偏移被吸收进阈值。若不触发则继续播放，若触发则丢弃未播放未来，已播放音频永不修改。
冻结主干时未来路径学的是什么监督
训练的目标是让掩码路径模仿冻结的干净自回归教师。论文冻结原始主干，只训练按流的 MASK 向量和只在 h≥2 启用的未来门控低秩适配，门控同样作用于解码音频码本的深度变换器。这样 h=1 走原始通路，h≥2 走学到的未来通路。为了模拟推理时每次唤醒之间推进帧数可变，训练把对话切成长度在 1 到 W 均匀采样的连续块，每块起点 h 重计为 1；并把干净拷贝与掩码拷贝拼成 2T 序列，掩码块只以其块边界之前的干净上下文为条件，块内因果注意，不跨掩码块延续。
掩码输入 × 未来门控适配： 掩码输入是用可学习的 MASK 向量替换尚不可用的未来输入，让模型在缺少远端上下文时也能做前向；未来门控适配是只在前瞻 h≥2 时启用的低秩适配参数。掩码解决输入缺失问题，门控保证 h=1 仍走原始自回归通路，二者组合才实现冻结主干而只学未来路径。
下面训练布局图把这种拼接与分块画得很具体，横轴是时间位置，纵轴是 17 个流，橙色斜线是 MASK，重点看不同流在不同 h 开始被遮蔽。
看图路径： 1. 先看左侧干净拷贝与右侧掩码拷贝拼成 2T 序列的结构；2. 再看掩码区按块长 3、5、4 切分且每块 h 从 1 重计；3. 对照右侧 MASK 阈值看助手侧与用户侧在不同 h 开始被遮蔽
论文图 4。原论文 Figure 4:：“Training sequence layout for masked future prediction.”。
图中左侧是 T 个位置的干净拷贝，右侧是 T 个位置的掩码拷贝，掩码对话区被切成块长 3、5、4 的示例块，每块 h 从 1 重计。右侧标注显示助手全部流从 h≥2 被遮蔽，用户 cb0 从 h≥3，用户 cb1 到 cb7 从 h≥4，底部图例说明 Δ 原生延迟不变，阶梯表示输入可用性而非注意力掩码，时间注意仍是因果的。这与正文掩码时间表一致。监督是蒸馏损失：对有效文本位置同时匹配完整文本分布与按 PAD、EPAD、词汇分组的三态分布，对音频按语义码本权重 1、声学码本权重 0.02 加权匹配。
论文说三态蒸馏是为了保留何时沉默、何时开口等粗粒度交互状态。训练数据是 Seamless Interaction 双人面对面交互，保留 42313 个会话约 2728.5 小时，优化 526 步，有效批量 32，最大窗口约 163.8s。需要指出原文没有报告拿掉蒸馏后必然怎样的因果结论，相关消融只在附录给出具体数值对比。
实验在什么数据与计时条件下比较
评估分 4 条线。全双工交互用 Full-Duplex-Bench v1.0 的 727 个片段，覆盖暂停处理、简短应答、平滑轮转和用户打断，还在 v1.5 的重叠与干扰语音下做配对评估；用户波形经 Mimi 流式输入，助手自由生成，轮转率、延迟、简短应答频率与时机分布、打断回答恰当性都用官方脚本计算，打断评分用 gpt-5.6-luna 在关闭推理 effort 下打分。通用语音能力用 VoiceBench 与 OpenAudioBench 的单轮协议，指令播放时助手强制静音，播完后自由生成，分别评助手文本流和生成语音转写后的分数。
人工评价在 MTurk 上做，自然度只听打断后的助手回答，对话分听完整交互并只评打断处理与衔接，要求每段完整播放并设注意力检查。计时用固定的 60 片段子集在单张 RTX A6000 上测，区分部署路径的流式墙钟、端到端 GPU 与语言模型核心 3 段时间，加速比都相对自回归 personaplex-rl-seamless，唤醒帧延迟单独同步测量并报告 99 分位与超过 80 ms 的比例。基线包括 Moshi、PersonaPlex、自回归主干，以及 3 种只延迟执行不预测未来的训练无关基线：PAD、Silero 和 Smart Turn，它们在跳过的帧固定输出静音，最长延迟由 R 控制。
省了多少次唤醒而交互行为变化多大
主结果要同时看推进帧数与行为指标。论文报告在完整评测上 Listen 与 Speak 平均每次唤醒推进 1.91 与 2.23 帧，而自回归基线为 1，说明唤醒频率大约降到一半左右。暂停、轮转与打断等指标与主干接近，配对显著性在 Holm 校正后 20 项比较均未检出显著差异，论文明确说这只是未发现差异证据，不能当作等价证明。人工评价显示 Listen 的语音自然度与对话分与主干基本持平，Speak 保持对话分但自然度下降。下面的表把推进帧数与人工评价放在一起，方向是推进越高越好，自然度与对话分越高越好。
该表比较同一预测器下两种保留策略相对自回归主干的变化，公平条件是相同提示、采样与种子，指标方向为每唤醒帧数越高越省，自然度与对话分越高越好，最后一列为语音自然度变化。
| 系统 | 每唤醒推进帧数 | 语音自然度 | 对话分 | 语音自然度变化 |
|---|---|---|---|---|
| personaplex-rl-seamless | 1.00 | 3.93 | 4.09 | 基线 |
| DiffuPlex-Listen | 1.91 | 3.92 | 4.08 | 基本持平 |
| DiffuPlex-Speak | 2.23 | 3.54 | 4.07 | 自然度下降 |
Listen 把唤醒次数省下一半左右而人工两项分数几乎不动，Speak 再多省约 0.3 帧但自然度从 3.93 降到 3.54，接近 Moshi 的 3.52 水平，而对话分仍在 4.07 附近。这说明保守消费沉默未来代价小，激进消费语音未来要用自然度换推进数；该表只覆盖 v1.0 与人工子集，重叠语音下的行为需看 v1.5 配对分析，不能推广到所有噪声条件。
每唤醒推进帧数 × 核心语言模型耗时： 每唤醒推进帧数是总交互帧除以总主干唤醒次数，衡量调用频率降了多少；核心语言模型耗时是语言模型核心累积的 GPU 执行时间，衡量真正省了多少计算。前者高不自动等于后者省，因为 DiffuPlex 单次唤醒要算更宽的未来块，必须同时看两者才能判断摊薄是否划算。
累积耗时真的下降了吗单次唤醒贵多少
推进帧数高不等于总耗时降，因为单次唤醒算了更宽的块。论文在 60 片段计时子集上报告 Listen 与 Speak 分别为 1.98 与 2.26 帧每次唤醒，核心语言模型累积时间从 656.8s 降到 408.4s 与 365.5s，对应 1.608 倍与 1.797 倍加速；部署路径墙钟加速为 1.455 倍与 1.590 倍，端到端 GPU 加速为 1.458 倍与 1.593 倍。按唤醒次数折算，单次核心耗时是基线的 1.23 倍与 1.26 倍，说明省的是调用次数而非单次成本。实时性方面，唤醒帧 99 分位为 61.34 ms 与 61.41 ms，没有超过 80 ms 的实测唤醒帧，因此仍能维持 12.5 Hz 节拍。下面的表把累积耗时、加速比与尾延迟放在一起，时间越低越好，加速比越高越好。
该表在固定 60 片段与同一 GPU 计时路径下比较累积耗时与单次唤醒代价，时间越低越好，加速比越高越好，尾延迟用来判断是否满足 80 ms 实时约束。
| 系统 | 核心语言模型累积时间 | 核心加速比 | 部署墙钟加速比 | 唤醒帧 99 分位延迟 |
|---|---|---|---|---|
| DiffuPlex-Listen | 408.4s | 1.608 倍 | 1.455 倍 | 61.34 ms |
| DiffuPlex-Speak | 365.5s | 1.797 倍 | 1.590 倍 | 61.41 ms |
主要收益是累积核心时间下降约 248s 与 291s，墙钟也同步下降；具体代价是单次唤醒更贵且 99 分位从 46.85 ms 升到 61 ms 量级，但仍在 80 ms 内。论文强调满足截止只是可行性，累积 GPU 时间的下降才是长时间交互的意义；该结论依赖所测硬件与软件栈，换环境数值会变，未测的长尾与首帧建图开销也不在这组数字里。
只跳过计算而不预测未来会怎样
为了证明预测本身有价值，论文构造了只延迟执行、用静音填充跳过帧的基线。R 越大允许连续跳过越多，墙钟加速越高，但交互行为退化越重。给出的例子是 R=6 时 PAD 达到 2.05 倍墙钟加速，但简短应答频率从 0.163 降到 0.048，轮转延迟从 0.124s 升到 0.423s。相比之下 DiffuPlex 在 1.455 倍与 1.590 倍墙钟加速下更接近原始的应答、轮转与说话占比。下面的表把这种用静音换加速与用预测换加速放在同一语境下，墙钟加速越高越好，但应答频率与延迟有明确方向。
该表比较不预测未来的延迟执行与预测未来的 DiffuPlex，条件是同一冻结主干与同一评测，墙钟加速越高越好，简短应答频率越高越好，轮转延迟越低越好。
| 系统 | 墙钟加速比 | 简短应答频率 | 轮转延迟 | 行为代价 |
|---|---|---|---|---|
| PAD 在 R=6 | 2.05 倍 | 0.048 | 0.423s | 应答被抑制 |
| DiffuPlex-Listen | 1.455 倍 | 行为接近基线 | 行为接近基线 | 行为接近基线 |
| DiffuPlex-Speak | 1.590 倍 | 行为接近基线 | 行为接近基线 | 行为接近基线 |
延迟基线能刷出更高的原始加速数字，但代价是助手在跳过段被迫沉默，抑制了本该出现的简短应答并推迟轮转；DiffuPlex 加速数字低一些，但因为预测了唤醒之间的交互而保留了行为。这组对比不支持只看加速比选模型，也提醒控制器本身的 CPU 开销在主计时里被排除，Smart Turn 每交互秒约 13.90 ms 的 CPU 成本需另计。
置信与修正各自管住什么样的激进消费
消融显示保留与修正是互补的。去掉置信后 Listen 从 1.91 升到 2.11 而行为变化不大，因为仍受 PAD 与最小长度约束；Speak 从 2.23 升到 2.80 但打断评分从 4.357 降到 3.550，说明对语音未来放开置信会明显伤及回答恰当性。去掉修正后 Listen 升到 2.49、Speak 升到 3.08，但简短应答频率掉到 0.078 与 0.080，轮转延迟升到 0.440s 与 0.480s，说明只保留不修正会失去对新来用户语音的响应。下面的表把这两组干预的推进数与响应性放在一起，推进越高越省，评分越高越好，延迟越低越好。
该表在 Full-Duplex-Bench v1.0 上仅展示去掉修正干预，推进帧数越高越省，打断评分越高越好，轮转延迟越低越好，用来分离修正的作用；去掉置信的结果只在正文叙述而不入表。
| 策略与干预 | 每唤醒推进帧数 | 打断评分 | 简短应答频率 | 轮转延迟 |
|---|---|---|---|---|
| 无修正 Listen | 2.49 | 4.372 | 0.078 | 0.440s |
| 无修正 Speak | 3.08 | 4.251 | 0.080 | 0.480s |
主要结论是保留约束限制激进消费，修正保障响应性；反例是无修正虽然推进最高但轮转与应答明显变差，不能只看推进数。论文还报告唤醒终止原因：修正触发的唤醒平均已消费 4.24 与 3.79 帧，而耗尽型唤醒多为只保留 1 帧，说明短间隔多因保守保留而非长草稿被秒撤回。状态级无操作修正率 Listen 为 92.4%、Speak 为 82.5%，多数修正不改变近 320 ms 内的交互状态，但仍是防止不一致草稿的安全阀。
同交互下两种策略的差异可用下面这张 rollout 图直观理解，横轴是时间，每列 80 ms，蓝色是已听帧，深蓝是主干通过，斜线是起草后被撤销。
看图路径： 1. 看同一红色虚线边界处 h=2 已是词汇而非静音；2. 对比上方 Speak 一次拿走 9 帧与下方 Listen 只拿 1 帧；3. 注意斜线 revoked 帧都是未播放部分，已播放 Uh huh 不动
论文图 10。原论文 Figure 10:：“Different retention policies on the same interaction.”。
图中红色虚线边界处下 1 帧已是词汇而非静音，Speak 保留 16 帧并实际消费 9 帧后才修正，Listen 因只允许 PAD 而只保留自回归的 1 帧。下方标注说明同一草稿与置信下，Speak 1 次送出 9 帧而 Listen 只送 1 帧。这解释了 Speak 推进更高但也更容易触及语音建模短板的原因，限制条件是该例子为单样本展示，不能当作平均推进的证明。
语音未来变差与缺失的同帧语义条件有关吗
论文把 Speak 的自然度损失归因到声学码本缺少同帧语义条件。基线里助手 cb0 相对 cb1 到 cb7 有一步原生延迟，预测某物理帧的 cb1 到 cb7 时该帧 cb0 已作为时间主干输入；但在 h≥2 的掩码未来里同帧 cb0 也被遮蔽，声学码本只能在缺语义条件下预测。干预实验在 199 个有效打断样本上把被遮的同帧 cb0 换回真值再顺序生成 cb1 到 cb7，语音段负对数似然下降 0.0912，静音段只降 0.0285，而换回助手文本反而变化 -0.0176，说明效应特异于语义音频信号。进一步把 Speak 输出的文本与 cb0 固定、用原始自回归路径只重生成 cb1 到 cb7，UTMOSv2 从 2.646 升到 2.894。
只固定文本而重生成 cb0 到 cb7 得 2.903，完全自回归为 2.919，因此大部分可测损失在声学条件恢复后即被找回。这些重放只是诊断分析，不是推理的新阶段。局限是它们用了真值或逐帧重算，实际部署时未来 cb0 本来就没有，不能直接当作实用解法，论文也明确说需要更好的未来音频建模才能像消费静音段那样可靠地消费长语音段。
哪些结论是有边界的还有什么没测
有几处边界需要先讲清。训练是冻结主干加门控适配的自蒸馏，不是为掩码未来从零训练的模型，附录显示去掉未来门控会改变 h=1 通路并影响轮转行为；换到 PersonaPlex 主干仍能省唤醒但暂停与打断行为明显变差，说明迁移不是自动的。推理的保留与修正是基于固定阈值的规则，没有与预测器联合学习；W 从 8 到 32 的训练与推理错配实验显示实际消费量变化不大，说明最大前瞻不等于实际用量，提大 W 还会增加单次成本。
通用能力上 Listen 在 VoiceBench 与 OpenAudioBench 基本持平，Speak 在语音到语音的最大降幅出现在 OpenAudioBench，但变化分散在多任务而非单一类别。v1.5 显示打断响应率三者接近，但用户简短应答场景下 DiffuPlex 恢复原回答更多、新回答更少，谈话与背景音条件变化混杂。统计上校正后无显著差异不等于等价，语音特征的前后变化只在系统内检验，没有检验变化幅度在系统间是否显著。未评测的范围包括其他全双工架构、其他部署环境与更长的连续交互，墙钟与核心加速都依赖实测栈。
要复现第一步做什么需要哪些信息条件
复现先从自回归边界校验做起：设 W=1 关闭未来预测，在相同启动、流式用户编码、采样与种子下对比滚动实现与官方逐帧路径的词序列，论文说两者应一致，这是检验掩码拼接与延迟对齐是否正确的最低门槛。接着固定主超参数 W=16、置信阈值 0.80、修正阈值 -0.5，Listen 最小长度 6、Speak 最小长度 2，采样用助手音频温度 0.8 与 top-k250、助手文本温度 0.7 与 top-k25，种子 0，语音启动用 SC0001.wav 加静音与系统提示。
训练需 Seamless Interaction 双通道时序保留的预处理，包括重采样、转写、强制对齐、语音检测与 Mimi 编码，以及按阈值过滤麦克风泄漏与低语音密度会话；只更新流特异 MASK 与门控低秩适配，主干冻结。计时要复用固定的 60 片段子集与单卡空闲节点，区分墙钟、端到端 GPU 与核心 3 条路径，控制器决策预计算重放以免污染 GPU 计时。代码开源、权重可下载、系统可运行是三件不同的事：论文只给出演示页链接并计划评审后发布实现与评测脚本，不能写成作者资源已公开或可一键运行。
什么时候值得尝试还缺哪项验证
如果场景里助手长期处于聆听、打断频繁但每次需要快速让路，且每 80 ms 1 次的主干调用已成为瓶颈，Listen 这类只消费沉默未来的保守策略值得先试，因为它在论文条件下省约一半唤醒而人工两项分数基本不动，且尾延迟仍在 80 ms 内。如果助手需要连续讲长语音且对自然度敏感，Speak 目前是用自然度换推进数，论文的声学条件分析表明缺同帧 cb0 是一个可解释的来源，但还没有实用的未来音频建模方案，此时不宜直接部署。
还缺的验证包括在新主干与新硬件上的重复计时、在更长与更嘈杂交互中的行为保持，以及把保留与修正阈值做联合学习或自适应调整后再看效率与交互的权衡。容易产生的误解是把每唤醒帧数当成加速比本身：单次唤醒更贵，只有累积核心与墙钟同时下降才算省；另一个误解是把延迟基线的高加速当成更优：那些数字来自静音填充，代价是应答与轮转行为，论文的对比恰好说明预测唤醒之间发生了什么才是关键。
📎 论文与评分元数据
排名：前50% | 文档类型：方法研究 | arXiv 原文
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
评分规则：type-aware-v1
评分模型：muse-spark-1.3-contributor
评分请求协议：openai_responses