MiniMax Music 3.0-音乐创作模型

MiniMax Music 3 是一种高性能的音乐创作模型,能够生成时长可达五分钟的完整歌曲。该模型基于歌词和详细的音乐描述进行创作,能够生成结构紧凑、富有表现力的歌曲,同时具备稳定的长音频质量。只需提供一个创意想法和可选的歌词,模型即可在一次生成中完成作曲、编曲、演唱与制作,创作出一首完整的歌曲。

从音乐描述、语言模型到声音渲染重新设计了整条生成链路:用细粒度时序描述呈现情绪、配器与演唱的发展,以全局—局部协作的 Hybrid-LM 兼顾长程结构和声学细节,再通过多层 RVQ、Hidden States 融合与 Flow-Matching/Flow-VAE 提升最终声音的保真度。由此带来三项核心升级:更准确地理解创作意图、更完整且富于变化的编曲,以及更清晰、更自然的声音表现。

MiniMax Music 3 模型结合了一个 8 亿参数的全局语言模型,用于构建长期的音乐结构;以及一个 0.6 亿参数的局部语言模型,用于处理帧级的声音细节。该模型还采用了基于流匹配和流变显式估计的连续隐藏状态合成系统。最终,该模型能够生成 32 kHz 采样率、16 位立体声的 WAV 音频文件。

MiniMax Music 3.0 技术解析:开放权重音乐模型如何实现完整歌曲生成

MiniMax 正式推出新一代音乐生成模型 MiniMax Music 3.0。用户只需输入一个创意想法,并根据需要提供歌词,模型便可以在一次生成中完成作曲、编曲、演唱与制作,生成最长约 5 分钟的完整歌曲。

与只追求“生成一段好听音频”的传统方案不同,Music 3.0 更关注创作者意图能否贯穿整首作品:情绪是否持续一致,乐器是否按照结构合理进入和退出,人声是否自然,歌曲是否具有完整而连贯的发展。

MiniMax 官方将 Music 3.0 定义为开放权重、生产级全能音乐模型。其核心技术路线由 Tokenizer、Hybrid-LM 和 Synthesis 三个部分组成,并通过 Structured Caption、Hidden State Fusion、Flow-Matching 和 Flow-VAE 等技术,提升音乐结构、编曲细节与声音质量。

一、Music 3.0 解决了音乐生成中的哪些难题?

音乐生成看似只需要“输入提示词、输出音频”,但真正困难的地方在于如何把抽象的创作要求转化为可持续执行的音乐结构。

  • 用户指定的乐器能否贯穿整首歌曲,而不是只在开头出现?
  • 歌曲从主歌进入副歌时,情绪是否有自然的铺垫和释放?
  • 长达数分钟的生成过程中,节奏、调性和人声是否保持稳定?
  • 复杂编曲中,鼓组、贝斯、人声和旋律乐器能否保持清晰分离?
  • 生成的人声是否具有自然的发音、换气、连贯性和情感变化?

Music 3.0 的设计目标,正是同时解决这些问题。它不仅要生成一段合理的音乐,还要尽可能实现一套完整、连贯的创作构想。

二、三层技术架构:Tokenizer、Hybrid-LM 与 Synthesis

Music 3.0 的完整生成流程可以概括为三个阶段:

  1. Tokenizer:将音乐压缩成适合模型理解和预测的多层离散表示。
  2. Hybrid-LM:同时建模歌曲的全局结构和局部声学细节。
  3. Synthesis:将语言模型理解到的音乐信息还原为高保真音频。

1. 多层 RVQ:分离音乐结构与声学细节

Music 3.0 使用八层残差向量量化(Residual Vector Quantization,RVQ)表示音乐信息。

  • 第一层主要负责音乐的核心语义和结构。
  • 第二至第八层逐步补充声学残差和声音细节。
  • 第一层使用大小为 16,384 的码本。
  • 第二至第八层分别使用大小为 1,024 的码本。

在训练过程中,模型会先单独训练第一层,使其建立稳定的音乐信息骨架,再联合训练全部八层。这样的分层设计,可以避免单层 Token 同时承担过多的结构和音质信息,也有助于降低长歌曲生成时的累计误差。

2. Hybrid-LM:全局结构与局部声学协同建模

为了兼顾长程结构和局部细节,Music 3.0 采用了全局模型与局部模型协同工作的 Hybrid-LM 架构。

  • 8B Global LLM:基于 Qwen3.5-8B 初始化,负责逐帧预测音乐语义 Token,并理解整首歌曲的上下文、结构和发展方向。
  • 0.6B Local LLM:随机初始化,负责在每一帧内部沿深度轴预测声学 Token,补充局部的音色、演奏和声音细节。

训练过程分为两个阶段。第一阶段主要建立 Global LLM 对音乐语义的预测能力;第二阶段则对 Global LLM 与 Local LLM 进行全参数联合训练。

这种“全局负责方向、局部负责细节”的分工,使模型能够在最长 5 分钟的歌曲中保持结构稳定,同时保留不同段落应有的变化。

3. Hidden State Fusion:从离散预测走向连续声音渲染

传统音乐生成流程通常会将离散声学 Token 直接送入解码器。Music 3.0 则进一步融合 Global LLM 与 Local LLM 的连续 Hidden States,并将其作为声音生成模块的条件输入。

官方公布的声音生成链路为:

LLM 融合特征 → Flow-Matching → VAE Hidden States → Flow-VAE Decoder → 最终音频

其中,2.4B Flow-Matching 模块负责将融合后的语言模型特征映射至 VAE 隐空间;123M Flow-VAE 则负责完成最终的音频解码。

相比只依赖离散 Token,连续 Hidden States 能够保留更多高维声学信息,从而改善人声发音、乐器连贯性和音乐细节表现。

三、Structured Caption:让模型真正理解创作意图

音乐提示词最大的难点,是很多听感描述并不能直接转化为可执行的生成条件。例如,“温暖但克制”“逐渐变得宏大”“像一场现场演出”等表达,对人类音乐制作人来说很直观,但对模型而言却需要更细粒度的结构化描述。

Music 3.0 使用 Structured Caption 对音乐进行细粒度的时序描述。它不仅描述曲风,还会进一步说明:

  • 速度、拍号与调性;
  • 音乐情绪如何随时间变化;
  • 主奏和伴奏乐器何时进入、叠加或退出;
  • 鼓组、贝斯和律动基础如何发展;
  • 人声的音色、唱法、气声、假声与和声;
  • 空间感、混音质感、Delay 和 Autotune 等效果。

这套描述方式将抽象的音乐感受转化为更接近专业编曲语言的生成条件,使模型能够在歌曲发展过程中维持统一的音乐身份,同时保留合理的动态变化。

Prompt Enhancement:降低专业音乐创作门槛

为了让非专业用户也能使用这些复杂的音乐描述,MiniMax 构建了基于模板的 Prompt Enhancement System。

系统可以从专业 Structured Caption 模板库中选择合适的表达,并结合音乐术语与编曲规则,将用户的一句话扩展为逻辑更完整、细节更丰富的结构化提示词。

例如,用户只需输入“做一首温暖、克制的不插电歌曲”,系统就可以进一步补充人声类型、吉他演奏方式、空间感、动态变化和混音方向,使最终结果更接近用户真正想要的作品。

四、更完整、更富于变化的长歌曲编曲

长歌曲生成并不只是把音频“延长”。真正的难点在于让不同段落之间形成合理的发展关系。

Music 3.0 支持使用段落标签描述歌曲结构,包括:

  • [intro]:前奏
  • [verse]:主歌
  • [pre-chorus]:副歌前段
  • [chorus]:副歌
  • [bridge]:桥段
  • [instrumental]:器乐段
  • [solo]:独奏段
  • [outro]:尾奏

这些标签提供宏观结构,而 Structured Caption 则进一步描述每个时间阶段中的情绪、配器、人声、节奏和空间效果。两者结合后,模型可以更好地理解“哪里应该发生什么变化”。

在模型侧,8B Global LLM 负责维护全曲上下文,0.6B Local LLM 负责补充每个时间帧内的声学细节。这样的协作机制,可以帮助歌曲保持整体方向,同时避免长时间生成中出现段落重复、编曲单一或情绪突然中断。

五、声音品质升级:更清晰的混音与更真实的乐器

Music 3.0 在声音表现方面也进行了系统升级,目标是让混音更加开阔、清晰和平衡,减少传统生成音乐中常见的拥挤与浑浊感。

多层 RVQ 负责保留从核心结构到声学细节的不同层次信息;Hidden State Fusion 则在连续特征层面连接语言模型和声音渲染模块。通过这两种方式,模型可以更准确地响应具体的乐器指令,并呈现滑音、连奏等更接近真实演奏的技法。

  • 独奏乐器的触弦、运弓和演奏细节更加清晰;
  • 鼓组和贝斯具有更明确的冲击力与层次;
  • 复杂电子编曲中的声部分离度更高;
  • 低频保持力量感,同时减少对其他声部的遮蔽;
  • 人声周围的空间感更加自然。

六、重塑自然人声:减少“机器感”

人声往往是生成音乐中最容易暴露机器感的部分。高频伪影、发音不清、乐句僵硬、不自然的换气,都会影响听众对歌曲情感的感受。

Music 3.0 通过新的声音渲染系统,对音色、唱法、气声、假声、和声以及 Delay、Autotune 等人声效果进行更细致的描述。

结合 Global LLM 与 Local LLM 的连续 Hidden States,Flow-Matching 和 Flow-VAE 可以将这些演唱信息带入最终的音频生成过程,从而改善:

  • 歌词发音的准确性;
  • 旋律线条的连贯性;
  • 主歌与副歌之间的情绪变化;
  • 呼吸和停顿的自然程度;
  • 多层和声与主唱之间的融合。

理想情况下,生成的人声可以从克制的主歌逐渐过渡到开阔的副歌,也可以根据歌曲风格完成节奏型演唱、持续旋律、气声和声等不同表达。

七、一个适合 Music 3.0 的提示词示例

如果希望获得更稳定的结果,可以参考以下结构编写提示词:

温暖的中文流行抒情歌曲,74 BPM,A♭大调。
情绪从克制怀旧逐渐发展到温暖明亮的副歌。
成熟男中音,细腻但不过度夸张的演唱,
以钢琴、木吉他、古筝和柔和弦乐为主要配器。
主歌保持留白,副歌加入鼓组和宽阔和声,
整体采用自然的现场录音室混音质感。

[Intro]
[Verse]
[Pre-Chorus]
[Chorus]
[Bridge]
[Final Chorus]
[Outro]

这个提示词同时包含了风格、速度、调性、情绪发展、人声特征、配器、混音方向和歌曲结构,通常比单独输入“生成一首温暖的中文歌曲”更容易得到稳定、可控的结果。

八、Music 3.0 对 AI 音乐创作的意义

从技术路线来看,Music 3.0 的重点并不是单一模型规模的提升,而是对音乐生成全链路进行重新设计。

  • Tokenizer 负责把音乐拆解为结构与细节;
  • Hybrid-LM 负责同时理解长程结构和局部声学;
  • Structured Caption 负责把创作者意图转化为可执行描述;
  • Hidden State Fusion 负责连接语言理解与连续声音渲染;
  • Flow-Matching 与 Flow-VAE 负责还原更高保真的最终音频。

这意味着 AI 音乐正在从“生成一个片段”逐步走向“完成一首作品”。对于音乐人、短视频创作者、游戏开发者、影视制作团队和普通用户来说,未来的重点不再只是能否生成音乐,而是能否更准确地表达创作意图,并在生成过程中保持结构、情绪和声音质量的一致性。

结语

MiniMax Music 3.0 通过多层 RVQ、Hybrid-LM、Structured Caption、Prompt Enhancement、Hidden State Fusion、Flow-Matching 和 Flow-VAE 等技术,试图解决音乐生成中最具挑战的几个问题:长歌曲结构稳定、编曲具有发展、人声更加自然,以及复杂混音中的细节还原。

它所展示的方向非常明确:音乐生成不应只是“听起来像音乐”,而应该更加接近真正的创作流程,让用户可以从一个想法出发,逐步得到一首完整、连贯并具有制作质感的歌曲。

关于模型权重、使用方式和具体开放政策,请以 MiniMax 官方最新发布页面为准。

参考资料:
MiniMax Music 3.0:新一代开放权重、生产级全能音乐模型|MiniMax 官方技术博客

ParaASR:用 MTP 加速 4B 大模型语音识别,30 分钟音频一次完成转写

大语言模型正在成为自动语音识别的新型解码器:它能更好地处理同音词、标点恢复、专有名词、中英文混说和长距离上下文,但也带来了一个直接问题——解码器越大,每生成一个 token 的成本越高,长音频转写尤其容易受到延迟限制。

StepFun 团队在论文《ParaASR: Multi-Token Prediction for Fast and Long-Context LLM-Based Speech Recognition》中提出 ParaASR。它使用冻结的 0.6B 音频编码器和 4B 稠密 Transformer 解码器,并在解码器后加入五个 Multi-Token Prediction(MTP)分支,让模型每次前向计算最多提出 6 个 token,再通过自回归路径验证并接收其中正确的连续前缀。

论文报告 ParaASR 平均每次前向计算可接收 5.0 个 token,在单张 NVIDIA H800、单并发条件下达到 0.0053 的实时因子(RTF)。模型保留原生 32K 上下文,可在一次解码会话中处理最长约 30 分钟音频。其中文、英文和长音频基准平均错误率分别为 2.97%、3.68% 和 3.70%。

论文ParaASR: Multi-Token Prediction for Fast and Long-Context LLM-Based Speech Recognition
机构StepFun,合作作者来自 NTU、PKU、UNSW、SJTU、USTC
版本arXiv:2607.29279v1,2026 年 7 月 31 日
模型规模0.6B 音频编码器 + 4B LLM 解码器 + 5 个 MTP 分支
核心能力多 token 并行提议、自回归验证、32K 长上下文、最长约 30 分钟单次转写

一、研究背景:大解码器带来质量,也带来逐 token 延迟

传统 ASR 主要围绕 CTC、Transducer 或声学序列建模展开。近年来,系统逐渐转向“音频编码器 + 适配器 + 大语言模型解码器”的架构:音频编码器提取声学证据,LLM 根据音频表征和已经生成的文本继续写出转录结果。

这种架构能够借助大模型的语言知识解决许多并非纯声学的问题,例如:

  • 同音词和上下文歧义;
  • 中英文代码切换;
  • 标点恢复与逆文本规范化;
  • 人名、地名和专业术语;
  • 会议、广播等长音频中的全局一致性。

问题在于,标准自回归解码一次通常只生成一个 token。设音频为 a,此前已经生成的文本为 x≤t,则下一 token 的预测过程为:

\(p_t=P\!\left(x_{t+1}\mid a,x_{\le t}\right)\)

如果输出序列包含 N 个 token,解码器就需要大约 N 次串行前向计算。解码器从 1B 扩大到 4B 后,语言建模能力增强,但每个 token 都要支付更高的计算成本。长音频同时需要更多输出 token 和更长上下文,因此矛盾更加明显。

二、核心洞察:ASR 比开放式文本生成更适合 MTP

ParaASR 的核心判断是:语音识别并不是开放式创作。文本大模型写故事时,后续内容可能存在大量合理分支;但 ASR 的目标是忠实恢复已经存在于音频中的内容。给定音频和当前转录前缀后,局部未来具有更强的确定性。

因此,模型可以在预测下一 token 的同时,让多个辅助分支分别预测更远位置:

\(p_{t,h}=P\!\left(x_{t+1+h}\mid a,x_{\le t}\right),\qquad h\in\{1,\ldots,5\}\)

主分支负责 xₜ₊₁,五个 MTP 分支分别预测 xₜ₊₂xₜ₊₆,一次前向计算形成六 token 提议。和直接并行输出不同,ParaASR 不会无条件采纳这些未来 token,而是只接收与标准自回归路径一致的最长连续前缀。

若 MTP 提议为 ,自回归验证结果为 x*,接收长度可以抽象表示为:

\(K=\max\left\{k:\hat{x}_{t+i}=x^{*}_{t+i},\ \forall i\in\{1,\ldots,k\}\right\}\)

一旦第 k+1 个提议与正常解码路径不一致,该位置及其后的提议全部拒绝,模型从已验证前缀继续自回归解码。正确预测能够减少前向次数,错误预测最多只是缩短本次接收长度,不会直接改变最终转录结果。这是论文把 MTP 称为“安全加速模块”的原因。

三、ParaASR 模型架构

ParaASR 的主干没有刻意设计得很复杂,而是在标准音频语言模型上重点改造解码路径。

模块设计作用
音频编码器0.6B Transformer,初始化自公开全模态基础模型,训练期间保持冻结提取音频声学表征
时间下采样8 倍下采样,每 80ms 产生一个声学 embedding降低长音频输入序列长度
适配器线性映射层把声学 embedding 投影到语言解码器的隐藏空间
文本解码器4B 稠密 Transformer,初始化自预训练文本 LLM根据音频和文本前缀生成转录
上下文原生 32K context支持最长约 30 分钟音频单次转写
MTP 模块5 个未来 token 分支与主分支共同提出最多 6 个 token

MTP 分支内部如何连接

每个 MTP Block 同时接收上一个分支的隐藏状态和经过位移的 token embedding。两路输入分别归一化后拼接,通过线性层恢复到解码器隐藏维度,再进入一个解码器式 Transformer Block。所有 MTP 分支与主干共享词嵌入层和词表输出头,使未来 token 提议尽可能保持与主解码器一致的语言空间。

32K 上下文与 80ms 声学 embedding 是长音频能力的基础。论文声称该组合可让模型直接处理最长约 30 分钟音频,从而避免传统“VAD 切片—逐段识别—文本拼接”带来的边界错误和跨片段实体不一致。

四、三项主要创新

  1. 把语音的确定性转化为解码并行度:论文没有单纯压缩解码器,而是利用音频对输出文本的强约束,让 4B LLM 可以一次预测多个未来 token。
  2. 多 token 提议与自回归验证结合:MTP 负责加速,标准解码路径负责最终正确性;错误提议只影响速度,不直接决定输出。
  3. 短音频精度、长音频一致性和推理速度统一训练:模型先建立可靠的自回归 ASR,再训练 MTP 分支,避免并行目标从训练初期干扰识别能力。

严格来说,MTP 和投机解码并非论文首次提出。ParaASR 的价值主要在于证明:与开放式语言生成相比,ASR 的声学锚定特性使未来 token 更容易预测,因此能够获得更高的连续接收率,并在较大解码器上实现实际的系统加速。

五、训练数据:1.356T 预训练 token、10 万小时短音频与 5 万小时长音频

1. 音频语言基础预训练

ParaASR 继承公开音频语言基础模型的分阶段预训练方案,总规模为 1.356T 文本和音频 token:

