Hibiki- 流式语音翻译[Kyutai]

Github: https://github.com/kyutai-labs/hibiki
paper: High-Fidelity Simultaneous Speech-To-Speech Translation
主页：https://kyutai.org/2025/02/10/hibiki.html

[Read the paper] [Samples] [HuggingFace]

Hibiki——一款 支持实时、高保真、设备端运行的语音到语音翻译模型。它基于 Moshi 所构建的核心思想和架构，借助自研的合成数据实现高效训练，并支持在移动端进行推理。Hibiki 能忠实传递原说话者的声音特性和语流，其质量和自然度在现有模型中最贴近人工翻译的效果。 Hibiki 的推理代码与模型权重开源，同时在研究论文中公开了所有训练细节。

什么是 Hibiki？ Hibiki 是一款用于流式语音翻译的模型（也称为同声传译模型）。与传统的离线翻译不同（离线翻译需等到说话人完整表达完毕后才开始翻译），Hibiki 能动态地积累刚好足够的上下文，并实时逐段输出准确的翻译内容。当用户说话时，Hibiki 会一边生成目标语言的自然语音（含声音迁移），一边输出对应的文字翻译。

架构：Hibiki 是一个仅包含解码器的同声传译模型。Hibiki 利用 Moshi 的多流架构，同时建模源语音和目标语音。这使得 Hibiki 能够在生成目标语音的同时持续处理输入音频流。Hibiki 以恒定的 12.5Hz 帧率生成文本和音频标记，从而实现连续的音频输出流，并附带带时间戳的文本翻译。Hibiki 的主干模型包含 20 亿个参数。我们还训练了一个移动版本 Hibiki-M，具有 10 亿个参数，用于设备端推理。

训练：Hibiki 依赖于对来自同一说话人的源语音与目标语音及文本之间对齐数据的监督训练。由于此类数据的实际数量非常有限，我们依赖于合成数据生成。在源语言和目标语言的转录文本之间，通过一种上下文对齐的弱监督方法进行词级匹配，该方法利用了一个现成的 MADLAD 机器翻译系统。由此得出的对齐规则是：一个词应当仅在可以根据源语言预测出来时才出现在目标语言中。这一规则通过插入静音或使用具备语音控制和对齐感知能力的语音合成系统（TTS）生成目标语音来实现。

推理：Hibiki 会持续编码源语音并生成目标语音。Hibiki 依赖简单的温度采样，因此兼容批处理，不同于依赖复杂推理策略的模型。此外，Hibiki 的语音转换保真度可以通过调整无分类器引导（Classifier-Free Guidance）的系数来控制：系数越大，语音相似度越高，但系数过大会导致翻译质量下降。Hibiki 目前仅支持法语到英语的翻译。得益于其仅解码器架构，Hibiki 可在单个 H100 GPU 上批处理最多 320 条并行翻译（使用无分类器引导时为 160 条）。其更小的替代模型 Hibiki-M 可以在智能手机硬件上本地运行。当前模型训练时支持最长 120 秒的序列，使用 40 秒的上下文窗口。

High-Fidelity Simultaneous Speech-To-Speech Translation

摘要：

Hibiki 利用多流语言模型同步处理源语音和目标语音，并联合生成文本和音频标记，以实现语音到文本和语音到语音的翻译。还解决了同步传译中的挑战，这与其顺序式翻译不同—后者在源语句结束后才开始翻译，而同步传译需要在实时过程中根据上下文的积累逐步生成准确的翻译。为此，我们引入了一种弱监督方法，该方法利用现成文本翻译系统的困惑度，按词识别最优延迟，并构造对齐的合成数据。在监督训练之后，Hibiki 可通过标准的温度采样方法实现自适应的同步语音翻译。在法语-英语同步语音翻译任务中，Hibiki 在翻译质量、说话人一致性和自然度方面展现了当前最先进的性能。

Introduction

为了训练 Hibiki，我们通过对单语音频的转录文本进行翻译与再合成，生成合成的平行数据。尽管这提供了在序列层面对齐的输入输出对，但无法学习细粒度的对齐信息。为此，我们引入了“上下文对齐”方法，这是一种基于现成机器翻译系统困惑度的简单方法，用于推导词级对齐。随后通过在目标语音中适当插入静音，使 Hibiki 能够在不依赖复杂推理策略的前提下，实现实时自适应的翻译流程。

困惑度（Perplexity）是一种衡量语言模型预测样本的好坏的指标，常用于自然语言处理中。如果一个模型预测得越准确，则其困惑度越低。

想象你在玩一个猜词游戏。你的朋友正在说一个句子，说到一半突然停下来，让你猜下一个词是什么。比如：

"今天天气真..."
"我想吃一碗..."
如果你能很容易地猜出下一个词（比如"好"或者"面"），说明这个句子对你来说"困惑度很低"。 如果你完全猜不到下一个词会是什么，那么这个句子对你来说"困惑度很高"。

在人工智能和语言模型中，困惑度就是用来衡量模型对文本的预测能力:

困惑度越低 = 模型越自信 = 预测越准确
就像你很容易猜到"今天天气真好"中的"好"一样
困惑度越高 = 模型越困惑 = 预测越不确定
就像面对"今天我遇到了一只..." 这样的句子，下一个词可能是"猫"、"狗"、"兔子"等很多可能，很难准确预测

此外，鉴于训练数据中说话人相似度差异较大，我们提出为训练样本标注说话人相似度类别。该方法避免了对训练数据的过滤，同时在推理阶段通过无分类器引导（classifier-free guidance）倾向生成说话人高度相似的语音输出。

方法

我们考虑一个源语言的语音话语，将其表示为单声道波形X∈R^fs⋅d，采样率为 fs=24kHz，时长为 d。类似地，其目标语言的翻译表示为 Y∈R^fs⋅d。我们假设对 X 进行了填充，以确保 X 和 Y 拥有相同的时长。我们的目标是建模条件概率 P[Y∣X]。此外，我们增加了一个约束：在已知 X 的情况下对 Y 的建模应具有因果性，并且相对于源语音具有最小延迟，例如与人工同声传译员在实时翻译场景中所面临的约束相同。

为了通过监督学习学习这一约束，目标语音 Y 本身必须构建为满足因果性约束。我们首先假设 Y 满足这一约束，并介绍如何对其分布进行建模。随后，我们引入一个信息论准则，用以验证 Y 相对于 X 是否具有因果性，并进一步将一个非因果的翻译转换为一个因果的翻译。

模型

以 Moshi框架为基础，对从神经音频编解码器中获得的多个离散标记序列进行联合建模。

Neural audio codec

我们使用预先训练的因果和流式 Mimi 编解码器将 X 和 Y 编码为低帧率的离散标记序列。

编码器将持续时间为 d 的输入波形转换为一个潜在向量 U∈R^C×fr⋅d，其中 C是潜在空间的维度，帧率 fr=12.5 Hz。随后，U被投影到其在一个包含N_A 个条目的码本中的最近邻。该投影的残差接着被投影到另一个具有相同大小的码本中，如此重复，直到完成 Q 次投影。最后一次的残差被舍弃，解码器则被训练为从这些投影张量的总和中重构原始输入波形。

在语言建模任务中，我们关注的不是量化后的潜在向量及其残差，而是其在码本中投影对应的离散索引。我们将这些索引表示为 (At,q)∈{1,…,NA}^fr⋅d×Q。在 Mimi 中，帧率为 fr=12.5 Hz，投影次数 Q 最多为 32，但我们实际使用不超过 16 个。

第一层量化输出被训练用于复现来自 WavLM 自监督音频模型中获得的语义信息。我们将 At,1 称为语义标记（semantic tokens），而将 At,q≥2 称为声学标记（acoustic tokens）。

这些声学标记按从粗到细的层级排列：前几层承载最重要的音频信息，后续层则建模更精细的音频细节，从而确保感知上的平滑与自然性。

Joint modeling of discrete audio tokens

音频流的离散标记无法轻易地被压缩为一个具有合理基数和帧率的单一离散序列。因此，我们采用 RQ-Transformer在时间轴 t 和量化器轴 q上联合建模 At,q。

该模型由一个大型的 时序 Transformer（Temporal Transformer） 组成，其运行帧率与编解码器相同，即 fr，并接收至今为止生成的所有标记作为输入，即所有 t≤fr的标记

A0 被定义为指示生成开始的确定性标记。然后，较小规模的深度变换器在量化器轴上对标记 At,1,…,At,Q 进行自回归建模，例如，对于所有 t≤fr⋅d 和 q≤Q ：

At,0 也是一个特殊令牌，其目标是：

我们进一步引入了2个时间步长的声学延迟，这意味着我们建模的是 τ(A)t,q而非直接的 At,q。

0 为特殊标记。在使用编解码器解码音频之前，会移除延迟。

生成“内心独白”（即与生成音频内容对齐的填充文本标记）有助于提升生成音频的质量和稳定性

Translation as multistream modeling

我们已经介绍了方程（1）和（2）中的 RQ-Transformer 如何实现对多路离散标记流的联合建模。我们将该框架改编用于联合语音到语音与语音到文本的同步翻译任务。具体做法是将目标译文 Y 的音频标记 A^Y 与源语音 X的标记 A^X 在量化器维度 q 上进行拼接，即：

Hibiki 还预测一个文本流 Wt，对应于输出 Y 的转录文本，并在词与词之间加入足够的填充以保证其与音频保持对齐。需要注意的是，与以往多任务翻译工作不同，Hibiki 在推理阶段主动利用了这一能力。这里我们用 Wt表示文本流，其基数为 N_W，且帧率与音频流相同，均为 fr。

Alignment and synthetic interpretation data

我们假设对 (X,Y) 尊重同声传译的限制。我们现在引入一个无监督的标准来估计和执行因果关系源语句和目标语句之间的依赖关系。

文本域比齐

我们首先在文本域中形式化地表达这些约束。设 S=(S1,…,Sn)表示源语句 X中的词序列，T=(T1,…,Tm) 表示目标语句 Y 中的词序列。

理想对齐（Ideal alignment）：我们希望定义一个理想的对齐序列 (a_j^ideal)∈{1,…,n}^m，其中 a_j^ideal 表示第 j个目标词 T_j 在生成前应等待的源词 Si 的索引，以最小化对 Tj 的不确定性。

若训练使用的对齐比 a^ideal更激进（即目标词提前生成），则模型在推理时可能出现幻觉现象（hallucination）；而若对齐更保守（即目标词延后生成），则模型依然保持因果性，但会引入额外的延迟。

上下文对齐（Contextual alignment）：

我们引入一个标准来估计 a^ideal 。我们将其表示为条件对数似然：

我们预期 logp_j,i随着 i 的增加而上升，因为更多的上下文信息通常更有利于生成正确的翻译。我们的假设是，对于某个目标词 T_j，增量 δj,i=log⁡(p_j,i)−log⁡(p_j,i−1) 在 i=a_j 时达到最大值。也就是说，第 j个目标词的生成在该位置获得了最大的上下文收益。

为估计 log⁡(p_j,i)，我们使用现成的文本翻译语言模型 MADLAD-3B，将其输入截断为前 i 个源词，并计算预测第 j个目标词的对数概率log(p^_j,i)。据此，我们定义了一种上下文对齐方法，用以估算每个目标词最优的等待位置，并以图 3 的形式加以示意。

图3：我们使用一个预训练的文本翻译模型，计算目标词 “into” 在不同输入截断条件下的对数似然（log-likelihood）。当对应的源词 “en” 出现在输入中时，我们观察到“into”的对数似然显著上升（详见公式（6））。这表明该源词提供了关键的上下文信息，从而支持了我们对最优对齐点的判定方法。

音频域对齐

