流式语音到语音:Moshi 与 Hibiki 的全双工对话

流式语音到语音:Moshi 与 Hibiki 的全双工对话

本节摘要:2024-2026 年重新定义了语音 AI。Moshi 用单个模型在 200 毫秒延迟下同时听与说,Hibiki 逐块做语音到语音翻译——两者都抛弃了 ASR → LLM → TTS 的级联流水线,改用基于 Mimi 编解码 token 的统一全双工架构。这是新的参考设计。本节聚焦一个根本问题:第 11、12 节搭出的语音 agent 都有一个 300~500 毫秒的延迟地板(VAD 触发 → STT 处理 → LLM 推理 → TTS 生成),每级都有自己的最小延迟,流水线形状本身就把你封顶了。Moshi(Kyutai, 2024-2026)问了一个不同的问题:如果没有流水线呢?如果一个模型直接吃音频、吐音频,持续不断,文本只是中间的「内心独白」而非必经阶段?答案就是全双工语音到语音:理论延迟 160 毫秒(80 毫秒 Mimi 帧 + 80 毫秒声学延迟),单 L4 GPU 上实测 200 毫秒——是顶级流水线语音 agent 的一半。本节将拆解 Moshi 的双 Mimi 流 + 内心独白文本架构、深度 Transformer 的码本间依赖建模、Hibiki 的流式翻译、Sesame CSM 这位「表亲」,以及 Moshi 赢在哪里、输在哪里。读完本节,你能判断何时该用全双工架构、何时该坚持级联流水线,并理解为什么 2026 年多数企业生产仍然后者。

学习目标

阅读完本节,你应当能够:

1. 解释级联流水线的延迟地板(VAD+STT+LLM+TTS 各有最小延迟,形状本身封顶),并理解全双工架构如何绕开它。
2. 描述 Moshi 的双流架构:用户音频流 + Moshi 自身音频流 + 内心独白文本流,三者并行,12.5 Hz × 8 码本。
3. 理解深度 Transformer 如何在一个 80 毫秒帧内顺序预测 8 个码本(码本间依赖),以及它与 VALL-E、VibeVoice 的共同范式。
4. 说明 Hibiki 流式语音到语音翻译 与 Hibiki-Zero(免对齐数据 + GRPO 强化学习)的工作原理。
5. 对比 Moshi、Hibiki、Sesame CSM、GPT-4o Realtime、Gemini 2.5 Live,知道 Moshi 赢在哪里、输在哪里,以及为什么企业生产 2026 年仍多坚持流水线。

一、问题与直觉

第 11、12 节搭出的每个语音 agent 都有一个约 300~500 毫秒的根本延迟地板:VAD 触发、STT 处理、LLM 推理、TTS 生成。每级都有自己的最小延迟,你可以调优与并行,但流水线形状把你封顶。

Moshi(Kyutai, 2024-2026)问了一个不同的问题:如果没有流水线呢?如果一个模型直接吃音频、吐音频,持续不断,文本只是中间的「内心独白」而非必经阶段?

答案就是全双工语音到语音。理论延迟 160 毫秒(80 毫秒 Mimi 帧 + 80 毫秒声学延迟)。单 L4 GPU 上实测 200 毫秒。这是顶级流水线语音 agent 的一半。

Moshi 架构

输入:两条 Mimi 编解码流,都是 12.5 Hz × 8 码本:

• 流 1:用户音频(Mimi 编码,持续到达)
• 流 2:Moshi 自身音频(Moshi 生成)

Transformer:一个 7B 参数的时序 Transformer 同时处理两条流加一条文本「内心独白」流。在每个 80 毫秒步,它:

1. 消费最新的用户 Mimi token(8 码本)。
2. 消费最近的 Moshi Mimi token(8 码本,如已生成)。
3. 生成下一个 Moshi 文本 token(内心独白)。
4. 经一个小型深度 Transformer 生成下一个 Moshi Mimi token(8 码本)。

