GLM-4-Voice 完整架构：Tokenizer、Streaming Thoughts 与流式解码

GLM-4-Voice 的核心不是把 ASR、文本 LLM 和 TTS 串起来，而是让同一个自回归模型直接读取语音 Token，并交替生成文本 Token 与语音 Token。文本负责语义规划，语音 Token 负责音色、韵律和声学输出。

依据 GLM-4-Voice 论文和官方仓库整理。三个公开组件边界是 Voice Tokenizer、GLM-4-Voice-9B 和 Streaming Decoder。

一、Voice Tokenizer：把语音压到每秒 12.5 个 Token

Tokenizer 以 Whisper-large-v3 encoder 为基础，在时间维做池化，再用一个向量量化码本把连续表示离散化。12.5 Hz 表示每 80 ms 产生一个 Token；论文给出的信息率是 175 bps，因此码本有效容量约为每个 Token 14 bit。

token_rate = 12.5 token/s
bits_per_token = 175 / 12.5 = 14 bit
codebook_size ≈ 2^14 = 16,384

流式并不是事后切块。普通 Whisper encoder 的双向注意力会看到未来帧，GLM-4-Voice 将卷积改成因果形式，并用 block-causal attention 限制可见范围。码本通过指数移动平均更新，低使用率向量会被重置，以避免只有少量 code 被反复使用。

这是语义导向的单码本 Tokenizer，不是高保真音频 codec。

低码率有利于 9B 模型进行长序列推理，但一个 175 bps 码流不足以直接重建自然波形。最终音质依赖后面的条件生成解码器补全声学细节。

二、GLM-4-Voice-9B：语音 Token 进入语言模型词表

中间模型从 GLM-4-9B-Base 初始化，将语音 Token 作为新词表项加入自回归序列。预训练混合文本、无监督语音、语音—文本监督数据以及合成的交错语音—文本数据；论文称总训练量约一万亿 mixed tokens。这里不能写成“一万亿真实语音 Token”，因为文本和合成数据也在分母内。

训练信号	主要学习内容	为什么需要
纯文本	语言、知识与指令能力	继承文本 LLM 的能力上限
无监督语音	语音 Token 的序列规律	利用大量无转写音频
语音—文本配对	识别、翻译、内容对齐	建立两种 Token 空间的对应
交错语音—文本	边组织语言边生成语音	训练 Streaming Thoughts 调度

三、Streaming Thoughts：文本始终比语音领先一小段

模型不是先写完整答案再朗读，而是循环生成 13 个文本 Token，再生成 26 个语音 Token。论文选择 1:2 的组块比例，使文本语义轨在播放轨之前保持小幅领先；用户因此更早听到首个音频块，模型又保留了文本 LLM 的语言脚手架。

上下文 → 文本 token × 13 → 语音 token × 26
                         ↘ 下一组文本 × 13 → 下一组语音 × 26 → ...

这里的 “Thoughts” 容易造成误解。公开论文中的文本轨是可训练、可对齐的输出规划信号，不应解释为模型私有的隐藏推理链。它更接近“边写字幕边说话”，而不是“暴露思维过程”。

为什么不能只生成语音 Token？

纯音频序列同时承载文字内容、发音、音色和韵律，语言知识的学习效率较低。显式文本轨把“说什么”和“怎么说”部分解耦，让预训练文本模型继续承担知识与长程语义规划。

四、Streaming Decoder：从低码率语义 Token 补全波形

解码器沿用 CosyVoice 的三段式思路：Token encoder 将离散语音 Token 变成条件表示，conditional flow matching 生成声学特征，HiFi-GAN 声码器再合成波形。流式模式按块运行，论文设置的首块是 0.8 秒，即至少等待 10 个 12.5 Hz 语音 Token。

first_chunk = 10 tokens / 12.5 tokens·s⁻¹ = 0.8 s

0.8 秒是模型解码块的算法条件，不等于完整产品的首包延迟。麦克风缓冲、网络、9B 模型采样、flow matching 和音频播放都还会增加时间；硬件和实现不一致时，不能直接拿它与其他厂商的端到端延迟比较。

五、它是流式 Speech-to-Speech，但不是严格的原生全双工

GLM-4-Voice 能在回答尚未完成时持续输出语音，也能控制情绪、语速、语调和方言。这解决了“必须等完整文本才能开口”的延迟问题。但公开架构没有像 Moshi 那样同时建模用户和助手两条持续音频流；播放期间的打断通常仍需外部会话控制。

问题	GLM-4-Voice	Moshi 式全双工
输出能否边生成边播放	可以	可以
模型生成时是否持续吸收用户音频	公开架构未提供对称双流	是
重叠、附和、打断是否进入训练表示	不是论文核心	是核心建模对象

因此更准确的定位是：GLM-4-Voice 用低帧率语义 Token 和交错文本轨实现低延迟流式语音对话；它证明文本脚手架可以与端到端语音生成共存，但没有消除轮次边界。