给定一对语音对齐样本 (X,Y)，我们使用 Whisper 模型对其进行转录并提取时间戳，然后应用公式（6）计算对齐位置。如果目标语句 Y 中第 j 个词的时间戳在源语句 X 中第 a_j^ctx个词之后，则认为该对齐 ( a_j^ctx ) 是被遵守的。

为了降低对齐错误的影响，我们要求目标语音 Y 相比上下文对齐结果至少滞后 2 秒；同时，我们会排除局部延迟中高于滑动窗口（5 个词）平均延迟 25% 的“尖峰”异常【某个词的时间延迟相对于其上下文明显偏高，高出周围词平均延迟的 25% 以上】。

静音插入（Silence insertion）：

若 Y 不满足对齐要求，可通过在目标词前插入适量静音段来调整其时序，如图 1 所示。然而该方法存在两点限制：

当时间戳不准确或词之间没有自然停顿时，静音插入可能造成生硬的语音切断；
调整后的 Y 可能相对理想对齐严重滞后，例如当 Y的语速慢于 X 时。

该方法用于语音翻译训练阶段的样本对齐。

对齐感知的语音合成（Alignment-aware TTS）

为了获得更加自然的对齐语音数据，我们使用具备硬性与软性位置控制能力的 TTS 模型对 Y 进行（重新）合成，同时保留对说话人风格的准确建模。这种方法不仅可以生成对齐更好的训练数据，还可提升词错误率（WER）和说话人相似度。

我们训练一个 TTS 模型，其输出同时包括音频和与之同步的文本序列，并在输入中加入说话人条件。文本流被强制与目标文本完全一致，模型仅允许插入填充标记。音频输出相对于文本是滞后的，以便其内容受文本控制，不论是内容还是时间戳。

当 TTS 提前于对齐点 a^ctx 时，填充标记会被强制插入以延迟下一个词的生成；当 TTS 滞后于目标时，会在填充标记的 logits 上施加惩罚，惩罚值随着滞后时间从 1 秒增加到 2 秒时线性从 0 增加到 -2。这样能平滑提升语速，从而追上源语音的节奏。

我们对每个输入生成 6 到 8 个候选样本，优先根据词错误率选出最佳结果，其次考虑说话人相似度。该方法仅应用于语音翻译微调数据集的构建。

声音迁移（Voice Transfer）

改进语音迁移数据：在训练带有声音迁移功能的语音翻译模型时，通常采用同一说话人的合成配对序列进行监督训练。然而，图 4 显示，该数据集中源语音和目标语音的说话人相似度（以说话人嵌入的余弦相似度衡量）平均仅为 0.23，相当低。作为参考，当前最先进的跨语种声音迁移系统的平均说话人相似度约为 0.40。因此，我们使用对齐感知的 TTS 重新生成了 CVSS-T 数据，这使得迁移语音可以更好地保留说话人特征。如图 4 所示，重新合成后的 CVSS-T 数据的平均说话人相似度提升至 0.47。尽管如此，我们的训练数据混合了合成数据与重新合成的 CVSS-T，整体相似度仍分布较广泛，其中仍有大量样本低于 0.40。

条件训练（Conditional Training）如果直接筛选出说话人相似度高的数据用于训练，确实可以提高声音迁移效果，但会导致训练样本显著减少，从而可能损害翻译质量。例如，若仅保留说话人相似度大于 0.40 的样本，将导致 训练数据减少约 45%。因此我们采用条件训练（conditional training），在训练过程中告知生成模型每个样本在声音迁移方面的可靠性。我们为每个训练样本打上一个离散的“声音迁移评分”，其标签来自以下集合：

{ very_bad, bad, neutral, good, very_good }

评分依据是说话人相似度的分位数划分，每个评分标签对应一个可学习的嵌入（embedding），在模型的每个时间步加入输入中。值得注意的是，这些分位点是在合成数据和 CVSS-T 数据合并前计算的，以确保模型学习的是实际的说话人相似度，而不是将某标签“误绑定”到某特定数据集。在推理阶段，我们始终传入 “very_good” 标签，以期生成具有良好说话人保持能力的语音。

无分类器引导（Classifier-Free Guidance）我们采用**无分类器引导（classifier-free guidance）**来增强条件训练的效果。具体做法是：分别使用 very_good 和 very_bad 条件下计算输出 logits，然后结合两者以调整采样过程，从而增强模型在推理时对说话人风格的控制能力。

这与实时推理兼容，因为它能以批大小为 2 同时生成两组 logits。结果表明，这种方法能显著提升语音转换效果。

Experiments

训练策略

通过以下步骤训练一个法语-英语的语音翻译系统：

文本预训练。 我们首先在多语言的纯文本数据上，从头开始预训练 Temporal Transformer，采用下一个词预测任务

音频预训练。 在预训练好的文本模型基础上，使用非平行的法语和英语数据，在单流设置下进行音频预训练

语音翻译训练。 我们构建了一个约包含 4 万小时法语和英语语音的翻译数据集。首先从一批富有表现力的法语音频中提取约 230 万条单说话人的语音片段，每段时长约 60 秒。我们使用 Whisper的 large-v3 模型对这些片段进行转录，并借助 PySBD将转录文本分句，然后使用 MADLAD-3B分别翻译每个句子，最后重新拼接成英文翻译文本。我们利用 TTS 系统合成语音，条件是原始法语说话人的身份（使用一段 10 秒的语音）。我们应用静音插入技术，以获得同声传译的语音对。

我们进行基于说话人相似度的条件训练，并对源语音频施加噪声增强。在每对训练数据中，我们在源语音流中语音结束后首帧加入一个特殊的输入 EOS 标记，在文本流中也加入另一个特殊 EOS 标记，指示模型生成语音的结束。

语音翻译微调。 我们使用引入的对齐感知 TTS 技术，构建了一个包含长句式的合成数据集，并改进了 CVSS-T/train 数据集，具有自然停顿和较高的说话人相似度，总计约 900 小时。

Hibiki-M 的训练。 其训练流程与 Hibiki 相同，先进行文本和音频预训练。在语音翻译训练阶段，通过软蒸馏从 Hibiki 获得知识，再进行相同的微调步骤（不再进行蒸馏）。

推理：

我们使用流式编解码器对音频进行编码，并将生成的 token 输入 Hibiki，同时解码输出 token 以获得流式翻译。在输入结束时，我们向模型发送一个 EOS（结束）标记，并持续采样，直到模型自行生成一个 EOS。推理参数通过对 Audio-NTREX 的保留 8% 数据和 CVSS-C 的验证集分别进行交叉验证来确定。对于 Audio-NTREX，最优参数为 γ = 3.0，温度为 0.8，audio token 的 top-k 为 250，text token 的 top-k 为 50。在 CVSS 上，除了对 text token 使用温度为 0.1 的采样外，其余配置相同。我们推测，较低的文本采样温度通常有助于提升翻译质量，但可能导致模型过早生成 EOS 标记。

Results

**表 1：** 与离线基线系统的对比结果。我们还报告了一个闭源流式模型（*）的性能，因为它采用了相同的评估协议。

表 1 将 Hibiki 与在翻译时可以访问完整源音频的离线基线模型进行了比较。尽管 Hibiki 进行的是同声传译，但它的表现优于所有模型，包括 StreamSpeech 的离线版本。表 2 将 Hibiki 与可用的同声传译基线模型进行了对比。在短格式设置中，我们的模型优于 StreamSpeech 和 Seamless，但平均延迟时间增加了 0.7 秒。长格式数据集的挑战更大，因为 StreamSpeech 无法生成清晰易懂的翻译。Hibiki 的表现优于 Seamless，但延迟时间平均高出 0.8 秒。

音频保真度。

如表 2 所示，关于说话人相似度的客观评估结果表明，Hibiki 在语音转换方面显著优于 Seamless（我们未评估 StreamSpeech，因为它不执行语音转换）。表 3 中的人类评估结果进一步验证了这一点，并显示 Hibiki 在音质和自然度方面远高于 Seamless，接近专业人工口译音频的真实水平。

这意味着 Hibiki 不仅能够生成高质量的音频，还能在语流中插入流畅且自然的停顿。

消融实验：对齐策略。
我们将所提出的上下文对齐方法与其他方案进行比较。表 4 显示，在训练时对目标语音不施加延迟会导致翻译质量非常低，这是可以预期的，因为模型缺乏足够的上下文来生成翻译。为训练样本添加延迟能够提升 ASR-BLEU 分数，其中 10 秒的延迟表现为一个合理的选择；但平均延迟（以 LAAL 表示）比使用上下文对齐差得多，因为模型无法根据上下文自适应调整生成节奏。“句子对齐”作为常量延迟与上下文对齐之间的折中方案，将每个输出句子的起始时间对齐到相应源语句子的结束时间。这种做法提高了翻译质量，但延迟反而更严重。

总体而言，上下文对齐在翻译质量与延迟之间提供了最佳平衡。

消融实验：无分类器引导（Classifier-free guidance）。
表 5 显示，使用“very good”标签时，说话人相似度为 0.42，与 Seamless（0.43）相当。采用无分类器引导（γ = 3.0）可以显著提升说话人相似度，同时不会明显损害翻译质量。但如果权重设得过高，模型性能会下降，表现为生成的语音不可理解。

附录中有趣地展示了：将 γ 增大到极端值时，会导致生成的语音出现夸张的法语口音（即我们的实验中使用的源语言），我们认为这是由于用于标注数据的说话人模型存在偏差所致。

消融实验：通用消融。
同时预测文本 token 如何作为语音生成的框架。表 4 验证了这一点：将 Hibiki 作为单模态模型训练（即不预测文本输出），会导致性能大幅下降；同样地，从一个预训练文本语言模型出发，直接进行语音到语音翻译（S2ST）训练，效果也很差。

推理能力

批量推理。Hibiki 的推理采用恒定帧率下的温度采样，这使得流式的无分类器引导和多个语音源的并行处理变得非常简单。这一点不同于 Seamless 和 StreamSpeech，它们的推理策略更复杂，需对每个序列做出动态且不规则的决策，因而难以批量处理。图 5 显示，即便同时处理 320 条语音序列（或在无分类器引导下处理 160 条），Hibiki 在 H100 上仍能保持快于实时的推理速度。

端侧推理。我们蒸馏得到的 Hibiki-M 在短文本和长文本翻译任务上都能与 Seamless 相媲美，如表 2 所示。我们将其在长音频上的较低说话人相似度归因于其建模的量化器数量较少（8 个而非 16 个），这使得音频比特率降低了一半。图 6 展示了 Hibiki-M 在 iPhone 16 Pro 上的推理轨迹。即使使用支持无分类器引导所需的批量大小为 2，Hibiki-M 在一分钟的推理过程中仍能保持快于实时的速度。若使用滑动窗口注意力对 Hibiki-M 进行训练，还可进一步提升其实时性能。

局限性

本研究仅聚焦于一个翻译任务（法语到英语），若扩展到更多语言，可能需要借助 MADLAD 这类大规模多语言模型，但这也意味着需为更多语言训练相应的 TTS 系统。此外，虽然 Hibiki 在与 CVSS-C 的真实目标对比时能达到 35.5 的 ASR-BLEU 分数，但若将其输出与 MADLAD 的文本翻译对比，则可达到 47.9 的 ASR-BLEU。这表明 Hibiki 非常擅长生成与 MADLAD 类似的翻译结果；若使用更优或更丰富的伪目标（pseudo-target）对其进行训练，Hibiki 有望进一步提升相对于真实目标的翻译质量。

Kyutai’s STT and TTS：Delayed Streams Modeling framework

流式TTS：https://kyutai.org/next/tts
流式STT：https://kyutai.org/next/stt
STT+LLM+TTS demo：https://unmute.sh/
https://kyutai.org/next/unmute
Github：https://github.com/kyutai-labs/delayed-streams-modeling
论文：paper is coming soon