三条流——用户音频、Moshi 音频、Moshi 文本——并行运行。Moshi 能边说边听用户;能在用户打断时打断自己;能不打断主话语地发回「嗯哼」之类的反向频道。

深度 Transformer:在一帧内,8 个码本不是并行预测的——它们有码本间依赖。一个小型 2 层「深度 Transformer」在 80 毫秒内顺序预测它们。这是 AR 编解码 LM 的标准因子分解(VALL-E、VibeVoice 也用)。

为什么内心独白文本有帮助

没有显式文本,模型不得不在声学流里隐式建模语言。Moshi 的洞见:强迫它在音频之外同时吐文本 token。文本流本质上是 Moshi 所说内容的转录。这提升了语义连贯性,让语言模型头更容易替换,还白送你转录。

Hibiki:流式语音到语音翻译

同样的架构,在翻译对上训练。源音频进,目标语种音频出,持续不断。Hibiki-Zero(2026 年 2 月)消除了对词级对齐训练数据的需求——用句级数据 + GRPO 强化学习优化延迟。初始支持四个语种对;用约 1000 小时可适配到新语种。

更广的 Kyutai 技术栈(2026)

• Moshi——全双工对话(法语优先,英语支持良好)
• Hibiki / Hibiki-Zero——同声语音翻译
• Kyutai STT——流式 ASR(500 毫秒或 2.5 秒前瞻)
• Kyutai Pocket TTS——1 亿参数 TTS,CPU 可跑(2026 年 1 月)
• Unmute——在公共服务器上组合这些的完整流水线

L40S GPU 上吞吐:3 倍实时下 64 个并发会话。

Sesame CSM——表亲

Sesame CSM(2025)用类似思路——Llama-3 骨干 + Mimi 编码头。但 CSM 是单向的(吃上下文 + 文本,产语音)而非全双工。它是市场上最好的「语音存在感」TTS,但与 Moshi 的全双工能力不完全相同。

2026 年性能数字

💡 Moshi 的「内心独白」文本流是一个精妙的设计:它不要求文本作为输入(那是流水线的做法),而是让模型在生成音频的同时自愿生成文本。这相当于把「我想说什么」显式化成一个 token 流,迫使模型在声学层面之上维持一个语义骨架,从而显著提升长对话的连贯性——代价是多预测一条流,但 12.5 Hz 下这点开销微不足道。

二、从零实现

第 1 步:接口

Moshi 暴露一个 WebSocket 服务器,吃 80 毫秒块的 Mimi 编码音频,吐 80 毫秒块的 Mimi 编码音频,双向持续。

import asyncio
import websockets
from moshi.client_utils import encode_audio_mimi, decode_audio_mimi

async def moshi_chat():
    async with websockets.connect("ws://localhost:8998/api/chat") as ws:
        mic_task = asyncio.create_task(stream_mic_to(ws))
        spk_task = asyncio.create_task(stream_from_to_speaker(ws))
        await asyncio.gather(mic_task, spk_task)
​

第 2 步:全双工循环

async def stream_mic_to(ws):
    async for chunk_80ms in mic_stream_at_12_5_hz():
        mimi_tokens = encode_audio_mimi(chunk_80ms)
        await ws.send(serialize(mimi_tokens))

async def stream_from_to_speaker(ws):
    async for msg in ws:
        mimi_tokens, text_token = deserialize(msg)
        audio = decode_audio_mimi(mimi_tokens)
        await play(audio)
​

两个方向同时跑。Python asyncio 或 Rust futures 是标准传输。

第 3 步:训练目标(概念)

对每个 80 毫秒帧 t:

• 输入:user_mimi[0..t]、moshi_mimi[0..t-1]、moshi_text[0..t-1]
• 预测:moshi_text[t],然后 moshi_mimi[t, codebook_0..7]

文本先于音频预测(内心独白);音频在深度 Transformer 内按码本顺序预测。