阶段数据规模目标
语音—文本对齐100B ASR token,12K steps冻结音频编码器和 LLM,仅学习音频适配器到文本 embedding 空间的映射
音频 token 扩展128B 文本 + 128B 音频 token加入 6.6K 个离散音频 token,训练 TTS、语音到语音等统一能力
统一多模态预训练800B token,其中包含 400B 文本混合 ASR、TTS、语音翻译以及文本—语音交错续写
Cooldown 与能力扩展200B 高质量 token增强副语言理解和多语种 ASR,并使用覆盖 5 万个说话人的会话式语音合成数据

2. 约 10 万小时短音频监督数据

短音频 SFT 数据由主流公开语料和大量私有数据构成,每条样本不超过 30 秒。数据覆盖普通话、英语、频繁中英文切换、主要汉语方言和地域口音,同时包含专业术语、远场录音和高噪声环境。论文称私有数据经过人工核验,以保证音频与转录的高质量对齐。

3. 约 5 万小时长音频伪标签数据

长音频数据不是直接使用单一 ASR 模型生成标签,而是采用多系统校验:

  1. 用 VAD 把原始长录音切成不超过 30 秒的语音片段;
  2. 使用三个 ASR 系统分别转写;
  3. 统一大小写、标点和表面格式;
  4. 中文按字、英文按词执行 ROVER 对齐和投票;
  5. 一个文本单元至少获得两个系统支持才被接收;
  6. 过滤分歧率超过 5% 的片段;
  7. 重新拼接相邻片段,并使用 LLM 恢复标点、执行 ITN 和统一全局实体。

论文用下面的分歧率作为伪标签可靠性代理指标:

\(\hat{e}=\frac{\#\,\mathrm{disagreed\ positions}}{\#\,\mathrm{text\ units}}\)

ê > 0.05 时,片段被丢弃。最后的 LLM session-level refinement 很关键:它不是只修正单个短片段,而是在整个会话范围内统一反复出现的人名、术语和实体,减少长音频拼接后的前后不一致。

六、训练流程:先做好 ASR,再训练 MTP 加速器

ASR 监督微调

训练采用对话式指令格式:system prompt 指定转写任务,user 输入音频特征,assistant 输出语言标签和转录文本。为提高噪声鲁棒性,训练集中还加入纯非语音或严重噪声输入,目标输出为非语音标签和空文本。

  • 训练序列预算:32K token;
  • 声学增强:SpecAugment 式时间遮挡和频率遮挡;
  • 音频编码器:保持冻结;
  • 优化模块:线性适配器和 4B 语言解码器;
  • 训练步数:10K;
  • 峰值学习率:2×10⁻⁵
  • 全局 batch size:32;
  • warmup:100 steps;
  • 余弦衰减终点:1×10⁻⁶

MTP 第一阶段:冻结主干,对齐未来分支

在已经收敛的 ASR 解码器后加入五个 MTP Block。每个 MTP Block 的 Transformer 层从解码器最后一层初始化,分支专用投影层随机初始化。此时只训练 MTP 模块,主干、共享 embedding 和 LM Head 全部冻结,峰值学习率为 2×10⁻⁴

MTP 第二阶段:联合校准

未来分支初步对齐后,模型解冻适配器和语言解码器,以更低的 2×10⁻⁵ 学习率联合优化。论文称两阶段沿用 32K 序列预算、全局 batch size 32 和 10K-step 训练配置。

越远的 token 越难预测,因此 MTP 分支损失采用指数衰减权重:

\(w_h=\frac{\alpha^{h-1}}{\sum_{j=1}^{H}\alpha^{j-1}},\qquad H=5,\quad \alpha=0.9\)

每个位置的总目标由标准下一 token 交叉熵和五个未来 token 交叉熵构成:

\(\mathcal{L}_t=\mathrm{CE}(p_t,x_{t+1})+\sum_{h=1}^{H}w_h\,\mathrm{CE}(p_{t,h},x_{t+1+h})\)

损失只作用于转录 token。这样的分阶段设计避免随机初始化的 MTP 分支在早期破坏已经稳定的识别主干。

七、实验设置

论文从识别精度、长音频能力和推理效率三个方面评估 ParaASR。主要对比模型包括 VibeVoice-ASR、FunASR-Nano、Doubao-ASR-2603 和 Qwen3-ASR-1.7B。

  • 除 Doubao-ASR-2603 使用官方 API 外,其余模型均部署在单张 NVIDIA H800 上;
  • 推理采用单并发;
  • 不原生支持长音频的模型使用 VAD 切成最长 30 秒片段;
  • 中文使用 CER,英文与长音频使用 WER;
  • 基准覆盖 AISHELL-1/2、WenetSpeech、FLEURS、LibriSpeech、Common Voice、VoxPopuli cleaned AA 和 Earnings22 cleaned AA;
  • Wenet testnet long 由同一来源会话中的相邻片段拼接构造。

错误率的通用定义为:

\(\mathrm{ER}=\frac{S+D+I}{N}\)

其中 SDI 分别代表替换、删除和插入错误;中文以字符数作为 N,得到 CER,英文以词数作为 N,得到 WER。

八、识别效果:平均成绩领先,但并非每个数据集都第一

评测类别VibeVoice-ASRFunASR-NanoDoubao-ASR-2603Qwen3-ASR-1.7BParaASR
中文平均 CER10.193.663.343.172.97
英文平均 WER7.145.246.673.853.68
长音频平均 WER4.875.596.114.203.70

相对 Qwen3-ASR-1.7B,ParaASR 的中文平均错误率相对下降约 6.3%,英文下降约 4.4%,长音频下降约 11.9%。其中代表性结果包括:

  • AISHELL-1 CER:0.71%
  • AISHELL-2 iOS CER:2.29%
  • LibriSpeech clean WER:1.38%
  • LibriSpeech other WER:3.16%
  • LibriSpeech clean long WER:1.27%
  • LibriSpeech other long WER:2.90%

不过,“平均第一”不等于所有数据集都第一。ParaASR 在 Wenet testnet、Wenet testmeeting、Common Voice、FLEURS en、Wenet testnet long 和 Earnings22 等数据集上仍落后于部分基线。例如 Wenet testnet 上 Doubao-ASR-2603 为 4.03%,ParaASR 为 4.54%;Earnings22 上 VibeVoice-ASR 为 5.62%,ParaASR 为 6.52%。这说明 ParaASR 的优势更接近整体质量—效率前沿,而不是对所有领域实现绝对统治。

九、推理效率:4B 解码器比 1.7B 基线更快

实时因子定义为处理时间与音频时长之比:

\(\mathrm{RTF}=\frac{T_{\mathrm{inference}}}{T_{\mathrm{audio}}}\)
模型RTF相对 ParaASR
VibeVoice-ASR0.1039约慢 19.6 倍
FunASR-Nano0.0591约慢 11.2 倍
Doubao-ASR-26030.0640约慢 12.1 倍
Qwen3-ASR-1.7B0.0094约慢 1.77 倍
ParaASR0.0053基准

RTF 0.0053 意味着在论文条件下,处理 30 秒音频约需 0.159 秒。RTF 测试使用 100 条、每条 30 秒的音频。尽管 ParaASR 使用 4B 解码器,它仍比 Qwen3-ASR-1.7B 的 0.0094 更快,说明多 token 接收抵消了更大解码器的单步成本。

需要注意,Doubao-ASR-2603 通过官方 API 测试,而其他模型运行在本地 H800 上,因此这项 API 与本地部署之间的 RTF 对比并非完全同条件。

十、为什么选择 MTP-5,而不是更多分支

配置各位置接收率平均接收长度
MTP-30.96 / 0.88 / 0.803.6 / 4
MTP-50.95 / 0.88 / 0.80 / 0.71 / 0.645.0 / 6
MTP-70.96 / 0.88 / 0.80 / 0.72 / 0.65 / 0.59 / 0.536.1 / 8

从 MTP-3 增加到 MTP-5,平均接收长度从 3.6 提升到 5.0,增长约 39%;继续增加到 MTP-7,平均接收长度只提高到 6.1,增幅约 22%。越靠后的 token 接收率越低,第七位置只有 0.53。

生产推理中,较远位置预测失败会造成 KV Cache 回滚并打断连续解码,分支数量过多的维护成本可能抵消额外接收的少量 token。因此论文最终选择 MTP-5 作为并行度、接收率和工程复杂度之间的平衡点。

十一、消融实验:MTP 基本不改变识别精度

类别不使用 MTPMTP-5变化
中文平均 CER3.003.000.00
英文平均 WER3.833.87+0.04
长音频平均 WER3.633.69+0.06

配对消融显示 MTP-5 引起的平均波动不超过 0.06 个绝对百分点。这与验证机制相符:MTP 猜对时加速,猜错时缩短接收前缀,最终输出仍由验证后的自回归路径决定。

但论文中有一个值得注意的呈现问题:表 4 的 MTP-5 数值与表 1 最终 ParaASR 的个别结果并不完全一致,例如表 1 的 VoxPopuli 为 2.76%,表 4 为 3.69%;表 1 的 FLEURS zh 为 2.63%,表 4 为 2.76%。这可能意味着消融使用了独立的配对 checkpoint 或不同实验产物,但论文没有明确解释。因此,表 4 适合用来观察“加入 MTP 前后”的相对变化,不宜与表 1 的最终模型逐项拼接。

十二、论文的价值与局限

值得肯定的地方

  • 抓住了 ASR 的任务特性:音频为未来 token 提供强约束,使 MTP 比开放式生成更容易获得长连续接收前缀。
  • 没有用小模型换速度:ParaASR 保留 4B 解码器的语言能力,通过减少串行步数提高吞吐。
  • 训练流程风险较低:先训练可靠 ASR,再分阶段加入 MTP,避免辅助目标破坏主干。
  • 兼顾长音频:32K 上下文、80ms 音频表征和 5 万小时长音频监督共同服务于会话级一致性。
  • 实验不只报告精度:同时给出 RTF、逐位置接收率、平均接收长度和配对消融。

仍需谨慎看待的地方

  • 论文使用大量私有数据,约 10 万小时短音频中公有与私有数据的具体比例没有披露。
  • 摘要页面没有给出代码、模型权重或完整数据发布地址,关键结果暂时难以由外部团队完整复现。
  • 4B 文本解码器的具体基础模型名称没有明确披露,音频编码器只说明初始化自公开全模态基础。
  • Doubao API 与本地 H800 的效率结果不在完全一致的硬件和服务链路下。
  • “最长 30 分钟一次转写”是重要能力,但论文没有单独展示不同音频长度下的显存、吞吐、延迟和错误率曲线。
  • 平均成绩领先,但在部分领域和数据集上仍落后于其他模型,实际部署仍需按目标场景复测。

结语

ParaASR 的核心贡献不是简单地给 ASR 换上一个更大的 LLM,而是重新处理“大解码器质量高、逐 token 推理慢”的矛盾。它利用语音转写的确定性,同时预测多个未来 token,再由自回归路径验证,使一次 4B 解码器前向计算平均输出 5.0 个已验证 token。

从论文结果看,MTP-5 几乎没有改变识别错误率,却把系统 RTF 降到 0.0053,并保留 32K 长上下文和最长约 30 分钟的单次转写能力。这说明在语音识别这类有外部输入强约束的生成任务中,模型规模与推理速度并不必然冲突:只要未来 token 足够可预测,并且存在可靠验证路径,大模型也可以通过提高单步有效输出量实现低延迟服务。

下一步真正决定 ParaASR 影响力的,将是模型与代码是否开放、外部团队能否复现 RTF 和长音频结果,以及它在电话、会议、方言、强噪声和专业领域中的实际稳定性。

Hy ASR 3.0 preview-腾讯混元语音识别模型

Hy ASR 3.0 preview 融合高精度语音识别与深度语义理解能力,在通用识别、上下文感知、多场景鲁棒性以及方言覆盖等核心维度实现全面提升,能够在更复杂的真实输入中给出准确、连贯且更接近用户意图的转写结果,从“逐字转写、单点优化”演进为“理解语境、兼容场景、一键直出”

架构、数据、后训练持续增强,提升语音识别能力上限

Hy ASR 3.0 preview 的能力提升并非来自单一模块,而是模型架构、数据  Scaling 与后训练优化共同作用的结果。

在架构层面,Hy ASR 3.0 preview 采用兼顾效率与性能的 MoE 架构,并将基座模型升级至 Hy3,进一步增强语言理解、上下文建模和语义推理能力。在语音侧,团队自研无监督语音 Encoder,通过数千万小时级无监督语音数据训练,使其能够从复杂音频中提取高质量的声学表征。

为了持续提升模型的语音建模与理解能力,混元团队对语音 Encoder 和大语言模型进行联合训练,引入数千万小时级、多来源的语音数据,覆盖多种方言、口音和声学环境,并通过高质量数据管线进行精细化标注。在大规模联合预训练的基础上,Hy ASR 3.0 preview 通过多阶段能力注入,逐步获得上下文感知、复杂场景适应和方言识别等能力。

围绕通用识别、上下文理解和复杂场景鲁棒性,团队构建了高质量的 SFT recipe,覆盖上下文 context、专业名词、不同声学环境以及多样人群语音。针对方言识别能力,SFT 数据体系进一步覆盖 10 大方言片区和 20 余个二级小片区。

在此基础上,团队进一步引入多阶段强化学习,分别针对通用转写准确性、Any-context 上下文能力和复杂长尾场景进行优化,降低模型在复杂声学环境中的误识别和漏识别问题。

AmphionASR-大规模热词的个性化语音识别

基于Qwen3-ASR-1.7B的统一条件化语音识别系统,将热词检索、目标说话人选择、退化鲁棒与耳语识别整合进单一1.7B参数SpeechLLM。

现实中的语音识别往往不只是“把声音转成文字”。用户可能希望模型优先识别人名、品牌名和行业术语,也可能只想转写某个指定说话人;输入音频还可能带有远场、噪声、混响、传输丢失,甚至是耳语。AmphionASR 的目标,就是用一个统一的 SpeechLLM 同时处理这些条件,而不是为每种场景分别维护一套模型。

论文最终给出的模型以 Qwen3-ASR-1.7B 为基础,通过分阶段微调、检索增强和目标说话人数据合成,将通用 ASR、热词 ASR、目标说话人 ASR、退化音频 ASR 和耳语 ASR 统一起来。其最突出的结果包括:热词检索 Recall@50 超过 94%,中英文实体错误率分别下降 55% 和 37%;目标说话人识别 WER 达到 13.02%;中文耳语 CER 为 0.58%,英文耳语 WER 为 6.11%。

AmphionASR 的四项主要条件化识别能力——热词、目标说话人、退化鲁棒性和耳语识别。

一、论文要解决什么问题

传统通用 ASR 默认将输入中的全部可听语音转写出来,但在实际业务里,“识别什么”和“在什么条件下识别”经常需要额外说明。论文将这些需求归纳为四类:

  • 热词条件识别:利用用户提供的词表,提高人名、地名、产品名和专业术语的识别率。
  • 目标说话人识别:给定目标说话人的短注册语音,只转写混合音频中该说话人的内容。
  • 退化音频识别:处理噪声、远场、遮挡、混响、录音染色、电子失真和传输丢失等情况。
  • 耳语识别:处理声带振动特征和正常语音明显不同的低能量耳语。

这些任务的附加信息不同,但输出目标相同:生成用户真正想要的那部分转写。AmphionASR 因而采用统一的指令接口,通过文本指令、热词列表或注册语音告诉模型当前任务。

本文提出 AmphionASR,一套可同时适配上述四类识别任务的统一模型。热词列表、目标说话人注册音频作为任务条件输入;各类受损语音、耳语样本则用于让模型适配非常规声学输入。该设计将通用识别主干网络,与 “识别对象、识别约束条件” 两类辅助信息解耦。 热词识别分支的技术路线参考已有研究,融合 GLCLAP Top-K 检索、提示词注入、基于强化学习的 GRPO 优化方案;本文重点是将整套热词流程集成至统一模型,并在四类任务上完成全面评测。

二、模型总体设计

AmphionASR 由音频编码器、语言模型和热词检索分支组成。论文称其为 1.7B 模型,是按照 LLM 参数量命名;如果计入约 300M 的音频编码器和 2.6M 的检索适配器,总参数量约为 2.0B。

组件参数量主要设计
音频编码器300M初始化自 Qwen3-ASR-1.7B 的 AuT 编码器
语言模型1.7B28 层 Decoder-only Transformer,隐藏维度 2048
RAG 适配器2.6M音频和文本两侧的 MLP 投影层
合计约 2.0B音频编码器、LLM 与检索适配器
核心参数来自论文 Table 1。

Figure 2,AmphionASR 整体架构图

1. 音频编码器

输入为 16 kHz 单声道音频。前端提取 128 维 Log-Mel 特征,帧移为 10 ms,随后经过卷积下采样和 24 层 Whisper 风格的 Pre-LN Transformer,输出 2048 维、12.5 Hz 的音频帧表示。模型使用 800 帧的分块推理窗口,从而突破普通 30 秒输入限制。

2. 语言模型与统一提示词

音频表示会直接进入 Qwen3-ASR-1.7B 的语言模型嵌入空间,再由自回归解码器生成转写。不同任务不需要切换模型,只需要更换提示词和可选输入:

  • 通用 ASR:要求转写输入音频。
  • 热词 ASR:在提示词中增加 [Hotwords: ...]
  • 目标说话人 ASR:先输入注册语音,再输入待转写的混合语音。
  • 耳语 ASR:明确告诉模型输入是一段 whispered audio。

目标说话人任务中的注册语音和混合语音共用同一个音频编码器,并以“注册语音在前、混合语音在后”的两个音频嵌入片段进入 LLM。这个设计没有增加独立的说话人编码网络,而是让语言模型在统一上下文中完成说话人条件选择。

三、细粒度热词检索:从万级词库中找出当前相关词

直接把上万个候选热词塞进提示词既浪费上下文,也会引入大量无关干扰。AmphionASR 因此先进行检索,只选出与当前音频最相关的 Top-K 热词,论文默认 K=50。

与将整段音频池化成一个向量的方案不同,AmphionASR 保留逐帧音频表示。音频帧和候选热词分别通过两个小型 MLP 映射到共享的 512 维空间:

\( a_t = g_{\mathrm{audio}}\!\left(\mathrm{AuT}(x)_t\right),\qquad k_h = g_{\mathrm{text}}\!\left(E_{\mathrm{tok}}(h)\right) \)

每个热词与所有音频帧计算内积,并取时间维度上的最大值作为相关性:

\( s_h = \max_t a_t^{\top}k_h,\qquad \mathcal{H}’=\operatorname{TopK}_{h\in\mathcal{H}}(s_h) \)

这种 max-over-time 方式强调局部匹配:即使热词只在长音频中短暂出现,也不容易被全句平均表示淹没。选出的热词随后作为逗号分隔的文本插入提示词,ASR 仍然只需要执行一次解码。

Figure 3,细粒度热词检索流程。该图用于说明音频帧、文本热词、共享空间和 Top-K 选择之间的关系

四、训练数据与三阶段训练

AmphionASR 基于低秩自适应微调(LoRA)有监督微调(SFT)三阶段训练方案完成训练。AmphionASR 使用 11 个公开语料构建出 8 个训练集合,总计 3,737,145 条训练样本。其中,目标说话人样本包含注册语音和混合语音两个音频输入,同时加入通用转写数据,缓解模型灾难性遗忘问题。

训练任务样本数主要来源
耳语 ASR222,440WhispEar,中英文耳语
退化鲁棒 ASR556,421Voice-in-the-Wild-2M
热词 ASR1,043,317CommonVoice、MagicData、AISHELL-1/3、THCHS-30
通用 ASR 保持1,290,464AISHELL-2、LibriSpeech
目标说话人 ASR624,503多个公开单说话人语料合成

训练阶段热词词表构建逻辑

针对带热词的训练样本,每条样本动态生成专属热词列表,真实热词 + 干扰词总数量约束在 10~50 个,词表构建分三步:

  1. 真实实体词 每条标注真值热词有 5% 概率被随机剔除,模拟检索模块召回不完全的真实场景。保留绝大多数真实热词,使模型能够借助上下文偏置修正稀有实体、领域专业术语,解决无约束解码器极易错识这类词汇的问题。
  2. 难例负样本(易混淆干扰词) 在线检索器为每条样本最多召回 10 个高度混淆词汇;检索打分权重为:0.6× 字符重叠度 + 0.4× 二元组杰卡德相似度,中文额外增加音节级近邻检索扩充候选。这类字形、发音相近的干扰词用于训练模型区分相似热词,避免模型无脑匹配列表内任意词汇。
  3. 随机干扰词 词表剩余空位从全局热词库随机填充;优先填满难例负样本,再补充随机词,保证列表总长落在 10~50 区间。随机无关词汇用于约束提示词长度,防止模型过度依赖匹配候选词产生识别偏置。

每条语音样本有 80% 概率保留完整热词提示行,20% 概率直接舍弃热词输入。该策略让模型在训练时同时接触 “带热词辅助” 与 “无热词辅助” 两类输入,提升泛化能力。

阶段 1:适应耳语和退化音频

音频编码器和 LLM 同时训练,数据来自 Voice-in-the-Wild-2M 和 WhispEar。由于这些声学条件与普通清晰语音差异较大,论文首先允许声学表示和语言模型共同适应。

阶段 2:学习热词与目标说话人条件

冻结音频编码器,只更新 LLM。模型在这一阶段学习如何使用热词提示,以及如何根据注册语音从多人混合音频中选择目标说话人。

阶段 3:通过数据回放抑制灾难性遗忘

继续冻结音频编码器,在前两阶段数据之外加入 AISHELL-2 和 LibriSpeech 通用转写数据。目的不是追求新的通用 ASR SOTA,而是在增加个性化能力后尽量保留原模型的基础识别能力。

三个阶段均采用全线性层 LoRA,LoRA rank 为 64、alpha 为 128;每阶段训练 1 个 epoch,学习率为 \(1\times10^{-6}\),余弦衰减和 5% warmup,有效 batch size 为 384,使用 6 张 GPU。

GRPO:同时优化转写准确率和热词一致性

三阶段 SFT 后,论文冻结音频编码器,通过 GRPO 继续优化 LLM。ASR 奖励是经过截断的负 CER:

\( R_{\mathrm{asr}}(\hat y,y)=\max\left(0,1-\mathrm{CER}(\hat y,y)\right) \)

热词奖励检查每个候选词在预测和参考文本中的“出现/未出现”状态是否一致:

\( R_{\mathrm{hw}}(\hat y,y;C)=\frac{1}{|C|}\sum_{c\in C} \mathbf{1}\!\left\{\mathbf{1}[c\in\mathrm{Pred}]=\mathbf{1}[c\in\mathrm{Ref}]\right\} \)

总奖励为:

\( R=R_{\mathrm{asr}}+0.3R_{\mathrm{hw}} \)

这一设计不仅鼓励模型抄对热词,也惩罚它盲目输出提示词中实际没有被说出的词。不过论文没有提供“SFT 后、GRPO 前”的独立对照,因此实验无法单独量化 GRPO 的贡献。

五、目标说话人数据是如何合成的

目标说话人训练数据由单说话人语料离线合成。对于同一目标说话人,系统选择两段不同录音:一段作为 3 至 5 秒注册音频,另一段作为待混合的目标语音,再加入 1 至 2 个非目标说话人。

混音过程可写为:

\( x_{\mathrm{mix}}[n]=s_{\mathrm{tgt}}[n]+\sum_{k=1}^{K}\alpha_k s_{\mathrm{int},k}[n-o_k],\qquad \alpha_k=\frac{\rho_{\mathrm{tgt}}}{\rho_{\mathrm{int},k}}10^{-\mathrm{SNR}_k/20} \)

其中 \(K\sim\mathrm{Cat}(\{1:0.8,2:0.2\})\),说话人间 SNR 服从均值 5 dB、标准差 7 dB 的正态分布,并截断到 -5 至 20 dB;干扰语音覆盖目标语音的比例从 0.1 到 1.0 均匀采样。之后以 0.5 的概率加入 RIR,再以 0 至 25 dB 的 SNR 加入 MUSAN 或 AudioSet 环境噪声。

为了降低“目标说话人不在场时仍然胡乱输出”的问题,训练集还包含 66,194 条空转写负样本,包括噪声/静音和只有非目标说话人的混合音频。这一部分是目标说话人系统能够学习保持沉默的关键。

Figure 4,目标说话人训练数据离线合成流程;可同时参考 Table 16 和 Table 17 的 RIR、噪声来源与负样本参数

六、实验结果

1. 热词和行业实体识别

在 GigaSpeechBench 的 12 个垂直领域中,加入 RAG 后,中文平均实体 B-CER 从 23.18% 降至 10.39%,相对下降约 55%;英文平均实体 B-WER 从 14.78% 降至 9.35%,相对下降约 37%。加入热词上下文后,AmphionASR 在中文 12 个领域中的 11 个、英文全部 12 个领域中优于无热词输入的 Qwen3-ASR-1.7B。

测试集无 RAG使用 RAGRecall@50
GigaSpeechBench 中文平均 B-CER23.18%10.39%
GigaSpeechBench 英文平均 B-WER14.78%9.35%
CommonVoice 中文热词9.27%2.30%94.52%
CommonVoice 英文热词28.93%9.81%95.19%
根据论文 Table 9、Table 10 和 Table 11 汇总,指标均越低越好,Recall 除外。

在约一万个候选词的词库上,相比已经预先计算好 Top-50 热词的条件,在线检索增加的配对中位延迟为英文 1.37 ms、中文 3.25 ms。但该实验每种语言只有 30 条音频,运行在共享 H20 上,没有并发和 RTF 数据,因此只能说明热状态下的相对开销,不能直接视为生产吞吐量结论。

2. 目标说话人识别

在内部合成的目标说话人测试集正样本上,AmphionASR 的 WER 为 13.02%,明显低于零样本 Qwen3-Omni-30B-A3B 的 31.91%,也远低于未进行目标说话人训练的 Qwen3-ASR-1.7B 的 78.99%。

模型正样本 WER目标缺席静音误报率
Qwen3-ASR-0.6B84.97%100.00%
Qwen3-ASR-1.7B78.99%100.00%
Qwen3-Omni-30B-A3B 零样本31.91%9.15%
AmphionASR13.02%6.10%
论文 Table 13,数值越低越好。

这一结果说明模型确实学到了“根据注册语音选择说话人”的能力,同时负样本降低了目标缺席时的幻觉。不过测试集由与训练相同的合成流水线生成,只是更换随机种子和说话人;论文也没有与专用 TS-ASR 模型进行完全一致协议下的比较,因此泛化能力仍需要公开真实重叠语音数据验证。

3. 真实退化音频鲁棒性

Voice-in-the-Wild-Bench 包含 5,000 条中英文音频,覆盖 7 类单一退化和 Mixed 复合退化,并分为真实录音与频谱模拟两组,共 16 个子集。AmphionASR 在其中 8 个子集取得最低 WER。

  • 真实录音领先项:遮挡 1.38%、混响 7.91%、录音染色 6.32%、传输丢失 2.32%。
  • 模拟退化领先项:噪声 7.24%、混响 11.49%、录音染色 11.55%、Mixed 4.19%。
  • Real-Mixed 为 2.85%,仅次于 Mega-ASR 的 2.63%。

这说明阶段 1 的退化训练具有明显效果,但 AmphionASR 并非在所有条件下都领先,例如真实噪声、远场、电子失真以及部分模拟条件仍有其他专用模型表现更好。

4. 耳语识别

耳语识别是论文中最稳定的优势之一。AmphionASR 在中文 wEar 上取得 0.58% CER,在英文 WTIMIT 上取得 6.11% WER,均为表中最低。

模型wEar 中文 CERWTIMIT 英文 WER
Whisper-large-v316.33%11.99%
Kimi-Audio-7B-Instruct1.48%10.95%
Qwen3-ASR-1.7B1.22%9.56%
FireRed-ASR2-LLM1.01%15.18%
AmphionASR0.58%6.11%
论文 Table 15 的主要模型结果。

相比基础模型 Qwen3-ASR-1.7B,AmphionASR 在中文耳语上绝对降低 0.64 个百分点,在英文耳语上绝对降低 3.45 个百分点。模型同时在中英文上领先,说明耳语训练没有出现明显的语言间取舍。

5. 通用 ASR 能力是否被遗忘

论文在 4 个英文和 6 个中文通用测试集上进行了保持性检查。与同规模的 Qwen3-ASR-1.7B 相比,AmphionASR 在每个测试集上的差距都不超过 0.85 个绝对 WER/CER 点,并在两者直接比较时赢下 10 个测试集中的 4 个。

需要区分的是:这不代表 AmphionASR 在 4 个数据集上取得所有系统中的最好结果。Table 18 和 Table 19 的整体领先者仍分散在 Kimi-Audio、Step-Audio、FireRed-ASR2 等模型中。论文将该实验定位为“能力保持检查”,而不是通用 ASR 的 SOTA 声明,这是较为客观的表述。

七、论文的主要创新点

  1. 用统一接口承载多种条件化 ASR。文本指令、热词和注册语音都被组织为 LLM 上下文,使不同任务共享音频编码器和解码器。
  2. 将帧级热词检索接入完整 SpeechLLM。局部 max-over-time 匹配比整句池化更适合发现短时出现的实体,并把万级候选库压缩到 Top-50。
  3. 通过双音频输入实现目标说话人选择。注册音频和混合音频共用声学编码器,不需要额外构建完全独立的 TS-ASR 网络。
  4. 系统化构造目标缺席负样本。噪声、静音和纯干扰说话人样本教会模型在找不到目标时保持沉默,从而降低幻觉。
  5. 分阶段训练兼顾专项能力与基础能力。先适应声学变化,再学习条件控制,最后回放通用数据,训练顺序与不同模块的职责相匹配。

需要注意,论文明确指出 GLCLAP Top-K 检索、提示词注入和 GRPO 的组合已有相关工作。AmphionASR 的贡献重点不是提出一种全新的检索或强化学习算法,而是把这些方法集成到统一模型中,并覆盖更多条件化识别任务。

八、局限性与值得继续验证的问题

  • 语言范围有限:当前核心评测只覆盖普通话和英语,尚不能证明统一训练方法对越南语等语言同样有效。
  • 热词对比并非完全同输入:多数基线没有收到热词,因而结果证明的是完整“检索加上下文提示”流水线价值,而不是公平条件下检索器单模块的增益。
  • GRPO 缺少独立消融:没有 SFT-only 对照,无法知道最终提升中有多少来自 GRPO。
  • 目标说话人测试仍偏内部合成:需要在公开真实会议、重叠说话和跨设备数据上验证。
  • 延迟测试规模较小:共享 GPU、每种语言 30 条请求、无并发、无 RTF,不能据此推断生产服务容量。
  • 统一模型并非所有任务都最优:它的优势是能力覆盖和共享部署,而不是在每个通用或退化子集上都击败专用模型。

九、总结

AmphionASR 最有价值的地方,是把 ASR 从“无条件转写器”推进成“可被用户条件控制的语音识别模型”。热词告诉模型哪些词值得重点关注,注册语音告诉模型应该听谁,任务指令告诉模型输入属于耳语还是普通语音,而退化数据让模型适应真实采集环境。

从实验结果看,热词和耳语是目前证据最充分的两项能力:前者在万级候选词库下显著降低实体错误,后者在中英文测试集上同时取得最好结果。目标说话人和退化鲁棒性同样表现出潜力,但还需要更严格的公开测试和生产级吞吐评估。

对于实际 ASR 系统,这篇论文给出的启发并不是必须把所有任务都塞进一个模型,而是可以建立一套共享的语音表示和解码骨干,再通过文本上下文、参考音频与检索结果描述用户意图。这样既能减少多模型维护成本,也让个性化语音识别拥有更统一的产品接口。


基于 OpenRLHF 的大模型强化训练

OpenRLHF代码细节

https://zhuanlan.zhihu.com/p/12871616401

训练入口

ppo_ray相关的训练入口在:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/cli/train_ppo_ray.py

在main中我们启动了driver进程,并执行训练函数train(args),这里主要做了如下几件事:

  • 在ray集群上部署Actor/Ref/Critic/RM实例
  • 在ray集群上部署vllm_engines实例
  • 配置Actor和vllm_engines之间的通讯,用于传递权重
  • 训练Actor和Critic模型

我们依次来解读这几个关键步骤。同时为了在表述上消除歧义,我们接下来谈到“Actor”时,会使用Ray-Actor和PPO-Actor来做区分,从之前的介绍中可知,Ray-Actor是指部署在Ray集群中的远端class,PPO-Actor/Ref/Critic/RM都属于Ray-Actor。

部署Actor/Ref/Critic/RM实例

(1)非共同部署

针对多个node的情况,我们以PPO-Actor为例,看代码是如何将其部署到Ray集群上的。

  • PPORayActorGroup创建在driver进程上,可将它理解成一种部署方案,专门负责部署PPO中的4类模型
    • PPORayActorGroup中维护着self._actor_handlers,它是一个List[ray.actor.ActorHandle],列表中每个元素表示某个远端Ray-Actor的引用,而这个远端Ray-Actor可以是PPO-Actor/Ref/Critic/RM实例。如前文所说,我们可以在ray集群中的任何位置调用这个handler,来对相应的远端Ray-Actor执行操作。
    • 在本例中,我们创建了4个Ray-Actor(1个master-actor,3个worker_actor)。每个Ray-Actor都运行在一个worker进程中。在创建Ray-Actor的同时,我们也会去修改worker进程的环境变量。后续当我们在这些worker进程中启动ds_zero相关的分布式配置时,ds会读取这些环境变量信息,这样我们就知道哪些Ray-Actor同时又构成ds中的数据并行组。
    • 使用PPORayActorGroup部署模型实例的代码如下:
model = PPORayActorGroup(
        # 为部署该模型的全部实例,我们想用多少台node,例如本例中为2
        args.actor_num_nodes,
        # 为部署该模型的全部实例,我们每台node上想用多少gpu,例如本例中为2
        args.actor_num_gpus_per_node,
        # Actor/Critic/Reward/ReferenceRayActor
        ActorModelRayActor, 
        # pg可理解为,在ray cluster中锁定/预留一片资源,然后只在这片资源上部署该模型全部实例。
        # (pg维护在Head Node的GCS上,参见3.3)
        # 例如本例中,pg锁定的资源为node0 gpu0/1, node1 gpu0/1,
        # 我们只在上面部署ActorModelRayActor全部实例
        pg=pg,
        # 当我们在pg指向的预留资源中分配模型实例时,再进一步指定每个实例占据一张gpu的多少部分
        # 等于1说明每个实例占满一张gpu,即“非共同部署”
        # 小于1说明每个实例只占部分gpu,即“共同部署”,例如PPO-Actor/Ref共同部署在一张卡上
        num_gpus_per_actor=0.75 if pg else 1,
    )

ActorModelRayActor创建在远端worker进程上,是Ray-Actor。它包含了设置ds_zero分布式环境、加载模型权重、数据集准备、optimizer/scheduler准备、训练等一系列操作。

共同部署

针对下图的情况,我们以PPO-Actor为例,看代码是如何将其部署到Ray集群上的

  • PPORayActorGroup:在driver进程上创建2个PPORayActorGroup,分别管理PPO-Actor,PPO-Ref的部署
  • 使用actor_model = PPORayActorGroup(..., pg = pg, num_gpus_per_actor=0.75)创建PPO-Actor部署方案实例;使用ref_model = PPORayActorGroup(..., pg = pg, num_gpus_per_actor=0.25)创建PPO-Ref部署方案实例
  • 这里,两个方案实例使用的pg都是同一个,即这个pg都指向“1台node,每台node 8张卡”这片预留好的资源。
  • num_gpus_per_actor = 0.75/0.25是一种创建trick,虽然我们的最终目的是为了让PPO-Actor和PPO-Ref对半分一张卡(对半=共享,不是指显存上对半分),但是:
    • 假设设置为0.5,当我们实际部署ActorModelRayActor时,Ray先在单卡上部署1个ActorModelRayActor实例,当它准备部署第二个ActorModelRayActor实例时,它发现由于每个实例只占0.5块卡,因此完全可以把第2个实例接着第1个实例在同一张卡上部署,这样就导致最终无法让PPO-Actor和PPO-Ref共享一张卡
    • 假设设置0.75,当我们在单卡上部署完1个ActorModelRayActor实例后,ray发现单卡剩下的空间不足以部署第2个ActorModelRayActor实例,所以就会把第二个实例部署到别的卡上,这样最终实现PPO-Actor和PPO-Ref共享一张卡
    • 所以,这个设置是为了达到不同类型模型的实例共享一张卡的目的,而并非真正指模型实际占据的单卡显存空间。
  • 最后,在这一步中,我们对全部ActorModelRayActor共创建8个worker进程,对全部RefenreceModelRayActor共创建8个worker进程,一共创建16个工作进程。

相关代码依然在:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/launcher.py#L143

部署vllm_engines实例

  • create_vllm_engines:在driver端,我们通过运行该函数来创建vllm_engines,过程相似于4.2节中的介绍,信息都在图中,这里不赘述。
  • LLMRayActor:worker端Ray-Actor,它主要是把vllm实例进行了一些包装,包装的目的是为了让ds_rank0和all vllm ranks间可以进行PPO-Actor的权重通讯(参见2.1(3))
  • 在上面的例子中,我们会创建4个worker进程(不占gpu资源,只占cpu资源),用于运行管理4个vllm_engine。在每个worker进程内,vllm实例还会创建属于自己的worker进程做分布式运行(这些worker进程会实际占据gpu资源)。

相关代码参见:
https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/vllm_engine.py


https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/vllm_worker_wrap.py

ds_rank0与vllm_ranks之间的通讯

PPO-Actor的ds_rank0需要和all_vllm_ranks进行通讯,传递最新的PPO-Actor权重,例如以下ds_rank0要把完整的权重broadcast给16个vllm_ranks:

我们分成如下几步实现这个目标:

(1)创建通信组

Step1:

代码来自:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/ppo_actor.py#L58
这段代码执行在PPO-Actor0(ds_rank0)所在的worker进程中。这个worker进程将通过handler引用,触发远端每个vllm_engine上的init_process_group操作,并将ds_rank0纳入通讯组

 # Create torch group with deepspeed rank 0 and all vllm ranks
        # to update vllm engine's weights after each training stage.
        #
        # Say we have 3 vllm engines and eache of them has 4 GPUs,
        # then the torch group is:
        # [    0,      1, 2, 3, 4,  5, 6, 7, 8,  9, 10, 11, 12]
        # |ds rank 0 |  engine-0  |  engine-1  |   engine-2   |
        #
        # For ZeRO-1/2:
        #   1. Broadcast parameters from rank 0 to all vllm engines
        # For ZeRO-3:
        #   1. AllGather paramters to rank 0
        #   2. Broadcast parameters from rank 0 to all vllm engines
        if self.vllm_engines is not None and torch.distributed.get_rank() == 0:
            ...
            # world_size = num_of_all_vllm_ranks + 1 ds_rank0
            world_size = vllm_num_engines * vllm_tensor_parallel_size + 1
            ...
            # =====================================================================
            # 遍历每个vllm_engines,将其下的每个vllm_rank添加进通讯组中,这里又分成两步:
            # 1. engine.init_process_group.remote(...):
            #    首先,触发远程vllm_engine的init_process_group方法
            # 2. 远程vllm_engine是一个包装过的vllm实例,它的init_process_group
            #    方法将进一步触发这个vllm实例下的各个worker进程(见4.4图例),
            #    最终是在这些worker进程上执行“将每个vllm_rank"添加进ds_rank0通讯组的工作
            # =====================================================================
            refs = [
                engine.init_process_group.remote(
                    # ds_rank0所在node addr
                    master_address, 
                    # ds_rank0所在node port
                    master_port,
                    # 该vllm_engine的第一个rank在"ds_rank0 + all_vllm_ranks“中的global_rank,
                    # 该值将作为一个offset,以该值为起点,可以推算出该vllm_engine中其余vllm_rank的global_rank
                    i * vllm_tensor_parallel_size + 1, 
                    world_size,
                    "openrlhf",
                    backend=backend,
                )
                for i, engine in enumerate(self.vllm_engines)
            ]
            # =====================================================================
            # 将ds_rank0添加进通讯组中
            # =====================================================================
            self._model_update_group = init_process_group(
                backend=backend,
                init_method=f"tcp://{master_address}:{master_port}",
                world_size=world_size,
                rank=0,
                group_name="openrlhf",
            )
            # =====================================================================
            # 确保all_vllm_ranks都已添加进通讯组中
            # =====================================================================
            ray.get(refs)

Step2:

代码来自:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/vllm_worker_wrap.py#L11
这段代码实际运行在每个vllm_engine(即每个包装后的vllm实例)下的worker进程内。例如tp_size=2,那么每个vllm实例下就有2个worker进程,这两个worker进程都会运行这段代码

class WorkerWrap(Worker):
    def init_process_group(self, master_address, master_port, rank_offset, world_size, group_name, backend="nccl"):
        """Init torch process group for model weights update"""
        assert torch.distributed.is_initialized(), f"default torch process group must be initialized"
        assert group_name != "", f"group name must not be empty"
        # =====================================================================
        # torch.distributed.get_rank(): 在当前vllm_engine内部的rank,
        #                               例如在tp_size = 2时,这个值要么是0,要么是1
        # rank_offset:当前vllm_engine中的第一个rank在“ds_rank0 + all_vllm_ranks"中的global_rank
        # 两者相加:最终得到当前rank在“ds_rank0 + all_vllm_ranks"中的global_rank
        # =====================================================================
        rank = torch.distributed.get_rank() + rank_offset
        self._model_update_group = init_process_group(
            backend=backend,
            init_method=f"tcp://{master_address}:{master_port}",
            world_size=world_size,
            rank=rank,
            group_name=group_name,
        )
        ...

(2)_broadcast_to_vllm

构建好通讯组,我们就可以从ds_rank0广播PPO-Actor权重到all_vllm_ranks上了,这里也分成两步。

Step1:PPO-Actor ds_rank0发送权重

代码在:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/ppo_actor.py#L146
这段代码运行在ds_rank0对应的worker进程中

    def _broadcast_to_vllm(self):
        # avoid OOM
        torch.cuda.empty_cache()
        model = self.actor.model.module
        count, num_params = 0, len(list(model.named_parameters()))
        for name, param in model.named_parameters():
            count += 1  # empty_cache at last param

            # Fire all vllm engines for broadcast
            if torch.distributed.get_rank() == 0:
                shape = param.shape if self.strategy.args.zero_stage != 3 else param.ds_shape
                refs = [
                    # 远端vllm_engine的每个rank上,初始化一个尺寸为shape的empty weight张量,
                    # 用于接收广播而来的权重
                    engine.update_weight.remote(name, dtype=param.dtype, shape=shape, empty_cache=count == num_params)
                    for engine in self.vllm_engines
                ]

            # For ZeRO-3, allgather sharded parameter and broadcast to all vllm engines by rank 0
            # ds_rank0发出权重(视是否使用zero3决定在发出前是否要做all-gather)
            with deepspeed.zero.GatheredParameters([param], enabled=self.strategy.args.zero_stage == 3):
                if torch.distributed.get_rank() == 0:
                    torch.distributed.broadcast(param.data, 0, group=self._model_update_group)
                    ray.get(refs) # 确保所有vllm_ranks接收权重完毕

Step2: 各个vllm_ranks接收权重

代码在:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/vllm_worker_wrap.py#L29
代码运行在每个vllm_engine(即每个包装后的vllm实例)下的各个worker进程中。例如tp_size = 2,那么每个vllm实例下有2个worker进程,这2个worker进程都会运行这段代码。

 def update_weight(self, name, dtype, shape, empty_cache=False):
        """Broadcast weight to all vllm workers from source rank 0 (actor model)"""
        if torch.distributed.get_rank() == 0:
            print(f"update weight: {name}, dtype: {dtype}, shape: {shape}")

        assert dtype == self.model_config.dtype, f"mismatch dtype: src {dtype}, dst {self.model_config.dtype}"
        # 创建同尺寸空张量用于接收ds_rank0广播来的权重
        weight = torch.empty(shape, dtype=dtype, device="cuda")
        # 接收权重
        torch.distributed.broadcast(weight, 0, group=self._model_update_group)
        # 使用接收到的权重进行更新
        self.model_runner.model.load_weights(weights=[(name, weight)])

        del weight

 PPO-Actor/Critic Training

正如2.1(4)中所说,我们将部署在ray集群上的PPO-Actor/Ref/Critic/RM实例们进行分组,每组分别负责一份micro-batch的训练,上图刻画了某个组内的训练流程。一组内的训练流程发起自PPO-Actor实例(fit方法),注意不同颜色的worker0表示的是不同工作进程。共分成如下步骤执行。


Step1:发送prompts,并从vllm_engine上收集(prompt, response)。

代码参见:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ppo_utils/experience_maker.py#L627



Step2:从Ref/Reward/Critic上收集并处理exps

代码参见:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ppo_utils/experience_maker.py#L492



Step3: 确保将处理后的exps传送给Critic,并行执行Actor和Critic的训练

将exps传送给Critic:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ppo_utils/experience_maker.py#L470
Actor训练:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/ppo_actor.py#L125
Critic训练:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/ppo_actor.py#L122
我们在Actor实例所在的worker进程上出发Actor和Critic的训练。以上代码只给出了训练入口,更多细节需要顺着入口去阅读。



Step4:vllm_engine权重更新。

代码参见:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ray/ppo_actor.py#L130

RLHF-PPO算法细节

整个RLHF-PPO训练过程大致分成2步:

  • Stage1:收集exps
  • Stage2:使用收集到的exps计算actor_loss和critic_loss,用于训练actor和critic

在OpenRLHF中的核心代码为:https://github.com/OpenRLHF/OpenRLHF/blob/bb46342711a203c457df2fbca5967fd0549557e0/openrlhf/trainer/ppo_trainer.py#L19

下面我们分别解读这2个stage的过程

 Stage2:Training

ASR大模型GRPO训练

从一个 SFT(监督微调)得到的 Qwen3-ASR语音识别模型 出发,用 Ray + DeepSpeed + vLLM 缺省(此处未启用 vLLM,由 actor 自身 generate 的方式做 PPO/GRPO 强化学习: 对每条音频采样多个转写结果 → 用一个 远程 Python 奖励函数(CER、关键词、语言一致性、平滑度等多维打分)给每个结果打分 → 用 group_norm(GRPO 组内归一化) 计算优势 → 用 PPO 策略损失 更新 actor(冻结音频 encoder,只训 LLM/adapter 部分)→ 周期性保存 HuggingFace 权重。

整体调用链:

run_train_v2_from_sft.sh                    # 启动脚本:起 Ray 集群 + 提交 job
  └─ openrlhf.cli.train_ppo_ray             # 入口:解析参数、建 Ray actor 组、驱动训练
       └─ ActorModelRayActor (ray/ppo_actor.py)   # actor 进程:建模型、数据、优化器
            └─ ActorPPOTrainer.fit → PPOTrainer.fit  # PPO 主循环
                 ├─ RemoteExperienceMaker            # 采样 rollout + 打分 + 算优势
                 │    ├─ actor.generate               # 生成转写(rollout)
                 │    ├─ reward_func (远程 py)         # 多维奖励打分
                 │    └─ group_norm 优势               # GRPO 组内归一化
                 └─ PPOTrainer.ppo_train              # 用 PolicyLossV3 更新 actor

ASR语音识别-MOE架构论文

MOE- Conformer :

MoE Adapter: https://arxiv.org/pdf/2601.02967

论文:Mixture-of-Expert Conformer for Streaming Multilingual ASR

这篇论文 Mixture-of-Expert Conformer for Streaming Multilingual ASR 讨论的是一个更偏工业部署的问题:如何让一个流式端到端 ASR 模型同时支持多种语言,又不把推理成本推到端侧设备难以承受的程度。作者选择的路线是把 Mixture-of-Experts 放进 Conformer,把模型总容量做大,但每次推理只激活一小部分参数。

摘要:容量变大,激活参数不线性变大

论文提出的模型是在流式多语种 Conformer 中加入 MoE 层。MoE 层由多个 FFN 专家和一个 softmax gate 组成,每个输入帧只选择权重最高的两个专家参与计算。这样,专家总数可以增加,模型总容量也可以增加,但推理时激活的专家数固定,因此计算和激活参数不会随专家数量线性增长。

论文中的 gate 先对第 l 层输入 x 做线性映射,再通过 softmax 得到专家权重:

\( g_l=\mathrm{Softmax}(W_l\cdot x) \)

随后只取 top-2 expert,并把两个 expert 的输出按 gate 权重加权求和:

\( y=\sum_{i=1}^{2}g_{l,i}\cdot e_{l,i} \)

实验覆盖 12 个语言 locale。相对于 180M 参数的多语种 cascaded Conformer baseline,MoE-End 模型把平均 WER 从 11.33 降到 9.98,约 11.9% 相对改善。与同等总规模的 dense baseline 相比,MoE 达到类似 WER,但推理激活参数约为 211M,对比 dense 的 400M 更省。再结合多语种 neural LM 做 shallow fusion,平均 WER 还能进一步相对降低约 3%。

引言:多语种统一模型的容量问题

多语种端到端 ASR 的吸引力很直接:用一个模型识别多种语言,降低维护和部署复杂度。过去几年,CTC、LSTM、attention-based 模型以及流式 RNN-T 都在多语种 ASR 上取得了进展。尤其是端侧流式场景,模型既要有识别质量,又要满足低延迟和低计算。

经验上,模型容量越大,多语种 ASR 越容易受益。Whisper、USM 等大型模型也说明了大数据和大模型对语音识别质量的推动作用。但大模型的代价是训练和推理成本。对端侧应用来说,不能简单把模型扩大到数十亿参数。

已有一些效率方案依赖语言相关组件,比如按语言选择 adapter 或二阶段模型。但流式场景里,稳定预测语言信息本身就不容易,还可能引入错误传播。本文的 MoE 路线更直接:由输入表示动态选择专家,不需要显式语言标签,也不需要 ground-truth language information。

相关工作:专家模型与语言信息

论文把自己的方法放在几类工作之间比较。第一类是 ASR 中已有的 MoE 模型,但许多工作偏单语种,或者需要额外的共享 embedding 网络来做专家路由。第二类是 NLP 和视觉中的 MoE,比如 Switch Transformer 或 DeepMoE,不过这些结构在 ASR 尤其是流式多语种 ASR 中的直接效果并不确定。

第三类是 informed-expert:模型根据已知语言信息选择某个语言专家、adapter 或二阶段模块。这种做法在有可靠语言标签时很自然,但部署中会遇到两个麻烦:语言信息要么来自外部,要么需要模型先预测;一旦预测错了,后面的专家选择也会受影响。本文的 MoE 不显式使用语言信息,routing 由模型从声学表示中学出来。

MoE Conformer:把专家放在 FFN 位置

基础模块是 Conformer。一个 Conformer layer 通常包含两个 FFN、中间的 self-attention 和 convolution。作者把 MoE 主要用于替换 Conformer 里的 FFN,尤其是 end FFN。每个 MoE 层包含多个 FFN 专家和一个 router。

对每一帧表示,router 通过 softmax 计算各专家权重,然后选出 top-2 专家。两个专家的输出按路由权重加权求和,得到该 MoE 层输出。训练和推理都使用 top-2。为了防止专家使用不均衡,论文加入辅助负载均衡损失,让不同专家都有机会被训练到。

这个设计的关键是稀疏激活。比如总共有 8 个、16 个或 24 个专家时,每帧仍只走两个专家。总参数代表模型潜在容量,激活参数代表推理成本;MoE 的优势就在于让这两者不再完全绑定。

实验设置

模型训练使用 RNN-T loss,并额外加入专家负载均衡项。论文中的 auxiliary loss 写成:

\( l_{\mathrm{aux}}=\frac{1}{N}\sum_{i=1}^{N}c_i\cdot m_i \)

其中 m_i 是第 i 个 expert 的平均 gate,c_i 是 top-2 路由中该 expert 被选择的计数。

数据

实验使用 12 个语言 locale:美式英语、中文、法语、德语、日语、美式西班牙语、西班牙西班牙语、阿拉伯语、意大利语、印地语、葡萄牙语和俄语。训练数据来自 Voice Search、YouTube 等多个域,总计约 139.4M 条人工转写匿名语音。不同语言数据量差异很大,从 0.5M 到 25.2M utterances 不等。

测试集来自 Voice Search 流量,每个语言大约 1.4K 到 10K 条 utterances,与训练集不重叠。评价指标是 WER;对中文等语言,论文按字符计算错误率。

模型细节

baseline 是一个语言无关的多语种 transducer 模型,包含 7 层 causal Conformer encoder 和 10 层 non-causal cascaded encoder。causal 部分保证流式,non-causal cascaded 部分提供约 0.9 秒右上下文。模型使用 separate decoders 分别服务 causal 和 non-causal encoder,以获得更好质量。baseline 总参数约 180M。

MoE 改造主要发生在 cascaded encoder。作者尝试替换 start FFN、end FFN 或两者都替换。最多使用 24 个专家,但每次训练和推理只选 top-2。输入特征为 128 维 log-Mel filterbank,经连续帧堆叠形成 512 维输入,并下采样到 30ms 帧率;训练中使用 SpecAug 增强鲁棒性。

结果与比较

消融实验

首先看 MoE 放在哪里。baseline 平均 WER 为 11.33。把 MoE 放在 start FFN,平均 WER 为 10.10;放在 end FFN,平均 WER 为 9.98;两处都放,平均 WER 最好,为 9.54。不过两处都放会增加推理激活参数。作者最终更多采用 MoE-End,因为它在质量和效率之间更均衡。

专家数量方面,8 experts 的 MoE-End 平均 WER 为 9.98;减少到 4 experts 后为 10.40;减少到 2 experts 后为 10.58。由于推理始终激活 top-2,专家总数减少主要影响总容量而不是激活参数。结果说明,额外专家确实被模型利用了。

MoE 层数也很重要。只在隔层使用 MoE,平均 WER 退到 10.50;只在第一个 Conformer 层使用 MoE,为 10.88。即便只加一个 MoE 层也比 baseline 好,但完整地在 end FFN 位置加入 MoE 才能发挥主要效果。

与 dense baseline 和 adapter 比较

与 180M baseline 相比,MoE-End 模型总参数约 400M,推理激活约 211M,平均 WER 从 11.33 降到 9.98。为了排除“只是模型变大”的因素,作者构造了一个同为 400M 的大 dense baseline。这个 dense 模型平均 WER 也是 9.98,但推理需要激活 400M 参数;MoE 只激活 211M,约为 dense 的 53%。

与基于 ground-truth language information 的 adapter 模型相比,MoE 的意义更明显。Adapter 模型依赖真实语言信息选择对应模块;MoE 不需要语言标签,只根据输入动态路由。把 FFN multiplier 调小并增加专家数后,16 或 24 experts 的 MoE 在平均 WER 上接近 adapter,但部署上少了语言信息依赖。

Shallow Fusion 进一步提升

作者还训练了一个 128M 左右的多语种 neural LM,并在解码时做 shallow fusion。文本数据来自 12 种语言的监督训练文本和额外 text-only 数据。加入 LM 后,MoE 模型平均 WER 从 9.98 进一步降到 9.68,约 3% 相对改善。

不过改善并非所有语言都一致。法语收益最大,中文和印地语出现退化。作者推测,中文退化可能与 text-only 数据里混入粤语转写有关;印地语则可能因为 text-only 数据规模很大但与 Search 域不完全匹配,需要更好的过滤策略。

结论:MoE 的部署价值在于“不需要语言标签”

这篇论文展示了 MoE 在流式多语种 ASR 中的一个清晰用途:用更大的总容量提升多语种识别质量,同时通过 top-2 稀疏激活控制推理成本。最重要的是,模型不依赖语言标签完成专家选择,这比 adapter 或 per-language expert 在真实部署中更省心。

从结果看,MoE-End 相对于 baseline 有 11.9% 平均相对 WER 改善;与同规模 dense 模型相比,达到类似质量但只激活约 53% 参数;与语言标签 adapter 相比,质量接近但路由更自动。对端侧、流式、多语种这三个约束同时存在的场景,这种“动态容量”思路很值得继续跟进。

快手论文:Parameter-Efficient Conformers,利用MOE进行模型裁剪

这篇论文 Parameter-Efficient Conformers via Sharing Sparsely-Gated Experts for End-to-End Speech Recognition 关注一个非常实际的问题:Conformer 在端到端语音识别里效果很好,但模型层数和参数量上来之后,训练、部署、端侧运行都会变重。作者的思路不是简单砍层,也不是只做普通的参数共享,而是把“共享 Conformer 块”和“稀疏门控专家”结合起来,让少量参数被重复使用,同时用 MoE 保住表示容量。

摘要:少参数,不想少能力

论文的核心目标是构造一个参数高效的 Conformer 编码器。传统跨层权重共享可以减少参数,但也会压缩模型容量,导致识别性能下降。作者提出的方案是在共享的 Conformer 块中加入 sparsely-gated MoE:第二个前馈网络不再是单一路径,而是一组专家,由路由器选择其中一个专家参与计算。这样总参数增加了一些,但每次前向只激活一个专家,计算量基本保持在非 MoE 模型的水平。

为了让共享块在不同深度位置仍能适配不同层级的表示,论文还让路由器和归一化层保持独立,而不是所有内容都共享。最后,作者用全参数模型作为 teacher,通过隐藏层表示的知识蒸馏进一步弥补共享模型的能力损失。实验显示,在 AISHELL-1 上,最终模型用约三分之一的编码器参数取得了接近全参数模型的 CER。

引言:Conformer 很强,但部署不轻

端到端 ASR 中,Transformer 和 Conformer 已经是很常见的编码器选择。Conformer 在 Transformer 的全局建模基础上加入卷积模块,更适合语音这种既有长程依赖、又有局部结构的序列。相对位置编码、Macaron 风格 FFN、卷积增强等设计,都让它在语音识别中表现稳定。

问题在于,这类模型往往参数冗余。直接堆很多层可以换来更强表达,但也带来显存、存储和推理成本。已有工作会通过跨层共享参数降低模型规模,类似让同一个 block 被重复调用多次。这个办法省参数,但副作用也明显:自由参数少了,模型容量下降,性能容易掉。

作者的切入点是:既然共享会损失容量,那就在共享块内部引入 MoE 来补容量;既然 MoE 可以稀疏激活,那就只让少数专家参与一次前向,避免计算量跟着总参数线性增长。这个组合特别适合“参数少、计算不能太贵”的场景。

背景:Conformer Seq2Seq ASR

论文使用的是 attention-based encoder-decoder 框架。编码器把声学特征序列变成高层表示,解码器按 token 逐步生成文本序列,训练时优化负对数似然,推理时用 beam search 找更可能的输出。

论文中先把 AED 的逐 token 预测概率写成下面这个形式,其中 y<s 表示当前位置之前的 token 前缀:

\( P(y_s \mid y_{<s}, x)=\mathrm{Trfm}(y_{<s},x) \)

对应的最大似然训练目标,也就是负对数似然损失为:

\( L_{\mathrm{nll}}(\theta)=-\frac{1}{S}\sum_{s=1}^{S}\log P(y_s\mid y_{<s},x) \)

Conformer 块由两个 FFN、一个多头自注意力模块和一个卷积模块组成。两个 FFN 采用半步残差风格,注意力负责长程依赖,卷积负责局部模式。本文的 MoE 改造发生在第二个 FFN:作者把它替换成一个稀疏门控的专家集合,也就是 MoE-Conformer block。

论文把一个 MoE-Conformer block 的计算写成四步。最后一步中,第二个 FFN 被替换成 MoE 版本:

\( \begin{aligned} z_t^{(1)} &= z_t + \frac{1}{2}\mathrm{FFN}(z_t),\\ z_t^{(2)} &= z_t^{(1)} + \mathrm{MHSA}(z_t^{(1)}),\\ z_t^{(3)} &= z_t^{(2)} + \mathrm{Conv}(z_t^{(2)}),\\ \hat{z}_t &= \mathrm{LayerNorm}\left(z_t^{(3)}+\frac{1}{2}\mathrm{FFN}^{(\mathrm{MoE})}(z_t^{(3)})\right). \end{aligned} \)

方法:共享稀疏门控专家

Conformer 参数共享

作者把连续的 C 个 Conformer 块看作一组,再堆叠 G 组。不同组中相同位置的块共享参数,相当于一组块被递归调用 G 次。这样做的好处很直接:如果想要 12 次变换,不一定真的保存 12 套编码器参数,可以用更少的块反复计算。

但是共享不是白来的。共享块在浅层和深层面对的表示分布不一样,如果完全用同一套参数、同一套路由、同一套归一化统计,模型会很难同时适配不同深度的表示。因此后面两个设计,也就是独立路由器和独立归一化,就变得很关键。

MoE 动态路由

MoE 模块由 E 个并行 FFN 专家和一个 router 组成。对每个时间步的表示,router 输出各专家的概率,论文采用 top-1 选择,只激活得分最高的专家。也就是说,虽然模型里存着多个专家参数,但每次计算只走其中一个 FFN。

top-1 MoE 的路由过程如下。router 先产生各 expert 的 gate 分数,再选择最大分数对应的 expert:

\( \begin{aligned} g &= [g_0,\cdots,g_{E-1}]=\mathrm{softmax}(\mathrm{router}(z_t^{(3)})),\\ i^* &= \arg\max_{0\le i\le E-1} g_i,\\ \mathrm{FFN}^{(\mathrm{MoE})}(z_t^{(3)}) &= g_{i^*}\mathrm{FFN}_{i^*}(z_t^{(3)}). \end{aligned} \)

这个设计把“容量”和“计算”部分解耦:总参数更多,潜在表达空间更大;但激活参数不增加太多,推理计算仍接近普通 FFN。为了避免所有样本都挤向同一个专家,作者加入 load balancing loss,同时在训练时给 router 加高斯噪声,让专家选择更分散。

负载均衡损失用于鼓励 expert 被更均匀地使用:

\( L_{\mathrm{balance}}=E\sum_{i=0}^{E-1}f_i\bar{g}_i \)

独立路由器与归一化

论文没有把所有 MoE router 都一起共享,而是让每个 MoE 模块拥有自己的 router。直觉上,同一个共享块在第 1 次、第 6 次、第 12 次递归调用时,输入表示已经处在不同层级;如果路由路径完全一致,就会限制专家选择的灵活性。

归一化层也类似。LayerNorm、BatchNorm 的统计和缩放偏移参数对表示分布很敏感。作者让归一化模块保持独立,使不同层级的表示能够维持各自合适的统计状态。论文还把归一化中的 scale 和 offset 看作一种轻量 adapter,用很少参数增强共享块的适配能力。

隐藏层知识蒸馏

共享模型再聪明,毕竟参数少。作者用全参数 Conformer 编码器作为 teacher,让共享模型的编码器输出尽量接近 teacher 的隐藏表示。这里不是只蒸馏最终预测分布,而是直接约束隐藏 embedding 的 L2 距离。这样做的目的,是让小模型学习 full model 的中间表征轨迹。

hidden embedding 蒸馏损失直接约束 student encoder 输出 h_t 与 teacher encoder 输出 h_t' 的距离:

\( L_{\mathrm{kd}}=\frac{1}{T}\sum_{t=0}^{T-1}\lVert h_t-h_t’\rVert_2 \)

训练目标

最终损失由三部分组成:主任务的负对数似然、MoE 的负载均衡损失、隐藏层知识蒸馏损失。负载均衡项负责让专家不塌缩,蒸馏项负责让共享模型贴近全参数 teacher。论文还在实验中加入 CTC loss 来辅助对齐。

\( L=L_{\mathrm{nll}}+\frac{\alpha}{C}\sum L_{\mathrm{balance}}+\beta L_{\mathrm{kd}} \)

这里 C 是 MoE module 的数量,αβ 分别控制负载均衡损失与蒸馏损失的权重。

与已有工作的关系

MoE 常被用来扩大模型容量,尤其是在 NLP 大模型里,通过条件计算扩展到很大的参数规模。但这篇论文不是追求超大规模,而是把 MoE 当作参数高效工具:共享专家、重复使用专家,让少量模块发挥更大作用。

跨层权重共享也不是新想法,ALBERT、Universal Transformer 以及若干 ASR 工作都用过类似机制。本文的不同点在于,它没有只做朴素共享,而是在共享结构里加入稀疏专家,同时让 router 和 normalization 独立,从而减少共享带来的容量和分布适配问题。

实验:

实验设置

实验使用 AISHELL-1 普通话语音识别数据集:约 150 小时训练语音、18 小时开发集、10 小时测试集。输入特征为 80 维 FBANK,窗口 25ms、步长 10ms,并使用全局 CMVN、速度扰动、SpecAugmentation 和 time stretch 等增强手段。词表包含 4235 个中文字符以及起止符号。

模型前端是两层 CNN subsampling,把帧率降到 25Hz。编码器维度为 256,MHSA 使用 4 个头,卷积核大小 15,FFN 中间维度 1024。MoE-Conformer 的第二个 FFN 使用 4 个专家,解码器是 4 层 Transformer。训练 80 个 epoch,使用 PyTorch 和 FastMoE 实现。

结果与分析

主表里,全参数 C12 编码器参数量为 21.58M,测试集 CER 为 4.93。最终的 C2-MoE4-G6-KD 只有 6.95M 编码器参数,测试集 CER 为 5.03。换句话说,它用大约三分之一的编码器参数,做到了非常接近 full-parameter 模型的结果。

消融实验显示,单独减少块数会明显损伤效果,例如 C2 的测试 CER 为 6.50;加入 MoE 后,C2-MoE4 降到 6.22,说明专家机制确实补了一部分容量。再加入跨层共享递归计算后,C2-G6 为 5.62,而 C2-MoE4-G6 达到 5.08,说明“共享 + MoE”的组合比任一单独机制更有价值。

独立路由器和归一化的作用也很明显。C2-MoE4-G6 如果全部共享,测试 CER 为 6.00;只让归一化独立,降到 5.21;归一化和 router 都独立后,进一步到 5.08。这说明共享模型最怕的不是参数少本身,而是不同深度表示被迫使用完全相同的适配路径。

知识蒸馏带来的提升相对温和,但在 C2-MoE4-G6 上仍把测试 CER 从 5.08 推到 5.03。作者还通过输入输出 L2 距离观察模型内部变化:带独立 router 和 normalization 的共享模型更接近全参数 C12 的变化曲线,而全共享模型曲线更不稳定。

结论与未来方向

这篇论文的价值在于,它给出了一个较完整的参数高效 Conformer 方案:用跨层共享压缩参数,用稀疏 MoE 恢复容量,用独立路由器和归一化适配不同深度表示,再用隐藏层蒸馏补齐小模型表现。最终模型在 AISHELL-1 上以约三分之一编码器参数接近全参数模型。

它也留下了自然的后续问题:方法是否能在更大规模、多语种或更复杂的 ASR 数据集上保持优势?能否迁移到 RNN-T、CTC 或其他端到端 ASR 架构?从工程角度看,这类方案的吸引力很强,因为它不是单纯追求小模型,而是在“参数、计算、表达容量”之间做更细的拆分。

MoEAdapter for Large Audio Language Models: Sparsity, Disentanglement, and Gradient-Conflict-Free

这篇论文 MoE Adapter for Large Audio Language Models: Sparsity, Disentanglement, and Gradient-Conflict-Free 的问题意识很明确:大语言模型要理解真实世界,不能只看文本,音频是很重要的输入模态。但音频并不是一种均匀信号。语音、音乐、环境声承载的信息结构不同,如果用一个 dense adapter 把所有音频都压进同一个文本 embedding 空间,很容易出现参数更新方向互相冲突。

摘要:用专家分工处理异质音频

论文提出 MoE-Adapter,用稀疏 Mixture-of-Experts 替代传统的 dense audio adapter。它不是让所有音频 token 都通过同一套 FFN,而是用动态门控把 token 路由到若干专门专家,同时保留一定共享能力来捕捉全局上下文。这样,语音、音乐、环境声等不同属性可以在不同专家子空间中被建模,从而减轻梯度冲突。

实验基于 Qwen3-1.7B 骨干,音频前端使用 Whisper-VQ tokenizer 和 Whisper Encoder。作者在相同参数预算下比较 dense adapter 和 MoE-Adapter:两者总参数约 94.4M,但 MoE 因稀疏激活,推理时只激活约 70.8M 参数。结果显示,MoE-Adapter 在 MMSU、OBQA、MMAU 等音频理解和推理任务上均优于 dense baseline,并减少音频输入与文本输入之间的 modality gap。

引言:音频不是一种单一分布

大语言模型在文本推理上已经非常强,但只处理文本会限制它们感知现实世界的能力。音频包含人类说话、环境声音、音乐和情绪韵律等信息,是多模态智能绕不开的一环。当前许多大音频语言模型的主流做法,是加一个 adapter,把声学特征投影到 LLM 的文本语义空间里。

问题在于,很多 adapter 是 dense、参数共享的:所有音频都经过同一套投影层。这隐含一个假设,即不同音频类型可以被同一种映射均匀处理。作者认为这个假设过强。语音主要承载语义和语言结构,音乐更关注节奏、旋律和情感,环境声又有自己的声学模式。它们在表示空间中可能位于不同流形。

如果一个 dense adapter 同时学习这些相互差异很大的目标,不同数据类型的梯度可能朝相反方向更新同一组参数。这就是论文强调的 gradient conflict。MoE-Adapter 的贡献,就是用动态专家路由把这些冲突拆开:相似属性共享专家,冲突属性进入不同专家。

相关工作

大音频语言模型

早期音频问答或语音交互系统常采用级联管线:先 ASR 转文字,再交给 LLM。这样的系统容易受到识别错误传播影响,也会丢失语调、情绪、音乐和环境声等非文字信息。后来的端到端 LALM 通过可学习 adapter,把声学特征映射到文本空间,让 LLM 直接条件化在音频表示上。

现有 adapter 大致分为 Q-Former 类和 linear projector / MLP projector 类。后者结构简单、效率高,因此被许多最新模型采用。但这种全局共享投影层难以面对音频内部的分布差异。本文正是针对这个瓶颈,把稀疏 MoE 引入 audio-text alignment 阶段。

MoE 架构

MoE 的基本思想是让不同专家处理不同样本或不同 token,通过稀疏门控实现条件计算。它已经在语言模型、多模态模型、视觉语言模型等方向证明了对异质数据和任务冲突的缓解能力。音频领域也开始出现 MoE 相关工作,例如生成、医疗音频特征选择等。

不过,在通用 audio-text alignment 这个环节,主流 LALM 仍大量依赖静态、共享参数 adapter。本文的 MoE-Adapter 不只是借用 MoE 扩容量,而是把 MoE 作为一种“解耦工具”,专门处理音频属性之间的冲突。

方法

整体框架

模型采用类似 Kimi-Audio 的 dual-stream 音频前端:一条路径用冻结 tokenizer 提取离散语义 token,另一条路径用 speech encoder 提取连续声学特征。两类表示经过投影和融合后,进入 adapter。

传统方案会用 dense adapter 把融合音频特征映射到 LLM embedding 空间。本文则用 MoE-Adapter 完成这一步。最终,adapted audio embeddings 与文本 token embeddings 拼接,作为 LLM 的输入,并用标准自回归 next-token prediction 训练。

稀疏 MoE Adapter

Dense adapter 可以看作一个单体 FFN:所有音频 token 都通过同一组权重。作者指出,这种设计强制同一组参数同时容纳异质音频,会形成不必要的优化干扰。

论文先把 dense adapter 写成单体 FFN 投影。给定音频 token x,输出 embedding 为:

\( y=\mathcal{N}\left(W_{d2}\cdot\sigma\left(W_{d1}\cdot\mathcal{N}(x)\right)\right) \)

MoE-Adapter 把单体 FFN 替换成专家集合。每个专家都是轻量 FFN,router 根据输入 token 计算各专家得分,并通过 Top-k 选择保留若干活跃专家。被选中的专家输出按门控权重聚合,形成中间表示。随后再经过输出投影和 LayerNorm,对齐到 LLM embedding 维度,用来替换输入序列中的音频占位 token。

每个 expert 本身也是一个轻量 FFN:

\( E_i(x)=W_{e2}^{(i)}\cdot\phi\left(W_{e1}^{(i)}\cdot\mathcal{N}(x)\right) \)

router 根据 logits s=xW_g 做 Top-k 稀疏选择,再 softmax 得到门控概率:

\( G(x)=\mathrm{softmax}\left(T_k(s)\right),\quad s=xW_g \)

被选中的 expert 输出按 gate 权重聚合,并经过最终投影对齐到 LLM embedding 空间:

\( h_{\mathrm{MoE}}=\sum_{i\in I}G(x)_i\cdot E_i(x) \) \( y_{\mathrm{MoE}}=\mathcal{N}\left(W_P\cdot h_{\mathrm{MoE}}\right) \)

这套机制有两个效果:一是稀疏激活降低推理成本,二是专家分工让不同音频属性进入不同子空间。对于语音、音乐、环境声这种天然异质输入,第二点尤其重要。

训练目标

训练目标由 next-token prediction loss 和 auxiliary load-balancing loss 组成。前者让模型基于音频上下文预测后续文本 token,是主任务;后者用于避免 expert collapse,即所有 token 都涌向少数专家。

总训练目标为 next-token prediction 与负载均衡项的加权和:

\( L=L_{\mathrm{NTP}}+\lambda L_{\mathrm{aux}} \)

其中主任务 NTP loss 写成:

\( L_{\mathrm{NTP}}=-\sum_{t=1}^{T}\log P(y_t\mid y_{<t},X;\theta) \)

负载均衡损失会同时考虑专家的重要性和实际负载,让不同专家都被充分训练。这里有一个微妙的取舍:过强的均衡可能压制某些自然形成的专家偏好,但完全不均衡又会损害高层语义推理的泛化。论文后面的消融和分析专门讨论了这个矛盾。

论文将 expert importance 与 expert load 分别定义为:

\( \bar{P}_e=\frac{1}{B}\sum_{b=1}^{B}p_{b,e} \) \( \bar{f}_e=\frac{1}{B}\sum_{b=1}^{B}r_{b,e} \)

最终 auxiliary loss 为:

\( L_{\mathrm{aux}}=|\mathcal{E}_R|\sum_{e\in\mathcal{E}_R}\bar{P}_e\cdot\bar{f}_e \)

实验

实验设置

LLM 骨干是 Qwen3-1.7B,音频前端使用 Whisper-VQ tokenizer 和 Whisper Encoder。训练语料规模为 40B token,优化器为 AdamW,学习率调度采用 Warmup-Stable-Decay。为了公平比较,dense adapter 与 MoE-Adapter 的总参数预算都限制在约 94.4M。

评测覆盖几类能力。MMAU 用于音频感知和副语言理解,覆盖 speech、sound、music 等场景;VoiceBench 中的 MMSU 和 OpenBookQA 子集用于世界知识和语义推理,它们是从文本推理基准改造来的音频版本。所有评测采用 greedy decoding,避免采样随机性干扰比较。

主结果

在知识推理任务上,MoE-Adapter 明显超过 dense baseline。MMSU 的 audio accuracy 从 35.03 提升到 38.19,OBQA 从 50.10 提升到 53.85。对比文本输入准确率,音频输入仍存在明显 gap,但 MoE 把这个差距分别缩小了约 3.16 和 3.75 个点。

在 MMAU 这类副语言和音频感知任务上,MoE-Adapter 也从 59.79 提升到 61.50。这个提升说明专家路由不仅对知识推理有用,也能帮助模型捕捉更复杂的声学线索。论文强调,MoE 的收益不是单纯参数变多,而是在相近总参数预算下更合理地分配表示能力。

消融实验

专家配置方面,默认的 “8 choose 4” 表现最均衡:MMAU 61.50、MMSU 38.19、OBQA 53.85。把专家数扩大到 “16 choose 4” 反而变差,说明专家总数不是越多越好。把路由变得过稀疏,例如 “8 choose 1”,也会显著伤害音频推理。论文的结论是,专家数量、激活数量和专家容量之间需要平衡,而不是盲目扩某一个维度。

负载均衡损失的消融更有意思。去掉 EBL 后,MMAU 从 61.50 升到 63.01,但 MMSU 和 OBQA 分别下降到 37.37 和 52.31。作者解释说,MMAU 很异质且含有大量低层声学感知样本,不加均衡时 router 会集中使用少数“强专家”,反而有利于这类感知任务;但这会减少专家多样性,损害需要世界知识和语义推理的任务

专家分工与优化动态分析

专家均衡如何影响路由

作者在 MMAU 上分析 speech、sound、music 三类样本的专家激活热力图。结果显示,模型确实学出了模态相关的专家分工:有些专家主要服务单一类别,有些专家在 sound 与 speech 或 sound 与 music 之间共享。值得注意的是,几乎没有专家同时专门服务 speech 和 music。

这个现象符合直觉:环境 sound 和 speech/music 都可能共享一些低层声学特征,因此可以作为“桥”;但 speech 和 music 在时间结构、语义组织上差异更大,不适合强行塞进同一个专家。EBL 并不会消灭这种分工,而是防止少数专家过度支配,保留一定均衡。

梯度冲突与缓解机制

论文用两个指标分析优化过程。第一个是不同音频类别梯度之间的 cosine similarity。dense adapter 中,不同类别的梯度经常出现负相似度,意味着一个类别的更新方向可能伤害另一个类别。MoE-Adapter 则把这些相似度推向更正的方向,说明专家路由减少了破坏性干扰。

第二个是 gradient influence score,用来衡量基于某一任务梯度做更新后,对另一个任务损失是帮助还是伤害。dense adapter 中,speech 的更新会明显伤害 music 和 sound;MoE-Adapter 中,影响分数更多为正,说明它不是简单隔离任务,还能通过共享专家保留有益迁移。例如 speech 对 sound 的更新可以产生正向帮助,而 music 的冲突被更好地隔开。

结论

这篇论文把 MoE-Adapter 定位为解决 LALM 音频异质性的结构工具。相比 dense adapter,它用动态专家分工缓解语音、音乐、环境声之间的梯度冲突,在相近参数预算下提升音频知识推理、副语言理解和跨模态对齐表现。更重要的是,论文不仅给出指标提升,也通过路由热力图、梯度相似度和影响分数解释了为什么 MoE 有效。

局限性

作者也明确指出了几个限制。第一,实验目前只在 Qwen3-1.7B 骨干上验证,方法是否适用于其他 LLM 家族或更大规模模型,例如 70B,还需要实验。第二,论文没有系统研究稀疏路由随训练数据规模增长的 scaling law。第三,当前任务集中在音频理解与推理,没有扩展到生成式音频任务。

附录:超参数和工程含义

附录强调,dense baseline 与 MoE-Adapter 在总参数预算上被严格对齐,约为 94.4M。MoE-Adapter 的活跃参数约为 70.8M,大约是 dense baseline 的 75%。共同音频前端包含 speech encoder、audio hidden projection 和 feature fusion;MoE 端则包含专家集合、gate network 和 aggregation block。

从工程角度看,这个设置很关键。它把论文的结论从“MoE 参数更多所以更强”拉回到“在可比预算下,稀疏专家分工更适合异质音频”。如果未来大音频语言模型要同时处理语音问答、环境声推理、音乐理解和情绪韵律,adapter 层可能不该再是一个单体投影器,而应该具备更细粒度的路由和分工能力。

Mega-ASR 面向“全场景复杂环境”高噪语音识别

Mega-ASR 是一个专门解决”真实世界语音识别翻车”问题的开源框架——它用涵盖54种噪声、回声、丢帧等复合场景的240万条数据训练,让模型在嘈杂现实环境下的词错误率降低30%+,同时大幅减少”听没了”和”乱编内容”这两种高频故障。解决的核心问题是:在各种嘈杂、失真、回声、断连的现实场景下,尽可能准确地把语音转成文字。模型基于 Qwen3-ASR-1.7B进行后训练,通过一套专门设计的数据集和训练方法来强化”恶劣环境下的识别能力”。

一、ASR 在「现实世界环境」为什么不行?

  • 场景覆盖太窄:只解决噪音 / 远场单一问题,真实环境是复合干扰(噪音 + 混响 + 丢包一起上)。
  • 复合鲁棒性缺失: 缺乏对复杂环境的适应性,现实世界中的环境往往是多种因素共同作用的结果,很少模型能同时扛住多种失真叠加。
  • 训练与真实不匹配:训练数据太简单(WER 4%–10%),遇到高难度场景(WER>30%)直接崩

二、数据:Voices-in-the-Wild-2M

大规模、高难度、物理合理的复合声学仿真数据集

现有语音数据集的 3 大致命问题:

  1. 只覆盖单一干扰:噪音 / 混响 / 远场分开做,不模拟真实复合环境
  2. 难度太 “温柔”:平均 WER 只有 4%–10%,训练不出强鲁棒模型
  3. 真实录音太少太贵:收集覆盖所有场景的真实录音成本极高、不可扩

为了推动这一更具挑战性场景下的研究,提出了 Voices-in-the-Wild-2M,一个基于频谱级代码驱动仿真(spectrogram-level code-based simulation)构建的大规模数据集。这种设计使得超大规模数据生成成为可能。

首先识别并定义了 7 类经典的现实声学效应,这些基础效应用于模拟各种物理环境或设备引起的退化现象:

真实退化现象对应 Primitive
背景噪声Additive Noise
延迟反射Echo Delay
房间混响Reverberation
削波失真Nonlinear Distortion
带宽受限Resampling
高频衰减Spectral Filtering
音量不一致Loudness Transformation
丢包/卡顿Frame-level Stutter

设计了专门的频谱处理流水线,持续调整仿真参数,并利用 Qwen3-ASR 的监督微调(SFT)结果进行验证,直到模拟器在真实数据上的表现达到最佳拟合效果。

将这些原子效应组合成 54 种经过 Agent 验证的复杂声学配置,最终生成了 240 万条(2.4M)合成语音样本

与直接枚举各种复杂真实环境不同,将野外环境(in-the-wild)中的语音退化过程划分为三个层级:

  • Primitive Acoustic Effects(基础声学效应)
  • Atomic Acoustic Effects(原子声学效应)
  • Compound Acoustic Scenarios(复合声学场景)

第一层:Primitive Acoustic Effects(基础声学效应)

用 DSP 手段实现最基本的声学退化组件

原子效应核心基元组合模拟真实场景
噪声(Noise)加性噪声 + 响度归一街道、咖啡馆、车内、人群
远场(Far-field)混响 + 低通滤波 + 响度衰减远距离说话、智能音箱远场
遮挡(Obstructed)低通滤波 + 混响 + 衰减隔门、隔窗、口罩、墙后说话
回声 + 混响(Echo&Reverb)强混响 + 回声 + 高通大厅、车库、体育馆、空旷房间
录制染色(Recording)重采样 + 噪声 + 双带通滤波手机外放再录制、设备串音
电子失真(Electronic Distortion)非线性失真 + 低通麦克风过载、削波、劣质录音
传输丢包(Transmission Dropout)帧卡顿 + 响度归一网络丢包、蓝牙不稳、流媒体卡顿

第二层:Atomic Acoustic Effects(原子声学效应)

在中间层,我们利用上述 Primitive Effects 构建了 7 种原子声学效应

Atomic Effect中文
Noise噪声环境
Far-field远场录音
Obstructed遮挡语音
Echo & Reverb回声与混响
Recording录音链路效应
Electronic Distortion电子失真
Transmission Dropout传输丢失

一个 Atomic Effect 并不一定只对应一个 Primitive Effect。而是一个主导 Primitive + 若干辅助 Primitive。

比如:Far-field(远场)真实远场录音不仅仅是声音变小。通常同时具有:

  • 声压衰减(Loudness)
  • 高频损失(Spectral Filtering)
  • 房间混响(Reverb)

第三层:Compound Acoustic Scenarios(复合声学场景)

最高层将多个 Atomic Effects 进行组合,比如视频会议

Far-field + Echo&Reverb + Recording

无论构建 Atomic Effect 还是 Compound Scenario,都保持 Primitive Effect 的固定执行顺序。为的是避免物理上不合理的处理链

关键创新:不是随机乱组合,而是按物理规则合成

组合规则(保证真实不违和)

  • 锚点效应(3 种):远场 / 回声混响 / 遮挡(互斥,不同时出现)
  • 修饰效应(4 种):噪声 / 录制染色 / 电子失真 / 丢包(可叠加)

为了让难度 “均匀且可学习”,团队设计了全局 severity 参数 m ∈ [0,1]

  • 同一个音频里,所有失真共用一个 m
  • 保证:要么整体简单,要么整体难,不会出现 “强混响 + 零噪音” 这种不自然组合

最终选用 Linear 线性分布

  • 简单、中等、困难样本均匀覆盖
  • 训练最稳定、泛化最强

严格过滤保证可学习

  • 剔除 WER > 70% 的样本(太难学不动)
  • 保留物理合理组合
  • 统一响度、统一格式、对齐标注

三、Mega-ASR

 Qwen3-ASR 的基础上开发了 Mega-ASR-Base 模型

1. A2S-SFT:从声学 → 语义递进微调

解决:高失真下「听不清 → 猜不对」的连锁崩溃。分三阶段训练:

  1. 声学感知阶段:编码器 + 对齐器,按难度递进(WER<30% → <50% → <70%)
  2. 语义恢复阶段:冻结声学,只微调 LLM,学会从残缺信号还原语义
  3. 联合对齐阶段:全模块一起微调,声学与语义对齐

2. DG-WGPO:双粒度 WER 门控策略优化

解决:普通 WER 奖励在高失真下失效(只看词错,不管语义崩没崩)。设计两套奖励,按 WER 动态切换:

  • 低 WER(<30%):侧重词级别精细修正(软错误 / 硬错误区分)
  • 高 WER(≥30%):侧重句子级结构恢复(主干语义、长度、最长公共子串)

最终奖励 = 基础规则奖励 + 双粒度动态奖励

3. 环境感知路由(Router)

解决:鲁棒模型在干净音频上略有下降。

  • 训练一个轻量二分类器,判断音频是否恶劣
  • 恶劣 → 走 Mega-ASR
  • 干净 → 走原生 Qwen3-ASR
  • 推理开销 <1%,几乎无感

三、Experiments

Main results 

采用自适应路由的通用 ASR 性能具有竞争力:MEGA-ASR 在干净语音和多语言基准测试上,相较于 Qwen3-ASR、Seed-ASR 和 Kimi-Audio 仍保持极强的竞争力。

声学扰动条件下达到当前最佳鲁棒性:相较于最强基线 Qwen3-ASR,MEGA-ASR 的错误率进一步降低了 17.4%;相较于 Gemini-3-Flash,则降低了 64.5%

在组合式真实环境中的鲁棒性表现更优

在 Voices-in-the-Wild-Bench 基准测试中,MEGA-ASR 在多种真实世界退化条件下均取得了最佳性能,包括:

  • 混合退化(mixed degradations)
  • 远场语音(far-field speech)
  • 录音伪影与设备缺陷(recording artifacts)

Analysis

通过消融实验,我们总结出五个关键观察([Obs.1]–[Obs.5]),涵盖了语义层面收益、训练策略、奖励函数设计以及超参数敏感性等方面。相关证据分别来自表 5–9。下面对各项发现进行详细说明。

[Obs.1] MEGA-ASR 的收益不仅体现在 WER 上,也体现在语义层面指标上

表 7 显示,相比 Qwen3-ASR,MEGA-ASR 在语义层面指标上也取得了持续提升:

  • 漏识内容(Missed Content)从 14.2 降低到 5.9

这表明,MEGA-ASR 的改进不仅仅是降低词错误率(WER),还带来了更高层次的语义和整体理解能力提升,例如:

  • 减少幻觉(Hallucination);
  • 减少整句或整段语音遗漏(Dropped Utterances);

因此,MEGA-ASR 实现的是语义层面和整体层面的质量提升,而不仅是字词级别的识别优化。

[Obs.2] A2S-SFT 与 DG-WGPO 组件的消融分析

在 Voices 和 Noizeus 数据集上,对 A2S-SFT 各阶段以及 DG-WGPO 各组成部分进行了消融实验(表 5)。

  • 分阶段的“声学到语义(Acoustic-to-Semantic)适配”过程是有效且必要的。
  • DAPO 作为强化学习阶段的基础优化框架。
  • 句子级重构奖励对于中高错误率样本尤为关键。

[Obs.3] 基于规则的奖励函数与 LLM Judge 效果相当,但训练成本降低 3.2 倍

规则奖励已经能够充分捕获 LLM Judge 所提供的监督信号。

[Obs.4] 超参数消融实验

动态门控权重 αdyn 语义奖励权重 αs对模型性能的影响(表 8)

αdyn 所控制的权衡关系远比 αs 更敏感。

最终采用:

(αdyn, αs) = (0.6, 0.4)

因为它在所有测试子集上都达到最佳或接近最佳表现。

[Obs.5] 门控阈值 τ 的影响

过高的门控阈值会使门控机制过于严格(over-restrictive gating),从而限制奖励信号的有效传播,最终导致识别性能下降。

通过消融实验,得到以下核心结论:

  1. MEGA-ASR 的收益不仅体现在 WER,还体现在语义完整性与内容保真度上。
  2. A2S-SFT 的渐进式声学→语义适配以及 DG-WGPO 的各奖励组件均对性能提升至关重要。
  3. 规则奖励能够以接近 LLM Judge 的效果实现训练,同时将计算成本降低 3.2 倍。
  4. 动态门控权重 αdyn 是最敏感的超参数,最佳设置为 0.6。
  5. 门控阈值 τ=0.3 能在不同场景下取得最均衡的鲁棒性表现。

NIM4-ASR: 高效鲁棒可定制的实时LLM语音识别

paper: https://arxiv.org/abs/2604.18105

面向生产部署的 LLM-ASR 框架,系统解决轻量化、幻觉抑制、热词定制三大痛点。基于 phoneme-level encoder 预训练减少模态差距,引入 Iterative Asynchronous SFT(IA-SFT)防止 representation drift,设计 ASR 专用 RL 提升识别质量,并以 phoneme RAG 实现百万量级热词定制。

音频 → 600M Conformer Encoder(phoneme CTC 预训练,CKA 监控 drift)
                    ├── 流式:dynamic-chunk mechanism(预训练期内嵌)
                    └── phoneme CTC head → 音素假设
         MLP Adapter(4x 下采样,160ms/token)
                    ↓
              Qwen3-1.7B(LLM 解码器)
                    ↑
         Phoneme RAG:音素假设 → 检索热词数据库(<1ms)→ Prompt 注入

训练 pipeline:
    Stage1: Encoder 预训练(phoneme CTC,CR-CTC)
    Stage2: Alignment(仅训练 Adapter,冻结其余)
    Stage3: IA-SFT(异步并行,CKA 监控 encoder 稳定性)
    Stage4+5: Late Joint SFT + Context SFT + ASR-RL

Challenge

1、Limited downward scalability

在实际部署中,尤其是实时语音交互场景下,轻量级 ASR 模型由于推理延迟更低、计算成本更小因此更受青睐。然而,基于 LLM 的 ASR 在模型缩小后的性能表现并不理想:比如Qwen3-ASR-0.6B、Fun-ASR-nano这类轻量版本相比完整大模型存在明显性能差距。除了模型缩小本身带来的性能下降外,LLM-ASR 还额外承担了一种:模态税(modality tax),

即:模型中有相当一部分参数并不是直接用于 ASR 任务,而是用于跨模态对齐(cross-modal alignment)。这种结构性开销会导致轻量 LLM 真正可用于 ASR 的有效容量更少,从而带来不成比例的性能下降。

2、幻觉问题(Hallucination)

除了自回归 LLM 天生存在的 hallucination(幻觉)问题之外,encoder–adaptor–LLM 联合训练范式还会引入额外风险。

在联合优化过程中由于:LLM 梯度更强、LLM 语言先验更强。 encoder 会逐渐被拉向LLM 的优化目标,导致 encoder 的表示逐渐偏移到 LLM 的文本特征空间,称之为representation drift(表示漂移),导致encoder 会越来越依赖语言捷径(linguistic shortcuts)而不是精细声学信息(fine-grained acoustic fidelity)。在噪声、发音模糊、音频不清晰的声学歧义场景下会加重幻觉问题。

3、缺乏工业级热词定制能力(Lack of production-ready hotword customization)

为了解决上述问题,提出了面向工业部署的 LLM-ASR 框架 NIM4-ASR,重点优化推理效率和系统鲁棒性。

  • 提出了一种基于原则的多阶段训练范式
  • 优化了流式处理支持
  • 音素级 RAG 用于热词定制

Methodology

Model

encoder–adaptor–LLM 架构

1、音频特征提取

80 维 log-Mel 频谱,窗长(window):25 ms 帧移(frame shift):10 ms,全局均值方差归一化

2、Streaming speech encoder

编码器采用FireRedASR-AED Conformer,一个 4 倍下采样卷积模块 多层 Conformer Block 堆叠,输出帧率 25Hz,为了支持流式推理,训练阶段会模拟streaming 约束,将其改造成chunk-based streaming encoder

3、Speech adaptor

两层 MLP,将 encoder 输出映射到 LLM 的 embedding 空间,4倍下采样,将连续 4 帧特征进行拼接,帧率从 25 Hz 降到 6.25 Hz,每个 token 160ms。

4、Phoneme-level CTC head and RAG module

三层 MLP,将 encoder 表示解码为 phoneme hypothesis(音素假设),greedy decoding。RAG 模块会根据这些音素序列检索 hotword 数据库,将热词作为上下文提示注入 prompt

5、LLM decoder: Qwen3-1.7B

Training Recipe

与以往主要依赖经验微调的工作不同,首先对当前基于 LLM 的 ASR 系统的实际局限性及其根本原因进行了系统性的分析  ,结果表明跨模态差距和表征漂移问题仍未得到充分解决。基于这些见解,我们对训练流程进行了全面重新设计。如图 2 所示,NIM4-ASR 的方法论改进主要体现在四个核心训练阶段:编码器预训练、对齐、IA-SFT 和后期联合 SFT。除了这四个阶段的流程之外,我们在后期联合 SFT 之后进一步加入了上下文 SFT 和强化学习(RL),以增强上下文建模和鲁棒性。具体步骤如下所述。

 第一阶段:编码器预训练

为了缩小编码器表征与 LLM 嵌入空间之间的模态差异,采用了一种改进的连接主义时间分类(CTC)变体  ——即 CR-CTC 作为预训练目标。如图 2 所示,预训练期间的模型架构由编码器和 CTC 头组成。与先前工作中常用的基于注意力机制的编码器-解码器(AED) 相比,CTC 鼓励编码器生成低熵、音素区分性强的表征,使其与 LLM 的嵌入空间更自然地对齐,从而减少跨模态对齐的开销,并为自动语音识别(ASR)任务保留更多模型容量

将监督标签从字符级转移到音素级 ,明确地将编码器的容量用于声学到音素的映射,而不是过早地进行语义锚定,同时鼓励语言学习模型(LLM)更多地关注语义推理。这种设计实现了声学建模与语义推理的更清晰解耦,提高了两个模块的角色专业化程度。此外,采用音素预测作为预训练目标,鼓励编码器学习语言依赖性较弱的底层声学表征,从而为扩展到新的语言和方言提供更大的潜力。

为了赋予编码器原生流媒体处理能力,在预训练阶段引入了动态分块机制。具体来说,编码器在分块流媒体约束下处理完整的语音,其中每个批次的块大小和可见左侧上下文块的数量都是动态采样的。这使得编码器能够适应各种流媒体配置,从而实现灵活操作,以适应不同部署场景下不同的延迟预算。

Stage 2: Alignment & Stage 3: IA-SFT

在传统的训练范式中,对齐和联合 SFT 是在预训练完全完成后依次执行的。如图 2 所示,我们为 NIM4-ASR 提出了一种编码器迭代机制,该机制允许在预训练完成之前开始对齐,而 IA-SFT 在对齐完成后启动,并与剩余的预训练过程异步进行。为了确定何时初始化或更新对齐和 IA-SFT 使用的编码器,我们使用中心核对齐(CKA) 跟踪编码器表示的动态变化。CKA 将不断演化的编码器与在整个预训练过程中初始化并定期更新的参考检查点进行比较。给定从同一评估集中提取的两组编码器表示 E(a),E(b) ,CKA 定义为

第二阶段:对齐。 预训练达到 50 万步后,我们开始监测编码器,此时编码器开始呈现相对稳定的优化趋势。我们将 50 万步时的编码器快照作为初始参考检查点,之后每隔 1 万步预训练评估一次 CKA。当演化中的编码器与当前参考检查点之间的 CKA 分数首次低于预定义阈值.在对齐过程中,编码器和 LLM 均被冻结,仅训练适配器。在我们的设置中,首次触发发生在预训练约 101 万步时,对齐阶段持续 130 万步

第三阶段:IA-SFT。 对齐完成后,我们在联合 SFT 之前执行 IA-SFT 作为中间阶段。IA-SFT 保持编码器冻结,并基于异步预训练过程生成的编码器快照序列训练适配器-LLM 堆栈。具体步骤如下:

(i)初始化与监控。IA -SFT 在对齐完成后开始,使用从对齐过程中继承的编码器进行 100 万步的训练,同时编码器预训练并行进行。CKA 评估从之前更新的参考检查点恢复,并每隔 1 万步预训练步骤重复进行一次,监控表征偏移。

(ii)CKA 触发更新。 每当 CKA 分数低于预定义阈值时,当前预训练编码器的快照就会热插拔到 IA-SFT 分支中,并相应地更新参考检查点。

(iii)最终更新。 更新周期(ii)重复进行,直到预训练达到其 200 万步的​​最大值。预训练完成后,无论 CKA 得分如何,都将应用最终编码器更新,并且 IA-SFT 运行最后 200 万步。

在我们的实现中,IA-SFT 使用 101 万步预训练时的编码器检查点进行 100 万步训练,再使用 132 万步预训练时的编码器检查点进行 100 万步训练,最后使用完全预训练的编码器进行 200 万步训练——总共在三个编码器版本上进行了 400 万步训练。在 IA-SFT 过程中,编码器保持冻结状态,但会定期从异步预训练过程中更新,从而保持声学基础。这使得模型能够在不出现表征漂移风险的情况下加深跨模态对齐。从课程学习的角度来看,IA-SFT 逐步将 LLM 暴露于更精细的编码器表征中,使其能够学习不变模式并提高对声学扰动的鲁棒性。此外,由于对齐和 IA-SFT 与预训练异步运行,因此整个训练流程仍然保持高效。

Stage 4: Late Joint SFT

在编码器预训练和 IA-SFT 完成后,语音表征与 LLM 嵌入空间之间建立了稳健的初始跨模态映射。随后,我们执行后期联合 SFT,其中编码器、适配器和 LLM 以端到端的方式联合优化。与传统的联合训练相比,由于前期阶段已经最小化了模态差异,LLM 梯度引起的表征漂移风险显著降低。因此,这些梯度主要作为微调信号,无缝地优化声学到音素的映射以及音素到语义的关联。从几何角度来看,前期的对齐阶段建立了一个稳定的跨模态流形,使后续优化处于损失函数曲面的低曲率区域。在该区域内,梯度更新是对决策边界和流形几何结构的局部优化,而不是引起大规模的拓扑重构。

Stage 5: Context SFT

首先从训练语料库构建关键词集 S 。所有转录文本均被解析以提取候选短语,然后使用 Qwen3-30B-A3B-Instruct进行过滤,以保留命名实体,例如人名、兴趣点(POI)、媒体名称和专有名词。在训练过程中,我们提高长时长话语的采样比例,并按照以下模板,将从 S 中采样的关键词以概率方式注入到提示中作为上下文提示:

每个训练实例,我们首先从转录文本中存在的 S 中提取相关关键词。此外,对于每个关键词,我们以一定的概率从 S 中提取发音相同或高度相似的另一个关键词作为干扰项。相关关键词和干扰项被连接起来,然后添加到 {context} 字段中。干扰项的加入可以防止语言学习模型 (LLM) 过度依赖上下文线索而牺牲语义合理性。在此阶段,编码器、适配器和 LLM 会进行联合训练。

此阶段的设计目的在于实现热词定制,而非跨回合对话的一致性。对于多回合场景,还可以将从对话历史中提取的关键词添加到当前提示中。这种策略以紧凑的形式保留了关键的上下文信息,同时保持了比句子层面方法更低的推理延迟。

Stage 6: ASR Specialized RL

GRPO,奖励函数:

  • Accuracy reward
  • Hallucination reward
  • Context reward

Additional Stage: Phoneme Head Training for RAG

完成强化学习(RL)阶段后,主训练流程结束。接下来,我们引入一个额外的阶段来训练图 1 所示的 RAG 模块所需的音素头。在该阶段,编码器继承强化学习后检查点的结构和权重并保持冻结状态,而音素头则从预训练的 CTC 头初始化并保持可训练状态。训练目标和配置与预训练阶段一致。经过微调后,音素头可以将编码器表示转换为音素假设,供后续检索模块使用。

Training Setup

Robustness enhancement under noisy and silent conditions。应用了多种数据增强技巧来提高模型的鲁棒性。除了标准的 SpecAugmentation  和速度扰动之外,我们还随机地将一些真实的声学干扰(例如人声、车辆噪声和背景音乐)注入到 20%的干净训练样本中,以模拟具有挑战性的真实世界环境。这些噪声注入的信噪比(SNR)是从均值为 10 dB、标准差为 5 dB 的正态分布中随机抽取的。

Inference

优化流式推理

Encoder 与 LLM 解耦部署,Encoder 部署在 Triton,Adaptor + LLM 部署在 vLLM,CTC Head + RAG 部署在 CPU

Prompt 结构设计

[Static Prefix]
↓
[Streaming Speech Embeddings] 增量 append 到 context
↓
[Dynamic Hotword Context] 动态更新热词

两种 Streaming ASR Paradigm

增量假设刷新(hypothesis refresh)
vs
incremental context extension(增量上下文扩展)

| 方案                  | hypothesis refresh | incremental extension |
| ------------------- | ------------------ | --------------------- |
| 历史是否重复 decode       | 是                  | 否                     |
| KV Cache 是否重建       | 经常                 | 基本不                   |
| 是否实时 partial output | 强                  | 弱                     |
| TTFT                | 更低                 | 略高                    |
| Tail latency        | 高                  | 低                     |
| 适合场景                | 长会议                | 实时语音助手                |

Phoneme-based RAG(音素级热词检索)

文本 -> 音素序列,使用 Aho-Corasick 自动机,采用 Hard Matching不做模糊匹配,Retrieval Error 比 Retrieval Miss 更危险。

为了实现高效的热词定制,NIM4-ASR 构建了一个基于音素的热词数据库以及相应的检索算法,如图 1 所示。将每个热词文本预先转换为音素-词元序列,并将其存储为键值对,其中键是音素序列,值是对应的热词文本。这些音素序列首先根据音素词汇表转换为离散索引,然后使用 Aho-Corasick 自动机算法重构为带有失败链接的 trie 树。在推理过程中,编码器上的音素头通过贪婪解码生成音素假设,这些假设被转换为索引序列,并由自动机在一次遍历中扫描完成。当无法扩展部分匹配时,自动机将沿着失败链接找到最长的有效后缀状态,而不是从头开始重新搜索,从而能够以假设长度的线性时间复杂度检索所有候选热词。

为了减少冗余的上下文提示,我们采用了一种最长匹配过滤策略:被较长跨度完全覆盖的较短匹配项将被丢弃,仅保留最长的实体。例如,如果热词“NIO”和“NIO House”在同一假设中同时匹配,则仅保留“NIO House”。检索到的热词文本随后被连接起来,并与语音嵌入一起作为上下文提示注入到 LLM 提示中,从而为解码提供上下文感知的偏置。由于索引级映射的存储效率以及 Aho-Corasick 自动机的线性时间复杂度(仅取决于查询长度而非数据库大小),热词数据库可以轻松扩展到数百万条记录,同时保持每次查询的亚毫秒级检索延迟。

值得注意的是,我们的热词定制旨在优化命名实体(例如地点名称和媒体标题)的识别,这类热词数据库可能非常庞大,并且可能包含大量语音相似甚至同音的条目。为了确保在这种大规模环境下的检索精度,我们在 RAG 模块中采用了硬匹配策略,仅检索精确的音素序列匹配,而非近似匹配或编辑距离最小的匹配。经验表明,检索漏检通常比检索错误危害更小,因为 LLM 仍然可以利用内部语言知识和上下文恢复正确的实体。相比之下,软匹配更容易引入相似但错误的热词,即使模型在一定程度上能够应对噪声上下文提示,这些错误热词仍然会干扰解码。

Evaluation

总结:

NIO 车载场景出发的工业论文,偏向工程落地。phoneme-level encoder 预训练、IA-SFT 防 drift、ASR-RL、百万热词 RAG——每个模块都是真实生产痛点的解法。CKA 动态监控 encoder 表示偏移这个手段很细。但核心数据不公开,学术可复现性为零;”25 个 benchmark SOTA”要打折——主要赢在内部实体密集场景;Streaming 支持是”优化了”而非”重新设计了”。热词检索口音/方言效果差。未来将对话历史作为附加上下文信息纳入多轮交互场景,以提高跨轮次转录的一致性。

Qwen3.5-Omni:新一代大规模原生全模态大模型

Qwen3.5-Omni 是 Qwen 最新一代全模态大模型,支持文本、图片、音频、音视频理解。结构上,Qwen3.5-Omni 的 Thinker 与 Talker 均采用 Hybrid-Attention MoE 架构。Qwen3.5-Omni 系列包含 Plus、Flash、Light 三种尺寸的 Instruct 版本,支持 256k 长上下文,模型支持超过 10 小时的音频输入及超过 400 秒的 720P(1 FPS)音视频输入。模型在海量文本、视觉以及超过 1 亿小时的音视频数据上进行原生多模态预训练,该模型展现出卓越的全模态感知与生成能力。相比 Qwen3-Omni,Qwen3.5-Omni 多语言能力大大增强,能够支持 113 种语种和方言的语音识别和 36 种语种和方言的语音生成。

Qwen3.5-Omni 延续采用 Thinker-Talker 架构,Thinker 通过 Vision Encoder 和 AuT 接受视觉和音频信号输入,音视频信号通过 interleave 交织并搭配 TMRoPE 编码位置信息。Thinker 负责处理全模态信号并输出文本,Talker 负责接收来自 Thinker 的多模态输入以及文本输出,进行 contextual 语音生成,语音表征通过 Qwen3-Omni 提出的 RVQ 编码来替代繁重的 DiT 运算。由于 chunk-wise 的流式输入设计和流式 Talker 设计,整个模型可以进行 realtime interaction。不同于上一代 Qwen3-Omni 的双轨 Talker 输入,Talker 在输入的组织方式上采用了 ARIA(自适应速率交错对齐,Adaptive Rate Interleave Alignment)来动态对齐文本与语音单元,然后进行交错排布,以避免由于文本与语音 Token 编码效率差异导致的语音不稳定性,如漏读、误读或数字发音模糊等问题。

论文最重要的结论可以概括为三点:第一,模型规模扩展到数千亿参数级,并支持 256k 上下文;第二,训练使用了异构图文数据和超过 1 亿小时的音视频数据;第三,Qwen3.5-Omni-Plus 在 215 个音频与音视频理解、推理、交互子任务上达到强竞争力,尤其在音频理解、ASR、语音翻译和语音生成上表现突出。

1. 模型定位:从多模态理解走向全模态交互

Qwen3.5-Omni 处理的输入包括文本、图像、音频、无声视频和带音频的视频,输出则覆盖文本和流式语音。论文强调它是“native omni agent model”:模型不仅能感知和回答,还能进行 WebSearch、FunctionCall、实时语音交互和 Audio-Visual Vibe Coding,也就是从音视频指令中直接生成可执行代码。

从输入建模上看,不同模态会被转换为统一 token 序列。可以把它抽象为:

\( X = [x_{\mathrm{text}};\ f_{\mathrm{audio}}(a);\ f_{\mathrm{vision}}(v)] \)

其中 \(f_{\mathrm{audio}}\) 是 AuT 音频编码器,\(f_{\mathrm{vision}}\) 是视觉编码器,Thinker 在统一序列上生成文本级高层表示,Talker 再基于 Thinker 的输出生成流式语音 token。

2. 模型设计:Thinker-Talker + Hybrid MoE

Qwen3.5-Omni 延续 Qwen2.5-Omni 和 Qwen3-Omni 的 Thinker-Talker 架构,但在可扩展性、长上下文和流式语音上做了明显升级。

  • Thinker:负责文本生成和跨模态理解。它接收文本、音频、图像、视频的统一表示,并支持 chunk-wise streaming input processing。
  • Talker:负责语音生成。它接收 Thinker 的高层表示和当前轮文本输出,生成 RVQ codec token,再由 Code2Wav 渲染为波形。
  • Hybrid Attention MoE:Thinker 和 Talker 都采用 Hybrid MoE Transformer。论文特别提到其中的 Gated Delta Net 有助于长音视频序列建模,降低 KV-cache I/O 压力,提高吞吐和并发。
  • 长上下文能力:模型输入支持 256k token,约等价于超过 10 小时音频,或 400 秒 720P 视频(1 FPS)。

在感知端,文本使用 Qwen3.5 tokenizer,词表从 150k 扩到 250k,论文称多数语言的编解码效率提升 10% 到 60%。音频被重采样到 16kHz,转成 128 通道 Mel 频谱,使用 25ms 窗口和 10ms hop。AuT 音频编码器从头训练,使用 40M 小时音频文本对,经过 4 个 Conv2D block 下采样 16 倍,输出约 6.25Hz 的音频 token,也就是每个输出帧约对应 160ms 原始音频。

在视频和音视频同步上,论文不再只依赖稀疏的绝对时间位置 ID,而是在每个视频或音视频 temporal patch 前插入秒级 timestamp 文本,并在音频序列中随机插入 timestamp。这会略微增加上下文长度,但能让模型更自然地学习时间码,尤其适合长视频和长音频场景。

3. ARIA:解决流式语音中的文本-语音速率错配

论文中最值得关注的创新之一是 ARIA(Adaptive Rate Interleave Alignment)。在流式语音生成中,文本 token 和语音 codec token 的编码效率不同。如果二者对齐不好,就容易出现跳词、发音错误、数字读法混乱、语音不自然等问题。

Qwen3.5-Omni 不再采用固定 interleaving 速率,也不依赖 MFA 这类外部对齐,而是把文本和语音 token 统一到一个单通道交错序列中,并施加自适应速率约束。可简化表示为:

\( \frac{N_{\mathrm{speech}}(y_{\le t})}{N_{\mathrm{text}}(y_{\le t})} \le \frac{N_{\mathrm{speech}}(y)}{N_{\mathrm{text}}(y)} \)

这里 \(y_{\le t}\) 表示当前生成前缀,\(N_{\mathrm{speech}}\) 和 \(N_{\mathrm{text}}\) 分别表示前缀中的语音 token 数和文本 token 数。直观理解是:任何前缀中的语音生成进度都不能跑得比该样本整体文本-语音比例更快。这样既保留流式输出,又减少双轨同步开销。

Talker 的语音 codec 采用 RVQ 多码本表示,并通过 MTP 模块预测当前帧的残差码本。可以抽象为:

\( P(c_t^1,\ldots,c_t^K \mid c_{<t}, h) = \prod_{k=1}^{K} P(c_t^k \mid c_t^{<k}, c_{<t}, h) \)

其中 \(h\) 是 Thinker 提供的上下文表示,\(c_t^k\) 是第 \(t\) 帧第 \(k\) 个 codec codebook token。随后 causal ConvNet 逐帧把 codec token 转为波形,从而支持低延迟流式合成。

4. 数据与训练流程

Qwen3.5-Omni 的训练覆盖纯文本、图文、视频文本、音频文本、视频音频和视频音频文本等数据。论文披露了几个关键规模:

  • 总体使用超过 1 亿小时音视频内容。
  • AuT 音频编码器使用 40M 小时音频文本对训练,由 Qwen3-ASR 生成监督信号。
  • Talker 初始阶段使用超过 20M 小时多语言语音数据,并配合多模态上下文。
  • 第二阶段预训练使用约 4T token,其中 text 0.92T、audio 1.99T、image 0.95T、video 0.14T、video-audio 0.29T。
  • 支持范围:文本 201 种语言/变体,语音输入 113 种语言/方言,语音输出 36 种语言/方言。

预训练分为三阶段。S1 是 Encoder Alignment,冻结 LLM,分别训练视觉和音频编码器及 adapter;S2 是 General Stage,解冻所有参数,用多模态混合数据训练,序列长度为 32,768;S3 是 Long Context Stage,把最大长度提升到 262,144,并提高长音频、长视频占比。

后训练也分 Thinker 和 Talker。Thinker 使用三阶段策略:专门教师模型蒸馏、on-policy distillation,以及面向多轮交互的强化学习。Talker 使用四阶段策略:通用训练、长上下文 CPT、DPO/GSPO 偏好优化,以及轻量 speaker fine-tuning,用于增强自然度、表现力、语音可控性和零样本/定制音色能力。

5. 流式延迟与并发

论文给出了端到端首包延迟。单并发下,Qwen3.5-Omni-Flash 的音频输入首包延迟为 235ms,视频输入为 426ms;Qwen3.5-Omni-Plus 分别为 435ms 和 651ms。8 并发下,Flash 的音频/视频整体延迟为 352ms/1625ms,Plus 为 955ms/1980ms。

需要注意,论文明确说明 Flash 和 Plus 因模型规模、部署资源和并行策略不同,不适合做严格横向延迟比较。更关键的结论是:ARIA、chunked prefilling、MTP 和 streaming ConvNet 共同把首包语音延迟控制在可交互范围内。

6. 实验结果:理解能力基本不牺牲,音频能力明显增强

文本能力:Qwen3.5-Omni-Plus 基本保持了 Qwen3.5-Plus-NoThinking 的文本能力。比如 MMLU-Pro 为 85.9 vs 86.8,MMLU-Redux 为 94.2 vs 94.3,C-Eval 为 92.0 vs 92.3,LiveCodeBench v6 为 65.6 vs 67.1。值得注意的是 IFBench 上 Omni-Plus 为 52.6,略高于文本基线的 51.1。

音频理解与 ASR:与 Gemini-3.1 Pro 相比,Qwen3.5-Omni-Plus 在多个音频任务上更强。MMAU 为 82.2 vs 81.1,MMSU 为 82.8 vs 81.3,RUL-MuchoMusic 为 72.4 vs 59.6,VoiceBench 为 93.1 vs 88.9。ASR 方面,Fleurs top60 WER 为 6.55,低于 Gemini-3.1 Pro 的 7.32;LibriSpeech clean/other 为 1.11/2.23,也明显低于 3.36/4.41。

视觉与视频:Qwen3.5-Omni-Plus 在视觉任务上接近 Qwen3.5 文本/视觉基线,并在部分视频任务上更好。例如 RealWorldQA 为 84.1,高于基线 79.1;VideoMME w/o subtitles 为 81.9,高于 81.0;MLVU 为 86.8,高于 85.1;LVBench 为 71.2,高于 68.6。这说明音视频联合训练没有明显损伤视觉能力,反而增强了动态视觉场景的表现。

音视频理解:在 AudioVisual → Text 任务中,Qwen3.5-Omni-Plus 在 DailyOmni 上达到 84.6,高于 Gemini-3.1 Pro 的 82.7;Qualcomm IVD 为 68.5,高于 66.2;Omni-Cloze 为 64.8,高于 57.2。但它在 WorldSense、AV-SpeakerBench、VideoMME with audio 和 OmniGAIA 上仍低于 Gemini-3.1 Pro,说明音视频综合推理和工具使用仍有改进空间。

语音生成:在 SEED-TTS 零样本语音生成中,Qwen3.5-Omni-Plus 的 WER 为 test-zh 0.99、test-en 1.26,优于 Qwen3-Omni-30B-A3B 的 1.07/1.39,也在英文子集上超过 CosyVoice 3 的 1.45。多语言语音生成中,论文称 Qwen3.5-Omni 在 29 个评测语言中有 22 个取得最低 WER,并在多数语言上有更高 speaker similarity。

跨语言与定制音色:跨语言语音生成中,Qwen3.5-Omni 在 12 个方向中 10 个最好。比如 Chinese-to-Korean 错误率为 4.03,而 CosyVoice3 是 14.4,相对降低约 72%。定制音色方面,论文在 2026 年 3 月通过官方 API 对比 ElevenLabs、Gemini-2.5 Pro-Preview-TTS、GPT-Audio-2025-08-28 和 MiniMax-Speech-2.8-HD,Qwen3.5-Omni 在 29 种语言中有 10 种取得最佳 WER,并在日语、韩语等场景表现突出。

7. 关键创新点

  • 全模态 Agent 化:模型不只回答问题,还能执行 WebSearch、FunctionCall,并展现 Audio-Visual Vibe Coding 能力。
  • Thinker-Talker 的 MoE 升级:Thinker 和 Talker 都采用 Hybrid MoE,兼顾长上下文、多模态建模和服务并发。
  • ARIA 对齐机制:用自适应文本-语音速率约束替代固定对齐,改善流式语音的稳定性、韵律和发音自然度。
  • 多码本流式语音生成:RVQ token、MTP 和 causal ConvNet 组合,让语音可以从首个 codec frame 开始增量合成。
  • 时间戳显式建模:在音视频 patch 中插入文本 timestamp,提升长视频、长音频的时间感知和跨模态同步。
  • 大规模多语言训练:覆盖 113 种语音输入语言/方言和 36 种语音输出语言/方言,扩展了 ASR、TTS、跨语言 voice cloning 的边界。

8. 局限

这篇技术报告给出了大量指标,但仍有几个需要谨慎理解的地方。第一,Qwen3.5-Omni-Plus 和 Flash 的延迟数字不适合严格横比,因为部署资源和并行策略不同。第二,音视频综合任务并非全面领先 Gemini-3.1 Pro,尤其 WorldSense、AV-SpeakerBench、VideoMME with audio 和 OmniGAIA 仍有差距。第三,模型训练数据规模很大,但数据构成和过滤细节仍是技术报告级披露,不等于完全可复现。

总体来看,Qwen3.5-Omni 的意义在于把全模态模型从“看图、听音、回答”推进到“实时听看、连续说话、保持长上下文、能调用工具”的阶段。它的架构亮点不只是参数更大,而是通过 Hybrid MoE、ARIA、多码本 codec 和显式时间戳,把模型服务、流式交互和多语言语音生成这些工程难点一起纳入设计。

SoulX-Duplug 面向全双工语音对话系统即插即用流式状态预测模型

SoulX-Duplug —— 一款面向 全双工语音对话系统的即插即用流式状态预测模块。SoulX-Duplug 旨在解决当前语音对话系统中 实时交互能力不足、系统响应延迟高、模块耦合严重 等问题。通过将 语音活动检测(VAD)、语音识别(ASR)与对话轮次判断(Turn Detection)统一建模,SoulX-Duplug 可以帮助传统的半双工语音系统在 无需修改原有模型架构的情况下,快速获得 全双工语音交互能力。 项目还开源了 SoulX-Duplug-Eval,一个面向全双工语音对话系统的 双语评测基准,以促进该领域更标准化和可比较的研究。

Introduction

传统语音对话系统通常采用 半双工(Half-Duplex)交互模式:系统在用户说话时只能“听”,而在系统回答时用户则无法打断。这种严格分离的听说流程,使得交互节奏显得机械,也限制了真实对话中常见的打断(interruption)、停顿(pause)、附和(backchannel)等行为。 相比之下,全双工语音对话系统允许系统在生成回复的同时持续监听用户输入,从而支持更加自然的实时互动体验。

近年来,一些端到端全双工语音模型开始出现,但这类方法通常将 语言生成与交互控制强耦合 在同一个模型中,带来了新的挑战:

  • 模型训练难度高
  • 数据需求巨大
  • 交互策略难以控制
  • 系统扩展性受限

在实际工业系统中,更常见的方案是通过 VAD + ASR + Turn Detection 等模块组成级联流水线,为半双工系统提供基本的全双工能力。然而,这种方式也存在明显问题:

  • 传统 VAD 仅依赖声学特征,缺乏语义理解
  • 非流式 ASR 会带来额外延迟
  • 多模块级联导致系统响应速度下降

领域内目前仍缺乏开源的流式 semantic VAD 方案。SoulX-Duplug 正是在这样的背景下提出的一种独立、可扩展的解决方案。通过将语音交互中的双工控制能力从对话模型中解耦为独立模块并进行开源,SoulX-Duplug 旨在缓解全双工模型在数据规模与系统扩展性方面的挑战,使语音对话模型的优化能够更多聚焦于记忆能力、推理能力与共情能力等核心智能能力,而不必始终受到全双工交互机制的复杂约束。与此同时,通过引入文本引导的流式状态预测机制,SoulX-Duplug 能够更准确地理解用户语义意图,并在模块化架构下尽可能降低系统延迟,从而实现更自然、高效的实时语音交互体验。

SoulX-Duplug

Overview

SoulX-Duplug 是一个面向实时语音交互场景设计的 统一流式状态预测模块。与传统基于多模块级联的全双工语音系统不同,SoulX-Duplug 在单一模型框架中同时完成:

  • 语音活动检测(VAD)
  • 流式语音识别(ASR)
  • 对话状态预测(Dialogue State Prediction)

通过统一建模这些任务,SoulX-Duplug 能够在持续音频输入的情况下实时理解用户语音内容,并动态预测对话交互状态,从而实现更自然的全双工语音互动。总体架构上,SoulX-Duplug 采用 GLM-4-Voice speech tokenizer 以12.5Hz 的频率提取离散语音 token,取 160ms  (2 token)  的处理窗口流式交替生成语音识别文本与对话状态 token。这种设计使模型能够通过语音识别理解语义并判断当前对话状态,从而实现低延迟的交互控制。

State Token Design

为了刻画全双工语音对话中的交互动态,SoulX-Duplug 定义了五种核心状态 token:

  • user_idle 表示当前音频片段不包含语义信息,例如静音或背景噪声。
  • user_nonidle 表示用户正在进行具有语义内容的语音输入。
  • user_backchannel 表示用户“嗯”“对”等 backchannel 行为。
  • user_complete 表示用户当前语句在语义上已经完成,系统可以接管对话轮次并进行回复。
  • user_incomplete 表示用户虽然暂时停顿,但语句在语义上仍未结束,系统需要继续等待用户输入。 通过这种定义方式对对话状态进行了清晰、结构化的建模。

Speech Input Modeling

采用 GLM-4-Voice tokenizer,以 12.5 Hz 的频率提取音频 token:

Ad​=[ad,1​,ad,2​,…,ad,N​]

该 tokenizer 是一种 block-causal(块因果)语音 tokenizer,在大规模语音数据上预训练,可作为双语语音理解的基础编码器

在流式推理中:

  • 使用 block size = 12 进行音频 token 生成
  • 每一步处理:
    • 目标窗口(target window):160 ms
    • 左上下文(look-back):960 ms
    • 右上下文(look-ahead):40 ms

因此总感受野(receptive field)为: 1160 ms,共提取 15 个 token目标区域对应的 token 与 block 中的倒数第二和倒数第三个 token 对齐。随后,通过一个线性 encoder projector,将 Ad​ 的 embedding 映射为特征 A,以匹配 LLM 的 embedding 维度:

A=MLP(Ad)

文本引导的流式状态预测

为了在流式状态预测中显式引入语义信息,我们创新性地引入了联合 ASR 目标,并设计了交错预测范式(interleaved prediction)

{A1,T1,S1,A2,T2,S2,…,AT,TT,ST}

每个 160 ms 音频块对应两个音频 token:

At​=[at,1​,at,2​]

在历史上下文 Ht−1条件下,模型首先预测当前块的 ASR token 序列:

Tt​∼P(Tt​∣A≤t​,T<t​,S<t​)

其中Tt​:与第 t 个音频块对齐的流式 ASR 输出,在生成 Tt​ 之后,模型进一步预测对话状态 token:

St​∼P(St​∣A≤t​,T≤t​,S<t​)

  • St​:当前音频块对应的全双工对话状态

这种交错式设计在保持流式推理能力的同时,使状态预测能够获得显式的语义引导

Training Objective

由于不同类型的 token(例如文本 token、<asr_eos> 以及各种状态 token)在长序列中的出现频率差异较大,我们采用加权的 token 级训练目标

设:

  • Y:完整的目标 token 序列
  • yj​:第j 个 token

整体损失定义为:

其中:

  • LCE(yj​):预测 token yj​ 的交叉熵损失
  • τ(yj​):将 token 映射到其所属类型(如 ASR token / state token)
  • λτ(yj​)​:针对不同 token 类型设置的权重系数,用于在不同类别之间进行训练平衡

三阶段混合训练+ Teacher-Forced 推理

设计了三个顺序训练阶段:

  • 非流式 ASR 预训练。目标:学习基础语音识别能力
  • 流式 ASR 适配。目标:让模型适应 streaming 场景
  • 全双工状态预测微调。目标:强化实时对话管理能力(state prediction)

Hybrid 训练-推理策略。SoulX-Duplug 采用训练与推理不完全一致(hybrid)的策略:

训练阶段(第 3 阶段):

  • 端到端联合优化:
    • VAD + ASR + 状态预测

推理阶段:

  • 使用一个轻量级外部 ASR 模型(如 SenseVoice Small)
  • 为每个 chunk 提供:
    • teacher-forced 的流式 ASR 输出

这个设计的本质

训练时学“联合建模能力”,推理时用更强/更稳的 ASR 来“喂语义”,提升稳定性和效率。

算法延迟

  • 每个 audio chunk = 160 ms
  • 用户语音在 chunk tit_iti​ 内结束

由于模型是流式的:

必须等到下一个 chunk ti+1​ 才能确认“后面没有语音”

在处理ti+1​ 时:

  1. 检测到没有语音(VAD = silent)
  2. 判定 <|user_nonidle|> 结束
  3. 决策:
    • <|user_complete|>(语义完成)
    • <|user_incomplete|>(语义未完成)

由于语音结束点在 chunk 内均匀分布:

  • 平均等待时间:80 ms(= 160 / 2)
  • 再加一个 chunk:160 ms

最终:

Latencyavg=80 ms+160 ms=240 ms

SoulX-Duplug-Eval

为了解决现有全双工语音对话基准中跨语言评测资源不足的问题,我们构建了补充性的测试集,用于提升不同模型之间的可比性,并在对话状态预测系统级全双工对话两种评测设置下,实现标准化与公平比较。

提出 Easy Turn testset-En,作为原始 Easy Turn testset 的英文对应版本。

该数据集主要用于全双工状态预测(duplex state prediction),包含两类数据:

Complete(完整句)

  • 318 条样本
  • 内容为语义完整的 utterance
  • 由 ChatGPT 生成,并使用 ChatTTS2 [36] 合成

Incomplete(不完整句)

  • 299 条样本
  • 内容为语义不完整的 utterance
  • 同样由 ChatGPT 生成并通过 ChatTTS2 合成

为了支持中文场景下的系统级评测,我们构建了 Full-Duplex-Bench-Zh,作为 Full-Duplex-Bench的中文版本。

该数据集覆盖四种具有代表性的交互场景,所有文本均由 ChatGPT 生成,并通过最先进的 TTS 系统合成。

包括:

  • Turn-Taking 子集(轮次切换):用户连续说话数秒随后 15 秒静音,评估是否正确判断用户说完
  • Pause Handling 子集(停顿处理):单条 utterance 中插入多个停顿,区分自然停顿和语义未结束
  • User Backchannel 子集(用户附和):短 backchannel(如“嗯”“对”),防止模型误抢话
  • User Interruption 子集(用户中断/续说):是否识别“用户未说完”,是否正确预测 <|user_incomplete|>

实验

训练设置

中文数据总计约 47,000 小时。英文数据共计约 31,000小时。

在流式 ASR 训练中:

  1. 首先获取 字符级或词级对齐(alignment)【使用 Paraformer3 /WhisperX 生成时间戳】
  2. 将数据重组为 基于 chunk 的交错格式(interleaved chunk-based format)

状态预测训练阶段(State Prediction Stage):

英文数据:

  • 使用 Fisher 数据集 [14]
  • 规模:千小时级

中文数据:

  • 使用内部构建的约 万小时级语料
  • 构造方式与 Fisher 保持一致

数据标注与清洗流程

  1. 先进行对齐(alignment)
  2. 中文数据:
    • 使用 双 ASR 一致性过滤
  3. 数据增强:
    • 全局添加 Musan 噪声
    • 在静音片段加入 ESC-50 噪声
  4. 状态标签:
    • 使用 Qwen2.5-72B-Instruct进行自动标注

SoulX-Duplug 模型:

  • 语音编码器:预训练 GLM-4-Voice tokenizer
  • LLM backbone:Qwen3-0.6B [48]
  • speech tokenizer:全程冻结(frozen)

训练策略

  • ASR 预训练 LLM:全量微调 adapter:全量微调
  • 状态预测阶段对 LLM 使用 LoRA ,rank = 32,训练数据:双语 trainsets

推理设置

使用 teacher-forcing ASR 提供更准确文本引导 【中文:Paraformer,英文SenseVoice Small】

为了评估 SoulX-Duplug 的对话状态控制能力:Qwen2.5-7B-Instruct + IndexTTS-1.5

评测指标(Metrics)

  • Takeover Rate (TOR)
  • Response Latency (RL)
  • Resume Rate (RsR)
  • Respond Rate (RpR)
  • Stop Latency (SL)

结果

为了验证 SoulX-Duplug 在真实系统中的效果,团队以 SoulX-Duplug 作为对话状态控制模块构建了一个完整的全双工语音对话系统,并在中英双语的 Full-Duplex-Bench 基准上对系统进行了全面评测,该 benchmark 涵盖了:Turn Taking(轮次切换)、Pause Handling(停顿处理)、User Backchannel(用户附和)、User Interruption(用户打断)等多种全双工对话关键场景。

实验结果表明,基于 SoulX-Duplug 构建的系统在多个评测维度上取得了稳定且均衡的整体表现。在整体的 turn management 能力上优于现有模型,并在总体响应延迟指标上同样表现优异。这一结果充分验证了 SoulX-Duplug 的对话状态控制能力以及在系统构建中的实用价值。

同时,实际部署环境中 SoulX-Duplug 的独立模块的平均延迟约为 250ms,接近其理论延迟 240ms。这一结果显著优于传统基于 VAD 的方案(约 500ms),也低于近期提出的 FlexDuo 模块(约 343ms)。

Further Discussion

围绕全双工语音对话系统(FD-SDS)的设计与部署形成了若干观察与思考:

1、小 chunk 流式 ASR 识别效果较差

采用非常小的 chunk size 进行流式 ASR 在本质上仍然具有较大挑战。当 chunk 时长较短时,声学片段经常会跨越音素、音节或词边界被切分。这一问题在英语中尤为明显,因为单词很容易被切分到相邻的多个 chunk 中,从而导致识别不稳定以及瞬时错误。因此,在严格低延迟约束下,预测波动在一定程度上是不可避免的。此外,在实时流式场景中,基于 LLM 的方法虽然具有较强的上下文建模能力,但其上下文仍受限于增量解码(incremental decoding)以及有限的未来信息。因此,基于 LLM 的 ASR 模型在“解码速度与识别准确率的综合权衡”方面,并不一定优于传统结构(如 RNN-T)。

2、模块化系统 vs 端到端系统

尽管近年来端到端全双工语音对话模型(FD-SDMs)在经验表现上取得了较强效果,并展现出较大潜力,但它们通常需要大规模训练数据与较高计算资源。相比之下,模块化系统更易于实现与维护。当系统出现性能问题时,可以在不重新训练整个系统的情况下,对单个模块进行调整或替换。这种灵活性使得模块化设计在实际部署中可能更具优势

最后,目前的研究工作对实时应用的支持仍然相对有限。仍然需要更加成熟且易用的开源流式语音编码器与 ASR 模型。持续推进这一方向的发展,将有助于真正实现可落地的全双工语音对话系统(FD-SDSs)。