关于Kyutai：Kyutai 是一家位于法国巴黎的非营利性人工智能研究实验室，成立于 2023 年 11 月。该实验室致力于推动人工智能的开放研究，特别关注多模态大模型的开发与创新算法的研究，旨在提升 AI 的能力、可靠性和效率，并促进其民主化。

延迟流建模 (DSM) ：一种用于解决多种流式 X 到 Y 任务的技术（其中 X 和 Y 可以是语音或文本），它将我们在 Moshi 和 Hibiki 中采用的方法形式化了。

Kyutai STT

Kyutai STT 是一种流式语音转文本模型架构，在延迟与准确率之间实现了无与伦比的平衡，非常适合交互式应用。它支持批处理，可在单个 GPU 上处理数百条并发对话。发布了两个模型：

kyutai/stt-1b-en_fr：一个低延迟模型，支持英语和法语，并内置语义级语音活动检测器。
kyutai/stt-2.6b-en：一个更大的仅支持英语的模型，经过优化以实现尽可能高的准确率。

Streaming and accurate: 在英文测评集上的WER指标

Kyutai STT 是一个流式模型，这意味着它在接收音频的同时实时转录，而不是假设音频在开始处理前已全部可用。这使其非常适合诸如 Unmute [Make any LLM listen and speak using Kyutai’s speech-to-text and text-to-speech.] 之类的实时应用。

它输出格式良好的转录文本，包含标点符号，同时还提供词级时间戳。

在准确性方面，它的表现仍可与那些能够一次性访问完整音频的最先进非流式模型相媲美。

语义语音活动检测器

对于像 Unmute [Make any LLM listen and speak using Kyutai’s speech-to-text and text-to-speech.] 这样基于串联式语音对话的应用程序，需要一种方式来判断用户是否已经说完，以便生成回应。最常见的方法是使用一个独立的语音活动检测（VAD）模型，判断用户是否在说话，并在用户说完之后等待一个固定的时间。但在实际应用中，不可能找到一个适用于所有情况的等待时间。人们在说话时经常会出现长时间停顿，这会导致这种朴素方法出现误判。

为了解决这个问题，Kyutai STT 不仅预测文本，还预测用户是否已经说完话的概率。对于停顿的判断延迟会根据用户说话的内容和语调自适应调整。

低延迟

kyutai/stt-1b-en_fr 的延迟设定为 500 毫秒，也就是说，每个词会在说出后约 500 毫秒被转录。而 kyutai/stt-2.6b-en 的延迟为 2.5 秒。

在 Unmute [Make any LLM listen and speak using Kyutai’s speech-to-text and text-to-speech.]中，我们使用一种称为 “flush trick”（刷新技巧）的方法来进一步降低响应延迟。当语音活动检测器预测用户已经说完时，我们还需再等 500 毫秒（即 STT 模型的延迟），以确保不会截断转录的结尾部分。

为了减少这段延迟，我们利用了语音转文本服务器“比实时更快”的处理能力。当检测到说话结束时，我们请求 STT 服务器尽可能快地处理此前已发送的音频。服务器的运行速度约为实时的 4 倍，因此可以在大约 125 毫秒内处理这段 500 毫秒的音频（即 500ms ÷ 4 = 125ms）。通过这种方式，我们“扭曲时间”，只需等待这 125 毫秒，即可确保所有内容已被转录。

高吞吐量

Kyutai STT 非常适合在生产环境中部署：在一块 H100 GPU 上，它可以同时转录 400 路实时音频流。这得益于其采用的延迟流建模架构（见下文），该架构允许我们在无需任何额外“粘合代码”的情况下，以大批量运行模型，并实现流式处理。

相比之下，将 Whisper 改造成流式模型需要一个完全独立的研究项目——Whisper-Streaming。该系统会反复在最近几秒的音频上运行 Whisper，并将重叠的转录结果拼接在一起。

Whisper-Streaming 在技术上令人印象深刻，但它不支持批处理，这导致吞吐量大大降低。若目标延迟更低，其吞吐量会进一步下降，因为需要更频繁地重新运行 Whisper。

延迟流建模

Kyutai STT 的主要创新是一种在 Kyutai 开发的技术，称为延迟流建模（delayed streams modeling），最早在 Moshi 项目中率先使用了这一方法。

传统的语音转文本方法通常是将整段音频一次性输入模型，并由模型逐步（自回归地）生成文本。例如，Whisper 就是这样做的，它使用的是编码器-解码器结构的 Transformer 模型。

在 Kyutai STT 中，将数据表示为时间对齐的文本流和音频流。本质上，音频和文本是“并列”存在的，而不是一个接着另一个。文本流会进行填充，以确保文本的时间与音频对齐。只是将文本流延迟了几个帧，以便语音转文本模型能够进行一定程度的前瞻。

使用这种表示方式的文本-音频数据来训练 Kyutai STT，教它同时建模音频流和文本流。在推理阶段，我们保持音频流固定，实时输入接收到的音频，利用模型预测文本流。

这种方法的另一个巧妙之处在于其对称性。我们可以通过延迟音频流而非文本流，并保持文本固定（教师强制），来实现文本到语音的转换，进而预测音频。为使模型能够预测填充符号以对齐文本流和音频流的时间，需要一些技巧。

Kyutai TTS

Kyutai 文本到语音（TTS）最初是我们在 Moshi 开发过程中使用的内部工具。作为我们对开放科学的承诺的一部分，我们现在向公众发布了改进版的 TTS：kyutai/tts-1.6b-en_fr，一个拥有 16 亿参数的模型。该模型包含多项创新，使其特别适合实时使用。

State of the art

Kyutai TTS 在文本到语音领域树立了新的技术水平。词错误率（WER）衡量 TTS 未能准确遵循文本脚本的频率。说话人相似度则是评估在语音克隆时生成音频与原始样本声音相似程度的指标。我们在 NTREX 数据集中，选取了 15 篇英文和 15 篇法文新闻文章，对 Kyutai TTS 与其他模型进行了对比。除 Kyutai TTS 和 ElevenLabs 外，所有模型均按句子逐句生成，因为我们观察到这样能获得最佳效果。

适合大语言模型（LLM）

Kyutai TTS 无需提前获取完整文本，从接收到第一个文本标记到生成第一段音频的延迟为 220 毫秒。在 Unmute.sh 部署环境中，我们通过批处理同时处理最多 32 个请求，使用 L40S GPU 测得的延迟约为 350 毫秒。

其他被描述为流式的 TTS 模型仅在音频上实现流式处理，仍然需要提前知道完整文本。

Kyutai TTS 是首个同时支持文本流式处理的文本到语音模型。你可以边由大语言模型生成文本边输入，Kyutai TTS 会即时开始处理，从而实现超低延迟。这在大语言模型生成耗时较长的情况下尤为有用，比如资源受限环境或生成长文本段落时。

文本流式处理得益于下文详细介绍的延迟流建模技术。

语音克隆

为了指定语音，我们使用一段 10 秒的音频样本。TTS 能够匹配源音频的声音、语调、说话习惯和录音质量。

长时段生成

大多数基于 Transformer 的 TTS 模型针对生成少于 30 秒的音频进行了优化，通常不支持更长时间的生成，或者在处理较长音频时表现不佳。Kyutai TTS 在生成更长时段音频方面没有任何问题。

词级时间戳

除了音频本身，Kyutai TTS 还会输出生成词语的精确时间戳。这对于为 TTS 提供实时字幕非常有用。

延迟流建模

Kyutai TTS 独特的能力，如文本流式处理、批处理和时间戳功能，均得益于 Kyutai 开发的一项技术——延迟流建模，该技术最早由我们在 Moshi 项目中开创。

传统使用语言模型进行文本到语音转换的方法，是基于输入文本与音频的分词输出拼接在一起进行训练：

这意味着这些模型是流式的，但仅限于音频：在已知完整文本的情况下，它们开始生成音频，并允许你在生成过程中访问部分结果。然而，完整文本仍需提前获知。

而在 Kyutai TTS 中，我们将问题建模为时间对齐的文本流和音频流。本质上，音频和文本是“并列”存在的，而不是一个接着另一个。我们只是将音频流延迟了几个帧，以便文本到语音模型能够进行一定程度的前瞻：

这意味着一旦知道了前几个文本标记，无论最终文本多长，我们都可以开始流式输出音频。

在输入端，我们接收到一个没有时间信息的词语流，但模型需要使用填充符使文本流与音频对齐。这就是动作流（action stream）的作用：当它预测到 [word] 时，表示“我已完成当前词的发音，请给我下一个词”，此时我们将下一个词输入到文本流中。

VITA-Audio：高效、低延迟的实时端到端语音大模型

VITA-Audio: Fast Interleaved Cross-Modal Token Generation for Efficient Large Speech-Language Model

项目训练和推理代码以及模型权重完全开源，VITA-Audio 支持中英双语，且训练过程中仅使用开源数据，却在同等参数量级中稳居性能第一梯队。

如何高效生成Audio Token？

在端到端语音模型中，生成音频往往要经历以下流程：首先，语音 Token 随着语言模型（LLM）前向传播被逐步自回归地生成；随后，多个已生成的语音 Token 会被收集并送入解码器，最终合成为可播放的音频。由于每一步都依赖上一步的输出，这种多次循环推理的方式在生成首个音频片段前会消耗大量时间，且随着模型规模的扩大，延迟问题愈发严重。

VITA-Audio 团队对模型最后一层解码器的 Hidden States 进行了可视化分析。结果表明，语音模型在预测某个音频 Token 时，对应的文本 Token Hidden States 所承载的注意力权重显著高于其他位置。

更进一步的实验发现：

当屏蔽所有文本位置的 Hidden States 时，模型无法生成正常的音频；
但如果仅保留与当前音频 Token 对应的那一位置的文本 Hidden States，模型依然能够输出准确、连贯的语音，且这些 Hidden States 已隐含了足够的上下文信息（例如，区分多音字“行”读作“xíng”还是“háng”）。

这一发现表明，语音生成并不需要对整个文本—音频序列的全局语义空间进行复杂建模；相反，只需利用对应位置的文本 Hidden States，通过相对简单的映射模块即可完成高质量的音频 Token 预测。

基于此，VITA-Audio 提出了一种轻量级的多重跨模态标记预测（Multiple Cross-modal Token Prediction，MCTP）模块。该模块直接在单次前向传播中预测多个音频 Token，大幅减少自回归循环次数，不仅加速了整体推理流程，更显著降低了流式场景下首个音频片段的生成延迟。

VITA-Audio 的核心组件包括音频编码器、音频解码器、LLM[Qwen2.5-7B]、十个轻量级 MCTP 模块。CosyVoice as the audio encoder and decoder。其推理流程如下：

1. 文本与音频特征分别经编码后输入 LLM，LLM 在单次前向传播中生成文本 Token 或音频 Token。
2. 将 LLM 最后一层的隐藏态和输出先输入第一个 MCTP 模块，其输出再依次传递给后续的 9 个 MCTP 模块；每个模块各自预测一个音频 Token，累计得到 10 个 Token，并由音频解码器合成为音频片段。
3. 在下一次前向传播中，LLM 生成的 Token 会与 MCTP 模块生成的音频 Token 一并作为 LLM 输入，进行下一次前向传播。

由于每个 MCTP 子模块的参数量远小于 LLM，单次预测耗时仅需约 2.4 ms（约为 LLM 推理时间的 11%），显著降低了首个音频片段的生成延迟，并大幅提升整体推理速度。

为了解决同时从头训练10个 MCTP 模块带来的不稳定性，VITA-Audio 采用了如下四阶段渐进式训练策略：