设计要点:深度 Transformer 的存在是因为 Mimi 的码本有层级依赖——码本 0(语义)决定内容,码本 1-7(声学)在内容之上叠加细节。如果并行预测,模型无法利用「先知道内容再决定音色」的因果链;顺序预测则让每个码本都条件于前面的,信息流自上而下,符合 RVQ 的设计哲学。

第 4 步:Moshi 赢在哪里、输在哪里

Moshi 赢:

• 廉价硬件上端到端 < 250 毫秒。
• 自然的反向频道与打断。
• 无流水线胶水代码。

Moshi 不赢:

• 工具调用(没为此训练;需要单独的 LLM 路径)。
• 长推理(Moshi 是约 8B 的对话模型,不是 Claude/GPT-4)。
• 冷门话题的事实准确性。
• 多数生产级企业用例(2026 年仍用流水线)。

三、框架对比

⚠️ 四类坑:① 工具调用受限——Moshi 是对话模型,不是 agent 框架,要工具就结合流水线;② 特定声音条件——Moshi 用单一训练人格,克隆要单独训练一轮;③ 语种覆盖——法语+英语优秀,其他有限,Hibiki-Zero 有帮助但仍需训练数据;④ 资源成本——一个完整 Moshi 会话占一个 GPU 槽位,不是便宜的共享租户部署模式。

四、可复用产物

本节产出技能文档(原课程 outputs/skill-duplex-pipeline.md),为语音 agent 工作负载选择流水线 vs 全双工架构,并说明理由。决策表:

• 要最低延迟 + 自然反向频道 + 无工具 → Moshi 全双工。
• 要工具调用 + 长推理 + 企业级可控 → 级联流水线(第 12 节)。
• 要实时翻译通话 → Hibiki / Hibiki-Zero。
• 要定制声音 + 上下文 TTS(非对话)→ Sesame CSM。
• 要任意语种 + 商业可接受 → GPT-4o Realtime / Gemini 2.5 Live。

五、练习

1. 基础:运行 code/main.py。它符号化地模拟双流 + 内心独白架构。

2. 进阶:从 HuggingFace 拉 Moshi,跑服务器,测一次对话,测用户话尾到 Moshi 响应开始的墙上时钟延迟。

3. 挑战:拿你第 12 节的流水线 agent,在 20 条匹配测试话语上与 Moshi 对比 P50 延迟,写一份「流水线在哪些场景架构上仍胜出」的分析。

本节要点回顾

1. 级联流水线有 ~400ms 延迟地板,每级(VAD/STT/LLM/TTS)都有最小延迟,形状本身封顶。
2. Moshi 全双工架构绕开流水线:单 Transformer 直接吃音频吐音频,文本只是「内心独白」,200ms 端到端(地板的一半)。
3. 双流架构:用户音频 + Moshi 音频 + 内心独白文本,12.5 Hz × 8 码本并行,Moshi 能边说边听、自我打断、反向频道。
4. 深度 Transformer 在一个 80ms 帧内顺序预测 8 码本(码本间依赖),是 AR 编解码 LM 的标准因子分解(VALL-E/VibeVoice 同范式)。
5. 内心独白文本不要求输入,而是模型自愿生成,迫使声学层之上维持语义骨架,提升长对话连贯性,还白送转录。
6. Hibiki 同架构做流式翻译;Hibiki-Zero(2026.02)用句级数据 + GRPO 强化学习,免词级对齐。
7. Sesame CSM 是单向表亲(上下文+文本→语音),市场最佳「语音存在感」TTS,但非全双工。
8. Moshi 赢在延迟/反向频道/无胶水,输在工具调用/长推理/事实性——2026 年多数企业生产仍坚持流水线。

下一节,我们转向本章的安防维度——语音反欺诈与音频水印,讲透 ASVspoof 检测器、SilentCipher/Perth 水印,以及 EU AI Act 强制披露下的合规工程。