听、写、说三通道并行：LWS 如何释放语音模型里被封印的文本能力

论文： Liberating LLM Capabilities in Full-Duplex Speech Models
作者： Luoyuan Zhang, Bokai Xu, Junbo Cui, Weiyue Sun, Yingjing Xu, Hanyu Liu, Yuan Yao
链接： https://arxiv.org/abs/2606.07547
项目页： https://royalzhang.com/project/lws-page/

一句话总结

LWS（Listen-Write-Speak）把"可见文本"从语音模型的幕后搬到台前，用纯特殊token实现三通道并行，让全双工语音模型第一次同时做到：边听边想、边想边说、边写代码边聊天。

问题：语音模型为何"不会写代码"？

GPT-4o、Moshi、Mini-Omni 这些语音模型已经很厉害了，但有一个隐形的牢笼——它们只能输出语音。

当你问它"帮我写个Python脚本"，它的回答是一段口语化的描述，而不是可复制的代码块。当你问"分析一下这个表格"，它只能口头总结，无法输出 Markdown 表格让你直接粘贴。

为什么？ 因为现有语音模型把文本当作"隐藏中间状态"（hidden intermediate），语音才是最终输出。LLM 原生擅长的代码生成、结构化推理、多步推导——这些需要"可见文本"才能充分释放的能力——被语音这个输出通道给闷住了。

这就像让一位数学家在黑板上做题，但规定他只能用口头报答案，不能写出推导过程。

LWS 的核心设计：文本是第一类公民

LWS 提出了Listen-Write-Speak三通道交互范式：

关键突破：Visible Writing 不是语音的附庸，而是独立的第一类输出通道。 用户随时可以看到模型在思考什么、推导到哪一步了。

纯 Token 实现：不改模型，只加特殊符号

最精彩的是，LWS 不需要对标准 Transformer 做任何结构修改。

它只用一套特殊 token 来划分三通道行为：

<unit> [音频token] <|lc|> [思考文本] <|/lc|> </unit>        ← 监听单元
<unit> [音频token] <|spk|> [语音token] <|eos|> <|rc|> [回应文本] <|/rc|> </unit>  ← 回应单元

为什么分 ls_cogn 和 reply_cogn？ 因为两个阶段的信息状态不同——监听阶段只能看到已输入的音频历史；回应阶段还能看到模型自己生成的语音内容。分离后降低条件熵，避免全双工中的信息泄露（附录有 Jensen 不等式证明）。

两阶段数据流水线：解决"没有标注数据"的困境

全双工语音模型最大的训练瓶颈是：没有逐秒标注的认知数据。

LWS 的解法很聪明：

第一阶段：离线认知合成

• 用强教师模型（Qwen3-235B）从标准文本QA对生成三股文本流：
  1. 流式推理链 → 监督 ls_cogn（边听边想）
  2. 语音回应 → 口语化改写，监督 speak
  3. 原始结构化回答 → 监督 reply_cogn

第二阶段：在线时间线构建

• 将三股流与真实录音结合，用 CTC 做字符级时间对齐
• 构建全局逐秒时间线，插入随机静音间隔
• 对一部分数据做打断增强，训练重叠/接管能力

最终数据集：50万条中英双语训练样本。

实验结果：四张成绩单

1️⃣ URO-Bench（语音理解与推理）

LWS 在中文专业级（84.6）和英文专业级（78.0）均大幅领先，尤其在中文理解（92.5）和推理（85.9）上表现突出。两个消融实验（去掉边听边写 / 去掉边说边写）均全面低于完整模型，验证了双通道可见文本的必要性。

2️⃣ VoiceBench AlpacaEval（回复质量）

仅落后 GPT-4o-Audio 0.06 分，在所有开源基线中排名第一。这说明可见文本通道的质量可以逼近甚至追平顶级商业模型。

3️⃣ 写说一致性（Channel Consistency）

92.6%（589/636 样本）——语音回答与文本回答在事实上保持一致。这消除了一个关键顾虑：双通道输出会不会自相矛盾？答案是：不会，至少 92.6% 的情况下不会。

4️⃣ Full-Duplex-Bench（全双工交互）

LWS 在停顿处理（TOR 0.01）和打断质量（4.02）上达到或超过 GPT-Realtime，而打断延迟仅 0.65 秒，比 GPT-Realtime 的 1.50 秒快了一倍多。

能力矩阵：为什么 LWS 是唯一的"四边形战士"？

论文把现有范式按四个核心能力做了全景对比：

LWS 是唯一同时覆盖四项能力的系统。

工程细节：为什么它能跑得快？

• 音频编码：Streaming Whisper Medium，10 token/秒，stride 5，流式处理不等待整段说完
• LLM：MiniCPM-V + Qwen3-8B，只微调 LLM，音频编码器和 TTS 冻结
• TTS：LLaMA-based + FlashAttention + S3Tokenizer，独立线程运行
• 推理：异步三进程架构（音频编码 → LLM生成 → TTS合成），语音合成在 speak token 产生后立即启动
• 打断：无需外部 VAD，模型自己从音频 token 判断何时被打断

启发：从"语音模型"到"语音界面"

LWS 的真正意义不是做了一个更好的语音模型，而是重新定义了"语音模型"的角色——

语音不是目的地，而是接口。LLM 的文本能力才是内核。

当语音模型可以边听边写代码、边说边输出表格、被打断后立刻从文本上下文恢复——它就从"语音助手"进化成了"带语音功能的 LLM"。

这也解释了为什么 GPT-4o 的实时语音能力那么强：它本质上就是在 GPT-4 的文本能力上套了一个语音管道。LWS 用开源路线证明了，这种"文本优先"的设计可以走得通，而且走得很好。

一句话收尾

如果说 Moshi 证明了语音模型可以全双工，LWS 证明了全双工语音模型可以写代码。

这是语音交互从"玩具"走向"工具"的关键一步。

参考论文

• Zhang et al., "Liberating LLM Capabilities in Full-Duplex Speech Models", arXiv:2606.07547, 2026
• 项目主页：https://royalzhang.com/project/lws-page/

#AI #大语言模型 #语音交互 #全双工 #LLM #多模态AI #语音模型 #开源