1. 第一阶段-音频–文本对齐：利用大规模语音预训练任务，将音频建模能力融入 LLM，使其 Hidden states 同时承载文本和音频信息。
2. 第二阶段-单 MCTP 模块训练：训练初始 MCTP 模块，使其能够基于 LLM 的输出 Token 和 Hidden States 预测下一个标记。
3. 第三阶段-多 MCTP 模块训练：将首个 MCTP 模块的能力扩展到多个 MCTP 模块，每个模块根据前一个 MCTP 模块的输出标记和 Hidden States 预测其对应位置的标记。
4. 第四阶段-监督微调：以语音问答数据集为主进行监督微调，同时穿插 TTS、ASR 及纯文本数据，确保模型在各类任务上的泛化能力与训练收敛的平衡。

VITA-Audio 提供四种推理范式，以满足不同应用场景对速度与质量的平衡需求：

VITA-Audio-Turbo：最高效的方式，每次前向传播 LLM 生成一个标记【音频或者文本token】，MCTP 模块生成 10 个标记【音频或者文本token】，但因 MCTP 模块也参与文本预测，性能会略有下降，常用于 ASR 和 TTS 任务中。
VITA-Audio-Boost：LLM 专注生成文本 Token，MCTP 模块生成 Audio Token，并且第一次前向中就使用全部的 MCTP 模块，可以在第一次前向中就生成可以用于解码的 Audio Token Chunk。
VITA-Audio-Balance：在前两次前向中仅激活部分 MCTP 模块，保以维持文本与音频 Token 的合理配比（1:2），随后逐步激活部模块，通过动态调节文本／音频 Token 输出比例，实现生成速度与质量的最优平衡。
VITA-Audio-Vanilla：完全依赖 LLM 自回归生成所有 Token，不调用 MCTP 加速模块，推理速度最慢，但可获得最高的音频细节与一致性。

本文介绍了 VITA-Audio，这是一个轻量级框架，其核心在于引入独立高效的多重跨模态令牌预测（MCTP）模块，能够直接从文本 Token 与 LLM Hidden States 中生成音频响应，无需依赖 LLM 的全局语义建模，仅通过简单映射即可完成文本隐藏态到音频令牌的转换。

实验表明，VITA-Audio 在仅仅使用开源数据的情况下，在 ASR、TTS 和 SQA 任务的多个基准测试中均跻身同参数量级开源模型的第一梯队；同时，其推理速度与响应延迟也取得了显著突破。由此，VITA-Audio 为实时语音到语音生成树立了全新的范式。

理想同学：MindGPT-4o-Audio实时语音对话大模型

原文链接：MindGPT-4o-Audio

理想实时语音对话大模型MindGPT-4o-Audio上线，作为全模态基座模型MindGPT-4o的预览preview版本，MindGPT-4o-Audio是一款全双工、低延迟的语音端到端模型，可实现像人类一样“边听边说”的自然对话，并在语音知识问答、多角色高表现力语音生成、多样风格控制、外部工具调用等方面表现突出，达到了媲美人人对话的自然交互水平。

核心功能

全双工语音对话：可同时听与说，告别“你说完我再说”的非自然交互模式，媲美真实人类对话；
低延迟：理解和生成推理延迟260ms，全链路峰值响应延迟800ms，联网搜索时全链路延迟2000ms；
语音知识问答：广泛学习海量高质量知识，具备高精度、低幻觉的知识问答能力；
多角色对话：多角色低成本定制，实现有灵魂、有温度的口语对话；
高表现力语音生成：情境感知下的高表现力TTS及口语化的语气词与副语言生成能力；
多样风格控制：多种特色风格、口音、IP人物的理解、控制及生成能力，稳定的多轮连续对话风格记忆能力；
外部工具调用：多模态任务规划和工具调用，支持实时联网的时效性问答。

1. 模型能力

1.1 整体算法方案

MindGPT-4o-Audio是一款级联式的语音端到端大模型，我们提出了感知-理解-生成的一体化端到端流式生成架构实现全双工、低延迟的语音对话。其中：

· MindGPT-4o-Audio Duplex：感知有效语音输入，实现对话响应时机判定、打断判定、环境音拒识等功能；

· MindGPT-4o LLM ：理解语音及语言模态信息，经MindGPT-4o-Audio Duplex判定为有效交互意图的音频，通过音频编码器（Audio Encoder）实现模态对齐后，由大语言模型(基于理想自研推理模型MindGPT 3.0)自主判定是否调用工具，最终完成信息理解并生成隐式token(角色/风格/文本隐式token)；

· MindGPT-4o AudioHead：生成高自然度的语音，经MindGPT-4o LLM 生成的token流式输入 AudioHead 生成相应的Audio token，通过流式语音生成器（Streaming Speech Generator），最终生成多样化的风格及角色的口语化语音。

在各项权威音频基准测试以及语言理解、逻辑推理、指令遵循等语言理解任务上，MindGPT-4o-Audio 已达到行业领先水平，在语音交互评测基准VoiceBench多类评测中均显著领先行业领先的同类模型。此外，我们实验发现，业内主流的语音端到端模型一般会在提升语音交互能力的同时，造成语言交互能力的大幅下降，MindGPT-4o-Audio通过训练策略的优化保证了语言交互能力的高水准，在IFEval，GPQA等benchmark上平均领先行业20个PP以上。

为了进一步评估理想同学与市面上优秀语音对话产品（豆包、ChatGPT）在用户体验方面的表现差异，我们组织了内部的用户对比评测，从口语真实感(对话内容及表达的准确性及类人程度)、交互自然度(对话响应及全双工对话的流畅程度)两个方面进行设计。本次评测共邀请了24位不同年龄段的测试者参与，测试者需分别对理想同学、豆包及ChatGPT三款产品在选自真实对话场景的话题表现进行深度体验并独立进行评分。统计结果显示，在口语真实感方面，理想同学以94%的满意度占优，超越了豆包的92%；在交互自然度方面，理想同学继续保持领先，满意度达到92%。

同时，我们也基于理想同学手机App进行了端到端响应延迟测试，整体端到端延迟约1100ms（注：此指标为考虑实际用户量及部署成本后的实测延迟），显著领先豆包的2100ms和GPT-4o的1900ms。

1.2 全双工语音对话：MindGPT-4o-Audio Duplex

为了让理想同学像真人一样与用户进行实时对话，我们研发了MindGPT-4o-Audio Duplex，实现全双工对话能力。我们的模型通过结合上下文联合推理实现了自适应响应、即时打断和环境背景干扰拒识能力。

· 自适应响应：我们研发的全双工模型基于对话中的停顿间隙IPU（Inter-Pausal Unit）来判断对话响应时机，预测是否进行对话轮次转换，该方案可以减少碎片化计算节约推理资源，且能够避免在用户连续说话时打扰用户。同时我们提出了一种自适应响应时间机制KLT（Keep_Listen_Time），针对用户已完成的对话内容，如“今天有什么热门新闻？”进行快速响应，判定延迟低至150ms；针对用户犹豫不决的对话内容，如“我想要……” 以及对话轮次模糊的闲聊场景，如 “我今天心情不太好” 则自适应调整响应时间，等待用户继续说；全双工模型对话轮次切换准确率达到96.5%。

打断：全双工的关键能力是边说边听，在与用户对话的同时能够持续倾听用户。为了确保理想同学在接收到用户打断语音时，快速停止说话，避免对话重叠，我们采用了流式方案响应用户的打断，打断延迟低至1s。

· 拒识：同时为提升对话连续性，避免错误中断对话，针对用户Backchannel的附和，如“对对对”、“哈哈哈”以及背景噪声等场景进行拒识。

最终，MindGPT-4o-Audio Duplex打断响应率达到99%，Backchannel拒识率达到95%。

1.3 语音知识问答

为了让理想同学拥有行业领先的语音知识问答能力，我们建立了高质量的训练数据管线、高效率的模型能力训练管线，确保了语音知识问答多方面效果达到最优。

· 高质量训练数据管线：

– 后训练数据生产管线：通过外部采集、模型蒸馏、日志回流、指令推理多种方式，生产种类和功能全面的数据，包含语音和文本混合多模态，场景覆盖大模型通用能力和业务场景。数据丰富度相对于之前有非常大的提升，高质量后训练数据达数百万量级；

– 后训练数据质量体系：通过奖励模型打分和人工抽检结合的方式，对数据进行多个维度质量打分。训练数据质量得到有效的确保，数据平均正确率达95%；

– 多模态模型能力标签体系：设计一套完整多模态数据能力标签体系，对训练数据进行能力标注和分类，实现训练数据种类的精确控制，以及训练任务效果的精确控制。多模态能力体系分三层优先级维度，26个能力类目；

· 高效率模型训练管线

我们从两个方面建设模型训练管线：

– 高效数据配比技术：选取最优训练数据规模和能力配比，达到性能和成本均衡最优化。最终实现任务能力100%覆盖，训练数据量相对冗余数据减少89%，模型训练效果相对有提升明显；

– 多阶段和多任务混合训练技术：

多阶段训练：将训练分为预训练（Pretrain）和后训练（Post train）两阶段。预训练阶段使用数百万小时语音数据进行模态对齐，实现语音内容的理解能力。后训练阶段使用语音文本混合数据进行指令对齐，实现多模指令遵循和内容理解能力。

多任务混合训练：将多个核心能力任务和业务能力任务混合在同一阶段训练。核心能力任务包含模态对齐、指令对齐、逻辑推理和内容理解等任务；业务能力任务包含角色扮演、多轮对话和检索增强等能力，实现模型同时提升核心能力和业务能力，并提升模型的泛化能力。

· 高满意度的知识问答效果

通过上述技术，我们提升了模型训练效果，提升模型的核心能力，包括内容理解、指令遵循和逻辑推理等能力；使用Prompt工程提升模型的业务能力，实现了业务快速更新能力；最终确保模型在知识问答和回复风格上达到高准确度，相比MindGPT-3o版本平均提升 6pp。

1.4 多角色对话

当前主流语音交互产品中，通用模型往往呈现出扁平、单一的性格设定，缺乏情感与个性，导致用户难以与其建立深度的沟通连接；而业内具备角色扮演型的语音产品虽然具备一定的语言风格，但由于通用知识能力和工具使用能力的薄弱，难以支撑更广泛的应用场景。为了打造更自然、更具人性化的对话体验，我们从两个核心方向出发：“人物设计” 与 “类人对话”，构建一个兼具情商、智商与工具调用能力的多角色对话能力。

· 角色档案的属性设计：有灵魂、有趣的人物

为打破传统模型中角色形象扁平、情感缺失的问题，我们精心构建了完整的人物设定系统。该系统涵盖十余个维度的大设定，每个维度下包含多个子设定，包括但不限于：

– 人物背景与成长经历

– 说话风格与口头禅

– 性格特征与情绪反应

– 兴趣爱好与价值观

我们的目标是让角色具备如真人一般完整、立体的个体属性。在数据构建上，我们围绕这些人物档案生成专属问答数据和基础人设问答数据。同时为确保模型具备强大的通用能力，我们还构建了覆盖广泛、多样性强的泛化数据集，所有角色回复都经过口语化处理，风格统一为符合角色设定的表达方式，从而增强角色的一致性与真实感。

· 角色数据的生产管线：有温度、有陪伴的对话

为实现拟人化的多轮对话体验，我们采集真实语音交互数据，并基于真实对话范式合成大量模拟对话样本。重点优化的方向包括：

– 情绪识别与情感表达能力

- 多轮对话的意图理解与上下文保持

- 自然、地道的口语化表达

- 主动引导与倾听陪伴能力

通过“拟人化角色设定”与“真实感对话交互”的双轮驱动，我们致力于打造一个既有深度情感连接，又具备实用智能能力的语音交互系统，为用户带来真正自然、有温度的陪伴体验，我们希望用户面对的不再是“一个工具”，而是一个能聊天、会共情、懂回应的朋友。

1.5 高表现力语音生成

