现在的全双工语音模型有个尴尬:一边要听,一边要说,两边抢同一块 GPU。可当模型在「听」用户说话时,算力其实在空转——论文实测,监听块(chunk)有 70% 到 89% 的时长纯粹用来等下一段音频。反过来,一旦要说话或调工具,串行生成又会把 deadline 顶穿:每个被评测的工具调用都超时,LWS 模型的 95% 说话块也超时。
论文的解法有点反直觉:既然等音频的时候闲着,不如先把下一块的输出猜出来。
静音假设:两个观察
作者先做了个预言实验:同一段上下文,分别喂真实音频和一段等长静音,看输出差多少。四个模型汇总下来,两个结论很稳:95.3% 的块里,静音猜出来的输出和真实音频逐 token 相同;真出现分歧的块里,87.7% 的分歧发生在第一个输出 token——也就是模型决定「继续听」还是「开口说话」的那一刻。
三个组件
Speculative Listening 是免训练且无损的:不改权重,输出分布与自回归解码严格一致。
第一,静音假设起草。空闲窗口里,模型假设下一段是静音,直接贪心解码出一份草稿。
第二,跨块假设池。草稿按 N-gram 索引跨块保留。用户请求往往横跨好几块,前面攒下的草稿已经包含最终工具调用的大部分内容。
第三,runner-up 分支。从概率第二高的首 token 再起一条草稿,专门接住「在第一个 token 就分叉」的情况。
音频到达后,一次前向传播同时完成音频 prefill 和草稿验证,后续计算量只跟真正变了的 token 数量成正比。
消融实验最能说明问题
在 Streaming SLM 上,只加静音起草:说话块提速 2.6 到 2.9 倍,工具调用只有 1.2 到 1.4 倍——几十个 token 的调用根本写不完一个空闲窗口。再加假设池,工具调用从 1.42 倍跳到 22.04 倍。最后加 runner-up 分支,推到 23.41 倍。
也就是说,大部分收益不来自「猜得更准」,而来自「跨块攒草稿」。
数字和代价
在 760 段会话、15883 个块的 TickTock-Bench 上,四个模型(Streaming SLM、Gander、Realtime-Venus、LWS):说话块平均快 2.6 到 2.8 倍,工具调用最高 23.41 倍(Gander 上是 3.45 倍)。对照的三个免训练基线 PLD、Token Recycling、Lookahead 只有 0.96 到 1.23 倍。开口延迟平均砍掉 73%,降到 74 到 241 毫秒,已经贴上人类对话约 200 毫秒的接话间隔;最大落后实时时间平均减少 94.4%。质量侧,AlpacaEval 评分与自回归解码的差异不到 0.1 分。
代价也很直白:这是低并发、延迟敏感的部署方案。并发从 1 涨到 4,工具调用加速比从 22.7 倍掉到 10.5 倍。论文自己也承认只测了 Thinker 没测 Talker,以及并行流架构(每 80 毫秒一帧那种)不适用。
我的看法
这几年投机解码的论文都在卷「同一个模型内还能不能再快一点」,这篇换了维度:不是把已有的空闲算力榨干,而是问「这段空闲算力本来该干什么」。全双工语音是少数天然有大量空闲窗口的负载——用户不说话的每一毫秒,GPU 都在干等。把「等输入」从损耗变成资源,在我看来比任何单点 kernel 优化都更值钱。
这也留下一个问题:如果闲时算力这么值钱,为什么不是所有语音模型厂商都这么做?答案大概是:改 runtime 比改模型贵,论文能出彩,产品未必愿意动。