为了提升理想同学声音的整体表达效果，我们对表达自然度、推理速度和发音精度三个维度对模型进行了大量的设计与优化。

· 表达更自然：我们验证了对话历史上文语音的引入能够显著提升模型的韵律表达自然度，预训练阶段我们采用了30万小时以上的自建大规模连续对话语音数据库，使得模型具备了对于上文语音语义信息的理解，从而有效提升了模型的韵律表达精度。此外，在副语言表现方面，不借助额外的副语言标签，而是直接通过自然语言文本对副语言进行自适应的理解建模，整体表达效果也更加自然，使理想同学在口语真实感和交互自然度方面，达到了领先水平。

· 反应更快：MindGPT-4o-Audio采用文本token和语音编码混合流式建模，模型生成的语音编码将即时输入音频生成模块转换为语音并播放。有别于传统的整句合成以及依赖文本前端的建模方式，该方案不增加任何额外计算开销，实现了真正意义的流式合成，做到“想到哪就说到哪”，将语音生成的首包整体延时做到了100ms以内。

· 发音更准：模型整体采用了字符级别的建模方案，整体对于发音精度的挑战非常大，我们采用了多种优化策略来持续优化发音精度，包括文本CFG策略、phoneme信息引入、文本正则以及长尾数据增广、DPO优化等方案。最终实测在中文、英文测试集上，发音错误率达到了极低的水平。

1.6 多样风格控制

除了让理想同学具备高表现力的对话合成效果外，我们还赋予了理想同学风格控制的能力。我们希望理想同学能够支持特色风格、口音的扮演能力，同时具备风格的多轮记忆能力。

· 丰富的风格扮演能力：MindGPT-4o-Audio即使在使用默认音色的情况下，也可以根据需要模仿不同的风格、口音。要做到这一点，往往从训练数据上就同一个发音人具备多风格和口音的演绎能力，因此实现难度大，成本高。基于此，我们重新设计了音频编码方案，在最大程度保留韵律表现力的基础上，完成音色信息的解耦，实现风格控制及韵律建模，使得模型具备了各类型情绪演绎、风格扮演和口音模仿能力。

· 语音指令控制能力：MindGPT-4o-Audio还支持显示的语音指令控制，模型具备对多种语音语义指令的泛化性理解，为了提升模型对于风格指令的遵循能力，我们引入大语言模型里的CoT（Chain-of-Thought）技术，设计出了Style CoT方案，模型将先对当前风格信息进行预判，再将其作为输入生成语音，该方案进一步增强了模型对于风格的控制生成能力，使模型能够遵循指令实现风格演绎扮演、语速、语调的调整。另外，大多数的语音交互方案对于风格的触发基本都是单轮触发，缺乏风格的多轮记忆能力，不能做到多轮的风格遵循以及强度等级的风格控制，风格CoT的引入，使得模型具备了对于多轮风格的指令遵循及强度控制能力。

2. 工具能力

为了支持时效性问答、提升知识问答效果，我们基于MindGPT-4o-Audio研发了多模态任务规划和工具调用能力。

2.1 多模态规划

我们实现了MindGPT-4o-Audio的多模态任务规划和工具调用能力，输入语音、文本多模态信息，输出任务和工具调用结果。

· 在任务规划方面，支持多轮对话和时空感知能力，能根据历史上下文信息和当前的时间、位置信息，规划合理任务。比如“现在的金价是多少”，任务规划为“2025年6月6日的金价”，“周末了，给我推荐几个遛娃的地方”，任务规划为“推荐北京市适合遛娃的地方”，然后，将规划出的任务形成DAG（有向无环图）表示，可建模单步任务、并行多任务、多步骤任务之间的拓扑关系，能很好支持复杂任务的规划。

其中，我们建立了高效的智能体后训练数据管线，按照业务维度和能力维度进行数据的构造，使用大模型泛化、线上真实数据回流、人工生产等方式，实现对话全场景的全数据覆盖。我们还设定了严格的数据准出体系，通过模型打分、人工质检的方式对数据进行清洗，确保高质量数据的比例；在训练管线上，我们按照模态和任务的双维度进行科学的数据配比，按照课程学习的思路逐步提升模型从简单任务到复杂任务的规划能力。

· 在工具调用方面，我们使用function calling技术来实现这一能力，并通过一系列工作提升模型对工具选择、参数遵循的能力。

其中，我们的数据管线首先通过清洗高质量开源数据集，获取一批通用工具数据集，然后针对内部业务工具，参考MetaTool的数据构造格式，比如直接泛化生成、关键词生成、细节生成、重复问题处理等方式，构造符合业务需求的工具数据。此外，为针对性强化模型对参数类型和参数格式的指令遵循能力，我们针对性构造区分度不明显的工具数据；在训练管线上，我们进行两阶段训练流程，先进行SFT作为冷启动，让模型初步具备工具调用能力，然后采用RL-DPO，增强模型在工具选择和参数遵循上的能力。

我们实现的多模态任务规划和工具调用在链路延迟和效果上，均有优秀的表现。在链路延迟上，根据语音输入直接进行任务规划，减少了传统链路额外语音识别的时间开销，端到端响应延迟显著领先豆包和ChatGPT；多模态任务规划在业务测试集上准确率达到95.55%；工具调用能力在业务测试集上准确率达到94.25%。在通用工具调用benchmark上，我们也达到业界一流水平。

2.2 工具调用

我们支持知识搜索、体育赛事查询、影视娱乐查询、新闻查询、天气查询、股票信息查询、交通限行信息查询、日历查询、油价查询、汇率查询、商品信息查询等工具，模型解决问题的能力大大提升。

特别在搜索效果优化上，针对多来源信息冲突矛盾、内容丰富度不足等常见问题，我们上线了更细粒度的原子化知识层级（Claim-level）的重排序，以及基于知识推理的扩展搜索技术，大幅提升内容真实性和完整性。理想同学不仅能够获知更实时的热点事件，还能更准确理解专业术语，问答效果显著提升12%。

· 传统搜索技术，以网页搜索为例，一般采用NDCG@k、Precision@k、MAP等评估指标，侧重在粗粒度文档层级衡量效果，无法反映出多文档在细粒度知识层面上的内容重复、遗漏、冲突及错误问题。RAG场景下，搜索结果整体输入大模型，对文档偏序关系不敏感，更需确保在观点层面知识的正确性与完整性。针对这一本质性差异，我们提出Claim-level Rerank技术，通过将多条搜索结果，细化为原子化知识单元Claim的集合，并定义Claim F1值作为RAG搜索的核心评估指标，即关注全部搜索结果中正确Claims的召回率和精确率。我们验证了Claim F1值与大模型RAG问答效果的相关系数达到0.212，较传统搜索的Precision@k指标的相关系数提升2.6倍。

· 面对时效性强、知识密集型或者语义模糊的用户查询时，传统搜索工具，通常面临三大技术瓶颈和挑战：

知识滞后性：大模型依赖静态训练数据，难以应对新兴名词、专业领域术语、突发实时热点事件；

语义鸿沟：用户查询存在拼写错误、概念混淆时，传统模型缺乏验证纠错机制；

扩展同质化：基于语义的朴素扩展方法易产生重复或无意义结果，搜索结果未增加有效信息。

为解决以上问题，我们融合知识图谱增强和MindGPT 3.0的思维链推理能力，实现动态Query理解框架，具备多角度、差异化的改写扩展搜索能力，分钟级覆盖热点事件，搜索结果丰富度提升35%，专业术语识别准确率提升47%，复杂Query无需用户澄清，首次搜索满足率提升28%。

为真实评估理想同学与市面上优秀语音对话产品（豆包、Kimi）在工具调用端到端回复的表现差异，我们从任务维度和场景维度设计并执行了一项用户对比评测。测试者需分别对理想同学、豆包和Kimi三款产品在这些对话场景中回复结果的真实相关性进行评测。统计结果显示，理想同学在不同复杂度任务的对话场景上均优于豆包和Kimi。

3. 安全对齐能力

我们致力于建设符合通用价值观、中国普适价值观、理想同学自身价值观的MindGPT-4o-Audio，为此设计了完备的大模型安全对齐体系，根据MindGPT风险浓度差异，深度融合系统级防御能力和大模型安全对齐能力，使得MindGPT-4o-Audio在满足通用能力显著提升的同时，保持价值观回复能力安全、可控。

· MindGuard：在输入阶段识别用户输入的风险意图，Mind Guard会对高风险的语音输入进行检测拦截；在输出阶段，Mind Guard对极端风险进行识别和拦截，避免风险内容展现给用户；为了不影响语音端到端实时效果，输入和输出安全检测均采用边生成边检测，发现风险进行仲裁；

· 风险领域完备性：开发价值观攻击模型对MindGPT进行自动化、持续性攻击，自动化攻击帮助我们完善安全体系的已知风险领域。对于未知风险领域，安全对齐团队与公司安全团队redteam合作，持续收集各种新增、长尾的风险数据，同时线上日志挖掘也是安全体系新风险扩充的重要一环；

· 安全对齐：PTST、价值观CoT SFT等方法有效降低安全对齐所需的数量，显著提升价值观思考过程有效性和最终回复的无害性，MindGPT-4o-Audio在具备强大的安全推理和思考能力的同时，降低对通用指标的负向影响；

· 价值观安全奖励模型：基于自有安全体系的安全回复准则构建rule based和model based价值观奖励模型，应用于MindGPT-4o-Audio预训练、后训练、安全自动化评估等全生命周期，显著提升了安全对齐的效率和效果。

4. 工程能力

为打造 MindGPT-4o-Audio 高品质的语音交互体验，我们在 MindGPT-3.0 对话系统的基础上全面升级，围绕全双工、低延迟进行了深度优化。其中全双工方面，我们主要应用端云结合的 RTC 通信技术；低延迟方面，我们探索了端云全链路流式架构 + 流式推理技术。

4.1 基于 RTC 的全双工架构

传统的轮次（Turn-based）对话架构只能实现半双工能力，即用户输入和模型回复只能交替进行；而我们借助 RTC 技术，将整个对话架构升级为全双工系统，模型能够在“说话”的同时，实时“听到”当前用户正在说什么，结合模型能力，实现了真正的全双工语音对话（能够实时打断、被打断、甚至“抢话”等能力）：

· 传统的半双工对话，往往依赖于 VAD （Voice Activity Detection）等模块实现下述过程：

– 收声，如检测到用户声音，停止上一轮模型回复的播报；

– 检测用户说话结束，将整段音频作为模型输入；

– 模型生成回复，在端侧调用 TTS 播放；

– 重复 a-c。

· 基于 RTC 的全双工对话，模型能够自己“说”的同时，“听”到用户在说什么，实时判定是否要停止说话（被打断），或者开始说话（打断用户或者正常接话）

– 为用户和模型生成一对一的 RTC “房间”，用户和模型都加入房间；

– 模型实时按帧对齐的，收听用户说的话，以及当前自己说的话；

– 模型自主判定，什么时候打断或被打断 （是否继续播放回复或者停止播放回复）。

4.2 全链路低延迟优化

我们分别在网络接入层、服务架构层、模型推理层进行了低延迟的深度优化，力求达到更自然、流畅的人机交互体验：

· RTC 低延迟、抗弱网优化：

– 低延迟：与传统通信技术（如 websocket）相比，我们采用 RTC 技术，通过弱网补偿、骨干网优化、音频编解码优化等手段，显著降低了通信延迟的同时仍能确保较高品质的音质，平均消息到达延迟下降 67%。

– 抗弱网：通过 RTC 抗弱网技术，我们能够在弱网环境下仍然保持较高的连通率及通话音质，相对传统技术，RTC 信道在较高丢包率的网络环境下仍能保持较流畅的通话体验。

· 全链路流式优化：传统的对话架构在处理多模态信息时往往不够优化：存在 ASR -> LLM -> TTS 级联结构，语音识别结束后才进入大模型推理，大模型推理后才能进入语音合成，存在显著的级联延迟。我们基于 MindGPT-4o-Audio 多模态的能力，消除了级联结构，并在全链路（网络接入、业务逻辑、模型推理等）各个服务层级实现了音频全流式传送，尽可能的将流式音频及时送达各服务模块并启动预计算，实现全链路通信和计算的重叠，从而显著降低了延迟水平。

· 流式推理优化：

– 重叠计算：针对语音模态输入，我们在全链路流式的基础上，重叠了多个模块的推理过程，如双工判定模块和生成模块、文本 Prefill 和 AudioEncoder 模块等；流式推理优化后首 token 延迟从 1s 降到 20ms，语音生成的首包从 500ms 降到 60ms；

– P-D分离 + 多级调度：基于 P-D 分离的思路，将多模推理分解成 AudioEncode、Prefill、Decode 等多个阶段，并且针对不同阶段进行定制的调度策略优化，如 AudioEncode 使用 Static Batching 调度，Prefill 使用 Chunked Prefill 调度，Decoder 使用 Continuous Batching 调度，保证推理性能最优，高并发时仍然可以保持推理延迟在几十毫秒量级；

– 异构计算：推理服务异构计算架构，针对多模推理各阶段的算力需求和并发特点，将其分别部署到异构型号的 GPU 上，以最优化利用机器资源，降低延迟的同时降低了部署成本；对比非异构计算版本，推理成本降低 50%。

4.3 Prompt 平台

此外为了更好支撑业务定制及运营，我们上线了高灵活度的Prompt平台，持续确保业务质量：

· 动态提示词系统：建设一套基于原子指令和组合的动态提示词系统，针对语音大模型定制一套对话系统提示词框架，实现语音对话和知识增强问答能力，增强对话遵循和知识推理能力。使得在线推理格式与模型训练格式100%匹配，同时增加模型认知、模型安全和用户环境信息等核心业务指令遵循能力，确保业务能力覆盖 100%。

· 场景化提示词系统：使用链路信号自动感知技术，实现了场景流量自动圈选能力；并且对圈选的场景定制特定功能提示词框架，确保模型整体功能稳定，实现了场景个性化能力。支持全链路个性化效果定制，可以做到T+0分钟级快速热更新，指令任务达成率 > 95%。

· 角色扮演场景化：使用场景化提示词，实现自动感知角色扮演场景，在模型推理中使用不同提示词框架，使模型输出具有当前场景个性化的角色回复风格。目前上线个性化场景7个，后续可快速更新和新增场景，场景平均达成率 >90%。

关于LLM 训练和推理的 padding

1、LLM padding 细节
2、Prepacking-消除attention padding冗余计算

训练时候可以进行左pad 或者右pad，或者对 prompt 进行左pad，对 label 进行右pad。现在其实一般预训练或者微调的时候都不pad，否则会影响训练效率，大概的思路：假设 batch size = 2，max_seq_len = 16，sequence 1、2、3、4 分别有 7、9、6、10 个 token，那么就可以组成[[s1+s2], [s3+s4]] 进行训练，这个时候需要构造一个正确的 casual attention mask。flash_attn_varlen_qkvpacked_func 接口，就可以实现这样的计算而无需 padding。

batch 推理的时候一般只用左pad。推理时也只有batch推理会有影响，另外左对齐方便所有行同时产生next token。在强化学习训练PPO/DPO/GRPO 的时候需要用到推理，所以也需要做左pad！！

padding_side 的影响

谈到 padding，我们自然要考虑 attention_mask，借助 attention_mask 可以在计算 attention weight 时将 padding 带来的影响屏蔽掉。下面是设置不同的 padding_side，tokenizer 的输出：

没有设置 padding_side 或者 padding_side=’right’：

>>> from transformers import LlamaForCausalLM, LlamaTokenizer
>>> tokenizer = LlamaTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")
>>> tokenizer.pad_token = tokenizer.eos_token
>>> prompts = ["hello llama", "who are you?"]
>>> tokenizer(prompts, return_tensors="pt", padding=True)
{
    'input_ids': tensor([[    1, 22172, 11148,  3304,     2],                                                                                                                                                                                                                         │············
                         [    1,  1058,   526,   366, 29973]]),
    'attention_mask': tensor([[1, 1, 1, 1, 0],  [1, 1, 1, 1, 1]])
}

设置 padding_side=’left’：

>>> from transformers import LlamaForCausalLM, LlamaTokenizer
>>> tokenizer = LlamaTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf", padding_side="left")
>>> tokenizer.pad_token = tokenizer.eos_token
>>> prompts = ["hello llama", "who are you?"]
>>> tokenizer(prompts, return_tensors="pt", padding=True)
{
    'input_ids': tensor([[    2,     1, 22172, 11148,  3304],                                                                                                                                                                                                                         │············
                         [    1,  1058,   526,   366, 29973]]),
    'attention_mask': tensor([[0, 1, 1, 1, 1],  [1, 1, 1, 1, 1]])
}

要理解 padding_side=’right’ 为什么会导致结果不正确，关键的点是 next token 的预测是使用句子的最后一个 token 经过 transformer 层之后输出的 logit 来得到 next token 的。下面是 model.generate通过多次跳转后来到 next token 的处理逻辑：

# https://github.com/huggingface/transformers/blob/a7cab3c283312b8d4de5df3bbe719971e24f4281/src/transformers/generation/utils.py#L2411
        
model_inputs = self.prepare_inputs_for_generation(input_ids, **model_kwargs)

# forward pass to get next token
outputs = self(
    **model_inputs,
    return_dict=True,
    output_attentions=output_attentions,
    output_hidden_states=output_hidden_states,
)

next_token_logits = outputs.logits[:, -1, :]
# argmax
next_tokens = torch.argmax(next_tokens_scores, dim=-1)

从上面的代码可以看到，句子最后一个 token 所对应的 logit 会被用来计算 next token，因此，最后一个 token logit 的计算是否正确决定了推理的结果是否正确。
接下来，我们来看一下 padding_side=’left’ 和 padding_side=’right’，最后一个 token 所对应的 logit 是否是正确计算的。

我们先来看 padding_side=’left’ 的最后一个 logit 的计算过程，省略中间的具体细节，只给出关键的过程），这里只关注句子 “hello llama”：

从图 4 的计算过程可以看到，使用 padding_side=’left’ 的方式，attention score after masked 矩阵的最后一行和 V 的第一列进行内积后得到的值为正确且符合期望的值，即最后一个 token 所对应的 logit 的计算没有受 padding 的影响，该 logit 的计算过程正确。

因为最后一列计算得分时候，V第一行：pad token 的权重【 attention score】都是 0,且attention score 左下角权重为0，那么计算结果最后一列的结果只跟非pad的V有关

我们接下来看一下 padding_side=’right’ 的最后一个 logit 的计算过程：

从图 5 的计算过程可以看到，attention score after masked 矩阵的最后一行和 V 的第一列进行内积后得到的值是不符合期望的，即最后一个 token（pad token）所对应的 logit 的计算不正确，因为 pad token 也参与了计算，而正确预测 next token 的时候 pad token 是不应该参与计算的。

因为最后一列计算得分时候，V最后一行：pad token对应的的权重【 attention score 最后一行】不都是0，，那么计算结果最后一列的结果跟非pad的V有关。

至此，我们弄清楚了为什么 padding_side=’right’ 会产生不正确的结果。

Prepacking-消除attention padding冗余计算

一个batch里，不同的request，其prompt长度不一样，这样计算attention时会做padding，确保所有的request长度相同。如下图所示，1个batch总共4个句子，后面3个句子做了padding，这样做的一个问题就是，会浪费计算。

，一个解决方法是去除padding，把这些句子放在一个句子里计算。如下图所示，去除了padding之后，所有的request放在一个句子里。但是带来的问题是，attention计算只有句子之内的不同token需要进行attention计算（红色计算attention、蓝色计算attention等等），句子之间是独立的。所以这种做法必须要进行适当的数据组织，让我们的attention算子能知道自己该把哪些token放在一个句子里计算。如下图所示，虽然输入到attention算子的是一个句子，包含10个token，但是需要一些额外数据，让attention算子去把红色部分当一个request计算attention、蓝色部分当一个request计算attention、绿色部分当一个request计算attention、黄色部分当一个request计算attention。

预打包在概念上很简单；我们不是将每个序列填充到相同的长度，而是使用现成的装箱算法将多个提示打包在一起，以代替填充标记。

Whisper-Streaming

论文：Turning Whisper into Real-Time Transcription System

code：https://github.com/ufal/whisper_streaming

这篇文章介绍了最近一种先进的多语言语音识别和翻译模型Whisper，然而，它并非设计用于实时转录。在本文中，我们在Whisper基础上构建了Whisper-Streaming，这是一种实时语音转录和翻译的实现，类似于Whisper模型。Whisper-Streaming采用本地协议策略与自适应延迟，以实现流式转录。我们展示了Whisper-Streaming在未分割的长篇语音转录测试集上实现了高质量和3.3秒的延迟，并展示了它作为多语言会议现场转录服务中组件的稳健性和实用性。

Whisper-Streaming的核心组件和内部工作原理。它包括更新循环、音频缓冲区、跳过音频缓冲区中已确认的输出、修剪缓冲区、连接句间上下文，以及可选的语音活动检测。

1. 局部一致性策略（Local Agreement Policy）

Whisper-Streaming 采用局部一致性策略，通过自适应延迟来实现流式转录。该策略通过在连续更新之间寻找最长公共前缀，确保新生成的文本与之前的转录结果一致，从而提高转录的准确性和连贯性。

2. 音频缓冲区与修剪机制

系统维护一个音频缓冲区，实时接收音频数据。当新的音频数据到达时，系统会更新缓冲区，并根据需要修剪掉已确认的部分，以腾出空间处理新的音频数据。这种机制确保了系统能够处理长时间的语音输入，而不会导致内存溢出或处理延迟。

3. 句间上下文连接

为了提高转录的连贯性，Whisper-Streaming 会在处理新的音频段时，考虑前一个音频段的转录结果，从而保持句子之间的上下文一致性。这种上下文连接机制有助于减少转录中的断句和语义不连贯问题。

图1 处理三个连续更新的示例。黄色高亮文本是“提示”，表示要遵循的先前上下文。黑色边框矩形是音频缓冲区，里面的文本是Whisper从该声音段生成的转录文本。蓝色垂直线是时间戳，将缓冲区分为两部分，左边是先前确认的部分，右边是未确认的部分。LocalAgreement-2策略，或搜索最长公共前缀，应用于未确认（右侧）部分的两个连续更新。最长公共前缀用绿色突出显示，绿色下划线突出显示新确认的输出，而绿色虚线下划线表示先前和随后确认的输出。灰色下划线示范了在被忽略的确认部分的更新。

更新循环 Whisper-Streaming的主要部分是一个程序，利用循环接收源音频块并触发流式策略更新。参数MinChunkSize控制延迟和质量，并确定每次迭代处理的最小持续时间。如果更新计算超过MinChunkSize，下一个更新将立即在累积的音频输入上执行。该参数影响延迟和质量。

音频缓冲区 Whisper被训练用于处理长达30秒且包含一个完整句子的序列。它提供标点和单词级别的时间戳。这个过程在图1中有所说明。每次更新都涉及将传入音频存储在音频缓冲区的顶部，并用Whisper处理整个缓冲区。我们保持不变的是缓冲区始终以新句子开头，以保持Whisper的高质量。LocalAgreement-2被应用于当前和先前的Whisper输出。“确认输出”中最后一个单词的时间戳被保存。在后续更新中，我们总是从缓冲区的开头重新处理Whisper，包括上一个“确认输出”时间戳之前的部分（在图1中以灰色背景表示）。确认部分中转录的更改被忽略，因为它们在意义上常常是微不足道的。

跳过确认部分 当确定相对于先前更新的上一个确认单词的转录单词位置时，我们考虑到了由于新音频块导致的Whisper时间戳的潜在不准确性和更新。如果一个单词的时间戳在距离上一个确认单词的1秒间隔内，我们比较其前面的n-gram（其中n的范围从1到5）与上一个确认输出中的后缀。如果它们匹配，我们跳过这些单词。然而，这个规则在未来的工作中可以通过包括诸如设置和微调字符编辑距离阈值、修剪n-gram中的标点符号和大小写等措施来进一步增强。

修剪音频缓冲区 为了避免延迟中不可接受的长峰值，音频缓冲区限制在约30秒左右。当确认输出包含结束句标点符号后面跟着一个开始新句子的单词时，缓冲区会在标点符号的时间戳处被修剪。为此目的使用了语言特定的句子分割工具（例如Koehn等人，2007），确保缓冲区始终包含一个单句。尽管如此，如果缓冲区长度超过30秒，我们会保留由Whisper标记的最后确认的段落。

连接句间上下文 Whisper的转录函数利用“prompt”参数来保持文档内的一致性（一致的风格、术语和句间引用）。我们从先前音频缓冲区的确认输出中提取最后200个单词作为“prompt”参数，如图1所示（黄色背景文本）。

语音活动检测 有一个参数用于激活或停用Whisper的默认语音活动检测（VAD）过滤器，影响质量和延迟。

MWER loss 实现

1、paraformer 负例采样策略：

The implementation of Minimum Word Error Rate Training loss (MWER) based on negative sampling strategy from <Paraformer: Fast and Accurate Parallel Transformer for Non-autoregressive End-to-End Speech Recognition>

https://gist.github.com/TeaPoly/234429e6c2d74d10fcb4987bc541d528

def create_sampling_mask(log_softmax, n):
    """
    Generate sampling mask
    # Ref: <Paraformer: Fast and Accurate Parallel Transformer for Non-autoregressive End-to-End Speech Recognition>
    #       https://arxiv.org/abs/2206.08317
    Args:
        log_softmax: log softmax inputs, float32 (batch, maxlen_out, vocab_size)
        n: candidate paths num, int32
    Return:
        sampling_mask: the sampling mask (nbest, batch, maxlen_out, vocab_size)
    """
    b, s, v = log_softmax.size()

    # Generate random mask
    nbest_random_mask = torch.randint(
        0, 2, (n, b, s, v), device=log_softmax.device
    )

    # Greedy search decoding for best path
    top1_score_indices = log_softmax.argmax(dim=-1).squeeze(-1)

    # Genrate top 1 score token mask
    top1_score_indices_mask = torch.zeros(
        (b, s, v), dtype=torch.int).to(log_softmax.device)
    top1_score_indices_mask.scatter_(-1, top1_score_indices.unsqueeze(-1), 1)

    # Genrate sampling mask by applying random mask to top 1 score token
    sampling_mask = nbest_random_mask*top1_score_indices_mask.unsqueeze(0)

    return sampling_mask

2、CTC decoder mwer loss：

https://github.com/Mddct/losses/blob/main/py/mwer.py

关键：计算前缀束搜索候选路径

self.ctc_prefix_beam_decoer = CTCDecoder(beam_width=beam_width,top_paths=beam_width)

wenet/wenet/transducer/search/greedy_search.py
wenet/wenet/transducer/search/prefix_beam_search.py

3、其他：wenet

https://github.com/wenet-e2e/wenet/tree/main#

wenet/wenet/transformer/ctc.py

wenet/wenet/transformer/label_smoothing_loss.py

Attention-based 自动语音识别（ASR）模型的 Beam Search 解码过程：wenet/wenet/transformer/search.py

Paraformer-v2: An improved non-autoregressive transformer for noise-robust speech recognition

代码：https://github.com/NiniAndy/Paraformer-V2
论文：https://arxiv.org/abs/2409.17746

原始 Paraformer 在非自回归语音识别方面取得了显著成效，尤其在普通话任务中表现突出，但其也存在一些局限性，特别是在跨语言适配和噪声鲁棒性方面。

背景：

1. 多语言适配能力有限（Multilingual Limitations）

CIF 模块难以适应非拼音型语言（如英语）：
原始 Paraformer 使用 CIF（Continuous Integrate-and-Fire） 预测每个 token embedding。该机制假设每个语音片段可以通过声学模式推断出输出 token 数量。但英语等语言往往使用 BPE（Byte Pair Encoding） 等子词单元，token 数量波动大、边界不规则，CIF 很难准确预测 token 数。

在英语、法语等语言上性能显著下降；
CIF 在 token 数量估计不准时，会导致对齐错乱、token 重复或丢失。

2、对噪声敏感（Noise Sensitivity）

CIF 预测 α 权重完全基于声学表示，不含语义约束：
- 如果输入中含有背景噪声（如会议环境），CIF 模块可能将噪声解释为有意义的语音特征；
- 导致触发 α → β 条件时“错误地触发 token”，产生虚假输出。

噪声环境下 WER/CER 明显上升；
无语音输入时仍有输出（无法正确“输出空白”）。

3. 训练对目标长度高度敏感

CIF 模块需预测 token 数量，训练时必须强制调节 α 的归一化，使 token 数接近 ground truth；
若目标长度估计不准，Decoder 会收不到足够 token embedding，导致学习不稳定

原始Paraformer：

Encoder 提取帧级表示：

CIF 生成 token embedding：使用 CIF（Continuous Integrate-and-Fire） 模块将帧级特征聚合为 token embedding 序列：

CIF 中权重 α 的生成：

Decoder 并行预测：

为使预测长度 U′U’U′ 尽可能接近 ground truth 长度 UUU，训练时需要对α1:T 做归一化：

Decoder 并行预测：Decoder 是一个 双向 Transformer

Loss：

改进：

利用 CTC 模块来获取 token embedding，事实证明，该模块具有更好的多语言适应性和更强的抗噪性。

使用 CTC 模块提取 Token Embedding：

生成帧级 posterior：类似于标准 CTC 解码头，对每一帧计算 token 分布（含 blank）

Greedy 解码得到 token 序列：

每一帧取最大概率的 token index（可能含 blank 和重复）

压缩 token 序列（Remove blanks & merge repeats）：

对重复 token 合并并平均其 posterior，得到 token 数量为 U′U’U′ 的 embedding 概率序列，去除 blank；

映射为 Token Embedding：

并行 Decoder 解码（Bidirectional）：（没有因果掩码（causal mask）限制上下文访问，每个位置的 token 同时关注其左侧和右侧所有位置）

CTC 压缩后的长度 U′U’U′ 和真实 token 长度 UUU 不一致，导致无法直接计算 CE Loss，解决方法：使用 Viterbi 对齐 将 CTC posterior 对齐到 target：

其中 A1:T 是 Viterbi 解码得到的帧与 token 的对齐序列；
这样生成的压缩 posterior 长度严格等于目标长度 U。

Paraformer-v2 同时优化：

Decoder 输出与目标之间的 CE Loss；
Encoder 输出与目标之间的 CTC Loss。

实验结果：

实际训练疑问：

新一代 Kaldi 热词识别功能

转自：https://mp.weixin.qq.com/s/d7Ab9u1_OAGLF76V1ymHmg

什么是热词

热词其实是一个特别容易引起歧义的说法，尤其是在语音领域，比如唤醒次/命令词/新词都有人称之为热词，本文中要讨论的热词识别是在语音识别语境下的“上下文词语偏置”对应的英文为 contextual biasing。热词识别到底是做什么的呢？举一个例子就非常清楚了，比如：“今天河南省教育厅有关领导参观了南阳理工大学” 这样一句话，很多的语音识别系统应该会识别成 “今天河南省教育厅有关领导参观了南洋理工大学”，“南阳理工大学”和“南洋理工大学”音同字不同，训练语料中“南洋理工大学”又大概率多于“南阳理工大学”，所以模型非常倾向于输出“南洋理工大学”。热词识别要实现的就是，给定一些外部条件，让系统了解我们当前想要说的是“南阳理工大学”而不是“南洋理工大学”。

热词的实现方法

热词的实现方法大致可以分为两大类，一类是纯字符串匹配方法，一类是NN 神经网络 方法。顾名思义，纯字符串匹配的方法就是将解码过程中的所有可能路径都一一去匹配热词列表，如果匹配上热词就给对应的路径加上分数奖励，这样该路径就更有可能在 beam 剪枝中胜出，从而实现识别热词的功能。这种方法一般是在解码阶段实现，对声学部分是透明的，而且可以随意调整奖励的分数，比较灵活。需要解决的核心问题是高效的查找，一般都是基于自动机来实现，在解码器中附带一个类似于下图的热词图。

NN 方法其实非常多，近年也是大家发论文的热点（贴一个 awesome https://github.com/stevenhillis/awesome-asr-contextualization，有兴趣的同学可以去看论文），但总的来说就是将热词列表作为神经网络的其中一个输入，以此改变神经网络输出的分布，这样神经网络就能更大概率识别出热词。此种方法的使用需要在训练模型时进行干预，也就是说如果你需要一个带热词识别功能的模型，你就得重新训一个模型，最起码得在不带热词识别功能模型的基础上做 finetune。下图是一种可能的实现方式，通过热词列表来对 transducer 的 predictor 网络进行偏置。

实际的使用中也常常将两者一起配合使用，本文讨论的是第一种纯字符串匹配的热词实现方法。

基于 Aho-corasick 的热词实现

上文提到基于匹配的热词识别主要解决的是匹配效率问题，所以基本都使用自动机来实现，openfst 作为一个高效的自动机实现受到绝大部分人的青睐，但对于热词识别，还是有一些欠缺。比如，如果不进行较复杂的状态管理，则一次只能进行一个热词的匹配，这个问题 wenet 在其实现中有举例说明。如下所示，“唯品会”和“欧阳唯一”都是热词，但“欧阳唯品会”这条路径却无法匹配到“唯品会”。（openfst 当然可以实现这些功能，但会增加复杂度以及影响效率。）

热词的实现本质是一个多模匹配问题，它需要在 hypothesis 中搜索是否包含给定的热词列表，而多模匹配的最佳数据结构就是 Aho-corasick 自动机。关于 Aho-corasick 的构建细节本文不做过多叙述，感兴趣的同学可以阅读（https://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_algorithm）。

下面将一步一步叙述其怎样用于热词识别，下图是一个包含了热词 { "S", "HE", "SHE", "SHELL", "HIS", "HERS", "HELLO", "THIS", "THEM"} 的状态图（图要有一定复杂度才能够说明问题，爱学习的你一定会认真看的），Aho-corasick 图中主要有三种类型的边，goto 边（黑箭头），failure 边（红箭头）和 output 边（绿箭头），简单地说，匹配走 goto 边，匹配失败则走 failure 边直到匹配为止或者回到 ROOT 节点，而只要 output 边存在即表示命中热词 (理论上每一个终止节点都有一个指向自己的 output 边，下图中未体现）而且得沿着 output 边的路径一直回溯到没有 output 边为止。

图中每条 goto 边都有一个分数，每个节点含有两个分数（node_score, local_node_score)，node_score 为全局节点的分数即从 ROOT 节点到目前的路径分数和，local_node_score为局部节点分数即从上一个中止节点[匹配到热词的节点]到目前的路径分数和，匹配 failure 的分数为 dest.node_score - src.local_node_score（图中未画出，因为 dest 可能需要回溯几条 failure 边才能到达）。我们想在热词局部命中时就给予一定分数奖励，防止 beam search 过程将可能的热词路径剪掉，所以会有如此复杂的分数设计，部分命中给予奖励需要在匹配失败时对已施加的分数进行补偿或消除。奖励分数究竟应该在完全命中后才施加还是局部命中就预先给予，每个人有不同的看法，笔者未进行过严格的性能对比，k2 中目前的实现参照 Deep context (https://arxiv.org/pdf/1808.02480.pdf) 中 on the fly rescoring 一节所述，每匹配一个 token 都会施加分数奖励。

我们以 “DID_HE_WANT_HERS_SHELF” (注意空格 _ 也是字符），来说明整个过程是如何匹配的，以及奖励分数如何作用到路径。“DID_” 几个字符未匹配任何热词的前缀，状态一直停留在 ROOT （ROOT 的 failure 是它自己）。“H” 匹配 state 0 到 state 2 的边获得奖励 1，“E” 匹配 state 2 到 state 3 的边获得奖励 1（total 为2），此时命中 “HE” 获获得奖励 2 （total 为 4），“_” 未匹配上沿着 state 3 的 failure 边回到 ROOT 减去奖励 2 （total 为2），“WAN” 未匹配任何前缀状态一直停留在 ROOT，“T” 匹配 state 0 到 state 15 的边获得奖励 1 （total 为 3），“_” 未匹配上沿着 state 15 的 failure 边回到 ROOT 减去奖励 1 （total 为2），“H” 匹配 state 0 到 state 2 的边获得奖励 1 （total 为3），“E” 匹配 state 2 到 state 3 的边获得奖励 1（total 为4），此时命中 “HE” 获得奖励 2 （total 为 6），“R” 匹配 state 3 到 state 10 的边获得奖励 1（total 为7），“S” 匹配 state 10 到 state 11 的边获得奖励 1（total 为8），此时命中 “HERS” 获得奖励 4 （total 为 12），state 11 包含 output 边指向 state 1 即命中 “S”获得奖励 1 （total 为13）， “_” 未匹配上沿着 state 11 的 failure 边回到 ROOT 减去奖励 4 （total 为9），“S” 匹配 state 0 到 state 1 的边获得奖励 1 （total 为 10），此时命中 “S” 获得奖励 1 （total 为11），“H” 匹配 state 1 到 state 4 的边获得奖励 1 （total 为 12），“E” 匹配 state 4 到 state 5 的边获得奖励 1 （total 为 13），此时命中 “SHE” 获得奖励 3 （total 为 16），state 5 还有 output 边指向 state 3 即命中 “HE” 获得奖励 2 （total 为 18），“L” 匹配 state 5 到 state 6 的边获得奖励1 （total 为 19），“F” 为匹配上沿着 state 6 的 failure 边到达 state 12， state 12 依然没能匹配 “F” 沿着 state 12 的 failure 边回到 ROOT 减去奖励 4 （state 6 的 node_score）（total 15），匹配结束。“DID_HE_WANT_HERS_SHELF” 命中 “HE”，“HE”，“HERS” ，“S”，“S”，“SHE”， “HE” 获得 15 的分数奖励。下面还有一些测试样例，可以帮助理解整个匹配过程，实际的热词识别匹配不会这么复杂，能命中一两个热词就已经足够在 beam search 胜出了。

queries = {
        "HEHERSHE": 14,  # "HE", "HE", "HERS", "S", "SHE", "HE"
        "HERSHE": 12,  # "HE", "HERS", "S", "SHE", "HE"
        "HISHE": 9,  # "HIS", "S", "SHE", "HE"
        "SHED": 6,  # "S", "SHE", "HE"
        "HELL": 2,  # "HE"
        "HELLO": 7,  # "HE", "HELLO"
        "DHRHISQ": 4,  # "HIS", "S"
        "THEN": 2,  # "HE"
    }
    for query, expected_score in queries.items():
        total_scores = 0
        state = context_graph.root
        for q in query:
            score, state = context_graph.forward_one_step(state, ord(q))
            total_scores += score
        score, state = context_graph.finalize(state)
        assert state.token == -1, state.token
        total_scores += score
        assert total_scores == expected_score, (
            total_scores,
            expected_score,
            query,
        )

Wenet 中也有基于 Aho-corasick 实现的热词，但暂时还没有合并，可以在 wenet 仓库的 pull requests 里查找。

一些实验结果

热词的实验结果跟测试集关系很大，下面放的是早期的一些测试结果，具体效果怎样，请在自己的测试集上实验。下面测试中的热词均为测试集对应 transcript 文本上用 NER 工具提取的短语，并做了适当筛选去除特别容易识别的短语。

Aishell 测试集（包含 1073 条热词）：

Librispeech 测试集 (包含 487 条热词）：

可以看出，该实现对 contexts 子集有较明显的提升，而对其他测试集基本没有影响。

k2 热词功能现状

k2 的热词功能实现已经有一段时间了，由于作者比较懒忙一直没有全面支持，目前 icefall 中的 librispeech pruned_transducer_stateless4 recipe 和 wenetspeech pruned_transducer_stateless5 recipe 已经支持，zipformer 模型正在 PR 中（很快合并）。sherpa 和 sherpa-onnx 中已经实现了核心功能，并且封装了 python 的 API，因为已经有很好的样例，所以我们当然非常希望社区的小伙伴能一起帮忙完善，但如果你们也很懒忙，也可以在微信群告诉我们或者在 github 仓库提 issue，我们会根据需要来安排优先级，目前我们收到的两个提议是支持 sherpa-onnx android 平台和 sherpa-ncnn。

Ke-Omni-R :通过思考实现高级音频推理

Github:https://github.com/shuaijiang/Ke-Omni-R 【开源训练和推理代码】

贡献：用于将GRPO/思考过程加入到语音大模型的强化训练过程中。

[1] Xie, Zhifei, et al. “Audio-Reasoner: Improving Reasoning Capability in Large Audio Language Models.” arXiv preprint arXiv:2503.02318.
[2] Ma, Ziyang, et al. “Audio-CoT: Exploring Chain-of-Thought Reasoning in Large Audio Language Model.” arXiv preprint arXiv:2501.07246.
[3] Li, Gang, et al. “Reinforcement Learning Outperforms Supervised Fine-Tuning: A Case Study on Audio Question Answering.” arXiv preprint arXiv:2503.11197
[4] Xu, Jin, et al. “Qwen2.5-Omni Technical Report.” arXiv preprint arXiv:2503.20215

Ke-Omni-R 是基于 Qwen2.5-Omni 构建的高级音频推理模型。构建音频推理模型，通过强化学习引入深度思考过程，提升复杂任务的理解和推理能力。仅使用 10,000 个训练后样本，Ke-Omni-R 就在 MMAU Test-mini 和 Test 基准测试中取得了最佳性能。其开发过程中的关键洞察包括：

GRPO 算法 ：GRPO 算法显著增强了已经很强大的基础模型（Qwen2.5-Omni-7B）的性能，即使在看不见的语音领域也表现出卓越的泛化能力。
思考过程 ：融入简洁的思考过程（少于 50 个字）对于提高推理能力起着至关重要的作用。
KL 散度 ：通过利用 KL 散度，在 GRPO 训练期间观察到轻微的改进。
领域比例 vs. 数据量 ：领域多样性比数据量更重要。我们仅使用了 10,000 个样本，其中 5,000 个从 AVQA 中随机选取，另外 5,000 个从 MusicBench 中选取。

Performance: Accuracies (%)↑ on MMAU Test-mini and Test benchmark

Model	Method	Sound (Test-mini)	Sound (Test)	Music (Test-mini)	Music (Test)	Speech (Test-mini)	Speech (Test)	Average (Test-mini)	Average (Test)
–	Human*	86.31	–	78.22	–	82.17	–	82.23	–
Gemini Pro 2.0 Flash	Direct Inference*	56.46	61.73	58.68	56.53	51.65	61.53	55.60	59.93
Audio Flamingo 2	Direct Inference*	61.56	65.10	73.95	72.90	30.93	40.26	55.48	59.42
GPT4o + Strong Cap.	Direct Inference*	57.35	55.83	49.70	51.73	64.86	68.66	57.30	58.74
Llama-3-8B-Instruct + Strong Cap.	Direct Inference*	50.75	49.10	48.93	48.93	55.25	62.70	52.10	53.57
Qwen2-Audio-7B-Instruct	Direct Inference*	54.95	45.90	50.98	53.26	42.04	45.90	49.20	52.50
SALAMONN	Direct Inference*	41.00	40.30	34.80	33.76	25.50	24.24	33.70	32.77
Audio-Reasoner(Qwen2-Audio-7B-Instruct)	[1]	60.06	–	64.30	–	60.70	–	61.71	–
Audio-Cot(Qwen2-Audio-7B-Instruct)	[2]	61.86	–	56.29	–	55.26	–	57.80	–
R1-AQA(Qwen2-Audio-7B-Instruct)	[3]	68.77	69.76	64.37	61.40	63.66	62.70	65.60	64.36
Qwen2.5-Omni-7B	[4]	67.87	–	69.16	–	59.76	–	65.60	–
Qwen2.5-Omni-3B	[4]	70.27	–	60.48	–	59.16	–	63.30	–
Ke-Omni-R-3B(Qwen2.5-Omni-3B)	GRPO w/ think (ours)	72.37	71.87	65.57	59.60	64.26	64.17	67.40	65.17
Ke-Omni-R(Qwen2.5-Omni-7B)	GRPO w/o think (ours)	69.67	70.57	67.66	64.00	66.37	67.17	67.90	67.24
Ke-Omni-R(Qwen2.5-Omni-7B)	GRPO w/ think (ours)	69.37	71.90	69.46	67.13	67.87	67.10	68.90	68.71

Performance: CER/WER (%)↓ on ASR benchmark

Model	Method	WenetSpeech test-net	WenetSpeech test-meeting	LibriSpeech test-clean	LibriSpeech test-other
Qwen2.5-Omni-3B	[4]	6.3	8.1	2.2	4.5
Qwen2.5-Omni-7B	[4]	5.9	7.7	1.8	3.4
Ke-Omni-3B	ours	11.7	16.1	1.8	3.8
Ke-Omni-7B	ours	7.5	9.8	1.6	3.1

摘要：

Introduction

方法

模型

Neural audio codec

Joint modeling of discrete audio tokens

Translation as multistream modeling

Alignment and synthetic interpretation data

文本域比齐

音频域对齐

声音迁移（Voice Transfer）

Experiments

训练策略

推理：

Results

推理能力

局限性

Kyutai STT

语义语音活动检测器

低延迟

高吞吐量

延迟流建模

Kyutai TTS

State of the art

适合大语言模型（LLM）

语音克隆

长时段生成

词级时间戳

延迟流建模

1. 模型能力

​1.1 整体算法方案

​1.2 全双工语音对话：MindGPT-4o-Audio Duplex

​1.3 语音知识问答

​1.4 多角色对话

1.5 高表现力语音生成

​​1.6 多样风格控制

2. 工具能力

​2.1 多模态规划

​2.2 工具调用

​3. 安全对齐能力

4. 工程能力

4.1 基于 RTC 的全双工架构

​4.2 全链路低延迟优化

4.3 Prompt 平台

padding_side 的影响

Prepacking-消除attention padding冗余计算

1、paraformer 负例采样策略：

2、CTC decoder mwer loss：

3、其他：wenet

背景：

原始Paraformer：

改进：

实验结果：

实际训练疑问：

什么是热词

热词的实现方法

基于 Aho-corasick 的热词实现

一些实验结果

k2 热词功能现状

Performance: Accuracies (%)↑ on MMAU Test-mini and Test benchmark

Performance: CER/WER (%)↓ on ASR benchmark

1.1 整体算法方案

1.2 全双工语音对话：MindGPT-4o-Audio Duplex

1.3 语音知识问答

1.4 多角色对话

1.6 多样风格控制

2.1 多模态规划

2.2 工具调用

3. 安全对齐能力

4.2 全链路低延迟优化